The interesting story for me here (and I've been following it for years) is not that people have built an accelerator for the Amiga. It's that the Apollo folks have built out an advanced modern 680x0-compatible core. Given that NXP/Freescale have stopped producing new Coldfire architecture MCU and MPUs and the 68k series itself is dead years ago, this is really great. It's good work, and benefits not just the Amiga community (and other classic 68k machines like the Atari ST) but anybody who wants to continue to experiment and work with the 68k architecture, or upgrade any kind of legacy system.
I also understood that there was work happening on a from-scratch system that could run as an Amiga and potentially Atari ST compatible as well and would not require legacy hardware at all. I'd pay money for that.
That said, I doubt they could get away with licensing it for $$ in quantities, I suspect that they'd run into legal problems at that point. But who knows?
Yeah I've seen the first video before, very cool, and a testament to the amazing work that the EmuTOS team has put into that project. But EmuTOS running isn't really "ST compatible", just EmuTOS compatible. It wouldn't for example be able to run most games and the like given the different video hardware, and would not have support for MIDI and other devices, etc.
That said the second video does show a stock TOS running a game, so that's encouraging.
I’ve got one in my Amiga 500 and it’s crazy: bumps the speed up to around 234 MHz, runs in 1390 x 1024 x 32 through RTG SAGA (“Super AGA”) driver and a HDMI output, MicroSDHC reader onboard (plus 44-pin IDE), 64-bit superscalar MC68080 (not a typo), 128 MB memory + realtime clock + 1 MB CHIP. The newest core adds FPU support and they’re considering adding MMU support too. I’m running AmigaOS 3.9... on an Amiga 500.
Flashing of the FPGA circuitry with a new CPU core is done while the system is running, and they keep increasing the execution speed of the CPU with every update. The thing is nuts.
In theory, once MMU support is added, it should be possible to port illumos back to MC68000, since SunOS 4 used to run on that CPU years back. Solaris zones, DTrace and ZFS on Amiga hardware... now that’s what I’d call a hacking project.
If you have a scan doubler from Individual Computers and your monitor supports multiple inputs, the hardware banging resolutions go to that over VGA and Vampire goes over HDMI. If you don’t see it on HDMI you have to switch to VGA.
The scan doubler is shitty though: the quality varies with the monitor and it overheats. Jens knows about this because the manual mentions adding a small fan and since he was obviously aware of it, it should have been designed in.
I'd love to get one of these... The Amiga was my favorite computer growing up in the late 80's, early 90's.
BTW, Solaris 2.x and above (aka SunOS 5.x) never ran on the 68K.
SunOS 4.x (retroactively renamed Solaris 1.x) did, but it was a completely different code base than Solaris 2.x and above. I used to have a Sun 3/60 back in the day! My Amiga 3000 was a better machine.
I know this, which is why I explicitly mentioned SunOS 4.x. However remnants of MC68000 are sprinkled throughout the code. It should prove an interesting challenge to port an ultramodern OS to Amiga hardware. Vampire could make this possible.
Amiga did run a genuine System V Release 4.0 UNIX from AT&T ported over by Commodore. The link to the tape archive is on generationamiga.com in one of the articles.
Sun Microsystems almost bought the Amiga but Commodore screwed up the deal as usual.
I am not an electrical engineer so can someone explain how this thing can just piggyback on the existing chip like that. Is the existing cpu still doing things and this can read additional instructions the other one doesn’t see?
This is called piggy-backing and it has several uses.
Early PCs would stack/piggy-back memory chips to increase capacity. This was possible because of how memory was addressed.
Another use is to find dead chips. If you put a working chip on top of a dead chip it will read the signals and work.
Finally, in the case of the Vampire and other accelerators for PLCC socketed chips, the accelerator hi-jacks the bus telling the original CPU to do nothing while it takes over the bus.
Electrically there is no trickery, think of each pin as plugging two cords into a power strip. Both get power even though there is one source.
This probably would not work with modern chip packaging and modern frequencies, but it was a common technique back in the day.
Another example of piggybacking is the Commodore 64's (and one model of PETs') 6581 SID sound chip.
Back in the 80's you could bend a couple of the legs out of a second 6581, solder it to the first one, add a couple of wires (and maybe a diode? Can't quite remember), and now you had two sound chips for stereo sound.
These days for some reason people who choose to mod 64's make it unnecessarily complicated with tiny daughterboards and all kinds of needless circuitry. (They also learn how to do it from YouTube videos. We did it from ASCII text files!)
Usually the way these boards work is to simply pull all the CPU pins out to a separate socket. Apple called their equivalent the "Processor Direct Slot" and I'd assume the Amiga works in the same way.
You can typically pull some lines down and the CPU will stop clocking, or the accelerator card can follow the CPU clock and bang data directly into it. It provides very low-level and direct control of the CPU.
AIUI, at least Vampire V500v2, the one I have and for absurd reasons to do with physical distance with my Amigas haven't been able to test despite a year passed, 68k is removed and Vampire put in its place.
original chip is disabled, its IO buffers put in Hi-Z (high impedance) mode. 386/486 PC motherboards did the same thing when you used coprocessor/upgraded soldered CPU using socket.
I can't wait to get my hands on the stand-alone version that's supposedly on the way. Cheap and available (and compatible) hardware with decent performance is a long-awaited thing for a lot of Amiga enthusiasts.
For me, it's pure nostalgia. It's getting to relive the past that I loved with all new hardware, getting to do things that nobody from the time period could have imagined given the limitations and pushing the limits of the software of the system. Sure the OS hasn't been updated in years, but there's a giant library of software and hardware for the system that's still a draw, and using modern technology to make it more palatable and useful is a huge bonus in addition to enabling people to experience it all again.
Unforunately no real information is available, the most recent update is the May progress report [0]. The 500 version is due for release before the standalone, and for the standalone they need to finish implementing the graphics/audio chipset in FPGA plus probably other design issues. Personally, I hope to see the 500 version available in 2019 and the standalone in 2020.
There are VHDL or Verilog implementations of Amiga gfx/audio (see Minimig) but I wouldn't be surprised if the Apollo people want to do their own. After all, the (spiritual) successor, Natami, was to be compatible but greatly enhanced in the chipset front.
That's an American English / British English distinction. "Homely" only means "ugly" in American English and only when applied to a person. Otherwise, "homely" means something along the lines of "plain but cosy".
The best Amiga emulator (WinUAE) only runs on Windows and is still not quite there when it comes to emulating hardware expansions. Its ports to other OSes have been abandoned and the best candidate (fs-uae) is moving at snail pace whilst lacking a lot of the killer features from WinUAE.
Original hardware with modern FPGA-based expansions is a lot better in terms of retaining the feel of the Amiga and not compromising on performance.
It is not my experience that FS-UAE is moving at a snails pace. I'm using the dev releases and these seem to be on par with the current WinUAE features. Which killer WinUAE features are you missing?
That said I am looking forward to the V4 standalone and A1200 V4 cards, both being instabuys for me.
The last time fs-uae updated its core to match WinUAE was in
2016-12-11, from the dev notes:
"Updated emulation core from WinUAE 3300b2."
Since then, WinUAE has had _6_ major releases, the changelog
is visible on the front page and you can simply go there and read it, the list of features I consider killer is too big:
I don't know if this is still true, but I imagine it is because of the latency inherent in modern computers - a JIT-ed emulator is kind of "jittery".
Old school computer are pretty slow, but they react faster than our modern computers.
There was this comparison of "time to first character" or something like that - when you press a button, how long is it until you see a character on screen? IIRC old school computers like Apple II and Amigas won over Intel Core i* monsters.
I remember a kind of stutter on old PCs - screensavers used to have a stacatto effect where they would momentarily pause, and I think you could see the same in 3d games. My Amiga by comparison was always rock steady even when the frame rate dropped. I was convinced at the time that this made PCs significantly crappier - what kind of crumby computer can't maintain a steady user experience?!
I still miss the Amiga magic and wish we had something similar now, not just boring x86/64..
Even today, windowed applications are stuttery. They drop frames in what should be smooth animations.
The Amiga was technically better, in a way that can't easily be emulated. The Amiga video hardware could generate an interrupt at the end of the video frame output. As a result, an application could do all its work for the current frame, then call a "wait for vsync" function. That made it yield to the OS scheduler. When the interrupt fired, the scheduler would handle it and reschedule the app VERY QUICKLY. It was almost like a real-time OS. It knew that video generating was time critical.
I don't think you can't do that on Windows or Linux. The video hardware _might_ support interrupt generation but it isn't wired into the OS in the same way. You might get close to being able to use the "wait for vsync" in full screen DirectX apps, but even then it's a nightmare of video driver lies and OS scheduler complexity instead of a nice clean, simple, reliable feature all applications can use.
I'd be interested to know if Wayland solves this problem.
After I wrote this comment, I decided to have another look to see if this was fixed on Windows yet. It turns out it is. You can call DwmFlush() which deschedules your app until the Desktop Window Manager decides it is time to draw a new frame.
I might now try to recreate the classic Amiga Bezier lines screen saver.
Further update: On one machine I found that while DwmFlush() reliably keeps sync to the video rate (ie every time it returns is 1/60th of a second after the previous time), this wasn't sufficient to keep the video output stutter free. I tried many things to get rid of the stutters and gave up after an hour. My guess is the the compositor gives no guarantee that it will display every "frame" your app gives it, even if you give it exactly one per vsync.
The next day my machine had rebooted itself (presumably to apply an update) and now the stutter is gone.
That's the kind of thing that didn't happen on an Amiga :-)
I knew there was some interesting technical reason behind it! One of my bugbears is delayed response - I seem to see this more and more in mainstream software, and I think platforms like .NET etc don't help. I can't help feeling like I'm interacting with a façade. Things just feel so tighter when you click and the interface responds, consistently. I used to dabble with electronic music and I always found that dedicated hardware was much more satisfying as there weren't god knows how many layers of abstraction and management between you and the metal - just directly wired to a chip. Latency goes from annoyance to serious problem with audio.
And people who have not experienced (practically) zero latency computers, don't know what they are missing.
Heck, back in the day, even though I loved my Amiga, I preferred the editor of Turbo C to more sluggish, font rendering editors on the Amiga. DOS in text mode was unconditionally fast.
Maybe VR will drive the technology back to low latency. Latency in VR equals users throwing up.
I wonder if Linux could be hacked/tweaked to do something like that. If you replaced init with your own program and had exactly 1 process going on your machine, there'd be no scheduling.
A ”natural successor” to the 68040/68060 and suitable for implementation on FPGAs was developed by Apollo and is indeed known as the 68080. http://www.apollo-core.com/
My Amiga 1000 is stock. I've only really though about adding A500 external HDD, and maybe a kickstart ROM mod. I'm not too sure about accelerating it, you still only have an OCS Amiga at the heart, so a lot of the demanding software still wouldn't run. So what is the benefit of a faster CPU in it?
Your A1000 will be able to do up to 1390 x 1024 x 32 via RTG. Any software which already targets RTG should be able to make use of that immediately.
You’ll also have 128 MB of FAST RAM.
I’m given to understand that eventually it might be possible to do 1920 x 1280 x 32. We’ll have to wait and see, but every core update makes it better and better.
I also understood that there was work happening on a from-scratch system that could run as an Amiga and potentially Atari ST compatible as well and would not require legacy hardware at all. I'd pay money for that.
That said, I doubt they could get away with licensing it for $$ in quantities, I suspect that they'd run into legal problems at that point. But who knows?