-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
SE/30 DiiMO accelerator cloning
- Thread starter Bolle
- Start date
Weird, works with other cards just fine. I'd recommend giving it another try because it shouldn't be any different putting a Control Panel in Extensions, other than it loads sooner. System doesn't care.
Another thing to try is in the System Folder itself.
I'm not fussed about it - the custom extension approach of enabling via a 'scri' type extension works even better since it loads so early. Cheesestraws thinks it's somewhere around the welcome to macintosh screen, which is before all the really CPU heavy stuff starts happening. Shaves another 5 seconds or so off boot time.
Ah awesome, that's a nice solution. It always bugs me how much stuff happens before the Sonnet Nubus extension loads.
It's before the first piece of text is drawn, which is "Welcome to Macintosh", because loadable writing systems have to be loaded before any text is displayed. That's why they're loaded first.
No, but the bit of code that reads the preferences that the user set in the control panel might, if it's not particularly well written. I've come across control panels before that assume that if they're loaded they're in the control panels folder.
Fair enough, I was assuming that era needed to work in Sys 6 and Sys 7, so hard coded paths would cause more obvious issues like the MIDI extension.
The DiiMO CP is a bit weird. The state of its two preferences are stored as a resource in the CP itself. It's got two paths for enable/disable cache - both via an INIT and also at runtime, immediately when you check or uncheck the cache checkbox. SANE patches are only applied at boot time.
The CP has no other function, no patches to mitigate functional issues like other some other accels require. Since the Diimo is functionally transparent, FreeBSD and A/UX are fine with it as it just acts like a roided out 68030.
The CP has no other function, no patches to mitigate functional issues like other some other accels require. Since the Diimo is functionally transparent, FreeBSD and A/UX are fine with it as it just acts like a roided out 68030.
I've circled back to the musing from this post and have successfully moved the 12 GALs of logic into a single ATF1508 CPLD. It still needs some work to ensure stability to allow for a production version (if I decide to make them), but the major components are fully functional so far including 128KB of cache instead of 64.
This would work in SE/30, IIcx, IIx. I like the idea of a compact version which fits in the PDS slot (with a passthrough) for SE/30 or IIsi, but there's still a lot going on here, even without the GALs... probably won't happen.
This primarily serves as a (second) POC that it's possible to move logic from a collection of GALs into CUPL and the ATF150x fairly directly. There are definitely timing considerations to watch out for, but I knew the Diimo design to be fairly lax about the speed ratings of its PLDs: I've swapped most of them from 10ns ATFs to 3ns GALs (with stops at 10ns, 7ns, 5ns) and only managed to provoke a couple of issues. However, other designs like the PowerCache and GAL-based Turbo040 are more fiddly about their speed ratings, so those will probably be less easily translated...
I thought it'd be interesting to make up a diagram showing the relationships between nodes as I work on understanding the logic further.
Interactive version here: https://public.flourish.studio/visualisation/20222546/
PDS_CTL is system AS, DS, BERR, DSACK etc.
LOCAL_CTL are same signals but on the card's local bus only.
Buffer_CTL controls the buffers which selectively tie the local 50mhz bus to the system bus.
Cache controls operation of the cache logic.
Logic is the here-be-dragons stuff mostly that glues the various functional groups together.
Buffer_Bus is simply the local address/data busses.
Clocks are either the 50mhz or 16mhz clocks.
This would work in SE/30, IIcx, IIx. I like the idea of a compact version which fits in the PDS slot (with a passthrough) for SE/30 or IIsi, but there's still a lot going on here, even without the GALs... probably won't happen.
This primarily serves as a (second) POC that it's possible to move logic from a collection of GALs into CUPL and the ATF150x fairly directly. There are definitely timing considerations to watch out for, but I knew the Diimo design to be fairly lax about the speed ratings of its PLDs: I've swapped most of them from 10ns ATFs to 3ns GALs (with stops at 10ns, 7ns, 5ns) and only managed to provoke a couple of issues. However, other designs like the PowerCache and GAL-based Turbo040 are more fiddly about their speed ratings, so those will probably be less easily translated...
I thought it'd be interesting to make up a diagram showing the relationships between nodes as I work on understanding the logic further.
Interactive version here: https://public.flourish.studio/visualisation/20222546/
PDS_CTL is system AS, DS, BERR, DSACK etc.
LOCAL_CTL are same signals but on the card's local bus only.
Buffer_CTL controls the buffers which selectively tie the local 50mhz bus to the system bus.
Cache controls operation of the cache logic.
Logic is the here-be-dragons stuff mostly that glues the various functional groups together.
Buffer_Bus is simply the local address/data busses.
Clocks are either the 50mhz or 16mhz clocks.
Dear Santa Claus, I know what I want for Christmas.
I'll second that motion from superjer2000!
Always did want one of the DIIMO Accelerators. Thanks for your continuing additions ZigZagJoe!
We'll see! I still need to chase some issues preventing full speed operation, but I'd really like make something cool with the Diimo as it's the reason I'm here in the first place 
The original 64kb cache Diimo is ever so slightly faster than the powercache, with the additional 64kb on mine it ought to be the fastest 68030 accelerator out there. Admittedly, it's not a night and day difference, as the benefit of the additional 64kb is situational depending on data layout - but hey, Ill take it!
The original 64kb cache Diimo is ever so slightly faster than the powercache, with the additional 64kb on mine it ought to be the fastest 68030 accelerator out there. Admittedly, it's not a night and day difference, as the benefit of the additional 64kb is situational depending on data layout - but hey, Ill take it!
Nice! I’m guessing you have both a QFP ‘030 and CPLD under that heatsink?
Yep, there's a QFP CPU under a heatsink then an ATF1508 on the reverse of the PCB.
Unfortunately this project has been backburnered as I was finding an issue with 16 bit accesses locking the logic up. I've found some tricks while working on a 040 clock doubler design though which may have some impact on the issues I was seeing here with the Atmel fitter. Also a potential avenue for timing analysis which has been perpetual problem for me.
@zigzagjoe one possible reason why MicroMac halved the FPU speed is they were cheaping out and using lower rated 68030/68882s. They put MicroMac stickers on top of them so you couldn't tell what they were actually rated for. My (non-SE30) Diimo has 40mhz versions that were older rev/steppings and maybe older process node than the latest rev C that we have easy access to now. Maybe the earlier rev 882s were more sensitive to overclocking than the 030s?
Last edited:
Yep. Quite possible. I've found it's a bit of a crapshoot with the 1C12R FPUs if they can successfully operate at 50mhz or not. Guess they decided to go for false advertising instead rather than use properly rated chips.
Well, in a fit of pique I decided to tackle this again and I've already got some promising results. With a minor tweak I seem to have got the issues I was having previously to work, at least on simple test cases. Previously, synchronous termination or 16 bit asynch cycles had a chance to deadlock the internal logic.
I'm afraid of how much work it's going to take to validate the logic as fully functional though. The logic inside this thing is nightmarish, I'm not sure I'll ever be able to fully understand and "digest" it. It's not the most fun to assemble either, but at least less of a pain without any GALs to deal with.
I've recently become a convert for test headers. So much easier and more reliable than a forest of test clips. The particular snapping sound they make when they lose their grip also automatically pisses me off, too...
I'm afraid of how much work it's going to take to validate the logic as fully functional though. The logic inside this thing is nightmarish, I'm not sure I'll ever be able to fully understand and "digest" it. It's not the most fun to assemble either, but at least less of a pain without any GALs to deal with.
I've recently become a convert for test headers. So much easier and more reliable than a forest of test clips. The particular snapping sound they make when they lose their grip also automatically pisses me off, too...
Last edited:
What's your favourite type of test header? I tend to prefer the type you've got in your picture when necessary, or an on-board set of test traces that terminate at a rail (populated or not) when it can be designed in. That snapping sound used to make me flinch, but eventually just moved to increasing the fatalistic sense of doom that something was going to eventually fly off and land in the wrong place, releasing the magic smoke.
And while JTAG headers have their place in theory, those have ALWAYS frustrated me in practice.
Normally I try to design in at least a few SMD test points for unused pins or signals I may need to probe, or to allow for future experimentation/bodgery using an existing design. If I'm designing in a header I prefer to have a 2xwhatever IDC header, where one side is all grounds and the other is signals. Like below on my nubus prototype. Each of the leads for my LA has a ground and the more of those that are populated, the better, and they're mandatory for clocks.
If I have to bodge it on and expect to need to do a lot of probing I'll end up with something like the prior picture using a single IDC where clocks all have a dedicated ground and twisted pair but other signals have at least one ground per 4 connections. I did find some nice micro clips at aliexpress recently, but for signals I *know* that I will need to probe constantly I'd do something less temporary. If I have to use test clips I'd rather have a bodge wire hanging off (or at least a bit of solid core wire soldered) and a nearby ground.
Test clips take a while to set up, and if i need to borrow the LA for something else, ugh.
If I have to bodge it on and expect to need to do a lot of probing I'll end up with something like the prior picture using a single IDC where clocks all have a dedicated ground and twisted pair but other signals have at least one ground per 4 connections. I did find some nice micro clips at aliexpress recently, but for signals I *know* that I will need to probe constantly I'd do something less temporary. If I have to use test clips I'd rather have a bodge wire hanging off (or at least a bit of solid core wire soldered) and a nearby ground.
Test clips take a while to set up, and if i need to borrow the LA for something else, ugh.
The logic is based on the Diimo GALs, adapted to fit on a single PLD, right? So I take it you had to understand enough of it to be able to combine it, but other parts of the code you haven’t needed to analyse?
And so in adapting it to a single logic device new issues have arisen, perhaps because it was running marginally to begin with?
