All the more reason to properly Phi2-qualify the /OE and /WE signals. The address is guaranteed by the CPU to be stable while Phi2 is high, but should be assumed to be unstable as soon as Phi2 goes low (plus the hold time, which is 10ns for the WDC part at 5V; that hold time gives you enough leeway to insert a gate between the CPU and the device).

With that setup, you only need to worry about false reads generated by the CPU through the extra cycle needed to carry an index over a page boundary. The address falsely accessed is predictable, however, so you should just avoid using indexed addressing modes in your I/O address space, at least with large enough index values to cross a page boundary.

(Incidentally, the VIA is one of those devices which needs different bus signals than the above. But since it's specifically designed for the 65xx bus, it's easy to adapt to.)

I'm thinking a false read could happen at the beginning of a read cycle, as the address lines settle. Not just in a dummy cycle (that's a different consideration.)

With the decoding circuit linked earlier in the thread, yes - but not with the VIA, because that has its own Phi2 input. Only with some other device, like a 28L92.

With /OE and /WE properly Phi2-qualified, you might get a glitch on /CE, but that's harmless while Phi2 is low. If you're running the CPU below specified speed for the voltage, address lines will stabilise well before the rise of Phi2, and most slow EEPROMs can use that time as part of satisfying their address-to-output latency, even while /OE is inactive. That's why you can safely use a 150ns part at 4MHz.

@Chromatix: Yes, page fault accesses should be read only and should not cause wrong characters on screen. They only may affect I/O if that is addressed nearby.

I would suggest to check the access by using "clean" instructions. You may simply set up a sequence of absolute STAs to fill the screen or every third character position with a known character and then check for errors. If garbage still appears you need to work on your /WE.

My schematic was rife with errors and omissions. Just to aid the conversation, here is a corrected one.

Dammit, its still wrong. Standby...

I think I got it right this time...

Yeah, that's still a disaster area, but now I think I can discern what address layout you're aiming for. It looks like you want a 32KB ROM in the top half of the address space, 16KB SRAM in the bottom quarter, 8KB VRAM at $6000-$7FFF, and I/O devices in the remaining space from $4000-$5FFF.

Problems include that your SRAM is selected by just A15 low, but output-enabled by just A14 low. If you have R/W wired directly to /WE (or even qualified by Phi2), that means your SRAM will respond to writes in $4000-$7FFF which are not mapped such that you can read them. The only reason you aren't noticing corruption is because it's physically a 32KB part and you've got A14 wired up, directing the writes to the unused part of the memory array.

Similarly, your I/O space is selected by A14 high and A15 low, which actually selects all of $4000-$7FFF, overlapping your VRAM. The UART is further qualified only by A12, which means it will respond to two 4KB regions in that range (which ones depends on the sense of the second select, which I haven't looked up). That means some of your VRAM accesses will conflict with UART accesses on the bus.

Simply put, this doesn't seem to correspond with any advice @GARTHWILSON is likely to have given. You need to rework it along the lines I suggested above - I'll modify them below to account for your actual address layout:

ROM /CS = ~A15 ; $8000-$FFFF, 32KB
VRAM /CE = ~(A13 & A14 & ~A15) ; $6000-$7FFF, 8KB
I/O /Select = ~(A8..15 == $5F) ; $5F00-$5FFF, 256B - use your '688.
I/O Device = 3-to-8 decode of A5..7 (32B each) or 4-to-16 decode of A4..7 (16B each).
SRAM /CE = ~(~A15 & (VRAM /CE) & (I/O /Select)) ; $0000-$5EFF, 23.75KB
All /OE = ~(Phi2 & R/W)
All /WE = ~(Phi2 & ~R/W)

Note that in the above, I've given you access to more of your SRAM array than you had before. You still have plenty of space for I/O devices.

All that makes sense, and actually is kinda obvious to me now

Sans my VRAM and the associated 688, this circuit is taken directly from the Primer. I think where I went wrong is that Garth never intended a 4k RAM chip to be used with this scheme. When all you need access to are the various registers in a VIA or UART, you most address lines aren't even hooked up to I/O, so nothing bad happens. I foolishly didn't bother to consider how my VRAM actually intrudes on this space.

Tomorrow I'll look closer, but I bet anything it's the UART addressing causing the trouble. There is a lot of serial communication going on during screen writes, because I still send everything to both the screen and the serial port so that I have a working screen (the laptop) and a keyboard (also the laptop).

Two questions though: Doesn't this all mean that I can make accidental writes to the UART when writing VRAM, but not the other way around? No UART access can select VRAM, but I can see how the opposite can happen. In other words, I can't see how the bad data gets into VRAM, even with my messy decoding.

Also, I'm. Not clear what the advantage is to tying RW to PH2. As I have it now, RW is asserted for both halves of PH2, but CE is only asserted when it's HIGH. Aren't the data lines still tri-stated (or however it happens) when CE it's not asserted, regardless of RW?

Thanks for the time spent helping me. I'll try your suggestions in the morning.

You need to zoom in on the handful of nanoseconds around the falling edge of Phi2 to understand this part; the precise order in which things occur really does matter here. I tried to explain this earlier, but let's try again.

Looking at your oscilloscope trace, it's clear that Phi2 falls, *then* R/W goes high, *then* /CE goes high. According to WDC's datasheet, R/W is guaranteed to remain stable after Phi2 for the same amount of time as the address lines are guaranteed to remain stable - which is *not* to say that both are guaranteed to change simultaneously. But we *can* infer that /CE is not going high (and deselecting the device) until a time at which the address lines are no longer stable, and may in fact have been detected to change by the device. Furthermore, your device might be expecting a "data hold time" in which the data bus remains stable *after* its control signals are driven inactive.

Much of this is because you're implementing your Phi2 qualification of /CE through a rather complex and relatively slow logic device, the '688. You should assume that most such devices, especially in 74HC series, are several times slower than a simple gate. Refer to the datasheets for details.

In many RAM and especially ROM devices, the response to /CE and address lines is also somewhat slower than to /OE and /WE. This does not mean that the device is *guaranteed* to respond slowly to address line changes; it *does* mean that you must satisfy a longer setup time in order to guarantee *correct* operation. This will exacerbate the effects of the relatively slow logic in the address-decoding chain. The end result is a potential write to a different address than intended, as well as to the intended address. This is sufficient to explain your corruption problems.

By explicitly qualifying /WE and /OE with Phi2 with just a single gate delay, we can make all memory devices insensitive to changes in the address lines and R/W from the CPU, before the CPU actually changes them. That's how the 65xx bus was designed to work, and essentially all devices are designed to work with that sequence.

Now consider the following hypothetical: your UART responds to /WE going high more quickly than your VRAM does, and starts driving the data bus with the contents of some internal register while the VRAM is still sensitive to data. That would allow the UART to corrupt the VRAM when the latter is written.

Meanwhile, reading back from VRAM will sometimes cause both the VRAM and the UART to drive the data bus simultaneously, resulting in temporary short-circuits. That is *not* specific to your timing problems, only the faulty address decode.

Just got back from work. Gonna implement your scheme. Even if it doesn't fix the problem, you've sold me on the merits. I do like that I get more RAM, for really no cost. It's always bugged me that I'd carved out 16k for I/O, knowing I'd need a fraction of that.

Well, if it nags you having only 16K RAM, why not change your map a little
I would suggest to think first about where to place your VRAM. It may follow normal RAM above $7FFF, e.g. $8xxx. But perhaps you wish to use M$Basic that starts @ $8000. Then you had to move the VRAM to higher locations, perhaps $E000..$EFFF.

In any case (or to be flexible) you can use a 74HC85 (4 bit comparator) do select any page. Allthough the HC85 is similar slow than the 688, using the qualified /WR for all RAMs as Chromatix precisely elaborated everything should be fine. You have to use the P=Q output and invert it for /CSVRAM and (!!) to disable either /CSROM or /CSRAM (or both) depending where you finally drop you VRAM.

Similar you can use your 688 to carve out a single page of your map for I/O. Again you need to deselect whatever is placed usually there. I tend to use $FExx or (using the /E input of the 688) $FF00..$FF7F. (That page is only partial free due to the interrupt vectors placed there).

my 2 cents

Chromatix:

Finally scetching out your scheme on paper. Couple questions.

On my initial attemp to do it with all NANDs, I find myself having quite a few gates in series to get what I want. For instance, for the SRAM /CE, I need:

~(~A15 & (VRAM /CE) & (I/O /CS)

to get VRAM /CE, I need to AND A14 and A13. This means I NAND them, and then use another NAND to invert for the desired AND

that gets NANDed again to combine with ~A15. Thats three NAND's deep, and for SRAM, I need to feed that to more logic.

First, do I suck at combinational logic, and am missing some more efficient moves? And next, at some point I feel I'm not faster than the 688 was.

I could also use real ANDs, but I an't help the nagging feeling I'm missing a clever move or 2

My intention is that you use two 3-input NANDs in sequence to generate first VRAM /CE and then SRAM /CE. That's exactly the way it's written, so you don't need to think too hard about it. You can invert A15 any way you want (maybe using the third 3-input NAND gate you get on the same 74HC10 chip, or a spare 2-input NAND from the 74HC00 you'll also need), and of course you can use the same ~A15 result wherever it appears in my equations.

The '688's output is one of the inputs to the SRAM NAND gate, but this is fine because the CPU's address lines become valid sooner than the leading clock edge, and you no longer have a critical timing relationship between the *trailing* clock edge and the address decoder. It's the latter that was causing you problems before.

Then you only need to use three gates of a quad 2-input NAND to generate the /OE and /WE signals.

Thanks for the quick reply, and your patience. As luck would happen, I have everything I need to do this in my logic stash.