CGA 80x50x64k Mode Preview

[chjmartin2]

Ok, well... not exactly... I am working on the code to display this, but it is an 80x50 half height text mode using a fixed character (everything is the 50/50 shaded character) and a set of 4 different colors in two frames. The color matching is done by scaling a 640x200 image down to 80x50 and finding the closest match to the average of any four CGA colors. Those four colors are then displayed as the foreground and background in a set of two frames. When I write the display routine, the bright frame and dark frame will be interleaved. This is the simulated output. Each 80x50 image would only require 2,000 bytes because of the fixed character usage. The effect only works at 60 fps, but if you wanted to produce video playback you could flicker at 60 fps using bank-switching at a fixed divisor of 60 fps.

https://docs.google.com/file/d/0B4xJFZXUVgkydG5qZTNHNVBiUzQ/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkyT0FNSkRBNWxFdWs/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkyWjVZLUtBX3R5cDQ/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkybkluSnBZZlRLX0U/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkyWTl5b0NHbVI5T3M/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkyTS1VNUpOUlNFbk0/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkyRjlwMVhveVB1WGM/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkyb3R0bkY4dTNQaWc/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkycmk2WHg1MlVsSFk/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkyWDdXNVozWnhTa0E/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkyc20tT3JSOVc2aVU/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkyX2JvSVFyZ3lxMGs/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkyczFqeDU3czRHWnc/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkyVjBfSzdybHd5T0k/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkyeU1vaE0tNU9Gdmc/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkydW5lYnhZVVpvMjA/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkyVWpJWFFtWHQxY2c/edit?usp=sharing
https://docs.google.com/file/d/0B4xJFZXUVgkybE1KOTlRRlZiUkU/edit?usp=sharing

 

[Shadow Lord]

That is some excellent trickery. Of course the resolution (once past the thumbnail size) is a little underwhelming but nonetheless it is damn amazing if you could get it to work. I remember something similar back in the day where somebody had made a number of CGA games (ShareWare only) that had many more colors then the usual cyan/magenta scheme.

 

[pearce_jj]

Each 80x50 image would only require 2,000 bytes because of the fixed character usage. The effect only works at 60 fps, but if you wanted to produce video playback you could flicker at 60 fps using bank-switching at a fixed divisor of 60 fps.

Very nice! 60 fps is certainly possible, however my understanding is that snow is a very obviously problem when using 80-character text modes on the stock CGA adapter?

 

[reenigne]

Ok, well... not exactly... I am working on the code to display this, but it is an 80x50 half height text mode using a fixed character (everything is the 50/50 shaded character) and a set of 4 different colors in two frames. The color matching is done by scaling a 640x200 image down to 80x50 and finding the closest match to the average of any four CGA colors. Those four colors are then displayed as the foreground and background in a set of two frames.

Very cool! Does the converter use gamma correction?

When I write the display routine, the bright frame and dark frame will be interleaved. This is the simulated output. Each 80x50 image would only require 2,000 bytes because of the fixed character usage.

16.000 bytes surely? 80 characters * 50 rows * 2 bytes per character * 2 frames.

I wrote a simple viewer - https://github.com/reenigne/reenigne/tree/master/8088/cga/64kcolors (binary at http://www.reenigne.org/misc/64.com). To use this, append the generated data to the end in CGA memory dump format (i.e. every even byte needs to be 0xb1, odd bytes are attributes, second frame starts at byte 8000):
copy /b 64.com+data.bin 64k.com
Then you can just run 64k.com.

If you send me the data files I'll take photographs of how it looks on my 5153.

 

[reenigne]

I remember something similar back in the day where somebody had made a number of CGA games (ShareWare only) that had many more colors then the usual cyan/magenta scheme.

Do you happen to remember the details? Was this the 160x100x16 colour mode?

 

[reenigne]

Very nice! 60 fps is certainly possible, however my understanding is that snow is a very obviously problem when using 80-character text modes on the stock CGA adapter?

Snow is a problem when modifying video memory, but there's enough video memory to hold two pages of 80x50 text and therefore to display these images (changing the CRTC start address doesn't cause snow). Doing animation in this mode would be either very snowy or very slow, though.

 

[Shadow Lord]

Do you happen to remember the details? Was this the 160x100x16 colour mode?

Unfortunately no. I know I had a demo of it on a disk somewhere. I will look for it and see if I still have it...

 

[chjmartin2]

Very cool! Does the converter use gamma correction?



16.000 bytes surely? 80 characters * 50 rows * 2 bytes per character * 2 frames.

I wrote a simple viewer - https://github.com/reenigne/reenigne/tree/master/8088/cga/64kcolors (binary at http://www.reenigne.org/misc/64.com). To use this, append the generated data to the end in CGA memory dump format (i.e. every even byte needs to be 0xb1, odd bytes are attributes, second frame starts at byte 8000):
copy /b 64.com+data.bin 64k.com
Then you can just run 64k.com.

If you send me the data files I'll take photographs of how it looks on my 5153.

Wow. I can do that tonight. Easy to get packed.

The overall data is 16,000, but every character is the same (50 percent fill) only the colors change. Since color is only 1 byte per character then 80x50 per frame. Is 4,000 per frame and 8,000 per image of real data.

You always ask me about gamma and I do not know how to do.

 

[pearce_jj]

But the quickest way to update the display is either rep movsw or DMA direct from disk; either way we're not going to achieve 60fps with the IBM stock CGA adapter unfortunately because we need to transfer the full 8K per frame.

 

[reenigne]

You always ask me about gamma and I do not know how to do.

Suppose you have two sRGB colours (R1, G1, B1) and (R2, G2, B2). You want to know what colour you get by mixing them together (spatially dithering or temporally flickering) so you can compare to your source image to pick the best set of attribute bytes. The obvious thing would be to just take the per-channel mean: ((R1+R2)/2, (G1+G2)/2, (B1+B2)/2) but that gives colours that are too dark. A better formula is (255*((((R1/255)^2.2 + (R2/255)^2.2)/2)^(1/2.2)), 255*((((G1/255)^2.2 + (G2/255)^2.2)/2)^(1/2.2)), 255*((((B1/255)^2.2 + (B2/255)^2.2)/2)^(1/2.2))). Looks a bit daunting, but it's simpler if you break it down into three steps: Convert SRGB to linear, take mean in linear colour space, convert linear back to SRGB:

R1_linear = (R1/255)^2.2; G1_linear = (G1/255)^2.2; B1_linear = (B1/255)^2.2;
R2_linear = (R2/255)^2.2; G2_linear = (G2/255)^2.2; B2_linear = (B2/255)^2.2;
R_linear = (R1_linear + R2_linear)/2; G_linear = (G1_linear + G2_linear)/2; B_linear = (B1_linear + B2_linear)/2;
R = 255*(R_linear^(1/2.2)); G = 255*(G_linear^(1/2.2)); B = 255*(B_linear^(1/2.2));

You can even convert the input images and CGA palette to linear, then do all the computations as you have been doing and convert the final image back to SRGB for output. I'd be interested to see the results, but I suspect you'll be pleasantly surprised at how much difference it makes.

 

[chjmartin2]

Can you help me with the format a bit more? I have the ASCII value of the character (177) and a foreground (0-15) and background color (0-15).

I think I need to have Byte 0 be 177, and Byte 1 would be f+16*b? Byte 2 is 177 again and so forth..?

 

[Trixter]

I remember something similar back in the day where somebody had made a number of CGA games (ShareWare only) that had many more colors then the usual cyan/magenta scheme.

The most recognizable shareware game that did this was Round 42. Maybe the screenshots will jog your memory?

Very nice! 60 fps is certainly possible, however my understanding is that snow is a very obviously problem when using 80-character text modes on the stock CGA adapter?

You have time to write 480 words per vertical blanking interval and one word per horizontal blanking interval, without snow. That's 1360 bytes per 60Hz frame. This requires near total dedication of the CPU, however.

Doing animation in this mode would be either very snowy or very slow, though.

Slow, indeed (see previous response).

But the quickest way to update the display is either rep movsw or DMA direct from disk

I'm not entirely sure DMA from disk->video RAM is possible -- I've never tried it, but something tells me it isn't going to be "allowed" or work. The one wait state imposed by video ram would be the greatest limiting factor anyway.

 

[Trixter]

Can you help me with the format a bit more? I have the ASCII value of the character (177) and a foreground (0-15) and background color (0-15).

I think I need to have Byte 0 be 177, and Byte 1 would be f+16*b? Byte 2 is 177 again and so forth..?

Format is character|attribute| repeating. Attribute has the background in the high bits and foreground in the low bits:

87654321
BBBBFFFF

So the character "A" with a blue background (1) and a lightgrey foreground (7) looks like this at offsets 0 and 1 of video memory:

87654321 87654321
01000001 00010111
0x41(65) 0x17(23)

Hope I didn't misunderstand your request...

 

[chjmartin2]

If you send me the data files I'll take photographs of how it looks on my 5153.

Here is a file with a picture of Fred flintstone. It will display when I append it to 64.com, but it does not display the second frame?

https://docs.google.com/file/d/0B4xJFZXUVgkyVVJLTmgwV1dUdmM/edit?usp=sharing

The file is Fred.64C.

Not sure why it is not showing the second frame - first frame displays correctly.

 

[pearce_jj]

I'm not entirely sure DMA from disk->video RAM is possible...The one wait state imposed by video ram would be the greatest limiting factor anyway.

It works The DMA controlled respects IORDY through the RDYTODMA line. CGA RAM is the limiting factor as you say - but I measured about 15 fps direct from disk with 16KB frames, giving 240KB/s throughput or there abouts (when I was testing 160x100 mode).

 

[reenigne]

Here is a file with a picture of Fred flintstone. It will display when I append it to 64.com, but it does not display the second frame?

https://docs.google.com/file/d/0B4xJFZXUVgkyVVJLTmgwV1dUdmM/edit?usp=sharing

The file is Fred.64C.

Not sure why it is not showing the second frame - first frame displays correctly.

There were a couple of bugs in my viewer - one preventing display of the second frame and one limiting the number of rows to 40 instead of 50. I've updated the source and binary (same URLs as before), and here's a photograph of how Fred.64C looks on my 5153:



In real life it's very flickery though - I wouldn't be able to look at it for very long without getting a headache.

 

[Trixter]

It works The DMA controlled respects IORDY through the RDYTODMA line. CGA RAM is the limiting factor as you say - but I measured about 15 fps direct from disk with 16KB frames, giving 240KB/s throughput or there abouts (when I was testing 160x100 mode).

While cool to confirm, it may depress you to know that that is the maximum speed attained via REP MOVSW as well. So DMA does not offer a speed benefit if trying to fill video RAM, only a "do this while unattended" benefit. Since Int 13h doesn't offer any background transfer functions, I'm afraid there is no practical use for DMA directly to video memory.

 

[reenigne]

While cool to confirm, it may depress you to know that that is the maximum speed attained via REP MOVSW as well. So DMA does not offer a speed benefit if trying to fill video RAM, only a "do this while unattended" benefit. Since Int 13h doesn't offer any background transfer functions, I'm afraid there is no practical use for DMA directly to video memory.

I think the CGA's theoretical maximum DMA speed is about 436KB/s (4921875/11 bytes per second), so it would be useful with a dedicated piece of hardware. Dedicated hardware can also have dedicated software which could do the transfers in the background while the CPU is doing other things (albeit much more slowly than usual because most of the bus time is taken up with DMA to CGA).

 

[Trixter]

True, but if it only runs on one person's machine, that's not much fun I want the stuff I write to be accessible to all hobbyists.

 

[pearce_jj]

While cool to confirm, it may depress you to know that that is the maximum speed attained via REP MOVSW as well. So DMA does not offer a speed benefit if trying to fill video RAM, only a "do this while unattended" benefit. Since Int 13h doesn't offer any background transfer functions, I'm afraid there is no practical use for DMA directly to video memory.

Oh well

Re the colour mixing, I was wondering if the other shaded character values could expand the colour range even more (176/177/178 )?