Greetings,
I thought I'd break the habit of a lifetime and give a little bit of information on the latest emulation work.
So, first up a tiny little confession.. I've actually had the disk that's now under emulation for as long as I have had the Attack of the Mutant Camels Konix Source. The disk was labelled LN2 Konix EXE, so I had a suspicion what it was, however at the time I had no real way to dig into its contents -- unlike the other floppies which were PC formatted, this was somewhat different. My first attempts at getting data off it involved using an amiga 1200 and an MFM reader.. Unfortunately no matter which way I looked at the data, I couldn't make sense of it.
Fast forward to January last year, and I received some additional floppies (the ones used to reconstruct the Flare One boot disk). In order to read those, I ended up purchasing a KyroFlux
http://www.kryoflux.com/, and at that time I made a complete Flux dump of the "mystery" disk in the hopes of shedding some light on it. After all, at this stage all I knew was what the label told me, it could have been unformatted :
The infomation I had at the time, was that a Konix Floppy would store its save games on Track 0, and the rest of the disk would be used for program code (1 sector per track). The first track on the image was definately empty (although not unformatted :
Since the first track was for save data, this isn't surprising.. although it meant i had no clue where the boot block might have lived.... My suspicion was track 1 (however side 0 looked empty), side 1 however :
At the time it felt like the disk could well be konix format, but Flare One work and real life got in the way.
Fast forward to earlier this month and the discovery of possibly another real konix floppy disk, I decided to take another look at that mystery floppy. Now as luck would have it, along with the Flare One stuff I received, I also had a folder called BOOTROM - which looked very much like it might be the Konix BIOS intended for the production system. It took a couple of days, mostly because it turned out the hardware was different between the 8088 and the 8086 version, but I had it running under emulation (and it helped find a bug in the blitter hardware):
At this point, I was confident that if I could decode the disk data, there was a good chance it would boot.
The problem of course was that I still hadn't been able to decode a sector from the disk. Data on a floppy disk is stored as a stream of bits (simplified view - its actually a series of magnetic flux reversals), the problem all floppy controllers have is given a stream of bits moving under the head -- how do you know where the start of the sector is?
There are a few encoding schemes for doing this - MFM being the most common on 3.5 inch media. Documentation I had also seemed to confirm MFM. MFM essentially encodes a byte as a word (2 bytes) of data with the clock interleaved into it. The clever bit is that this encoding means certain words can't occur in a stream of real of data -- The amiga used 0x4489 IIRC to mark the start of a sector. This means the controller can simply watch the stream of bits until 0x4489 appears and then know its correctly aligned to the sector start.
It turns out in the case of the Konix, the disk controller was simplified significantly, in fact the way the start of a sector is found, is by using the index pulse that the drive generates once at the start of a revolution of the disk. And more importantly it turns out that the sync start point was actually defined by a normal data byte (not MFM encoded word). Thanks to the fact that the konix has 2 checksum bytes at the end of every sector and the knowledge gleamed from the bios on the probable sector length - I finally managed to dump some bytes from the boot block yesterday, and confirm they were executable code. So last night I dumped the full disk image and after fixing a subtle bug in the floppy emulation, was surprised by LN2 loading!
The BIOS also revealed that track 0 was re-purposed as some form of security (copy protection) -- where save games are supposed to go is a mystery at this time, the protect scheme makes use of the DSP, and at present fails - so i have a patch in the BIOS to ignore it for the time being.
Apologies for the wall of text.
TLDR; I did some archaeology and made something cool
Login
Register
FAQ
Search
