archive.worldofdragon.org

Hi Ciaran!

I was testing my dump of Manic Miner and it loads ok in XRoar but, when I press enter to play, it just shows random data on screen and hangs.

The dump works ok on a real Dragon. The same behaviour occurs with the dumps in the archive.

I'm using XRoar 0.27 on Windows 7 64 bit.

Funny enough, it works on the same version in my Linux Mint 12 under virtualbox... I don't remember whether it's 64 bit or not.

Well that was an interesting one - I had to git bisect to discover that's down to what happens to the data bus when the CPU fetches from an address that no device handles. DarrenA pointed out that the bus tends to indicate the last thing that was on it (probably the fetch instruction itself), and that behaviour's been built into XRoar since 2010 (version 0.24-ish). Except it's always been a bit lacking - it wasn't updated during "dead" CPU cycles.

I've pushed some snapshot builds fixing this, but I'm going to have to trace through Manic Miner and find where it accesses empty memory (maybe it's trying to check for a cartridge present as part of its copy protection or something).

I just tried my own copy and the cracked version of Manic Miner from the archive and they both work fine. Tested on XROAR versions 0.24, 0.27, and 0.28 with the following command line under 32-bit Windows XP.
I have attached both copies for test purposes.

EDIT: Attachment removed.

Oh I only just noticed the 32/64 bit implication...

I'm not even sure I have easy access to any machines with a 32-bit OS, but even so, that fix has nothing to do with word length. Very weird.

Tracing through, it runs this:
Where it proceeds to deliberately blat memory. Amusing! And indeed caused by my short-cut in the NVMA code: the NVMA after each instruction should put the same value on the data bus (from the top byte of ROM) in each case, and they'd compare. My short cut meant that the "bus" read $01 for the LDA and $02 for the CMPA.

Here's the discussion about what ends up on the data bus, with DarrenA pointing out what's going on here.

But what on earth in my code could produce a different result on a 32-bit machine? I'm a little confused by that.

Edit: Zephyr: looks like both your versions are cracked, they skip the code input stage entirely, which means they probably also omit that little bit of "protection" too.

Edit edit: also, actually I guess I will have a 32-bit OS - but it'll be Mac OS X on PowerPC, so may not prove anything.

sixxie wrote:Edit: Zephyr: looks like both your versions are cracked, they skip the code input stage entirely, which means they probably also omit that little bit of "protection" too.

Yes, just checked and that test for the presence of a cartridge is bypassed in both versions. When Robcfg wrote "The same behaviour occurs with the dumps in the archive" I assumed he had tried them all. No problems running that code under Dragon 32 emulation under XROAR 0.24 and the latest 0.28 snapshot with 32-bit Windows XP.

sixxie wrote:Where it proceeds to deliberately blat memory. Amusing!

Yep, such anti-social behaviour from a popular game was pretty silly and begging to be cracked! I hated ever having to remove ALLDREAM...

Sarah wrote:Yep, such anti-social behaviour from a popular game was pretty silly and begging to be cracked! I hated ever having to remove ALLDREAM...

That's just begging for a blow by blow account

Hi guys!

I tried zephyr's version and runs dandy on my setup.

Also, here you have my dump, it works ok in a real dragon and loads in Xroar (on my machine) up to the point where it freezes.

robcfg wrote:Also, here you have my dump, it works ok in a real dragon and loads in Xroar (on my machine) up to the point where it freezes.

It runs perfectly for me under the latest XROAR 0.28 snapshot (xroar-snap-20120509-w32). Try the attached version...

EDIT: Attachment removed.

My version works with the latest XRoar snapshot, thank you!

And the last zephyr version works with my standard 0.27 setup...