junior's revenge and eddie steady go wavs?

[samplefiend]

hi all

can anyone out there provide wav files that will load in xroar and a real dragon please? i've tried converting the cas files here but they don't seem to work even with fixcas etc used first.

thanks in advance for any help folks,

craig xxx

[admin]

Attached is a WAV of Eddie Steady Go - This was created from the CAS file on this site by doing the following:

1. FIXCAS EDDIE_ST.CAS EDDIE_S2.CAS

Simple converting EDDIE_S2.CAS to EDDIE_S2.WAV doesn't work, the loading screen is shifted horizontally and corrupted at the bottom etc. This usually means there is something missing from the CAS file (CAS files do NOT track silence) or the parameters used by fixcas need changing to set the interblock gap to a diferent value. Not knowing what this was, I tried something and used XROAR to load EDDIE_S2.CAS, but output (Ctrl+W) EDDIE_S3.CAS - This will output exactly what the dragon is asked to read.... The result was that EDDIE_S3.CAS included an additional set of sync bytes (~128) between the autoload routine and the loading screen which would account for the loading screen being shifted horizontally and that the interblock sync was 5.

2. Use XROAR to load EDDIE_S2.CAS and output EDDIE_S3.CAS
3. Use DC to convert EDDIE_S3.CAS to EDDIE_S3.WAV

EDDIE_S3.WAV loads fine in XROAR and should work on a real dragon.

[admin]

Attached is a working WAV of Juniors Revenge (Microdeal). Once more the problem was missing data in the original CAS file and this exhibited itself as a loading screen that was horizontally shifted.

Using the exact same process as above the output from XROAR showed that there were several blocks on the tape each with a full set of sync bytes and the interblock sync seems to vary (copy protection?).... Either way the output from XROAR when converted to a WAV works fine.

I wonder if sixxie will comment on why/how XROAR is filling in these "missing" sync bytes ! - Really glad I found out by accident that it did!!

[samplefiend]

hi there Simon,

Many thanks for the speedy response and even quicker uploads! both files loaded fine at my end in Xroar and i'll try them on ym hardware D32 tomorrow. is there any chance you could possibly upload the fixed cas files for both games too please? i converted them with DC.exe but it shifted the loading screens again and they won't load. it's so i can run them on my NDS too.

thanks again for all your help mate, you are a star!

craig xxx

[sixxie]

Ok, here's what's going on. Hope this helps understand how it works,
and why it sometimes doesn't!

The XRoar "-tapehack" mode employs a crazy heuristic to try and both
accurately reflect data blocks read by the standard ROM routines, and
format data bytes on nice boundaries to create "readable" .cas files.

It only works well for (most) programs that only use the ROM calls
when loading. For anything else (Superkid, Fire Force, ...) I still
need to study what's going on and specifically patch to account for it.

No data is written until the state is considered synced. State is
initially desynced with a long leader required to be written on the next
"sync".

Four ROM routines are trapped:

At $B94D, partway into the BLKIN call at $B93E, once a block sync byte
is recognised, a leader is written (long or short) and the state is
marked synced. The sync byte itself is also written ($3C).

At $B97E, about to return from BLKIN, the state is set to desynced, but
only a short (2 byte) leader is requested for the next sync. Most data
blocks will trigger this.

At $BDAC, returning from the BITIN call at $BDAD, a bit is written if
the state is synced.

At $BDE7, CASON, the state is marked desynced with a long leader required
for the next sync.

Additionally, whenever the cassette motor changes state to OFF, the state
is desynced with long leader required for next sync. Whenever the state
is desynced, zero bits are output to ensure the last byte is complete.

For a standard data stream, that basically amounts to a long leader being
written before the filename block and the first data block (because the
motor will switch off) with short leaders between all other blocks.

Some games use a "gapped loader", with the motor switching off and on
between all data blocks, and these will result in lots of long leaders
appearing in the output.

[samplefiend]

hi again

both wavs loaded no problems on my dragon 32 and i figured out how to covnert them to working .cas files using the tapehack option.

thanks again Simon for your help!

craig xxx