homebrew IDE interface

[DamageX]

One of the good things about being in 2020 is the ease of getting custom PCBs. I made my first ISA card last summer and for the next round I decided to try a zorro slot card for my A2000.

I tried to rework the A500IDE project from aminet into a zorro card, using the same addressing scheme so that the same driver would work. I used a pair of 74ls138 instead of the '688 because I already had some and didn't want to pay the shipping cost to get a '688 here just to build the prototype. I found out that the A2000 motherboard doesn't allow cards to use the reserved $Dxxxxx space though, so I had to change it to use the autoconfig space even though it is not autoconfig capable. It is now $82xxxx and I patched the driver to use the new address.

At first I couldn't figure out how to mount or format the drive with ide.device even though the identify utility correctly returned the disk info (after patching the addresses in it, and disabling the '030 data cache anyway). But then I found this link with a newer version of the ide.device http://nuclear.mutantstargoat.com/hw/amiga/a500hdd/files/

This is one is funny because it uses a fully unrolled loop (256 copies) of MOVE instructions to read/write sectors. Only 16-bit moves though, as back-to-back accesses caused by 32-bit moves supposedly caused data loss (I wonder if only certain HDDs may be affected?). After patching this one, I am up and running with my trusty old Quantum Fireball CR6. Data transfer speed is measuring up to 2.1MB/sec. I copied the entire contents of my 260MB SCSI over to the IDE and haven't seen any errors so far.

I have never used the FAT95 driver before but if that can also work with this type of interface it could be very convenient indeed.

How do drivers normally deal with memory-mapped I/O vs. the CPU data cache on Amiga? I did a little research on this and didn't find any good solution short of monkeying with the MMU. Disabling and then re-enabling the data cache every time the driver is called seems like it would be a huge time waster? I also found out that '030s have a write-allocate mode and that Amiga uses this for some reason (?)

The other thing I am wondering about is patching the motherboard ROM to make this a bootable device (ie. insert the driver into kickstart). Has anyone done this before? I saw a page that mentioned someone had patched in an A600 scsi.device to use an A600-compatible (like Gayle or whatever) IDE interface on an A500. Of course this one needs a different driver than that but I like the idea of using a modified motherboard ROM, since putting a boot ROM onto a zorro card doesn't seem to be possible without implementing autoconfig.

[psxphill]

How do drivers normally deal with memory-mapped I/O vs. the CPU data cache on Amiga?

Use Zorro II I/O space (0xa00000), instead of RAM space

I saw a page that mentioned someone had patched in an A600 scsi.device to use an A600-compatible (like Gayle or whatever) IDE interface on an A500. Of course this one needs a different driver than that but I like the idea of using a modified motherboard ROM, since putting a boot ROM onto a zorro card doesn't seem to be possible without implementing autoconfig.

You can boot from diagnostic rom 0xf00000, I think that is possible from a zorro 2 slot.

However you're dangerously in territory where you might as well implement autoconfig, and then people might actually want one.

[DamageX]

And what is special about $A00000? It's marked reserved for A2000s on this table https://www.amigacoding.com/index.php/Amiga_memory_map

Thinking further about my system, switching off the '030 data cache temporarily doesn't seem to be a big deal after all. If the driver is called to transfer each sector, and the fastest rate is around 2MB/sec, that is 4000 sectors per second at worst. So 4000 times per second the cache would be switched off and on. It's write-through so it doesn't need to be flushed. Writing a sector will have thrashed it anyway (as would reading if write-allocate is enabled) so nothing relevant to other tasks remains stored when the driver returns.

[psxphill]

And what is special about $A00000? It's marked reserved for A2000s on this table https://www.amigacoding.com/index.php/Amiga_memory_map

It's marked correctly in the official documentation.

http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node00D4.html

$00A0 0000 - $00B7 FFFF       Zorro II I/O Expansion Space

You could also try, although you'll need to avoid the configuration registers.

$00E8 0000 - $0EFF FFFF       Zorro II I/O & Configuration

What is special about it, is that because it's for I/O the MMU mapping will be set to non cache-able for that range. Because you never want to cache I/O.

Writing a sector will have thrashed it anyway (as would reading if write-allocate is enabled) so nothing relevant to other tasks remains stored when the driver returns.

I don't know, that is a big assumption and multitasking can make these things way more complicated. Or are you disabling interrupts as well?

[DamageX]

On pages 32 and 44 of the A500 A2000 Technical Reference Manual it describes the collision detection logic. Slave is not allowed to go low for these address regions:
0-$1FFFFF
$A00000-$BFFFFF
$C00000-$DFFFFF
$E00000-$E7FFFF
$F80000-$FFFFFF

So I am still skeptical about the possibility of $A00000. Maybe it changed between early A2000 boards and later ones or A3000?

You could also try, although you'll need to avoid the configuration registers.

$00E8 0000 - $0EFF FFFF       Zorro II I/O & Configuration

Possibly. If autoconfig boards are always assigned beginning with $E9 then $EF should be open except in extreme circumstances...

I don't know, that is a big assumption and multitasking can make these things way more complicated. Or are you disabling interrupts as well?

That's a good point, I don't know if the driver disables interrupts. I haven't picked it apart to that extent.

I was able to create a FAT32 partition on my Quantum Fireball and then mount it with FAT95 on the Amiga. I now have a means of transferring files to the Amiga that is far superior to RS232. Here is the mountlist:

Code: [Select]

FRE: device=ide.device
filesystem=L:FAT95
stacksize=4096
blocksize=512
activate=1
unit=0
flags=0
surfaces=1
blockspertrack=1
interleave=0
lowcyl=0
highcyl=1
buffers=100
globvec=-1
bufmemtype=1
dostype=0x46415401
mount=1
#

[psxphill]

On pages 32 and 44 of the A500 A2000 Technical Reference Manual it describes the collision detection logic. Slave is not allowed to go low for these address regions:

Unless you assert OVR. That extra range for IO might be on the A3000 and later.

You're also not supposed to hard code addresses, so I didn't think you wanted to do anything legally anyway.

[DamageX]

I've been looking into putting the driver into kickstart or into a ROM on one of the other zorro bus cards I have. Does kickstart copy the contents of byte-wide ROMs (only connected to half the bus) to RAM to execute them? ie. so that 16-bit ROM or latches/waitstates aren't needed? And after the system is booted how can I find out the entry point of a card ROM as specified in the card's autoconfig registers?

I had some other thoughts on mapping the I/O ports to $DA0000. What happens if you assert DOE instead of SLAVE? It's not clear what DOE is for. Or, my most devious plan yet... how about lifting the BERR pin on buster and then the cops can't stop you from using any address space you like??

edit: does anyone have a binary of the program described here? https://wiki.amigaos.net/wiki/Amiga_Hardware_Manufacturer_ID_Registry

edit2: To answer part of this... I found that on a 64K board I was still able to read autoconfig registers after the system is up and running, or at least up to $2E. Reading too far caused an instant crash. But skipping ahead to where the card's ROM was located it was clearly only connected to the high byte (even addresses)