Baremetal Amiga Emulator

[hooverphonique]

Originally Posted by bloodline

For some reason, even though I have tried to emulate 4 floppy drives, only the internal drive has it's drive head stepped from track 0 to 1 and then back again (about every 10 seconds, how do the other drives signal to the amiga they are present on the system?), this appears to be based on an interrupt generated by CIAA. Full Debugging output is provided via command line.

Additional drives are detected by the OS by clocking the SEL line 32 times and looking at the pulse train coming out of the RDY line (this is one of the reasons you need extra hw to connect an external drive). These pulse trains are pretty simple (like $00000000, $ffffffff, $aaaaaaaa and $55555555).

[bloodline]

Originally Posted by hooverphonique

Additional drives are detected by the OS by clocking the SEL line 32 times and looking at the pulse train coming out of the RDY line (this is one of the reasons you need extra hw to connect an external drive). These pulse trains are pretty simple (like $00000000, $ffffffff, $aaaaaaaa and $55555555).

Excellent, I wandered why the drive select lines were being rapidly pulsed during boot! Cheers, I can easily get the emulated drives to respond correctly if I need them.

[bloodline]

Originally Posted by kolla

Are you kidding, this is mighty entertaining and fun!

Just a silly idea I've had, throwing it out there... UAE as an EFI loadable, taking over the system at boot time.

This is essentially my idea. But my plan was to only have the bare minimum hardware emulation to get the OS into a usable state.

I think I have achieved this for KS1.2, it only needs the CIAs (for the timers) an the interrupt hardware.

But I want to boot KS3.0 so I can emulate the IDE for booting and direct that to the real mass storage hardware. KS3 is more tricky so I am implementing more of the hardware emulation to see what is going wrong, and it's really good fun!

[bloodline]

Originally Posted by Toni Wilen

Yes, it should work under KS 1.x trackdisk.device because it does not use word sync mode. (AFAIK because code was made before word sync hardware existed/worked, it was rewritten for KS 2.x)

Ok, I fed the output of rawread into my disk DMA (cutting off the 2004byte header), and after 5,984 MFM words have been read into memory, I generate a DSKBLK interrupt.

The OS then turns the disk motor off... all good! After a few seconds the emulator Gurus

I must be missing something

-edit- My address calculation was off, I now read in 7358 MFM words (as requested in dsklen) starting the address specified by dskpt... when I generate a dskblk int at this point the OS starts to randomly read memory... So I must be nuking something important in ram :-|

-edit 2- I found another bug, I was halving the address in dskpt (because my earlier implementation addressed the memory as words), now that is fixed, the MFM track loads fine and the blitter is fired up! let's see where this rabbit hole leads :-D

[bloodline]

Observing this more... it seems the track is loaded into ram, the blitter operates upon it, the result is garbage* (I am observing the memory pointed by channel D)... the OS tries again, and again, and again... same result... it steps the head to track 1 and then back to 0,and tries a further 4 times... since the result is meaningless each time it just fails... eventually the OS just gives up, switches the drive motor off and stops working.

Not ideal, but definitely progress

-Edit- Conveniently to OS makes Long write to bltbmod register when it is using the blitter for floppy disk work, which makes trapping that call rather easy.

*Actually not garbage, but what appears to be encoded MFM data... I assumed the blitter was supposed to be helping decode the data...

[hooverphonique]

Very interesting to follow, this thread is

Originally Posted by bloodline

*Actually not garbage, but what appears to be encoded MFM data... I assumed the blitter was supposed to be helping decode the data...

yes, those old kickstart versions (1.2, 1.3) do use the blitter for mfm decoding..

[Gorf]

This baremetal-emu is a very interesting idea!
Hope you can finish this project one day.

The thread here is also very interesting to read and gives some insight to how things were done on our beloved Amiga.

The MFM-encoding thing rises a question in my head:
What if C= (or some third party) would have added some small controller to the floppy-ports of the CIA (let's say a 65CE02) to do the MFM decoding already there?
This would reduce the transmitted data by roughly 50% - or double the max. speed.

Wouldn't that have been a nice way to hook HD-floppy-drives to the Amiga without modifying Paula?

[phx]

Originally Posted by Gorf

What if C= (or some third party) would have added some small controller to the floppy-ports of the CIA (let's say a 65CE02) to do the MFM decoding already there?

The CIAs only connect to some control and status lines, like step, head-selection, motor on/off, drive select, write-protect, etc. Paula reads and writes the actual track data (usually by DMA).

Wouldn't that have been a nice way

No. The Amiga would have lost much of its flexibility to deal with all kinds of disk formats. This would be similar to a PC floppy controller, which is quite restricted.

[bloodline]

Originally Posted by Gorf

This baremetal-emu is a very interesting idea!
Hope you can finish this project one day.

It started as a project to fill my time, while off work, looking after my daughter... but has become something of an obsession

The thread here is also very interesting to read and gives some insight to how things were done on our beloved Amiga.

The MFM-encoding thing rises a question in my head:
What if C= (or some third party) would have added some small controller to the floppy-ports of the CIA (let's say a 65CE02) to do the MFM decoding already there?
This would reduce the transmitted data by roughly 50% - or double the max. speed.

Wouldn't that have been a nice way to hook HD-floppy-drives to the Amiga without modifying Paula?

Everything about the Amiga appears to be about cutting costs, the CIAs for example are a poor fit into the Amiga's architecture, but Commodore obviously had these things by the shipping container load... so they stuck a couple in the Amiga for timers and to handle the serial, parallel, keyboard and floppy drive (control signals only). they are the Amiga equivalent of the the "South bridge" found in the IBM PC (by analogy, Agnus is essentially the North Bridge).

Hooking the floppy drive data output up to Paula and doing the MFM decoding in software is a classic case of money saving, I think if you were to add any more hardware to the Amiga to handle floppy disks, you would just add a proper floppy controller chip. it would be much cheaper and simpler than trying to stick another chip in the middle of the current process.

[Gorf]

Originally Posted by bloodline

Hooking the floppy drive data output up to Paula and doing the MFM decoding in software is a classic case of money saving, I think if you were to add any more hardware to the Amiga to handle floppy disks, you would just add a proper floppy controller chip. it would be much cheaper and simpler than trying to stick another chip in the middle of the current process.

Well, that design was already done by HiToro ... i once saw an interview with the guy responsible for Paula, Ron Nicholson: he was not that experienced compared to the others in the team, and just "made it work".

a new controller would probably break compatibility for all the strange formats games used to work with - and since Nicholson left very early and documentation was non-existent, Paula stayed a mystery till the end...

that's where my idea comes in: for dd-floppies you would use Paula as always ignoring your additional controller - for hd-floppies a 6502-like thingy (that C= already had) does the decoding and saves bandwidth....


Back to your Emulator:
you could do maybe the same in emulation and deliver already decoded-content into chipram (even for dd), so no need for emu-blitter or emu-cpu to do the heavy work.
(of course you would have to disable the decoding function in kickstart in this case)

[bloodline]

Originally Posted by Gorf

Well, that design was already done by HiToro ... i once saw an interview with the guy responsible for Paula, Ron Nicholson: he was not that experienced compared to the others in the team, and just "made it work".

a new controller would probably break compatibility for all the strange formats games used to work with - and since Nicholson left very early and documentation was non-existent, Paula stayed a mystery till the end...

that's where my idea comes in: for dd-floppies you would use Paula as always ignoring your additional controller - for hd-floppies a 6502-like thingy (that C= already had) does the decoding and saves bandwidth....


Back to your Emulator:
you could do maybe the same in emulation and deliver already decoded-content into chipram (even for dd), so no need for emu-blitter or emu-cpu to do the heavy work.
(of course you would have to disable the decoding function in kickstart in this case)

It would be simple enough to replace the trackdisk.device with one which didn't bother about mfm decoding. But you would need some way of loading it... or building a new 1.2/1.3 rom with a custom trackdisk...

It would certainly make my life easier if I didn't need to encode everything before I sent it to the disk DMA... but then it would be much easier if I didn't have to support the Cylinder, surface, sector geometry as well and just have a block interface, which is why I plan to support the Gayle IDE interface, which is just that, a proper "modern" disk interface. At which point you can dump the floppy and just use KS3.0

[Gorf]

Originally Posted by bloodline

It would be simple enough to replace the trackdisk.device with one which didn't bother about mfm decoding. But you would need some way of loading it... or building a new 1.2/1.3 rom with a custom trackdisk...

Well, there is the famous track salve patch (with source):
http://aminet.net/package/disk/misc/TrackSalve

with some modifications...

which is why I plan to support the Gayle IDE interface, which is just that, a proper "modern" disk interface. At which point you can dump the floppy and just use KS3.0

that sounds reasonable!

[bloodline]

Ok, I tried running rawread again on the same (Workbench 1.3) disk and predictably (if I've understood Toni correctly) have a different disk image, but this one is totally unreadable by my Emulator.

To understand exactly what is going wrong with my code I think we need to work through a bit of theory and see where my mental model deviates from reality.

First the low level disk structure:

The disk is divided up into 80 cylinders, i.e. Concentric rings starting at the outer edge of the disk moving in towards the centre of the disk.

Each cylinder has a lower and an upper surface.

Each cylinder surface (henceforth known as a track) is then divided into 11 sectors (there is also apparently a "gap area" here dividing the first and last sector, but I'm not concerned about that right now). A sector is 544 data bytes (actual low level format data, not mfm code, not Amiga file system data) in size.

If we do the maths 80*2*11*544 (cylinders*surfaces*sectors*bytes), that comes to 957,440 data bytes.

The first 32bytes of data in each sector is low level format data (aka the header), the remaining 512bytes is the actual data available to the filesystem.

Another quick calculation (80*2*11*512) gives us the Amiga's formatted capacity of 901,120 bytes!

The low level format sector header:

//Sector Sync
uint8_t 0x0;
uint8_t 0x0;
uint8_t 0xA1; // not really 0xA1 as this will have a missing clock bit in MFM code
uint8_t 0xA1; // as above

//Sector Info
uint8_t 0xFF; // Amiga disk identification
uint8_t 0xXX; // Track number = (cylinderNumber * 2) + surface number <0 or 1>
uint8_t 0xXX; // sector number (0 to 10)
uint8_t 0xXX; // countdown to track end (11 to 1)

//Sector label, apparently unused and always 0
uint32_t label0 0x0;
uint32_t label1 0x0;
uint32_t label2 0x0;
uint32_t label3 0x0;

//Header checksum... using the XOR algorithm from Track Salve
uint32_t hChecksum 0xXXXXXXXX;

//Data checksum... as above
uint32_t dChecksum 0xXXXXXXXX;

//Data block
uint8_t block[512];

This all seems quite straightforward, and I have already written a function which takes an ADF and spits out a file with this structure.

Now comes the bit that seems to be causing problems.

MFM:

This is a simple encoding scheme, each single data bit of a data stream as two mfm bits. The least significant bit is the same as the data bit, the most significant bit is position dependant...

1 -> 01
0 -> 00 (if the preceding data but was a 1)
0 -> 10 (if the preceding data bit was also 0)

Following the above scheme it is really simple to encode a data stream into mfm code.

But the Amiga being the Amiga, it's not that simple. The odd and even bits are arranged separately, which is actually a pretty clever way to allow quick decoding simply by masking, shifting the odd bits and then ORing them together (all operations the blitter can do).

An ordinary byte: STSTSTST encoded in this scheme looks like this (where S are the odd bits and T are the even bits:

To encode the odd section first shift right by one place:

0STSTSTS

Then "AND" with 0x55 to remove the original even bits, resulting in 0S0S0S0S

The even section is simply the original byte AND with 0x55. So the byte encoded on disks a word which looks like this:

0S0S0S0S0T0T0T0T

The Amiga's scheme is a bit more complex, as the odd bits are all encoded as a single block followed by the even bits.

I then run a loop over the encoded data to add the correct mfm clocking bits where appropriate.

Now, when the track disk device requests a track of data from the floppy it is provided with 11 sectors of this data (5984 words) followed by 320+ words of 0xAA to simulate the gap between the first sector and the last.

But it seems, the trackdisk.device is not fooled by this...

[mark_k]

Do you "wrap around" the MFM data? Trackdisk will start reading (probably) when the head is in the middle of a sector's data. It reads more than one revolution in order to ensure all sectors are unbroken/complete in the track buffer.

[bloodline]

Originally Posted by mark_k

Do you "wrap around" the MFM data? Trackdisk will start reading (probably) when the head is in the middle of a sector's data. It reads more than one revolution in order to ensure all sectors are unbroken/complete in the track buffer.

Yes, if the word counter goes above 6319, it just wraps back around the the start of the track.

[Toni Wilen]

trackdisk.device won't care if all reads start from "beginning" of track. Real floppy position does not need to be emulated. Only some custom track loaders need it.

[bloodline]

Originally Posted by Toni Wilen

trackdisk.device won't care if all reads start from "beginning" of track. Real floppy position does not need to be emulated. Only some custom track loaders need it.

Exactly, so I must producing garbage data... is there any way I could feed my data into UAE... Perhaps package it in the adf format produced by rawread?

[coder76]

I don't think that the Amiga floppy hardware is poorly designed. It is more flexible than the PC floppy controller, Amiga can read 720 kb DOS disks, but the PC disk drive can't read Amiga formatted disks. Also, some games like SWIV and Ninja Warriors are able to read from disk during gameplay (without slowing down action) on an A500, so the disk system isn't too slow or poorly integrated with interrupts either. I haven't seen any other computer being able to do that.

[Toni Wilen]

Originally Posted by bloodline

Exactly, so I must producing garbage data... is there any way I could feed my data into UAE... Perhaps package it in the adf format produced by rawread?

Probably easiest way.

Originally Posted by coder76

I don't think that the Amiga floppy hardware is poorly designed. It is more flexible than the PC floppy controller, Amiga can read 720 kb DOS disks, but the PC disk drive can't read Amiga formatted disks. Also, some games like SWIV and Ninja Warriors are able to read from disk during gameplay (without slowing down action) on an A500, so the disk system isn't too slow or poorly integrated with interrupts either. I haven't seen any other computer being able to do that.

PC floppy controller uses DMA and does not need CPU to transfer data (Amiga needs CPU power or blitter for MFM decoding). It is just historic software reasons (BIOS/DOS) that it works like it does and no one bothered because everyone had a HD, floppy was only used for data transfer.

Hardwired format requirement is practically the only real limit, in all other situations it is better than Amiga floppy "controller". It is only flexible because it is so simple, not much more than a PLL + bi-directional 16-bit parallel/serial converter + few CIA software controllable IO lines.

[bloodline]

Originally Posted by Toni Wilen

Probably easiest way.

Do you have the file spec for the extended ADF?