REV 3 - REV 5 - The beginning (ST536)

[exxos]

When "bit 5" goes low, it should be the same as a IRQ from ACSI pin 10 :shrug: , but still no auto boot :pullhair: @agranlund ??

Yep TOS basically polls address 0x00FFFA01 in a busy-loop until bit5 is zero, like so:

Code: Select all

btst #5,(MFP_GPIP).w

TF536r2 allows the read to reach the motherboard in order to get the full value of that register, then it clears bit 5 and signals ACK.

Why FFFA01 when the register doc says FFFA03 ?

What ACK ? See I'm not sure what happens after the IRQ is issued.. As the ide is waiting for ACK I assume (but how ?) But then I'm totally lost. As the ide needs to put data in the bus , but doesn't the CPU need to to a bus grant first ? But then how does it know its doing a ide access ?! :stars:

I did try to compile your code with the SDRAM module removed but just ended up with corruption as it tried to get to desktop, so no idea what's wrong there. Maybe if I send you my pinout file you could compile your code for me to try on my board to see if ide boots then. You would have to compile to a 144.. Hence removing the SDRAM module as the 144 can't fit your module in it otherwise :(

[agranlund]

Why FFFA01 when the register doc says FFFA03 ?

What ACK ? See I'm not sure what happens after the IRQ is issued.. As the ide is waiting for ACK I assume (but how ?) But then I'm totally lost. As the ide needs to put data in the bus , but doesn't the CPU need to to a bus grant first ? But then how does it know its doing a ide access ?! :stars:

I did try to compile your code with the SDRAM module removed but just ended up with corruption as it tried to get to desktop, so no idea what's wrong there. Maybe if I send you my pinout file you could compile your code for me to try on my board to see if ide boots then. You would have to compile to a 144.. Hence removing the SDRAM module as the 144 can't fit your module in it otherwise :(

Ah, no the IDE is not waiting for anything. It's TOS itself that basically sits in a loop and waits until it's done.
It simply polls the MFP over and over again until it's done :)

The DMA interrupt line is connected to a GPIO pin on the MFP and you can read that from FFFA01

Screenshot 2022-04-16 at 03.56.02.png

The DMA chip has no interrupt capability. Therefore, the end-of-transfer interrupts are generated by the
controllers (the FDC & HDC interrupt outputs are logically OR’ed).
These interrupts are connected to the General Purpose I/O Port, bit 5 and are masked and vectored by the 68901 MFP chip, on interrupt level 7.
If you prefer to poll the status of the interrupt request line you can test the bit 5 of the MFP GPIP
data register (this is what is done by the current TOS software).

So the TF536r2 patching isn't actually generating a real interrupt as such, but because TOS is polling GPIO pin5 instead of actually using interrupts, it works fine to fake the result for that on cpu-reads.

[exxos]

Ah, no the IDE is not waiting for anything. It's TOS itself that basically sits in a loop and waits until it's done.
It simply polls the MFP over and over again until it's done :)

The DMA interrupt line is connected to a GPIO pin on the MFP and you can read that from FFFA01
Screenshot 2022-04-16 at 03.56.02.png).

So is this image wrong then ? https://www.exxosforum.co.uk/forum/viewt ... 460#p83321

Its the same bit bits but listed in FFFA03 ?!

What document are you working from ?

[agranlund]

So is this image wrong then ? https://www.exxosforum.co.uk/forum/viewt ... 460#p83321
Its the same bit bits but listed in FFFA03 ?!
What document are you working from ?

No it's correct, but isn't that register for choosing if an interrupt should trigger on either rising or falling edge?
The actual interrupt status is read from the GPIP register (FFFA01)

I really like this document for all things HDD:
http://info-coach.fr/atari/documents/_m ... amming.pdf

But for this purpose, the sourcecode for TOS206 was really the best one to look at:

Code: Select all

...
MFP_REGS        equ $fffffa01
/* parallel port output - write */
MFP_LPT         equ MFP_REGS+0
/* general purpose - input */
MFP_GPIP        equ MFP_REGS+0
/* active edge register */
MFP_AER         equ MFP_REGS+2
...

Code: Select all

...
after IDE/DMA operation, loop and wait for:
btst      #5,(MFP_GPIP).w           /* interrupt? */
....

[exxos]

I really like this document for all things HDD:
http://info-coach.fr/atari/documents/_m ... amming.pdf

But for this purpose, the sourcecode for TOS206 was really the best one to look at

Ah, my image said FFFA01 was for parallel port data. So no wonder things are not working :roll:

I assume if you forced bit 7 low the machine would reset then ? I can't try anything else until Monday now :(

[agranlund]

Ah, my image said FFFA01 was for parallel port data. So no wonder things are not working :roll:

Yeah the naming wasn't great, though it is technically an 8bit parallel port.
The actual parallel port that has a physical connector at the back of the machine is something else which goes through the YM chip.

I assume if you forced bit 7 low the machine would reset then ? I can't try anything else until Monday now :(

Yeah it might, assuming TOS is looking at that bit to determine if it should reset the machine, and doesn't expect some kind of real interrupt to happen - faking the bit value on a cpu-read only really works if the software is polling instead of reacting to a real interrupt.

I don't know the details for how it determines the monitor change reset thing, I only know how to get rid of the TOS reset function so that it doesn't :)

[ijor]

I assume if you forced bit 7 low the machine would reset then ? I can't try anything else until Monday now :(

Yeah it might, assuming TOS is looking at that bit to determine if it should reset the machine, and doesn't expect some kind of real interrupt to happen - faking the bit value on a cpu-read only really works if the software is polling instead of reacting to a real interrupt.

I don't know the details for how it determines the monitor change reset thing, I only know how to get rid of the TOS reset function so that it doesn't :)

TOS records the monitor type at startup, and at the vertical blank it checks if that MFP bit changed. If that bit indicates the monitor changed, it forces a reset by default. But the reset is forced through a vector that can be intercepted and replaced.

[exxos]

I gave it one last try before I remove this project off my desk.

I changed the address to FFFA01. But this made no odds. Looking at TOS206 sources, it is actually accessing FFFFFA01 as a word. So peaking in STOS I changed it so that the word or byte access to either address flips bit 5 low. This definitely works in flipping the bit, but still makes no odds for IDE autobooting.

I also found I had a pulldown on IDEINT on the 536. I think it was supposed to be a pull up. Not had time to check properly but I swapped that anyway. Still no odds.

I added pullups on the databus because when the ST bus is isolated, the lines are floating otherwise. While bit 5 is low, the other lines were not all high. I thought this could cause a problem. Adding the pullups had no effect either.

So either I am doing something incredibly dumb or there is something more to getting this working,Or the idea simply just does not work. Either way I am out of ideas now and not really sure its worth spending the effort on it.

It still boots fine with the "pin 10 wire" and EMUTOS autoboots fine anyway.

[ijor]

I changed the address to FFFA01. But this made no odds. Looking at TOS206 sources, it is actually accessing FFFFFA01 as a word.

Are you saying that TOS 2.06 is accessing the MFP as word? Where do you see that?

[exxos]

Are you saying that TOS 2.06 is accessing the MFP as word? Where do you see that?

Code: Select all

...
after IDE/DMA operation, loop and wait for:
btst      #5,(MFP_GPIP).w           /* interrupt? */
....

I took the assumption that "W" meant Word access. But I don't know anything about assembly. So rather than waiting for someone to confirm,I just tried the fix on byte and word access. It made no difference anyway.