Hi everyone!
I discovered the 6502 and this forum several years ago, and in March 2020 designed a SBC. It is functional, but I really didn't know what I was doing at the time so it has many, many flaws. I am also very bad at the software side of things, so the most sophisticated program I wrote for it was a 4-function RPN calculator using a text terminal.

I set that SBC project down last year as life got busier, but recently my interest was rekindled while I was cleaning off my workbench and stumbled upon a partially-designed VGA interface for the computer which I was working on a while back (but that's another story.) So, I got back into things, pieced together the design and finished the VGA interface... which upon hooking it up to the 6502 did not work very well owing mostly to the poor design decisions.

So, I began a new design, and resolved to do it the "right" way this time.
Also being a massive avgeek, the suffix "-neo" seemed appropriate for the slightly retooled design, at least for the time being, and I also never gave the original a formal name. Thus, 6502neo was born.

Here are the (slightly ambitious) goals/project outline:
- 65c02 running at 14mhz minimum, ideally 20mhz or higher
- At least 512k of RAM (yes, this means banking)
- 2 VIA's for general purpose I/O
- UART for serial interface
- Additional I/O space available for expansion

To meet the speed goal, address decoding had to be greatly simplified from my first design, which could decode all the way down to 16 byte regions of memory. I came up with this memory map for the new computer:
RAM: $0000-77FF (30k)
I/O: $7800-7FFF (2k, 1 page per I/O device)
Banked RAM: $8000-BFFF (16k*32 banks)
ROM: $C000-FFFF (16k*8 banks)

This keeps all decoding in the upper 8 bits of the address, and most decoding can be done with only the top 2 address bits. Furthermore, I have decided to mostly use 74LVC series components, which are even faster than AC, and I can place them as close to the memory/IO device as possible, hopefully reducing load capacitance and therefore prop times (although I may have a flawed understanding of that.) The -LVC series also has combination/configurable gate options which are also used to cut down on prop delay. This allows decode times comparable to programmable logic, with the slowest access time being 12.1ns for the I/O select lines. ROM is selected in 4ns, Banked RAM in 5.1ns, and the low RAM in 7.8ns. Pretty good in theory at least...
The ROM chip I am using is the 39sf040-55, so a relatively fast access time of 55ns. Even so, going by the book with the timings, it will only be able to reach 10mhz without technically "overclocking" it. The principle I am going by with the clock speed is that I should design the system so the only part I need to "overclock" for it to work at higher speed is the CPU itself, and I am assuming the timings given by the datasheet scale linearly, even though this is an imperfect way to view things. So, I plan to use the clock stretching circuit designed by Dr Jefyll using a '163 timer to allow the ROM accesses to happen at effectively half speed compared to the rest of the system. The UART (A 28L92) will also receive a clock-streching input selector to allow it to run slower, although it may not be needed.

Memory banking is handled through one of the 65c22 VIA chips, where Port B is connected to the upper address bits of the ROM and Banked RAM. This allows for decently simple bank switching. There is also a second VIA on the board for I/O as well as the aforementioned 28L92 UART. I am also running the processor buses to a connector, which is not perfect, but I have placed plenty of ground pins throughout the connector, as well placing bypass caps as close as possible to every Vcc pin. The connector is also only intended for direct board-to-board connections when running at higher speeds.

Other than that I think the design is pretty self-explanatory, and I will attach schematics below. I'd appreciate feedback and any corrections to errors that anyone may have.
I do have 2 questions pertaining to possible issues I've identified.
1. I'm concerned about the clock stretching select lines, as I don't see a way to select them early enough to comply with the set-up time on the '163s inputs before the load pin is pulled low. Maybe this is a non issue?
2: The VIA timing diagram seems to suggest that the chip select must be low prior to the clock signal going high, and other reading I've done seems to confirm this. Will my address decoding circuitry be reliable enough to select the VIA's? This is important since the banking signals come from those chips. I have added pullup resistors on all of the bank select lines, so if the VIA is not working/in a reset state, the highest bank will be selected. I'm also thinking about alternative banking methods if needed.

I don't have a PCB layout done yet, but I will update when I do.

Thanks in advance for any help, advice, or suggestions!

Interesting! I look forward to seeing the build!

(And welcome, although it's a rather delayed welcome, as you note that you've been lurking for a while. Not as long as some though...)

Thanks! De-lurking is somewhat intimidating, but I decided that for this second project it was time to share with the community. (And get help from those much more experienced and knowledgeable than I am!)
I also would like to thank the community here for the wealth of knowledge available on this forum and the various websites hosted by members here. It's been great to have these materials to learn from!

I've spun up the first attempt at a PCB layout in my spare time this past week. It's very preliminary, I basically routed the bypass caps and let the autorouter give it a shot, but this mostly shows that I can fit it all into 100x100mm. I think I can go even smaller by placing some components on the back side of the board and moving all IC's to SMD packages (save for the ROM).


I've been thinking about my bank switching scheme. I'm sure this has been done before but the concept is to steal unused opcodes and use it as a load into a new "register." This would involve essentially 2 latches and a few comparators, along with some extra glue logic. Not sure if this would be able to work fast enough for my target speed though.

Other minor revision ideas:
Eliminate the header for UART channel B, I don't ever see myself using both channels.
Eliminate 4 of the IO select pins on the expansion header. My thought process is that if I need more I/O decoding in the future the device can do it itself given that the entire address bus is available.
Possibly eliminate one of the VIA's if my new bank switching idea is viable.
Eliminate ROM bank switching. If I did this I would continue to use the 39sf- flash chips for cost and speed reasons but only utilize 16k.

I've also thought about moving the I/O into into the top 16k of memory so the wait-state enable lines can be combined with the ROM (and propagation delay lowered.)

This is very much a "subtractive" phase of the design, where I am contemplating scaling back the design in certain areas to improve it in others.
Everyone, please feel free to share your thoughts. I'm always open to suggestions and constructive criticism. After all, it is the best way to learn!

-Z3d

Congrats on finding your voice, Z3d! It's clearly time your lurking days were over. Lots of great work here, and lots to talk about... more, in fact, than I can cover in one post. But here are some odds and ends, in no particular order.

(And nice work on the schematic, BTW. You've obviously put some effort into making it easy to read... effort which is a boon to yourself as well as others, because a well drawn schematic makes the design easier to think about! )

Your concern is well founded. Since you intend to push clock speeds to the max, it'll be best to reduce the number of gate delays involved in pulling the '163 inputs low. And one way to reduce the number of gate delays is to opt for a coarser signal sent to the '163. That is, apply wait states to a larger address range than that which the UART occupies. And BTW, is there any reason you've chosen not to drive the VIA Phi2 inputs from QA of the '163? Doing so will allow the VIA timers to keep proper time, overlooking the clock stretches.

This too is a valid concern. You'd be able to reduce the number of gate delays if you used both of the VIA's chip-select inputs. Right now you have logic that evaluates A15,14,13,12,11 and then conditionally enables the '138. IOW, two separate delays that happen one after the other. But instead the '138 could enabled at all times, and the A15,14,13,12,11 result could be sent to the other CS input of the VIA. This way, the two delays happen concurrently. I know this is a non-trivial rework. Maybe you'll need a second '138, or something other than 138's. But when excess delay is a problem it's good if you can break the total delay into two concurrent components.

R2 (in series with the line that drives the CPU's RDY pin) can afford to be much lower than 470 ohms. I'd go with 100 or even 50 ohms.

On the expansion connector, do you really need to include the high address lines? I'm guessing the external boards would be IO, not memory, but maybe I'm mistaken.


It's easy (and fast) to create a register that gets written by unused opcodes. And that's just the tip of the iceberg. The C02's unused opcodes have some truly remarkable properties, and there's a wealth of opportunity for the creative individuals among us! See Section 9 of this recently updated article, 65C02 Opcodes by Bruce Clark, augmented by Jeff Laughton.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I had meant to do this, so thanks for pointing out that oversight on my part. Although, now that I think about it, wouldn't this have the possibility of creating a bigger issue with the setup of the select lines before Phi2 high? That being said I don't want to wait-state the VIA's if I don't need to. How do they perform at higher frequencies, assuming the select lines are fast enough?


Good point, I hadn't really thought about this since the UART needs a single active-low chip-select so I built a circuit to cater to that. Perhaps running 2 different decoding circuits in parallel would work. So, keep the current setup with the '138 but also use a 74lvc1g139 to decode just 4 of the pages, very quickly (4.2ns), then evaluate A15-A10 to derive the active-high select. That keeps the complexity low enough while speeding it up significantly.


One of the future projects I have in mind is a hardware block data transfer engine using cycle-steal DMA. This could be used primarily for interface to video, but I also have a few ideas for graphics and math accelerators, and a storage controller. This is also the reason why I want quite a bit of RAM available for dealing with all of this data. This will have to wait for now though, but I'm sure I will post about it once the project gets going...

As for the clock stretching inputs, the coarser signal that you mentioned is definitely the way to go, but as said above I don't want to wait-state all of the I/O if I don't have to.
This got me thinking about the memory map again. The I/O can basically go 3 places: Top of Low RAM ($7800-7FFF), bottom of ROM ($C000-C7FF) or top of ROM minus the very top page for obvious reasons ($F800-FEFF). All have some tradeoffs. My original thought process was to put the longest decoding line on the fastest access time memory, the Low RAM, and since adding in the I/O decode adds a bit of delay I did that. This would also maintain software compatibility with my original SBC since it places I/O there (though there isn't much software anyways, sadly.) Placing the I/O with the ROM would allow for 48k contiguous RAM, if some future application even needs contiguous memory, and would mean that the clock streching inputs for the whole system would be a single NAND gate. But, this would make it hard to not clock stretch all of the I/O and increase the select delay on the slowest device in the whole system.
The UART likely needs 2 extra clock cycles at higher speeds given what I've read, but those more familiar with the 28L92 feel free to correct me if I'm wrong. So the ROM idea also wouldn't work very well there because it only needs 1 extra clock cycle, and I don't want to slow the system down more than I need to. So, maybe splitting the I/O down the middle and having half of it be wait-stated and half of it not is the way to go. That way A10 can be used to distinguish from what needs the wait-states and what doesn't.
Sorry if that made very little sense, at this point I'm very much thinking out loud. Any thoughts on how to tackle this one?

Last night I also worked on a design for the illegal opcode hijack mechanism, where opcodes $24 and $44 would be used to read into the banking register. So, you could either load a value immediately or from a zero page location. The design I came up with had to abandon comparitors though because they were far too slow, and it used 11(!) chips. There must be an easier and better way that I'm missing here.

Thanks for the help and suggestions so far!

-Z3d

It doesn't seem like a problem to me. During a stretched clock the select lines won't be changing because the address won't be changing (because the CPU is on stretch time).

I haven't tried pushing WDC VIAs to 14MHz and beyond, but I expect they'd readily tolerate overclocking just as the WDC CPUs do.


On the subject of decoding, here's a diagram with some ideas to consider. We were talking about having two signal paths operating simultaneously, each managing certain address bits, and originally we assumed the chip for which we were decoding had multiple CS inputs. For example, the VIA (like most 65xx peripherals) has two CS inputs, and some RAMs do, too.

But you don't need two CS inputs if the chip in question has /RD and /WR inputs. In that case one of the decode signal paths can be used to qualify /RD. That's what's going on with the Low RAM chip in the diagram. (And the UART could use this idea, too. But the diagram is just a collection of ideas, and isn't intended as a blueprint you should copy.)

The B inputs of the '521 get hardwired high or low, thus specifying the page in which you want IO to appear. The '521 needs a pullup on its output, unless you can arrange that all the chips it drives are "T" series (such as 74ACT).

Decoding opcodes $24 and $44 is pretty easy (and I'll share some suggested logic some other time). But you lost me when you mentioned comparators. Do they relate to the cycle-steal DMA you mentioned?

It seems there are a lot of ideas in flight... more than I can easily digest and comment on, to be honest. But I guess you plan to have all the fancy stuff on the expansion card, not the main board. And that limits the scope of what's on the main board, which is probably good. I've run out of time, so I'll sign off now.

-- Jeff

Edit: booboo in diagram

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

my 65816 SBC runs at 20MHz and uses clock stretching for ROM and IO Accesses. the onboard VIA uses the unstretched clock so that the timers work consistently.
and i can say that the VIA works perfectly fine in this kind of setup and at these speeds.

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

Looking back on it, this certainly is true! My last post was incredibly scatterbrained, which I apologize for. This often happens to me with my various projects, so I thank you for bringing it up so I can refocus on what I've got going here.
Honestly I should have not mentioned my slightly hair-brained DMA idea, currently it's only a concept and the development of that will have to wait for another time. I certainly need to improve my understanding of both hardware and software before I can work on that.
So, going back to my first post and refocusing on the goals of this project:

The latter 4 items on the list have been implemented, so most of my remaining uncertainty and where design efforts need to be focused is on the speed goal, which we've been discussing here. I did some work last night and it looks like we came up with similar designs conceptually, but I implemented it with discrete logic. The fastest implementation I could come up with requires 8 gates and selects the CS and /Clock-Strech lines in 7ns. I was aware of the 74FCT521, but a bit intimidated by the TTL output levels and the issues that may cause. I don't need to decode all of the top 8 address bits anyways, I'm giving each I/O device an entire page.
I hadn't thought about using the RAM /OE as a pseudo chip select though! I suppose that has the advantage that usually the IO and device is selected before the clock signal goes high so there is only still a single gate delay to the /OE signal.


I am quite curious, but I'm pretty sure at this point that I'll just use the VIA to bank the RAM.


My reference to comparators (Oops, I spelled it wrong the first time) was about using them to detect the desired opcodes by hard-wiring one input to either $24 or $44. Sorry, that was worded poorly the first time.

The 65C22 datasheet is very confusing, which I understand is typical for WDC. If you take the timing diagrams at face value, the VIA wants /CS and CS set up 10ns before Phi2 high, but the 65C02 at 14mhz only guarantees the address will be valid on the bus 5ns before Phi2 high! I figured something must be wrong there, so good to hear that they should work without a wait-state at 14mhz.

Attached are the updated schematics as of last night. Notable changes include the implementation of the "Fast I/O" select lines, a slight optimization of the normal I/O select, and removal of 1 of the ROM bank select lines. I also rearranged some things to clean them up and present the information better. Note that I have not annotated it yet, I ran out of time when working on it last.
Updated propagation delay times:
7ns for IO Clock Stretch Select
7ns for Fast IO select (both High and Low select lines)
11.3ns for 'normal' IO select
Pretty good, but perhaps there are still nanoseconds (or fractions of) to be squeezed out somewhere...

Thanks everyone!

-Z3d

I've been working on a new preliminary PCB layout over the past few days, but (almost predictably) it is proving to be a massive pain to route.
Perhaps a transition to some programmable logic would be in order? I have zero experience with any of it, but I think even a 16V8 would be sufficient, for just the I/O and clock-streching selection.
Still curious about unused opcode stealing to bank-switch the RAM but haven't put much thought into it since my last post.

So I thought I was basically done with the design phase, but maybe it's time to rethink some of this again.
That being said, does anyone see any errors in the current design?

-Z3d

honestly i've rarely routed my PCBs manually, i just use FreeRouting to do it for me and after it's done i go over everything again to clean up a few corners and such.
even my 20 MHz capable 65c816 SBC was done using FreeRouting (except for the USB +/- Data lines), so i'd say the program is pretty competent.

the 22v10, 16v8, and such are pretty decent PLDs with the neat benefit that they can be programmed using the TL866ii plus (an amazing ROM/FLASH/MCU/PLD Programmer that can also test Logic and RAM ICs and i hope you already have one). so you don't need an extra programmer for the PLDs like with the ATF150x CPLDs.

I also use freerouting - but even it is struggling with this layout for some reason! It often gets stuck in a loop which it can't seem to break out of. Even when it does produce an output, it's not very good, with tons of errors around through-holes and whatnot. I think I can improve this by arranging the components 'logically', such that the connections each chip needs to make are relatively close to each other.

I do have a tl866ii plus, and I agree it's such an amazing little programmer!
Funny story about that, I actually programmed my first 6502 breadboard project/prototype with a homemade DIP switch programmer (I was trying to save a few bucks) and I finally gave up when I attempted to debug my first 'real' program which was almost 350 bytes, all done by hand! After that experience, I bought the programmer.

Hi all!

Last week I decided to make the switch to programmable logic for the IO address decoding. I settled on the ATF16V8-5JX, the 5ns part. Parts arrived from digikey on Friday and I quickly worked up the CUPL code. It's dead simple.

I built a test setup which revealed the longest delay to be 4.3ns, so even better than spec. And, keep in mind, that was on a breadboard and included my kludged together PLCC to DIP adapter.

The memory map now is as follows:
Low RAM: $0000-7BFF (31k)
Fast I/O: $7C00-7FFF (4 devices)
High RAM: $8000-BFFF (16k)
Slow I/O: $C000-C1FF (2 devices)
ROM: $C200 (15.5k)

Of course, the PLD means that the I/O can be reconfigured anywhere within the bottom 32k or top 16k.
The top 16k of memory can have a clock stretch selected with a jumper on the board.

I used the memory /RD signals as a pseudo chip-select as suggested by Dr Jefyll. This helped remove a bunch of complexity from the board.
Propagation delay is as follows:
0ns for Low RAM (A15 is wired directly to the /CS)
4.2ns for High RAM
3.5ns for ROM
3.5ns for Clock Stretch Select
5ns for all I/O select lines
/RD and /WD: 3.5ns from PHI2 high

Pretty good if I do say so myself! I drew some timing diagrams to scale on graph paper which validated that it should work at 20mhz or more (except for the ROM), assuming the CPU holds up, which I expect it to based off of what I've read.

Board layout is done too. The 6502 is moved back to a PLCC package for a few reasons. One, it actually allowed for a tighter board layout since everything is available on both sides of the board. Two, this will let me play the silicon lottery a little bit and swap between 6502's to see which one runs fastest. The UART has been moved to a QFP package so the TI part can be used.

Here's a 3d render:

I think it looks amazing in black, but that will cost extra so not sure if I'll go with that.

Attached are updated schematics.
Anyone see a reason this thing won't fly? I can send gerbers too if anyone is willing to look them over.

I don't know if this is something people do around here, but I'd also be willing to sell a few boards to help defray the costs since I have to order at least 5 anyways. (Assuming the thing works)

Thanks everyone for all the help and suggestions so far!

-Z3d

what PCB manufacturer are you using? with JLCPCB for example, a 2/4 layer board in black or white doesn't cost more, it only takes more time to make than default green.

on a different note, why the 2 VIAs are so far apart from eachother? the empty space between them looks a bit weird IMO... you could move them together a bit more, and center them with their respective connectors. (just for aesthetic reasons)
and something else, if you have USB on your board and want an easy serial connection to a PC, i highly recommend the FT240X. it's pretty much just a UART and Serial to USB adpater in a single chip. you don't even need an external oscillator. it's very tiny and easy to hook up, good if you only want to connect to a host device like a PC, but if you want to use Serial for other things you would need a seperate UART

other than that, the only 2 things i would note are:
1. PB5 on U15 (VIA) being left unconnected seems a bit like a waste of a pin. why not hook it up to an onboard LED or button so you can use it for testing and such?
2. i would personally reassign the power pins on the VIA Connectors to be closer together, similar to how i have it on my SBC:

though i do like how you have the power pins flipped so if you have a card and insert it the wrong way it won't instantly kill all chips or polarized caps on it. (then again you can also just make the connector keyed)

anyways, i wish you luck with ordering and assembling!

First. nice looking board... congrats on getting it done. Also, I like the SMT usage and the PLD for decoding as well... I switched to a PLD for glue logic 5 years ago, never looked back.

Some thoughts on your design:

1- Memory Map: You have a pretty large I/O block and it limits contiguous memory to 30KB from $0000. Any particular reason?
2- Perhaps look at stepping up to an ATF22V10 for decode. You could generate the Ph2 qualified memory write/read signals and save a couple chips, or include the low RAM select with the PLD. giving you more flexibility for I/O locations.
3- You have a couple unused inputs on the 16V8... oversight or on purpose?

Noting the memory map, do you have some specific ideas on what you're going to do from a software view? Any thoughts on perhaps getting Fuzix to run (which requires banked memory). Back in the 80's I configured my 65C02 system for using $FE00 as an I/O page (256 bytes) and then divided that into either 16- 16-byte wide I/O selects or 8- 32-byte wide I/O selects. This does allow a pretty large contiguous memory range which could be useful for certain type of software, like an OS (Fuzix, DOS/65 or write your own). The same for running a larger BASIC program or perhaps compiled C code.

Any specific plans for additional I/O adapters? Having some ideas tends to influence your decisions on the number of I/O selects and the address width of them.

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