Commodore History Part 8-The Amiga 1000 [video]
youtube.com
youtube.com
…now if only there could be actual selling 8520 CIA replacement chips/fpga replacement being manufactured AND sold instead of destroying old motherboards…
https://github.com/niklasekstrom/cia-verilog
https://github.com/bwack/VHDL6526 (6526 and 8520 differ only in their TOD clocks so it should be simple for this to support both kinds)
Since these were made probably with 100nm+ process, Cost of making them shouldn’t be an issue vs. potential sales, (maybe after the chip shortage ease) since whoever owns the amiga patents are not doing anything better than the last multiple owners since commodore… my money would be on fpgas even if denatures the machine a bit.
Apollo Vampire V4 standalone is a "modern" FPGA implementation of a 68k Amiga that is nearly 100% Amiga compatible but much, much faster and with updated graphics etc. http://www.apollo-core.com/v4.html
So: MiSTer if you're looking for an authentic Commodore Amiga experience and want to play old games etc, Vampire if you have a lot of money to spare and want to do "modern" things on a classic Amiga (fancier games, MP3 and video playback...)
You should also consider that Amiga emulation is very accurate and fast these days and you could just get a Raspberry Pi running UAE which would be mostly indistinguishable from the FPGA reimplementations once you're up and running.
Where FPGA really shines is in producing a consistent timing model and the associated performance quirks (such as slowdown in video games).
https://rmcretro.store/multisystem-board-only/
And a review of this set of parts from Anthony of LTT:
The maker still apparently sells them on Amibay[2].
[1]https://eab.abime.net/showthread.php?t=93869
[2]https://www.amibay.com/forum/want-to-sell/hardware-for-sale/...
* The MiSTer FPGA computer supports an Amiga core.
* The Vampire V4+ Standalone, another FPGA-based system, is pretty much the ultimate 680x0 (compatible) Amiga. Both it and the MiSTer are going to more closely approximate the original Amiga hardware by having the FPGAs configured to mimic the custom chips, but they are a little pricey.
* If you don't mind an emulated system, or need to go cheap, then a Raspberry Pi with PiMiga might do. When you consider that the Raspberry Pi 400 is literally today's version of an Amiga 500 form factor, it makes sense.
If you wanted a modern Acorn Archimedes this is also easily had with a Raspberry Pi: simply boot the Pi port of RISC OS!
However, games back in the day hade been made for digital joysticks — which (I personally, find) are more accurate on diagonals than D-pads are. So, I think that a retro-joystick (such as the TheC64 Joystick from the same company) or vintage joystick with USB adaptor would be a must for the authentic experience.
I recently saw a video with Sophie Wilson in which she mentions that various CPUs of the day were tested and all had roughly the same speed and hence they decided to design the ARM processor.
Or was that taken into account?
Sophie Wilson's goal was to run BASIC at 6502 assembly speeds, and they couldn't do that with the processors they had available.
The first ARMs operated at ~4 MIPS, but of course they were 32 bits (registers and data bus), so they were a lot faster than the 68000 and the 6502.
Citing wikipedia: The ARM2 was roughly seven times the performance of a typical 7 MHz 68000-based.
It gets really hard to actually compare processing speeds across architectures. Your 32bit registers might really help accelerate 32bit math, but aren't going to do a thing for 8bit stuff like text processing.
Also the 32bit versions of instructions took longer than 16bit versions, as the 68000 only had a 16bit data bus, and a 16bit ALU.
I dislike the "register size" definition, because it kind of falls apart on modern CPUs. Which register should you be measuring? If it's the GPRs, then we will probably be stuck with 64bit CPUs forever, which is boring. Perhaps we should allow the vector registers to be counted? That would mean most modern CPUs are 256bit, but some Intel CPUs are 512bit. What about fpu registers? That would make the 8088+8087 an 80bit cpu, despite it's tiny 8bit bus.
Personally, I think we should be using a definition that roughly scales with the the performance of the CPU, rather than the software API.
I quite like the idea of memory-bus width. That would fix the 68000 at 16bit, where it arguably belongs, but would make some weirdness with the 8086 and it's 8088 sibling being 16bit and 8bit. But then again, that does actually reflect re-world performance between the two. It gets a bit complicated once CPUs start gaining caches, but I propose we measure the bus width between the CPU core and it's L1 cache. Most modern high performance CPU designs can move actually transfer multiple registers (commonly three) to/from L1 cache every single cycle. Since those registers can be 256bit, that would make them a 768bit cpu.
Though if we start talking about per-cycle data transfers, we really should go back and update older CPUs to how much data they can actually transfer per cycle? Since it takes the 68000 12 cycles to transfer 32bits of data to/from memory, that would really make it a 3bit cpu.
The z80 would become 1bit, and the 6502 would be 2bit (remember, the 6502 does one memory transfer per cycle, while most other 8/16bit CPUs do one memory transfer every 4 cycles), and the 8080 would be 0.62 bits.
You just can't win. Might be better to just to write-off the entire concept of bitness as flawed.
The 6502 takes 1 clock cycle (which might be stretched if needed) to access memory and can read or write 1 byte; At 2 MHz the 6502 in the BBC has a memory bandwidth of 2Mbytes/s.
So going from the 6502 to the 68000 would only get you twice the performance. But the 68000 takes many more clock cycles to handle an interrupt compared to the 6502 and since the BBC Micro was designed around interrupts instead of DMA this would eat up all the performance gain. This was true of the 16 bit micros from National, Zilog and Intel as well.
The ARM2 takes 1 clock cycle (which can be stretched if needed) to access memory and can read or write 4 bytes. In addition, it can tell memory if the next access will be random or if it will be at the address following the current one. DRAM has to slow down the processor for random accesses (a RAS cycle followed by a CAS cycle) but can work at full speed for sequential accesses (just CAS cycles). That means that sometimes the ARM2 runs at 4 MHz and sometimes at 8 MHz - supposing an average of 6 MHz is very reasonable. So we are talking about a bandwidth of 6Mx4 = 24Mbytes/s. That is 12 times faster than the 6502 and 6 times faster than the 68000. And the ARM2 has a normal interrupt that is very fast plus a fast interrupt that is instantaneous.
Note that in theory you need "2MHz" DRAMs for the BBC's 6502 or an 8MHz 68000. But in practice if you want to share the memory between video and the CPU you will need 4MHz DRAMs. Which is what the ARM2 also uses, but without sharing with video. The solution is to fetch the video in chunks using the sequential CAS-only mode, put it in a FIFO and then feed the video that instead of directly. Which is what the MEMC/VIDC companion chips for the ARM2 did. Now the video still slows down the processor, but doesn't hog 50% of the bandwidth.