Lode Runner cartridge & BIOS calls

Expert (76)

05-01-2010, 11:15

Hi,

Can anyone tell me how likely or not it is that the Lode Runner software on cartridge makes use of MSX BIOS routines?

The reason I ask is that I'm looking into the possibility of porting the MSX version of Lode Runner to another Z80 platform. If the code is (almost) self-contained, it would simply be a matter of patching the input and graphics routines for the target platform. OTOH, if it is likely to make extensive calls into the MSX BIOS, then this will not be an option.

FWIW I've completed a similar project, porting the arcade Space Invaders to the TRS-80 Model 4 using the same technique. I've also been successful in getting Pacman to run on the TRS-80 as well, although the graphics routines weren't completed. Obviously SI is based on much simpler hardware than the MSX...

members.iinet.net.au/~msmcdoug/sitrs/index.html

TIA

Aangemeld of registreer om reacties te plaatsen

Van Metalion

Paragon (1628)

05-01-2010, 12:01

Well any software for the MSX was supposed to always use the MSX BIOS routines.
But a large number of games did use their proper code to speed up things, although it was always within the boundaries of the MSX standard.

It is quite an easy check : scan the source for every branch opcode (JR, JP, CALL) - and their conditional cousins - for a address within the BIOS space ($0000 to $01FF). Should be easy with an hex editor ...

Van nikodr

Paladin (750)

05-01-2010, 16:07

I did this for you rcdev upon loading the rom i did what metalion said.I loaded the game and after the first title screen i checked the addresses called.

The following addresses were called from within the bios

$0038 (that is always called as long as you have an msx,unless you use im2)
$013e
$0047
$0053
$0093
$0096
$0141
$004d

Here are the explanation of the calls and what they do
http://map.grauw.nl/resources/msxbios.php

Van Leo

Paragon (1236)

05-01-2010, 20:26

i would not do this , it prooves that some bios routines are used but not that direct hardware acces is not done ...
i would scan rom for $D399 , $D398 , $DB99 , $DB98 for vdp and the same for psg io ports.
after there is also the possibility of ld c,99h and out (c),a ...

Van sd_snatcher

Prophet (3675)

05-01-2010, 21:02

If the code is (almost) self-contained, it would simply be a matter of patching the input and graphics routines for the target platform. OTOH, if it is likely to make extensive calls into the MSX BIOS, then this will not be an option.
Please allow me to disagree here. Even if it uses the MSX-BIOS if would not be much different to port.
Or maybe it's even easier because the BIOS functions do use standard parameters. All you would need to do is to code your own routines receiving the same parameters and change the address of the CALLs/JPs/etc to the address of your own routines. The vast majority of the routines the games use are pretty low-level: write to a register, read to a register, initialize CI etc so it probably will not be much of a problem for you to code similar ones.

OTOH, you're pretty welcome to port games in the other way around! What about porting Z80 arcade games to the MSX2? That would be very cool too. Even Pacman could be one.

Van tcdev

Expert (76)

06-01-2010, 12:38

Thanks for the info, guys, I'll look further into it.

I was concerned about the BIOS being used extensively, this requiring large amounts of code to be ported the TRS-80. However, I'm hoping that it uses simple routines for setting video mode, reading keyboard input, and not much more!?!

I was looking at porting Space Invaders to the MSX, as I have a complete commented disassembly from my TRS-80 port. But someone pointed out that an arcade-perfect port exists anyway, so it would be pretty much a waste of time. Pacman would be interesting though!

Have you guys seen the port of Donkey Kong for the TRS-80 Coco3? The original code was hand-translated line-by-line into 6809 assembler, and a tile/sprite engine added to emulate the original hardware. Graphics scaling aside, the end result is a perfect "emulation" (not technically an emulation of course, but rather a port) of the arcade version.

Van MäSäXi

Paragon (1884)

06-01-2010, 22:18

I have SEEN it ages ago not played Looks just like arcade!

http://nitros9.lcurtisboyle.com/donkeykong.html

Everyone not familiar with COCO, please check my old favourite link: :D

http://nitros9.lcurtisboyle.com/

for coco game list (with lots of screenshots of course!:), interview of coco game author etc... :)

Van MäSäXi

Paragon (1884)

06-01-2010, 22:22

I have always admired how GREAT those coco games look, when thinking how OLD they are!!!

Van tcdev

Expert (76)

07-01-2010, 12:24

Thanks for doing that! No surprises, just keyboard, VDP, PSG & video RAM - exactly what I was hoping.

I wouldn't be surprised if there are other direct accesses to the hardware in the code itself, but if there aren't any, then porting should be relatively simple. One issue is the memory map - the TRS-80 has a flat 64KB RAM once the ROM is switched out. The hires graphics are port-mapped, so no need to worry about video memory getting in the way.

The down-side of port-mapped graphics, of course, is that they're rather slow. However, Lode Runner is a good candidate because there's not a lot of graphics moving around at any one time. Only a few "sprites" and they're relatively small. I started to write Lode Runner myself about 20 years ago on the TRS-80, and whilst it was never finished, it was impressive for the time. Although for purist reasons I prefer the Apple II version of Lode Runner, if I can get the MSX version running on the TRS-80 I'll be very impressed, as will a number of TRS-80 enthusiasts no doubt!

Van MäSäXi

Paragon (1884)

07-01-2010, 14:23

Tcdev, I would like to point out one fact, in case you don´t know about it.

MSX Loderunner is a nice game, BUT enemy A.I. is quite bad, MSX Loderunner II suffers exactly same thing. I remember there was such thing, that if you stand still on a certain ladder, enemies on certain other ladder can´t move at all until you move. If you move up, enemy too move up, if you move down, enemy mirror your action again, and when you stop, they´ll stop too.... irritating.... Do you think real life enemies would do something like that? Ok, it´s just an old computer game, but I remember that on Commodore 64 enemies never stop (except just for a while when they drop to hole made by you, before they can get up) no matter which ladder you use, they´ll keep comin´ on all the time.

MSX Loderunner enemies can´t do that. Maybe this may sound little thing, but in fact it can be VERY frustrating, as it may make some level impossible to finish, because enemies won´t go away from certain ladder if you are in certain position. And some levels may be too easy because of the same reason. There are other Loderunner clones on MSX too, which all suffer same problem.

Maybe you could add some more intelligence to TRS-80 port? It shouldn´t be too hard. That would make TRS-80 port better than MSX version.

Van tcdev

Expert (76)

08-01-2010, 06:26

MSX Loderunner is a nice game, BUT enemy A.I. is quite bad, MSX Loderunner II suffers exactly same thing.
Actually, I was playing it a bit today after getting it running under MESS, and I did notice that problem. The original Apple II version does have the baddies running away at times, but the AI seems to be the same as the C64 version. No surprises since IIRC both were programmed by Doug Smith himself, whilst the MSX port was not. I consider the Apple II version to be the benchmark for all other games, even if the AI isn't "realistic". It's still a fantastic and very playable & challenging (& above-all, fun) game.

My ultimate aim is to disassemble either the Apple II or C64 version to extract the AI for a "perfect" port of the Apple II version on the TRS-80 and other platforms. I'd code it in C so it would be relatively portable, even across older platforms. Many many years ago I had the player running around the screen on the TRS-80, written in spaghetti assembler, and it looked damned impressive!!! After that I ported it to the Amiga in AMOS BASIC then C, and finally to the PC under DOS, but it never got much further than the player running around. A colleague wrote some enemy AI for the PC version which was reasonably accurate, so I did actually have a version with baddies as well, but no collision detection etc. Anyway, I digress...

I've run the MSX cartridge though IDA Pro disassembler and had a preliminary look at the code. I've identified all code areas and have commented every BIOS call. I'm reasonably confident I could get the game running on another similar Z80 platform, but there's a couple of issues that I need to confirm/resolve before I decide it can actually be done on the TRS-80.

The game uses the halt instruction in several places. Not sure what periperhals it's waiting on atm.
I wasn't aware that the VDP had hardware sprites; still, it's not a showstopper at all.
I'm not 100% sure what the target memory requirements are, but I think they're OK for the TRS-80.

I've started commenting the start-up code, and I'm reasonably confident I can at least get the TRS-80 to execute enough code to display the credits screen. So I might start working on that next - adding stubs for the BIOS calls and hopefully able to run a routine that scrapes video memory to the TRS-80 hires screen, if there's enough free memory on the TRS-80 to allow me to do that. Otherwise I'll have to start out writing directly to hires screen memory....

If I can get the title screen showing on a TRS-80 emulator, I'll post a screen-shot!