Instead, Paul Allen's emulator worked at the code source level, and was implemented as a macros for the assembler. This wasn't even an 8080 assembler, it was a PDP-10 assembler and they created a bunch of macros to output the proper bytes for 8080 machine code.

For PDP-10 mode, they switched to a different set of macros, that took the same source code but for each 8080 instruction, it generated one or more PDP-10 to replicated the behaviour of 8080. The source code also replaced the IO code with native PDP-10 IO routines. This gives you a PDP-10 binary that you can run as normal.

I'm sure Paul Allen could have written an 8080 machine code interpreter if he wanted to; It's really not that hard to make an emulator of a single CPU with limited IO, especially when the instructions are all documented. But the goal wasn't to emulate other people's 8080 binaries, the goal was to quickly create a programming environment to target the 8080 platform.

That's what I was thinking. These guys were pretty bright and an 8080 is not exactly a complex CPU. It wouldn't be a trivial task by any means, but I'm sure he or billg could have pulled it off.

Don't get me wrong: I doubt it was enough enough to run a BASIC implementation but the 8080 instruction set is so simple that I was able to write a few simple bit-manipulation programs and believe they worked. I'm sure Allen's was much more capable, but it would not have needed to do any of the things expected of a modern emulator (timing, cache, complex addressing modes, interrupts...)

IMO, the problem that our modern definition of "emulator" is overly opinionated. The strict definition requires that the emulator take the CPU's machine code at runtime and either interpret it, or dynamically recompile it.

You could have an xbox emulator that dynamically recompiled x86 to x86 and everyone would agree that's an "emulator". But you make a few minor changes to that dynamic decompiler and turn it into a static decompiler and suddenly people start debating if it's still an emulator. If you go a step further and switch to using the CPU's virtualisation support or even just running the x86 code direction people will really put their foot down and say it's not an emulator. Despite the fact it's still emulating the GPU and Audio DSP and a bunch of other hardware.

The CPU is usually one of the simpler parts to emulate, the real complexity is in emulating the rest of the hardware, so I find it really weird that our definition of "emulator" only cares about how the CPU is implemented.

If we switch to a slightly less strict definition of "emulator" then there is nothing wrong with Paul Allen's 8080 emulator meeting the definition. It still emulates the behaviour of the 8080 cpu, so it is an emulator.

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

I would not be surprised if some version / implementation of roff ran on PDP-10 under some OS.

In retrospect they had a giant market and we were kids at the end of the world, they did a little better than us. Always wished we'd trademarked the name, it would have been worth something

Development systems from Intel were almost as expensive as a cheap minicomputer.

https://news.ycombinator.com/item?id=15005101

The 8008 would have been available already, but it was not binary compatible. However, an assembly translator was available (similar to the latter one translating 8080 asm to 8086).

So the question is if Allen wrote a binary emulator or perhaps something that interpreted asm source code? Maybe the emulator code is still hiding somewhere in the Microsoft archives… :)

https://retrocomputing.stackexchange.com/questions/4984/how-...

And a bit more about the PDP10 macro assembler that was used (also for 6502 BASIC) at Michael Steil's site:

https://www.pagetable.com/?p=774

Then they wrote the BASIC interpreter on the emulator, copied it to punched paper tape and Allen wrote the loader for that while he was on the plane to demo it for Altair.

On the real Altair 8800 hardware which they had never seen, it worked first time (they must have had some advance knowledge of the Altair’s I/O functions)

It was a series of amazing feats

https://en.m.wikipedia.org/wiki/Altair_BASIC

Edit: maybe this feat was not so famous because the Altair was not sold in numbers like the Apple II, which Steve Wozniak is well known for (25000 Altairs sold vs Apple’s 6 million - plus clones)

The Motorola 6800 and Mostek 6502 soon became more popular because they were easier to interface than the Intel 8080A. The Zilog Z80 came out a couple of years later.

Intel did originally call their iAPX CPU the 8800, but that’s almost got to be an unrelated coincidence because the Altair 8800 was launched in late 1974, but the iAPX’s development didn’t begin at Intel until 1975. The iAPX is also an utterly diverse architecture and instruction set that Intel abandoned later, and they continued with the x86 line.

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

The earlier versions that ran on things back to the 8086 were more impressive, to me.

CALL ADDR: ((SP)-1) <-- (PCH), ((SP)-2) <-- (PCL), (SP) <-- (SP)+2, (PC) <-- ADDR

Typo I think, should be '-2', since that stack grows downward.

While what he did was certainly impressive, I don't understand why it would qualify for legendary status. Doing things like this wasn't all that rare back in the day.

I find that the devs in those spaces tend to regard working directly with hardware as being akin to magic. It's not surprising: very few developers these days are working on bare metal, so the work they do seems weird and out there, even though for us it's just another day at the office.

As a graybeard, I forget that what I expect pretty much any competent dev to know is no longer the baseline expectation.

Paul Allen did this in 1974 without the Internet or modern software tools.

I think it is absolutely extraordinary and incredibly impressive.

Compared to modern programming, assembler on a 16- or 36-bit machine is simple, logical, and not at all abstract. DEC made a point of offering high quality detailed docs to students, and there was a kind of assembler culture that produced operating systems like TOPS-10, compilers for various languages, and editing tools, often with access to the sources.

And as others have pointed out, the 8080 was not a complex processor. So mapping its instructions to macros wasn't hugely challenging.

I had a friend who wrote a Z80 emulator - a harder challenge - on a PDP-10 as a spare time hobby project. It took about a month of after-hours programming. Full-time, it would have taken much less.

More interesting is that it's possible Gates & Allen had access to the sources for the PDP-11 4K word Dartmouth BASIC.

I have no idea if the original 8-bit MS-BASIC was a clean room reimplementation. But it's at least possible it wasn't.

^^^ This.

Back in the 80s I wrote a 8051 assembler running on a Z80 system. This involves a parser, and also a bunch of tables with opcodes, operand formats & so on.

Took a number of weeks parttime (not sure if I ever completed it, but the bulk of the functionality was there iirc). This was using just text editor, Z80 assembler, maybe a debugger, and 8051 family datasheet(s).

Apart from emulating I/O (as simple or complex as that in emulated machine), difficulty-wise this should be similar to writing an emulator.

8051 and 8080 are not very different in complexity.

Anyone doing anything with computers in 1974 did it without the internet or modern software tools. It seems to me it was an era where you were either a 'computer whizz' or else you didn't really get involved with computers.

Not saying its not impressive though, I think any programmers from that period who are still remembered now would be rated as 'very very good' by modern standards.

I'd highly encourage anyone to read a data sheet for something like an ESP32.

I once stuffed a software UART, simple command interpreter and a temperature control algorithm into a microcontroller that had a single accumulator and a grand total of 504 bytes of OTP Flash (a donut to anyone who can guess what it was from that odd memory size :-) and didn't give it a second thought until years later someone pointed out that it was unusual.

It's literally not extraordinary because it wasn't that rare of a thing to do. I'd expect most expert engineers of the day would be able to accomplish the same.

The internet and modern tools are merely conveniences that increase productivity. Devs have been working without them for longer than they've been working with them.