How exactly did you "enter it" without a second computer though? Was there a simple test rig or something that you would make as an electronics project, where you would input opcodes and ascii and it would write it to a rom? Only real thing i can think of.

The Apple II had a thing called the monitor, which was a tiny CLI program in ROM that you could invoke from the BASIC command line (CALL -151). With it you got the ability to disassemble memory (300L would spit out 6502 opcodes starting at address 768), set memory regions to sequences of hex digits (300: A9 21 20 FO FD 60 would write a tiny program on an Apple II Plus that printed an exclamation point, if my memory serves), and execute memory (300G).

With these three commands, and a working memory of the hex that corresponded to the opcodes, you could be reasonably productive writing short 6502 programs.

Fun and extremely niche fact: the typo CALL -161 jumped into the monitor, but only after the weird side effect of unhooking the sniffer that watched for DOS 3.3 commands sent via the ROM's text I/O. Not only did this make text print faster -- useful when you were visually dumping memory to the screen to find something quickly, but it also protected against accidentally destroying your disk if you unwittingly printed a sequence like ^M^DINIT HELLO^M, which would trigger the disk initialization routine.

Can't tell it for 6502... but for Z80. Because was my first own "computer":

* a single Z80 (which was nicer than 8080, because the latter needed an extra clock IC) * 256 bytes of static RAM * 1 8bit D-Latch (Flipflop) with 8 LEDs * 1 8bit D-Latch with 8 dip switches * 2 8bit buffers that can go tristrate between the hex-thingies and the address & data bus * 2 rotating hex thingies: you could rotate them between 0-f for data * 2 rotating hex ones for address

Now, how did it work? I pulled nBUSRQ down (bus request). This made the Z80 go tri-state. It also made my buffers non-tristate.

Then I used 2 of the hex-thingies to set the address and 2 of them to set the data. Now I set nWR to low and that would write the entered data byte into the SRAM.

When I was done, I turned nBUSRQ back to high, so the Z80 again was the boss of the bus. And then I simply used nRESET to low to make the Z80 execute my program starting at address 0.

I did only tiny programs, like adder, some PWN/sound wave program, an traffic light simulator.

But, since I soldered this all by myself, I had no "monitor program" like the KIM-1 had. So I had to do all of that by hardware.

RE "...How exactly did you "enter it" without a second computer though...."

You would use the "monitor program" to poke hex data into memory locations, starting at a nominated RAM memory address. Needed to be done VERY CAREFULLY. one bad hex digit and your program likely crash. After entering all the program into memory, you would use a monitor program , command to get tell the CPU to jump to a certain address and start executing a program there. OLD computer magazines often had such hex listings printed in them.

Front panel switches?