Games for the IBM 5155 portable (or XT desktop)

[Trixter]

Maybe a member with technical expertise can explain why. Most of the games I've been trying out -- if they run on the 5155 at all -- do not have this problem. I like PAKU-PAKU, and it looks great on a VGA monitor, but the snowstorm is too distracting for me to play the game on the 5155.

I can pretty much guarantee that Jason (author of PAKU-PAKU) is either 1. preparing a long rant about what CGA snow is, why it sucks, and why he won't be addressing it, or 2. working on a command-line switch that will avoid snow at the expense of screen update speed. Knowing him, I'd bet real money on response #1

He has graciously made the source available, so I'll try some snow-avoidance techniques on my 5160+CGA tonight. I'm sure there is a tradeoff that can minimize (but not eliminate) the snow without slowing things down too much.

 

[Trixter]

Here's an interesting way to generate a list on mobygames as well. Apparently you can select (1) technology filter. Here are a list of dos games that support CGA which are probably compatible.

You're welcome. An alternate search, and one that is probably more relevant for his platform, would be filtering by 8086/8088: http://www.mobygames.com/browse/games/dos/tic,11/ti,64/ . There are definitely games that support CGA that would have no chance of running on his 5155 (Stunts is a notable example, which requires 16Mhz or more to be playable and fun.)

 

[vwestlife]

Wait... so "snow" can happen in 160x100 CGA "graphics" mode, too? I guess that makes sense, since it's a modified text mode, but somehow I don't ever remember seeing it...

 

[Trixter]

Yeah, I came across bricks.exe previously and ruled it out. It's just not watchable on an 8088. All the bricks are flashing constantly and annoyingly. Whatever the author was trying to do, it doesn't work in CGA.

I think you tried a different program -- the BRICKS.EXE in that archive uses the 160x100x16 fakemode that only works on CGA. I think you're thinking of a different "brick" program. (You are correct in that it is another breakout-clone, not a pong clone.) If you run that BRICKS.EXE and it really does display flashing characters, then either you have non-CGA in your machine (ie. EGA or VGA), or there is a really subtle bug in the code that I've never seen before.

PONG is such a simple game to write on any microcomputer that it might be worth making your own as a simple programming exercise. BASIC is certainly fast enough.

 

[Trixter]

Wait... so "snow" can happen in 160x100 CGA "graphics" mode, too? I guess that makes sense, since it's a modified text mode, but somehow I don't ever remember seeing it...

You were probably looking at programs/games that either took pains to avoid snow, or you were playing those games on a Tandy 1000 or compatible that didn't suffer from the CGA snow problem.

 

[reenigne]

Maybe a member with technical expertise can explain why. Most of the games I've been trying out -- if they run on the 5155 at all -- do not have this problem. I like PAKU-PAKU, and it looks great on a VGA monitor, but the snowstorm is too distracting for me to play the game on the 5155.

IBM CGA adapters suffer from snow when both of the following are true:

• The mode is (based on) 80-column text mode (this includes the psuedo 160x100x16 graphics mode, because it's just 80 column text mode with the row height reduced to 2 scanlines and the characters set to one of the "vertical half" characters).
• The code reads from or writes to CGA memory while the raster beam is drawing the actual data part of the screen (i.e. not the overscan or retrace parts).

80-column text mode is different from other modes in that it accesses video RAM at twice the rate (i.e. 160 bytes per scanline, or a byte rate of 3.57MHz). In 40-column text mode and both 640-pixel and 320-pixel graphics modes, the byte rate is 1.79MHz and there's enough video memory bandwidth to interleave the CRTC video memory accesses with the CPU video memory accesses. In 80-column text mode there isn't enough video memory bandwidth for this, so (to avoid data corruption) the CGA card lets the CPU win, and that's what causes the snow.

The designers of the CGA could also have solved the problem by making the CPU wait until the end of the scanline, but that would have been roughly an order of magnitude slower, and the same thing is achieveable through software anyway (by checking the CGA status register to see when the raster beam is outside the active area). This would slow down something like Paku Paku tremendously though. Maybe it could be done if the video accesses for each frame were optimized enough to fit into 25% of the CPU time and performed from a timer interrupt synchronized with the vertical overscan period. But I think Paku Paku is pretty heavily optimized already!

 

[Trixter]

This would slow down something like Paku Paku tremendously though.

Eliminating snow would slow down Paku Paku tremendously. Reducing it, possibly substantially, would not.

 

[Maverick1978]

I have "WHERE IN THE WORLD IS CARMEN SANDIEGO" in its original box, looking like it was just handed to me by a clerk at CompUSA. It was a gift from Christmas Past that I never installed but recently came across in a box of PC software. The WITWICSD box includes both 720K and 1.2MB disks, and the specs are 640K, hard disk... uh oh, VGA. The 5155 portable is CGA.

Hmm.... As I think on it more, it was both Where in Europe... and Where in Time... that we played on the PS/2 Model 25 back in the day. Gray-scale CGA and 8086 speed. Yeah!

 

[reenigne]

Eliminating snow would slow down Paku Paku tremendously. Reducing it, possibly substantially, would not.

What did you have in mind? I guess if all the screen updates for the frame were done together and initiated from an interrupt synched with the vertical overscan (as I mentioned in my previous message) then that would confine whatever snow that didn't fit in the overscan into the top part of the screen. I'm not sure what proportion of the time is currently spent drawing though.

 

[Trixter]

What did you have in mind? I guess if all the screen updates for the frame were done together and initiated from an interrupt synched with the vertical overscan (as I mentioned in my previous message) then that would confine whatever snow that didn't fit in the overscan into the top part of the screen. I'm not sure what proportion of the time is currently spent drawing though.

After giving it a shot for about an hour tonight, I'm throwing in the towel. The program doesn't spend a lot of time drawing, but the structure of the game loop is that screen updates are interleaved (meaning, instead of queuing up all game logic and screen changes at 15Hz, he runs the timer at 60Hz and then does 1/4th of the game logic and screen changes each tick). With this structure, I was putting snow checks in front of every update slice, and checking for snow at 3/4ths of 60Hz (one of the slices doesn't update the screen) is not practical. Plus there is music code going on in the background and excessive snow checking was affecting that.

If you want to read his rationale for structuring the game this way, it's in the source around line 1935 in PAKU.PAS.

 

[Gib]

Anybody play chess on an 8088 motherboard in mono CGA? I've got Sargon III, Chessmaster 2000, and Mychess all running, and I'm trying to pick a favorite.

 

[Trixter]

Mychess *is* Chessmaster 2000 -- same author ([FONT=Verdana, Arial, Helvetica, sans-serif]David Kittinger[/FONT]), same algorithms. Sargon III is probably the better chess player due to the refinement the authors went through at that time.

I suck at chess, so I can't say I've gathered any useful opinions from playing them. I like CM2000 for a quick game, and I like to turn on the "what am I thinking" window so I can watch the algorithm work.

For a while I've had this fantasy of setting up two identical 8088s and having them play chess against each other, trying to find the best out of CM2000, CM2100, CM3000, Battlechess, Sargon II/III/IV/V, etc. Most of them work roughly the same way, so whichever one is written better (ie. faster, in assembly, etc.) is going to win. I'd have to inventory each program's features to find a meaningful comparison, like both players are set to "40 moves in 30 minutes".

 

[Gib]

Same author and based on the same engine, but oddly, Mychess reportedly plays a stronger game than its successor, Chessmaster 2000. I haven't played a complete game in either of them yet, so I'm not sure why people say that. Perhaps it's the extra bells and whistles Kittinger built into CM. I'm more familiar with Sargon III, having played it so much on the Apple IIe. It's a tough opponent. Sargon II was easier.

It's easier nowadays to have chess engines play against each other, because GUIs (e.g., Winboard, Arena) have built-in "two machine" or "tournament" modes. It's fun to watch Houdini take on Rybka.

Mychess *is* Chessmaster 2000 -- same author ([FONT=Verdana, Arial, Helvetica, sans-serif]David Kittinger[/FONT]), same algorithms. Sargon III is probably the better chess player due to the refinement the authors went through at that time.

I suck at chess, so I can't say I've gathered any useful opinions from playing them. I like CM2000 for a quick game, and I like to turn on the "what am I thinking" window so I can watch the algorithm work.

For a while I've had this fantasy of setting up two identical 8088s and having them play chess against each other, trying to find the best out of CM2000, CM2100, CM3000, Battlechess, Sargon II/III/IV/V, etc. Most of them work roughly the same way, so whichever one is written better (ie. faster, in assembly, etc.) is going to win. I'd have to inventory each program's features to find a meaningful comparison, like both players are set to "40 moves in 30 minutes".

 

[vwestlife]

You were probably looking at programs/games that either took pains to avoid snow, or you were playing those games on a Tandy 1000 or compatible that didn't suffer from the CGA snow problem.

I just played two of the most common 160x100 games on my IBM 5150 PC with the original IBM CGA board -- Bricks by Vince Bly and Moon Bugs by Windmill Software -- and neither has any snow.

 

[Trixter]

I stand corrected, my memory is faulty. I just ran those two and also round42 (my personal pick for most-played 160x100 game) on my 5160 and you are correct, there is no snow. I disassembled all three of them to take a peek, and all three perform waiting for vertical retrace, horizontal retrace, or both. (Moon Bugs is a little weird in that it checks for horizontal retrace twice, then loads a pixel to display, then checks for it twice again, then finally stores the pixel -- guess he was either using it for timing, or just being extra careful?) In any case, thanks for keeping me honest!

It's important to note that all three games perform very little drawing -- the actual number of pixels changing per frame in all three games is 60 or so. Checking for horizontal retrace every pixel is easy to do when you have 60 pixels to draw and 200 attempts per frame can be made. Although, this gives me an idea and I will try a different tactic with Paku tomorrow on the 5160 (and when I say I'll try something, I mean I'm writing code and testing on the actual 5160+CGA, so I'll know immediately if what I'm doing is right).

 

[deathshadow]

Unfortunately, there's a lot of "snow" on the screen when PAKU-PAKU runs. The 5155 CGA card-composite mono monitor combo throws a lot of artifacts on the screen in response to the coding of some programs. Maybe a member with technical expertise can explain why. Most of the games I've been trying out -- if they run on the 5155 at all -- do not have this problem. I like PAKU-PAKU, and it looks great on a VGA monitor, but the snowstorm is too distracting for me to play the game on the 5155.

To be expected, it's text-mode so snow on a real CGA is a given... just like when 80x25 text scrolls normally.

I can pretty much guarantee that Jason (author of PAKU-PAKU) is either 1. preparing a long rant about what CGA snow is, why it sucks, and why he won't be addressing it, or 2. working on a command-line switch that will avoid snow at the expense of screen update speed. Knowing him, I'd bet real money on response #1

You are correct...

He has graciously made the source available, so I'll try some snow-avoidance techniques on my 5160+CGA tonight. I'm sure there is a tradeoff that can minimize (but not eliminate) the snow without slowing things down too much.

The video bandwidth difference of snow vs. no snow is massive -- we're talking basically the max throughput of the 8 bit bus (over 128k/sec ideal, more like 20k/sec real world after code overhead) vs. being able to send maybe 16 characters per frame during the vertical blanking period and MAYBE a byte or two if you can trap it right during the horizontal blanking period.

Each 'character' sprite is 24 bytes, the copy from backbuffer basically means 48 bytes transferred to video memory per sprite per frame (old position + new position), which works out to 1.6k or more per frame having to be transferred not counting the blinking pellets or the score updates... only around 100 times the memory bandwidth available when you use the anti-snow techniques.

Pain in the ass IBM cheaped out and screwed up the circuitry for 80x25 text mode... and why whenever possible I'd rip out the original CGA and put in a snow-free clone card, even if it wasn't "stock".

Praise be the Tandy 1000 and PC Jr. lacked that particular flaw.

 

[reenigne]

being able to send maybe 16 characters per frame during the vertical blanking period

That seems a little on the low side to me.

Suppose you're writing to CGA using a loop like this:

top:
lodsw
mov di,ax
movsb
loop top

Including CGA wait states and DRAM refresh, that should take about 72 CPU cycles maximum. So just inside the 16 scanline vertical sync period you should be able to transfer 67 bytes per frame. If you continue transferring right up until the active area restarts that's 160 bytes per frame. And if you use the timer technique I described earlier in the thread to start transferring right at the beginning of the vertical overscan region you can get about 262 bytes per frame.

You won't be writing using a loop like that, though, you'll mostly be transferring horizontal runs of 3 attribute bytes which can be done much more quickly with "movsb; inc di; movsb; inc di; movsb" which will be at least twice as fast. The theoretical limit with "rep movsw" to CGA is 4266 bytes per frame total or about 1K per per frame in the vertical overscan period.

If you're transferring 20K per second to video RAM using your current techniques, that's 341 bytes per frame which takes eliminating snow out of the realm of "impossible" and places it squarely in the realm of merely "hard".

Of course, it does require caring enough to implement it, which may be the limiting factor here...

 

[deathshadow]

So just inside the 16 scanline vertical sync period you should be able to transfer 67 bytes per frame

Excepting you can't detect the start of blanking, so your stuck waiting for retrace, costing you half that... Yes, you could add even more timing to it, but it's already at the limit of a 4.77mhz machine code-wise... adding more timing code just destroys gameplay since there's just not enough CPU for it.

If you're transferring 20K per second to video RAM using your current techniques, that's 341 bytes per frame which takes eliminating snow out of the realm of "impossible" and places it squarely in the realm of merely "hard".

... and notice I said 1.6k per frame NOT counting the blinking pellets. realistically it's more like 2k per frame, at the slowest level that's done 1 in 6 of my audio timer ticks, which goes 120 times a second... so 20fps on the slowest level. Say hello to Mr. 40k/second. At bare minimum double the time available when snow removal is applied.

I spent a good deal of time agonizing over adding snow removal or not -- in testing the only place it was practical was on a 10mhz or faster 8088... and even then you ended up with unplayable crappy frame rates and horrible flicker... much like what makes round 42 feel, well... I'd rather have the snow than be able to see the blasted thing redrawing the screen.

Though it MAY be possible with some other tricks -- there is the 'delay blitting until the scan starts' method, which if you can render slower than the vertical scan can let you blit 'behind' the draw, giving you the entire frame. Normally that's not viable since people draw directly to screen, but since my routine is using a back-buffer and then writing changes after the scan.... No, that's out of order rendering, would have to 'top down' sort them and add top-down delays, either of which would shtup the audio timing.

 

[reenigne]

Excepting you can't detect the start of blanking, so your stuck waiting for retrace, costing you half that... Yes, you could add even more timing to it, but it's already at the limit of a 4.77mhz machine code-wise... adding more timing code just destroys gameplay since there's just not enough CPU for it.

Here's an algorithm that allows you to run some code inside the entire vertical overscan period without needing to check the CGA status register at all after the initial setup at the beginning of the program.

• Set the PIT count to 19912 cycles (912*262/12, or exactly one CGA screen.
• In setup, wait for vertical retrace. Then wait for the start and end of the active scanline, 200 times. Now you're right at the start of the overscan period. Start the timer going, and you'll get an interrupt at exactly this point in every frame.
• Do all your drawing for the frame in that interrupt.

If you want the timer to be running at 120Hz or 240Hz for audio purposes you can set the timer count to 9956 or 4978 and only draw every 2nd or 4th interrupt (maybe draw on interrupt 1/4 and update audio on interrupts 2/4 and 4/4 to keep it regular).

... and notice I said 1.6k per frame NOT counting the blinking pellets. realistically it's more like 2k per frame,

I don't understand where that 1.6K per frame figure came from. You said 48 bytes per sprite per frame and there are 5 sprites so that's 240 bytes. The blinking pellets look like they are 3x3 pixels or 6 bytes each, times 4 for another 24, and 8*4*5/2 = 80 bytes for the score. What am I missing?

at the slowest level that's done 1 in 6 of my audio timer ticks, which goes 120 times a second... so 20fps on the slowest level. Say hello to Mr. 40k/second.

Ah okay, you've been using frame in the "game" sense (20Hz to 30Hz depending on level) and I've been using it in the "CGA" sense. In that case, either multiply all my byte-per-frame counts by 3 (or 2) or divide all yours by 3 (or 2).

I spent a good deal of time agonizing over adding snow removal or not -- in testing the only place it was practical was on a 10mhz or faster 8088...

Ah, in that case I apologize for implying that you didn't care! I do wonder if maybe you didn't think of the technique of keeping the PIT and the CRTC in sync, though. I believe it should be portable enough - the only cards affected by snow will be those that use the ISA bus's OSC signal for their timing which is the same one that the PIT clock is ultimately derived from.

Though it MAY be possible with some other tricks -- there is the 'delay blitting until the scan starts' method, which if you can render slower than the vertical scan can let you blit 'behind' the draw, giving you the entire frame.

That sounds like the technique for eliminating tearing without using page-flipping, which is nice but not really relevant for snow removal since you'll get snow whereever you write in CGA RAM if the raster beam is in the active area when you do it - chasing the beam doesn't actually buy you anything.

 

[Trixter]

That seems a little on the low side to me.

Indeed. My own measurements when writing a text writer showed that I was able to write 200 words without snow by waiting only for horizontal retrace. I also have a "copy text screen from buffer to screen" that checks for both horizontal and vertical retrace and that one is able to do 200 words during the display cycle and 470 words during vertical retrace. (Code is TFASTWRI.PAS in ftp://ftp.oldskool.org/pub/misc/xtfiles.rar if anyone wants to pilfer it, just throw me a bone if you do)