Basic Specs/changes vs 6809:
* 8-bit data / 24-bit address.
* Microcoded, 8-bit instruction packets.
* SRAM based control store.
* 16-bit ALU and internal data path.
* All address registers extended with 8-bit page.
* DP(zero page) register deleted, along with associated instructions. This includes extended direct(I expect it's use is rare enough to be a waste of opcode bits.)
* Add E and F accumulators from 6309.
* Binary compatibility is out the window so a mix of 6809 and 6309 opcodes will be shuffled around. In particular the register to register 6309 ops should be on page 0, along with the new registers.
* Little endian, none of that big endian devil business here.
* Logic design is going for simplicity. So similar CPI to 6809. To compensate the clock will be at least 10Mhz.
* Vectors will be 0x00xx based instead of 0xFFxx

Thoughts/stuff under consideration:
* Probably won't bother with the DAA instruction.
* Indirect addressing is on thin ice. For a compiler I'd rather it stored the de-referenced address in a register/stack as accidentally using this mode in a loop would be disastrous for performance.
* I want to port Unix v6 at some point. So a supervisor mode and stack will be added. This might include an MMU for address translation, don't know if it's worth the cost in complexity.
* Going into this I was expecting to at least maintain assembler compatibility so I could port some code. One of the first things I wanted to port was BBC Basic. I spent a few hours today looking into this... Yeah a port is not happening, way too much work. Instead I'm just going to straight up recreate it, much less work. Backwards compatibility was probably a pipe dream.
* I might change to x86 style accumulators, ax=16-bit/a=8-bit instead of D16=A8+B8. That would give me an extra 16-bit register.

For graphics there will be two separate bitmap layers. The first is intended as a background layer, that has hardware scrolling via presetable counters. The second is the foreground layer intended to emulate sprites. It's special feature is transparency using a transparent colour key of 'zero'. This colour key controls a 2:1 MUX. Basically any zero pixel in the foreground will be replaced by one from the background layer.

All the actual pixel moving will be done in software. In addition to the 6309 block move instruction(3 cycles per byte) there will hopefully be a fixed 8x8 block memory move(2 cycles per byte) and a fixed 8x8 register to memory copy(1 cycle per byte) that will be used for single colour fills and erasing sprites(zero fill). There are some problems with interrupts and line offset with these 8x8 instructions, I'm just going to pretend they don't exist for now.

Although this graphics hardware was designed for TTL this will be handled by an FPGA. The most important benefit is protecting my sanity, as simple as the above is, it's a lot of chips. Native resolution will be 720p for modern monitors. This divides nicely to 640x360 for text/static images and 256x144 for games. 1 MB of SRAM.

Also the FPGA will generate a clock for the CPU.

Audio will be a computer controlled analog synth, similar to the Commodore SID. That's far in the future though.

It might be better to design it as 16 bit machine, with byte addressing, than having 8 bit encoding.
8 registers + PC seems a nice option. (R),(R+),R,(R INDEX) seem to be minimum addressing modes
if you have a push. A reg for (R),R / PC for (R+, 0+INDEX),

I've been analyzing the cycle times for various instructions for 6809 and 6309 native mode. I was hoping I could match the cycle times of at least the 6809, but it does some things that make that difficult.

Firstly, to keep chip count low I want to use a 1w-1r register file made out of DFFs. Also I want the PC to be part of the register file. Previously I read that unlike the 6309 the 6809 didn't use pre-fetching. However some instructions do overlap execution with instruction fetch, like ADDA immediate(A = A + i8) it's 2 cycles instead of the expected 3. The problem is I use the ALU to update the PC, so can't overlap execution. If I were to use counters for the PC it's an extra 9 chips(6 x '163 + 6 x '244/'245 vs 3 x '574), almost 50% more chips for the register file.

There's a couple of problem instructions that are too expensive, PSH/PUL. The 6809 uses an 8-bit bitmask to select which registers should be pushed on the stack and it only takes 1 cycle per byte pushed. Brute force worst case that's 256*8 micro instructions. I don't have a solution for this yet as doing this with hardware costs too many microcode control lines.

I thought about increasing instructions to 16-bit for convenience.

But you might need to define better. As is, a stack relative 16-bit add is 6 cycles compared to 68k which is 12 cycles. 16-bit register to register add is 3 cycles vs 4 for the 68k. The bar is set pretty low.

Better for me is a 16 bit instruction to have byte and word data.
8 bit cpu's need tricks to have both word and byte data.
With my computer the memory model is for core style memory,(18 bit data,mar, word aligned memory)
1st cycle load mar, 2nd cycle read/write memory. Instructions tend to be 2,4,6 ... cycles long with a 1.25
Mhz clock. For me getting it to work is more important than cycle counting. A register op is 3 cycles,
put reg on data bus, read input
pc ++ to mar,
do op, fetch new instruction.
register swap is 4 cycles.
Getting it working is more important than bean counting.
Ben.
PS. My timing is for easy baud rate generation,

Yes, this is a good idea. The engineer in me wants to optomise things.


I'm not restricted to 8-bit long instructions. The only restriction is that only one 8-bit packet can be processed per cycle. Instructions can be 4+ bytes long.

I'm using a more traditional microcode 'engine'. There's no step counter instead it uses a next instruction field. There's a mux to select between next ucode instruction pointer and the IR and a few extra bits to keep track of state. So you can feed in bytes to the microcode as needed.

I've been thinking a bit about virtual address translation and if it's really needed. It's quite costly in chip count, and the upper address bits are the critical path for accessing memory as they drive the chip select decoders.

The alternative is lock and key memory protection. I'm not sure how this was originally implemented. In this case it will be a single SRAM chip holding the lock for every page for every process. This is a simple bit check that can happen in parallel with memory access. In supervisor mode this SRAM can be mapped into the address space with a mux for updating, along with a '245 on the data side.

There are downsides to this approach:

1. Memory fragmentation will be something programs need to deal with.
2. Guard pages have to be backed with physical memory.
3. No fancy features like copy on write.

Have you looked at cache memory chips, the tend to be like 32Kx9 wide at 10 ns.

Most of the SRAM I have on hand is 10-15ns, of various sizes.

I do have a couple of cache chips but they are 32-bit and synchronous.

The problem is the number of chips required for routing. The page table needs to be bypassed and you need a mechanism to write those rams. It's one of those things that appear simple but end up using quite a lot of chips.

That's ok though. Memory protection/virtual memory isn't a requirement, it's just a convenience to catch bugs that Ill be making.

Memory is cheap, just give the full 64 Kb of ram per process segment.
Can you split program access from data access? 64Kb code and 64Kb
data does most things.
The OS/9 mmu chip can be still found, but it is big 40 pin dip.

Every address register has a page extension. So I could easily do 192KB per process I+D+Stack, this is plenty for retro games and what not. Realistically I'll probably only have one large memory process running at a time, of the top of my head that's probably just a text editor or compiler. So in practice memory fragmentation with lock and key memory protection shouldn't be an issue. I really should make a post about the goals for this project.

Also I have the option of adding support for full 24-bit addresses using microcode, if I need it.

I've decided to take a different tack, and will be including a second processor.

It will be a SAP based design, 20-bit address(16-bit + 4-bit page) and 8-bit data, clock probably <4Mhz, all the blinkenlicht. It will be built first and eventually become a peripheral processor, but to start with will be heavily involved in the bootstrap.

Instruction set will be vanilla 6809 where possible, with the addition of a load page register instruction. The SAP is supposed to use an 8080 ISA. I thought about going in that direction, but the 6809 ISA is just too nice.

Speaking of bootstrapping, there will be no cross development what so ever. This includes the microcode ROM. Programming will be with a custom made hex keypad/bus monitor.

I've identified a couple of things in the 6809 ISA that are going to cause some problems. The push/pop instructions, and the indexed addressing post byte. Mostly because I can't use the usual brute force method of using lots of microcode.

For the push/pop instruction the 6809 uses a post byte bitmap to select which registers should be pushed or popped, and it's fast at only 1 cycle per selected register byte; plus setup.

In this case each byte would take a couple of cycles to calculate the address and one cycle to read/write memory. So it could take almost 40 cycles to move all eight registers. I think this will add too much interrupt latency. So I'm going to use individual push/pop instructions for every register.

For indexed addressing the first instruction byte contains the operation and the second byte is used to calculate the effective address. The problem here is that the instruction can only be processed one byte at a time. Normally some state can be stored in the microcode address bits to be used later, but this uses a large amount of ROM space. The fix is to have a 16-bit instruction register and a mux to select the appropriate byte.

How about 2 kinds of push/pops. 1) single reg using --R/R++ 2) special op that pushes/pops all but D and S.
I think that would cover 90% of the operations on a 6809.