Dumping protected games?

[robcfg]

Hi there!

I was trying to dump "Eddie Steady Go!" and found that the wav file loads in XRoar where the CAS file dumped with XRoar too, doesn't. I think it has the kind of protection that shifts all data one bit, the one that make the sync pulses appear as 0xAA instead of 0x55.

How can I convert it to a valid CAS file?

In any case, you can download the working wav file here.

[Sarah]

What you describe doesn't sound like protection; if you're seeing sync bytes as 0xAA that probably simply indicates you're not sync'd with them? It's only likely to be necessary to do that if the cassette doesn't use the standard block structure (such as Screaming Abdabs, IIRC) although even then you can still safely assume that at least the start of data can be sync'd (which is actually what DCWIN does when used in raw/custom mode; even though DC didn't). A bit shift (in isolation) also shouldn't prevent the file loading correctly, if converted without any loading errors (unless the emulator you're using actually requires the data to be byte aligned).

The copy of ESG held in the archive appears to be the one that I made in 1995. I don't remember having any difficulty with it - but then it was 17 years ago! A quick view doesn't show anything unusual about it (looks like a short loader consisting of 3 blocks, followed by 2 headerless sections):

Code: Select all

Leader length 9 bytes
Header "EDDIE" (binary: start 410, exec 512)
Leader length 12 bytes
EOF (total 3 blocks)
Leader length 51 bytes
EOF (total 118 blocks)
Leader length 51 bytes
EOF (total 8 blocks)

[robcfg]

Hi Sarah,

If I convert the wav file with Xroar, the resulting cas file shows a corrupted loading screen and doesn't load.

Could you try to convert my wav file?

[Sarah]

I don't have anything to hand for checking the WAV header, but looking at the bytes in your file, presumably it's a 16-bit sample?

[robcfg]

Yes, but I can convert it to 8bit samples if you need it.

I've attached my cas file dumped with xroar.

Thanks for your help!

[Sarah]

Okay... I made a quick change to DCWIN so that it down-converts the 16-bit samples on-the-fly and your WAV file then worked straight away. The result is much the same as the previous analysis:

Code: Select all

Loading C:\EddieSteadyGo.wav
Read 18602352 bytes (17MB)
Calculated volume threshold 31
Calculated average wavelength 32 bytes
Leader length 128 bytes
Header "EDDIE" (binary: start 410, exec 512)
Leader length 128 bytes
EOF (total 3 blocks)
Leader length 128 bytes
EOF (total 118 blocks)
Leader length 128 bytes
EOF (total 8 blocks)
Finished

The CAS file saved from this conversion loads fine in T3. I also tried the one that you just attached and that loads fine too. I don't see any corruption of the loading screen? Do you mean something really difficult to see -- just a few pixels the wrong colour?

[robcfg]

I mean something in the line of the attached screenshot

ESG_XROAR_FAIL.PNG (25.51 KiB) Viewed 4323 times

And it freezes there.

[Sarah]

Looks like something's wrong with XROAR. This is what I see using any of the CAS files with either PC-Dragon or T3:



The game then starts once loading is complete...

[sixxie]

Looks like the main problem here is that XRoar doesn't account for how long has passed when writing out leaders. When it "desyncs" (ie, detects that the ROM is now trying to sync with leader), it just adds in a 256 byte leader. This isn't long enough for Eddie Steady Go (and the generated CAS file won't load into a real Dragon either). Here's one with the code hacked to generate 384 byte leaders instead.

I'll try and make XRoar actually insert leaders corresponding to how much time has passed when the ROM syncs up.

[zephyr]

Yes, but I can convert it to 8bit samples if you need it.

I've attached my cas file dumped with xroar.

Thanks for your help!

The .CAS file loads perfectly under XROAR v0.24.