Road Runner C64 - Mindscape can't make a working G64!

[BarryB]

Obtained a Loose Disk of Road Runner ages ago, distributed by Mindscape which I can't make a working G64 of? I believe this is from the Arcade Mega-Hits Vol.1 compilation and no idea if PAL or NTSC! Retried today to see I could make it work but no luck. The disk has ben dumped and on the ftp: /DUMPS/C64/BarryB/20-08-2016/Loose Disks/RoadRunner[LooseDisk][Commodore64].7z

The Disk is notchless so can't see it being deliberately modified but when dumping (using -i6) all tracks show *H warnings and some show as having +XX sectors modified! There is an error on T0.0 (T1 CBM) with 1 bad sector and have read there are 2 versions of this disk, one with V-MAX and one with weak bits on T1 so I guess that bad sector on T1 is the protection? Also, when it gets to T0.0 I get the usual 'Control command rejected by the device' message but as there is an error on T0.0 I get this message after every revolution, can this behaviour be ignored and is it normal?

However, when I create a G64 it fails to load in WinVICE 2.4a in either PAL/NTSC and variant models as it always sticks on T1 and goes no further! Is this a known hard to copy disk or just not supported in a G64? Not tried on real hardware as I haven't got a C64 setup to test.

Here's the output when dumping:

-

Code: Select all

8.1[00]: CBM DOS: <unformatted>
-6.1[02]: CBM DOS: <unformatted>
-4.1[04]: CBM DOS: <unformatted>
-2.1[06]: CBM DOS: <unformatted>
00.0    : Control command rejected by the device
00.0    : CBM DOS: <error>, trk: 001, sec: 21, bad: 1, *H +9
00.0    : Bad sector found
00.0    : Control command rejected by the device
00.0    : CBM DOS: <error>, trk: 001, sec: 21, bad: 1, *H +9
00.0    : Bad sector found
00.0    : Control command rejected by the device
00.0    : CBM DOS: <error>, trk: 001, sec: 21, bad: 1, *H +9
00.0    : Bad sector found
00.0    : Control command rejected by the device
00.0    : CBM DOS: <error>, trk: 001, sec: 21, bad: 1, *H +9
00.0    : Bad sector found
00.0    : Control command rejected by the device
00.0    : CBM DOS: <error>, trk: 001, sec: 21, bad: 1, *H +9
00.0    : Bad sector found
00.0    : Read operation failed
00.1[08]: CBM DOS: <unformatted>
02.0    : CBM DOS: OK*, trk: 002, sec: 21, *H
02.1[10]: CBM DOS: <unformatted>
04.0    : CBM DOS: OK*, trk: 003, sec: 21, *H +21
04.1[12]: CBM DOS: <unformatted>
06.0    : CBM DOS: OK*, trk: 004, sec: 21, *H +2
06.1[14]: CBM DOS: <unformatted>
08.0    : CBM DOS: OK*, trk: 005, sec: 21, *H
08.1[16]: CBM DOS: <unformatted>
10.0    : CBM DOS: OK*, trk: 006, sec: 21, *H +2
10.1[18]: CBM DOS: <unformatted>
12.0    : CBM DOS: OK*, trk: 007, sec: 21, *H +21
12.1[20]: CBM DOS: <unformatted>
14.0    : CBM DOS: OK*, trk: 008, sec: 21, *H +1
14.1[22]: CBM DOS: <unformatted>
16.0    : CBM DOS: OK*, trk: 009, sec: 21, *H +1
16.1[24]: CBM DOS: <unformatted>
18.0    : CBM DOS: OK*, trk: 010, sec: 21, *H
18.1[26]: CBM DOS: <unformatted>
20.0    : CBM DOS: OK*, trk: 011, sec: 21, *H +17
20.1[28]: CBM DOS: <unformatted>
22.0    : CBM DOS: OK*, trk: 012, sec: 21, *H +5
22.1[30]: CBM DOS: <unformatted>
24.0    : CBM DOS: OK*, trk: 013, sec: 21, *H +1
24.1[32]: CBM DOS: <unformatted>
26.0    : CBM DOS: OK*, trk: 014, sec: 21, *H +1
26.1[34]: CBM DOS: <unformatted>
28.0    : CBM DOS: OK*, trk: 015, sec: 21, *H +1
28.1[36]: CBM DOS: <unformatted>
30.0    : CBM DOS: OK*, trk: 016, sec: 21, *H +21
30.1[38]: CBM DOS: <unformatted>
32.0    : CBM DOS: OK*, trk: 017, sec: 21, *H +18
32.1[40]: CBM DOS: <unformatted>
34.0    : CBM DOS: OK*, trk: 018, sec: 19, *H +8
34.1[42]: CBM DOS: <unformatted>
36.0    : CBM DOS: OK*, trk: 019, sec: 19, *H +16
36.1[44]: CBM DOS: <unformatted>
38.0    : CBM DOS: OK*, trk: 020, sec: 19, *H
38.1[46]: CBM DOS: <unformatted>
40.0    : CBM DOS: OK*, trk: 021, sec: 19, *H
40.1[48]: CBM DOS: <unformatted>
42.0    : CBM DOS: OK*, trk: 022, sec: 19, *H +1
42.1[50]: CBM DOS: <unformatted>
44.0    : CBM DOS: OK*, trk: 023, sec: 19, *H +1
44.1[52]: CBM DOS: <unformatted>
46.0    : CBM DOS: OK*, trk: 024, sec: 19, *H
46.1[54]: CBM DOS: <unformatted>
48.0    : CBM DOS: OK*, trk: 025, sec: 18, *H
48.1[56]: CBM DOS: <unformatted>
50.0    : CBM DOS: OK*, trk: 026, sec: 18, *H
50.1[58]: CBM DOS: <unformatted>
52.0    : CBM DOS: OK*, trk: 027, sec: 18, *H
52.1[60]: CBM DOS: <unformatted>
54.0    : CBM DOS: OK*, trk: 028, sec: 18, *H +16
54.1[62]: CBM DOS: <unformatted>
56.0    : CBM DOS: OK*, trk: 029, sec: 18, *H +18
56.1[64]: CBM DOS: <unformatted>
58.0    : CBM DOS: OK*, trk: 030, sec: 18, *H +13
58.1[66]: CBM DOS: <unformatted>
60.0    : CBM DOS: OK*, trk: 031, sec: 17, *H +11
60.1[68]: CBM DOS: <unformatted>
62.0    : CBM DOS: OK*, trk: 032, sec: 17, *H +12
62.1[70]: CBM DOS: <unformatted>
64.0    : CBM DOS: OK*, trk: 033, sec: 17, *H +15
64.1[72]: CBM DOS: <unformatted>
66.0    : CBM DOS: OK*, trk: 034, sec: 17, *H +10
66.1[74]: CBM DOS: <unformatted>
68.0    : CBM DOS: OK*, trk: 035, sec: 17, *H +10
68.1[76]: CBM DOS: <unformatted>
70.0    : CBM DOS: <unformatted>
70.1[78]: CBM DOS: <unformatted>
72.0    : CBM DOS: <unformatted>
72.1[80]: CBM DOS: <unformatted>
74.0    : CBM DOS: <unformatted>
74.1[82]: CBM DOS: <unformatted>
76.0    : CBM DOS: <unformatted>
78.0    : CBM DOS: <unformatted>
80.0    : CBM DOS: <unformatted>
82.0    : CBM DOS: <unformatted>

Enjoy your shiny new disk image!
Please consider helping us to preserve media and continue development:
http://www.softpres.org/donate

[ZrX]

Sounds like NTSC Mindscape weakbits that DTC doesn't know yet how to handle.

There's a sector on track 1 that contains 3 bytes with short weakbit section inbetween. Those 3 bytes have to match what's checked or it fails.

[BarryB]

Right, so unsupported at this time then and I guess it will fail when written back to disk and loaded on real hardware? It seems to be continually reading track 1 because if you detach the disk from WinVICE it drops to a READY prompt and the drive indicator flashes an error.

At least I have the streams for when it gets supported!

[ZrX]

IIRC the protection reads 8 bytes from the start of that sector, then checks bytes 3, 7 and 8. Bytes 4-6 contain weakbits.

[BarryB]

Well, you have far superior knowledge about the disk structure than me, so I guess what's happening is it can't read some of those bytes (as they are not there or not correct format) so just keeps looking ad infinitum!

[Feltzkrone]

@ZrX: Yes, that's almost correct.

The drive code reads the first 16 raw GCR data bytes of track 1 sector 0 where

• 2nd byte must be D5
• 7th byte must be AA
• 8th byte must be D4
• the value of 4th, 5th or 6th byte must change on two consecutive reads

With AGC involved it's hard to judge from the raw random-looking flux data what exactly has been written to disk originally, but a pattern of 55 D5 55 00 00 00 AA D4 should do for emulation and one could add very few 1-bits in case that framing is lost too frequently on real hardware, e.g. 55 D5 55 01 01 00 AA D4 instead. Can't check the latter because I currently don't have working C64 equipment set up.

In VICE you can track what's going on using the monitor:

Code: Select all

device 8:
break store 0310
m 0300

At each break drive memory at 0301 holds the bytes which have just been read. Things which are probably going wrong during conversion of raw flux to G64 bits are lost framing for the 7th and 8th byte and/or lost weak bits property for bytes 4-6, i.e. the G64 just contains random bytes which aren't weak anymore.

So just keep the raw stream files to make sure that nothing is lost and if you need working G64 files for cases like these and you're not comfortable with waiting for corresponding IPFs and an updated decoder library don't hesitate to ask for those.*

* in return for a submitted dump or proof of ownership of course

[ZrX]

I should get one of these Mindscape disks to do analog dump of the sector to see how it was really written.

[BarryB]

@Feltzkrone: I dumped the original disk as mentioned in the first post: /DUMPS/C64/BarryB/20-08-2016/Loose Disks/RoadRunner[LooseDisk][Commodore64].7z

So if a working g64 can be made i'd very much appreciate that!

[mr.vince]

Barry, you need to learn to format your posts please.

See Feltzkrone's post and yours, which I just modified. Thank you.

[BarryB]

You mean CODE Tags, sorry!