| Author: | Lord Crass (guest: search) |
|---|---|---|
| Date: | Sat, Apr 30th, 2011 @ 22:50 ( . ) |
There's a few of the non-working images I've analyzed and here's what I've found: Mainframe: Uses a disk routine that accepts user code (U# commands) to process lower-level disk commands such as sector reads/writes. Uses the drive's job queue to process most of these. It fails when it's told to retrieve track 36 sector 16 and encounters an error 23 (READ ERROR). It retries 4 times and gives up and resets the computer. This is very likely a bad copy or a bad dump. Galaxian (V-Max V4): This one has a non-standard V-Max loader that doesn't force all file loads through the V-Max splash screen program. The code that loads track 20 is also different and it doesn't look for the standard signature on track 20 which marks the beginning of data. It simply looks for byte $37 and then starts reading. Since there are multiple $37 bytes on this track, this might be a track-sync type protection, but it seems to "mostly" work in this case. The loader comes into drive RAM and it all looks good up until it overloads over top of the loading routine, where the instruction pointer is supposed to land on a newly written RTS instruction. The RTS comes in 1 byte out of place, the stack pointer is wrong, and the whole works gets screwed up. Felony! (Thunder Mountain V-Max V3): Same loader as Galaxian, but the track 20 loads in completely corrupted. Can the originals be verified as working and redumped? |
5/20/2011 @ 21:07----Lord Crass 5/21/2011 @ 20:08----------Pete Rittwage --- 0 Users Online --- 0 Recent Unique Posters |