RCA 1802

General project related announcements and discussions. Events, other retro systems, the forum itself...
Post Reply
Posts: 44
Joined: 30 Sep 2020, 22:19

RCA 1802

Post by Sugarplum »

I started studying the RCA 1802. I am pretty sure the Gigatron can outrun it, even in vCPU mode. It was a somewhat odd CPU.

It uses 8 clock cycles in a machine cycle, and instructions take 2-3 machine cycles. That means it takes 16-24 clock cycles per instruction. The instruction length is 1-3 bytes. NOP only takes 1 byte but takes 3 machine cycles (ie., 24 clock cycles). I am not sure if that was deliberate to give other devices more time to access the bus or what. It has lines to let you know what the CPU is doing, so that makes it easier to negotiate with other devices on the board. It has 16 16-bit "scratchpad" registers. However, it only has an 8-bit ALU and accumulator. So if you need to copy 2 of the general-purpose "scratchpad" registers, you would need 4 instructions. You'd have to Get one byte, Put it, Get the other byte, and Put it.

The bit arrangement of the opcodes is rather neat. The high nybble is the instruction and the low nybble is the register that is involved. So 16 instruction groups that mostly work on the 16 registers, with a handful of exceptions where that doesn't apply. For instance, you cannot load via register 0 since the 0 is used for the Idle instruction which is much like a Halt until interrupt instruction.

Any of the scratchpad registers can be used as the program counter, and any can be used as the index. One thing that it can do like the Gigatron is advance the index register. There are no Call and Return instructions. Those can be emulated by changing the active program counter. So subroutines would need to know what the previous program counter was.

I've been playing with the notion of making a design that is loosely based on it. I think I'd want to sacrifice half the registers to have another instruction bit to add instructions to make up for its shortcomings. A Call and a Return would be nice. It would be nice if the accumulator was 16-bits, even if the 8-bit ALU is maintained. With at least 2 more instructions, one could transfer registers in 2 instructions rather than 4. Direct register to register moves would be nice, but that would be a challenge since you'd only have 3 bits. You'd likely have a choice of 2 and a choice of 4 of the 8 scratchpad registers. So multiple instructions (maybe 4-6) would be needed here to get full coverage.

Changing the lines might be good too. There are only 8 address lines for the 16-bit addresses. The In and Out instructions are apparently multiplexed onto the data bus.
Posts: 6
Joined: 03 Nov 2020, 11:42

Re: RCA 1802

Post by Flamore »

CDP 1802 <3
Pretty sure that the newer ones (produced after 2008) use about 1-3 clock cycles
Posts: 24
Joined: 10 Oct 2019, 14:28

Re: RCA 1802

Post by alastair »

Sugarplum wrote: 12 Nov 2020, 13:20 I started studying the RCA 1802. I am pretty sure the Gigatron can outrun it, even in vCPU mode. It was a somewhat odd CPU.
I worked on a v1802 implementation for a similar project, but switched to a v8080 on Marcel's recommendation :lol: The 1802 is a good fit for a virtual CPU since the overhead of managing the 16 registers is the same as the register constrained 6502. You can manage all those extra registers in the zero page with no additional slow down. A Gigatron vCPU version wouldn't out run the original though.

Marcel posted some performance numbers on the v6502 and provided an insight into the machine cycle speed:
marcelk wrote: 17 Jun 2019, 11:19 This simple benchmark suggests it does two 6502 instructions on average for each black VGA scanline. At the fastest video mode, this will be the equivalent of 125,000 cycles per second, or 8 times slower than the original NMOS chip at 1 MHz. Not bad for half the transistors that are in a true 6502.
The CDP 1802 was typically clocked around 2MHz, so 250,000 machine cycles per second with 8 clock cycles per machine cycle. Marcel's post suggests a Gigatron vCPU would run around 50% as fast, which is still impressive for an emulation.
Post Reply