jecel

Normally education or human oriented languages start arrays at 1 (Smalltalk, Cobol, Lua, APL, Wolfram, etc) while hardware oriented languages start arrays at 0 (C and friends, Oberon, Forth, Scheme and so on). Human oriented languages that have to play nice with C also tend to use 0. As do Python and Basic, which contradicts my rule.

Probably the number one reason not to start arrays at 0 in an educational language is that having the last element of an array of size 10 have an index of 9 causes quite a bit of confusion.

"Seventy five years ago, the University’s ‘Baby’ computer became the first electronic computer with a read/write memory to run a program." says the article.

The modified ENIAC used a kind of ROM for its program (a function table), so the addition "first....with a read/write memory" deals with that.

> The idea of Carrier Sense is that the "carrier" signal on the network indicates that the network is idle.

Wouldn't a carrier indicate that the network is busy? Actually, Ethernet is a baseband system and so doesn't actually have a carrier, but for Alohanet you would only have the carrier when a transmitter was on even if it wasn't actually sending 1s or 0s at that instant.

While friction is invariant with the area, adhesion is proportional to the area. Tire grip is much more adhesion (think a glue-like chemical reaction) than friction, which is why race cars use such wide tires even though that ruins the air flow.

The original motivation for the Pi was to offer current generations the same learning opportunities that low cost home computers offered those growing up in the 1980s. An expensive shared family PC in the 2000s didn't encourage tinkering. And things would get even worse as these PCs got replaced with closed smartphones as the only computing platforms people would grow up with.

So a really cheap computer, even if limited, would allow the young programmers to experiment and even if they ended up damaging it at a sufficiently low cost it wouldn't be a disaster.

The initial prototype hooked up two of the same processor in the first Arduinos, one running a Python interpreter and one generating a TV output. Booting to a programming prompt like the 1980s micro would encourage learning the language.

The second prototype used a much more powerful chip and the third added an ARM that could run Linux (it was the one shown in 2011 which looked like a fat USB pen drive). They realized that though the 1980s home computers booted to a Basic prompt, most of the time they loaded ready made games from cassette tapes instead. Having Linux would open up the modern Internet to the little machine.

I think they could have had it both ways - with a small local flash they could boot to a Python prompt if the SD cards was not present. With the card you would go into Linux. In a way, the original idea is finally here with the RP2040 microcontroller configured for MicroPython even though that has the flavor of cross-development instead of a stand-alone machine.

There is a design style called RTL (register transfer level) which works better with registers that have separate clock and enable inputs. The clock goes to all registers, but on any given cycle only a subset of those are enabled depending on the current state. Since these enables are generated from the outputs of these registers which then pass through some combinational logic, they will be stable around the rising edge of the clock.

Note that people talk about Verilog or VHDL as "RTL languages". That is not correct - these languages allow hardware designs using any style to be modeled. But sticking with RTL is strongly encouraged. A design that uses the output from one part of a circuit as a clock to another part, for example, is not RTL. This might cause problems when moving from one FPGA to another or to an ASIC.

About 20 years ago I was watching the local news (small town in Brazil) and one of the things they showed was a farmer's 130th birthday. He had been bedridden for nearly a year at that point but everyone commented how he had been still working hard until that happened. They showed his wedding picture where his wife, now herself an old lady, looked like a teenager while he looked pretty much like the old guy he was during the interview. His youngest son was 30 at the time, which is another thing people who wouldn't believe his age would accept.

It might have been fraud for 15 minutes of local fame. This wasn't national or international news and nobody had any interest in a book of records. But it seemed real to me.

IBM simply followed the tradition created by the companies already in the microcomputer market. Apple's documentation, for example, included the full schematics and the source listing for the ROMs:

http://cini.classiccmp.org/pdf/Apple/Apple%20II%20Reference%...

You could get similar documentation for all Radio Shack products and many others.

MITS didn't set out to make their Altair 8800 an "open system". In their case it wouldn't make sense not to have the full documentation for the customers that were building their own machines from kits. But this resulted in clones and in competitors rebranding their "Altair bus" as the S100 (standard 100 pin) bus and making improvements to it as a group resulting in MITS losing control. So IBM should have known what would happen, but probably thought they were too big and important for history to repeat itself.

I should also have mentioned The Mill architecture as an example of dealing with code as blocks of instructions instead of each one separately. In this case they get a higher fetch rate for their VLIW machine by starting execution from the middle of the block and fetching both up and down at the same time. So they have two program counters which get set to the same value on every jump or call.

https://millcomputing.com/

The point is that inside every advanced processor instructions are handled in groups and if you expose that to the compiler you can save transistors and energy.

We are still moving forward and hope to have interesting things to show soon. For any other readers, my Morphle Engine (aka SiliconSqueak 5) processor design has many elements in common with EDGE (and so with Dataflow as well).

I found the reference to Windows running on Microsoft's E2 processor (which in turn has links to relevant papers):

https://www.theregister.com/2018/06/18/microsoft_e2_edge_win...

I have twice had the experience of meeting a professor who had done their PhD in the late 1980s/early 1990s on Dataflow and were lamenting having wasted their time since it turned out to be a dead end. I pointed out to them that the computer they are currently using has a hidden Dataflow machine inside of it - it just has a front end converting the x86 code stored in memory into the dataflow graph (reorder buffers, reservation stations and so on) before actually executing it.

Perhaps one day the "all advanced processors are really RISC inside" meme will get replaced with "all advanced processors are really dataflow inside".

Of course, there is the option to make the dataflow visible to the outside with the EDGE (explicit data graph execution) architecture (Microsoft even showed Windows running on one).

Small correction: MOS Technology was an already existing company known for its calculator chips when Peddle took his team from Motorola to work there.

A very interesting recentish example was Andreas Olofsson leaving Analog Devices in 2008 (where he had been designing DSP chips) to found Adapteva to create his Epiphany chip with 16 (and later 64, with 1024 planned) RISC processors essentially in his home. He had a bit of success with the Parallella board on Kickstarter to show off the chip.

Tesla invented this because he wasn't happy that cavitation was reducing the life of bladed turbines.

You can have a compiler or assembler in a Harvard Architecture computer, but having separate instruction and data memories means that you can't generate the instructions and then execute them. You need some scheme to move stuff from one memory to another. Think of a PIC or AVR8, for example, rewriting its own Flash memory which isn't even the same width as the data memory.

There is a Walmart Supercenter close to where West Palmetto Park crosses US 441. I don't know it that is outside the city limits.

Great blog post. Some observations:

Ada was not originally an object-oriented language, though it eventually became so. But the 432 project predated Ada and pivoted to that language when it came out. Intel had to adapt Ada to work with objects (it was pretty close already).

An advantage of the 33 bit scheme to protect capabilities is that you can push them on the stack where they will get mixed with normal data and then pop them later such that everything still works. In the 432 style you would need two separate stacks or awkwardly work around not being able to push/pop capabilities.

The "AND NOT" instruction is interesting for using a mask to clear bits. which is why it is called "BIC" on the ARM.

While the 186 and 286 were flawed for making IBM PC compatible machines, for what they had been designed for they did a pretty good job.

It is funny to see VME boards considered "large" (though there were options to allow them to be huge). The name is "VersaModules European format" replacing the 370x230mm VersaBus boards with 233.35x160mm 6U for typical VME boards. Simple i/o could use 3U (100x160mm) boards. This reduction was possible because of denser chips, specially PALs.

Very large boards (9U height and/or 340mm or more depth) were used later, as I mentioned above. But I consider them the exception.

Apple wanted an ISA-like form factor so the cards became 101.6mm high and between 177.8 and 327mm deep. So a bit smaller, but not that much than more typical VME boards. The less squarish form factor does make routing signals to the connector a little more complicated.

It was a joke: when Seymour was informed that Apple was using a Cray machine to design their computers he said something like "funny, I use an Apple computer to design the Cray". But in reality he never used computers at all but did everything with paper and pencil.

Both Cuis and Squeak (from which both Pharo and Cuis were forked) are still actively developed. Pharo does have the largest presence in the two major Smalltalk conferences (FAST in Argentina and ESUG in Europe) but there is no need to worry if one of the other options is more aligned with your needs.

Here is a recent discussion:

https://millcomputing.com/topic/what-is-your-roadmap-for-202...

Having watched hundreds of academic presentations and been at many technical conferences, I don't agree.

If you compare a paper published in a conference's proceedings with the corresponding oral presentation (which is what his videos are) there tends to be a difference. The worst presentations are those that try to copy/paste the paper into PowerPoint resulting in walls of text and those are the most likely to have a references slide.

The ad for the newsletter is very reasonable for the venue (Youtube) and if it would be unacceptable in a different context, like showing the videos in a classroom, that is not the author's fault.

The 286 added "in string" and "out string" instructions. It turned out that if peripherals had a small internal buffer it was more efficient to use these new instructions instead of using DMA hardware. This is why hard disk controllers for the original PC and XT used DMA but from the AT on they normally didn't.

In some equipment, like the Teletype Model 33[1], you had left arrow and up arrow instead of _ and ^. This was part of the 1963 draft of ASCII, but was changed in the final version. In the early 1980s there was still a lot of equipment by DEC and Xerox stuck with the original version, which was what the creators of Smalltalk-80 were familiar with.

[1] https://en.wikipedia.org/wiki/Bit-paired_keyboard

Reversible computing[1] allows us to use less energy than the von Neumann–Landauer limit of kT ln(2) energy dissipated per irreversible bit operation (note that our current technology is still many orders of magnitude from this limit). It does not reduce the energy requirements to zero.

[1] https://en.wikipedia.org/wiki/Reversible_computing

"The 68000 uses much wider microcode (85-bit microinstructions compared to 21 bits in the 8086)." is not what I remembered.

Another source says "The actual internal representation is a combination of "microcode" and "nanocode". The 68000 has 544 17-bit microcode words which dispatches to 366 68-bit nanocode words." which sounds right.

Somewhere around here I have a very detailed article about this which might not be available online, but it would take some time to dig it up.

The TMS340 family used bit addresses, but pointers were 32 bits.

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

I saw one of those running Cromix. It was being sold in Brazil as if it were a local machine by Brascom called BR-1000[1]. They called the OS "BR1000" as well. Some students were trying some examples from the manual and they weren't working. I suggested they replace all calls to br1000() with cromix() and that did the trick.

Another Z80/68K machine was the TRS-80 Model 16[2]. The Sega Genesis[3] (or Mega Drive) was another case of these two processors paired together.

[1] https://www.old-computers.com/museum/computer.asp?st=1&c=533

[2] https://www.old-computers.com/museum/computer.asp?st=1&c=242

[3] https://en.wikipedia.org/wiki/Sega_Genesis

The Alto could emulate different instruction sets via microcode (like their previous machine emulated a PDP-10) and it came with a built in emulation for the Data General Nova, but internally it was a very different machine. The biggest similarity was that it used the same ALU chip, the 74181.

The article mentions that "Kay gambled his budget on Lampson and Thacker’s proposal, calling it the “Interim Dynabook.”" and this budget was for Kay's group to buy more Novas and add a frame buffer to them and high resolution displays like they already had been doing. Smalltalk-72 initially ran on one of these modified Novas. With the default emulation the Alto ran all this old code right away.

Later on the Alto's flexibility allowed them to do things the Novas couldn't, like implement BitBLT and run Smalltalk or Mesa bytecodes directly. So they were not only a bridge to the past, but to the future as well.

Some people who wanted an Alto but couldn't get it made their own:

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

https://en.wikipedia.org/wiki/Lilith_(computer)

I think you are both right. The term "killer app" can be used for something that causes people to buy something else no matter how expensive just to have that first thing. Visicalc for the Apple II, Lotus 123 for the IBM PC and clones (previous apps ran equally well on non clone MSDOS machines), and the web browsers as you mentioned.

Normally it is associated with making something very popular, and in that regard the Analyst certainly wasn't. But it did get a small group to buy absurdly expensive D-machines from Xerox just to run it, though I think it was more than those who bought them to run Lisp:

http://www.bitsavers.org/pdf/xerox/dolphin/1100_Scientific_I...

More about the Analyst from later in its life:

http://www.bitsavers.org/pdf/xerox/xsis/

See the October 5 1960 entry in this list:

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