Thread
Amiga accelerators based on FPGAs already exist. MHz is meaningless; the speeds are anywhere around to twice the speed of a 50 MHz m68060:
http://www.majsta.com/modules.php?name=News&file=categories&op=newindex&catid=1
Work is already underway to make the CPU core more complete (MMU, FPU support, too), and some work has been done on an Amiga 500 version which would be compatible with certain Macs if the m68000 is socketed since it just uses the CPU socket.
The current core would be faster, but not significantly faster than m68060 CPUs, but later FPGA cores could really speed things up tremendously. There's been talk about one which would be electrically compatible with m68040 sockets, which would probably interest everyone here...
http://www.majsta.com/modules.php?name=News&file=categories&op=newindex&catid=1
Work is already underway to make the CPU core more complete (MMU, FPU support, too), and some work has been done on an Amiga 500 version which would be compatible with certain Macs if the m68000 is socketed since it just uses the CPU socket.
The current core would be faster, but not significantly faster than m68060 CPUs, but later FPGA cores could really speed things up tremendously. There's been talk about one which would be electrically compatible with m68040 sockets, which would probably interest everyone here...
Guys excuse me,It is indeed the apollo core,is full 68020 compatible,it is as fast as a 500mhz 020 cause it is superscalar,has two execution units,fast fpu and many other improvements,it runs this fast on common Cyclone 5 Altera,nothing too exotic,there are Xilinx Zync 7010 boards for 99 dollar now,Zync 7010 contains fast Artix 7 fpga logic and is big enough for a very fast 68k mac,it has 1 gig ram,HDMI,usb,ethernet,all this on a credit card sized board.
Maybe we could do a kickstarter campaign to hire in some developers?
Maybe we could do a kickstarter campaign to hire in some developers?
Same lot as that NatAmi thing, isn't it? If so I'd expect them to get it done.
But not open, no, so Mac people can't extend it and it'll only support the boards they decide. Feels a bit backwards to me, but I suppose anyone still involved with Amigas must secretly love getting left high and dry.
But not open, no, so Mac people can't extend it and it'll only support the boards they decide. Feels a bit backwards to me, but I suppose anyone still involved with Amigas must secretly love getting left high and dry.
The developer,Gunnar,is very openminded,but he does all the hard work on his own,if we could support him it would accelerate the proces enourmously.We could have a cheap FPGA board with a very fast 68k MAC,AMIGA,ATARI,the hardware is here,only needs some good FPGA developers to write the code.
On one hand you're talking about an FPGA-based accelerator, then in the same thread you mention:
So you want to skip the Mac hardware altogether and just use an FPGA board? Why not just get a really fast Core i7 and emulate a Mac in that case?The core Majesta uses is a crippled version with one execution unit,the full core has two of them so much faster,it is blazing fast,there wouldnt even be a need for an Mac,it could run on the FPGA alone.
John,software emulation and fpga are not the same isn't it?,can you buy a real fast i7 for 99 euro/dollar?,but I am not here to argue,some very talented man puts alot of energy in preserving and upgrading a processor wich we all love I hope,the only way we not so talented could support him is with our money,if we bundle our forces instead of argue maybe one day we can have new 68k computers,be it APPLE MAC,AMIGA or ATARI
Well especially if you can get the 68K fast enough, you may be able to finally write a decent web rendering engine for the 68K mac and it actually be usable.
BUT... there is a HUGE BUT... the processor can be 5Ghz, your still stuck at the 16 to 33Mhz system bus using the real hardware, this includes the RAM so its going to be slower than balls still.
Sure the CPU can crunch the numbers as fast as lightning, but if you cant "get" it to there, then it wont run any faster.
itll help if the L2 cache and of course the main system RAM is modern and running as fast as the processor. But again, the interrupts and all that jaz are ASIC/VIA controlled, and again, your stuck.
BUT... there is a HUGE BUT... the processor can be 5Ghz, your still stuck at the 16 to 33Mhz system bus using the real hardware, this includes the RAM so its going to be slower than balls still.
Sure the CPU can crunch the numbers as fast as lightning, but if you cant "get" it to there, then it wont run any faster.
itll help if the L2 cache and of course the main system RAM is modern and running as fast as the processor. But again, the interrupts and all that jaz are ASIC/VIA controlled, and again, your stuck.
No, software emulation and FPGA emulation are not the same, but they're also not all that different. I'm interested in an FPGA accelerator because it can be used with real hardware from decades ago. Remove all the hardware and emulate it (in the case of a complete FPGA system), and it's less interesting to me.
The completeness of the current m68k FPGA accelerator for the Amiga 600 is a good sign. But how practical is it to do something like that for Macs? As far as I know, the only Macs that have a surface mount m68000 are the Classic and the Portable. How many 128K / 512K / SE Macs have socketed m68000s?
Considering the space and power limitations of the Amiga 600, the FPGA accelerator is damned impressive. But the next step, and a better one for people who care about performance, would be an FPGA accelerator for m68040 sockets. m68040 machines have more of a power budget for the CPU, have much faster access to motherboard memory and more expandability, along with a more physically robust socket. I'm looking forward to those!
The completeness of the current m68k FPGA accelerator for the Amiga 600 is a good sign. But how practical is it to do something like that for Macs? As far as I know, the only Macs that have a surface mount m68000 are the Classic and the Portable. How many 128K / 512K / SE Macs have socketed m68000s?
Considering the space and power limitations of the Amiga 600, the FPGA accelerator is damned impressive. But the next step, and a better one for people who care about performance, would be an FPGA accelerator for m68040 sockets. m68040 machines have more of a power budget for the CPU, have much faster access to motherboard memory and more expandability, along with a more physically robust socket. I'm looking forward to those!
Having hunted around the appropriate websites for a bit, it looks to me like the current state of play is this:
• It looks like they have transparent 68EC020 emulation working at ~200MHz
• They're using a software shim to handle exceptions, but I'm not sure if that is only for the 060 emulation, or for both modes.
nb: these are beta releases that are still being debugged.
Both of those imply that it's not Mac-ready. The EC020 was never used in a Mac. And the "software shim for exceptions" is the same reason we can't use existing Amiga 060 accelerators on Macs.
The surface mount vs DIP40 issue with the 68000 is "only" a matter of altering the PCB layout to suit.
To my thinking, the ultimate scenario for Macs would be:
• Fully transparent 68000 emulation at speed, and
• Fully transparent 68040 emulation at speed.
Either of those would allow the use of the accelerator with existing Mac system software, ie, not requiring the patching that Amiga folks have already done to the various Amiga OSes to use 060s etc.
But as I have at present no way of contributing to the work, this is all wild speculation on my part.
• It looks like they have transparent 68EC020 emulation working at ~200MHz
• They're using a software shim to handle exceptions, but I'm not sure if that is only for the 060 emulation, or for both modes.
nb: these are beta releases that are still being debugged.
Both of those imply that it's not Mac-ready. The EC020 was never used in a Mac. And the "software shim for exceptions" is the same reason we can't use existing Amiga 060 accelerators on Macs.
The surface mount vs DIP40 issue with the 68000 is "only" a matter of altering the PCB layout to suit.
To my thinking, the ultimate scenario for Macs would be:
• Fully transparent 68000 emulation at speed, and
• Fully transparent 68040 emulation at speed.
Either of those would allow the use of the accelerator with existing Mac system software, ie, not requiring the patching that Amiga folks have already done to the various Amiga OSes to use 060s etc.
But as I have at present no way of contributing to the work, this is all wild speculation on my part.
That's exactly the problem I see with this kind of accelerators.Well especially if you can get the 68K fast enough, you may be able to finally write a decent web rendering engine for the 68K mac and it actually be usable.
BUT... there is a HUGE BUT... the processor can be 5Ghz, your still stuck at the 16 to 33Mhz system bus using the real hardware, this includes the RAM so its going to be slower than balls still.
Sure the CPU can crunch the numbers as fast as lightning, but if you cant "get" it to there, then it wont run any faster.
itll help if the L2 cache and of course the main system RAM is modern and running as fast as the processor. But again, the interrupts and all that jaz are ASIC/VIA controlled, and again, your stuck.
I'm not really an expert, but if I recall correctly most (if not all) 68k Macs derive all their clock signals from a single oscillator that controls the CPU, the bus speed and possibly the video signal refresh rate. You can't just expect to speed everything up, because replacing that oscillator would create all kinds of troubles with the system architecture.
I think you could completely bypass the main oscillator by having the CPU run with its own clock, but that would have very little effect - you would still be limited by the bus and RAM speeds, so the performance gain would be negligible if present at all.
I don't really know how accelerator cards worked back then, but if you could design an accelerator that's got its own CPU *and* RAM to bypass the stock ones, you may achieve something interesting. But that's far from being a drop-in replacement.
^ This.
Initially I thought the idea was to build an entirely new model of Macintosh, which I would imagine happening one of two ways:
Talking about an accelerator card for an existing Mac sounds more promising to me. The big issue there, as Sherry and techknight and others said, is RAM. To see much benefit from a 500 MHz CPU in a computer designed for ~20 MHz, you'd need to replace all the RAM, the memory controller, and the caches. And even then, anything on the Nubus like a graphics card would still run at the same old speed. Disk I/O would be just as slow too. But it would be pretty nifty! It could be tons faster for computation-heavy work.
Initially I thought the idea was to build an entirely new model of Macintosh, which I would imagine happening one of two ways:
- New fast CPU in an FPGA, with memory controller, ASICS, I/O, sound, graphics, etc. implemented externally in hardware. This would be the closest thing to a "real" Mac, and would be very cool, but probably a tremendous amount of work.
- The entire thing implemented in an FPGA, with connections for a VGA or HDMI display and USB peripherals. Probably an easier approach (though still very challenging), but as johnklos said, the difference between that and an emulator is subtle. It's totally different at the bottom level, but the end result looks nearly identical. Put Mini vMac on a fast ARM CPU board inside a custom enclosure, and ask people to tell the difference between that and an FPGA solution.
Talking about an accelerator card for an existing Mac sounds more promising to me. The big issue there, as Sherry and techknight and others said, is RAM. To see much benefit from a 500 MHz CPU in a computer designed for ~20 MHz, you'd need to replace all the RAM, the memory controller, and the caches. And even then, anything on the Nubus like a graphics card would still run at the same old speed. Disk I/O would be just as slow too. But it would be pretty nifty! It could be tons faster for computation-heavy work.
The Amiga 600 accelerator has 64 megs of local, really really fast memory. Macs could use system memory to boot and add the really fast memory during boot. But even though the interface to the motherboard is 7.16 MHz, 16 bit, it still makes the old school Amiga ECS chipset shine.
Would it be faster to do everything on the FPGA, or would it be faster to take an existing 68k compatible CPU like a Coldfire, then add the instructions needed to be compatible with a Mac?
I guess all the hard work has been done already on the Amiga side. Probably faster for everything on FPGA.
I guess all the hard work has been done already on the Amiga side. Probably faster for everything on FPGA.
It occurs to me, bigmessofwires, that your Plus Too would in many ways be the perfect development / testbed for an FPGA-based accelerator. Keep the hardware definition of the rest of the system the same, and replace the 68000 core with Apollo or whatever. Then uhhhhhh, fix it until it works.
There's also a Macintosh FPGA core for the MiniMig board, which was developed by Benjamin Herrenschmidt. http://www.minimig.net/viewtopic.php?f=6&t=411&start=10
That's another problem, actually. The '020 was/is capable of multiprocessing but this was never implemented on the 68K-era Mac. It doesn't matter if your system has 1 core or 256 cores if the software was only written to utilize 1 of them.it is as fast as a 500mhz 020 cause it is superscalar,has two execution units,fast fpu and many other improvements
In PC land there are even cases where running old OSes (like Windows NT 3.1) in VMs on multi-core systems will make the system run slower or become unstable because they don't know how to handle the shift between cores. To get them working properly the hypervisor has to be locked to a single core (affinity).
An "execution unit" isn't a "core". I'll save you the "TL;DR" but in short a CPU that presents itself externally as a single "core" is of course actually made of a bunch of separate little bits and bobs (instruction decoders, ALUs, etc) and faster CPUs sometimes have more than one of each of these bits and bobs wired in parallel so the CPU can execute (parts of) multiple instructions at once. CPUs capable of doing this (transparently, or partially so) are broadly termed "Superscaler"; the first superscaler x86 CPU was the original Pentium, while the only superscalar "classic" 680x0 CPU was the 68060. So... yeah, apparently they designed a Superscalar 68020-compatible; assuming they did things properly there shouldn't be any need for software changes, although it should be noted that in many cases to take full advantage of the "two or more instructions at once" capability it's best to recompile your code so it can order things to take optimal advantage of the hardware.
(There are usually limitations as to what sorts of instructions can execute simultaneously; obviously this applies if the next instruction directly relies on the results from the last one, but there are other cases where instructions can block each other. But these changes are not of the same order as rewriting for SMP support.)
(There are usually limitations as to what sorts of instructions can execute simultaneously; obviously this applies if the next instruction directly relies on the results from the last one, but there are other cases where instructions can block each other. But these changes are not of the same order as rewriting for SMP support.)
Ah yes, I had a dumb moment. You are correct, I was thinking in terms of cores. There are some issues in terms of pipelining and the order of execution but yes, it's not as dramatic as a redesign for SMP.
Although some work has been completed in getting this to run as a Mac I am still skeptical at this phase. Even the very nice Basilisk II emulator, which has been in development for years, is still not perfectly stable nor compatible with all applications. This FPGA seems like an even taller order at the moment.
Although some work has been completed in getting this to run as a Mac I am still skeptical at this phase. Even the very nice Basilisk II emulator, which has been in development for years, is still not perfectly stable nor compatible with all applications. This FPGA seems like an even taller order at the moment.
I personally can't see any real-world justification for the expense and/or effort of development on a largeish scale. Cool idea on paper but it really does sound like a case of travelling the world for the sake of sixpence. Not that I am in any way intending to trivialise the efforts of the developer in question whom is working upon the project at present, I just really can't see that there is significant benefits to really motivate enthusiasts to want to get behind it... Cool just isnt enough in a lot of cases.
Don't worry, it's not just you who doesn't get it. The market for the utterly gonzo Amiga upgrades is apparently driven by the dreams of a core of super-enthusiasts (which I can't imagine could *possibly* be very many people at this point?) who still believe the Amiga is somehow still a living platform and the existence of something like a "500mhz 68020" will somehow bring developers back to make new... Amiga-things. What's particularly amusing/pointless about this thing is it takes this already tiny market, which for the most part has bought into the whole "Amiga PPC" thing, and tries to split off the chunk who this whole time have been pining for faster native 680x0 CPUs instead. Are there *really* enough people out there that even *think* they need such a thing to justify its existence? Obviously this thing is going to be of zero use running classic games, as those were already written to target the Amiga platform as-shipped so... it really seems like a solution to a problem that doesn't really exist. The only people who "need this" really need a new computer, hate to break it to them.
And following that same line of reasoning it makes even less sense as a Mac upgrade for the simple reason that unlike the Amiga Apple *had* a well-executed and nearly seamless transition to PowerPC so there already scads of machines out there that should run classic Mac software as fast or faster than a crazy-fast accelerator will. It's probably not the best thing to look at but, for instance, if we play with Speedometer 4.0 benchmark numbers taken when running in "68k code mode" a 500mhz-ish G3 or G4 should be comparable to a Mac II running at about 500mhz. (And of course the machine will be scads faster when running native code.) And that's assuming that a Mac II with one of these upgrade cards would really be as fast as what you'd get if you could just magically turn the bus clock in a Mac II up to 500mhz, which is a pretty laughable idea.
So... yeah, not getting it. It is, however, "cool".
And following that same line of reasoning it makes even less sense as a Mac upgrade for the simple reason that unlike the Amiga Apple *had* a well-executed and nearly seamless transition to PowerPC so there already scads of machines out there that should run classic Mac software as fast or faster than a crazy-fast accelerator will. It's probably not the best thing to look at but, for instance, if we play with Speedometer 4.0 benchmark numbers taken when running in "68k code mode" a 500mhz-ish G3 or G4 should be comparable to a Mac II running at about 500mhz. (And of course the machine will be scads faster when running native code.) And that's assuming that a Mac II with one of these upgrade cards would really be as fast as what you'd get if you could just magically turn the bus clock in a Mac II up to 500mhz, which is a pretty laughable idea.
So... yeah, not getting it. It is, however, "cool".
You may be looking at this backwards. It's not:
"I really want a much faster 68000 Amiga. Hey, I could build a 500 MHz superscalar '020 with an FPGA!"
but more like:
"I really want to tinker high-speed FPGA processors. Hey, I could build a much faster Amiga!"
and from that point of view, it makes as much sense to me as anything else around here.
"I really want a much faster 68000 Amiga. Hey, I could build a 500 MHz superscalar '020 with an FPGA!"
but more like:
"I really want to tinker high-speed FPGA processors. Hey, I could build a much faster Amiga!"
and from that point of view, it makes as much sense to me as anything else around here.
Amiga people like to do things other people say they can't. So while the rest of the world was saying that Quake and other game engines would never run on Amigas, people went and made them run on Amigas.
The attraction for the Amiga 600 is that it's the smallest Amiga and the only accelerators it ever got were m68030 accelerators. Therefore, something faster than an m68030 is nice. That it happens to be faster than an m68040 and will eventually be faster than an m68060 is just bonus.
Remember - there are thousands of games for Amigas! With a floppy emulator, you can boot and play any of thousands of games quickly and easily.
The attraction for the Amiga 600 is that it's the smallest Amiga and the only accelerators it ever got were m68030 accelerators. Therefore, something faster than an m68030 is nice. That it happens to be faster than an m68040 and will eventually be faster than an m68060 is just bonus.
Remember - there are thousands of games for Amigas! With a floppy emulator, you can boot and play any of thousands of games quickly and easily.
What he said. No one is going to make money building 68K Mac upgrades -- or not much money. But the hardware development can certainly be fun.but more like:
"I really want to tinker high-speed FPGA processors. Hey, I could build a much faster Amiga!"
and from that point of view, it makes as much sense to me as anything else around here.![]()
I still want to build a video card for the SE/30 with really fast memory on board -- at which point, why not replace the system RAM with some of the RAM on the "video" card, etc.
Well, so... looking it up it looks like the Quake port recommends a 68060, which is a good, what, 3x times faster than the best CPU a real Amiga ever shipped with? DOS Quake would run sorta-mostly-okay on 486DX4s and its target platform was the original Pentium 60 so... yeah, I'm not sure running on a 68060 is that impressive a feat. How does it run on actual *unmodified* Amiga?Amiga people like to do things other people say they can't. So while the rest of the world was saying that Quake and other game engines would never run on Amigas, people went and made them run on Amigas.
Well, so this is where I have to admit ignorance: with "most" Amiga games is the experience actually improved by a more powerful CPU? I was sort of under the impression that outside a relative handful of titles released after the platform's "official" death most of the classic Amiga games were targeted at a bone-stock A500, with a lesser number aimed at machines approximating the A1200's specs. Sure there *are* these games like the various FPS clones/ports with scalable rendering that can suck up all the CPU cycles they can get, but, again, I was sort of under the impression that the bulk of the games available for the platform treated it more like a gaming console? (Again, I could be completely off-base as nobody I knew had an Amiga; a few computer shops in the area had an A500 sitting in the corner in the late 80's running demos but I don't think they were exactly flying off the shelves.)Remember - there are thousands of games for Amigas! With a floppy emulator, you can boot and play any of thousands of games quickly and easily.
In any case, perhaps I gave the wrong impression... I certainly think it's *neat* what these guys are doing. I'm actually very impressed that we've reached to point where a small band of hobbyists can engineer a superscalar CPU and be able to just flash the design onto an off-the-shelf chunk of silicon silly putty. Perhaps I'm just wondering out loud if an "accelerator card" is really the best goal for such a thing given all the compromises that come along with going that route vs. a complete FPGA re-creation. If nothing else those A600s aren't getting any younger.
That's almost exactly literally what I was going to say.Perhaps I'm just wondering out loud if an "accelerator card" is really the best goal for such a thing given all the compromises that come along with going that route vs. a complete FPGA re-creation. If nothing else those A600s aren't getting any younger.
If somebody came along and thought that they could reimplement a fairly basic but well appointed Mac, such as the Quadra 650 or 800, I'd be extremely interested in the project, and would possibly be interested in helping out (financially.)
It doesn't have to be the 650 or 800 specifically, but I like that idea because even if you can't get anything faster than what that system already was, you've got a pretty healthy system already.
To be honest, rather than "really fast" 68k Mac, I would love to see a "really durable" one. I would like either a really good, really accurate emulator for 68k Macs (I don't care if it brings my quad i7 to its knees) or some kind of re-engineered 68k system.
Either pack it all into something the shape and size of a NUC or a Mac mini with, say, video (HDMI?), ADB, Serial, Ethernet, Audio, and an outboard-facing SD reader, or build a micro ATX board (or a new box, so you have room to properly mount NuBus hardware? Who knows) with all the trimmings of a "regular" Quadra 650/800, plus a few extras -- maybe make it a 40 or 50MHz '040, build 128 or 256 megs of RAM directly onto the board, one or two SD or CF slots for mass storage, and either build on a newer GPU or figure out how to add a whole raftload of V-RAM to the existing one, so we can just use it with regular LCD monitors.
It would cost a lot and it'll never happen, but I can dream, right?
DDR2 memory is cheap and faster than a speedy 68040 can really take advantage of. When I looked at this, I thought one could probably get the whole thing, along with an integrated DDR2 memory controller onto a Xilinx Spartan 3 or 3A chip. The necessary chip would be BGA and require special soldering. The cost, depending on the size of FPGA really needed ranges from $50 to about $100. At the time I was sizing for a 68030 replacement, but the 68040 shouldn't require more IO, just more logic slices. I'm a little uncertain of my estimates, because I'm not certain how to translate the transistors in a 68030 or 68040 into number of gates or logic slices needed in an FPGA. I suspect that the FPGA ends up needing a lot more than the equivalent number of transistors...maybe make it a 40 or 50MHz '040, build 128 or 256 megs of RAM directly onto the board, one or two SD or CF slots for mass storage, and either build on a newer GPU or figure out how to add a whole raftload of V-RAM to the existing one, so we can just use it with regular LCD monitors.
It would cost a lot and it'll never happen, but I can dream, right?
Anyway, the point is, with the DDR2 interface, you would just use that for VRAM too. A 1GB laptop form factor DIMM is about $12. Allocate 256MB or even 512MB of it for system RAM, and there's still plenty left over for video memory.
If you mean the connectors, yes they are still avaiable. It's been a year or more since I checked Digikey, but they still had them for $5 - $10 and they pop up on Ebay regularly. When shopping for them be careful of 96 pin vs. 120 pin, female vs male and right angle vs straight. It's fabulously easy to get the wrong combination for your application.Even running full out I have trouble imagining any 68k emulator maxing out an i7.
Could someone still get NuBus slots? Or would you end up scavenging dead boards?
http://www.ebay.com/sch/i.html?_nkw=eurocard&_sacat=100016&_odkw=din&_osacat=100016&_trksid=m194&ssPageName=STRK:MEFSRCHX:SRCH
I checked Newegg before I posted. 1GB Laptop DDR2 DIMMs are about $12. And Xilinx has a DDR2 controller cell in their free library. It's good to get the -5 speed in stead of -4 speed rated Spartan 3A for use with it though.Said no one who bought DDR2 recently.
For this application, there's no reason to look at anything larger than a 1GB DIMM. Oh, you could maybe force a 2GB DIMM if you insisted on 512MB of system RAM and then decided to dumb-out on the FPGA interface and only address 32 bits of the 64 bit DIMM. That would take up 1GB and you'd need some more for video RAM, so that pushes one to 2 GB. But why in the world would anyone make those design decisions?
Really, a 512MB DIMM would probably be plenty and those are available on Ebay for about $1.50 each if you buy some of the lots of ten or twelve that upgraders are offering.
Of course it's **possible** to include QuickDraw acceleration. As always, the tricky bit is in actually doing the work... I'm not 100% certain that we can reproduce the information that one must have in order to intercept the QuickDraw calls and divert them, but I think that information is available.
I am thinking more of the lines of a Raspberry pi or beaglebone processor running a web browsing/video playing engine that gets "framed" into the mac environment, sorta like parallels does with Mac OS and Windows.
Then I could use the machine as a daily driver. Get best of both worlds. browsing the web and watching youtube videos, while using the mac too
Then I could use the machine as a daily driver. Get best of both worlds. browsing the web and watching youtube videos, while using the mac too
I've mentioned this elsewhere, but I'll put it here, too.Even running full out I have trouble imagining any 68k emulator maxing out an i7.
Computers and game consoles are a little different, but basically when looking at game consoles, you can either get quick and dirty, or accurate. Accurate emulators take hecka horsepower.
The more accurate, the better, I personally believe, if only because in the olden days (again, time constraints) I often ran into situations that weren't supported or were supported only extremely poorly by "quick" emulators like SheepShaver and Basilisk II.
The other thing, if this hypothetical accurate 68k emulator can run at over 100% of the speed of some native target (because you know, computers are so much simpler than game consoles), I bet literally nobody will complain. One of the recent situations I've been hearing about is using MPW on a Mac to compile things for the Apple IIgs. This task is actually somewhat complicated and is a near perfect case for a 68k (or PowerPC) replica machine that can run System 7 at over the original speed of one of these systems. (In one case, a friend doing this is buying a PB2400c and installing a G3 upgrade in it, but if a physically replicated 68k Mac could do it, or if they could run it on an emulator, but one of the concerns I heard from some people doing that task was that not all of the emulators are really stable enough. (I don't think accuracy was a concern, I forgot if the one emulating already was using SheepShaver or Basilisk.)
I don't know how often those people compile their applications, but when they do, they want it to complete as fast as it can, for debugging purposes.
I'm an FPGA guy, and I really like this idea. As others on this thread have stated, increasing the CPU clock won't buy you anything with slow ROMs, RAM, etc because you'd spend most of your time stalling. But putting the system on FPGA is a way to get everything up to speed. Implementing the whole system on an FPGA or two might be possible for a simpler mac. The real challenge is reproducing proprietary logic like SCSI and glue chips. Modern FPGAs like Artix/Virtex 7 have enough fabric and BRAMs, and have high-speed lines that can be run to SDRAM or DDR chips which are common on even inexpensive FPGA boards. Pseudo-SRAM chips aren't terribly expensive and you don't need a lot.
If we are able to get the HDL for a 68k, then one of the hardest parts of the work is done. A superscalar core might not be a good idea for a first attempt because having substantial clock delays between decode and result could introduce synchronization problems that a classic mac system can't deal with. I'm not very familiar with m68k arch, so I don't know for sure if this would actually be a problem, but I suspect that changing the order of accesses on address and data busses might not work.
The mac emulators out there already understand how this proprietary logic works, right? So going from software code to HDL is conceivable, especially with the help of one of the emulator authors...
If we are able to get the HDL for a 68k, then one of the hardest parts of the work is done. A superscalar core might not be a good idea for a first attempt because having substantial clock delays between decode and result could introduce synchronization problems that a classic mac system can't deal with. I'm not very familiar with m68k arch, so I don't know for sure if this would actually be a problem, but I suspect that changing the order of accesses on address and data busses might not work.
The mac emulators out there already understand how this proprietary logic works, right? So going from software code to HDL is conceivable, especially with the help of one of the emulator authors...
They already have the Amiga and Atari ST on FPGA and even a few arcades that use the 68K CPU (Williams Electronics' Joust and Star Gate to name two), and I seen other projects claiming they have Macs running on FPGAs. I am interested in this but don't have the money to invest in learning it.
This is very much doable if they can do a Mac on a Chip. Just using the CPU only in a Mac Mother board is not enough as they would be waiting for the Mac's system to send them the information needed. But there is nothing out there saying that you can't make an accelerator that fits the NuBus or PDS slots like a DayStar or Radius Rocket on a FPGA Chip. But you wont get them at 500MHz for the same reason.
This is very much doable if they can do a Mac on a Chip. Just using the CPU only in a Mac Mother board is not enough as they would be waiting for the Mac's system to send them the information needed. But there is nothing out there saying that you can't make an accelerator that fits the NuBus or PDS slots like a DayStar or Radius Rocket on a FPGA Chip. But you wont get them at 500MHz for the same reason.
Wow, thanks for making me aware of this. This is fascinating and impressive!IIRC, BMOW actually had built something similar, at least at some level, called the Plus Too. I'm not really sure about what could be "recycled" (if anything), but if the purpose is to build a Mac on FPGA I think it could be a starting point.
Yeah, this would be a great starting point. He's done a hell of a lot of work. Looking through his code, which is an intimidating amount of verilog, I read some of his comments discussing mysterious behavior and problems. Figuring these little bits out would be very time consuming. Continuation of this project is daunting, and BMOW is a smart dude.
As he states in his blog posts, he has only implemented the bare minimum of hardware without SCSI or writing to floppy to get to boot, and that's a pretty good indicator of how hard this would be.
Most of my nostalgia and enjoyment comes from having the box, and I'd bet most others here feel the same. Even if we did have a 500 MHz Quadra SoC, it still wouldn't find its way back to our desks for the day-to-day stuff, sadly.
Happily, there are at least two freely available 68K soft cores that can be synthesized for an FPGA. As for the other stuff, I borrowed some from a previous Mac-in-an-FPGA project by Benjamin Herrenschmidt, which used the Minimig board (an FPGA Amiga board). His version included SCSI support, but not floppy. I copied his SCC implementation more or less verbatim (with his permission). So I think all the pieces are there, at least for a simpler Mac like the Plus, if not for a Mac II machine. But I personally kind of lost interest, once I realized how much effort it was going to take to debug it all to get a fully working system.As he states in his blog posts, he has only implemented the bare minimum of hardware without SCSI or writing to floppy to get to boot, and that's a pretty good indicator of how hard this would be.
Woah, he lives here! BTW, I randomly found your 68 Katy project and used it as a reference for a system I made, great stuff.
In your comments you mentioned some possible clock-edge synchronization issues regarding the stability. Some of the schematics show a slightly different clock frequency than those used on your Altera chip. For instance, you're using 32.5 MHz and the oscillator is something like 32.428 (not sure at the moment). Would the use of external osciallators through some differential clock inputs be a good way to get exactly the frequencies needed? I only have experience with Xilinx stuff, but I've noticed it can be hard to get precise frequencies from the internal generators.
In your comments you mentioned some possible clock-edge synchronization issues regarding the stability. Some of the schematics show a slightly different clock frequency than those used on your Altera chip. For instance, you're using 32.5 MHz and the oscillator is something like 32.428 (not sure at the moment). Would the use of external osciallators through some differential clock inputs be a good way to get exactly the frequencies needed? I only have experience with Xilinx stuff, but I've noticed it can be hard to get precise frequencies from the internal generators.
Hmm, I don't remember the details of that now, but for most purposes I don't think it's essential to get an exact clock speed match for the original hardware, as long as it's pretty close. Yeah, those internal clock dividers are somewhat limited as to what frequencies they can do, so if you really need exactly 15.6672 MHz or whatever, you'll need to use an external oscillator to get it. What's more important than the exact clock speed is the relative speed of the various clocks, as you said. If all the clocks are ultimately derived from the same master clock, then you shouldn't have issues with edge synchronization.
It's been a few years since I looked at it, but I think one of the problems with Plus Too was that it was pushing the flash ROM to the edge of its timing specs, and I didn't understand the synthesis software well enough to set up proper timing constraints for the ROM access. I suspect it was occasionally fetching a bad value from ROM, causing the instability problems I observed. I never really figured out a good way to debug problems like that - I could debug functional problems like a reasoning error in the design, but not timing or electrical problems.
It's been a few years since I looked at it, but I think one of the problems with Plus Too was that it was pushing the flash ROM to the edge of its timing specs, and I didn't understand the synthesis software well enough to set up proper timing constraints for the ROM access. I suspect it was occasionally fetching a bad value from ROM, causing the instability problems I observed. I never really figured out a good way to debug problems like that - I could debug functional problems like a reasoning error in the design, but not timing or electrical problems.
So you were using an external Flash ROM? The newer Xilinx FPGAs have Block RAM slices that could be used as the ROM storage, and it wouldn't be terribly difficult to load the Mac ROM into BRAMs from the bitstream. Such a setup would not have any of those timing issues.
