Live data from Hacker News

Write up of my homebrew CPU build

willwarren.com

21–30 of 54 posts

Re: Write up of my homebrew CPU build

#21
Hello Will, interesting read, and happy to see 8-bit breadboard builds on HN. I used to follow Ben and James years ago and built a fully functional 256-byte ROM/RAM cpu that could accept instructions from Arduino as a IO input. I gave up on extending output to add a mini OLED. Cool to see your project and can't wait for part 4.

Re: Write up of my homebrew CPU build

#22
post #5

> It’s a standalone tool that lives outside the computer. I put the EEPROM into the socket, and connect via serial to my laptop to upload the binary files. Huh, I guess I never really thought about it, but how did they program the first CPUs? Like how did they overcome the chicken/egg situation?

Here is a blog post describing how to do it with a PDP8. Note: he used an assembler but in those days you had do translate to machine code by hand.

https://raymii.org/s/articles/Toggling_in_a_simple_program_o...

Re: Write up of my homebrew CPU build

#23
post #5

> It’s a standalone tool that lives outside the computer. I put the EEPROM into the socket, and connect via serial to my laptop to upload the binary files. Huh, I guess I never really thought about it, but how did they program the first CPUs? Like how did they overcome the chicken/egg situation?

When I was building embedded controllers with 6502 processors in the 1970s and 1980s we used UV erasable EPROMS and a programmer (my own design) with a ZIF socket built on an expansion board in an Apple ][. The prototype board also had a ZIF socket but the production boards would have ordinary DIL sockets, our production volume was too low to warrant ordering actual ROMS so we used the UV erasable ones and put a metallised sticker over the window.

All programming was done on the Apple in 6502 assembler. It took 45 minutes to assemble an 8kB rom image. This meant that you took extreme care to think about what the code was doing as assembling a new image was often the most time consuming part of the Edit-Assemble-Test loop.

Re: Write up of my homebrew CPU build

#24
post #5

> It’s a standalone tool that lives outside the computer. I put the EEPROM into the socket, and connect via serial to my laptop to upload the binary files. Huh, I guess I never really thought about it, but how did they program the first CPUs? Like how did they overcome the chicken/egg situation?

He says that's for microcode ROMs though? As opposed to a user program written in machine code that you would use the CPU to execute. I don't believe ancient CPUs had microcode. Everything was implemented in hardware.

Even Babbage's Analytical Engine had microcode.

Re: Write up of my homebrew CPU build

#25
post #5

> It’s a standalone tool that lives outside the computer. I put the EEPROM into the socket, and connect via serial to my laptop to upload the binary files. Huh, I guess I never really thought about it, but how did they program the first CPUs? Like how did they overcome the chicken/egg situation?

IIUC, that's what sci-fi LED panels of really old computers were. They showed all the internal statuses of the CPU as well as CPU-RAM bus. And the toggle switches allowed individual bit overrides.

The operator sets a CPU RESET switch to RESET, then powers on the machine, and start toggling RAM address and data switches, like HHLL HLLH HHHL LLLL. The operator then press and release the STEP push switch. The address 0b 1100 1001 is now set to 0b 1110 0000. This is repeated until the desired program or a bootloader is all complete. The operator finally sets CPU RESET to Normal, and CLOCK dial to RUN.

The CPU exits reset state, initializes program counter with reset vector, e.g. 0b1000, and start executing instruction at PC++. 1000, 1001, 1010, so on. Then oh no, the EXCEPTION indicator comes on, the LED shows 0b 1110 0000. That's divide r0 by 0, etc.

They didn't actually spend every half a day toggling those switches. They loaded their equivalents of bare minimum BIOS recovery code, then the rest wad loaded from magnetic or mechanical tapes. Only when computers were booted up blank slate or crashed and in need of debugging, the users resorted to that interface.

If they had the CPU-RAM main bus split into ROM and RAM address ranges in such ways that setting address to reset vector will yield the first byte of a BIOS program lithographically etched into the ROM chip, then simply powering on the machine will do the same thing as loading the BIOS manually.

There were also things like magnetic core memories. They didn't require lithography to fabricate, and there were both ROM and RAM kinds of those.

Re: Write up of my homebrew CPU build

#26

Earlier quoted context omitted.

He says that's for microcode ROMs though? As opposed to a user program written in machine code that you would use the CPU to execute. I don't believe ancient CPUs had microcode. Everything was implemented in hardware.

Even Babbage's Analytical Engine had microcode.

Would you care to elaborate? That sounds both unlikely (but I assume I'm just naive) and also interesting.

Re: Write up of my homebrew CPU build

#27
post #25
post #5

> It’s a standalone tool that lives outside the computer. I put the EEPROM into the socket, and connect via serial to my laptop to upload the binary files. Huh, I guess I never really thought about it, but how did they program the first CPUs? Like how did they overcome the chicken/egg situation?

IIUC, that's what sci-fi LED panels of really old computers were. They showed all the internal statuses of the CPU as well as CPU-RAM bus. And the toggle switches allowed individual bit overrides. The operator sets a CPU RESET switch to RESET, then powers on the machine, and start toggling RAM address and data switches, like HHLL HLLH HHHL LLLL. The operator then press and release the STEP push switch. The address 0b…

The pictures of workers weaving a program into core rope memory is peak steampunk vibes.

Re: Write up of my homebrew CPU build

#28
post #20

Earlier quoted context omitted.

He says that's for microcode ROMs though? As opposed to a user program written in machine code that you would use the CPU to execute. I don't believe ancient CPUs had microcode. Everything was implemented in hardware.

CPU's microcode can be surprisingly simple: The CPU has bunch of internal signals, which activates certain parts of the CPU and the logic when to turn each signal on comes from reading bunch of input signals. The microcode can be just a memory where the input signals are the memory address and the output is the control signals.

It's just that at some point when it's all physically wired up in hardware as opposed to being stored in some form of memory I have difficulty thinking of it as code or a program. By the time you're rearranging wires to enter a "program" aren't you actually refactoring the CPU itself?

Anyway I feel like the answer to the chicken and egg problem originally posed is to point out that things used to be different. Tools such as text editors and compilers are merely modern syntactic sugar.

Re: Write up of my homebrew CPU build

#29
post #8
post #5

> It’s a standalone tool that lives outside the computer. I put the EEPROM into the socket, and connect via serial to my laptop to upload the binary files. Huh, I guess I never really thought about it, but how did they program the first CPUs? Like how did they overcome the chicken/egg situation?

Actual application code was hardwired, entered manually with switches and lights, or with punch cards. Later, when ICs were sufficiently advanced, mask-programmed ROMs/PLAs.

Or diode matrix ROMs were pretty popular as well.

Electrically, essentially what happens in most mask ROMs, but as a circuit board that allowed you to solder in a diode or not in each bit location in order to specify a 1 or a 0.

Re: Write up of my homebrew CPU build

#30
The first image I saw gave me considerable anxiety and dread lol. I am so impressed, and have always wanted to do something like this. I took a digital logic course in university that was an absolute blast. I never wanted to stop there, but ultimately ended up doing so. However, just looking at all those wires made me feel a sense of, "Maybe I won't do this after all."
Post reply on HN