Jump to content
42bs

New 6502 (and successors) disassembler

Recommended Posts

10 hours ago, 42bs said:

This is the code to look for in the boot sector:
 


_382	lda $31
	jsr $fe00
	lda $fcb0
	beq _38f
	jsr _24f
_38f	lda #$10
	sta $32
_393	sec
	ldx #$10
_396	lda $fcb2
	ldy #3
_39b	adc $fcb2
	dey
	bne _39b

This is for a 256K game (ldy #3 => sum up 4 bytes).
512K games have ldy #7.

128K games have no loop, so just sum up 2 bytes.

 

I picked 8 games, and all checked the correct number of bytes. So EPYX took the wrong boot sector.

 

Ok, I ran Handybug with the breakpoint at $000200, and I let it hit that point twice, which allowed me to look at the appropriate section of code. Thank you for teaching me a bit about assembly debugging.

 

My code does not have ldy #3 or ldy #7. It has an ADC opcode instead, which I suppose puts it in that third category you mentioned (128k games).

So what you're saying is that the programmers made the Gauntlet mistake when they wrote Zarlor. They used a boot sector that leaves half of each block not check-summed.

42bs, I have to ask: What was it about my post, saying that Zarlor doesn't work on my Lynx, that lead you to the conclusion about the check-summing?
 

 

 

zarlor_boot_sector.PNG

Share this post


Link to post
Share on other sites

Zarlor uses the second type of bootsector but yes, it contains a bug which does not check the complete card. So, if the card (which seems unlikely) contains a corrupted byte in the untested part it may fail later.

 

Share this post


Link to post
Share on other sites
2 minutes ago, 42bs said:

Zarlor uses the second type of bootsector but yes, it contains a bug which does not check the complete card. So, if the card (which seems unlikely) contains a corrupted byte in the untested part it may fail later.

 

I still believe that the game is probably fine, just maybe that's it's using some part of my Lynx that's faulty.

 

Theoretically, if I knew what I was doing, would it be possible for me to hack the game such that it bypasses the troublesome title sequence at the beginning of the game?

Share this post


Link to post
Share on other sites

@BS If you check the table I posted a few h ago, you would see that zarlor used a different (newer) loader type, which check full block size. You could easily check that in the emulator by tracing the ROM reads.

@OAA It seems very very unlikely to have a hardware failure which trigegrs in only one specific game.

Share this post


Link to post
Share on other sites
4 minutes ago, sage said:

@BS If you check the table I posted a few h ago, you would see that zarlor used a different (newer) loader type, which check full block size. You could easily check that in the emulator by tracing the ROM reads.

@OAA It seems very very unlikely to have a hardware failure which triggers in only one specific game.

 

I agree that it's odd, sage, so do you have any theories? Neither the Zarlor cartridge nor the ROM file works on my Lynx. The ROM file has been verified to work on other Lynxes, and it works for me in Handy, but it crashes in my BennVenn flash cart while all other games seem to work fine in the flash cart. As for the cartridge, I don't have a second Lynx to test it on, so I might take it to the local retro store and ask if they'll test it for me. But the ROM file alone is odd. Any idea why a verified ROM file won't run on my console?

Share this post


Link to post
Share on other sites

For the benefit of myself when I look at this in the future, and for the benefit of any other newbie hacks out there, here's how I set a breakpoint in Handybug (42bs has previously suggested I should set a breakpoint at 0x200 and let it hit that twice, which will allow me to look at certain section of the assembly code).

Ok, so this is with the debugging version of Handy, version 0.98Beta in Windows 10.

I loaded the game, and then from the Debug menu, I opened the Debugger window.

In the Debugger window, I typed "HELP" to get a listing of the commands.

Then I typed "BP 1 00200" in the Debugger window. This sets breakpoint #1 at address $00200, otherwise known as 0x200.

Then I typed "RUN" in the Debugger window to run the code. It stopped when it hit the breakpoint. I typed "RUN" again, and it stopped at the breakpoint a second time.

At that point, from the Debug menu, I opened the Code window. This shows the assembly code, and I scrolled down to 00200 and confirmed that it did indeed have a little asterisk by it, marking it as a breakpoint. The code section of interest was immediately following this breakpoint.

Share this post


Link to post
Share on other sites

 

8 hours ago, sage said:

@BS If you check the table I posted a few h ago, you would see that zarlor used a different (newer) loader type, which check full block size. You could easily check that in the emulator by tracing the ROM reads.

@OAA It seems very very unlikely to have a hardware failure which trigegrs in only one specific game.

 

@sage Oops, it seems I got trapped by myself. Zarlor is a 128K game it seems. But I doubled each block back in time to make it work on our EPROM cards 🙂

Thus, the checksum code is correct.

 

 

Edited by 42bs

Share this post


Link to post
Share on other sites
6 hours ago, 42bs said:

 

UBYTE CCart::Peek0(void)
{
   ULONG address=(mShifter<<mShiftCount0)+(mCounter&mCountMask0);
   UBYTE data=mCartBank0[address&mMaskBank0];

   if(mCounter==0 || mCounter==0x1FF || mCounter==0x3FF || mCounter==0x7FF) printf("== Read bank $%02X $%03X==\n",mShifter,mCounter);
   
   if(!mStrobe) {
      mCounter++;
      mCounter&=0x07ff;
   }

   return data;
}

adding a simple print will tell you what (block and position) the loader is accessing on startup.

(unless you use my lynxboot.rom replacement, which skips the loader process ;))

 

Share this post


Link to post
Share on other sites
3 hours ago, sage said:

UBYTE CCart::Peek0(void)
{
   ULONG address=(mShifter<<mShiftCount0)+(mCounter&mCountMask0);
   UBYTE data=mCartBank0[address&mMaskBank0];

   if(mCounter==0 || mCounter==0x1FF || mCounter==0x3FF || mCounter==0x7FF) printf("== Read bank $%02X $%03X==\n",mShifter,mCounter);
   
   if(!mStrobe) {
      mCounter++;
      mCounter&=0x07ff;
   }

   return data;
}

adding a simple print will tell you what (block and position) the loader is accessing on startup.

(unless you use my lynxboot.rom replacement, which skips the loader process ;))

 

 

Sage, please help me out with my understanding here...

1) Is this bit of code meant for me or for 42bs? Where would someone add this code? Would this go into Handy's boot file?

2) Your custom lynxboot.rom... That's a replacement for the default Handy boot file, right? I assume it would not be functional as a replacement for the BennVenn El Cheapo flash cart boot file. 

 

Share this post


Link to post
Share on other sites
1 hour ago, OldAtAtari said:

 

Sage, please help me out with my understanding here...

1) Is this bit of code meant for me or for 42bs? Where would someone add this code? Would this go into Handy's boot file?

2) Your custom lynxboot.rom... That's a replacement for the default Handy boot file, right? I assume it would not be functional as a replacement for the BennVenn El Cheapo flash cart boot file. 

 

1) for anyone who wants to compile his own emulator for debugging this.

2) this is just a copyright free version for the emulator, which work with all commercial and most homebrew roms.

Share this post


Link to post
Share on other sites
6 minutes ago, sage said:

1) for anyone who wants to compile his own emulator for debugging this.

2) this is just a copyright free version for the emulator, which work with all commercial and most homebrew roms.

Thanks, sage! I'll play around with it this weekend, and I'll ask if I have any follow-up questions.

Share this post


Link to post
Share on other sites
10 hours ago, 42bs said:

I've seen once a hardware test card for the Lynx, but I have no image. Maybe someone else has and can make it "public".

Edit: Found it:

https://romhustler.org/rom/lynx/lynx-diagnostic-cart-v002-1989

The system test results from the diagnostic cart are somewhat vague. See image. I wonder what it's testing. Maybe I can find some documentation.

IMG_20210129_120614550_MP~2.jpg

Share this post


Link to post
Share on other sites

Just want to chime in and say that I have a similar issue as OldAtAtaribut with California Games.  I posted a Youtube video of the problem: 

 

 

Very strange that this only happens with this one game (original cart and romcarts).  All other games are fine.  I'm going to look into these programming resources as well and see if I can make any progress that benefits us both.  I'm a developer myself, but primarily in cloud architectures, so not so applicable here. :( 

  • Like 1

Share this post


Link to post
Share on other sites

And especially since I'm feeling guilty about hijacking this topic, I'll direct interested parties to look at my other topic specifically about my Zarlor Mercenary problem, which now, thanks to the example set by Bstar, has a Youtube video of the problem.
 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...