REV 3 - REV 5 - The beginning (ST536)

[DaveC]

The address length is a word and the CPU extends FA01 to FFFFFA01. CPU would throw errors trying to access words or longs on an odd address.

[ijor]

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.

Oh, I see. That "w" is about the addressing mode, not about the width of the data. But yes, from the point of view of the hardware, it should be correct to react also on word access, because a real MFP would not care as long as it is still enabled.

I'm afraid I am not too familiar the the IDE interface, neither with the TF536, to be more helpful with the specific issue. But may I suggest you perform some simulations? FPGA (or CPLD) simulations might sometimes involve quite some work to setup, but they are worth.

[agranlund]

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.

The .w in this case means that it's treating the address as a word, to reduce the code size by a tiny margin.
It basically does "btst #5,$FA01"
(and $FA01 becomes sign extended to $FFFFFA01)

Patching motherboard-reads does work on the old TF536:
It does something like this when it detect a read from FFFFFA01 (* or 00FFFA01, both are equally valid from Atari software point of view)

• Open bus to motherboard and let it handle the read request

• Wait until DTACK from motherboard (don't let it reach CPU) and we have the data from the motherboard.

• Isolate bus from motherboard again.

• Patch data bit 5 depending on the IDE irq signal (on the old TF536 that bit is simply AND'ed with the IDE_IRQ signal)

• Now that we are done, and have patched the data, signal DSACK to the CPU

(*) This is why it'll be important to consider both variations wherever you compare register addresses in the firmware. Old software may use either 00xxxxxx or FFxxxxxx to access the same thing.
The easiest is to just convert all FFxxxxxx into 00xxxxxx at the top level so you don't have to bother anywhere else.
(Also a reason why 32bit Ataris must use a CPU that has an MMU. TOS3+4 sets it up to cover this particular dilemma, and maprom.prg does the same for TOS206)

[exxos]

• Open bus to motherboard and let it handle the read request

• Wait until DTACK from motherboard (don't let it reach CPU) and we have the data from the motherboard.

• Isolate bus from motherboard again.

• Patch data bit 5 depending on the IDE irq signal (on the old TF536 that bit is simply AND'ed with the IDE_IRQ signal)

• Now that we are done, and have patched the data, signal DSACK to the CPU

.....

Yeah but I don't do that exactly as I am out of LA's in the PLD. As by default they are all 1's ( at least on my machine) I just isolate the ST bus and drive bit 5 low to the CPU and leave it at that. All the other bits are pulled high on the TF536.

Granted it would need more work because of MONO on bit 7.. But for the time being is not actually important.

So bit 5 goes low..

IMG_0477.JPG

This image was taken before doing the "word fix". But in either access bit 5 goes low now.

The only other changes was to put a clause for IDEINT into the patch code. I had to remove that part to confirm it works in STOS..

So bit 5 definitely goes low.. And yet IDE still refuses to AutoBoot. It works fine if I attach the IDENIT wire to ACSI pin 10 like normal. So it's not the card at fault AFAIK.

:shrug:

[agranlund]

But for the time being is not actually important.

Yeah that's fair and makes sense for testing it.

Granted it would need more work because of MONO on bit 7..

Mono, and the other bits too :)
Bit4 is read in the TOS ACIA interrupt handler, Bit0 for printer related stuff.
And of course, it checks Bit5 for Floppy/ASCI/SCSI irq status too so it'll need the original value patched rather than replaced.

[ijor]

Yeah but I don't do that exactly as I am out of LA's in the PLD.

Did you check the timing analysis report? When the device is full the compiler might struggle to meet timing. This is assuming the design is properly time constrained, otherwise it should.

[agranlund]

Silly question perhaps, and probably just grasping at straws :)
But could IDEINT high/low be wrong in your patch code?
IDEINT as it comes from the IDE hardware, is opposite from the Atari DMA interrupts. I believe it's active high.

Had a look at the original TF and Bit5 is AND'ed with the inverted IDEINT.

wire IDE_INTERRUPT = ~IDEINT;

IDE_INTERRUPT is the value that is AND'ed with the original Bit5, basically putting the bit to 0 when the IDE device pulls its interrupt line high.

[exxos]

Did you check the timing analysis report? When the device is full the compiler might struggle to meet timing. This is assuming the design is properly time constrained, otherwise it should.

I haven't but, as STOS reports the correct value then it *should* be ok.

..
wire IDE_INTERRUPT = ~IDEINT;
IDE_INTERRUPT is the value that is AND'ed with the original Bit5, basically putting the bit to 0 when the IDE device pulls its interrupt line high.

It certainly qualifies under "dumb stuff I might have done". But it is inverted. I even tried it both ways just to be sure.

I tried thinking backwards on this problem and tried to break it from working with the ACSI pin 10 wire.. Basically just isolated the whole bus on FFFA01 so they all be 1's.. and the feker still booted. :roll:

[Badwolf]

I'm not sure, from the snippets I've seen, that you are matching the 'shadow' register at 0xFFFFFA01, as Anders says.

Your tests are all on the 32-bit address (00FFFA01), but we've just seen in the TOS source that TOS uses the 32 bit address FFFFFA01.

What does STOS peek say when you use the 'shadow' (top byte = FF) register?

BW

[exxos]

@Badwolf I did wonder about the 32bit thing as well. Though it's why I only match 24 bits currently so it should always match. But don't forget I only have 29 address bits as well..

I have that many versions of this code now :roll:

Code: Select all

localparam PATCH_ADDRESS = 24'hfffa01; 
wire BUSEN_INTREQR = (A[29:0] != PATCH_ADDRESS) | AS30 | ~RW30  ;

So at $FFFA01 I get "233" as expected.

$FFFFFA01 I get "255". So "nothing there" :roll: So my code isn't working for the address TOS may actually be looking at then :roll: I did try at one point earlier trying to decode FFFFFA01 but made no odds either.