exxos's Atari, Amiga & retro forum

I sent this yesterday to exxos but really this should be an open discussion. Lets start with the facts.

TF536 has an IDE interface but i cant make it work out of the box on a TOS2.06 machine (or lower). I seem to need EmuTOS to make it work. The IDE interface can easily be placed at 0xF00000 and the appropriate address lines setup.

Now onto the Rumor:-

If the IDE interrupt is patched over to the ACSI interrupt then IDE will work on 2.06. True?

Now on to my possible solution... If the above is true.

The TF536 can inject any interrupt level, handle the ack, and patch up the register that gets read. This trick is done to make IDE plug and play on the Amiga 500. I wonder if it could be done on the Atari too.? How it works...

It does the usual interrupt and interrupt ack cycles on the board. No great shakes there.. but the TF536 can do a man in the middle on a 16 bit wide register.. The read cycle starts and the correct data comes form the system.. its latched by the cpld and the DTACK is masked off... then the system is held in a read cycle while the bus buffers between the 030 and system go high impedance and the CPLD places patched data on the bus. Then an acknowledge is sent. This is all tested and working. We can do this with any address. Dont' argue about the mechanics of this its done and dusted.

But with this system It should mean we can make the system think there is an interrupt pending without a patch wire just like on a A500 with a TF534/TF536.

The information missing to complete this puzzle is which address is read for the interrupt status and which bits need to be set/unset to make the system think this interrupt is pending.

@terriblefire not sure if this is of use for you?

http://ftp.lip6.fr/pub/atari/Docs/hardware.txt

I've had several ST IDE interfaces. One from Alan Hourihane for the STE, both of exxos interfaces, and PPeras Megabus interface.

Every last one needs the patch lead to the ACSI interface using either TOS 2.06 or TOS 1.04 patched to allow IDE boot, so if there's a way to plug and play it, it'd be good to see.

So are you saying that it doesn't need the patch cable to work with Emutos?

Interesting.

rubber_jonnie wrote: 28 May 2020 20:37 I've had several ST IDE interfaces. One from Alan Hourihane for the STE, both of exxos interfaces, and PPeras Megabus interface.

Every last one needs the patch lead to the ACSI interface usingeeither TOS 2.06 or TOS 1.04 patched toaallow IDE boot, so if there's a way to plug and play it, it'd be good to see.

So are you saying that it doesn't need the patch cable to work with Emutos?

Interesting.

I've never had the patch wire with EmuTOS. and it does work. The TF534 and TF536 are designed to allow chipset register patch up on the fly. So if someone can explain how that works so that the software doesnt think its a "spurious" interrupt we're generating it may indeed be possible.

PhilC wrote: 28 May 2020 20:15 @terriblefire not sure if this is of use for you?

http://ftp.lip6.fr/pub/atari/Docs/hardware.txt

I cant see anything that specifically manifests as a change in a register in there.

Wouldn't this be it ?

$00011C|ST-MFP-7 - FDC/HDC

MFP FDC/HDD on the same MFP pin...

That is what i am talking about. Perfect thanks.

terriblefire wrote: 28 May 2020 23:21 I cant see anything that specifically manifests as a change in a register in there.

It appears Atari TOS just busy loops while checking bit 5 of the MFP Active Edge Register (mapped to 0xFFFA03) to determine when done, so I recon it's worth a shot man-in-the-middle change that one?

Snippet from Atari TOS sources, it does this type of thing after IDE operations.

idestat1:
btst #5,(MFP_GPIP).w /* interrupt? */
beq.s idestat2 /* if so, out of the loop */
cmp.l (_hz_200).w,d0 /* time-out? */
bhi.s idestat1 /* if not, wait some more */


I don't know if there could be any other issues if you simply just man-in-the-middle that register?
Atari TOS at least doesn't seem to care about an actual interrupt here, as far as I can tell it doesn't have an interrupt handler for this and instead just busy waits on that bit immediatly after sending IDE commands..



The IDE irq signal goes into the 68901 chip (called the MFP). From there I believe it goes to the GLUE (or MMU?) and then into the 68000 as IPL6 I believe.
The 68000 itself does not keep track or tries to figure out where to jump for the interrupt, the 68901 jumps the 68000 to the correct offset, based on what MFP interrupt ocured, in a table that normally starts at $100 (the table base can be changed from code)

Here's a pretty good article about irq, and mfp-irq:
https://www.atarimagazines.com/v5n2/Exc ... rupts.html

Also the Atari memory map:
http://deunstg.free.fr/sct1/hardware.htm

agranlund wrote: 29 May 2020 00:46 I don't know if there could be any other issues if you simply just man-in-the-middle that register?
Atari TOS at least doesn't seem to care about an actual interrupt here, as far as I can tell it doesn't have an interrupt handler for this and instead just busy waits on that bit immediatly after sending IDE commands..

That is exceptionally useful and could definitely be MIM'd Could even be done without asserting the IPL lines if you are correct.

agranlund wrote: 29 May 2020 00:46
The IDE irq signal goes into the 68901 chip (called the MFP). From there I believe it goes to the GLUE (or MMU?) and then into the 68000 as IPL6 I believe.
The 68000 itself does not keep track or tries to figure out where to jump for the interrupt, the 68901 jumps the 68000 to the correct offset, based on what MFP interrupt ocured, in a table that normally starts at $100 (the table base can be changed from code)

Here's a pretty good article about irq, and mfp-irq:
https://www.atarimagazines.com/v5n2/Exc ... rupts.html

Also the Atari memory map:
http://deunstg.free.fr/sct1/hardware.htm

I have a pretty good understanding of the ST interrupt system. Here is a functional FPGA ST built by me a few years ago.

https://github.com/terriblefire/atlys_atarist

Major parts of the MFP live on in MiST.

Now I'm confused as of what adress it actually waits for.. I need to go to sleep :)

In a hurry I was assuming it is:
$FFFA03|byte |Active Edge Register BIT 7 6 5 4 . 2 1 0|R/W

..but it does look like it's FFFA01 since this is the code it does:
btst #5,(MFP_GPIP).w


The defines are:
MFP_REGS equ $fffffa01
MFP_LPT equ MFP_REGS+0
MFP_GPIP equ MFP_REGS+0
MFP_AER equ MFP_REGS+2