Last visit was: Wed Oct 09, 2024 7:12 pm
|
It is currently Wed Oct 09, 2024 7:12 pm
|
JNK eX80 - A multi instruction set TTL computer
Author |
Message |
DockLazy
Joined: Sun Mar 27, 2022 12:11 am Posts: 41
|
About a year ago, on a whim, I started work on my take on a Ben Eater style computer the JNK-8. It ended up as a 6800-esque accumulator machine with a 16-bit address space and all the blinkin lights. This is it's current unfinshed state and design: It is built using my version of the deadbug construction style. It's more squished bug than deadbug, as the chips are the right way up and the pins are bent outwards like a flat pack. It's built using 'junk' parts so some of the chips like 74AS646 don't make a lot of sense. I was saving the good stuff for my main project. At this point most of the data path and control lines are wired up. It's missing the clock, memory, power, and all the discretes. The first reason it's not finished, for now, is that I messed up the endianness and put the temp register(temp microcode storage) on the A port of the ALU instead of the B port. I use the B port to load addresses into the address registers and since this is a little endian machine the LSB should be loaded into the temp register first. The second reason is I didn't really have a goal for this machine except to see some pretty blinkin lights. So I kind of ran out of motivation to finish, until recently. While doing some research I stumbled across the schematics for the famous Datapoint 2200, in particular the design of the ALU. It uses SRAM for a register file and a shift register as a hidden accumulator/temporary working register. It's a nice simple design that got me thinking... The drawings are here: https://archive.org/details/bitsavers_d ... 5/mode/1up if you are interested. It includes two versions of the processor. One of them is a serial design. Neither of them is microcoded. Well worth a look! That got me to thinking about the 8080 and then CP/M. As I think everyone here knows the biggest problem of building your own computer is the lack of software. Although software is a big part of why I'm building this computer. It would be really nice to run someone else's code, and CP/M via it's BIOS make this pretty easy on 80 series processors. I've had a bit of trouble deciding which direction to take this computer in. I want the fun of programming a retro 8-bit machine, but also want something that is more of a minicomputer with at least a 24-bit flat address space so I can have a real OS and self hosting compiler. I've gone backwards and forwards between these requirements way too many times. At this point I'm just going to throw in the towel and do it all. So this computer will support at least two ISAs. The first is a binary compatible version of the 8080 that can run CP/M. The second will be a custom register-memory machine, undecided on the register setup at the moment. I also might extend the 8080 instruction set at some point and add some high level language friendly instructions. Some of the Z80 might be an option as well that's if I need it for compatibility. On the hardware side this machine will be microcoded and semi-pipelined built from mostly F series TTL. The register file is pseudo 2-read 1-write port. It's made of single port SRAM chips which are shadowed to get two reads. Writes happen via time division multiplexing. The ALU and register file are 16-bits wide as is the databus to the memory controller. Address generation will be different compared to the JNK-8. I can unlock some parallelism by separating the program counter out of the register file. The counters I have on hand are too slow so this might become an address adder as well. I'm still undecided if I want separate address registers for the big ISA. Since the register file has plenty of space, fast context switching for interrupts and multiple threads might be possible. I think it would take 5 or 6 cycles to switch context mostly to just exchange the program counters and status flags. That's if I use status flags, compare and branch might be an option. The cycle time should be in the 100ns-70ns range. The rest of what makes up a computer will be packed into a Lattice MachXO3 FPGA. This includes a memory controller, graphics, IO for keyboards/controllers, SPI for NOR flash storage, and clock generation. For main RAM I have a heap of new old stock EDO DRAM and for graphics I have a couple megs of async SRAM. So my current task is to figure out the register arrangement and instruction encoding for the big ISA. I'm open to any suggestions, complaints, criticisms or any comments you might have.
|
Tue Apr 26, 2022 2:06 pm |
|
|
robfinch
Joined: Sat Feb 02, 2013 9:40 am Posts: 2187 Location: Canada
|
Love the register stack. Is that a copper clad board the IC's are mounted on? How did you strip all the magnet wire?
_________________Robert Finch http://www.finitron.ca
|
Wed Apr 27, 2022 3:08 am |
|
|
DockLazy
Joined: Sun Mar 27, 2022 12:11 am Posts: 41
|
I forgot to say that board will be put aside. This project is starting from scratch with a 300x300mm copper clad board. I might revisit it at some point when the shortages end. robfinch wrote: Love the register stack. Is that a copper clad board the IC's are mounted on? How did you strip all the magnet wire? Indeed, it's a lacquered(to prevent oxidation, not for insulation) copper clad board acting as a big ground plane. This particular insulation goes soft at soldering temperatures. So with a bit of flux I can dip the cut end into a solder pool on the end of the iron. The flux and solder works it's way under the insulation and with the help of surface tension you can peel the insulation back. Usually takes a couple of seconds. This only works with the low temperature magnet wire.
|
Wed Apr 27, 2022 5:01 am |
|
|
BigEd
Joined: Wed Jan 09, 2013 6:54 pm Posts: 1799
|
Oh, good spot Rob, I love stacked chips! (I posted a collection of photos over here) This is a nice construction, DockLazy - but I am very enthusiastic about building something enough like an 8080 to run CP/M. That gives you lots of software, and crucially it also gives you a self-hosting environment. And as we know, there's plenty of scope for extensions to the 8080, if at some point that seems attractive. And, nice link to all those Datapoint schematics! Both historical and intrinsically interesting.
|
Wed Apr 27, 2022 7:19 am |
|
|
alrj
Joined: Thu Feb 25, 2021 8:27 am Posts: 38 Location: Belgium
|
Impressive build, I love it! I understand very well what you mean about the lack of software when you build your own processor. This is by far the main reason why I'm making my processor an actual Risc-V, instead of something that is "mostly like a Risc-V but simpler to build". And this is also why BB-88, my previous project of a 8088 computer on breadboard, was kept mostly compatible with the PC architecture. Building a processor/computer from scratch is often enough work without having to write an assembler on top of that. And a linker. And a compiler. And an OS. And...
|
Wed Apr 27, 2022 7:36 am |
|
|
robfinch
Joined: Sat Feb 02, 2013 9:40 am Posts: 2187 Location: Canada
|
I find it harder to follow a spec and get all the corner cases correct, than it is to use my own spec. No worry about getting exact compatibility with your own design. Something isn’t working out leave it out. I guess it depends on one’s goals. Starting with an existing design is a great starting point. I started with a 6502 clone.
It is not too bad to bootstrap something original if you have good software skills and it can be a lot of fun. The secret is to make use of existing software. I was able to modify vasm to support the Black Widow in about a day. vlink, the linker, I have used out of the box a couple of times. I have an existing compiler that will not take more than a few days to modify. I get stuck at the OS stage though, not having a complete OS yet. I just copy the software from one project to the next and it “grows”.
I am more interested in the hardware though, so once I have things working to the point of displaying information on-screen and serial I/O working I tend to lose interest. If a core can execute the 1,000 line printf() routine while handing serial interrupts the hardware must be mostly working. One can spend forever trying to get software working.
I sometimes experiment with cores other people have developed. There are some good 68k, 6502, z80 and other cores on the web.
_________________Robert Finch http://www.finitron.ca
|
Wed Apr 27, 2022 9:54 am |
|
|
DockLazy
Joined: Sun Mar 27, 2022 12:11 am Posts: 41
|
BigEd wrote: Oh, good spot Rob, I love stacked chips! (I posted a collection of photos over here) This is a nice construction, DockLazy - but I am very enthusiastic about building something enough like an 8080 to run CP/M. That gives you lots of software, and crucially it also gives you a self-hosting environment. And as we know, there's plenty of scope for extensions to the 8080, if at some point that seems attractive. And, nice link to all those Datapoint schematics! Both historical and intrinsically interesting. Man I thought I was crazy, Timo and Duane are on a whole nother level, I'm going to have to step up my game! I have only scraped the surface when it comes CP/M software... I'm kind of surprised by the number of compilers available. alrj wrote: Impressive build, I love it! I understand very well what you mean about the lack of software when you build your own processor. This is by far the main reason why I'm making my processor an actual Risc-V, instead of something that is "mostly like a Risc-V but simpler to build". And this is also why BB-88, my previous project of a 8088 computer on breadboard, was kept mostly compatible with the PC architecture. Building a processor/computer from scratch is often enough work without having to write an assembler on top of that. And a linker. And a compiler. And an OS. And... That is an impressive breadboard setup for the BB-88, it's also why I want to pack the rest of the computer into FPGA, basically anything that isn't part of the processor to keep the size down. I'm actually not too worried about writing linkers and compilers. I just need a compiler that's functional enough to generate working code. Any hotspots I can replace with hand assembled code if need be. That's the cool thing about building things from scratch, you get to bend the rules and ignore the status quo.
|
Wed Apr 27, 2022 2:34 pm |
|
|
DockLazy
Joined: Sun Mar 27, 2022 12:11 am Posts: 41
|
robfinch wrote: I find it harder to follow a spec and get all the corner cases correct, than it is to use my own spec. No worry about getting exact compatibility with your own design. Something isn’t working out leave it out. I guess it depends on one’s goals. Starting with an existing design is a great starting point. I started with a 6502 clone.
It is not too bad to bootstrap something original if you have good software skills and it can be a lot of fun. The secret is to make use of existing software. I was able to modify vasm to support the Black Widow in about a day. vlink, the linker, I have used out of the box a couple of times. I have an existing compiler that will not take more than a few days to modify. I get stuck at the OS stage though, not having a complete OS yet. I just copy the software from one project to the next and it “grows”.
I am more interested in the hardware though, so once I have things working to the point of displaying information on-screen and serial I/O working I tend to lose interest. If a core can execute the 1,000 line printf() routine while handing serial interrupts the hardware must be mostly working. One can spend forever trying to get software working.
I sometimes experiment with cores other people have developed. There are some good 68k, 6502, z80 and other cores on the web. This is intended to be a long term project. Once the hardware is 'done' it will turn into a long term software project. It's intended to be a retro minimalist computer that has some fun programming constraints, with a sprinkling of nostalgia of course. The inclusion of the 8080 ISA was kind of an accident. From the get go I've tried to build a retro style instruction set, basically not RISC. But over time my designs tend to morph into large bit width RISC monstrosity. You know, I'd change a thing here because it might be annoying... It would be good if registers could fit an address, better change that. Load/store would save lots of opcode space, just a quick tweak. Suddenly you have a RISC machine. This time around I've immersed my self in old school architectures to get a feel for the design language. One of those architectures was the Datapoint 2200. As I mentioned in the OP that led me to the 8080 and CP/M, which seems to be having a bit of a resurgence in the retro community. Off the top of my head, the only warts I need to deal with are accessing 8-bit registers that are stored in the high byte of the register file, BCD, interrupts, and parity. Everything else is covered with microcode. I might be able to cover the Z80 as well, but the alternative register set makes that a bit of a pain. I could be wrong but I think CP/M should help a lot with the edge cases and since it's console driven timing shouldn't be a problem. The 8080 instruction set is actually quite nice as there's not much that needs to be removed. Intel hadn't yet damaged the instruction set too badly. The major changes I'd make would be to prefix or remove some of the conditional call and return instructions. I would also prefix a good chunk of the move instructions as the instructions that don't touch A or memory are hardly ever used. That would leave plenty of space for some two byte(8-bit opcode + 8-bit offset) base + offset instructions for SP and HL or an index register. I also have an interest in computer architecture as well, but I'm still waiting on a reasonably priced FPGA board with plenty of memory bandwidth.
|
Thu Apr 28, 2022 8:10 am |
|
|
BigEd
Joined: Wed Jan 09, 2013 6:54 pm Posts: 1799
|
DockLazy wrote: I also have an interest in computer architecture as well, but I'm still waiting on a reasonably priced FPGA board with plenty of memory bandwidth. There's a thread over on 6502 about FPGA dev boards - it could do with an update, not only because time has passed but also because of the current supply chain situation. Survey of FPGA dev boards
|
Thu Apr 28, 2022 8:13 am |
|
|
DockLazy
Joined: Sun Mar 27, 2022 12:11 am Posts: 41
|
Apologies, this will be a bit of a mess. Working on the big ISA trying for 16 general purpose registers first(1 is marked as the stack pointer but works as a general register). Instructions need to fit in 16-bits. Made up of an 8-bit opcode, 4-bit source/dest reg, and 4-bit source reg. Immediates/offsets will probably be in 16-bit packets. Since the opcode is 8-bit I'm using a spreadsheet to create an opcode map. It's a bit more work but it's more obvious if there are useless instructions (mov A,A) or any empty slots. Prefixes if I need them will be a byte wide. This is a register-memory machine. Mem ops can be a source and destination: Reg = Reg op Reg/Mem, Reg/Mem = Reg/Mem op Reg. There are three data sizes 8, 16, and 32 bits. For memory addressing modes there is just register + offset. A real register indirect would be nice as it would save a cycle and a couple of bytes, but I don't think it would fit. Fortunately it seems to be used only rarely. Some of the opcode space is wasted by encoding the data size of register-register ops. I might be able to get rid of the 8-bit register ops. The 16-bit ops are needed for speed as the ALU is only 16-bits wide. Compare and branch is looking more likely. There is still a carry flag but it's only affected by the add/sub with carry instructions. With support for 32-bit math ADC and SBC might end up getting the boot. Actually they might be a candidate for the first prefix instructions. On the hardware side. I'm going to use clock stretching for stalled memory access. Random access on the DRAM takes 104ns, and 25ns within an open 2k word row. As this will probably be the critical path address generation will require some special treatment. Currently memory fetch is this: RS/RD DFF -(12ns)> Reg file SRAM -(17ns)> temp DFF -(8ns)> adder -(35ns)> Voltage Translation -(6ns)> FPGA -(?ns)> VT -(6ns)>(address)DRAM(data)-(25-104ns)> VT -(6ns)> FPGA -(?ns)> VT -(8ns)> another temp DFF. That is about >120ns for the fastest case Which is terrible. I'll fix this later.
|
Sat Apr 30, 2022 12:50 pm |
|
|
Ken KD5ZXG
Joined: Sat Sep 03, 2022 3:04 am Posts: 51
|
Stacking DIPs I fully support. Remember doing that for both lower case and 48K in my TRS-80. But SOIC gets a bit ridiculous. Done that (once was enough) only now recommend to enemies...
You do not have the required permissions to view the files attached to this post.
|
Sat Sep 03, 2022 9:06 pm |
|
|
oldben
Joined: Mon Oct 07, 2019 2:41 am Posts: 649
|
DockLazy wrote: Apologies, this will be a bit of a mess. This is a register-memory machine. Mem ops can be a source and destination: Reg = Reg op Reg/Mem, Reg/Mem = Reg/Mem op Reg. There are three data sizes 8, 16, and 32 bits. On the hardware side. I'm going to use clock stretching for stalled memory access. Random access on the DRAM takes 104ns, and 25ns within an open 2k word row. As this will probably be the critical path address generation will require some special treatment. Currently memory fetch is this: RS/RD DFF -(12ns)> Reg file SRAM -(17ns)> temp DFF -(8ns)> adder -(35ns)> Voltage Translation -(6ns)> FPGA -(?ns)> VT -(6ns)>(address)DRAM(data)-(25-104ns)> VT -(6ns)> FPGA -(?ns)> VT -(8ns)> another temp DFF. That is about >120ns for the fastest case Which is terrible. I'll fix this later. The dark side says 8/16/48 bits. Why Dram, Static ram now is 258k by 8. Any eproms used 100 ns is the best you can find off hand. Right now I am redesigning using 16v8's for easy PCB layout and LS parts (low edge rates), but then you use have kicking around. At those speeds add +1 or +2 ns for signal transit time. I have had bad luck with FPGA's like the Altera DE1 (Cyclone II), as this one seems to be sensitive the phase of the moon for routing. I dislike VHDL and Verlog for logic design, and use AHDL by Altera, So myself I don't plan to use any more FPGA's, but a group FPGA design for a lower cost FPGA retro computer might be a good idea. I would put on two serial ports, and two standard sized SD card slots.(TTY and modem/ 2 floppy style drives for cp/m). Ben.
|
Sun Sep 04, 2022 5:36 am |
|
|
DockLazy
Joined: Sun Mar 27, 2022 12:11 am Posts: 41
|
oldben wrote: The dark side says 8/16/48 bits. Why Dram, Static ram now is 258k by 8. Any eproms used 100 ns is the best you can find off hand. Right now I am redesigning using 16v8's for easy PCB layout and LS parts (low edge rates), but then you use have kicking around. At those speeds add +1 or +2 ns for signal transit time. I have had bad luck with FPGA's like the Altera DE1 (Cyclone II), as this one seems to be sensitive the phase of the moon for routing. I dislike VHDL and Verlog for logic design, and use AHDL by Altera, So myself I don't plan to use any more FPGA's, but a group FPGA design for a lower cost FPGA retro computer might be a good idea. I would put on two serial ports, and two standard sized SD card slots.(TTY and modem/ 2 floppy style drives for cp/m).
Ben. I have a whole heap of new old stock 72-pin EDO drams, actually most of parts I'll be using are stuff out of my 'junk' pile. For SRAm I think 512Kx8 10ns was the sweet spot for price, at least the last time I looked. You can get SST39F NOR flash down to 55ns, 70ns in DIP.
|
Mon Sep 05, 2022 2:20 am |
|
Who is online |
Users browsing this forum: CCBot and 0 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|