[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Latent Advanced Demuffin 1.1 bug
- Subject: Latent Advanced Demuffin 1.1 bug
- From: Hot Rod <hotrod.apple2@gmail.com>
- Date: Tue, 24 Jul 2012 21:20:22 -0700 (PDT)
- Bytes: 3529
- Complaints-to: groups-abuse@google.com
- Injection-info: glegroupsg2000goo.googlegroups.com; posting-host=75.73.130.159; posting-account=NsBJFwoAAACliuoc2Cfykslw7D5NuJ4-
- Newsgroups: comp.sys.apple2
- Organization: http://groups.google.com
- User-agent: G2/1.0
Greetings,
I don't know if anyone still has cause to use Advanced Demuffin much anymore, but back in the day, it was a main tool used to normalize disks (aka 'crack'). Back in 1986, I happened across a bug in it, wrote it down, and never opted to fix it.
I had reason to dust it off and use it again this week, and wouldn't you know it - I hit that same darn bug again (which of course I'd forgotten all about).
The gist of it is that Advanced Demuffin loads IOBs and RWTS files by reading the first sector of the file into memory at a page offset of #$FC (e.g. $13FC for an IOB, or $B5FC for an RWTS or wherever the page is set to). So if you set the page to load an RWTS as B6, it would read the first sector starting at $B5FC, not actually $B600.
It does this because the first four bytes of the first sector of a file contain the address and length of the file, and so then the first bytes of the actual file will then start on the next page boundary (e.g. $1400, $B600).
This wouldn't be so bad (although you could clobber four bytes you weren't expecting on the page preceeding what you thought was the start), except that in doing this, it fails to read the LAST four bytes of the file.
The routine that transfers the sector data into the target page is at $15C2. It stores data using the Y-reg as offset, starting at Y=0 and incrementing to 0 again. The problem is that the base address is always the $xxFC address (obtained indirectly via $3E.$3F as lo-byte/hi-byte). So when Y = 0 again, the last address stored to is only $xxFB, and $xxFC.$xxFF (the last four bytes) never get stored.
So if the RWTS you're loading has critical data in those last four bytes (like say, the read translate table), it will create all sorts of problems trying to convert a disk. This is exactly the issue I hit in 1986, and then again this week.
Fixing it would be possible, but cumbersome, as there's no really good patch space inline. One approach would be to relocate the routine that's at $15C2 (e.g. move it out to $1D00) and patch it with an extra loop that just gets those last four bytes. Might make a good 1.2 version.
Anyway, I wanted to mention it so at least a reference to the info existed.
Anyone end up with a copy of The Stack's source code?
]HR