• Please review our updated Terms and Rules here

Problem running Round42

J

jltursan

Veteran Member
Joined
Sep 24, 2010
Messages
841
Location
Madrid, Spain
I'm trying to run Round42 shooter in an Amstrad PC-1640/PC-6400 without success, the display turns an absolute mess. The PC-1640 has a Paradise PEGA chipset with some powerful features; but seems unable to render the 160x100 used by Round42.
Wasn't it simply a hacked text mode with chars height trimmed down?, seems simple to emulate :p

Has anyone experience about the compatibility of this special mode?
 
I remember playing Round42 on the PC1512, and it's 160x100 mode worked fine there. However, it's quite possible that Round42 doesn't work properly with EGA machines like the PC1640. There's some technical information about the PC1640 (and it's graphics adapter) at http://www.seasip.info/AmstradXT/1640tech/section1.html . In particular, section 1.22 shows some DIP switch settings that can be used to configure it. I'm guessing that the primary adapter in your system is set to ECD350 mode. Try it in ECD200 mode instead. Then text modes will use 200 scanlines instead of 350, which may give Round42 a better chance of working.
 
If it's EGA or VGA, the majority of 160x100 video mode games will NOT run. In fact, I'm only aware of two that do... Tunneler, and my own Paku Paku...

... and Tunneler on a EGA will display "Squished' as it sets the text slice to 3px out of 350, giving you a bar at the bottom of the screen. With the later versions of Paku Paku I reprogram the CRTC to output 200 lines like a normal CGA mode so it doesn't have that problem. I actually pulled the values from when the switches are set to a CGA monitor, and force feed them into the CRTC regardless of the switch position!

I believe Tunneler and my own are also the only ones to work on a VGA card -- in Tunneler it has the problem that every other row is 1px wider due to the 9 line character width as the default text mode on a VGA is in fact 720x400. (just as EGA text mode normally defaults to 720x350, not 640x350) In the more recent versions of PP I reprogram the text mode to 640x400 with 8 pixel wide fonts so it doesn't have that problem either. Side note, I'm still a huge fan of the 90x30 VGA text mode...

But older "classic era" CGA games that use said mode? EGA and newer they just don't work -- EVEN if you set the card to 200 line mode. The character height change needed to make it work is done differently on EGA than it is CGA.

So no Round 42, Moonbugs, Bandit, Kids on Keys, Bricks, or Exterminator for you.

I've played with the idea of creating a TSR that at regular intervals forces the display into the correct setting, but if the game uses timers properly that could go tits-up face-down... would probably work with Round42 though since it quite clearly doesn't have any timer throttling.

Maybe program the mode override into a keystroke? Poll the port the CGA code tries to set?

I might play with this again when I have a break to see if some sort of compatibility fix could be implemented. If nothing else, could just make a program that looks for the mode set in known games, appends the fix code to the end of the executable, and replaces the offending code with a call and a bunch of nops. (or call and a jump... or two jump...)

Would be nice to take those old games and make them EGA/VGA/Jr compatible. I do love me some moonbugs...

Did I say Junior? Yeah, there's a problem there too. Blink on/off is set different. Found that out the hard way when writing Paku Paku... it's what prompted me to invest in buying a real Junior to test with since I mistakenly thought my Tandy 1000's (Yes, Plural) were "close enough" ... If "blink" stays on, every other pixel column will flash instead of show intensity.
 
Last edited:
So no Round 42, Moonbugs, Bandit, Kids on Keys, Bricks, or Exterminator for you.
Click to expand...
Would be nice to take those old games and make them EGA/VGA/Jr compatible. I do love me some moonbugs...
Click to expand...

Too bad as my other main machine is the Jr :p

I would also love to see moonbugs running and not in DosBox...

Wouldn't be easier to cook a patch for these games modifying the way the CRTC is initialized, closer to what Paku Paku does?
 
Said "patch" would have to be customized for each program... and since we're basically talking two or three k of code, injecting that to something like a flat COM file (where data is assumed to start right after execution and the stack growing down towards it) could be tricky to implement.

An easier approach would probably be to just make a loader. You use int 0x21 AH = 0x4B, AL = 0x01 to load the program into memory, patch where it sets the CGA mode to call our routine instead, and then execute it after determining where to call from the PSP returned by int 0x12 AH=0x51. (since ah=62 is dos 3.3/later, and 2.x support would be nice for things like the Junior).

You could then pass the filename to the loader, using that filename as your trigger for which addresses to patch. Maybe even hijack one of the unused interrupts since an INT is less code than a CALL making it easier to inject into existing code. (again, just NOP any remaining space).

The big trick being to find in each program that we want to patch where "out dx, al" is called where dx is 0x3D4 and AL is 8 values in a row that could be hardcoded each or read from an array -- though since that's a CRTC reprogram you'd also have to question what order they are doing things in as for EGA/VGA if they did a clear screen first before the reprogram, we'd have to do it again -- in which case you might want to do this as early as the mode 3 set and just erase the rest of the existing mode-set code... We'd need your own clear routine, and not every program agrees on which character to use for that clear... some people preferred 0xDD, others 0xDE for the left/right pairing. (either works, it just depends on which nybble on the attribute is more convenient for left/right display).

I'm gonna play around with this a bit later tonight. See if in disassembling Moonbugs if I can find where and how they are setting the mode, and what would be involved in patching it.

That and see if I can remember how to do a INT 0x21, AX = 0x4B01 and start the program WITHOUT resorting to AH = 0x62 -- it's been a couple decades since I wrote anything like that... not since I wrote the crack to bypass the questions in Chu... uhm, nevermind.

Would be nice to drag those games kicking and screaming out of "CGA Only" land.
 
The Paradise chipset in the PC1640 can do actual hardware emulation of CGA. DISPLAY CDCOLOR at the DOS command prompt should do this; or try setting the DIP switches to one of the CGA modes.
 
JohnElliott said:
The Paradise chipset in the PC1640 can do actual hardware emulation of CGA. DISPLAY CDCOLOR at the DOS command prompt should do this; or try setting the DIP switches to one of the CGA modes.
Click to expand...

I haven't tested yet the dip switches; but the DISPLAY command solution didn't work, the game displays the same messed up graphics, no change :(
Seems that deathshadow is right about what's happening here. Not easy to figure out a cure for that.
 
You must log in or register to reply here.
Back
Top