Terrible Fire Accelerators

[PR77]

Originally Posted by plasmab

INTREQR.. it’s literally 2 fast cpu clock cycles slower than INT2 per interrupt... which is sod all on context.

I also assert the IPL lines. You then need to cope with IACK.

Simply asserting IPL lines doesn’t work. Tried on the TF534 Rev 1. There is even a video of this somewhere.

Thanks. The polling was only a question, I didn't think this was being done. I'm really impressed with your TF534 work, excellent job.

P.S., I actually slowed it down my IDE interface to 667Kbyes (delayed /DTACK) and with a DOM it is rock solid.

[plasmab]

Originally Posted by Toni Wilen

Small warning: this hack is probably safe in AmigaOS because exec interrupt handlers check both INTENAR and INTREQR but it can cause bad side-effects in other operating systems (or if program that takes over the system and uses IDE interrupts) which may only check INTREQR and execute the interrupt even when INTENA has matching interrupt bit disabled. Or crash if very unexpected IDE interrupt comes even when INTENA has all interrupts disabled.

Just a little thought on this. You’d have to work very hard to get a crash with the behaviour of the TF534. First you need to have no Interrupt level 2 vector setup. Or a badly behaved one.

Second you’d need to enable interrupts in Gayle but not INTENA. Why would you do this if you didn’t want to handle them.

If your were this paranoid about interrupts you’d be masking them in SR.

Most other 68K OS (Linux, EmuTOS) are not going to have an issue.

[plasmab]

Spent the evening trying in vain to get systest to compile.

It has a bunch of issues with the code that maybe only show up in later versions of gcc. For example it defines a bunch of variables as static.. but those are then shared between modules... which seems like an oversight..

Also have a flight project underway.

EDIT: and as he says it he gets it building..

[hooverphonique]

Originally Posted by plasmab

I’ll patch INTENA on the final version.

But how can you do that? You would need to store whatever is written to INTENA somewhere, and then check there if level 2 is enabled before generating your own interrupt, but even that could fail because INTENA could be written by the copper, and you wouldn't be able to intercept that (I think). EDIT: Seems it would require ECS and CDANG=1 for the copper to access INTENA, so probably not very plausible to happen.

Originally Posted by plasmab

I dislike how Amiga OSes assumes interrupts are off by disabling INTENA though. You should mask them off in SR if you want to be safe. Spurious interrupts do occur.

The IPL bits in the SR set a minimum level to which the cpu responds to interrupts - you cannot mask level 2 off, for instance, without disabling level 1 as well.


Toni is right about lot's of software that takes over the machine will not verify if some interrupt is set in INTENAR/INTREQR in the corresponding ISR, but how often that will cause problems with your INT2 trick, I don't know.

[plasmab]

Originally Posted by hooverphonique

But how can you do that? You would need to store whatever is written to INTENA somewhere, and then check there if level 2 is enabled before generating your own interrupt, but even that could fail because INTENA could be written by the copper, and you wouldn't be able to intercept that (I think).

True. But updating interrupts that way is FUBAR...

Sniffing a write to INTENA and storing the result in the CPLD is trivial.

It’s the best I can do. If you want perfection I’m afraid it’s not possible.

The IPL bits in the SR set a minimum level to which the cpu responds to interrupts - you cannot mask level 2 off, for instance, without disabling level 1 as well.


Toni is right about lot's of software that takes over the machine will not verify if some interrupt is set in INTENAR/INTREQR in the corresponding ISR, but how often that will cause problems with your INT2 trick, I don't know.

Sure. But if they don’t just set a vector to a routine that just RTEs then they’re stupid. Because hardware can jitter and Interrupts do occur on their own.

Plus Gayle had its own completely separate interrupt enable register which i emulate 100%. So the hardware banging software would have to enable/disable INTENA with the copper, deliberately enable the Gayle interrupts and have not bothered to set an interrupt level 2 vector AND THEN manually bang the IDE interface...

Sorry but that’s a stretch and I don’t care about such stupid software. I’ll just list it as incompatible if anyone finds a program that dumb.

Frankly any software hitting the IDE interface on its own (unless it’s an OS or a driver is very dangerous)

[plasmab]

The trade off here is that a handful of badly behaved programs will fail vs people not trying to solder INT2 cables onto A500s, A1000s, CDTVs!!! And A2000s... I’ll take that trade off.

If Toni knows any software that’s a candidate for testing this I’m happy to look into it.

[plasmab]

I have a new version of systest that accesses an unloved hardware register when an error is detected. I can trigger the LA on access to this register and see what’s going on... more later

[alenppc]

Originally Posted by plasmab

Sorry but that’s a stretch and I don’t care about such stupid software. I’ll just list it as incompatible if anyone finds a program that dumb.

Frankly any software hitting the IDE interface on its own (unless it’s an OS or a driver is very dangerous)

Considering that Gayle style IDE device is exclusive to the A600/1200, I would be VERY surprised if such a software existed, so this is all mostly theoretical speculation. Even if a hypothetical Linux kernal mishbehaved, it can be fixed...

[Toni Wilen]

No one modifies INTENA with copper (and if someome does, it surely has nothing to do with PORTS interrupt anyway). It is very common to only check INTREQR (or not check it at all but in case of PORTS interrupt, it would be really bad code because PORTS has multiple different interrupt sources) so using last CPU written INTENA value should make it practically 100% compatible.

[keith]

Hi I found this not sure if it's any help if not then sorry!
https://raw.githubusercontent.com/rk...inimig/Gayle.v

[plasmab]

Originally Posted by keith

Hi I found this not sure if it's any help if not then sorry!
https://raw.githubusercontent.com/rk...inimig/Gayle.v

Gayle isn’t the issue. We have 100% working Gayle with tests and around 1000 users (TF328)..

EDIT: There isn’t actually anything I need to know. It’s just whether I can do what I need to in the confines of the TF534

[shaf]

Silly question, I already have the TF530 wat are the differences between it and the TF534 just an extra 2MB if RAM?

Could I desolder The TF530 and use the Parts for the TF534?

[alenppc]

Originally Posted by shaf

Silly question, I already have the TF530 wat are the differences between it and the TF534 just an extra 2MB if RAM?

Could I desolder The TF530 and use the Parts for the TF534?

No, different ram, different CPLD.

[plasmab]

Update on the ZII ram..

Looks like its managing to occasionally miss a write cycle...

[plasmab]

Yeah i cant see anything wrong.. weird.

[plasmab]

Ah found a possible glitch..

[plasmab]

Ok.. i think i've fixed it...

https://github.com/terriblefire/terr...0_24_alpha.zip

Systest run starting on TF2 shortly.

[plasmab]

Originally Posted by plasmab

Ok.. i think i've fixed it...

https://github.com/terriblefire/terr...0_24_alpha.zip

Systest run starting on TF2 shortly.

Not 100% but an improvement for sure.

[8 Bit Dreams]

Originally Posted by plasmab

Ok.. i think i've fixed it...

https://github.com/terriblefire/terr...0_24_alpha.zip

Systest run starting on TF2 shortly.

Will test and report

[alenppc]

Excellent, I am going to test this after work tonight.