6502.org

Could a ROM be used as an address decoder and a TX output latch? Each 1K RAM block is a pair of 2114's. Could something like this work? If the 'latch' method fails then perhaps the ROM Q6 and Q7 outputs could be used to drive SET and CLR inputs of a flip-flop made from the two unused 74LS00 gates?

Cheerful regards...

Interesting! I'm guessing the ROM contents are such that Bit7 is high for all bytes at locations whose address contains a high in the A9 position, and Bit7 is low for all bytes at locations whose address contains a low in the A9 position. Thus, when A9 and Bit7 are high they act to keep each other high, and likewise when low they act to keep each other low.

But isn't there something missing? Seems to me the high or low state on Bit7 will persist forever! There's nothing shown that would prompt it to produce a serial bitstream. Edit: hmmm, does the ROM contain a pair of locations whose Bit7 content deviates from the rule I described above?
In theory that's a bit dodgy, because the EPROM output isn't guaranteed to be glitch-free in the instant following an address transition, and (unlike a clocked D-type) the flipflop you describe would react to a glitch.

That's the theory! In practice you might find that some EPROMs do work reliably, even with a flip-flop made from the two NAND gates.

-- Jeff

Yes... Here's how I imagined the ROM tables could be set up (see below). Use something like sta $0FE0 to set TX = 0 and sta $0FF0 to set TX = 1.

My question is whether this B7 -> A9 connection can create a viable 'latch' that can survive address/data transitions? Do you get nice smooth data output transitions if you're not toggling the ROM chip select and output enable inputs each clock cycle?

I think you can get nice smooth data output transitions if /CS and /OE are held low and only one address input changes state. Indeed, I remember a homebrew CPU whose main board featured about a dozen very large EPROMs... and, astonishingly, no 574s or similar registers! If I can find the link again I'll post it. Anyway, IIRC the EPROMs had /CS and /OE held low, and they were being "clocked" (!!!) by having only one address input change state.

Your proposed scheme fails to meet the stipulation of only one address input changing state, so I think you have to assume there will glitches on the outputs. But perhaps the glitches could be absorbed by a simple low pass RC filter between D7 and A9. The time constant would have to be slow enough to eat a glitch but fast enough to respond when there's a memory access that's intended to change the Bit7/A9 state. And arranging that doesn't sound too hard, assuming that a glitch will be much shorter than a memory access...

-- Jeff

ps- in case anyone's drawing a blank on the chart (as I initially did), perhaps this version will be helpful.

OT: Here's a PDF regarding that astonishingly unconventional homebrew CPU I mentioned.

Is there any guarantee about what appears on the address bus when PHI2 is low? The suggested circuit doesn't qualify anything with PHI2, so random rubbish appearing when PHI2=0 could interfere with the operation of the "latch". There's also the problem of "dead" bus cycles when the processor outputs an address which isn't really valid.

Assuming the w65c02 address bus is similar to the w65c816 (and assuming you're using the WDC chip - which i should probably have gone back and checked) then within a few 10s of nanoseconds after PHI2 goes low a valid address will appear on the address bus. I don't think there's a point where there's garbage on the address bus - just one valid address after another.

[Edit - of course you're using the 6504. That was the whole point of this thread I absolutely couldn't say if it just steps from one valid address to another, how long that valid address would take to appear, or even if the whole address appears at the same time.]

Great work from Michael thinking outside the box. I like how you even mapped the trigger into top of Zero page for faster access.

Just need to figure out a) whether the address bus is stable and/or the EPROM is glitchy so we don't need a d-type latch, and b) whether it can be simplified eg 512byte prom or regular logic and still keep the zero page location. Note we could combine (a) and (b) in a registered PLD eg. PAL 16R4 but it doesn't feel very sportsmanlike.

I would expect the address bus to change from one valid address to the next, at a macro scale, but down at the nanosecond level it's possible that some address lines will change before others, especially as different lines might have different loads - and certainly a high to low transition might have an effect at a different time than a low to high transition on another line. So in that sense, there is a race, and decoding logic could produce a glitch.

When the 6532 first appeared I don’t believe it was very expensive for what you get - I just don’t believe it was available to the public in ‘76.
http://archive.6502.org/datasheets/mos_ ... b_1977.pdf

But of course we don’t really need I/O or a timer for basic.(If a tree falls…)
But maybe the 128 bytes of SRAM was enough?

The 6532 was included in the September 1977 release of the Atari 2600. The Atari was prototyped in 1976 - but I don't know if the prototype used the 6532 or not.

A severe case of magic smoke all because Spock didn't get the 5- or 6lbs of platinum he needed.