[Coco] Kicking the Z-80 butts...

[Dave Philipsen]

Hey, if you implement the processor itself in FPGA you might find that 
it could keep up fairly well with some of the larger graphics spaces.  
I've got a little Altera board that is running a 6809 core at 25 MHz.  
Currently I've got it throttled back to 16 MHz so I can access an 
external 55ns static RAM with no wait states.  Hoping to get a 10ns RAM 
working soon so I can go back to the 25 MHz.

Also, at about 25 MHz you can run a pixel clock that will give you VGA 
resolutions.  So why couldn't you implement a 640x480 graphics system 
that refreshes itself on the opposite side of the clock much the same as 
the VDG and GIME work on the CoCo?   ....just an idea.

Dave Philipsen


On 4/28/2015 3:19 PM, Zippster wrote:
> Yes, at 32K per screen, those last modes you mentioned would be getting pretty cumbersome to move around in 64k.
> I would think that is a maximum as well, though probably workable.
>
> I’ve been thinking about an idea for an FPGA based VDG for 8-bits that would get the pages out of the 64K address space
> and pretty much allow for as much resolution and colors as the CPU could reasonably keep up with as far as reading and writing to
> them.  The timing should be fun…  :)
>
> - Ed
>
>
>> On Apr 28, 2015, at 2:44 PM, Hugo Dufort <hugo at seshat.ca> wrote:
>>
>> As I have mentioned in another discussion recently, had Tandy moved away from the VDG & designed their own "slightly improved VDG" at the time of the Coco2, they could have supported some additional low-res video modes with some very interesting features. All within the 64k limit, and aligned to the 1.5k video pages (PMODE/CPLEAR), respecting the existing limits, e.g. PCLEAR8.
>>
>> For example:
>> 64x96 x256colors (6k/screen)
>> 128x96 x16colors (6k/screen)
>> 128x96 x256colors (12k/screen)
>> 128x192 x16colors (12k/screen)
>> 256x192 x4colors (12k/screen)
>>
>> +RGBI palette support for all these modes (available: the 64 EGA colors x4 shades)
>>
>> This would have paved the way to higher resolution 16-color and 256-color modes in the Coco3. But at this point, we wouldn't have been able to map 256x192x256colors high-memory pages to low-memory pages in an efficient way. Addressing this mode would have been complex, especially for full-screen game development. I really think the maximum workable resolutions for the Coco3 (limited to 64k low memory, whatever the addition memory is) would have been:
>> 160x200 x256colors
>> 320x200 x16colors
>>
>> But it's all speculation and "in hindsight", of course! ;)
>>
>> Hugo
>>
>> Le 2015-04-28 15:20, Zippster a écrit :
>>> Well, it is late ‘70s technology.  Earlier that decade the first microprocessors were introduced.
>>> I guess the 6847’s major weak point is probably the terribly limited 32 column text display.
>>> Other VDGs of the time were pretty low-resolution as well.  But you have to remember there
>>> wasn’t much resolution available on the display devices either, even if you would have had the silicon for it.
>>>
>>> Video is just a massive amount of data once you start to move past 300x200 or so and just a few colors.
>>> Even the 6809 will start to choke pretty quickly heading in that direction.
>>>
>>> Although it is a pretty incredible 8-bit CPU with an interesting story behind it.
>>> It should have been more popular.
>>>
>>> - Ed
>>>
>