jecel

Very good points. About ARM1, 2 and 3, if my memory from 4 decades ago is correct then the changes from 1 to 2 were a move to a slightly newer process node, replacement of "multiply step" with actual multiply instructions and the addition of the co-processor interface. 2 and 3 are the same processor, but with the latter adding a 4KB onboard unified cache, which allowed it to run at a much higher clock frequency.

Thanks for the link. As Ken points out at the end, "Probably the biggest objection to calling the ARM1 microcoded is that the designers of the ARM chip didn't consider it that way.[4] Furber mentions that some commercial RISC processors use microcode, but doesn't apply that term to the ARM1". My opinion is the same as Steve Furber's, though I can certainly see Ken Sherriff's viewpoint.

In theory PLAs and ROMs are fully equivalent. In practice, while the ROM can accept any possible "microcode", a PLA might have to be enlarged if you want to change some of the "micro instruction". This need to change the hardware to change the functionality of an instruction is what makes me consider this design hardwired instead of microcoded.

[EDIT] Another issue is that the ARM1 has three pipeline stages. The "microcode" here is not used for the fetch and decode stages, only the execute one. So though register to register operations take 3 clock cycles to execute, only one "micro instruction" is needed (the second line in the table).

ARM1 had multicycle instructions (LDM and STM) and the ARM2 added more (MUL and MLA) but as far as I know these were controlled by hardwired finite state machines, not microcode.

ARM only shows up on a white board on the background of a discussion towards the end. So it isn't 100% absent from this movie, but it is really about the conflict between Clive Sinclair and Chris Curry (just like "Pirates of Silicon Valley" is about the conflict between Steve Jobs and Bill Gates).

"IBM had no moat around the PC." is true about the original PC and XT, but they did have 7 patents on the AT. After the PS/2 attempt didn't work out, their lawyers spent the first half of the 1990s going after the chipset makers and the second half of the 1990s getting clone makers themselves to license these patents (along with some other unrelated ones that weren't about to expire).

A quick search showed it isn't easy to find online version of these patents (because IBM has so many that even knowing these are from 1984 didn't help), but I remember that one was related to being able to split a screen into a graphics and a text part in their EGA board (though the Apple II previously did this too, but with a fixed split), one was about detecting 360KB vs 1.2MB floppy drives by seeking to track 60 and then stepping back 59 tracks and checking if we were now at track 0 (not unlike how the Apple II handled the lack of a track 0 signal, but for a different purpose), one was for the "bus master" signal in the PC AT (later ISA) bus and I can't seem to remember the other four but they were all similar in style.

So in the late 1990s you had to pay IBM if you wanted to make a PC clone (AT and up, but 8088 clones had died out in the early 1990s).

Yes, I only tested the 60Hz vertical refresh options.

Thanks for the link. I meant to write 1280x720@60Hz for 16:9 HDMI TVs/monitors but have used 1024x768 quite a bit in the past for 4:3 VGA monitors and ended up mixing the two.

VIDEO_ID_CODE 4 (1280x720) works on all monitors I tested while 1 (640x480) only displays on half of them:

https://github.com/nand2mario/nestang/blob/master/src/hdmi2/...

Though DVI/HDMI monitors are supposed to handle 640x480, over half of the ones I have tested don't display anything. Every single one of them worked just fine at 1280x768, however, so I am changing my projects to use that.

Please note that RISC-V and RISC5 are different projects:

https://riscv.org

https://riskfive.com

Despite the name of the second site, the actual processor is called RISC5 (see the menu on the left) and is part of the Oberon project by Niklaus Wirth.

The 2022 PhD thesis linked from their web site includes a picture of what they claim was an actual chip made using a 22nm process. I understand that the commercial chip might be different, but it is possible that the measurements made for the thesis could be valid for their future products as well.

By original MIPS designers do you mean from Stanford? Those would include John L. Hennessy, Norman P. Jouppi, Steven Przybylski and Christopher Rowen as the authors of the first papers about the project. If you are talking about the MIPS company started by John Hennessy and Chris Rowen, Wikipedia has this list:

https://en.wikipedia.org/wiki/MIPS_Technologies#Notable_Cont...

In either case, I am not aware of any of them being RISC-V leaders though John Hennessy did rewrite the books he co-authored from DLX to RISC-V.

SPIM was the name of a MIPS32 simulator widely used in computer science research at one point:

https://spimsimulator.sourceforge.net/

RISC-V looks a lot more like MIPS than it does RISC-I to IV, so on the technical side having MIPS-the-company abandon MIPS-the-architecture was not such a huge change. And DLX that the Hennessy and Patterson books used before they were changed to RISC-V was essentially MIPS as well.

You have to manually carve up the heap into arrays if you want to have more than one. If variable F points to the start of an array then F,I@ will read F[I] while 42!(F,I) is an assignment F[I] := 42. The comma operator is just to convert a word index to a byte index, so F+(2*I)@ and 42!(F+(2*I)) also work but are uglier.

The sieve example uses a single 8Kword array https://github.com/jeceljr/baby8/blob/main/examples/bla/siev...

Thanks for the link - at the time I did a quick search and didn't find that or any other language with that name.

The 1KB target was for Baby 8 (the associated processor) binary code. That processor had a few quirks (like only indirect addressing outside the "zero page") and the language design partly reflected that. Seeing other people fit Lisp into less than 512 bytes made me think I had sacrificed too much functionality for size.

The incomplete Squeak code was just a quick test to see if the language made sense at all before wasting time doing the assembly version.

Not yet, and if I publish any of the languages I will probably use a different name (like "Oak" -> "Java"). Though I did call the unfinished language I published "BLA" (Baby 8 LAnguage - an attempt to see if I could fit an interpreter and editor in 1KB) so I might stick with the stupid names after all.

https://github.com/jeceljr/baby8/tree/main/examples/bla

I have named the experimental languages I am toying with "Plan <x>" (for Programming LANguage, but also because it is a good term as you pointed out). Originally I was using numbers (probably would skip "Plan 9" like Microsoft skipped Windows 9) but the experiments went in different directions and implying an order was misleading. So I switched to star names: Plan Sirius, Plan Rigel, Plan Vega...

Sun's project was an attempt to have a high performance Java processor to replace the simpler PicoJava:

https://en.wikipedia.org/wiki/MAJC

The Xerox Dorado, an ECL beast evolved from the Alto, was considered the only machine to offer a good Smalltalk experience when Smalltalk-80 was initially released. The Xerox Dolphin, for example, was only about "0.1 Dorados" despite being a serious improvement on the Alto. The Apple Lisa was only about 0.05 Dorados.

That level of performance was only achieved by PCs when we got 50MHz 486 (for purely interpreted Smalltalk-80 virtual machines, with JITs much slower computers could match the Dorado).

The Alto created the image from a display list, like the Atari 800 or the Amiga. So you could have a wider rectangle on most of the screen for pictures and a narrower rectangle at the bottom for displaying status. It was not up to showing overlapping windows. Nearly all applications just set things to one rectangle, having a frame buffer in practice. This was the case for Smalltalk, which is where Bill saw the overlapping windows. One problem is that filling up the whole screen (606x808) used up half of the memory and slowed down user code, so Smalltalk-72 reduced this to 512x684 to get back some memory and performance.

The Smalltalk-76 MVC user interface that the Apple people saw only ever updated the topmost window which, by definition, was not clipped by any other window. If you brought some other window to the front it would only then be updated. But since nothing ran in the background it was easy to get the wrong impression that the partially visible windows were being handled.

Bill's solution had two parts: one was regions, as several other people have explained. It allowed drawing to a background window even while clipping to any overlapping windows that are closer. But the second was PICTs, where applications did not directly draw to their windows but instead created a structure (could be a file) with a list of drawing commands which was then passed to the operating system for the actual drawing. You could do something like "open PICT, fill background with grey pattern, draw white oval, draw black rectangle, close PICT". Now if the window was moved the OS could recalculate all the regions of the new configuration and re-execute all the PICTs to update any newly exposed areas. If the application chose to instead draw its own pixels (a game, for example) then the OS would insert a warning into the app's event queue that it should fix its window contents.

In parallel with Bill's work (perhaps a little before it) we had Rob Pike's Blit terminal (commercially released in 1982) which added windows to Unix machines. It had the equivalent of regions (less compact, however) but used a per window buffer so the terminal would have where to copy newly exposed pixels from.

Didn't the TMS 1000 include the processor, i/o, ROM and RAM? All that in 8K transistors seems frugal.

I was disappointed to find that half of the monitors and TVs I tested don't show 640x480 HDMI though all of them worked at 1280x720.

So I am redoing a project I am working on to use the higher resolution.

The 68000 actually had three 16 bit ALUs, so could munch a peak of 48 bits per clock cycle. Only one could do all operations while the other two were basically just add. These days we would say there were part of the AGU (address generator unit) but one of them was shared with the data register operations.

He was: he pointed out that the world of computing he (we) knew back then is illustrated in all the ads. Note that August 1981 is also the month the original IBM PC came out. In contrast the articles showed a world of computing with mice, overlapping windows, menus, cut/copy/paste.

A comment in the video pointed out that the mouse had been invented back in 1964 and claiming it was not common is a cop out. The author of the video didn't know about it before this issue and I didn't know about it. But now we knew, and for how many others was this true?

Much of the memory in a Lisp program is in the form of CONS cells, so the MIT LISP machines had a compact way of encoding this. They also used tagged memory to be able to handle the different kinds of data at runtime. They inherited a very stack-oriented execution model from the PDP-10 implementation of LISP. And they implemented very complex instructions using microcode.

The Symbolics people refined this approach while the LMI people kept the original design until nearly the end when they tried to do a RISC+tags:

http://fare.tunes.org/tmp/emergent/kmachine.htm

As far as I know the Tektronix Smalltalk computers (4404 and later) were the only ones to try a higher resolution scrolling virtual screen.

For Alan Kay's talk they removed some limits of the original hardware, like screen size, processor speed, memory limits and storage (floppies in the original). They found that without these limits the experience was actually better than more modern Smalltalks in some ways. Sort of like using a 1980s 8 bit microcomputer with a modern SD card.

Squeak runs just fine on Linux computers (among many OSes) including the Raspberry Pi.

The project you linked to recreated the original Xerox Smalltalk-80 on the Pi. It has a rather limited scope so I don't know if they ran out of steam or simply reached the end.

While (+ 1 2) doesn't work in the basic system, it is possible to extend it entirely in Lisp so that it does work. You could use Church numerals to represent the numbers, for example. I once did it by representing numbers as lists of hex digits because I was writing a 6809 assembler in Lisp and hex math made it convenient.

For a serial computer, an oscilloscope will easily do what a set of blinking lights will do for a parallel computer. By trading time for space it gives you a free serial to parallel conversion.

All 32 bits in the ARM1 and 2 were used to address data, so in theory you could have 4GB of RAM. But these processors only had 26 address pins, so that would give you at most 64MB (similar to the 24 address pins in the 68000). If you used the MEMC chip to interface to your DRAM then the limit would be a mere 4MB.

For code the limitation was baked into the architecture itself. The bottom two bits of the program counter were used to define the current execution mode (and always output as 0 to fetch word aligned instructions) while the top six bits were the status flag. That meant that saving the PC to the stack saved the whole execution context in a single memory write and it only took one read to restore it.

Fixing this required moving the flags to a separate register, which was a very visible change.