Bugs on a ROM to BIN conversion

Expert (75)

03-05-2020, 22:43

I was trying my hand at converting a ROM file to BIN using the msxr2b tool and was having mixed results with it.
I'm only trying with 16KB and 32KB ROMs of course.

Knightmare and Antarctic Adventure look to be 100% working without issues, but I've got some strange behavior on other games.

Arkanoid looks like it locks up the machine (black screen), but if I reset the MSX it actually starts and looks to be working, although with an annoying visual bug:

The .bas launcher I'm using is the typical

5 POKE -1,(15-PEEK(-1)\16)*17
10 BLOAD"FILE1.BIN",R
20 BLOAD"FILE2.BIN",R

With Zanac, everything looks to be working alright, but the FDD access led stays on all the time.

These behaviors have been confirmed on both real hardware (NMS-8280) and emulator (openMSX).

I've also tried using ONEDRIVE.COM to free more memory at the start, but it didn't change anything.

Is there a way to debug those annoyances in openMSX or any other way?

By Manuel

Ascended (17939)

03-05-2020, 23:31

Are you familiar with the openMSX debugger?

By donluca

Expert (75)

03-05-2020, 23:43

Unfortunately not, but willing to learn!

By Manuel

Ascended (17939)

04-05-2020, 00:19

Well, get it and try it out... you can find links to it on our website in the Download box.

By Grauw

Ascended (9904)

04-05-2020, 01:24

donluca wrote:

With Zanac, everything looks to be working alright, but the FDD access led stays on all the time.

This is probably because the game has a custom interrupt routine and bypasses the BIOS ISR. The DiskROM for disk drives sets up a H.TIMI hook that counts down a timer which stops the drive from spinning once it reaches zero. This time-out is there to avoid the drive from continuously spinning up and down. But if the BIOS ISR is not invoked, that never happens. The game originally did not have a problem with this since it is a ROM which boots up before any disk activity.

An easy workaround for this case is to manually call H.TIMI a bunch of times (e.g. 256) before starting the game. This will fast-forward the couner and stop the drive quickly.

By Manel46

Hero (625)

04-05-2020, 12:48

donluca wrote:

Arkanoid looks like it locks up the machine (black screen), but if I reset the MSX it actually starts and looks to be working, although with an annoying visual bug:

This occurs when the machine is restarted, if it is an MSX2 or higher.
In the startup process some bytes are overwritten from 8000h. With an MSX1, no.

By donluca

Expert (75)

04-05-2020, 14:35

@manuel: the debugger is fantastic! The issue is that I have a complete lack of knowledge of assembly and how CPUs work at low level, so right now I'm just looking at the RAM and seeing how the bin files are loaded.
The thing I'm not understanding is why if I load the original ROM via loadROM it works without issues but if I first convert it to 2 BINs with msxr2b it gives me those issues. I need to take a closer look.
Looking at the generated bins, it looks like msxr2b adds a header and lots of other stuff at the end which I have no clue about. Maybe there's an error in the header? I guess it tells BLOAD the start and end address of the data, maybe there's something wrong in there.

@grauw: Thanks, that makes perfect sense. Is this possible to achieve via BASIC? Or do I need to write it in assembler?

@Manel46: If I understood correctly, you're telling me that an MSX2 overwrites some bytes from 8000h when reset, but this doesn't happen in an MSX1. Correct?
So there's something wrong when I load the bin files which prevents the game from booting, but when I reset, due to using an MSX2, some bytes at 8000h are overwritten and this lets the game boot? (This would also explain the small graphical glitch).

By tfh

Prophet (2898)

04-05-2020, 14:54

donluca wrote:

@grauw: Thanks, that makes perfect sense. Is this possible to achieve via BASIC? Or do I need to write it in assembler?

"Back in the days" quite some BASIC loaders did:

5 POKE -1,(15-PEEK(-1)\16)*17
10 BLOAD"FILE1.BIN",R
20 BLOAD"FILE2.BIN"
30 FORa=0to1500:next:defusr=&Hxxxx:a=usr(0)

By Grauw

Ascended (9904)

04-05-2020, 14:58

donluca wrote:

@grauw: Thanks, that makes perfect sense. Is this possible to achieve via BASIC? Or do I need to write it in assembler?

DEFUSR=&HFD9F:FOR I=0 TO 256:U=USR(0):NEXT

This might also solve your problem with Arkanoid…

As tfh said, you then need to remove the ,R from the second .bin and run it manually after the disk drive loop (figure out the start address and then DEFUSR=<address>:U=USR(0)).

By donluca

Expert (75)

04-05-2020, 15:58

Thanks to both!

I'm actually studying some loaders from cracked disk to see what they were doing and indeed I found something similar to

30 FORa=0to1500:next:defusr=&Hxxxx:a=usr(0)

Now I'm starting to understand what some of those loaders are doing

By Manel46

Hero (625)

04-05-2020, 17:06

donluca wrote:

No. These overwritten bytes are not the ones that allow the rom to start. The rom is started with a reset because the bios searches and finds the rom header in 4000h.
These bytes spoil whatever is in 8000h. Usually graphics, but if there is code everything can happen.
Yes, with MSX1 this does not happen.