G64 demo "Bounty Bob Strikes Back" problems.

All questions about how to use KryoFlux go here.
Post Reply
User avatar
Modeler
Posts: 20
Joined: Sun Feb 04, 2018 9:49 pm

G64 demo "Bounty Bob Strikes Back" problems.

Post by Modeler » Thu Apr 05, 2018 10:43 am

Hi all,

Apologies for being yet another person to raise an issue while trying to produce a working floppy from g64_demo/BBSB/bbsb.g64, but I think this is an odd one as the disk writes and verifies fine. It just doesn't load on a real C64 / 1541 and I've read posts from other users who have been able to do it.

The point of this just to road-test my set-up. I'm using a Panasonic JU-475 drive (flippy-modded but this isn't a factor) and a brand new, unused floppy disk (KAO branded, new old stock from a good batch). This is the output:

Code: Select all

dan@Mini-110 ~/kryoflux_2.6_linux/dtc $ ./dtc -f../g64_demo/BBSB/bbsb.g64 -w -dd1
Image name: ../g64_demo/BBSB/bbsb.g64
Image type: G64
Image sides: 1
Image tracks: 84
Side 0: td: 1, cf: off, data: 26, unformatted: 58, nfr: 0
Filter mode: side -wg: 3, crosstalk -wk: 3
Side mode: side -g: 0, td -k: 2, flip -wy: 0, flippy -y: 0
Write mode: bias -wb: 0, erase -we: 0
00.0    : Writing G64, trk: 01.0, Big Five
00.0    : Verify: OK
01.0    : Writing G64, trk: 01.5, Big Five
01.0    : Verify: OK
02.0    : Writing G64, trk: 02.0, Big Five
02.0    : Verify: OK
03.0    : Writing G64, trk: 02.5, Big Five
03.0    : Verify: OK
04.0    : Writing G64, trk: 03.0, Big Five
04.0    : Verify: OK
05.0    : Writing G64, trk: 03.5, Big Five
05.0    : Verify: OK
06.0    : Writing G64, trk: 04.0, Big Five
06.0    : Verify: OK
07.0    : Writing G64, trk: 04.5, Big Five
07.0    : Verify: OK
08.0    : Writing G64, trk: 05.0, Big Five
08.0    : Verify: OK
09.0    : Writing G64, trk: 05.5, Big Five
09.0    : Verify: OK
10.0    : Writing G64, trk: 06.0, Big Five
10.0    : Verify: OK
11.0    : Writing G64, trk: 06.5, Big Five
11.0    : Verify: OK
12.0    : Writing G64, trk: 07.0, Big Five
12.0    : Verify: OK
13.0    : Writing G64, trk: 07.5, Big Five
13.0    : Verify: OK
14.0    : Writing G64, trk: 08.0, Big Five
14.0    : Verify: OK
15.0    : Writing G64, trk: 08.5, Big Five
15.0    : Verify: OK
16.0    : Writing G64, trk: 09.0, Big Five
16.0    : Verify: OK
17.0    : Writing G64, trk: 09.5, Big Five
17.0    : Verify: OK
18.0    : Writing G64, trk: 10.0, Big Five
18.0    : Verify: OK
19.0    : Writing G64, trk: 10.5, Big Five
19.0    : Verify: OK
20.0    : Writing G64, trk: 11.0, <unformatted>
21.0    : Writing G64, trk: 11.5, <unformatted>
22.0    : Writing G64, trk: 12.0, GCR Data
22.0    : Verify: <not verified>
23.0    : Writing G64, trk: 12.5, <unformatted>
24.0    : Writing G64, trk: 13.0, Big Five
24.0    : Verify: OK
25.0    : Writing G64, trk: 13.5, <unformatted>
26.0    : Writing G64, trk: 14.0, Big Five
26.0    : Verify: OK
27.0    : Writing G64, trk: 14.5, <unformatted>
28.0    : Writing G64, trk: 15.0, Big Five
28.0    : Verify: OK
29.0    : Writing G64, trk: 15.5, <unformatted>
30.0    : Writing G64, trk: 16.0, Big Five
30.0    : Verify: OK
31.0    : Writing G64, trk: 16.5, <unformatted>
32.0    : Writing G64, trk: 17.0, <unformatted>
33.0    : Writing G64, trk: 17.5, <unformatted>
34.0    : Writing G64, trk: 18.0, CBM DOS
34.0    : Verify: OK
35.0    : Writing G64, trk: 18.5, <unformatted>
36.0    : Writing G64, trk: 19.0, <unformatted>
37.0    : Writing G64, trk: 19.5, <unformatted>
38.0    : Writing G64, trk: 20.0, <unformatted>
39.0    : Writing G64, trk: 20.5, <unformatted>
40.0    : Writing G64, trk: 21.0, <unformatted>
41.0    : Writing G64, trk: 21.5, <unformatted>
42.0    : Writing G64, trk: 22.0, <unformatted>
43.0    : Writing G64, trk: 22.5, <unformatted>
44.0    : Writing G64, trk: 23.0, <unformatted>
45.0    : Writing G64, trk: 23.5, <unformatted>
46.0    : Writing G64, trk: 24.0, <unformatted>
47.0    : Writing G64, trk: 24.5, <unformatted>
48.0    : Writing G64, trk: 25.0, <unformatted>
49.0    : Writing G64, trk: 25.5, <unformatted>
50.0    : Writing G64, trk: 26.0, <unformatted>
51.0    : Writing G64, trk: 26.5, <unformatted>
52.0    : Writing G64, trk: 27.0, <unformatted>
53.0    : Writing G64, trk: 27.5, <unformatted>
54.0    : Writing G64, trk: 28.0, <unformatted>
55.0    : Writing G64, trk: 28.5, <unformatted>
56.0    : Writing G64, trk: 29.0, <unformatted>
57.0    : Writing G64, trk: 29.5, <unformatted>
58.0    : Writing G64, trk: 30.0, <unformatted>
59.0    : Writing G64, trk: 30.5, <unformatted>
60.0    : Writing G64, trk: 31.0, <unformatted>
61.0    : Writing G64, trk: 31.5, <unformatted>
62.0    : Writing G64, trk: 32.0, <unformatted>
63.0    : Writing G64, trk: 32.5, <unformatted>
64.0    : Writing G64, trk: 33.0, <unformatted>
65.0    : Writing G64, trk: 33.5, <unformatted>
66.0    : Writing G64, trk: 34.0, <unformatted>
67.0    : Writing G64, trk: 34.5, <unformatted>
68.0    : Writing G64, trk: 35.0, <unformatted>
69.0    : Writing G64, trk: 35.5, <unformatted>
70.0    : Writing G64, trk: 36.0, <unformatted>
71.0    : Writing G64, trk: 36.5, <unformatted>
72.0    : Writing G64, trk: 37.0, <unformatted>
73.0    : Writing G64, trk: 37.5, <unformatted>
74.0    : Writing G64, trk: 38.0, <unformatted>
75.0    : Writing G64, trk: 38.5, <unformatted>
76.0    : Writing G64, trk: 39.0, <unformatted>
77.0    : Writing G64, trk: 39.5, <unformatted>
78.0    : Writing G64, trk: 40.0, <unformatted>
79.0    : Writing G64, trk: 40.5, <unformatted>
80.0    : Writing G64, trk: 41.0, <unformatted>
81.0    : Writing G64, trk: 41.5, <unformatted>
82.0    : Writing G64, trk: 42.0, <unformatted>
83.0    : Writing G64, trk: 42.5, <unformatted>
So no errors at all but the resulting disk causes my 1541-II to start head-banging, even loading the directory. It does start to load but dies with a checksum error immediately. It's as if my 1541-II is out of alignment, but it loads original disks fine as well as other disks made with KryoFlux. I also own a 1541, VIC-1541 and an Excelerator+, none of which will load it although some get further than others. Oh, and I did write protect the floppy as it was mentioned by IFW as a requirement in another thread.

Could my Panasonic drive be out of alignment? I can create working floppies from other images of protected disks using this set-up though. However, any disks I create directly from stream files end up with errors on them. I'm thinking this is related to the Bounty Bob issue. If my set-up was all good, I wouldn't expect to see these issues. Any help would be appreciated!

User avatar
Modeler
Posts: 20
Joined: Sun Feb 04, 2018 9:49 pm

Re: G64 demo "Bounty Bob Strikes Back" problems.

Post by Modeler » Tue Apr 10, 2018 3:17 pm

I ran this by sncbook2k on the Lemon64 forum (I believe he does post here from time to time), he says:
You have to have a perfectly aligned 1541 to load it from a copy. It always starts with banging the head from the copy. This in my opinion has sopmething to do with writing with a 1.2m head vs a 360k head.

You'll probably see that the G64 even bangs the head in WinVice.
Perhaps finding a 360 KB floppy drive might improve results when writing back DS/DD disks. This has been discussed before though, I'm not sure if there's any mileage in it.

EDIT: It just occurred to me that a 360 KB drive from a PC would probably be unable to write half tracks anyway.

SomeGuy
Posts: 178
Joined: Wed Feb 18, 2015 8:18 pm

Re: G64 demo "Bounty Bob Strikes Back" problems.

Post by SomeGuy » Wed Apr 11, 2018 3:06 pm

Correct, 360k IBM PC drives do not have direct control over the stepper motor and therefore can not step to half tracks. In theory one could use an intentionally out of alignment 360k drive to write specific half tracks, but then there is also the issue that AGC/filtering on 360k drives usually don't seem to like GCR encoding. ( may or may not affect writing).

User avatar
IFW
Posts: 3077
Joined: Mon Nov 08, 2010 2:42 pm

Re: G64 demo "Bounty Bob Strikes Back" problems.

Post by IFW » Thu Apr 12, 2018 5:08 pm

It's part of the copy-protection...
You have to write protect the disk after writing it, otherwise the loader fails with checksum errors.
Usually people who copy a disk don't write protect the copy :lol:

User avatar
IFW
Posts: 3077
Joined: Mon Nov 08, 2010 2:42 pm

Re: G64 demo "Bounty Bob Strikes Back" problems.

Post by IFW » Thu Apr 12, 2018 5:10 pm

...and yes, you need a 96 TPI drive to write this specific disk.

User avatar
IFW
Posts: 3077
Joined: Mon Nov 08, 2010 2:42 pm

Re: G64 demo "Bounty Bob Strikes Back" problems.

Post by IFW » Thu Apr 12, 2018 5:15 pm

If you did write protect the disk and there was no verify error, it's incompatible hardware unfortunately.
It requires an original 1541 drive very well aligned and the machine shouldn't have any additional hardware like SpeedDOS. Cartridges may be no-go as well...
Not to mention CIA type...

User avatar
Modeler
Posts: 20
Joined: Sun Feb 04, 2018 9:49 pm

Re: G64 demo "Bounty Bob Strikes Back" problems.

Post by Modeler » Thu Apr 12, 2018 8:59 pm

IFW wrote:
Thu Apr 12, 2018 5:08 pm
It's part of the copy-protection...
You have to write protect the disk after writing it, otherwise the loader fails with checksum errors.
Usually people who copy a disk don't write protect the copy :lol:
I did write protect it. I've tried it a couple more times in my 1541-II and it varies how far it gets. It got to 11 blocks to go on one attempt.

I have an original 1541 so I'll experiment with that. If the copy is good, maybe it'll make a suitable calibration disk for it? :)

rcade
Posts: 112
Joined: Mon Nov 21, 2011 5:21 pm

Re: G64 demo "Bounty Bob Strikes Back" problems.

Post by rcade » Sat Apr 14, 2018 4:01 am

Due to how the timing works, I bet it likely only works on an original 1541 and not a II.
-
Pete Rittwage
C64 Preservation Project
http://c64preservation.com

hyperactive
Posts: 148
Joined: Sun Jul 01, 2012 5:18 am

Re: G64 demo "Bounty Bob Strikes Back" problems.

Post by hyperactive » Sat Apr 14, 2018 5:21 am

Both the 15x1 drive, and the drive being used to write the g64 out with your KF board, must be near perfectly aligned.
Both my 1541 and 1571 drives do not encounter any issues loading and running the game.
I think the protection scheme is a little more tolerant than you might think. I was quite surprised when both machines (yes, the real ones) loaded the game with no trouble. It also seems to work on an emulated 1541-II.
Altering the CIA2 settings on the emulated machine doesn't seem to stop it from loading either, so I'd say you're good to go.

Post Reply