65816 Pseudo-SoC

[Proxy]

Hi everyone!

Recently a Thread on here gave me an idea for a Project: (Post: "Arduino Nano-Sized" Logic Chip..ette?)
the idea being a full System (minus RAM) on a mircochip sized board, specifically a DIP package.
that's also where the name idea comes from. "SoC" means "System on a Chip", and while this isn't a full computer inside a chip, it is an almost full computer on a chip sized/shaped carrier board.

the system is planned to be powered by a 65816 with a VIA for some GPIO, and (gasp) no progammable logic!
so i chose DIP-64, the same package the 68000 uses, as it hopefully has enough pins for all signals and enough area to fit everything. (spoilers it didn't)

Code: Select all

Memory Map:
$000000 - $00FEFF - External ( 63.75 kB)
$00FF00 - $00FFFF -  Low ROM (256     B)
$010000 - $017FFF - High ROM ( 32    kB)
$018000 - $01FBFF - External ( 31    kB)
$01FC00 - $01FFFF -       IO (  1    kB)
$020000 - $FFFFFF - External (~15.9  MB)

IO Map:
$FC00 - $FC0F - VIA
$FC10 - $FFFF - External

doing the whole low/high ROM split does require a bit of extra logic, but it frees up bank 0 while still allowing for the ROM to be 32k in size, which is required to be able to reprogram it at runtime.

speaking of logic, as mentioned above i wanted to try out the LVC 1G/2G/3G logic ICs instead of something programmable this time. this also allows the SoC to run at 3.0-5.5V without having to swap out any ICs besides the Flash chip.

anyways, problem is that i've never really worked with discrete logic that much. so there might be some obvious mistakes i have made in my design.
plus there might be some ways to optimize the circuit to use fewer gates or spread them out more. currently the longest chain of gates is 8. so i expect the propagation delay to not be that great, and i'd like to reach atleast 16MHz with this.

here the current Schematic:

65C816_SOC.pdf

(153.54 KiB) Downloaded 108 times

i designed the logic in Digital, tested it, then went over the design again to use only 2/3 input gates, after another round of testing i remade it in KiCad.
so i'm fairly sure the circuit will work as it did in the simulator, but again there might be some mistakes here and there (like missing pull resistors or similar).
here the logic circuit:

I am using the same clock circuit as in my current 65816 SBC, but the WSE (Wait State Enable) signal doesn't come from a CPLD this time, and the LVC series doesn't have a JK Flip Flop, so i opted to use 2x D Flip Flops instead. i'm thinking about replacing U14 and U24 with a single 2G79 (dual D-Flip Flop) to save 1 IC, as neither of those require the PRE/CLR inputs or make use of the inverted output.

on another note, the Schematic doesn't specify the type of 74's ICs used for the 245 and 573, because i don't really know which one would be the best to use. HC, AC, or something else? i'm not sure.

also, depsite the SST39SF0x0 looking like a PLCC chip, the pinout is the same for the PLCC and DIP variant. and i think i will go with the DIP version, so programming the Flash for the first time doesn't require a PLCC to DIP adapter.

lastly, the connector J0 (which is the 64-pin DIP footprint) has the signals i want around it, but none of them are connected yet as they might move around a bit to make routing easier. due to a lack of pins i had to sacrifice some signals, specifically i removed CB1 and CB2 from the connector in favor of a second set of VCC and GND pins. it does remove some functionality from the VIA but CA1/2 are still around so it should be fine. (also i forgot to put any pull resistors on the CB1/2 pins, which direction should i pull them to if at all?)

i have already done a bit of work on the PCB itself, but i have to find a good placement for all the ICs to avoid excessive crossing of signals, plus i'd like to keep this a 2 layer PCB so i have to worry about GND and VCC as well.

.

but that is pretty much all i have right now.
any criticism/suggestions/ideas (especially around the logic and how i could make it better) are appreciated!
and of course any questions as well.

[akohlbecker]

Exciting project!

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.

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. The W65C265S has a full 24 bit data bus, includes a built in monitor and 2 pages of ram (zero page and stack), allowing it to be used without external RAM. It has built-in chip selects for external RAM and IO, as well as GPIOs and UARTs. With the board space saved, you could include an FTDI USB-to-UART with a USB connector, Arduino style, as well as external RAM. Of course the fun might be to figure out the discrete logic and supporting chips with a W65C816S, but I thought this warranted a mention given your size goals.

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.

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.

I spent a lot of time optimizing a "feature-complete" breakout board for the 65C816, which might be of interest to you (see attached).

[Proxy]

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.

[plasmo]

No, no, don’t delete your post. It may trigger ideas for others. My thought when I read this post is instead of RAM-less, breadboard-friendly DIP package, make it ROM-less breadboard-friendly DIP where the pin out is compatible with SST39SF0x0 so it can program the flash when stacked on top of a flash in a breadboard. I’m thinking about it…
Bill

[BigDumbDinosaur]

Proxy wrote:

Recently a Thread on here gave me an idea for a Project: (Post: "Arduino Nano-Sized" Logic Chip..ette?), the idea being a full System (minus RAM) on a mircochip sized board, specifically a DIP package...any criticism/suggestions/ideas (especially around the logic and how i could make it better) are appreciated!

I see a lot of cascaded logic, which is obviously going to get in the way of performance. If it were me, I’d confine ROM and I/O to a single bank. That would help reduce decoding granularity requirements. Furthermore, you should not saddle a potential user of this device with a lot of ROM. If you must do so, your logic should allow it to be mapped out and replaced with RAM.

Also consider that if you have any plans to run this unit at double-digit clock speeds, you will likely have to wait-state ROM and I/O accesses. The WDC 65C22 can run at double-digit speeds, but most ROM can’t, and the end user may also have I/O hardware that can’t keep up.

That said, I question the practicality of doing what you’re planning to do solely with discrete logic. I foresee the required logic as cumbersome, both in terms of prop time and accounting for edge cases, e.g., when or when not to invoke a wait-state. Also, unless you are prepared to use very small SMT packages for everything, I suspect this unit’s footprint will exceed that of a DIP64 package. I’d being doing this with a Microchip ATF1504AS in a QFP package to solve both the logic density and physical space requirements.

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.

I agree. Also, along with inner power and ground layers, you need multiple external VCC and GND pins to avoid voltage sags and ground bounce.

[BigDumbDinosaur]

akohlbecker wrote:

Did you consider using the microcontroller variant of this CPU?

Wouldn’t doing so defeat the purpose of this project? Also, the 65C256 is limited to 8 MHz. It might be possible to clock it faster, but who knows?

Quote:

The W65C265S has...GPIOs and UARTs.

What if the end user of Proxy’s device doesn’t want all that stuff?

Quote:

Consider finding a way to bring out SYNC to the DIP socket as it is helpful for single stepping.

The 65C816 doesn’t have a SYNC output—it has to be synthesized by ORing VDA and VPA, which adds more logic. More useful, I’d think, would to bring out VDA and VPA and let the user decided how to use them.

Quote:

I spent a lot of time optimizing a "feature-complete" breakout board for the 65C816, which might be of interest to you (see attached).

Do you have that in monochrome?

[Proxy]

BigDumbDinosaur wrote:

I see a lot of cascaded logic, which is obviously going to get in the way of performance. If it were me, I’d confine ROM and I/O to a single bank.

both ROM and IO are in Bank 1, there is just a sliver of ROM in bank 0 as well so the system can boot at all. it's pretty much the same as with my current SBC.

BigDumbDinosaur wrote:

That would help reduce decoding granularity requirements. Furthermore, you should not saddle a potential user of this device with a lot of ROM. If you must do so, your logic should allow it to be mapped out and replaced with RAM.

i mean with 16MB of potential RAM, and 512kB chips in DIP package, it shouldn't be much of an issue. the main reason the ROM is so large in the first place is to allow in-system programming, as that requires having control over atleast the bottom 15 Address lines of the Flash.

i could shrink the ROM to 8k and move it and IO into Bank 0. it would eat up some valuable space in Bank 0, and no longer allow for in-system programming of the Flash, but would make the logic much simplier.

BigDumbDinosaur wrote:

Also consider that if you have any plans to run this unit at double-digit clock speeds, you will likely have to wait-state ROM and I/O accesses. The WDC 65C22 can run at double-digit speeds, but most ROM can’t, and the end user may also have I/O hardware that can’t keep up.

yea i already implemented that. you can see the wait state logic in the Schematic and the image. i know from my own SBC that the Flash and IO won't run that fast.

BigDumbDinosaur wrote:

That said, I question the practicality of doing what you’re planning to do solely with discrete logic. I foresee the required logic as cumbersome, both in terms of prop time and accounting for edge cases, e.g., when or when not to invoke a wait-state. Also, unless you are prepared to use very small SMT packages for everything, I suspect this unit’s footprint will exceed that of a DIP64 package.

you can see the PCB i have made so far at the bottom of the post. the logic does fit, but the issue is just routing it all. and yes i plan on having JLC assemble the whole backside, so i'm using the smallest SMT packages they allow, and only have logic on the back. on the front you would still need to solder the CPU and VIA manually as they don't fit onto the back (plus LCSC, JLC's supplier, doesn't carry WDC's chips at all so they couldn't solder them anyways).

BigDumbDinosaur wrote:

I’d being doing this with a Microchip ATF1504AS in a QFP package to solve both the logic density and physical space requirements.

yea but i said i didn't want to use programmable logic this time because the 1G/2G/3G series looks really interesting, plus then i would need a JTAG connector somewhere, which is against the self imposed challenge of not having any other connectors on the board besides the DIP package ones on both sides.

.

BigDumbDinosaur wrote:

Wouldn’t doing so defeat the purpose of this project? Also, the 65C256 is limited to 8 MHz. It might be possible to clock it faster, but who knows?

yea it kinda does, but i also forgot that chip existed in the first place. i'm still thinking about shifting the whole project to instead be about an Arduino like board based around the 65C265.
while i can likely get better performance with this project compared to the 65C256, i can't compete in terms of size, features, or overall cost.

[Martin A]

Proxy wrote:

the main reason the ROM is so large in the first place is to allow in-system programming, as that requires having control over atleast the bottom 15 Address lines of the Flash.

If you're not bringing out CB1 and CB2, could you use CB2 for A14 to the ROM?

That would allow you to shrink it to 16k in the memory map, still have access to A14 for flash programming, and still have access to nearly all 32k through paging via CB2 if really needed.

[GARTHWILSON]

Definitely don't delete it!  I'd like to see your idea developed, even if it evolves a lot before becoming reality.  I've always liked the 64-pin, .9" row spacing DIP size for this kind of project.  You can also put parts on the motherboard between the two rows, under the IC (or in this case, your module).  I show a dense thru-hole SBC with a 68000 in the middle of the page at http://wilsonminesco.com/6502primer/CustomPCB.html .

But I have to keep coming back to the fact that putting two or three rows of pins on the same edge, with .100" row spacing, will make for better AC performance, and less room limitation, like I used for the 4-megabyte SRAM module shown near the top of the front page of my site which is 2 rows with 23 pins per row.  VME bus and, I believe, a couple of other buses also, use three rows of 32 pins per row.  Even without going to the full 32 length, you could get more pins, and you could fit the PLCC 65C265 if you like, because parts don't have to fit between rows.  You won't need to sacrifice signals.  Pins can be straight or 90°.

Quote:

i plan on having JLC assemble the whole backside

Let us know how that goes.  So far, I haven't ever used one of these cheap hobby prototyping houses for SMT assembly yet, only PCB fab.

[akohlbecker]

Proxy wrote:

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).

There is no difference with assembly that I know of.

Proxy wrote:

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.

It might be routable, especially at 45°, but it is a strech yes. It is a different direction for sure.

Proxy wrote:

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!

You might not need all the address bus exposed if you have enough built-in RAM, saving a few pins? Some lower address pins and some I/O chip selects could be all you need.

Proxy wrote:

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!

Thanks

Proxy wrote:

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.

Please don't delete threads, you never know what information might be useful to someone one day

BigDumbDinosaur wrote:

akohlbecker wrote:

Did you consider using the microcontroller variant of this CPU?

Wouldn’t doing so defeat the purpose of this project? Also, the 65C256 is limited to 8 MHz. It might be possible to clock it faster, but who knows?[

Quote:

The W65C265S has...GPIOs and UARTs.

What if the end user of Proxy’s device doesn’t want all that stuff?

I address this in my post by saying "Of course the fun might be to figure out the discrete logic and supporting chips with a W65C816S, but I thought this warranted a mention given your size goals."
Plus he did include a VIA on his board!

BigDumbDinosaur wrote:

Quote:

Consider finding a way to bring out SYNC to the DIP socket as it is helpful for single stepping.

The 65C816 doesn’t have a SYNC output—it has to be synthesized by ORing VDA and VPA, which adds more logic. More useful, I’d think, would to bring out VDA and VPA and let the user decided how to use them.

True, I thought the 265 had such a pin but I misremembered. It has a RUN pin that only outputs SYNC when in emulation mode

BigDumbDinosaur wrote:

Quote:

I spent a lot of time optimizing a "feature-complete" breakout board for the 65C816, which might be of interest to you (see attached).

Do you have that in monochrome?

Of course, you can find the schematic in B&W in the topic for this board viewtopic.php?f=4&t=7272

[Proxy]

hmm, alright i think i'll finish this project (or atleast get a working prototype) before moving on to the 65C265.

akohlbecker wrote:

It might be routable, especially at 45°, but it is a strech yes. It is a different direction for sure.

that might be an idea for another time. i only have 1x 65C265, and it's the PLCC version.

looking at what lcsc has in store, i can just baaaarely fit an IS61C5128AS (512k x 8bit) SRAM chip below the Flash. this means the module (i'll stop calling it SoC) wouldn't require external RAM to function. so the only things it needs to run at all is, a power source, a clock, and a reset circuit. the downside is that this will lock the module to run at 5V, unless you specifically leave out the onboard RAM and exclusively use external 3.3V memory. (and of course a 3.3V flash chip).

having a RAM chip onboard also makes the logic and routing more complex. so to combat that, i will move the ROM and IO into Bank 0, and shrink the ROM to 16k or maybe even 8k (leaving the address lines up to A14 to be controlled by the VIA). the VIA could also be used to disable the onboard RAM, in case external one should be used instead.

this would also free up some pins on the DIP connector, which would allow signals lile VPB, ABT, and VA (which is just VPA and VDA OR'd together) to be brought out.

i could also use a smaller RAM Chip. like a IS62C256AL (32kB x 8bit). it has more clearance due to having fewer pins. but it would only fill up Bank 0 half way, instead of completely filling 8 Banks. so you'd be pretty much forced to have external memory as 32kB isn't a lot for a 65816. so i think i'll try to make the 512kB chip fit.

akohlbecker wrote:

You might not need all the address bus exposed if you have enough built-in RAM, saving a few pins? Some lower address pins and some I/O chip selects could be all you need.

Yes i could lower the amount of external Address lines. maybe to 22 in total. A0-A21. that would still allow for up to 4MB (technically 3.5MB) of external memory to be hooked up. but would also free up 2 additional pins on the connector (maybe for one more set of VCC+GND pins)

if i go with the 16k ROM the new memory map would look like this:

Code: Select all

Memory Map:

$000000 - $00BEFF - Onboard RAM   ( 47.75 kB)
$00BF00 - $00BFFF - IO            (256     B)
$00C000 - $00FFFF - Onboard Flash ( 16    kB)
$010000 - $07FFFF - Onboard RAM   (448    kB)
$080000 - $3FFFFF - External      (  3.5  MB)


IO Map:
$BF00 - $BF0F - VIA
$BF10 - $BFFF - External

now i just have to redo the logic, and see what other packages lcsc has in stock. maybe i can use some BGA chips to save more PCB space?

i also think i'll be jumping over to 4 layers, just to remove the complexity of routing VCC and GND everywhere.

[Proxy]

alright i got 2 more pins free and opted to bring out ABT and VPB for potential memory protection/management circuitry or similar.
RWB would've also been an option for additional VIAs as there only are seperate RD and WR pins (which are gated behind PHI2).

while i did map the address and data pins on the RAM, ROM, and Connector to mostly line up with eachother, to avoid overlapping trace paths... i haven't done as good of a job with the logic ICs. i did group related ICs together and placed them roughly where the pins to the Connector for them are as well. but my autorouter is still having issues.

I changed the default via and trace widths to help with that. i checked JLC's capabilities (which are aparently slightly different for multi-layer boards) so it should be with spec.
if this actually works, you'd have an almost complete Computer (minus power, clock, and reset circuit) in the area of a 68000 CPU. not bad!

but for sanity reasons, before i actually put out the order (if the autorouter finishes within the lifespan of the universe), i just want a few more eyes on the Schematic to check for any mistakes that might still hide in there:

65C816_SOC.pdf

(161.94 KiB) Downloaded 82 times

i personally can't see anything obvious jumping at me.

[Martin_H]

This is an interesting project, and good luck with it.

I would add that a good 65C265 breakout board is something the hobby (or at least me) needs. I have the MENSCH which unfortunately lacks the chip select pins as a header.. This essentially cripples it for doing anything more than noodling, and lighting up the CS line LEDs as a reminder of what could have been.

Even a sixteen bit address bus with the 65C265 chip select lines opens up all kinds of options.

Given that I want something like this I should probably be willing to try and make it myself, but I haven't designed a PCB, and have only a tiny amount of experience with surface mount ICs. So it is currently outside of my ability.

[Proxy]

Short update, I finally got the autorouter to finish. I did change it to be a 4 layer board, but I had to sacrifice the VCC layer and make it a mixed signal/power layer for it to actually work.
And as a test I exported all nessecary files uploaded them to jlc, picked the correct parts, and went all the way to the checkout. Just to see how expensive it would be...

Result: ~100 EUR for 5 pre-assembled boards.
So that's 20 EUR per board, plus another 25-30 EUR for the flash, CPU, and VIA, making it around 50 EUR per fully assembled board.

That's pretty insane, especially if I were to sell these things pre-made and pre-programmed.
I sadly didn't look exactly at the individual part cost, but it was definitely a huge contributor to the total cost.
I'll redo the order once I'm home and get a more detailed look at it.
to see if I will actually order some or just throw the project on github and leave it for now and focus on other things, like the 65c265 board, or the plans I've been making around a tiny OS for my SBC. We'll see.