Modifying Homesoft's Miner 2049er - Addit'ns causing crash behavior - ideas?

[tschak909]

Hello All,

 

am in the middle of bringing up more games as High Score Enabled.

 

Miner 2049'er has a high score table, but it isn't persisted.

 

The approach has been thus:

 

* Grab a copy of Homesoft's Miner 2049er.xex

* Add two segments to load and save the high score memory table from disk sectors 719/720, respectively.

* Change existing calls to hiscore table and enter high scores to jump through these new routines, and back to their original places on the way out.

 

I have made the modifications, and tools to apply these modifications, and placed them on GitHub here:

https://github.com/FujiNetWIFI/fujinet-high-scores/tree/main/atari-game-ports/miner-2049er

 

The makefile does the following:

* Pulls virgin XEX from ../../atari-blank-games

* Assembles the read and write asm routines.

* Compiles and Runs the first patch program (patch.c) to fold these two in as new segments. The write routine has a replacement 0x2E0 segment.

* Runs Hias's dir2atr to create a new DOS 2.0 disk image with this XEX in, with picoboot.atr as the boot record.

* Compiles and runs the second patch program (patch2.c) to insert the contents of score.bin, containing a score table into sectors 719/720 of the new disk image.

 

At this point, we have the ATR that I've attached.

 

The read routine loads into address $5900

The write routine loads into address $5A00

 

But it goes a bit wonky. Upon booting, the title screen starts normally, and crashes when the rainbow effect starts.

 

The game will play normally, but when a new high score is entered, pressing ENTER will cause the program to crash again, after the first call to SIOV. Looping through XMTDON (as if the SIO complete vector never happens)

 

This one is a head-scratcher. What could be going wrong?

 

-Thom

Miner 2049er.atr

[phaeron]

It looks like you are trying to directly patch an LZ-compressed executable. One of the code fragments you patched was reused in a copy span, corrupting later code in the program.

 

[tschak909]

oh dear, guess I need to use a different version of the program, then...

 

Thanks

 

Does Mr. Homesoft frequent AtariAge?

 

-Thom

 

[phaeron]

  2004:227: 38 | A=00 X=00 Y=80 S=F5 P=33 (    ZC) | 2016: F0 63             BEQ $207B
  2004:227: 42 | A=00 X=00 Y=80 S=F5 P=33 (    ZC) | 207B: 60                RTS
  2004:227: 50 | A=00 X=00 Y=80 S=F7 P=33 (    ZC) | 2012: 4C C1 7F          JMP $7FC1
  2004:227: 54 | A=00 X=00 Y=80 S=F7 P=33 (    ZC) | 7FC1: AD 14 D0          LDA PAL

 

You could also try to patch the loader after decompression and before it transfers control to the game.

[+MrFish]

4 hours ago, tschak909 said:

Does Mr. Homesoft frequent AtariAge?

Calling Mr. @nobody

 

[tschak909]

Getting much closer. patched the code to now properly do the patching AFTER the decompressor has done its thing, and the game doesn't crash now. yay.

 

This leaves reading/writing to the disk. 

 

Miner seems to really do a number on the pokey interrupts, effectively masking everything off, but restoring the interrupt mask still doesn't cause XMTDON to complete, even though the mask is active. What am I missing?

 

	LDA #$00
	STA NMIEN
	STA DMACTL
	STA SDMCTL

	LDA #$C0
	STA POKMSK
	STA IRQEN
	
	LDA #$31		; Drive 1
	STA DDEVIC
	LDA #$01		; Unit 1 (D1:)
	STA DUNIT
	LDA #'R'		; Read
	STA DCOMND
	LDA #$40		; ->Atari
	STA DSTATS
	LDA #$00		; $0800
	STA DBUFLO
	LDA #$08
	STA DBUFHI
	LDA #$80		; 128 bytes
	STA DBYTLO
	LDA #$00
	STA DBYTHI
	LDA #$CF		; Sector $02CF
	STA DAUX1
	LDA #$02
	JSR SIOV		; Do it (It spins here, XMTDON never happens.)

	LDA #$40		
	STA DSTATS
	LDA #$80		; $0880
	STA DBUFLO
	LDA #$08
	STA DBUFHI
	LDA #$89		; Sector $02D0
	STA DAUX1
	JSR SIOV		; do it

	LDA #$3E
	STA DMACTL

	LDA #$80
	STA NMIEN
	
	JMP $92B9		; Finish and back to high score display

 

-Thom

 

[phaeron]

Common cause of this is calling SIOV with the I flag set. This hangs the transfer because the IRQs never fire.

 

Miner also appears to replace the VBI immediate vector. This will cause SIO to hang if a device timeout occurs, because OS timer #1 isn't run.

 

[Chilly Willy]

Also, many games never expect you to be using the SIO during the game, so they feel free to reuse ram used by the SIO for game data. You may need to back up and restore SIO ram locations when trying to use the SIO. I don't know if Miner does or not, but it seems like something that should be checked.