There are so called emulator adapters available (? at least I hope so). For example here or such a beast. On top of that you can connect a board containing your CPLD plus buffers. This looks ugly but should work. But it isn't cheap for sure. Perhaps designing a POC V2.2 with drivers will be cheaper.

No. The below circuit generates Ø2 and delivers it to both the '816 and the CPLD. In fact, I tried to arrange the PCB layout so the distance from the flop's Q output is about the same to both the MPU and the CPLD to keep clock skew out of the picture.


PHI1 is not used.


Output slew rate is something I have tinkered with during troubleshooting. It doesn't seem to make any difference.

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

You're right: the first solution is ugly and clumsy to boot. The second one is more elegant, although a PCB would have to be made to use it.


Neither route gets me excited.


POC V2.2 is in the design stage as we speak—so to speak. I'll post more once I've got a circuit worked out.

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

I've got a "first cut" design done for POC V2.2. Changes relative to V2.1 are as follows:

• Removal of some functions from the CPLD. The CPLD in V2.2 will be limited to generating chip selects, which means only combinatorial logic will be used. This change should (in theory) remove any tricky timing issues that may have been lurking in V2.1's CPLD. Functions that were present in the V2.1's CPLD and have been removed are:
  
  
  • Generation of qualified read and write signals. Discrete logic is used for this function, in the same circuit configuration I used in POC V1.1.
    
    
  • Memory mapping. I have eliminated the "layered" memory map that makes it possible to replace ROM at $00E000-$00FFFF with RAM, as well as replace RAM at $00C000-$00CFFF with ROM. In V2.2., ROM will appear in both of these address ranges. RAM will appear at $000000-$00BFFF, $00D800-$00DFFF and $010000-$0FFFFF.
    
    
  • A16-A19 address bit generation. This function is now handled by discrete logic, specifically a 74AC573 D-latch, connected up in a fashion similar to the circuit shown on page 48 of the 65C816's data sheet. As my clock generator circuit can produce an inverted Ø2, I don't need the inverter shown in WDC's circuit.
    
    
  • Wait-state generation. As I know the ROM I've been using can easily work with a 12.5 MHz Ø2 clock, I decided to forego wait-stating and the timing issues that it can pose.
  
  
• Use of buffers/drivers on the outputs of the CPLD. The purpose of this change is to produce voltage level conversion, as the CPLD's output levels are really TTL, not CMOS. If you examine the schematic and PCB layout, you'll see a jumper block (JP1), which can be configured to connect control inputs on all devices driven by the CPLD directly to the CPLD or to the buffers/drivers. This will allow me to determine what effect, if any, the CPLD's output voltages has on the unit's ability to run in a stable fashion. There are a total of nine outputs on the CPLD, so I am using a 74ACT245 to handle eight of them, and one section of a 74ACT125 to drive the ninth circuit.
  
  
• Use of a bus transceiver on the data bus. Here again, I'm using a 74ACT245 as a level converter. The two SRAMs and the EPROM actually produce TTL voltage levels, not CMOS, which the 'ACT245 will convert to the CMOS levels expected by the 65C816 (if one can believe the WDC data sheet) during a read cycle. The control circuitry to the 'ACT245 is arranged so the data bus will be isolated from the '816 during Ø2 low, which is when the bank bits are present. This is a bit of a "belt and suspenders" move, since reads and writes are also qualified by Ø2. In theory, data bus contention during the "turn-around time" after the '816 ceases driving the bank bits onto the data bus shouldn't occur.

Here's the schematic:


Here's the PCB layout:


The PCB's size top-to-bottom is the same as that of V2.0 and V2.1, but is 5/8" (15.88mm) larger side-to-side to accommodate the additional hardware. I also did some minor rearrangement in places to get a better layout, as well as to make room for an Aries 28-C182-10 "ejecta-DIP" socket (U12) for the ROM. This change was made to eliminate having to piggy-back a ZIF socket on the ROM socket for quick ROM changeouts.

Here's the source code for the CPLD logic:

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

Based on a (very) quick scan, I'd say those LED's need two current-limiting resistors, not one.

I have to say I'm not a fan of schematics which (like other pages of this one) are basically just nets lists. I welcome the visual aid of actual lines drawn to indicate connections (or fundamental connections such as buses at least). They increase readability, almost as the comments in a source file do. (Am I the only one that feels this way?) Anyway, I'm glad you didn't draw the LED's as a net list. Maybe I'll look at the other pages some other time.

Good luck with the new project, BTW!

-- Jeff

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

You're right!


Thanks!

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

What about something like:



Or am I hopelessly out of my league?

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Yup, that'll work. It does waste some current, since there's always a resistor effectively in parallel with whichever LED is active, and really you only want a resistor in series. Instead it's always one of each. But OTOH with this scheme it'd be easy to substitute a single, bi-color LED instead of two discrete devices if you wanted to.

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

I second that

A brief look at your pcb layout I found:
I would suggest moving C27 just below C28 will greatly ease the handling of the ZIF socket.

You have two unused triple input AND gates left and 3 buffers of an AC125. I haven't looked at the specs, but wouldn't one of the two gates serve for buffering /O3 as well?

You have made no provisions to /ABORT and to slow down (using RDY or manipulating PHI2). But you have 4 I/O pins left on your ATF:
- I would use /ABORT to detect a write attempt to the ROM space, but it could become handy for other situations as well.
- If you later add an extension board there the sheer length of the signal lines may force you to slow things down.


Regards, Arne

One thing more:I assume that are typos.

I decided to go with Jeff's circuit. Far be it from me to waste precious milliamps—even though a PC power supply runs the thing.


I wanted to use a bi-color LED but couldn't find one where the anode of one section is connected to the cathode of the other. The multi-leaded versions all seem to be common anode or common cathode. There are bipolar LEDs available, but they have two leads, which would end up complicating what should be a simple circuit. As it so happens, I've got tons of green and red LEDs available and PCB space isn't at a premium at that location, so I took the lazy way out.

Attached are the corrected schematic and PCB layout.



The layout graphic is a little deceptive as far as clearances go. The way in which I drew the ejection socket (which isn't a ZIF, see below image) includes the space required to clear the two levers that force the ROM out of the socket. Moving C27 probably wouldn't gain much as far as working room is concerned.



No, they are correct.

The console port on J2 (shown on the last page of the schematic) is rigged up so it can be operated at TIA-232 or TTL (actually, CMOS) voltage levels, depending on how the jumper blocks JP2 and JP3 (located on the same page as U15) are configured. The TIA-232 configuration is for use with a standard terminal or a thin client acting as a terminal. The TTL configuration is for testing a VT-100 terminal device I have yet to build.


No. The 'ACT125 and 'ACT541 are being used as level converters, which the AND gate wouldn't be able to do—it's not a TTL-compatible device.


Implementing ABORT is timing-complex and not something envisioned for the POC V2 iteration.

If you read my previous post you will see I intentionally decided to leave wait-stating out of the picture so as to remove all clock-related functions from the CPLD. The V2.2 design has a specific purpose and that is to prove—or not prove—that differing voltage levels (TTL vs. CMOS) are behind some of the problems with POC V2.1.

The only expansion beyond what you see in this design will be my SCSI host adapter, which plugs into socket J5, same as in POC V1.1, the latter which runs at 12.5 MHz. No wait-stating is needed with the host adapter.

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

I added an amount for your fingertips and considered the position of C27 as a threat

Sorry, overlooked - perhaps too many jumper options in that section.

I don't see a difference between the electrical characteristics of a 74ACT125 and a 74ACT11. Same voltage levels, drive currents, delays.

Well, I assumed that this radical action is due to the problems with V2.1. But consider: if this new POC proofs that the signal levels are of that importance it seems to be then you need another POC to deal with the delicious timing of RUN and ABORT. If you now at least made provisions (IOW route the necessary connections) to add further control you can give it a try without new hardware. Leaving the associated CPLD pins unprogrammed should let them act like inputs or tristates. And you may insert jumpers or solder bridges near the CPU if you fear these additional traces might cause trouble if left floating.

Regards,
Arne

The levers are only used to eject the device, so little to no finger clearance is required outside of the levers—one pushes out on them to eject. When the device is inserted into the socket the levers are automatically closed as the device is seated. You'd have to see the socket to see why that clearance isn't necessary.


74ACT11 on the schematic is a typo. U6 is actually a 74AC11. Aside from that, it is near the opposite end of the board, right above J5. Routing to hook up that unused gate to the CPLD and the JP1 jumper block would be awkward, among other things.


Okay...


Circuitry is in place to implement wait-stating. For now, there is no logic in the CPLD to implement wait-states, so it won't activate any of the pins involved.

I have no plans to implement ABORT interrupts in this design. That is for a future design with more powerful logic.

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

I hope these changes work out. Lot's of effort in this so far.

_________________
Bill

My mods to V2.2 to add wait-stating won't work...something that was determined in my sleep last night. I'll explain.

When the 65C816 is stopped by negating RDY it halts in what is effectively the Ø2 high state, the same as if the Ø2 clock had been "frozen" in the high phase. While halted, the '816 will maintain the state of A0-A15, RWB, MLB, VPB, VDA, VPA and E as they were immediately prior to the negating of RDY. If the '816 was halted during a write cycle, D0-D7 will contain whatever it is that the '816 is writing. The MX output will reflect X, since the internal clock will be high.

Now, here's the problem. The CPLD in V2.2 is being used only to generate chip selects via combinatorial logic. Discrete logic is being used to generate the /RD and /WD signals, as well as the A16-A19 address bits. Also, a bus transceiver acting as a level converter sits in between the MPU's D0-D7 connections and the system's RAM, ROM and I/O. Ø2 is used to qualify /RD and /WD. Ø1 (inverted Ø2) is used to open and close the 'AC573 latch that captures the A16-A19 address bits. Ø1 is also used to gate the data bus transceiver so it isolates the rest of the data bus from the '816 while Ø2 is low, which is when the bank bits are emitted.

Considering all this, it is patent that merely halting the '816 with RDY won't work as expected—significant problems will arise. The first one is the state of /RD or /WD (depending on if the '816 has been halted during a read or write cycle, respectively) will not be maintained while the '816 is stopped. Instead, /RD or /WD will rise and fall as the clock falls and rises, possibly confusing the device being accessed.

Adding to the confusion, each time Ø2 falls, the data bus transceiver will go to the high-Z state, breaking the connection between the '816 and the device being accessed. Again, during a wait-stated write cycle the device being accessed may malfunction due to inadvertent timing violations.

More onerously, the latch that captures the bank bits and generates A16-A19 will open each time Ø1 goes high during the wait-state and then close again when Ø1 goes low. The problem is that while the latch is open it will be capturing data, not bank bits. Hence the effective address seen by the rest of the system will change during the wait-state, causing no end of grief.

Faced with these little contretemps, I have to make one of two choices: forego wait-stating in V2.2 or concoct a different way to accommodate slow hardware. Wait-stating is not essential, as the chosen hardware can run quite fast...12.5 MHz is easy with POC V1.1, which is 100 percent discrete logic. On the other hand, I have aspirations of trying to get the speed higher in V2, which will demand wait-states on ROM and some of the I/O hardware. So, what's a broken down old dinosaur to do?

While contemplating this matter, I was staring at the schematic, specifically the clock generator circuitry, and thinking about what goes on inside the '816 while RDY is low. That's when I decided the solution might be in halting the clock during Ø2 high for the required amount of time and then letting it resume. I would be simulating externally what the '816 does internally during a wait-state (also when the WAI instruction has been executed).

The basic clock generator circuit in all my POC units is:


I use the 74AC74 flip-flop to strengthen the clock signal, assure symmetry and in the case of V2.2, generate the Ø1 signal that gates the bank bits latch and the data bus transceiver. As is typical of this sort of circuit, the /CLR and /PRE inputs to the flop are tied to Vcc, which causes the flop's Q and /Q outputs to follow the D input as the clock oscillator's output goes high on each cycle. Of course, /CLR and /PRE can be used in other ways, as can be seen by examining the flop's function table:


In particular, note the first row in the table, in which /PRE is low. In this case, Q will stay high and /Q will stay low, without regard to what is going on at the CLK and D inputs. Q high and /Q low is the Ø2 high state.

So, my thinking goes, if I assert /PRE when a wait-state is needed, Ø2 will be "frozen" high, causing the '816 to halt as though RDY has been brought low. With Ø2 continuously high, the state of /RD and /WD will be maintained. At the same time, Ø1 will be "frozen" low. Hence the data bus transceiver will remain gated to maintain the path between the '816 and the rest of the system, and the bank bits latch will remain closed, thus maintaining the state of A16-A19. So far, so good.

Naturally, solutions may give rise to new problems. Since it would be the CPLD that would make the determination when a wait-state is needed and how long it should be, it must have a continuously running clock input and most importantly, that clock must stay in sync and phase with the Ø2 clock when the latter is not halted. The unused second section of the flop can be used to produce the CPLD's clock, which is referred to as the GCLK.

Here's the modified clock generator circuit:


Note the netlist symbol /STP (top right corner). This will be an output from the CPLD. Normally, /STP will be driven high, keeping U1a's /PRE high—Ø1 and Ø2 will run. When the CPLD has determined that a wait-state is required, it will drive /STP low, driving U1a's /PRE low and freezing the Ø1 and Ø2 clocks.

Where the trickiness will come in is in timing. If this is to work, the CPLD must assert /STP immediately after GCLK has gone high in order to start the wait-state. When the wait-state has expired, /STP must be deasserted immediately after GCLK has again gone high so Ø2 and GCLK remain in phase.

Opinions?

Incidentally, I'd expect this arrangment would also work with the 65C02.

————————————————————————————————————
Edit: I started a separate topic on using Ø2-high stretching to achieve wait-states.

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