i should've mentioned before that the main challange of this project (or an SoC like this in general) is that everything should roughly fit into the surface area of a specified chip package (in this case DIP-64).
this means the PCB cannot be much larger than an actual 64 pin DIP chip, and there cannot have more than 64 pins on it.
though i'm already questioning the concept.... oof.
akohlbecker wrote:
At this size, a 4 layer PCB will be virtually identical in price (6€ vs 2€ per 5 units at JLC), and 4 layers gives you a lot of advantages for routing compactness and also signal integrity.
hmm, i might do a test to see how much it would cost with 4 layers. i don't know if 2/4 layer PCBs have any price differences when it comes to JLC's SMT assembly (as the logic in the back is not intended to be soldered by hand).
akohlbecker wrote:
Did you consider using the microcontroller variant of this CPU? It would reduce the number of supporting chips considerably, which might be useful at this size.
i kinda did at the start, but i also forgot about it's existance while designing this. this is pretty much just a RAM-less version of 65C265. just custom made, in a DIP package, and with a programmable ROM.
the PLCC 65C265 is too large, the QFP-100 version is a pain to solder (and just barely fits).
also it's only rated for 8MHz (and i have no knowledge of it ever being overclocked to reach +16MHz), it has a hardwired internal ROM that takes some extra steps to work around, and exposing all of the required address and data lines doesn't leave a lot of IO left.
overall i do want to explore the 65C265 a bit more... maybe this is finally the time for it.
akohlbecker wrote:
For logic families, I tend to gravitate towards AHC, which can run at 3.3V, if the timings let you afford it. From the DIP socket I suppose this will be used on a breadboard, and I don't know how LVC behaves in that use case, I have never used them. Look at their edge rates, AHC is pretty gentle. Most RAMs and ROMs are specced with TTL levels, so I made the data bus buffer an AHCT variant.
hmm, yea AHC seems like a good choice!
also while the design is breadboard friendly (which is mainly a byproduct of using a DIP package), it's not limited to breadboards. and i would expect anyone trying to push for higher speeds (like myself) to put it into a socket on a custom PCB.
akohlbecker wrote:
Consider finding a way to bring out SYNC to the DIP socket as it is helpful for single stepping. I'm also using BE quite a lot in my circuits but I also ensure my RAM/ROM WE/OE and data bus buffer and bank latch are tri-stated by BE, for example to do in-circuit programming of the ROM. You might not need that as much. I would build in the /RST circuit with an SMD button, and maybe an LED on E, which you can blink for troubleshooting.
well there really aren't any pins left on the connector where i could put those. i already had to sacrifice some of the VIA's pins, ABT, and VPB (which would've been useful for Memory Management/Protection circuits). so if you really need to single step the CPU you just have to do it by controlling the clock, counting cycles, and using the VIA's GPIO pins to send debug information.
Plus i don't really see a reason to bring out BE, if you need the SoC seperated from the rest of the System you can use some external tri-state buffers. and even if i did have BE on the connector, on it's own it's pretty useless as you also need access to RWB and VDA/VPA to generate the CS/OE/WE signals for the onboard ROM and VIA.
personally i would also like to avoid User IO (connectors, buttons, LEDs) on the SoC, as that would turn it from a MCU wannabe to an Arduino board...
i did mention wanting to do in-system programming (ISP) of the Flash. but i plan on having the CPU do it by running some copying function from RAM. (sadly programming the Flash while executing from Flash is not possible)
so BE is not required for that.
overall ISP is a finicky idea, as it makes the system able to brick itself... but the same is true for any in-system programmer unless it comes with a battery.
hmm, i have atleast 1 idea on how to avoid (or atleast reduce the chance of) the system bricking itself. maybe that's a good topic for another thread!
akohlbecker wrote:
I spent a lot of time optimizing a "feature-complete" breakout board for the 65C816, which might be of interest to you (see attached).
damn that's a beautiful Schematic!
it's defenitly more complete in terms of CPU signals, but i cannot really afford any of that due to the lack of PCB space and pins.
.
overall you kinda got me to reconsider my whole project. the idea was to have a Microcontroller like board in a chip package where you'd just need the chip, some RAM, power, and a clock to get it running. and if needed for another project you can take the whole module out without having to rewire anything.
but thinking about it, i don't really see that being a use case... even for me alone.
so maybe making an Arduino like board is a much better idea. that would also finally give me an excuse to use the 65C265 (or not if it actually just suck too much).
i'm not sure if i can just continue that in this thread though, or if i should make a new one and let this one die or delete it.