6502.org

So I finally (at the age of 29) finished designing my first computer. It is 65(C)02 based with the following features:

• 6502 Processor.
• Built-in Reset feature.
• Power on and power off button.
• Programmable Instruction Decoder. (Use the dedicated ROM to program the instruction translation. E.g. invalid op-codes -> BRK)
• Prioritised maskable interrupts.
• 65SIB port.
• USB type B port. (For PC communication.)
• 22-pin GPIO connector.
• ATX power supply. (22 or 24 pin.)
• 3 processor clock speeds available.
• Bank switched RAM. (16 banks.)
• Bank switched ROM. (16 banks, 1 shared.)
• Processor bus expansion slots. (To be used as a slot for add-on cards that are added straight to the board. NO CABLES!)

Available under an Open Hardware license, on GitHub at: https://github.com/TheAlmostGenius/WolfNet-6502-WBC

Documentation available on GitHub at: https://thealmostgenius.geekgalaxy.com/WolfNet-6502-WBC

Any comments, ideas, suggestions or corrections can be posted in the discussion on the GitHub repository here: https://github.com/TheAlmostGenius/Wolf ... iscussions.

Welcome and thanks for sharing!

Welcome! Sounds like an interesting list of features.

I would like to learn more, but unfortunately I'm finding it an uphill battle. I discovered a README and a FAQ, but was unable to locate any detailed description. I mean prose, not just design files. Is there nothing that talks at least briefly about the features -- how they'd be used, and perhaps the benefits you anticipate? Perhaps the desired material is there but I simply failed to find it.

Congratulations on your project just the same.

-- Jeff

Id love to learn more. But I second Jeff. Can't find any design info or even schematics readable on a mobile. There's only one html with the memory map but that does render as source.

What bus design do you use? RC6502?

André

Edit: I know preparing a design for publication with full docs can take quite some time. I learned that it helps me validate if even I understand my design as good as I should. Found one or the other bug while writing docs... also helps foster discussion and valuable feedback from others

I see there's a nascent mini-site built from the docs in the repo, which might be worth reading and keeping an eye on:
https://thealmostgenius.geekgalaxy.com/ ... -6502-WBC/

Well, looks like he used KiCAD for schematics and PCB layout.

I noticed a few areas of concern:

1- BE line on CPU is left floating, should be tied to Vcc via a pull-up resistor.
2- Using a W65C51N for UART, unsure if he realizes that part has a bug.
3- Separate address decode circuit (multiple chips for each) for every I/O device.

I counted 53 chips... and a very large PCB.

You need to be a lot more careful with the mains voltage there. I don't know much about that - only enough to avoid doing it myself - but I'm worried that you have very little clearance between the mains traces and each other (they cross on opposite sides of the board for example) nor between mains and the ground fill. Any faults may not be protected by the on-board fuse because they might occur before the fuse.

I believe you should separate the traces more and consider adding cutouts between them if they do need to pass close by each other. There ought to be a MOV or neon or some other kind of surge protection as well, and you ought to also physically shield the area with the mains voltage using a grounded shell.

It's also a linear power supply which is heavy and inefficient. Overall life is much simpler (and safer and hence possibly longer) if you just use an external PSU and keep your circuit low voltage.

Wow four separate inverters for A15, three separate inverters for A14. UART address selection does not include A10 and A11 ... which makes for a strange mirroring that may conflict with other parts.

This looks all strange. The select seems to be all made with only the specific target in mind. All that could probably be replaced by a few 74ls138..

Really could use some rework regarding resource use. Maybe pcb costs are low enough and chips fast enough today to allow for such a design to be cheap enough and workable, but it certainly is not as good as it could be

Documentation will be done very soon. That seems to be the most requested thing other than making existing documentation readable on mobile. To that end I have so far been using GitHub Mobile and the readme is meant to be accompanied by the other *.md files. May end up making .pdf documents as they are almost universal now. Having already optimised this from over 90+ parts. (Mostly glue logic that was easily replaced with more efficiency AND less chips.) I feel confident that I can further optimise and bring down the chip count. You are right as well, it is a big PCB. (2 ATX boards side-by-side.) Schematics will also be available for those who are colour-sensitive or colour-blind in a black and white format. (I got you BDD.) The mains circuit will now be scrapped as well in favour of an ATX power supply. (There are lots of these around so they can be very cheap.)

Oh.. and as for the bus, it was mostly arbitrary and changed as the design has evolved... However, the ideas are now flowing.

Thanks. Looking forward to some more info.
Regarding the bus, maybe you should consider using an existing bus design to be able take advantage of existing card designs

Oh and if you use decently sizes chips, like a 512k RAM and larger ROM chips you might also save considerable chip count, board space and cost

I was redesigning the address decoding using the 138s and it occurred to me that the 65C22 could drive the extra address pins on larger chips rather than using is as a chip select. As for the existing bus design, could anyone recommend one that has a similar pinout that would be compatible? (I don't mind moving pins around or adding some in but I don't want to really lose any...)

Did you have a look at rc6502?

Also, I just noticed all the interrupt lines on the bus? Why not a single interrupt line per slot and the slot number determines the priority?

Here's the Rev 2.4 schematic converted to monochrome... hope this is easier to read.
I think it would be a good idea to read through some of the datasheets on the various chips. You still need a pull-up resistor on the BE line for the CPU. Also, if you're not planning to use a non-WDC processor, you can delete the jumper for VP going to ground.

You can also replace the 555 timer and inverter for the reset circuit and use a single DS1813 supervisor chip, saves space and a lot of components. I'm not sure why you have so many different ROM banks, but perhaps you can give us some logic on how you plan to use them. As already noted, you can easily use higher density memory chips and reduce the count. If you have plans on banking memory (RAM and ROM) you might want to look at the 512KB ROM/RAM card on the RC2014 stuff... the same approach can be used for the 65C02 as well and would likely be more efficient than what you already have.

If you have the ability to program a PLD (ATF22V10 comes to mind), you could replace a lot of decode logic chips with one or two of these and delays will be much less. Also, you show a selectable clock rate for the CPU of 8-, 4- and 2MHz. Yet, your expansion connectors only show the 8MHz clock. Logically I would think you would want the same clock that's driving the CPU to be routed to the expansion connectors. Then again, we really don't know how you plan to use this setup and what expansion cards are planned, etc.

I would also recommend you ditch the 65C51... any non-WDC parts (sans the xmit bug) will be limited to about 4MHz (if you can find 4MHz rated parts). Going to an NXP SC29L92 DUART would make more sense and give you additional function as well. If you plan on using a UART channel to communicate to a modern PC, note that there are UART to USB adapters than can be mounted on board and reduce the chip count further and have a nice high-speed serial connection.

Finally, have you developed any software for this project yet? Did you do any initial prototyping with some code to make something work so you have an idea on how to get the software side started? Starting with something small at first usually gives you some good insight on how to grow the project.