Shamus fixed for XL/XEs with title music?

[Rybags]

You can do keyboard processing without need for enabling the IRQ. Just read the KBCODE register on Pokey and use the SKCTL bits to do debounce. For debounce just ignore the "same as previous" keypress for 3 frames after the keyup of occurs.

[+slx]

You can do keyboard processing without need for enabling the IRQ. Just read the KBCODE register on Pokey and use the SKCTL bits to do debounce. For debounce just ignore the "same as previous" keypress for 3 frames after the keyup of occurs.

I actually thought it would be easier using the IRQ because it would save me patching whatever main loop the game uses. Rob did not find a VBI that made it "tick" and as it does not use the keyboard at all my idea was to enable a keyboard interrupt during my initial patching routine which when any key is hit would then execute my "pause" code that needs to stop whatever else is going on and switch to a new screen with "PAUSE" until another key is hit and everything is restored before an RTI....wishful thinking?

 

One could also argue that a pause feature would make the game too easy

Edited September 18, 2017 by slx

[+slx]

After lots of tinkering with the code that changes the speed when moving from level to level I had the brilliant (if late) idea to change the delay loop code itself. As it employed an unnecessary CPX #00 before a BNE it was easy to add a BMI instead and presto, negative speed values are treated just like zero. This will add up to 7 cycles per use of the delay loop but that should be imperceptible for all but the most finely tuned Shamus players

 

Another extremely simple change to the speed adjustment routine (cancelling out some code with NOPs) took care of a logic bug that would have allowed speed to become slower than it was initally when running back and forth through levels several times.

 

Not that it is extremely likely that anyone would have ever suffered from either "bug", but then I can't release a Shamus with known errors ...

[Rybags]

Seems the game uses DLIs in lieu of VBlank processing. Whether "tick" related stuff goes on inside those?

 

My suggestion would be to just try a VBI Immediate to implement the pause. If the player presses Space, just stay inside the routine, do the debounce and wait for Space again. Disable further VBlank NMIs in the meantime and do the return at VCOUNT = 0 with NMIs enabled again just to keep things sort of normal.

 

I don't think you could disable DLIs without screen corruption - stuff like seperate charset for walls and the score. And probably some colour changes going on too.

[+slx]

 

My suggestion would be to just try a VBI Immediate to implement the pause. If the player presses Space, just stay inside the routine, do the debounce and wait for Space again. Disable further VBlank NMIs in the meantime and do the return at VCOUNT = 0 with NMIs enabled again just to keep things sort of normal.

 

I don't think you could disable DLIs without screen corruption - stuff like seperate charset for walls and the score. And probably some colour changes going on too.

 

Enabling VBI causes DLIs to stop. Maybe need a better place to insert my VBI code.

 

My idea was to "bypass" the DLI stuff by using an alternative display list without DLIs during pause and switching back to the original display list including DLIs when pause ends.

 

Will try that next but for now, off to work.

[Rybags]

I suspect the system VBI code is probably upsetting something, possibly due to doubling up on some functions.

Possibly you could enable VBlank, use the Immediate vector just JMP $E462 which will bypass all the OS code.

[+slx]

I suspect the system VBI code is probably upsetting something, possibly due to doubling up on some functions.

Possibly you could enable VBlank, use the Immediate vector just JMP $E462 which will bypass all the OS code.

:headbang: Of course! System VBI messes with all colours, CHBASE, etc. and if the system didn't need it before it certainly won't need it now... thanks for the hint! (Should have noticed as the menu colors had changed but I was too focused on the interrupts.)

 

 

Gesendet von iPhone mit Tapatalk

[Rybags]

The question would still remain though - do the DLIs only do screen related stuff or is timing or game dynamics tied to one or more?

I guess one way to find out - pause at the start of a room, wait 30 seconds then resume - if there was timer action going on you'd probably have the shadow show up right away.

[+slx]

I got the VBI running in the menu without problems but it seems the program uses the VBI vector addresses as variable storage. So I'll either have to go the KBI route or find all code changing VVBLKI at $222/$223 and redirect that somewhere else (which doesn't sound like much fun).

[Rybags]

If it's using the VBlank vectors then maybe it's using others as well.

 

Have you considered just running the whole thing through IDA's Disassembler? Then you could have some workable source which ultimately might make modifying it easier.

[+slx]

If it's using the VBlank vectors then maybe it's using others as well.

 

Have you considered just running the whole thing through IDA's Disassembler? Then you could have some workable source which ultimately might make modifying it easier.

 

As I started this as a project of "just patching in the maps from the C64" and never thought I'd need to re-code the game as much as I have to now, I didn't try to completely so far. Will have a look at it.

[+slx]

If it's using the VBlank vectors then maybe it's using others as well.

 

Have you considered just running the whole thing through IDA's Disassembler? Then you could have some workable source which ultimately might make modifying it easier.

 

Managed to install IDA freeware under Boxer (a DOSBox like app for Mac) and put a copy of Shamus where it can find it, but I can't set it to 6502, it only offers 386 type processors.

[Rybags]

That's a bummer. I've got a dodgy torrent download from probably 4 years ago. It has all sorts of CPUs supported from the 70s onwards but is a Win32 application.

[+slx]

$222 and $223 seems to be one of the "main" game variables involved in screen and enemy drawing but fortunately it is always used with direct addressing. I think I have found all occurrences and after patching them to a safe place the game still works! Now need to make this patch permanent and then I can try VBIs again.

[+slx]

I managed to successfully stop the game but can't restart it properly.

 

Below is the code I use for my VBLANK routine. When Space is sensed (via SKSTAT and KBCODE) during four consecutive VBIs, it changes to the PAUSE routine, kills NMIs, changes the display list to a display list just showing "PAUSED" (which has the nice effect of halting all DLIs that make the game move) and kills the sound.

 

Then it waits for any key being pressed "4 times in a row" and if that happens, jumps to ENDPAUSE which restores the display list and enables NMIs.

 

The only drawback is that it only stays unpaused if I hold the space key and returns to PAUSE when I release it.

 

I suspect some logic error which I can't find past midnight or some anomaly with SKSTAT (when I debug this, SKSTAT seems to read $FF all the time once I have pressed the space key.

CHECKKEYS	LDA SKSTAT
			AND #$04
			BEQ EXIT
			LDA KBCODE
			CMP #$21
			BNE EXIT0
			INC PAUSECTR
			LDA PAUSECTR
			CMP #$04
			BNE EXIT2
	
PAUSE		LDA #$00
			STA NMIEN
			STA PAUSECTR
			LDA <PAUSEDLIST
			STA DLISTL
			LDA >PAUSEDLIST
			STA DLISTH
			LDA #$00
			LDY #$03
KILLAUDIO	STA AUDF1,Y
			DEY
			BPL KILLAUDIO
			
PAUSING		LDX #$04
KEYPRESSED	LDA SKSTAT
			AND #$04
			BNE PAUSING
			LDA KBCODE
			CMP #$21
			BNE PAUSING
			DEX
			BEQ ENDPAUSE
			BNE KEYPRESSED
 
ENDPAUSE	LDA #$B8
			STA DLISTL
			LDA #$35
			STA DLISTH
			LDA #$C0
			STA NMIEN
			STA HITCLR
EXIT0		LDA #$00
EXIT		STA PAUSECTR
EXIT2		JMP XITVBV

PAUSECTR		.BY $00

[Rybags]

Probably a logic error - I'd use a Ram based variable to flag a pause. Then branch to the appropriate code in the VBlank depending on it's value.

[NRV]

Without looking at the code, sounds like you need to use another key for unpause (like esc), instead of space..

[+slx]

Without looking at the code, sounds like you need to use another key for unpause (like esc), instead of space..

I'll try using the fire button to unpause. Still don't get why I can't register that the key is not pressed any longer.

 

The 'branch on paused/unpaused in VBI' is not that easy as I stay in the VBI all the time while paused in order to fully stop the game main loop and DLIs. (That means I disable further VBIs and use a separate display list without DLIs.) Unpause actually works with the code above, but only as long as I keep Space pressed.

 

 

Gesendet von iPhone mit Tapatalk

[+slx]

Pause works with fire button unpausing, and the routine is much shorter now than before. I still don't get why SKSTAT and KBCODE don't work as I thought they would...

 

I am a bit concerned, however, that introducing a VBI where there was none before will slow down the game (even if just a bit) by "stealing" a couple dozen cycles every frame, so I'll explore the keyboard interrupt path again. I think I found a way to patch all those $208/209 (keyboard interrupt vector) references with a routine that simply searches for all occurrences of $08 $02 or $09 $02 and replaces them with a "safe" storage address. Now need to tackle the IRQ code, hope it isn't more difficult than the VBI.

[Rybags]

I doubt the slowdown would be noticable. I've never experimented with the game re speed before but if it's largely based on delay loops then it probably runs at almost identical speed on Pal/NTSC. It varies depending on what graphics mode is in use but PAL machines actually run a little bit faster in the default Gr. 0 environment.

[+slx]

It's ANTIC mode 4.

 

Counting all instructions the total length of the VBI if nothing has happened is 72 cycles, so around 0,04 milliseconds.... I can shorten it to 71 cycles

[+slx]

Turns out using a keyboard IRQ isn't that easy either as all the IRQ vector space is used for game variables. While a major nuisance for this project, it never ceases to amaze how you can simply use an area in memory that is vital to normal OS functions for your own stuff if you don't plan to use that part of the OS.

 

While I dutifully cleared the VKEYBD vector I forgot VIMIRQ, leading to a jump to nowhere. Should be fixable but now I need to go to bed. As no other IRQs are used I think I'll leave VKEYBD alone and simply redirect VIMIRQ to my pause routine.

[+therealbountybob]

It's all good fun

[+slx]

Sure is!

 

As I still don't know how to prevent the keyboard interrupt from firing again after I have cleared it by storing 0 to IRQEN, I will return to the VBI solution and just tolerate a few milliseconds of delay per frame.

[Rybags]

The IRQ firing again problem is probably key bounce. The OS even caters for it by ignoring "same key again" IRQs for 3 frames.

 

So you could do the same... but that needs a frame counter ie VBlank. So doing it by VBlank is probably the better approach anyway.