65xx continuously variable clock

[Chromatix]

The diagram looks correct for /OE and /WE. Keeping your gate delays minimised for fast devices is also prudent.

I would worry more about VDA/VPA qualifying the EEPROM than your high RAM, since the main objective is to avoid taking unnecessary wait-states during internal-operation CPU cycles. The EEPROM will respond to $00FFFF, won't it? Other addresses commonly generated during internal-operation cycles include those closely related to program code and operands accessed in adjacent cycles, which are also likely to be EEPROM addresses. Qualifying high RAM addresses is harmless, though, and may help to reduce power consumption a little (many RAM devices have significantly lower standby current with /CE high).

Meanwhile, closer examination of EEPROM timing data shows that it can take several tens of nanoseconds to tristate its outputs after /OE goes high. At high clock speeds, that could significantly interfere with the bank address presented by the '816 during that interval - so that explains why the '245 bus transceiver is present in WDC's example circuit. Happily, there is a 74AHC245 which seems to be readily available and fairly inexpensive. The raw R/W signal suffices to select direction, while the enable of the '245 is active-low and can be taken directly from the LE of the bank latch.

[backspace119]

Chromatix wrote:

The diagram looks correct for /OE and /WE. Keeping your gate delays minimised for fast devices is also prudent.

I would worry more about VDA/VPA qualifying the EEPROM than your high RAM, since the main objective is to avoid taking unnecessary wait-states during internal-operation CPU cycles. The EEPROM will respond to $00FFFF, won't it? Other addresses commonly generated during internal-operation cycles include those closely related to program code and operands accessed in adjacent cycles, which are also likely to be EEPROM addresses. Qualifying high RAM addresses is harmless, though, and may help to reduce power consumption a little (many RAM devices have significantly lower standby current with /CE high).

Meanwhile, closer examination of EEPROM timing data shows that it can take several tens of nanoseconds to tristate its outputs after /OE goes high. At high clock speeds, that could significantly interfere with the bank address presented by the '816 during that interval - so that explains why the '245 bus transceiver is present in WDC's example circuit. Happily, there is a 74AHC245 which seems to be readily available and fairly inexpensive. The raw R/W signal suffices to select direction, while the enable of the '245 is active-low and can be taken directly from the LE of the bank latch.

I think I currently had the 245 qualified only with PHI2, I'll use the LE from the other to qualify it.

You're right about the eeprom, so I definitely need to do that, it shouldn't be too hard to add that in to the chip select qualification, which I believe currently is only A14 & A15 & LOW16E (signal generated by 8 bit comparator that enables low 16 addressed devices if all of the top 8 bits are 0)

[backspace119]

Something I forgot to ask earlier, does the 65SPI or the VIA require any kind of wait states ever? I don't think the VIA does, but I'm not sure on the 65SPI

[GARTHWILSON]

backspace119 wrote:

Something I forgot to ask earlier, does the 65SPI or the VIA require any kind of wait states ever? I don't think the VIA does, but I'm not sure on the 65SPI

Both are rated for 14MHz with no wait states.

[backspace119]

GARTHWILSON wrote:

backspace119 wrote:

Something I forgot to ask earlier, does the 65SPI or the VIA require any kind of wait states ever? I don't think the VIA does, but I'm not sure on the 65SPI

Both are rated for 14MHz with no wait states.

Ok, so should be fine unless I get up to doing crazy **** with the clock

[backspace119]

So I've decided I'm going to keep the LTC1799/1699 chip involved, with the SPI controlled rheostat. At bootup, it should be running at 1.8Mhz, it can then be set to change frequency in the bootup process (to a known good frequency). This will save having to buy multiple cans and test them, and also allows flexibility in the system.

For my next build, I'll be investigating that EconOscillator chip.

[Dr Jefyll]

Chromatix wrote:

closer examination of EEPROM timing data shows that it can take several tens of nanoseconds to tristate its outputs after /OE goes high. At high clock speeds, that could significantly interfere with the bank address presented by the '816 during that interval - so that explains why the '245 bus transceiver is present in WDC's example circuit.

Right. To omit the '245 transceiver, you really want every chip on the data bus to respond crisply. Sometimes that's a battle not worth fighting, because including a '245 isn't that big a deal. (And if delay is an issue, there are '245 variants based on FET switches, and these have no propagation delay per se. An active switch does has a small resistance, though, so there *is* a tiny delay based simply on RC.)

Chromatix wrote:

(I think a lot of internal-operation cycles end up putting $xxFFFF on the bus, which might often map to ROM).

$FFFF might be a Motorola 6800 and/or 6809 thing, but 65xx's don't do that. Dead aka "Internal Operation" cycles on 65xx chips tend to drive the address bus with a Partially Formed Address resulting from indexing, or an extra fetch off PC due to a conditional branch -- that sort of thing. All the various dead-cycle quirks are collected here.

-- Jeff

[backspace119]

Dr Jefyll wrote:

Right. To omit the '245 transceiver, you really want every chip on the data bus to respond crisply. Sometimes that's a battle not worth fighting, because including a '245 isn't that big a deal. (And if delay is an issue, there are '245 variants based on FET switches, and these have no propagation delay per se. An active switch does has a small resistance, though, so there *is* a tiny delay based simply on RC.)

Ya, it seems there are 245s that are fairly quick, so I didn't bother considering removing it, I just qualified it with the Bank LE signal generated from /RDY and PHI2

Dr Jefyll wrote:

$FFFF might be a Motorola 6800 and/or 6809 thing, but 65xx's don't do that. Dead aka "Internal Operation" cycles on 65xx chips tend to drive the address bus with a Partially Formed Address resulting from indexing, or an extra fetch off PC due to a conditional branch -- that sort of thing. All the various dead-cycle quirks are collected here.

That's very useful, thank you for linking it, To be safe I qualified the CS of the EEPROM with VDA | VPA, although it did require adding an additional gate delay to the CS (it's only 2 gate delays total, so hopefully not that bad). Do you think it's possible that this is unneeded? By this I mean, would it ever be possible for the machine to accidentally address EEPROM (addresses 0x00C000-0x00FFFF iirc) during a dead cycle? I know I've got IO protected through VDA, so it won't accidentally read anything from there, and it shouldn't ever be trying to write during a dead cycle, the only issue is making sure wait states aren't accidentally generated. Come to think of it, maybe it's better to qualify the wait state generator with VPA | VDA instead?

[Chromatix]

As Jeff pointed out, even if $xxFFFF isn't a thing, the address left on the bus is typically a repeat or preview of one used in adjacent cycles. With a 6502, you don't get the option of avoiding these accesses, because the CPU doesn't explicitly signal which accesses are real and which can be ignored - but the '816 does.

So if you're executing code from ROM, you might end up adding more wait-states than necessary if you don't qualify the ROM select, and that'll slow you down even more than simply running from a slow ROM needs to. Qualifying the select has the dual benefit of implicitly qualifying the wait-state generator, and avoiding putting the ROM itself into its active state, which consumes maybe 100x more power than standby.

[backspace119]

Chromatix wrote:

As Jeff pointed out, even if $xxFFFF isn't a thing, the address left on the bus is typically a repeat or preview of one used in adjacent cycles. With a 6502, you don't get the option of avoiding these accesses, because the CPU doesn't explicitly signal which accesses are real and which can be ignored - but the '816 does.

So if you're executing code from ROM, you might end up adding more wait-states than necessary if you don't qualify the ROM select, and that'll slow you down even more than simply running from a slow ROM needs to. Qualifying the select has the dual benefit of implicitly qualifying the wait-state generator, and avoiding putting the ROM itself into its active state, which consumes maybe 100x more power than standby.

I suppose that's true, I guess I'll leave it how it is

[BigDumbDinosaur]

backspace119 wrote:

So here's my /OE /WE circuit now...

It won't work quite as expected. Rather than I explain why to you and deprive you of the opportunity to figure it out, let me just leave you with a snippet from the 65C816 data sheet about the RDY pin:

• 2.24 Ready (RDY)
  
  The Ready (sic) is a bi-directional signal. When it is an output it indicates that a Wait for Interrupt instruction has been executed halting operation of the microprocessor.

The above is from the data sheet published on November 9, 2018.

Quote:

I've attached /OE and /WE to the /OE and /WE of all devices that use wait states, the RTC, EEPROM, and DUART (28L92). Other devices are still qualified off my READ, WRITE, and /READ, /WRITE signals, which are made by R/W and PHI2

Such segregation isn't necessary and only serves to add complexity to the circuit. Devices that don't use wait-states won't care about what /OE and /WE are doing when said devices haven't been selected. When they are selected, your glue logic shouldn't be generating a wait-state.

Incidentally, the 28L92 can be run at full bus speed without wait-stating in a 5 volt system. I've booted my POC V1.1 unit, which has no wait-state logic, at 15 MHz (using a 45ns PROM). As long as the 28L92's chip select is generated as soon as VDA || VPA is true the DUART will easily keep up with the '816 at full speed. Read page 54 of the 28L92 data sheet to see the bus timing specs.

Quote:

If this checks out I'm going to look at the clock circuit, and see about either changing it back to a oscillator can or possibly leaving it, but not using it for slowing the clock to talk to devices. One last thing here, iirc using this circuit I've attached I don't need to worry about absorbing clock pulses, since the /OE and /WE of devices won't be pulsing off the clock now, is this correct?

I again urge you to rein in the creeping featurism and build a basic unit so you can get your feet wet. You are, in my opinion, too fixated on things that should not yet be in consideration.

If it were me designing the unit, I'd use a can oscillator driving a flop for your Ø2 clock circuit. When I built my original POC V1.0 unit 10 years ago, I started with a 2 MHz oscillator, and also purchased 8 MHz and 16 MHz cans, as a goal was to see the unit run at 8 MHz. The unit almost worked on the first try...a missing trace on the PCB caused a partial DOA. Some blue wire fixed that problem, and the unit booted and displayed a simple banner on the terminal.

POC V1.0 POST Display

During early testing, I accidentally put the 16 MHz can in when I meant to put in the 2 MHz one. It booted and ran fine, thus accidentally meeting the goal of 8 MHz operation.

My point is that despite having nearly 40 years of professional electronics design and troubleshooting under my belt at the time, I kept POC V1.0 simple so I wouldn't be overwhelmed with issues, should they arise. You should do the same.

[BigDumbDinosaur]

backspace119 wrote:

So here's my /OE /WE circuit now, as far as VDA and VPA go, I've got VDA qualifying all accesses to any IO, and VDA | VPA qualifying access to the top 8 bits (2 4M memory modules).

Read/Write Generation

I was kicking this around a bit and came up with a slightly different version.

Alternate Read/Write Generation

rw_logic_w_waitstate.gif (6.87 KiB) Viewed 535 times

The difference is my version is gated by a signal that goes high when the glue logic selects something that needs to be wait-stated. It is independent of whatever is going on with RDY. Proper operation requires that chip selects not be qualified in any way by Ø2.

[backspace119]

BigDumbDinosaur wrote:

I was kicking this around a bit and came up with a slightly different version.

rw_logic_w_waitstate.gif

The difference is my version is gated by a signal that goes high when the glue logic selects something that needs to be wait-stated. It is independent of whatever is going on with RDY. Proper operation requires that chip selects not be qualified in any way by Ø2.

I had been thinking about something like this, I have that circuit for my /READ and /WRITE signals that get used throughout (my READ and WRITE are only used for one of the memory modules, since they're selected based on an address bit, and the one that requires the address bit be high was easier to implement (and cheaper in gate delays) with an active high READ and WRITE).

I didn't know that about the 28L92, I thought I'd read somewhere on here that people were running it with a single wait state.

As far as keeping it simple with the clock, what I was trying to do was prevent having to go back and redesign that part, since I already have the LTC1600/1799 chip in it and routed, I know I was unclear there, but I was actually trying to prevent more design time so I can get this show on the road.

As for the RDY pin, let me take a stab here, if the CPU starts a WAI command it's going to pass that signal into my circuit for OE and WE, which will in turn cause chips to possibly put garbage on the bus, and maybe bus contention too, am I correct?

[Chromatix]

According to the datasheet timings, the 28L92 will run up to 8MHz at 5V and 6.5MHz at 3.3V, and will accept its independent oscillator signal up to 8MHz. There is always the possibility of getting a "good one" that can be run faster in practice - and that might even be normal for certain parts.

The official specs are often quite conservative so as to offer high manufacturing yields and wide temperature ranges. As hobbyists, we might often run our projects only around 25°C, and we can be satisfied with getting eight "good" parts out of a batch of ten, or maybe a deviation in terms of power consumption if we violate some timing but otherwise no ill effect. Often, too, the specs were set some time in the past, and the manufacturing process has been refined in the years since so that yields and performance are both improved.

For something like the 28L92, a wait-state when accessing it doesn't matter a great deal for overall performance, unless you're trying to do something really intensive with the timers. So I would take the safe option.

[backspace119]

Chromatix wrote:

According to the datasheet timings, the 28L92 will run up to 8MHz at 5V and 6.5MHz at 3.3V, and will accept its independent oscillator signal up to 8MHz. There is always the possibility of getting a "good one" that can be run faster in practice - and that might even be normal for certain parts.

The official specs are often quite conservative so as to offer high manufacturing yields and wide temperature ranges. As hobbyists, we might often run our projects only around 25°C, and we can be satisfied with getting eight "good" parts out of a batch of ten, or maybe a deviation in terms of power consumption if we violate some timing but otherwise no ill effect. Often, too, the specs were set some time in the past, and the manufacturing process has been refined in the years since so that yields and performance are both improved.

For something like the 28L92, a wait-state when accessing it doesn't matter a great deal for overall performance, unless you're trying to do something really intensive with the timers. So I would take the safe option.

After routing it (EDIT: to use a wait state), I'd prefer not to re-route it yet again. I'm not planning on using it's timers, so I suppose access time won't be that big of an issue here. Although I think BDD did bring up a good point about the OE and WE signal generation, that is, if I'm correct about what he's saying, in that if WAI is called it will drive these circuits.