• Please review our updated Terms and Rules here

Tandy 1000 TL - 85 Color Demo

chjmartin2

chjmartin2

Experienced Member
Joined
Dec 26, 2012
Messages
433
Hi,

I have been going back and forth on playing around with CGA graphics, but my only test machine is a Tandy 1000 TL, and, I figured, since I couldn't find anybody who had done it, that I would try to do some tweaked video "modes" and such. There is no huge feat here - but I think it is pretty cool that used GW-Basic made specifically for the 1000 graphics in order to access the graphics card, AND, that I used old school PC Paint to convert GIF files into Bsave files, saving myself a boatload of coding time to get to a demonstration. Now that I know how to get there, I have to play with it more before I give out code, but below is a preview. I keep working if I get some kind of comment! (I keep working anyway, but words of encouragement make me work harder.)


Thanks for watching.

Chris
 
Nice demo!

FYI: you don't need to type LOAD "filename.BAS" and then RUN. As a shortcut, you can just type RUN "filename" (no .BAS required), or even just specify the program name when starting BASIC from the DOS prompt (BASIC filename (no quotes)). :)
 
Awesome! So if I understand it well, you are getting 85 colors by mixing (using a very fast flickering) the 16 basic colors that the RGBI interface supports, and the CRT phosphor does the color composition. 85 is a bit weird number, how do you get it?
 
nestor said:
Awesome! So if I understand it well, you are getting 85 colors by mixing (using a very fast flickering) the 16 basic colors that the RGBI interface supports, and the CRT phosphor does the color composition. 85 is a bit weird number, how do you get it?
Click to expand...

85 is what I make it. All the flickering colours have 2 possible representations (e.g. green and blue gives the same as blue and green) and many have even more (e.g. green and magenta gives the same as red and cyan - both give a mid-grey). If you use the normal CGA palette (the one that the VGA BIOS uses in text modes, for example) and just add the "first frame" colours and the "second frame" colours componentwise (i.e. without attempting to any sort of gamma correction), there are 85 unique combinations.

The fact that colour 6 is brown (67% red, 33% green, 0% blue) instead of matching the pattern set by the other colours (which would make it a muddy yellow - 67% red, 67% green, 0% blue) works as an advantage here - without that there would be only 73 unique combinations.

I wonder what 16-colour palette would give the most different colours with flickering (both in terms of number of different colours and in terms of variety).
 
reenigne said:
85 is what I make it. All the flickering colours have 2 possible representations (e.g. green and blue gives the same as blue and green) and many have even more (e.g. green and magenta gives the same as red and cyan - both give a mid-grey). If you use the normal CGA palette (the one that the VGA BIOS uses in text modes, for example) and just add the "first frame" colours and the "second frame" colours componentwise (i.e. without attempting to any sort of gamma correction), there are 85 unique combinations.

The fact that colour 6 is brown (67% red, 33% green, 0% blue) instead of matching the pattern set by the other colours (which would make it a muddy yellow - 67% red, 67% green, 0% blue) works as an advantage here - without that there would be only 73 unique combinations.

I wonder what 16-colour palette would give the most different colours with flickering (both in terms of number of different colours and in terms of variety).
Click to expand...

I counted them by making a test picture that did all of the combinations, blended it in photoshop and reduced down to the exact palette and it came to 85, nice to know that there is agreement that this is the combination.
 
pearce_jj said:
Where's Trixter.... 320x200 85-colour 30fps video anyone :)
Click to expand...

That is the plan. Keep in mind, every screen is 320x200x4 bits, 256,0000 bits or 32,000 bytes. In order to play video we need 60 fps (30 fps actual, but 2 frames for each blended frame) which is 1,920,000 bytes per second - 1,875 kilobytes per second. Ok - wow - so even XT-IDE can only get up to 500k/sec - so this would be a non-starter. I thought about 160x200 but that is 937.5 kpbs - still too much.

I have been thinking about this for a long time, and my belief is that I can use intra-frame compression (think MPEG) to make it work. I also have the audio as well. If we figure 44,100 KHz mono at 8 bit, then I need another 43k per second for audio as well. So, If I am going to use an XT-IDE at let's say 300k per second and I need 43k for the audio that leaves me with about 250k per second for video. I have 4 video pages to work with. At 250k per second I can update a little less than 1/8th of the screen per frame. In order to make the timing work I will have to get creative about what portion of the screen and how to update. My alternative is to somehow compress the frames and decompress them in realtime (when I get my Make-it-486 then I could probably cheat, but that doesn't feel right to me) and then update the screen. The problem is that my screens are going to be very diverse and RLE encoding would be useless. My last option (which I am not too fond of) would be to reduce the resolution until it can work and then add space in between or scale. That resolution would be 112x70 and I would display it at 224x140 either scaled or with space in between.

There is a lot to think about. First step is 320x200x16 at 8 fps to 10 fps - then we'll get to the flicker mode....
 
For audio you only really need 16kHz 8-bit mono, and for video there's two choices - frame rate or resolution. Personally I think 15 (30 actual) fps could look pretty good but even though the TL is 286 it's fully XT architecture - 8-bit ISA slots and no ZWS line either, in other words all expansion boards probably run with ~750ns cycle time. Not sure how the built-in video is wired up; running some simple timing tests on it should provide an answer though (REP MOVSW to video RAM).
 
Since this stuff is a bit Tandy specific, what about a small memory expansion card that filled in upper conventional RAM - the same RAM the video controller is scanning from. Then add an IDE interface to that with on-board DMA. It would be cheating, but the first design iterrations I did for JR-IDE (on paper) did just that. The DMA transfer loop, lane steering, and latch logic fit in an ATF1508. The 1MB RAM was organized in 16 bits with two parts on the back of the pld along with the IDE header. Block transfers to an on-chip address target could run as fast as any modern IDE device supports with an independent clock. Again.. cheating but a thought. It would still use the on-board video for output.
 
Even with the 8237A DMA directly to video RAM is perfectly possible! But the 8-bit 5MHz slots I think will be a bit problem collecting the data.
 
I did up the mix and I come to 81 colors.
colors.png

Letter codes indicate duplicates -- no reason to render bottom half since that's by definition redundant.
 
chjmartin2 said:
There is a lot to think about. First step is 320x200x16 at 8 fps to 10 fps - then we'll get to the flicker mode....
Click to expand...
Since you'd have the RAM for multiple pages on the TL/SL -- how about the non-standard 160x100 video mode? (a mode I'm pretty familiar with)
 
160x100 Mode

160x100 Mode

deathshadow said:
Since you'd have the RAM for multiple pages on the TL/SL -- how about the non-standard 160x100 video mode? (a mode I'm pretty familiar with)
Click to expand...

I have thought about that too. My Make it 486 just came in, so now I have a huge conflict. Playing with the Make it 486 offers several significant opportunities for hours of entertainment. My plan was to code a slideshow to distribute (I will still do) but now the Make It 486 is calling!

To the other post about the 81 colors, I think you left out the black-blue, black-green, black-red, etc...
 
You must log in or register to reply here.
Back
Top