That TSR one is on mouser, and looking at it, it's a switching regulator? Will this possibly introduce noise into the circuit?

They're designed as a drop-in replacement for the 7805, so it's highly unlikely you'll notice anything. I've used them in various projects over the past few years and they "just work", however I've never tried to measure any noise from them - mostly because they just work... I suspect you'll see more noise, etc. from the rest of the circuit though.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

cool, not having to get heatsinks is a pretty big plus here (but how am I going to keep my morning coffee warm now?)

So as I was laying out the PCB, I was going through and sourcing chips as I placed them, I just now remembered that I had a problem with the EEPROM timing, because it's too slow (that is, the 28c256) at 150ns access time. After looking around, it appears the only option to go faster and still be through hole is EEPROM/flash in a dip 32 package, that's at least 1Mbit in size. The write procedures for these is sort of complex, and requires me to have some of the unused address lines held to specific values (because specific memory locations must be written to).....and in fact, now that I think of it it's actually not possible to write to these, because the address line that's constantly held high needs to go low for one of the writes in the sequence.

I suppose losing writability of the EEPROM here isn't a horrible thing, I just wish there was another option. Does anyone know where I can get faster eeprom that won't be impossible to write to?

You could consider accessing the EEPROM more slowly, using the RDY line... not that this results in a simplest-possible design. But if you clock at 4MHz you'd be fine, that would be simple. Get the thing working, and then move up to a design which does wait states.

I was reading about wait states earlier, and I suppose I could add in a wait state circuit, it looked simple enough.

I found an even faster one that's in PLCC package, but it has the same stupid write procedure as the other (it's from the same series). Basically, if I want the eeprom to be writable on the board, I have to go with an actual eeprom, that is going to be very slow

Wait states may be my one and only savior on this endeavor.

It was when I was browsing daryl's site earlier that I found it.

So all I really need to do, is incorporate his design for wait state generation, and pass RDY into a NOR with PHI2 to power the demultiplexing of the address and data busses, so they do not become corrupted when we're in a wait state.

Does this sound right?

I'm also considering NVRAM, maybe in a smt format (will need to put it on a removable board though. So I can pull it to program it)

This is the fastest I can find in a still sort of sane packaging. I'll need to figure out the board to put it on for allowing me to program it, but it looks pretty good (other than being 3.3v)

https://www.mouser.com/datasheet/2/100/CY14B256LA_001-54707_0K_V-769515.pdf

Something interesting I just realized, the RTC with watchdog I was looking at includes 32k NVRAM...I could potentially use it to replace my EEPROM, although the one issue is that the registers for time keeping and control are located at the top of the memory, right where the CPU would want to go on startup. I could potentially wire some address lines non-standard, so I could get into a different spot in the RAM to get my boot code, but this feels like a weird approach.

The option I mentioned before with the TSSOP pacage I think I'm leaning away from. It's definitely very fast and capable, but I feel like it will be a headache to install. There is a third option, Maxim offers the same RTC setup that I have but without the RTC or WDT, only the nvram. I could opt for that and use it as eeprom as well.

In fact, there's yet a forth option, I could use wait states to load a small set of instructions from slow EEPROM for loading boot code from SPI EEPROM (although, I'm not sure if this will be a net speed gain or not, it will just allow me to only use wait states for a brief period).

Lots of options, but I think being thorough in the design phase will give me a higher chance of success when I actually put it together.

So, the NVRAM and EEPROM are the same package (dip 32 I believe) so I don't have to make a decision now. However, I will need to add the chips for wait states if I go with eeprom.

With that said, I've got my first layout done, I've annotated it so you can see what everything is, thoughts?



EDIT: I'm also looking for ideas on board size reduction, getting this made through OSHPark would be very expensive (although I know and trust them, I may look elsewhere if I have to have it made, which is very likely at this point)

EDIT 2: also, there's 2 (that I've spotted so far) extra bypass caps, I was able to remove some chips but those caps haven't been deleted yet

There is also Ferroelectric RAM. It looks like it should be able to be written to mostly like an SRAM, but it's non-volatile. It might or might not be any faster than the EEPROM on writes. It should be faster on reads, but don't quote me on that.
You can get a 5V parallel one from Mouser, but it isn't cheap, and it only seems to come in surface-mount.

If I could get it in through hole that might be cool, I'll look at it regardless though

Instead of electrolytics, you can use ceramic caps for the MAX232. They're a bit smaller and you can't put them in the wrong way.

Alright, the docs for 28L92 integration had it with polarized caps, so I assumed electrolytics, I can swap them out though, that's not too hard.