←back to thread

617 points EvgeniyZh | 2 comments | | HN request time: 0.002s | source
Show context
zabzonk ◴[] No.43576999[source]
I've written an Intel 8080 emulator that was portable between Dec10/VAX/IBM VM CMS. That was easy - the 8080 can be done quite simply with a 256 value switch - I did mine in FORTRAN77.

Writing a BASIC interpreter, with floating point, is much harder. Gates, Allen and other collaborators BASIC was pretty damned good.

replies(4): >>43577257 #>>43577890 #>>43579471 #>>43580146 #
TMWNN ◴[] No.43579471[source]
>Writing a BASIC interpreter, with floating point, is much harder. Gates, Allen and other collaborators BASIC was pretty damned good.

The floating point routines are Monte Davidoff's work. But yes, Gates and Allen writing Altair BASIC on the Harvard PDP-10 without ever actually seeing a real Altair, then having it work on the first try after laboriously entering it with toggle switches at MITS in Albuquerque, was a remarkable achievement.

replies(2): >>43579783 #>>43585204 #
WalterBright ◴[] No.43585204[source]
What Allen did was write an 8080 emulator that ran on the -10. The 8080 is a simple CPU, so writing an emulator for it isn't hard.

https://pastraiser.com/cpu/i8080/i8080_opcodes.html

Then, their BASIC was debugged by running it on the emulator.

The genius was not the difficulty of doing that, it wasn't hard. The genius was the idea of writing an 8080 emulator. Wozniak, in comparison, wrote Apple code all by hand in assembler and then hand-assembled it to binary, a very tedious and error-prone method.

In the same time period, I worked at Aph, and we were developing code that ran on the 6800 and other microprocessors. We used full-fledged macro assemblers running on the PDP-11 to assemble the code into binary, and then download binary into an EPROM which was then inserted into the computer and run. Having a professional macro assembler and text editors on the -11 was an enormous productivity boost, with far fewer errors. (Dan O'Dowd wrote those assemblers.)

(I'm doing something similar with my efforts to write an AArch64 code generator. First I wrote a disassembler for it, testing it by generating AArch64 code via gcc, disassembling that with objdump and then comparing the results with my disassmbler. This helps enormously in verifying that the correct binary is being generated. Since there are thousands of instructions in the AArch64, this is a much scaled up version of the 8080.)

replies(2): >>43585650 #>>43671032 #
dhosek ◴[] No.43585650[source]
The Wozniak method was how I used to write 6502 assembler programs in high school since I didn’t have the money to buy a proper assembler. I wrote everything out longhand on graph paper in three columns. Addresses on the left, a space for the code in the middle and the assembler opcodes on the right, then I’d go through and fill in all the hex codes for what I’d written. When you work like that, it really focuses the mind because there’s not much margin for error and making a big change in logic requires a lot of manual effort.
replies(1): >>43586892 #
1. mfuzzey ◴[] No.43586892{3}[source]
I started Z80 assemnbler (on a ZX80 computer) that way. But I soon get fed up looking up opcodes and especially calculating relative jumps (especially backwards ones) by hand as I often seemed to make off by one errors causing my program to crash.

So I wrote my on assembler in BASIC :)

replies(1): >>43598731 #
2. dhosek ◴[] No.43598731[source]
I wrote a Z80 disassembler that was, alas only partially complete as it didn’t handle the two-byte opcodes as part of my efforts to reverse engineer the MSX Spectravideo computer I got in exchange for writing some demo programs for the midwest distributor while I was in high school. I remember finding the memory locations of the character bitmaps by doing wholesale poke commands through the whole memory of the computer.