Tandy 1000 TL - 85 Color Demo

[Trixter]

Good point. I thought the argument was that ordered dither produces the best visual at 320x200. So yes, if I wanted to intra-frame compression then ordered would be a better method. Your suggestion makes me think of trying to figure out to make a series of tiles and XOR.... hmmmm....

If your pixels are close enough together and fuzzy, then I actually would argue ordered produces the best result. However, you're right, I was never saying it looked best, but rather pointing out its properties are particularly suited to animation.

Atari 2600 guy got mad at me for working on something similar to what he had done

I have no idea who you're talking about, but screw that guy. This is a hobby. If he wanted to claim some sort of world first then he should have done it already. I already dropped one of my biggest secrets (ordered dither) because I want to see something get done. Here's another secret: Deltas by tile will help your interframe compression but hurt your speed. A Tandy 1000 TL is a 286 so you can probably absorb it, but for my 8088+CGA system I'll be sticking to scanlines.

Here's another tip, drop XOR as a way to get the data onscreen. Reading from display memory is too slow. Change as little bytes as possible. We used XOR in Grind and wondered why autodesk animator .FLI files always seemed to perform better.

I had a melt-down today though and lost my whole system - luckily my programs are all saved, but my development rig has to be reimaged

This is why I have two drives on any vintage system I'm currently using actively -- one to use, and one as the backup ("XXCOPY src dst /clone /yy /zy" works well as a local filesystem rsync clone). And a packet driver and mTCP so I can make differential backups using pkzip to send off-site as a backup ("pkzip -i -r -p -es -o -xf:\backups\c\backup\5160dev.zip c:\backup\5160dev f:\backups\*.*" if you're curious).

 

[pearce_jj]

My machine takes almost 7 minutes to boot

Jim you need to get off Windows and drop in a decent SSD; you can expect to divide that boot time by 60!

 

[barythrin]

or drop it by 60 and just run dos ;-)

 

[Trixter]

Jim you need to get off Windows and drop in a decent SSD; you can expect to divide that boot time by 60!

I used to, and it used to go from start-of-boot to usuable machine in about 60 seconds. Financial pressures have prevented me from coming back to an SSD, which is why I boot from spinning rust right now.

 

[nimal]

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.)

 

[Anonymous Coward]

It would be pretty cool to modify this to work on EGA graphics too (for those of us without Tandy 1000s)

 

[deathshadow]

It would be pretty cool to modify this to work on EGA graphics too (for those of us without Tandy 1000s)

I was thinking this too -- actually started playing with coding it...

... and this isn't just restricted to 1000's -- it's restricted to just the TL/SL as older models don't have the RAM for two pages at 320x200... though you could in theory do 160x200 I think.

Working on making a javascript powered page to show the available colors, which I'm gonna screencap and use to make the palette for Paint Shop Pro which will handle my color depth reductions. I plan to use SDL_IMAGE in free pascal to then change PNG files made by PSP into bitmap files for use by my demo.

 

[Trixter]

it's restricted to just the TL/SL as older models don't have the RAM for two pages at 320x200...

All Tandy 1000 models have RAM for up to four 320x200x16 pages. Tandys are based off the PCjr, which divided the first 128K into eight 16K banks (called "pages" in the PCjr tech ref) and could use any one or two (consecutive) pages for screen display. The difference with the Tandy is that it implements those screen banks from the top of RAM down, vs. the PCjr which implemented them bottom-up. Tandy did this because the PCjr's design was stupid -- the interrupt table, DOS, and program code would always be loaded into the first and usually second 16K pages, leaving you with only 6. On all Tandy models, you get the full eight. This means the following should be possible on Tandy systems:

Non-SL/TL: 8 screens of 320x200x4, 640x200x2, or 160x200x16; 4 screens of 320x200x16 or 640x200x4
SL/TL: All of the above plus 2 screens of 640x200x16

I have pascal/asm code for choosing and displaying pages if you'd like to snag it: ftp://ftp.oldskool.org/pub/misc/tanfiles.rar ; look in tanfiles.rar\tanfiles\developr\PROGRAM\CGA\LIB for a library that has rudimentary support for 160x200x16 with multiple pages (search the *.pas files for "VidTAN" and you should find relevant info). My code does not properly handle the 640x200x16 modes of the TL/SL because they were implemented slightly differently. Tvdog's archive should be consulted for code that manipulates those. Also look in the \tanfiles\developr\program\tantro for a little program that displays a full-screen 160x200x16 rotozoomer that uses pageflipping.

 

[chjmartin2]

Viewer Package, Converter and More Still Caps of Actual Output

Viewer Package, Converter and More Still Caps of Actual Output

To All:

I am pleased to release my Tandy 1000 85 Color Image Converter and viewer. The converter is written in Freebasic. The viewer is written in Tandy 1000 GW-Basic. It is tested and works in Dos Box in Tandy Mode. (Hit CTRL F12 until the flicker stabilizes, mine happens around 5,000. It works on a real Tandy with no speed adjustments.)

TVIEW_85.ZIP

TVIEW_Conv.zip

Just unzip the TVIEW_85.ZIP into a dos directly, run TVIEW.BAT, enter the file name (without the extension) and press enter. Hit any key and q to quit back to the system.

Unzip TVIEW_Conv into a directory, run the TV85CONV.EXE and pick a BMP file to convert. It will output two files, name.TG1 and name.TG2. Move those into the viewer directory and you are good to go.

The input BMP file has to be 320x200x16 bit. The reason the resulting picture does not have a horrible flickering is because the bright and dark colors are interleaved and therefore the total visual energy at any given time is fixed between frames. (A real scientist could explain better I am sure...)

I'd love to see your screen caps!

Here are a few shots of it on real hardware:



Thanks,

Chris

 

[pearce_jj]

This is really clever IMO.

 

[Trixter]

The input BMP file has to be 320x200x16 bit.

No, you mean 24-bit

Very promising! My only question is why you are interlacing dark/light by scanline. Wouldn't interlacing by pixel be less distracting? ie:

x o x o x o x o
o x o x o x o x
x o x o x o x o
o x o x o x o x

etc.

 

[chjmartin2]

No, you mean 24-bit

Very promising! My only question is why you are interlacing dark/light by scanline. Wouldn't interlacing by pixel be less distracting? ie:

x o x o x o x o
o x o x o x o x
x o x o x o x o
o x o x o x o x

etc.

So... I thought the same thing and changed the interleave to the checkerboard - the flicker is worse. I can't figure out why, and it doesn't make a lot of sense, but the dark/light bands by line seems to work much better. Only way to see it is to try both on real hardware. The checkerboard looks better in dosbox, worse on real monitor...

 

[evildragon]

Maybe with a checkerboard it's not going as fast so it looks more pronounced? I would think checker boarding would require more CPU cycles than per line.

 

[chjmartin2]

Maybe with a checkerboard it's not going as fast so it looks more pronounced? I would think checker boarding would require more CPU cycles than per line.

If this program but were that complicated. All I am doing is bloading in a converted image onto one video ram page, and then another on the next video ram page and then switching between them timed at the vertical sync. Guys have been doing it on the C64 for years...

 

[Trixter]

If you're not already doing this, you might want to try tweaking your color matching by coming up with some sort of psychovisual model so that the flicker is less pronounced. For example, #FFFFFF and #000000 mixed together is "gray" but flickers badly, whereas another combo might have a similar luminance but flicker less (but, as a drawback, be tinted towards a color).

When I did my fakemode experiments a while ago, I started with a program that displayed boxes of solid-color and interlaced-pixel flicker between two colors, then waited for a Y or N keypress from me, with "Y" deemed an acceptable level of flicker. I then had the program print out the winning combinations. I don't remember the exact number, but it was roughly 36 combos that didn't flicker distractingly. Maybe perform the same experiments on yourself (on the Tandy, not dosbox) and see if a reduced set of combos results in a more pleasing picture?

 

[VileR]

Very nice!

I, for one, kinda like the scanline flicker effect! Though on the DOSBox side of things (don't own a Tandy), I'm a little surprised that it needs a cycles adjustment to work correctly, since you're using vertical sync for timing. Then again that's also the case with Jungle Hunt's mid-frame CGA palette swap, so I wonder if it's the same DOSBox quirk at work here.

 

[chjmartin2]

If you're not already doing this, you might want to try tweaking your color matching by coming up with some sort of psychovisual model so that the flicker is less pronounced. For example, #FFFFFF and #000000 mixed together is "gray" but flickers badly, whereas another combo might have a similar luminance but flicker less (but, as a drawback, be tinted towards a color).

When I did my fakemode experiments a while ago, I started with a program that displayed boxes of solid-color and interlaced-pixel flicker between two colors, then waited for a Y or N keypress from me, with "Y" deemed an acceptable level of flicker. I then had the program print out the winning combinations. I don't remember the exact number, but it was roughly 36 combos that didn't flicker distractingly. Maybe perform the same experiments on yourself (on the Tandy, not dosbox) and see if a reduced set of combos results in a more pleasing picture?

The amount of flicker is directly proportional to the amount of luminance difference between the flickered colors. Atari 2600 had a nice program called "flciker picker" that would let you pick out colors based on the same premise. All in, on the real hardware, the flicker is actually not bad at all, even for colors with large variation. I could just set a threshold of a luminance difference and elminate those colors. My next attempt is going to be to create two 80x25x16 color text mode images to flicker back and forth to create pictures. Will be an interesting challenge because of the limited character set, but will be a psuedo 640x200x85 color mode on CGA. Only being able to use the 8 darker background colors should prove somewhat interesting as well.

CGA only has one page of 320x200 and one page of 640x200 otherwise I would try flicker screens there as well.

I had a random thought of trying to optimize two screens, one 80x25x16 text and one 320x200x4 graphics and try to figure out the best set of common data closest to the target image, but that seemed like an awful longshot. I do know that I have enough memory to do two pages of 80x50 with half height characters and so, that may make for a very good CGA 640x200x85 mode display - at least for static pictures.

 

[chjmartin2]

Very nice!

I, for one, kinda like the scanline flicker effect! Though on the DOSBox side of things (don't own a Tandy), I'm a little surprised that it needs a cycles adjustment to work correctly, since you're using vertical sync for timing. Then again that's also the case with Jungle Hunt's mid-frame CGA palette swap, so I wonder if it's the same DOSBox quirk at work here.

I was surprised by it as well. I am using the vertical sync, and it doesn't need any help on the real hardware. I find I have to play with the cycles on Dosbox frequently though. Does it do the same thing in California Games?

 

[vwestlife]

Only being able to use the 8 darker background colors should prove somewhat interesting as well.

If you turn off the blink attribute, you can get all 16 background colors in CGA text mode.

 

[Trixter]

My next attempt is going to be to create two 80x25x16 color text mode images to flicker back and forth to create pictures. Will be an interesting challenge because of the limited character set, but will be a psuedo 640x200x85 color mode on CGA. Only being able to use the 8 darker background colors should prove somewhat interesting as well.

I very much look forward to this. Also, as vwestlife has pointed out, you can get all 16 background colors in 80x25 via the following code:

    {relevant bits}
    c_fast_char_clock=1; {use 160 bytes per line instead of 80; REQUIRED for 80x25 mode, otherwise 40x25 mode}
    c_graphics_enable=2; {otherwise, text mode}
    c_blackandwhite_enable=4; {otherwise, color signal}
    c_videosignal_enable=8; {otherwise, NO VIDEO SIGNAL}
    c_640x200_enable=16; {otherwise, 320x200}
    c_blinking_text=32; {otherwise, all background colors enabled}

    if realCGA
      then asm
        mov  ax,0003h {set 80x25}
        int  10h
        mov  dx,3d8h
        mov  al,c_fast_char_clock + c_videosignal_enable {blinking not included, so blinking is off}
        out  dx,al
      end else asm {if VGA, do something completely different}
        mov ax,0003h {set up normal 80x25 text mode}
        int 10h
        mov ax,1003h {disable blink on ega/vga}
        mov bl,0
        int 10h
      end;

CGA only has one page of 320x200 and one page of 640x200 otherwise I would try flicker screens there as well.

To quote Independence Day, "That's not entirely... accurate." If you play with the number of scanlines or columns, you can finagle smaller screen areas but two hardware pages. The easy-but-odd ones (assuming "320x200" 4-color graphics mode) are 160x200 (presents as a vertical column) or 320x100 (presents as "letterboxing"). More useful combos are 256x128 (for easy address calcs), and 224x140 (has same aspect ratio as 320x200). I have no idea if this kind of reprogramming works in DOSBox or MESS. The textmode resize test in the CGA Compatibility Tester could verify if they do.

I had a random thought of trying to optimize two screens, one 80x25x16 text and one 320x200x4 graphics and try to figure out the best set of common data closest to the target image

And flip between them? I don't think you can do that without the screen rolling (on a real monitor)...

I do know that I have enough memory to do two pages of 80x50 with half height characters and so, that may make for a very good CGA 640x200x85 mode display - at least for static pictures.

I look forward to that as well!