| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Thu, May 12th, 2011 @ 22:06 ( . ) |
I looked at the loader for Altered Beast and Turbo Out Run, and they are basically the same. The disk ID labels it as "SLOAD" (Sega-Load? Super-Load? Stolen-Load?) The loader is a decent fast-loader that reads standard CBM DOS sectors, but how it's stored and loaded in is the interesting part. It's either licensed or lifted from V-Max 3. The only difference is that the DOS is stored on track 38 or 36 instead of 20 and the byte sequence it looks for to signal the start of data on this track is different. For Altered Beast it is: 77 A9 E3 95 C5 A5 95 A5 95 A5 95 A5 95 A5 95 99 B3 For Turbo Out Run, it's $77 and then the byte sequence decodes to "SLOAD01T" before reading in the loader. |
 | Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Fri, May 13th, 2011 @ 00:29 ( . ) |
smartload by waffer blitware! |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Tue, Sep 18th, 2012 @ 01:19 ( . ) |
Ah. This explains why I can't get the protection to pass after writing the game to disk. I even tried using the -px vmax switch but it's still no go. It works on vice and it also runs with the SPS version. Is there a switch or combination I can use to write it back so that it will load? |
 | Author: | Pete Rittwage (registered user: 558 posts ) |
|---|---|---|
| Date: | Tue, Sep 18th, 2012 @ 08:12 ( . ) |
I've gotten copies to work before, but it's been years. You'd have to experiment with the different alignments (-a) on the protection track (38?). |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Tue, Sep 18th, 2012 @ 19:30 ( . ) |
I have. Using nibtools rev 560, I've tried -aw, -as, -ag and -a0 but they don't seem to work. Later this afternoon I'll try the same thing using an old copy of mnib. Cheers. |
| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Wed, Sep 19th, 2012 @ 22:25 ( . ) |
Statistically, you're unlikely to get a working copy of this track without modifying the g64 image before writing it back. After the header signature, there's a number of dummy pages worth of data that get read in and the checksum is verified for each. The track tends to get read by nibtools so that this signature appears near the end of the track. Vice has no problem with this because it loops back to the beginning of the track data with no break in the data stream. When you write it back to disk, the end of the track will be the gap, which contains junk. As the loader reads across this, the checksum will fail because this extra data is not expected. You can fix the image by cutting the bottom part of the track (starting at the header I mentioned in the first email) and pasting it back at the top of the track in the image file. Then when you write it back to disk, none of that data will be interrupted by the gap. That's the theory, anyway. It's also why it's important to know where the start of the track is, and when to stop writing. Nibtools makes an attempt to find the start, but in cases like this it has no way of knowing, unless this track happens to align with the index hole (have you tried this?) |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Thu, Sep 20th, 2012 @ 01:38 ( . ) |
No because I don't have an IHS. |
| Author: | hyper active (registered user: 296 posts ) |
|---|---|---|
| Date: | Thu, Sep 20th, 2012 @ 03:10 ( . ) |
that worked, but you must first make sure tracks 36-40 are unformatted and then set the drive motor to 299.60 rpm, then write them back with automatic GCR reduction turned off. Get the drive speed wrong and the track won't load and you'll have to start over. timing is critical. |