Image Map Image Map
Page 3 of 6 FirstFirst 123456 LastLast
Results 21 to 30 of 57

Thread: Games for the IBM 5155 portable (or XT desktop)

  1. #21
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,144
    Blog Entries
    1

    Default

    Quote Originally Posted by Gib View Post
    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.

  2. #22
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,144
    Blog Entries
    1

    Default

    Quote Originally Posted by barythrin View Post
    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.)

  3. #23

    Default

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

  4. #24
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,144
    Blog Entries
    1

    Default

    Quote Originally Posted by Gib View Post
    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.

  5. #25
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,144
    Blog Entries
    1

    Default

    Quote Originally Posted by vwestlife View Post
    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.

  6. #26

    Default

    Quote Originally Posted by Gib View Post
    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!

  7. #27
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,144
    Blog Entries
    1

    Default

    Quote Originally Posted by reenigne View Post
    This would slow down something like Paku Paku tremendously though.
    Eliminating snow would slow down Paku Paku tremendously. Reducing it, possibly substantially, would not.

  8. #28
    Join Date
    Mar 2010
    Location
    Florida, USA
    Posts
    1,945

    Default

    Quote Originally Posted by Gib View Post
    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!
    ---
    Currently seeking:
    * Roland MPU-401/AT (with daughter card header)
    * Magitronic K-156 Keyboard (5pin DIN w/ XT-AT switch)
    I also collect PC and C64 Sierra On-Line software!

  9. #29

    Default

    Quote Originally Posted by Trixter View Post
    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.

  10. #30
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    5,144
    Blog Entries
    1

    Default

    Quote Originally Posted by reenigne View Post
    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.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •