Baremetal Amiga Emulator

[Toni Wilen]

Originally Posted by bloodline

Do you have the file spec for the extended ADF?

(from disk.c)

/* UAE-1ADF (ADF_EXT2)
* W reserved
* W number of tracks (default 2*80=160)
*
* W reserved
* W type, 0=normal AmigaDOS track, 1 = raw MFM (upper byte = disk revolutions - 1)
* L available space for track in bytes (must be even)
* L track length in bits
*/

[coder76]

Originally Posted by Toni Wilen

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.

Yes, but I think leaving DMA support out here was a good idea, as decoding an MFM track doesn't take a long time anyway, probably less than 1/50 s judging on data amount. This gives flexibility to handle different formats, as the coding/decoding is not hardcoded anywhere. The Amiga should also be able to support GCR format, which packs more data on a track than MFM, although loading goes slower. One can also decode MFM tracks without $4489 syncmarker, looking for syncmarks slows down the reading. This makes decoding data trickier again. One can also choose to read half tracks instead of whole tracks via cia controlled diskside. Don't know if its any use, but some games also loaded like this.

[bloodline]

Originally Posted by Toni Wilen

(from disk.c)

/* UAE-1ADF (ADF_EXT2)
* W reserved
* W number of tracks (default 2*80=160)
*
* W reserved
* W type, 0=normal AmigaDOS track, 1 = raw MFM (upper byte = disk revolutions - 1)
* L available space for track in bytes (must be even)
* L track length in bits
*/

Perfect, many thanks

[Gorf]

For coding/decoding data via blitter in in Amiga-MFM format, this may be helpful:

http://aminet.net/package/util/pack/Blitter

This Utility could be used to code files to an format,which is necessary
for decoding datas,which are loaded with an own Trackloader.These Datas
can be decoded EASY AND FAST with the BLITTER ! But the Datas must be
saved in the MFM-Format on Disk before decoding !

I'll give the instruction how to decode the datas in your own sourcecode.

[bloodline]

I've tried my own build extended ADF in WinUAE and it doesn't work, so I was correct, my code is defective...

[Toni Wilen]

Originally Posted by coder76

Yes, but I think leaving DMA support out here was a good idea, as decoding an MFM track doesn't take a long time anyway, probably less than 1/50 s judging on data amount. This gives flexibility to handle different formats, as the coding/decoding is not hardcoded anywhere. The Amiga should also be able to support GCR format, which packs more data on a track than MFM, although loading goes slower. One can also decode MFM tracks without $4489 syncmarker, looking for syncmarks slows down the reading. This makes decoding data trickier again. One can also choose to read half tracks instead of whole tracks via cia controlled diskside. Don't know if its any use, but some games also loaded like this.

Yeah, it made it flexible but if it had (optional) hardware MFM encoding/decoding, it would have been possible to use HD disks without ugly rotational speed hacks.. (Of course correct fix would have been Paula 16bit -> 32bit upgrade when AGA was designed but it didn't happen)

[bloodline]

Originally Posted by bloodline

I've tried my own build extended ADF in WinUAE and it doesn't work, so I was correct, my code is defective...

I just tried the rawread produced extended ADF files in WiniUAE 3.6.0 (under wine), and they don't boot either

[Toni Wilen]

Originally Posted by bloodline

I just tried the rawread produced extended ADF files in WiniUAE 3.6.0 (under wine), and they don't boot either

There is no guarantee rawread works reliably, especially with amigados tracks that are mostly empty, it probably chose bad splice point...

[bloodline]

Originally Posted by Toni Wilen

There is no guarantee rawread works reliably, especially with amigados tracks that are mostly empty, it probably chose bad splice point...

That's good to know, I will keep trying until I get one that works. I will then be able to use that as a "known good" image.

[Toni Wilen]

I just added command line option to winuae (winuae.7z, you should be able to find the complete url..), -rawextadf that forces writing of all tracks, even if it decodes to amigados, as raw data.

Create extended adf, format it in emulation: you have valid extedended adf, all tracks in original undecoded format.

[bloodline]

Originally Posted by Toni Wilen

I just added command line option to winuae (winuae.7z, you should be able to find the complete url..), -rawextadf that forces writing of all tracks, even if it decodes to amigados, as raw data.

Create extended adf, format it in emulation: you have valid extedended adf, all tracks in original undecoded format.

That is brilliant!

[NorthWay]

Originally Posted by Toni Wilen

not much more than a PLL + bi-directional 16-bit parallel/serial converter + few CIA software controllable IO lines.

Wouldn't an _optional_ MFM decoder just have been a few wires and some selector logic?

[Gorf]

Originally Posted by NorthWay

Wouldn't an _optional_ MFM decoder just have been a few wires and some selector logic?

that was my thinking as well. But you need probably some extra logic to read/write these "illegal" MFM-code sync-markers and gaps....
But probably nothing a cheap 6502-variant could not handle back than - or some Arduino Nano could now.

PS:
the CSG 4510 "Victor" was a 65EC02 with two CIAs in one chip-package;
used in the CDTV-II prototype as well as in the C65 prototype.
That one would have made good match to provide hd-floppys for Amiga and even save space/costs on the board.

[bloodline]

Originally Posted by Toni Wilen

I just added command line option to winuae (winuae.7z, you should be able to find the complete url..), -rawextadf that forces writing of all tracks, even if it decodes to amigados, as raw data.

Create extended adf, format it in emulation: you have valid extedended adf, all tracks in original undecoded format.

Just confirming that the -rawextadf option works as expected and does produce a vaild mfm image.

I really appreciate the support. I will try this with my emulator over the weekend.

-edit- I couldn't resist trying to feed in the raw mfm data into my disk DMA as produced by Toni's modified winUAE... amazingly it boots (after loading track 0 it then steps up to track 40 - as expected, this is where the root is located and continues to boot) then crashes... I will have to investigate at the weekend.

[Gorf]

Ok, here comes the next (maybe) useful link:

http://amigadrive.blogspot.de

This guy programmed his raspi to act like a real Amiga floppy drive - also bare-metal without a linux-kernel!

So it reads from sd-card (FAT) and encodes correctly to Amiga-MFM - and the other way as well.

[bloodline]

This might qualify as one of the most boring screenshots in history... But (not visible in a static shot) the power LED is flashing and a Guru is in progress

I think my floppy emulation is still not quite right, because the OS keeps trying to load cylinder 40 (track 80) over and over, it clearly can't seem to read the root dir.

-edit- It appear that when CIAB prb bit 2 is high the upper surface is selected (this appears to be counter to the HRM)...

[bloodline]

A Mac build if you want to try at home.

A bootable adf is included in the archive. command line arguments:

zorro <kickstart rom> <bootable raw extended adf>

When you see the "insert workbench" screen hit the "a" key to insert the loaded disk.

[bloodline]

My Emulator as "progressed" to the point that the Guru works properly now... I really hope this will help debugging.

Anyone here good with KS1.2 guru numbers?

[emufan]

Originally Posted by bloodline

My Emulator as "progressed" to the point that the Guru works properly now... I really hope this will help debugging.

nice progress

Anyone here good with KS1.2 guru numbers?

Amigalove website has an informative article:
Guru Meditation Errors - How to Read Them

[bloodline]

Originally Posted by emufan

nice progress

Amigalove website has an informative article:
Guru Meditation Errors - How to Read Them

If I've read this correctly, intuition seems to think my emulation is crap This is unsurprising... I will try harder.