I'm basically designing the SB2.5 in Kicad (learning Kicad as I go).

I will be adding on to the design with an audio chip, etc.

But for now, I have the CPU, RAM/ROM, glue, etc.

I would welcome any opinions on the design. Again, this isn't really my design at the moment but it will evolve into something a little more to my needs.

I will include the VIA's, serial, etc. at a later date.

Any opinions greatly appreciated!

_________________
Cat; the other white meat.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The circuit shown is pretty much identical to Daryl's SBC2.5 CPU/Memory/Decode section, so it would work. I did a similar design back in the late 80's using the same chip combo but 74HCT logic at the time. I use page $FE00 for the I/O. My current version retains this but uses 74HC logic and has run at 8MHz without issue using all WDC chips.

This said, I would agree with BDD's comments on the clock source, chip selection, etc. The "implied" memory map is pretty simple, ROM is from $8000 - $FFFF. Ram is from $0000 - $7EFF and the I/O decode from the 7430 is page $7F00. However, the 74138 chip won't be active as you have the enable lines configured incorrectly. E3 needs to be active high or no I/O selects will occur. In short, you should swap E1 and E3 and you'll have the same I/O decodes as Daryl's SBC 2.5.

http://sbc.rictor.org/sch2.html

_________________
Regards, KM
https://github.com/floobydust

Hmm...didn't see that for some reason. Good catch.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I probably stared at it longer... plus it's pretty close to my own CPU board

_________________
Regards, KM
https://github.com/floobydust

Everyone, thanks for the suggestions! You guys are great.

I have updated the PDF file on the original post.

I believe I have addressed most of the issues mentioned. First, the LS parts were just a foobar on my end. I always meant to use faster components.

I have upgraded the components to reflect that.

One that I was unsure of was the 8 input NAND. The fastest one I could find that wasn't near end-of-life was the 74F30. I believe it's a 5.5ns part and was reasonably cheap at Mouser. Not sure about the "F" part though.

Another recommendation that BDD mentioned was the counter/clock circuit. I've actually been thinking about doing that anyway. Perhaps putting a 4040 counter in there clocked pretty high and putting jumpers from the outputs to the CLK. That way, the user can jumper different speeds to the CPU and other fan-outs. I will work on that part next.

Oh, I think I fixed the memory decoding too. I had simply wired it wrong. I'm glad you guys caught that!

Finally, there is a memory map on there too. But it's Daryl's design so:



Any other suggestions are greatly appreciated.

Thanks!!!

_________________
Cat; the other white meat.

I would make a few other changes:

1- Clock rate: pick one... the main reason to change clock rates is the memory and I/O device limitations.
- a counter would give you multiple clock rates accessible, but you can also swap out the clock oscillator.
- a flip-flop (like BDD uses) will give you a true 50/50 duty-cycle clock, which is a plus.
2- I would change the I/O addressing so the selects are 32-bytes wide instead of 16-bytes wide. More options on I/O devices.
- you can use a pair of 65C22 VIAs with a single I/O select and a single inverter gate.
- you can use larger I/O devices, like a quad UART (again, a BDD approach).
3- Perhaps a NMI trigger (with another DS1813) so you can use it as a panic routine.
4- Add a RW-RO jumper for the EEPROM so you can write code to it insitu.
- I have this option on my CPU board and my monitor support supports it, nice to have.

Okay more than a few... but overall, will give you a more flexible CPU board.

_________________
Regards, KM
https://github.com/floobydust

Some of this aseptic. I'm not sure if you are after that kind of comment, but here you go anyway.

I miss busses. The CPU, ROM and RAM could easily be "bussed together". I personally feel this is clearer then lots and lots of labels, which run the risk of reducing the schematic to a netlist.

You have big AND gates.

My own preference is to draw the decouplers in their own "block" and put the pullups with the associated part.



These can be a lot of work though, with PLCC parts etc. Alternatively there are some nice DUARTs available, and if you hunt around you will find some in DIP.



Definitely strongly recommended. I can even work on my own ROM remotely, which is handy.

_________________
8 bit fun and games: https://www.aslak.net/

Minor update. I hope to finish much more this weekend.

I've updated the original PDF.

This update has a 74AC74 flip-flop tied to the OSC and O2. I pulled the circuit from Daryl's clock primer. Hope I did it right.

I also added a jumper block for WE on the ROM. I hope I did that right. But how would I program in-circuit? Is there a tutorial out there for that? I have one of those chip programmers that I use. So I'm not sure how I would do that. Unless the point is to have the 65C02 update ROM.



I need to learn how to properly do buses in KiCad. I think the lines going out to the thick bar looks pretty good. I don't think it's hard to do...I just haven't even tried. But I will look into that and see what I can do.



LOL. Yeah, I thought so too. But, those came straight out of the KiCad library. I haven't bothered to redo them. Then again, I have poor eyesight.




I don't like the way I represent the pull-ups. I actually like the caps near the component because in my head, it makes it easier to know they're there.


Suggestions always welcomed.

Thanks again!!

_________________
Cat; the other white meat.

Yeap, the CPU would do it. You have to be careful, obviously. Timing rules need to be honoured, and you cannot (generally) rewrite the same space your are running the reprogramming routine from. On my micro I copy the reprogramming routine to RAM, then run it from there. The schematic looks good.



Busses are just "graphical niceness" in KiCAD. The wire has the netlist name, instead of a label.



Me too.



Yes, that's a very good reason to place them nearby in the schematic. Being lazy, I just add a whole bunch to the schematic and then when it comes time to lay out the board, just drag any old cap footprint to the right place to make sure each IC has one.

_________________
8 bit fun and games: https://www.aslak.net/

Writing to the EEPROM insitu is fairly simple. You should reference the datasheet for the device you're using. I've been using the Atmel 28C256 EEPROM. It supports a byte write and a page write mode. In my monitor (which is posted out here) I use byte write mode and use the toggle bit for sensing which ensures the write has completed.

Note however, that the code that writes to the EEPROM can NOT be located in the EEPROM, as you don't have access while the chip completes the write cycle (which can be upwards of 10ms). You also need to turn interrupts off during the write sequence as well. My code sets up the variables, copies the byte write routine from ROM to RAM and makes JSR calls to write each byte, which also verifies the write. In short, I'm copying data from RAM to EEPROM.

_________________
Regards, KM
https://github.com/floobydust

How would you modify Daryl's SBC 2.5 decoding logic to do that?
Is it enough to remove the A4 line from the 138 and move the rest of the lines up one pin on the 138, if that makes any sense and then ground /E2?