• Please review our updated Terms and Rules here

CGA 80x50x64k Mode Preview

Not sure what you mean by "64 combinations of 2x2 sub-pixels" - in 40x100 text mode there are 16 pixels per character cell so you'd need 65536 different characters (actually 32768 since you can swap foreground and background) and you'd still have some ZX-spectrum style "attribute clash" due to only having two different colours per character cell.

How about 40-column text mode, CRTC tweaks for one scanline per row (requires reprogramming some CRTC registers twice per frame from a timer interrupt) and using the characters 0x0d, 0x21, 0x35, 0x4c, 0x48, 0x6a and 0x99. In their top row, these characters have all combinations of pixels you need for a 160-column mode, so that gives you 160x200x16 on an RGBI monitor (with a small amount of attribute clash - two colours per 4-pixel character cell). I came up with this a while ago but never got around to doing anything with it.

I like the optimization part of this. I'm going to start a new thread about the TMV algorithm that I am using...
 
Hi all,

I had posted to this thread a different TMV encoder for 8088 corruption. The main encoder on the thread is not mine, I think mine is on Page 5. Anyway, it was originally a fast encoding engine for flickering two 40x25 screens together. I went ahead and updated the code to make use of the 80x50 mode and viewer that reengine wrote for me. The results are dramatically better, of course still with the limitations of the apparent flicker. Because it is so fast, using a preview mode you can get a really good idea of what the result will look like. I've found that bringing down the overall contrast and brightness of the image can help reduce the effect as well. Anyway, I need some help. I want to recreate some classic BBS .GIF files from back in the day, but I am finding the ones I can find on the web lacking. I know everyone had their own experience because BBS's were different. Before I release my converter I actually want to try to make it into a slideshow demo, maybe even with a loop on the PC speaker of some kind. The quality is good enough that I believe it is worth it to invest the time. I have an idea how to hack one together. Anyway, because I want to do a demo that is 256k (so it would have fit on a 320K floppy back in the day). That would be 16 pictures if I used all of it for pics, but I want music. (I don't want to have to pack them, this is my first attempt at a demo instead of a tool!) Anyway, that means like 12 or so pictures. I want it to run from a 5.25 low density floppy on an 8088 8.0 Mhz with CGA using RGBI.

So... can I get some thoughts on iconic GIF files to use for the slide show. I'm also open to thoughts on a theme for it. Like, maybe an iconic movie, or actress. I'm not sure... Any ideas?

Chris
 
Not sure what you mean by "64 combinations of 2x2 sub-pixels" - in 40x100 text mode there are 16 pixels per character cell so you'd need 65536 different characters (actually 32768 since you can swap foreground and background) and you'd still have some ZX-spectrum style "attribute clash" due to only having two different colours per character cell.

How about 40-column text mode, CRTC tweaks for one scanline per row (requires reprogramming some CRTC registers twice per frame from a timer interrupt) and using the characters 0x0d, 0x21, 0x35, 0x4c, 0x48, 0x6a and 0x99. In their top row, these characters have all combinations of pixels you need for a 160-column mode, so that gives you 160x200x16 on an RGBI monitor (with a small amount of attribute clash - two colours per 4-pixel character cell). I came up with this a while ago but never got around to doing anything with it.

I just re-read this and now I understand what you mean. You could get images like this:

dietcok.gifcheetara.giflena.gif

If you went down to 80x200 and gave me a 60 hz flicker, we could make this:

liberty.gif

The ideal mode would be the best 4:3 character relationship still having control of one scan line. The reason is that the interlacing effect works REALLY well at 200 scan lines. 80x200 is kind of silly. If you could tweak to 160x100 but only one scan line and lower horiz resolution that would be better. The best would be a tweaked mode that gives me the most degrees of freedom for horiz resolution but still using the whole screen and the maximum vertical res. Even if the whole thing is stretched out. Thoughts?
 
Yeah, you've got it! Those are some fantastic images - unless you know better you'd think they were some kind of clone card with a real 160x200x16 mode rather than a tweak mode of genuine CGA.

I do actually have a way to make the mode I think you're asking for. It involves doing a CRTC restart every other scanline, increasing the start address by 40 characters each time. That way, we can effectively duplicate scanlines and do a full-screen 160x100x16 mode (with attribute clash) in 8kB, or a 160x100x136-ish mode in 16kB.

If you care more about having the same vertical pixel-size as a 200-line mode than using the full screen, you can do a 160x100 "widescreen" mode or a 112x140 4:3 mode with two restarts per CRT frame instead of ~100.
 
So... can I get some thoughts on iconic GIF files to use for the slide show. I'm also open to thoughts on a theme for it. Like, maybe an iconic movie, or actress. I'm not sure... Any ideas?

How about images that represent popular culture (pin-ups, movie stills, political figures, sports cars, etc.) from roughly when CGA was made available to when EGA was out? I guess that would be images from roughly 1981 to 1985? (Which would mirror, fairly closely, the stuff we used to trade on BBSes during the latter half of the 1980s)
 
Yeah, you've got it! Those are some fantastic images - unless you know better you'd think they were some kind of clone card with a real 160x200x16 mode rather than a tweak mode of genuine CGA.

I do actually have a way to make the mode I think you're asking for. It involves doing a CRTC restart every other scanline, increasing the start address by 40 characters each time. That way, we can effectively duplicate scanlines and do a full-screen 160x100x16 mode (with attribute clash) in 8kB, or a 160x100x136-ish mode in 16kB.

If you care more about having the same vertical pixel-size as a 200-line mode than using the full screen, you can do a 160x100 "widescreen" mode or a 112x140 4:3 mode with two restarts per CRT frame instead of ~100.

Oh my the options seem so daunting. Right now the interlacing on the 80x50 mode is highly apparent, but on the Tandy mode it is barely there. I am not sure what a mode that does two rows would do, but, here is a preview of the state of my current encoder in the 80x50 mode. (Scaled to 640x400 for reference). I am not happy with the interactivity of the encoder. I am going to change over to Visual Basic instead of Freebasic. It will be a learning curve, but I will make better tools for users. (Algorithm's converters for C64 are so much more elegant.)

POP80x50.jpg

popconv80x50.jpg

It would be good to have both full screen 160x100 and duplicate 160x100. But man... 112x140 would likely be the coolest. Too many choices. I still want to make the 80x50 slideshow... as you can see, it is pretty sweet. (the below example would have big and likely unbearable flicker though)

Chris
 
How about images that represent popular culture (pin-ups, movie stills, political figures, sports cars, etc.) from roughly when CGA was made available to when EGA was out? I guess that would be images from roughly 1981 to 1985? (Which would mirror, fairly closely, the stuff we used to trade on BBSes during the latter half of the 1980s)

It is funny because I thought of that and wanted to do a 1981, 1982, etc. Maybe I should rethink that and actually make images so that I can edit them to the way I want them...

Ok... back to that.
 
Also - I wouldn't just use those characters. I could cycle through all of them the same way I do for the 80x50.
 
What is the best environment to assemble your program? I want to use it to try to make a slideshow and don't want any compiling challenges.

Only have done Z80 assembler, but I'll take a stab at 8086...
 
I usually just use yasm (from a build.bat file that performs all the build steps for whatever project I'm working on) and TSE Pro as my text editor.
 
I usually just use yasm (from a build.bat file that performs all the build steps for whatever project I'm working on) and TSE Pro as my text editor.

So... I am torn now. Should I be working on a new converter? :)
 
Huh? You you can use any toolchain you like for your converter. You can use the output of your converter as the input to another program...

What I meant was that I wasn't sure if I should continue on my 80x50 slideshow, or if I should start working to the new parameters that Reenigne laid out...
 
Yeah, you've got it! Those are some fantastic images - unless you know better you'd think they were some kind of clone card with a real 160x200x16 mode rather than a tweak mode of genuine CGA.

I do actually have a way to make the mode I think you're asking for. It involves doing a CRTC restart every other scanline, increasing the start address by 40 characters each time. That way, we can effectively duplicate scanlines and do a full-screen 160x100x16 mode (with attribute clash) in 8kB, or a 160x100x136-ish mode in 16kB.

If you care more about having the same vertical pixel-size as a 200-line mode than using the full screen, you can do a 160x100 "widescreen" mode or a 112x140 4:3 mode with two restarts per CRT frame instead of ~100.

So, here is the situation. On the Tandy 1000, when I do 640x200x16 and flicker two screens with an interlaced imaged. I get absolutely zero flicker, the tight interlacing really can make the flicker barely visible and with flicker reduction optimizations, it can almost go away. The 80x50 mode can get better color fidelity, but, when I use the reduction techniques, it is good, but not nearly as good as the Tandy result. So, when I came here to talk about the 80x50, then I saw what you were saying about the other mode. Now, I did not make a 320x200 flicker viewer for the Tandy, so, I am not sure what impact the horizontal dot resolution has on flicker.

What I really need is the ability to interleave the flickering, we want to maintain the closest overall image luminosity from one frame to the next. If you look at the below image you can see that image #1, turns into two flickered images in #2. When you flicker them in that way you get a whole dark screen and a whole bright screen and that just flickers horribly. I learned this from the Atari 2600 Chronocolor demo.

interleave.jpg

So the deal here is that the most important thing is the ability to get to one scan line per color change - I think. The 80x50 mode has 4 scan-lines per color change and even with a cross hatch it is too much. I like the idea of the 112x140 option you describe. That would be 14 characters across right? It would be 4x3 and although not full screen I am sure that the best option is the one with the fewest scanlines per interleave. I'd be happy to try both ways.

On to the encoder...

Chris
 

Attachments

  • interleave.jpg
    interleave.jpg
    29.1 KB · Views: 2
So the deal here is that the most important thing is the ability to get to one scan line per color change - I think.

Ah, ok. I was confused about what you meant by that but that clears it up. Yeah, the CGA only has enough memory for one full screen of one-scanline-per-row image data in modes other than 80-column text, so you'll need to reduce the viewport to get two pages. In 80-column text mode you'd need to reduce it even further, to a quarter of the screen.

The 112x140 mode I mentioned uses 28 of the 40 characters horizontally.
 
Ah, ok. I was confused about what you meant by that but that clears it up. Yeah, the CGA only has enough memory for one full screen of one-scanline-per-row image data in modes other than 80-column text, so you'll need to reduce the viewport to get two pages. In 80-column text mode you'd need to reduce it even further, to a quarter of the screen.

The 112x140 mode I mentioned uses 28 of the 40 characters horizontally.

It will be 224x140 with attribute clash and pixel limits if we use every character. Ok. Let me make the converter and post the previews. Is making a viewer trivial for you? I assume I'll do the same we did last time except in a 28x140x2 format. Should be 15,680 bytes, yes?
 
It will be 224x140 with attribute clash and pixel limits if we use every character. Ok. Let me make the converter and post the previews. Is making a viewer trivial for you? I assume I'll do the same we did last time except in a 28x140x2 format. Should be 15,680 bytes, yes?

The converter is done, was pretty easy to change the format. It made me wish I had coded it with constants that I could change, oh well, it is done now. I can't believe we can do this with CGA by the way. I hope it is actually real, because, check out Lena:

Lena_utl.jpg

And the encoder in action:

cgaultimate.jpg

I am so excited to see it in classic RGBI glory. My 5th grade self would spend a week picking his jaw up off the floor...
 
Back
Top