NOTE: I today tried running with a 14.18Mhz crystal - thinking that maybe I was experiencing a clock domain issue by trying 16Mhz previously... That made no difference at all. So there's either a fault on the FPU side, or something is incorrect regards software side / configuration. If you have any ideas on what might be going on with the FPU on this card, please let me know!
On the Amiga Hardware Database, there are a couple advertisements for this accelerator. The second advertisement actually shows the FPU installed, and they have pin 1 is located in the upper left corner of the socket, instead of the bottom right corner.
I think either those are wrong, or a different revision PCB! I've double checked the pinout on the socket in relation to ground and chip selects and I am sure they are correct.
Somehow UA-cam ate my additional comment on this card, so here we go again...as mentioned, I had the same card (the Tornado, not the Mach 2). I used it in an Amiga 500 with ECS chipset, Kickstart 2.0, 1MB chipram and 1.5MB slowram in the trapdoor. That ram card required an additional cpu adapter to support more than 0.5MB in that slot. So I stacked that adapter and the Tornado. The keyboard didn't fit anymore, so a taped it to the case from the outside and routed the keyboard cable through a hole in the top of the case. Looked strange, but worked fine. I can't remember if I had to fiddle around with the jumpers, but I do remember that I had a switch attached to the card to "disable" it. Actually, you can't fully disable it. It's always running at 14MHz. All you can do is to disable the cache. But that, you can do on the fly while the machine is running. Without the cache, Sysinfo shows these 10% speedup and ~12Mhz. Only with cache enabled, it shows higher speeds and ~14Mhz. The actual performance increase of the card in a system without real fastram in real applications is around 75%. I used the card for gaming (3d flight sims), 3d rendering, painting (DPaint), coding and compiling and I actually really liked it.
I was thinking exactly this! I seen he placed a 68882 in the board but the software was trying to detect a 68881. I cant remember if they are interchangeable with a 68000?
This was an interesting vid indeed. I may have even retained some of the architecture details you shared - will have to wait til the next morning to see if that is the case lol, I have such a bad memory. I enjoy the deep dives you do as to why / how, and the compatibility levels later on down the line. Thanks Gadge :)
I had this card back in the days to speed up my Amiga 500. I really liked (and somehow still do...) the idea of caching instead of sticking additional fast RAM onto the board, because this way, it speeds up access to data in the chip memory (and ranger RAM...) as well. I used it for several years but then I must have tossed it for some reason. Now, I'm looking for one on eBay but none came up in months...😢
Hmmm. I never seen this before Chris. I enjoy the Commodore Amiga for sure. But this happens to be the first time seeing anything like this. Thank you Chris, I learned something new today. 8^) Anthony..
It's actually quite difficult to get any speed improvements unless you have direct bus support from the glue logic, which of course these accelerators do not. External caches are a cool idea, but pale in comparison to a CPU with an internal cache. Just for the heck of it, I modified WinUAE to allow a unified 2-way cache with the 68000 processor at 14MHz. The results are pretty interesting. Running code out of chip RAM, a 256 byte cache barely gets 10% improvement, while a 512 byte cache approaches 50% improvement (similarly, the 68020 is *really* crippled by its tiny 256 byte cache). Data caching doesn't work at all with chip RAM, but with slow RAM, icache results are fantastic, and dcache improvements are in excess of 30%. With the 512 byte unified configuration, icache hit rates are about 85% and dcache is about 75%. I've tested up to 16K of cache, but with the code I've tried, you get serious diminishing returns above 512 bytes, so I consider that the sweet spot. Assuming all code is running out of slow RAM, my SysInfo benchmark with the 512 byte cache @ 14 MHz is 3.08, and AIBB is around 2.20. If there had been a 68000 with a proper internal cache, and used 3 clocks for a cache hit rather than 4 for a full memory access, it would have performance roughly matching a stock A1200. I know, this is unrelated to the video... but messing around with emulation is still fun. 8)
I had the same card in my A500. If you remove the A590, the card works at 14 MHz. With a GPV HDD the card also works at 14 MHz. It is due to the addressing of the memory on the A590. Disable the A590 ram expansion or that of the Tornado.
It'd be interesting to see if it uses the FC lines from the 68000 to just cache code rather than data. There's a good chance it does just code data caching rather than data to give some useful cache coherence with such a small cache.
Supra Turbo 28. The funny thing is, every photo of that accelerator I've seen has the CPU's markings sanded off, because I believe it uses a 20 MHz CMOS version of the CPU.
NOTE: I today tried running with a 14.18Mhz crystal - thinking that maybe I was experiencing a clock domain issue by trying 16Mhz previously... That made no difference at all. So there's either a fault on the FPU side, or something is incorrect regards software side / configuration. If you have any ideas on what might be going on with the FPU on this card, please let me know!
On the Amiga Hardware Database, there are a couple advertisements for this accelerator. The second advertisement actually shows the FPU installed, and they have pin 1 is located in the upper left corner of the socket, instead of the bottom right corner.
I think either those are wrong, or a different revision PCB! I've double checked the pinout on the socket in relation to ground and chip selects and I am sure they are correct.
@@GadgetUK164 Hahaha, the story just gets weirder :)
Somehow UA-cam ate my additional comment on this card, so here we go again...as mentioned, I had the same card (the Tornado, not the Mach 2). I used it in an Amiga 500 with ECS chipset, Kickstart 2.0, 1MB chipram and 1.5MB slowram in the trapdoor. That ram card required an additional cpu adapter to support more than 0.5MB in that slot. So I stacked that adapter and the Tornado. The keyboard didn't fit anymore, so a taped it to the case from the outside and routed the keyboard cable through a hole in the top of the case. Looked strange, but worked fine.
I can't remember if I had to fiddle around with the jumpers, but I do remember that I had a switch attached to the card to "disable" it. Actually, you can't fully disable it. It's always running at 14MHz. All you can do is to disable the cache. But that, you can do on the fly while the machine is running.
Without the cache, Sysinfo shows these 10% speedup and ~12Mhz. Only with cache enabled, it shows higher speeds and ~14Mhz. The actual performance increase of the card in a system without real fastram in real applications is around 75%. I used the card for gaming (3d flight sims), 3d rendering, painting (DPaint), coding and compiling and I actually really liked it.
That might be what the middle jumper does now I think about it!
I think FPU should be 68881 not 68882, give it a try and might find it will work.
I was thinking exactly this! I seen he placed a 68882 in the board but the software was trying to detect a 68881. I cant remember if they are interchangeable with a 68000?
I tried a 68881 - they are technically the same tbh, just the 68882 is faster at a particular function I think.
@@GadgetUK164 Okay, thought it might have been that, but at lease you know it's not that has the issue.
This was an interesting vid indeed. I may have even retained some of the architecture details you shared - will have to wait til the next morning to see if that is the case lol, I have such a bad memory. I enjoy the deep dives you do as to why / how, and the compatibility levels later on down the line. Thanks Gadge :)
Cheers mate =D
I had this card back in the days to speed up my Amiga 500. I really liked (and somehow still do...) the idea of caching instead of sticking additional fast RAM onto the board, because this way, it speeds up access to data in the chip memory (and ranger RAM...) as well. I used it for several years but then I must have tossed it for some reason. Now, I'm looking for one on eBay but none came up in months...😢
Great puzzle-solving in this one!
Hmmm. I never seen this before Chris. I enjoy the Commodore Amiga for sure. But this happens to be the first time seeing anything like this.
Thank you Chris, I learned something new today. 8^)
Anthony..
It's actually quite difficult to get any speed improvements unless you have direct bus support from the glue logic, which of course these accelerators do not. External caches are a cool idea, but pale in comparison to a CPU with an internal cache.
Just for the heck of it, I modified WinUAE to allow a unified 2-way cache with the 68000 processor at 14MHz. The results are pretty interesting. Running code out of chip RAM, a 256 byte cache barely gets 10% improvement, while a 512 byte cache approaches 50% improvement (similarly, the 68020 is *really* crippled by its tiny 256 byte cache). Data caching doesn't work at all with chip RAM, but with slow RAM, icache results are fantastic, and dcache improvements are in excess of 30%. With the 512 byte unified configuration, icache hit rates are about 85% and dcache is about 75%. I've tested up to 16K of cache, but with the code I've tried, you get serious diminishing returns above 512 bytes, so I consider that the sweet spot.
Assuming all code is running out of slow RAM, my SysInfo benchmark with the 512 byte cache @ 14 MHz is 3.08, and AIBB is around 2.20. If there had been a 68000 with a proper internal cache, and used 3 clocks for a cache hit rather than 4 for a full memory access, it would have performance roughly matching a stock A1200.
I know, this is unrelated to the video... but messing around with emulation is still fun. 8)
I had the same card in my A500. If you remove the A590, the card works at 14 MHz. With a GPV HDD the card also works at 14 MHz. It is due to the addressing of the memory on the A590. Disable the A590 ram expansion or that of the Tornado.
It'd be interesting to see if it uses the FC lines from the 68000 to just cache code rather than data. There's a good chance it does just code data caching rather than data to give some useful cache coherence with such a small cache.
I never thought about that at all!!! That's a very good point!
I seem to recall an accelerator with a 28MHz 68000 fitted, but I can't remember what it was called.
Supra Turbo 28. The funny thing is, every photo of that accelerator I've seen has the CPU's markings sanded off, because I believe it uses a 20 MHz CMOS version of the CPU.
Fascinating......As Mr spock would say...
N x
That cup!
Haha =D Yes, it was well past its cleaning date lol