I would suspect that as well.... I'm using CTS MXO45HS cans (half-size). Accord to the datasheet, the 1MHz-20MHz cans are typical 10ma draw with a 50pF load. Looking at the W65C02 datasheet, the PHI2 clock input is 5pF, but I'd need to measure the current to see if it's much less with the lesser load.

_________________
Regards, KM
https://github.com/floobydust

It's not because of the load though. 5pF charged to nearly 5V and discharged to nearly 0V at a 20MHz rate takes less than a mA. It's gotta be the TTL logic inside. The can oscillator on my workbench computer takes about 75mA at a lower frequency (10MHz) which was typical back then. That's still well over than half the current budget for the whole computer with three VIAs, three ACIAs, A/D, D/A, op amp, line drivers and receivers, and a few other things.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

You're not any poorer after buying the power supply and scope than before. You're just not as liquid.

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

Yep, you're right. If I remove both GALs then I get between 40 and 45mA. I hadn't considered how much the GALs would use. I do have some AMD 22v10 PALs but the datasheet quotes 180-200mA ... each. You live and learn, I suppose.

Hi all

Here's an update with my 65C02v2 project. This is the one with the bank switching.
So far, so good. The board reads and executes instructions from ROM fine and can read/write bank 0 RAM. I've (literally) just now soldered in the links for the bank switching latch to the RAM and the decoding GALs. Should hopefully be able to do some tests tomorrow.
I'm especially happy with the RAM as it supports both the AS6C1008 and AS7C1024B (using an adapter). Both have the same pin-out and are 128KB (1Mbit). The main difference is that the AS6C1008 is a DIP package and is spec'd at 55ns while AS67C1024B is a SOJ32 and is spec'd at 10ns.

Here's a coupe of pictures (with AS7C1024B). The board has been tested fine at 25MHz divided down to 12.5MHz (via a D type flip flop). Haven't got anything faster crystal oscillator-wise at the moment, but I've got some on order (40MHz and 50MHz - so tests will be at 20 and 25MHz respectively).

Still need with hook up the VIA and ACIA IRQ lines.
The NMI is hooked up to a DS1813 power monitor and push button combo. I plan (as suggested by forum members) to have this as a "get out of jail free" option in case the computer locks up in a loop. I don't have the code for this at the moment, but I'll sort that out later.

Looks nice. It'll be interesting to see if it will fly at 20+ MHz.

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

Just an update. The RAM banking is not working properly yet. I can see the A15 and A16 lines changing as desired on the RAM (the latch is definitely working as desired), but the data is always written to and read from bank 0. Probably an issue with the secondary address decodeing GAL. I'll look into it further this evening.
In the emanwhile I hope my faster oscillator cans arrive today .

Could you publish the GAL code? I'm suspecting from your description of the problem that the latches in your GAL may not be closing when Ø2 goes high and hence losing the bank address. Another pair of eyes may spot something.

BTW, A15, would be driven by the 65C02 itself. It would be A16-A23 that would be controlled by your GAL.

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

Hi BDD.
I'm at work at the moment, but will be happy to publish the GAL code when I get home this evening.
However, I'm using a single cycle stepper and can deifnitely see the latch lines changing when told to and the outputs of the GAL to A15 and A16 *seem* ok. Apart from the bank switching, all actual RAM accesses for read and write go through ok and are definitely qualified with Ø2 going high.

A15 and A16 are controlled by the GAL to allow access to 4 banks (banks 0 to 3), with the swap area being between $2000 and $7FFF. This means that, bit-wise, it uses up to and including bit 14 for the RAM address inside the current bank and then bits 15 and 16 to select the bank.
The GAL code isn't really finished anyway as A15 and A16 have to be prevented from being anything other than 0 for addresses between $0000 and $1FFF (I always want that area accessible no matter the selected bank).

So to what is the MPU's A15 connected? I scrolled back through all the messages in this topic and didn't see a schematic anywhere.

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

I think that the schematic has been posted, but in another thread.


GAL1 (IC2) does the main device selection when it comes to address decoding
GAL2 (IC3) deals with IRQs and RAM bank selection

It shows you have the RAM's output-enable-not tied to write-not; so the RAM will only output data when it's supposed to be inputting data. That's backwards.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I concur with Garth: your hookup to the SRAM's control inputs is incorrect. You show the SRAM's /CE ("chip enable") connected to /RAM_SEL from GAL IC2, which is correct, assuming that /RAM_SEL is driven low during any RAM access. However, you have errors with the SRAM's /OE ("output enable") and /WE ("write enable") connections:

• You have /OE connected to /WR. I infer from that signal's name that /WR is "write data" and would go low during an MPU write cycle, qualified by Ø2. If so, then /RD ("read data") from GAL IC2, not /WR, should be connected to /OE on the SRAM.
  
  
• You have /WE on the SRAM connected to R/W, which is the unqualified output from the MPU's RWB pin. /WE should be connected to /WR of GAL IC2 so that a write to the SRAM is qualified by Ø2 (I'm assuming that is what the GAL does to generate the /WR signal).

Also noted:

• There is an /IRQ3 on GAL IC3 but no corresponding connection elsewhere. However, I see an /IRQ#3 connected to /IRQ of UART IC13. Are these supposed to be the same signal? The netlist generated by the schematic program will not see it that way.
  
  
• The UART's /IRQ output is open-collector, which means it needs a pull-up resistor (3.3K recommended).
  
  
• /IRQ4 on GAL IC3 appears to be unused at this time. It too must be pulled up so it doesn't pick up noise and cause spurious interrupts.
  
  
• You have /ROM_SEL tied to both /CE and /OE of the ROM. That means that the ROM will drive the data bus as soon as it is selected, even if the selection occurs during an MPU write cycle (which could happen due to programming errors). The result will be major bus contention between the ROM and the MPU. The ROM's /OE input should be connected to GAL IC2's /RD output to settle this issue.
  
  
• I see /IO65XX connected to the /CS2 inputs of both VIAs (IC7 and IC8), but can't find a corresponding connection elsewhere. If you are initially planning to not use those devices you should patch a temporary pull-up to their /CS2 inputs so noise doesn't cause random selections.
  
  
• Your symbol for the MPU is incorrectly labeled, and it appears that you have some incorrect connections. Pin 37 is the Ø2 clock input and is officially designated PHI2—it should be connected to pin 2 of IC14A. Pins 3 and 39—officially designated PHI1O and PHI2O, respectively—should not be connected to anything.
  
  Also note that the official designation for the read/write output is RWB. Yes, it's a bit of nitpicking but consistency is important in any design that will be seen (and possibly built) by someone other than yourself. The corresponding net should also be labeled RWB, not R/W, to make it clear that it is the "raw" read/write output of the MPU.
  
  
• You should consider connecting the MPU's RDY pin to an output on GAL IC2 so you can implement wait-states on slow devices. The UART would be a candidate for that, assuming it's not the genuine WDC 65C51.
  
  Note that RDY must be connected to a pull-up resistor no matter what, and as RDY is bi-directional, it will be necessary to prevent contention in the event the MPU executes a WAI instruction. This may be accomplished by either isolating RDY from the GAL with a small signal Schottky diode or by arranging the GAL's logic so its output to RDY is high-Z when a wait-state is not active. I recommend the latter.
  
  
• In addition to the four 1 µF charge pump capacitors required by the MAX-238 (IC15), another 1 µF capacitor should be used to locally bypass this device, as described in the data sheet. Additionally, I recommend that a 100 µF low ESR electrolytic be in parallel with the 1 µF bypass, both capacitors being placed as physically close to the MAX-238 as possible, with short and stout Vcc connections.
  
  
• Be sure to heat-sink IC11 if it will be subjected to the maximum input of 20 volts.

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

A trivial point, but I believe the cap on the MAX238 on the V+ pin is backwards.

_________________
8 bit fun and games: https://www.aslak.net/

Thanks for your input, guys. I've listed my responses/notes to what you said below.

@BDD and Garth

The /OE issue is my own fault. I'd forgotten to actually connect it in the diagram, so when I went to wire the board up I ended up trying to figure out
where to connect. At the time I was rewriting some of the GAL2 (2nd decoder) code and so made the /WR go high for writing (so the name of that signal is actually now completely misleading). Initially, I had intended for that signal to be low which is why it started out as /WR instead of WR.
The two lines R/W lines from GAL2 really should be marked as WR and /RD.

@BDD

With regard to /WE - yep, you are correct. I did have this qualified with PHI2 at one point in time and thought I'd changed it in the circuit, but I haven't. Time for a face palm, methinks. Oddly, the RAM does write and read back the correct values, though.

[edit] Now that I've had a chance at having a proper sit down and think: I qualified the CS for the RAM with PHI2, not read/write.

The IRQ side of things has not been implemented (yet), but you're right about the net list names. As I'm wire wrapping this it doesn't matter too much, but it should still match up so I'll go in and correct that.

The UART side of things isn't complete, but thanks for the tip regarding the need for a pull up for the open drain IRQ.

I was under the impression that GALs had automatic pull ups built in...? I'm happy to add a pull up resistor if needed if I'm wrong.

Thanks for the tip on the ROM /OE enable. I'll connect this up.

Please ignore the /IO65XX for now. I was going to use that for enabling the VIAs, but have changed my mind and gone for dedicated enable pins from GAL1. I'll remove that from the schematic to save on confusion.

Fortunately for me I went by the pin out from WDC in their data sheet for the CPU so PHI2 is actually connected to pin 37. At the time that I created this circuit diagram (some months back) I think I must have ended up with a poor EAGLE library for the 65xx range of ICs. I did contact WDC to ask if they have their own library, but unfortunately they don't but did say that they would look into it.
I'll see if I can find a library with a correct pinout for the WDC65C02 CPU.

Thanks for the advice with regard to the caps. I'll implement that.

For the moment IC11 is subject to 7V and current limited to 300mA so things seem ok heat-wise for the moment. Once I put in a dedicated PSU then I'll add in the heatsink as a precaution.

@Aslak3

Well spotted - I'll correct that on the schematic.

Thanks again for your advice and sharp eyesight, guys.

@BDD Just a side note: I received my 40 and 50MHz oscillator cans today so have tried both on this board. The 40MHz (divided down to 20MHz) seems to be running fine. The 50MHz one (divided down to 25MHz) is less stable and prone to lock up.
I'll have to give these a go on my original 65C02 project.