"The Grave Cave" Eathenr0ss Software (c) 1982

[groepaz]

I havent seen a thread about this one, so here it is...

This one appeared in a VICE bug report ages ago. The .tap did not load, and generally looked broken (but apparently isnt)

In any case - SLC managed to partially solve the riddle:

first, the game requires +3k (Block 0) Expansion. so far so trivial

then. for some reason this game requires a strange procedure to load (and this is also the case on real VICs)

load<return>
<run/stop>
load<return>
<play>

following this sequence it loads and runs fine

The remaining question is what exactly happens there, and why?

If you go to the monitor before the first and the second LOAD, you can see that somehow this procedure results in a stack pointer misalignment (first $f3, second $f2)

The author of the game however claims that this tap loaded on real, early, VICs. see the whole mess (and .tap) in the ticket: https://sourceforge.net/p/vice-emu/bugs/206/

How could this ever work without using this load/break/load sequence? I tried some alternative ROMs, but no dice so far It might also be a simple case of using uninitialized RAM - however i also tried a few common patterns with no luck

Perhaps having a few dumps from different sources could also shed some light on this (ie, do they all behave like this?)

[tokra]

If you go to the monitor before the first and the second LOAD, you can see that somehow this procedure results in a stack pointer misalignment (first $f3, second $f2)

I've played around with this a little and notice that the game loads fine, if you do a STOP/RESTORE before loading. This also changes the startup value of the stack-pointer from $f3 to $f2.

I confirmed this behavior of the stack-pointer being one less after STOP/RESTORE compared to RESET on my real machine as well. As to why this is or why this could be causing the loading-problem is beyond me. Even the C64 does this stack-pointer change from $f3 to $f2 (at least VICE does).

Not sure what else gets initialized by STOP/RESTORE.

[groepaz]

Good observation! (And also weird behaviour...)

[tokra]

For what it's worth: I tried loading this .tap yesterday with my SD2IEC with TAP-support (from Manosoft.it SD2IEC ITS) on my original PAL-machine. Basically this emulates a tape-drive with the SD-card. It did not crash the computer, but did not start loading the second part either. I did the STOP/RESTORE-trick on the next try and then it loaded and started fine.

So, just a poorly constructed loader in my opinion that may work on some obscure machines, but certainly no fault of VICE if it does not.

[Mike]

I confirmed this behavior of the stack-pointer being one less after STOP/RESTORE compared to RESET on my real machine as well.

The BASIC cold start (after power on or reset) initialises the stack pointer with LDX #$FB/TXS at $E381. Any action that at least partly involves the CLR routine at $C65E (BASIC warm start from STOP/RESTORE, program start, file I/O and BASIC runtime errors, after program load in direct mode, NEW) initialises the stack pointer with LDX #$FA/TXS at $C681. KERNAL and BASIC interpreter push some data on the stack before the already mentioned "$F3" or "$F2" values of the stack pointer are encountered.

In practice that means, the "$F3" value will only ever be visible right after reset; about any time later whenever BASIC deems it necessary to purge the stack, "$F2" will appear. That behaviour can also be observed with MINIMON (with the SP values of $F7 and $F6, respectively):



In any case, it is no emulation related thing. Real hardware shows indeed the same behaviour, also on C64 (see ROM addresses $E39D and $A681), C16/C116/+4 (checked with TEDMON) and C128 (also checked with TEDMON) ... quite probably on all 8-bit CBM BASIC versions.

Greetings,

Michael