The Visual ARM1
blog.visual6502.orgThis is probably really amazing if you know what you're looking at. I have no idea what any of the parts do and what code is being run.
I would love to see someone give a "guided tour" though all the parts of the CPU, and step through some assembly to see how the things works.
I can see from the picture there are distinct areas, and large arrays of gates that might be memory or adders or I don;t know. It would be amazing to see an add interaction actually wire up some memory to some gate and see the result propagate through the CPU.
You could try to work through "Code, the hidden language" http://www.charlespetzold.com/code/
EDIT: The Art of Electronics has an accompanying book called the Student Manual, which will walk you through the process of (eventually) building a small computer.
He hasn't written anything about this ARM1 (yet), but Ken Shirriff (http://www.righto.com/) has some very interesting gate-level explanations about parts of other old processors scanned by the same Visual6502 project. Take a look, for instance, at these posts: http://www.righto.com/search/label/6502
slightly off topic, but...
> Credit goes to ... Lee Smith for spotting the variable record format used to encode the file (an artifact of the VMS on Acorn's VAX that at first appeared to be widespread corruption of the file),
These days, thanks to Unix and C I suppose, a file is just a collection of bytes. That wasn't always the case. Consider Pascal, where a file is a file of something (records, integers, etc).
So, on VMS, you had streaming files (just a collection of bytes) but also RMS -- Record Management System -- files, which were files of records. There were fixed length records (the record size was probably stored in the file metadata) and variable size records (record size was stored inline, as a byte or word prefix before the record). You might think you're just writing data to a file, but you're writing records (the OS adds the prefix for variable records or 0-pads for fixed length). Then when reading, you might request xx bytes but it will only read one record at a time. (Kind of like how fgets() will stop reading when it finds a newline or a tcp socket will stop reading when it finds a PUSH.)
There are advantages and disadvantages to this but if you're dealing with a VMS RMS file, you need to be aware or it will look corrupted.
The arm1 was designed on paper by people at Acorn whod never made a chip before I believe? Turned out pretty good.
nah, I remember both Wilson and Furber mentioning buying Apollos for CAD.
What code is it running? When I click play, it seems to be in a tight loop from code at addresses 24-34.
Maybe it's simulating an entire OS run - if I leave it on for a few years it will finish zeroing the RAM and start booting :)
I'm amazed at how small and (relatively) simple it all looks, that you can literally see the registers on that picture. Just 25K transistors for a whole 32-bit CPU with a 3-stage pipeline.
For those who would like a bit more detail about the feature of this CPU: http://everything2.com/title/ARM1
One thing I was curious to know is whether the ARM1 had a hardware multiply instruction, whether they could fit that in this tiny CPU. It does not.
ARM2 had hardware multiply & more shadow registers and came in at 30k transistors according to Wikipedia. Everything2 thinks the ARM2 came in at just over 25k transistors though, with the ARM1 using less than 25k.
Would be nice if somebody with the knowledge could do some kind of guided tour where they would go over some of the structures what they are and what they do. For me as a software developer with no knowledge of electronics it looks nice but thats about it.
So the ARM1 had no cache & no microcode. 15 user visible 32 bit registers, with some (Nos 10-15 IIRC) duplicated for use during interrupts (FIQ mode). I think a couple more registers were also duplicated for use during other interrupts. So bottom left looks like it might be the register bank. The square block at top right might be the instruction decode PLA?
There’s a block diagram for the ARM2 in this document: http://www.riscos.com/support/developers/asm/cpu.html I believe the ARM was much the same, with the exception of fewer banked registers & no integer multiplier, so the dedicated could probably trace the paths and make some guesses about where each block is located.
Yes, I think bottom left is the register bank -- you can see it is 25 elements horizontally by 32 vertically, and there are 25 total registers listed on the right (r0..r15 plus the svc/irq/fiq mode-banked copies of some of r10 through r14). Also I'm pretty sure the program counter (r15) is the far-left-hand-side, because that first row does not have cells in the bottom two bit positions or the top six (ARM1 used 26-bit addresses, hence the missing top six, and PC values are always 4-aligned, so no bottom two bits).
This one is pretty good: http://wiki.nesdev.com/w/index.php/Visual_circuit_tutorial
I hope they tear apart the VIC-II chip next time.
I know it seems like the state-machines of VIC-II are fully documented, but perhaps there could be even more tricks undiscovered?