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

[Hugo Dufort]

I think a pure 64-machine should limit itself to 12kb or 16kb max for 
its video modes ; otherwise you don't have much left for your OS and 
application.

The Coco3, with its extended paged memory, can handle 32k graphics pages 
without trouble (but using full resolution makes scrolling and 
double-buffering difficult). In fact, you can easily swap 4x8k pages 
using the MMU banks #4-7 (for instance) in ASM calls and NOT nuke DECB. 
I have used this strategy in my ASM sprite function for Paul Thayer's 
BASIC game. Tandy's memory management strategy for DECB rather uses MMU 
pages #1-4 for video, and page 6 for the HGET/HPUT buffers page.

Hugo

Le 2015-04-28 16:19, Zippster a écrit :
> 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
>>>
>


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
http://www.avast.com