• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

SE and SE/30 accelerators--discussion of new hardware development

tact

Well-known member
I recently scored a Diimo 030 50mhz! w/fpu  If i could help with anything ;)

Thought this was the fastest 030

 

Bunsen

Admin-Witchfinder-General
If I might suggest a strategy to contain feature creep:

Focus on the "simple" CPU accelerator with DDR as a single board, and give it a fast board level interconnect for later, optional daughterboards with features such as VGA, USB, etc.

 

bdurbrow

Well-known member
I would suggest a similar, but slightly modified tactic: just have one spare pad for an extra FPGA, that is left uncommitted. Route a few lines to the main FPGA, and the rest to an expansion header (also unpopulated). With the high-speed (i.e, gigabit) serial IO now in most FPGAs, it won't take too many IO lines to route for this.

That way, later down the line, the extra hardware can be added if needed (i.e, you discover that you actually need more processing for the core feature set) or desired without having to re-spin the board layout; and any extras can be software defined.

:)

 

Paralel

Well-known member
I can say, with absolute certainty, there are no triple digit speed '030's out there. I would bet my life on it.

 

Anonymous Freak

Well-known member
Agreed. Definitely a typo. The part number ends with -16C, the "16" is the speed. The photo is actually of the faster 25 MHz model (it ends in -25C.)

That said, there are fast 68060 and even "embedded 680x0 derivatives," such as ColdFire and DragonBall lines, although they all have complications that would make using them in a Mac "difficult."

 

Bunsen

Admin-Witchfinder-General
The Coldfire and other late-68k derivatives have been kicked around here plenty in the past.  The general conclusion has been that they're just incompatible enough with mainstream 68ks to be a PITA, and expensive.  I think ZaneKaminski's approach of using an accelerated 68000/68030 softcore in an FPGA is likely to prove the most fruitful.

 

Gorgonops

Moderator
Staff member
The major issue I see with *direct* adoption of the Vampire is that the "Apollo" CPU core they've designed has no MMU support. In theory that might not *strictly*, 100%, be a deal breaker for running MacOS, it could be possible with semi-minimal effort to graft on minimal Macintosh-compatible "HMMU" mapper support, thereby converting any originally-68030-equipped Mac fitted with your accelerator into the equivalent of an extremely highly-clocked 68020-with-no-MMU original Macintosh II or LC. It would rule out using virtual memory or running anything like NetBSD or A/UX on your upgraded machine, however, and there may be ROM and OS compatibility issues that would have to be worked out. (I'll revisit that below.)

Another thing to note is that as of yet all their "it actually exists" hardware targets 68000 machines. They don't actually have a version for 68030-based Amigas. (They're currently working on one for the Amiga 1200, which uses an odd-duck of a CPU, the 680EC20, which can kind of be thought of as a 68000 with a 32 bit data bus but retaining the 24 bit address bus, but even that one seems to be sort of in vapor-ware land.) Therefore an upgrade for an SE/30 or better Mac would be breaking new ground for the hardware. The SE is of course a 68000, so in theory at least that's less of a stretch for the hardware, but then we get back to software problems: The SE is strictly a 24 bit addressing machine and lacks any support for the "32 bit clean" memory model needed to use more than, best possible case, maybe 12MB of RAM. (Strictly speaking, because of peripheral mapping issues the SE is limited to 4MB of RAM unless you shuffle I/O around. And of course it's also missing things like Color Quickdraw, which is a prerequisite for any 32 bit software.) To make full use of something like a Vampire in a plain SE I think you'd pretty much have to cook up a hybrid ROM and implement a memory mapper that would essentially turn an SE into, logically, something like a cross between a Mac Classic II, an LC, and an SE/30.

(IE, map whatever RAM is on the card into a linear space for main memory, use the RAM on the main board *only* as video RAM for the built-in display, and shove the rest of the I/O on the board up to the top of the memory map, modifying the drivers appropriately. That last part is essentially what 32 bit Macs do when they're switched from 24 to 32 bit addressing, the deal here is you'll have to do it with the custom memory mapper you add and, again, fake out MacOS into accepting it's running on something that doesn't really match any real world Mac. Considering the success of emulators like BasiliskII which themselves don't really much resemble any real Macintosh it's probably very doable, but it'll require some pretty low-level hackery to pull it off.)

 
Last edited by a moderator:

trag

Well-known member
Changed my mind but don't see how to delete entire post.

 
Last edited by a moderator:

ZaneKaminski

Well-known member
Hmm... should have trusted the part number. I thought that mislabeled '030 was for embedded applications and this was a faster compatible part or something.

I have emailed the developer of the Apollo core for Amiga and he hasn't responded. Plus the concerns you bring up, Gorgonops, make it seem like that core may not be anything close to a magic bullet.

Hard processor pushes the system cost too high.

Other than this Amiga thing, I don't think there are any 68k soft cores that can execute 68020 instructions, and I'm not capable of designing a 68k compatible processor.

I'm gonna see if I can make some kind of a translation layer that will convert 68k instructions into groups of several ARM/Thumb instructions, running on an FPGA+ARM SoC chip. It would be like the 68k emulation of the PPC Mac OS but done in hardware.

I'm in my fourth year of college, but I need 5 years or so to get both of my degrees in mathematics and computer science. This hardware translation/emulation layer seems like a novel approach, so I'll try to make it into my undergrad thesis and publish a paper on it. That'll surely get me into a good graduate school.

 
Last edited by a moderator:

kreats

Well-known member
Well I think they have considered working on those things (MMU and FPU).

All of these issues would be present no matter how it was done - may as well leverage the work of others.

Could have different "modes" of compatibility - you could even have a real 50mhz 030 onboard to switch between. A lot of older software doesn't run properly with 32bit addressing on anyway.

I'd quite like a 12mb 68000 at 100Mhz. One some software was ported to it, it could be quite capable

 
Last edited by a moderator:

techknight

Well-known member
Hmm... should have trusted the part number. I thought that mislabeled '030 was for embedded applications and this was a faster compatible part or something.

I have emailed the developer of the Apollo core for Amiga and he hasn't responded. Plus the concerns you bring up, Gorgonops, make it seem like that core may not be anything close to a magic bullet.

Hard processor pushes the system cost too high.

Other than this Amiga thing, I don't think there are any 68k soft cores that can execute 68020 instructions, and I'm not capable of designing a 68k compatible processor.

I'm gonna see if I can make some kind of a translation layer that will convert 68k instructions into groups of several ARM/Thumb instructions, running on an FPGA+ARM SoC chip. It would be like the 68k emulation of the PPC Mac OS but done in hardware.

I'm in my fourth year of college, but I need 5 years or so to get both of my degrees in mathematics and computer science. This hardware translation/emulation layer seems like a novel approach, so I'll try to make it into my undergrad thesis and publish a paper on it. That'll surely get me into a good graduate school.
if you did that, then you could probably use the Basilisk II or vMac source, at least pieces of it. 

 

ZaneKaminski

Well-known member
Well my thought was to do the translation in hardware and then write the instructions into the memory accessible by the ARM core, so the source for the software emulators would not be the most applicable. I think that will yield higher performance than the software emulator approach, and like I said, it's also novel.

I've gotta investigate the Cyclone V FPGA with ARM SoC and check out what type of interconnect fabric exists between the FPGA and SoC to see if this is doable

 

Unknown_K

Well-known member
People develop for the Amiga because there are not that many accelerators to go around, and that group is not adverse to spending money. Prices for used SE and SE/30 accelerators are probably cheaper then anything you could build new so unless you just want to do this for the fun of it I don't see a major profit center here.

 

ZaneKaminski

Well-known member
Like I said, I know it will cost quite a bit of money to build the cards, though the Vampire for Amiga people price theirs at 150 EUR if I recall correctly.

I'm gonna complete the project, release the design files and source code, and then make myself a website and put it and my few other major achievements on there to serve as my portfolio. I'm young and relatively inexperienced, but I have the technical mettle and the money to pay for a few boards to keep and also to sell (slowly). My aim is to learn something and contribute something cool to the Macintosh community, not to make a commercially feasible product.

 
Last edited by a moderator:

Bunsen

Admin-Witchfinder-General
so the source for the software emulators would not be the most applicable.
No, but the documentation they put together in reverse-engineering Apple's machines might be helpful.

 
Top