Bloggidy

Since presettable 16-bit up/down counters are impossible to find, maybe the data and return stacks ought to be limited in size, with the high 8 (data stack) or 12 (return stack) bits being in a separate register.

It might be interesting to add some basic security features to the system that would allow implementation of processes. For example:
– only “ring 0” (which could be the code in the lowest 4K for example) can directly modify the data/return stack pointers or else an interrupt would trigger
– a page table that maps, say, 4K worth of memory from anywhere in the 64K ram to 0x0000 – 0x0FFF, and this is the only region the process can access
– By making “ring 0” be the code that executes in the first 4K of RAM (for example), things like UART or I/O functions might be accessed by special mechanism – software interrupts (DOS style) for example. Alternatively, I/O ports (to which the UART would be connected) could be mapped through a paging mechanism also.

Eureka! A first draft of the bootstrap circuit that extracts the BIOS from a serial EEPROM and dumps it into the SRAM is done:

It obviously doesn’t include other circuitry yet to align it to the rest of the future system (like OR gates on the SRAM /CE for example), and it’s untested, and I think I forgot to connect the data counter’s /RCO to the BS_DONE flip flop, but other than that…

I guess it would be doable to just have a 3-byte instruction that loads a data word from a literal address to the stack? Basically it would be a slightly optimized form that doesn’t first put the address onto the stack itself:
1. Decode first byte of instruction, push TOS
2. Move first address byte into the high byte of the SRAM address latch
3. Move the second byte into the low byte of the SRAM address latch
4. Latch the SRAM data bus into the TOS register

Would it make sense to have some sort of paging for literal SRAM access? Basically, have the high N bits of the address be adjustable through a separate register and then have the remaining bits encoded in the instruction.

On second thought: 8-bit data/instruction bus makes for happier times. From a usage point of view, 16-bit is pretty silly in a microcontroller. Either you can get away with 8 bits (and use software for 16-bit operations), or you need 32 anyway.
So anyway:
Four 16-bit counters.
1) Preloadable, up only – for instruction counter – must be tri-state – its output feeds into the address bus of the 2^16B = 64KB SRAM. This counter is used to fetch the next instruction (or the next byte of a 2-byte instruction)
2,3) Preloadable, up/down – for data and return stack pointers, respectively. Can be re-written on the fly to switch between threads! These are also tri-state, and feed into the address bus of the SRAM.
4) Up only, maybe with prescaler? – used for system counter, to time things etc. Tri-state, connected to data bus.

Also: a boot loader consisting of an 8-bit parallel-output serial-input shift register, connected to a prescaler and a serial EEPROM on the serial side and the SRAM data bus on the parallel side, and a counter connected to the SRAM address bus. When the “chip” comes out of RESET, X bytes (hard-wired? DIP switch configurable? software configurable?) are read from the serial EEPROM and written into the first X bytes of the SRAM. After this is completed, execution starts from location 0 (the reset vector), which is where the boot code was loaded to.
The boot EEPROM would probably also be available to be written via another shift register, but this can sit on the I/O bus (which may or may not be the same as the memory bus).

Not entirely sure how one makes timing work in such a system… I mean, if a few different things are loading down the address bus, for example, and/or there are some things gated into memory, there must be quite some skew between the address bits. So how do you account for that when generating signal timings? I guess for gated things, the address lines are just fanned out and what’s actually gated are the chip enable/chip select signals, which can (and probably should) arrive later, anyway.

Target frequency for this whole mess is in the 10MHz range, btw – though I may take that down to 2-4MHz if I feel like it. (Obviously, real world applicability and performance are not huge concerns here.)

The only drawback with an 8-bit data bus is that a memory read will look like:
li [high byte]
li [low byte]
la ; read data

and since the instruction size is only 8 bits, li would have to be a two-byte instruction, meaning it would take 5 cycles to load a byte of data. Maybe a 16-bit instruction size would be better? But that seems excessive, since it will be a pretty small instruction set, and there would be a lot of wasted space with 16 bits.

There COULD of course be an instruction that simply reads the next N bytes out of the program into the data stack. That way, program memory would look like

[read 2 bytes to dsp]
[byte 0]
[byte 1]
[load data]
[…]

Though that would lead to a almost micro-code like execution, which would be more difficult to implement in a LSI circuit.

I’ve been playing with the idea of designing and maybe actually building a stack processor (that is, a processor that, rather than a bunch of registers, has a data stack as its primary local data storage), using 7400-series and similar ICs. Obviously this is not practical in the least, but it could be quite fun.
The idea is to use discrete ICs to implement every aspect of the processor, like so:
– 4x 74181 chips would form a 16-bit ALU
– a 16-bit register would form the top-of-stack (TOS) register
– a 64K dual-port SRAM would be the memory (dual-port so that both data and instructions can be read simultaneously) – this would include instruction memory, the stack itself, and data memory.
– a 16-bit binary counter to implement the PC
– a serial EEPROM for the BIOS
– some random peripherals – some 7-segment LEDs, a UART, maybe an LCD
– a shitload of gates to implement the control unit/address decoding

Madness.