Fast memory needs fast, strong buffer to drive large data bus loads. 10nS RAM can’t afford to have slow 5nS-class bidirectional buffers. So it has ACT-class drivers and associated signal integrity issues. Ultimately it is signal integrity issue of driving 8-bit data from RAM array that is at same time writable and respond to fast write glitches. Retro hobbyist community really don’t pay much attention to signal integrity nor have the expensive analytical tools nor willingness to pay for control impedance pc boards. That’s fine dealing with slow memories and processors; we can get away with sloppy prototyping and just having fun. 10nS RAM require significantly greater discipline and understanding of signal integrity issues and more importantly the analytical tools and advanced pc board layout tools that I no longer have access in my retirement. Fortunately pc board is quick and inexpensive so at least it is easy to iterate the design. As long as I keep the board small and design simple, I probably will be OK.
Bill

Edit, sorry about the off topic discussion. I’ll revisit my thread about overclocking 6502 since I have a couple related PC boards coming from JLCPCB this week.

Hoorary! I think this demonstrates how close you are to a fully working system, if it's working well with that part disabled.


Are you stretching the clock for ROM accesses? Typical EEPROMs have rather slow timings, e.g. 150ns seems common - by the book this is only fast enough for 3-6 MHz depending whether its a full cycle time or read access time. 25MHz with a 50% duty cycle is 40ns total cycle time - 20ns per clock phase - and that's very short for EEPROMs. Other technologies like Flash may be faster though, in case you're using that.

You may be able to measure on your oscilloscope how soon your EEPROM tends to assert the data bus after being selected, this will be easiest outside of your main circuit though as if you don't have a storage oscilloscope you'll need to create a repetitive test scenario.


Is this using the most recent glue-v2 that you posted? Maybe there is a timing race of some kind, or just too much propagation delay between the stages of the decoding.

One thing that strikes me, reviewing glue-v2 again, is that your bank register (flipflop) changes state based only on the state of the address bus - it is not qualified by the CPU clock. So when the address bits are changing during phase 1, it could accidentally change the flipflop's state. To verify this you could try hard-wiring it to always be set or always be reset, or disconnect its output and fix that either high or low.

You can't fix this by just feeding phi2 into U2 because that's also used to select VIAs, which need their selection signals to be set up during phase 1. Perhaps you need an extra '139 after U2 to decode /RAM and /ROM but only when phi2 is high - a bit like U4A - and as a bonus you'd be able to put /RAM and /ROM into the same I/O block, and use a lower address line to select between them.

Or turn things around a bit - generate a single active-low signal into the flipflop's clock input, active only during phase 2, with D0 going into its D input - then you can use a single address to control the flipflop and write 1 or 0 to it to choose between RAM and ROM, rather than having a different address for each. RESET can feed into either the asynchronous set or asynchronous reset inputs of the flipflop instead of into its clock input. This setup is much closer to what you might want to do if you had more than one bank selection bit (you can easily drive an 8-bit register this way instead of just a single flipflop).

Another observation - the path from A15 to /CLKSTRETCH involves a lot of components - U5A, U3, U4B, and U6A. So when your oscillator rises, the counter U1's outputs fall and phase 1 starts. After a delay the CPU finishes putting an address on the bus. Then we need to wait potentially for U5A, U3, U4B, and U6A, before U1's inputs are ready for the next tick - then U1 itself has a setup time for parallel loading. All that has to fit within one oscillator period, it feels like quite a lot to me for a 25MHz oscillator (40ns). I'm just guessing based on AHC parts often having propagation delays in single digits, HC parts sometimes do but often specify double digits, but it might be worth checking and measuring what you're seeing in practice.

Hi Bill, I don't think this is off topic at all! What you're saying matches my experience with this board pretty well. This W24512 doesn't seem to pull rail-to-rail, and my data bus is all kinds of noisy compared to previous builds, even though there's nothing on right now it except the CPU, RAM, ROM, and (sometimes) a logic analyzer. Although, it seems like some parts from some manufacturers are more forgiving than others; the last time I used high speed SRAM (12ns) it was a 32k Renesas 71256SA12TPG, and it seemed to be able to handle whatever hobbyist sloppiness I threw at it. Now I kind of wish I'd bought more of it!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

I meant to ask about that - according to its datasheet it only outputs at least 2.4V, which is too low for non-T series CMOS parts, potentially including the CPU. There's another thread here about CMOS-compatible RAM that's been active recently, discussing reasons for this and how much it matters in practice. One point was that some of these SRAMs are actuality 3V parts with an internal voltage regulator to step down from 5V, which is why they require 5V power yet can't output a 5V signal.

But another possible reason is simply weak drivers, in which case on a lightly loaded bus (all CMOS parts) you might still get a good voltage out, even though it's not guaranteed, as not much current is drawn.


Yes I use those all the time with great results, though I haven't specifically checked the output voltage range either in the datasheet or in my circuit's. I was just looking on Mouser to buy some more while ordering other parts and they're not in stock at this speed any more.

I am! Although, I am also using a pretty fast (70ns) FLASH ROM. The only part of the system that runs at the oscillator frequency is the prescaler / stretcher. Everything else runs at 1/2 or 1/8 the oscillator speed, depending. So with a 20MHz oscillator, the RAM is running at 10MHz, and the ROM is running at 2.5MHz. I was secretly hoping I might be able to get 16MHz / 4MHz, since the Rockwell ACIA I plan to use is a 4MHz part. On paper my glue is too slow for 16MHz, but sometimes parts are over-specced...

Yes, with the HC11. The previous version with the HC32 worked OK. The reason I changed it was because I would like the option to attach another slow device to the clock stretcher at some point in the future, and also to get rid of some inverters. I will sit down with some paper and a pen and draw out the truth tables today, in case my brain did something silly.

A little more on that topic:

This is one of my favorite retro 6502 books: https://archive.org/details/programming ... xperiments

On page 275 there's a schematic of a 1-bit output port that only uses control signals. I thought that was a cool idea - at the cost of one extra select line I could simplify the wiring and reduce the load on the data bus. Could be something there I missed too.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Of course! I sometimes forget that the `688 and `138 are basically just big combinatorial logic and that their outputs follow their inputs all the time, not just when I want them to. Thanks George!

That's how I did it in the previous version... a one-bit write-only register that latched D0.

I had planned to use all AHC for this board, but a few things are HC... the `688 is the slowest part, I think, and is involved in every transaction. I know I could go faster if I gave it up, but I really like the flexibility of having a small (128 byte) movable I/O window.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

It would be a huge change so take what I'm about to say with a grain of salt but...

I think you should be able to get to 25.175MHz, even on a breadboard. As mentioned above; don't fear fast SRAMs! With the exception they could need pretty fast rise or fall signal times < ~3ns. And that makes me think if you start using 10ns memory you're probably heading towards 3.3V land.

And if you're using 3.3V ICs that opens up a whole world of *very* fast components. Specifically the LVC family. Which you absolutrely can use in breadboards or with wire wrap if you want. I haven't seen an LVC DIP but they're fairly easy to solder onto breakout boards.

I've found they ring a lot, like a lot! in a breadboard but I've not found the ringing to go outside of valid VIH or VIL. However just to be sure I tend to put 100Ω or 220Ω resistors in series as close as possible to signal pins.

And that leaves interfacing with a 5V W65C02. I'm making an assumption that you have a '245 between your data pins and whatever else you're talking to so it should be possible just use a 74LVC4245 translator instead.

And getting up to 25.175MHz can be really useful because that makes it possible to run video memory access in sync with the '02 but whilst Φ2 is low.

(and I see a couple of posts whilst I was posting so this might not make sense anymore and I haven't considered the movable IO window)

You can get 280 of them from Digikey if you want to spend $940.

Mouser USA seems to have them, though: https://www.mouser.com/ProductDetail/Re ... fqkw%3D%3D, but they say they're obsolete and will be discontinued. Maybe I should grab some more before they dry up.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

I'm not using one on this board, but I do have some `245s. I was hoping to get by with just lots of ground return wires (one per signal), but I might could add one later if I have to. Space on the board is getting a little tight though!

That's OK! These are still interesting ideas. Even if I don't use 3v parts in this build, I might in the future. Food for thought!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

One other thing I was going to mention. For my very first build (an RC6502 Apple 1 replica SBC) I bought an oscillator socket. It appeared to be a plain old machine pin DIP-14 socket, except with only the 4 corner pins installed. So ever since then I never bought any more oscillator sockets, and just used regular DIP-14 machine pin sockets. This week (and earlier, with the previous prototype build that failed) I've been having some trouble getting good contact between the oscillator and the socket. The little socket fingers don't seem to grip the skinny oscillator leads they way they do the flat IC leads. I was wondering, for projects where you don't want to just solder the oscillator onto the board, what do you use? Will it go into a dual-wipe socket?

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

For my current build, I am using dual-wipe sockets - not machine pin ones - and they seem OK. It's a bit wonky though - the oscillator pins are way too long for the socket, and some have gone in further than others for some reason. It's working fine though, so I'd half-recommend it.

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

I've been using full round-hole DIP-14 sockets for a LONG time, and they work fine. On my most recent board I got a special "oscillator" DIP-8 socket, and it works fine too, basically identical. When I buy the socket for the oscillator, it is the highest quality socket I can get really. And it does still come in and out fairly easily, much easier than a chip. But again, never had issues. I never want to solder it directly to the board simply because it costs so much and I reuse them with every build anyways.

EDIT: Removed a mini-rant about sockets.

As far as the fast SRAM, I suppose I'll try it out sometime, seeing the overwhelming consensuses that they are still easy to work with.

Chad

I'm going to tentatively say that I have a working board! There are still some things I'd like to improve, though.

I reverted to the rev-3 glue logic, which uses an HC32 for both the RAM/ROM banking and the clock stretching. Unfortunately, in order to use the HC32 for the clock stretcher, I have to invert both inputs and the output, which means the clock stretch logic is slower than before. As I was afraid of, that made it too slow for 10MHz: You can see here the ROM select goes low, but the stretcher logic doesn't get finished in time, so there's an extra clock tick before the `163 hits the brakes. A lot of the time, this doesn't seem to matter (!) but every so often there are some memory glitches. Here's with a much slower (1MHz) oscillator, showing the clock stretcher behaving properly: I'm not sure what I want to do about this yet. I could just run it at 8MHz/4MHz, but that is a lot slower than I'd hoped. Either way, one of the nice things about wire-wrapping like this is that it's pretty easy to change things if I feel like it. As long as I don't need more ICs than I have sockets for, making changes just means undoing some wraps.

Meanwhile, to test the bank register I wrote a little "run from RAM" program: And here's a capture of it running: I actually find it's helpful to have the capture and the assembler listing side by side, so here is the listing, in case anyone is interested in actually looking closely: The reset line is *still* not as smooth as I would like. Here it is thumping along with the clock (this is the fast 20MHz oscillator): This offends my sense of aesthetics, and bothers me because I don't know why it's happening (Peanutbutter-1's reset line does not look like this), but the fluctuations never drop low enough to cause spurious resets. I guess I will be like Drogon - it works, but it looks scary, so that's why I don't probe my board.

The other thing is that the data bus still looks really bad. With the slow oscillator, you can *really* see clearly how the high levels are fluctuating. Again, they don't ever seem to drop low enough to cause logic errors, but it bothers me. It's ugly, and I don't understand why it's there.

That is to say, I think it's there because the oscillator / prescaler switch hard and put a lot of noise on VCC. But I've got bypass caps out the wazoo and a couple of big bulk decoupling capacitors (10uf and 100uf) right by where the power comes on board, which is what I normally do. Maybe these capacitors just aren't very good?

Anyway, overall, positive developments, and some more stuff to ponder.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad