Pseudo disk driver for PIStorm

[dad664npc]

Hi All - If you are not aware, there is development ongoing to get the AMIGA PIStorm working on ATARI ST's. Significant progress has been made. We are at the stage where we can reliably boot and run some (not all) programmes. Memory performance is slow at the moment and there are niggely issues with interrupts. Drop in to Discord to take a look - https://discord.com/channels/7844284613 ... 8668062742

Okay, so that aside, I am trying to write a driver to interface the ATARI to the PIStorm memory. I am at the point where I can load a disk image in to mapped memory on the PI side. I can read/write from/to that memory on the ATARI side.

Now the problem I have is not knowing how to implement a driver. Is it cookie based? I can create a cookie, but then how does the cookie point to the driver? How is the driver loaded in the first place? Is it simply put in the AUTO folder? How are disk drive calls redirected to the new driver? Is it simply pointing system variables (hdv_bpb, hdv_rw, hdv_boot, hdv_mediach) to the driver?

Ideally I would like answers for C as I don't want to have to learn 68K assembler if I can help it :)

Any help is appreciated
Cheers

[alexh]

If it was me I would map it to the HW addresses (and interrupts?) of the Atari ST-Book IDE registers

Write a driver in C as part of the Mushashi emulator running on the PI to convert accesses to the Atari ST-Book address mapped IDE registers into AtariDOS format IDE data originating from Linux directory / HDF file.

There should already be something 90% the same already there for converting accesses to the Amiga Gayle address mapped IDE registers into AmigaDOS format IDE data originating from Linux directory / HDF file.

Then you don't have to write drivers for GEM/TOS just use existing Atari drivers that support Atari ST-Book IDE like HDDriver.

Look to Hatari for inspiration on how AtariDOS / ST-Book IDE work.

There would be a limitation, you'd need a version of TOS with drivers for ST-Book IDE to be able to boot. (Just like you need KS2.05 or later on Amiga)

In Badwolf's PiStorm videos he has a HDD working... I had (wrongly?) assumed he'd done this part of PiSTorm. Perhaps he had a ACSI disk attached.

[alexh]

I can see from the chat on Discord that people are suggesting the same thing.

Why create a custom interface with new drivers when there is already an existing defined interface with drivers?

[dad664npc]

If it's that easy why isn't it done? What am I missing? If I knew how to do it, I wouldn't be posting on here asking for help.

[alexh]

If it's that easy why isn't it done?

Because the only other developer/user is Badwolf?

What am I missing?

I don't know. If you ignore Linux FS mapping and just concentrate on HDF file support that should be easier.

First identify the 680x0 addresses of the Atari ST-Book IDE interface. And their bit-function.

Code: Select all

##############IDE Controller (Falcon, ST-Book, IDE cards)          ###########
-------+-----+-----------------------------------------------------+----------
$F00000|long |Data Register                                        |R/W
$F00005|byte |Error Register                    BIT 7 6 5 4 3 2 1 0|R
       |     |Bad block mark -----------------------' | | | | | | ||
       |     |Uncorrectable error --------------------' | | | | | ||
       |     |Media change -----------------------------' | | | | ||
       |     |ID-Field not found -------------------------' | | | ||
       |     |Media change requested -----------------------' | | ||
       |     |Command aborted --------------------------------' | ||
       |     |Track 0 not found --------------------------------' ||
       |     |DAM not found --------------------------------------'|
$F00009|byte |Sector Count Register                                |W
$F0000D|byte |Sector Number Register                               |W
$F00011|byte |Cylinder Low Register                                |W
$F00015|byte |Cylinder High Register                               |W
$F00019|byte |Drive Head Register                                  |W
$F0001D|byte |Status Register                                      |R
$F0001D|byte |Command Register                                     |W
$F00039|byte |Alternate Status Register                            |R
$F00039|byte |Data Output Register                                 |W

Here is the Hatari ST-Book IDE emulation code and you can see it maps to these addresses and get an idea of their function inside the emulator.

https://git.tuxfamily.org/hatari/hatari ... /src/ide.c

Don't worry too much about the complexity, this is really just for reference if you get stuck.

Here is the equivalent inside Musashi for Gayle IDE (link provided by Claude)

https://github.com/captain-amygdala/pis ... -ide/ide.c

Don't worry about any complexity of the code. You're not going to concentrate on how it works (at first) but rather the differences between the Atari ST-Book IDE registers and the Amiga Gayle IDE registers.

https://www.amigawiki.org/lib/exe/fetch ... cation.pdf

They are both PIO IDE interfaces dating to the same era accessing the same HDDs so underneath they will have very similar form. You can see so many similarities in 2 mins just by looking. Hopefully you can work out how to map from one to the other... (using the Hatari code for reference) then use the existing Musashi code massaged a bit to make it look like an Atari ST-Book IDE interface.

Worst comes to the worst they are 100% completely different and you have to shoe-horn in the Hatari code changing the API from Hatari to Musashi.

Don't worry about AmigaDOS vs AtariDOS formats or anything like that with HDF files. They are just block based devices and the formatting all comes from the host OS.

Claude linked to the program that can generate blank HDF files with geometry.

https://github.com/captain-amygdala/pis ... 9c5787/ide

If I knew how to do it, I wouldn't be posting on here asking for help.

If I had the time and the equipment set up I would help more but I don't have either I'm sorry.