I was only thinking aloud about the n vs p fets for an integrated fet driver. I haven't actually looked into that at all....
Well, for my discrete computer I plan to have four kinds of memory - why be limited to just one when you can make life harder. Since it's a Harvard architecture (I.E separate data & code memories) it makes kinda sense.
1) The Data RAM (8 bits wide) will be with discrete edge triggered D-style flipflops. They require a lot of parts for each bit to have good read and write speeds.
There will bi a metric shitton of pcb's for any reasonable amount of memory. I most def need a pick n' place machine. Just populating a few hundred pcbs in China will cost almost as much as a Neoden machine. And with SOT's and 0603's any neoden machine should be good enough even without vision.
The code memories (11 bits wide) I plan three different versions of:
2) Code RAM A two transistor memory cell with some diode overriding logic to force it to set itself into 1 or 0. This is rather slow for writing, but can give full read speed.
3) Code "EPROM". A less compact diode matrix with jumpers for each diode to set the bits.
4) Code "ROM". A compact diode matrix type memory with diodes soldered into a grid on the pcb. So when the monitor and commin library functions is done and debugged I can just transfer the code from the EPROM or RAM boards into the ROM boards.
WOW! and thanks for the information.
That's a VERY big commitment, to do all that.
How are you solving the following problem ?
The microcode decoding "ROM" ?
Possible solutions are:
(1)...There is NONE, you are using a different type of cpu model, such as "severe" RISC design. (severe is NOT the right technical term, but to differentiate between that and something which still might have a microcode ROM in it).
(2)...It will be hard wired diodes etc, like your EPROMs etc. But my concern is that it would be a REAL PAIN to debug it!
(3)...It will initially be "ram", so you can change it like crazy, for test/debug/development reasons. Then later either always initialize that ram, or replace the final code with ROM/EPROM
(4)...{Cheat} Use standard SRAM initially. Then when code is ready/complete/stable, you make another ROM/EPROM board, with the final debugged microcode.
(5)...Determine microcode via FPGA and/or simulator and/or emulator. So you can set the microcode in stone, early on.
My best guess now that I have typed all this stuff, is that there isn't any ?
I'm convinced 4 is NOT the right answer, and consider 5 unlikely.
Pity you aren't hand winding individual core memory elements. Then RAM/ROM/EPROM/MICROCODE etc, would all be one and the same.
Also I know where you live now. I just need to borrow a thermal camera (from the other thread), go approximately to your location, then when your computer is finished and on, I'll search for the place, emitting HUGE amounts of heat.
Or just ask the locals, whose place has the slowest computer, possible.
Then enjoy seeing and discussing your new, self build/design computer. As I love stuff like that.