Thread
new 99 dollar 500mhz 68020?
I don't mess around with 68K Macs for speed. Making accelerators for 68K macs (ones with PDS slots) is not economical. You could run software on a FPGA board I guess but then so much for ADB and Nubus hardware.
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?
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.)
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.
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?
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?
The cool thing would be to build Quadra 840AV boards. Useless, but cool nontheless.
Could someone still get NuBus slots? Or would you end up scavenging dead boards?
The cool thing would be to build Quadra 840AV boards. Useless, but cool nontheless.
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...
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.
http://www.ebay.com/sch/i.html?_nkw=eurocard&_sacat=100016&_odkw=din&_osacat=100016&_trksid=m194&ssPageName=STRK:MEFSRCHX:SRCH
Well, sub 2GB sticks are cheap.
Depends on what you mean by cheap.
Less than DDR3.
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.
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.
Would it be possible to include QuickDraw acceleration and take real advantage of the VRAM? Could you run System 7 on a 4k display? :lol:
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.
Could even get QD GX working! 
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
Then it's just a thin client, and there are cheaper ways of doing thin clients, with or without a Mac.
I've mentioned this elsewhere, but I'll put it here, too.
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...
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.
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.
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!
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.
No, but having a CPU-FPGA only based accelerator, with at least some cache, or possibly a small amount of RAM would be nice
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.
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.