shopping list

[Michael]

allisonlastname wrote:

How do you recommend mapping the hole?

Another decoder & glue logic method, if I may, specifically for those 32K/32K RAM/ROM configurations. Note the use of a 64K RAM and its active high CS2 input used to qualify RAM read and write operations.

[allisonlastname]

floobydust wrote:

I've attached a section of a schematic for this,

I can see a way to minimise gate delays here, but it would limit me to using IO ICs with multiple chip selects. You could route /IOSEL directly to a chip select input, and then have the 3-to-8 decoder go to the other chip select. That way, /IOSEL doesn't need to go through the decoder and you save a few nanoseconds of propagation delay. Limiting my choice of IO chips probably isn't a great idea at this state of the process though.

[Michael]

allisonlastname wrote:

As for programming ROMs, I have an arduino and a raspberry pi. Googling for "arduino eeprom programmer" turns up a lot of results, so I think we're fine there.

May I ask which Arduino you have, please? An Uno R3 or Nano perhaps?

[drogon]

allisonlastname wrote:

floobydust wrote:

I've attached a section of a schematic for this,

I can see a way to minimise gate delays here, but it would limit me to using IO ICs with multiple chip selects. You could route /IOSEL directly to a chip select input, and then have the 3-to-8 decoder go to the other chip select. That way, /IOSEL doesn't need to go through the decoder and you save a few nanoseconds of propagation delay. Limiting my choice of IO chips probably isn't a great idea at this state of the process though.

A this point, especially if you're sticking to breadboards and 1-2Mhz, then it's not really going to be an issue. Get a proof of concept going then worry later about making it go faster.

That was another reason I used a GAL - my systems run at 16Mhz on a simple double sided PCB, but with care, etc. you can go much much faster. I don't feel the need right now.

-Gordon

[floobydust]

allisonlastname wrote:

floobydust wrote:

I've attached a section of a schematic for this,

I can see a way to minimise gate delays here, but it would limit me to using IO ICs with multiple chip selects. You could route /IOSEL directly to a chip select input, and then have the 3-to-8 decoder go to the other chip select. That way, /IOSEL doesn't need to go through the decoder and you save a few nanoseconds of propagation delay. Limiting my choice of IO chips probably isn't a great idea at this state of the process though.

Well, I've made a few boards which are running 100% reliable with a 5MHz CPU clock, the limiting factor being the R65C51P4 ACIA. I have one board set which is running at 10MHz, using a 70ns 28C256 EEPROM and a early sample WD65C51 which doesn't have the Xmit bit problem. I don't think you'll have a speed problem.... unless you're trying to run at very high clock rates. Exactly how fast do you plan on running your first system at?

If you think you have to go faster, just use a PLD. My C02 Pocket uses an ATF22V10C and that has much less prop delay.

[allisonlastname]

Michael wrote:

May I ask which Arduino you have, please? An Uno R3 or Nano perhaps?

It's a Seeeduino v3, which is pretty much pin compatible with Uno for all intents and purposes. It does have an onboard switch to select 5v or 3.3v operation, which is nice.

floobydust wrote:

Exactly how fast do you plan on running your first system at?

I'm aiming for 1mhz. If I can get it reliably working that fast, I might aim for something faster, but I won't be pushing for much above that for a while yet. I only pointed out the design change as an observation, rather than something I was seriously considering.

[drogon]

allisonlastname wrote:

I'm aiming for 1mhz. If I can get it reliably working that fast, I might aim for something faster, but I won't be pushing for much above that for a while yet. I only pointed out the design change as an observation, rather than something I was seriously considering.

This:

https://projects.drogon.net/ruby-6502-on-stripboard/

Ran at 16Mhz.

Achieving 1 or 2 Mhz on a breadboard ought to be easy.

-Gordon

[BigDumbDinosaur]

As designed, your circuit will not work as expected.

You are using Ø2 to qualify chip selects, which is not good design practice. In a 65xx system, chip selection and read/write gating are two separate operations, with the former occurring during Ø2 low and the latter occurring during Ø2 high. Note that everything that occurs during a 65xx bus cycle starts with the fall of the clock.

The MPU drives A0-A15 with a valid address tADS nanoseconds after the fall of Ø2. At that time, the glue logic should decode the address and select the device to be accessed. In particular, chip select and address pins of 65xx peripherals must be valid and stable before the rise of the clock. In your circuit, your 65C22 will not see a chip select until Ø2 goes high and hence will fail to respond.

What does need to be qualified by Ø2 is the write input of non-65xx peripherals, in this case, the SRAM. The data bus cannot be considered valid during Ø2 low and furthermore, the address bus will be briefly unsettled prior to the elapse of tADS. Asserting /WE during that time may result in corruption of RAM contents due to a potential timing race.

Attached is an example of how RAM/ROM and I/O can be controlled in a 65C02 system with three gates and a 3-of-8 decoder. The result is a maximum of 48K of RAM and 12 K of ROM, plus up to 8 I/O devices. This circuit has been tested at 20 MHz.

[allisonlastname]

Ok, I've done everything except clock generation. Let me know if there's any issues with the design.

[Michael]

Would I be out-of-line suggesting a couple parts changes? Unless you already have 62256 RAM and 28C256 EEPROM IC's, you might consider using a 64K or 128K RAM IC and a 39SF010A Flash ROM IC instead. A new AT28C256 costs $12+ compared to $3+ for a new 39SF010A and a new 128K RAM IC like the AS6C1008 is almost the same price as a new 32K 62256. Also, you could get a 5-pack of skinny 64K W24512AK-15 RAM IC's for about $3.50 (including shipping) from a vendor on AliExpress.

IMO, the 39SFxxx series Flash ROM's are easier to program and the extra active high chip select on 64K / 128K RAM IC's is quite handy but these chips will take up more room on a breadboard or a PCB.

Good luck. Cheerful regards.

[BigDumbDinosaur]

allisonlastname wrote:

Ok, I've done everything except clock generation. Let me know if there's any issues with the design.

A few things and you should be ready to build:

1. You are mixing logic families. VOH in TTL (i.e., 74LS) logic is a guaranteed 2.4 volts, with a theoretical maximum of 3.4. A CMOS logic 1 is typically VCC × 0.7 volts, which is higher than the capabilities of TTL logic. While it probably will work okay, there is no guarantee it will.
2. /OE on the ROM should be connected to the same circuit to which /OE on the SRAM is connected.
   
   A sneaky benefit of gating /OE on Ø2 high is that the ROM will inject milder transients into the power supply circuit than it would if simultaneously selected and enabled. Also, the ROM will get off the data bus more quickly if /OE is enabled only when Ø2 is high. In this circuit, that is not a critical requirement. However, it may become so when you build your next design and decide to amp up the clock.
3. Add a 3.3K pullup resistor to your reset circuit. The DS1813’s internal pullup is weak and relying only on it to keep reset high may make your reset circuit noise-sensitive.
4. You have your Ø2 circuit connected to the 65C02’s Ø2 output. WDC advises against doing so in new designs. They recommend that everything should be driven by the clock oscillator.
   
   A problem with using the C02’s clock outputs is they lag the clock input (Ø0) by an unspecified amount, hence subtle timing errors could be introduced with any device slaved to the clock, e.g., the 65C22. WDC no longer tests Ø1 out and Ø2 out and doesn’t guarantee their behavior. These outputs are present only to provide backward compatibility in systems in which the NMOS 6502 is to be replaced with a 65C02. Modern HCMOS clock oscillators have more than enough fan-out to handle all reasonable loads.
5. Note that the 65C22S has a totem-pole IRQ output—which can’t be wired OR. While that is of no concern in this design, it is something to keep in mind in a future design in which more than IRQ source is present.
6. I recommend you connect NMI and SOB to VCC through 3.3K pullup resistors so those inputs can be put to use. In my POC units, I have a DS1813 attached to NMI so I can manually interrupt a running program that has gotten stuck in a loop.
   
   SOB can be used as a high-speed input, which may be of some value.

[allisonlastname]

BigDumbDinosaur wrote:

You are mixing logic families.

All the 74 is supposed to be 74HC but kicad only has 74LS symbols for a lot of stuff.

BigDumbDinosaur wrote:

Add a 3.3K pullup resistor to your reset circuit.

Does that go here?

BigDumbDinosaur wrote:

You have your Ø2 circuit connected to the 65C02’s Ø2 output.

Ah. I had assumed that was the done thing, but apparently not. Is phi2 the inverse of phi0?

BigDumbDinosaur wrote:

Note that the 65C22S has a totem-pole IRQ output—which can’t be wired OR.

BigDumbDinosaur wrote:

I recommend you connect NMI and SOB to VCC through 3.3K pullup resistors so those inputs can be put to use.

The prototype is gonna be on breadboards, so I can mess with those when I need to.

[BigDumbDinosaur]

allisonlastname wrote:

BigDumbDinosaur wrote:

Add a 3.3K pullup resistor to your reset circuit.

Does that go here?

2023-04-02_23-57.png

Can you please post that in monochrome? I’m partially colorblind and can’t make out all of what is in your graphic.

[allisonlastname]

This better?

[GARTHWILSON]

allisonlastname wrote:

Is phi2 the inverse of phi0?

Φ0 is an input.  Φ1 is an output, basically Φ0 followed by an inverter.  Φ2 is also an output, basically Φ1 followed by another inverter.  So although Φ2 is supposedly in phase with Φ0, it is slightly delayed, by the propagation delays of the inverters.  In ye olden days, the Φ2 output always went to the other things that took Φ2; but WDC now recommends that for their W65C02S, you run everything from the same signal you feed to the Φ0 input (sometimes called the Φ2 input which is pin 37 on the DIP), not the Φ2 output (which is pin 39 of the DIP).