Let's start at the very beginning...

[BigDumbDinosaur]

DRG wrote:

Right. I've had a go at the schematic.

Looks like it ought to work.  An old design adage: bypass capacitors are like money.  No such thing as too much. 

In my designs, I assign the bypass caps the same number as the chips they bypass.  So U1 has bypass capacitor C1, etc.  In the case of devices that have multiple VCC inputs, such as the 65C816 in PLCC44, if the 816 is U1, its caps are C1a and C1b, etc.

[barnacle]

BigDumbDinosaur wrote:

its caps are C1a and C1b, etc.

Do you know, that's never actually occurred to me... in spite of looking at IC1a, IC1b...

D'oh!

Neil

[BigDumbDinosaur]

barnacle wrote:

BigDumbDinosaur wrote:

its caps are C1a and C1b, etc.

Do you know, that's never actually occurred to me... in spite of looking at IC1a, IC1b...

D'oh!

I didn’t invent the idea...I saw it years ago in the schematic for a Point 4 minicomputer.

For the ATF1504, if it’s, say, U3, its caps are U3a, U3b, U3c and U3d.

[plasmo]

A few comments about the schematic:
* Why are PHI2 and RWB shown as dashed lines?
* You can save a chip by combining 74HC11 function into 22V10
* Instead of using AS6C4008 (512K RAM), you can use the cheaper 128K RAM like AS6C1008. 128K RAM has active chip select that you can utilize to save 2 output signals from 22V10 so *WE and *OE are unnecessary.
* Instead of 22V10 controlling RAM and ROM chip selects, you can ground RAM and ROM chip selects and use 22V10 to control RAM and ROM output enables. This approach trading slightly higher power (because chip selects are always enabled) for faster operation (because output enables are faster).
* The speed bottleneck is 70nS SST39SF010. If you replace it with 45nS W27C512, you can achieve 14MHz operation.
Bill

[DRG]

plasmo wrote:

A few comments about the schematic:
* Why are PHI2 and RWB shown as dashed lines?No reason, really. I was just checking out the features of KiCad.
* You can save a chip by combining 74HC11 function into 22V10. I didn't think I had the available pins left to do this.
* Instead of using AS6C4008 (512K RAM), you can use the cheaper 128K RAM like AS6C1008. 128K RAM has active chip select that you can utilize to save 2 output signals from 22V10 so *WE and *OE are unnecessary. Understood, but I have the 512K in my parts drawer now.
* Instead of 22V10 controlling RAM and ROM chip selects, you can ground RAM and ROM chip selects and use 22V10 to control RAM and ROM output enables. This approach trading slightly higher power (because chip selects are always enabled) for faster operation (because output enables are faster). This will go into my memory banks for future use. I recall you mentioning it earlier in this thread when talking about ROMless.
* The speed bottleneck is 70nS SST39SF010. If you replace it with 45nS W27C512, you can achieve 14MHz operation. Again, understood, but I have 3xSST39 in my parts drawer now. I'll see if I can buy some - I see there not available at Mouser here in the UK.
Bill

What is the difference between "chip select" and "active chip select"? Is it the fact the AS6C1008 has 2 chip selects, an active low AND an active high?

Dave

[plasmo]

The standard 128K RAM has two chip selects, one active high and other active low. You can connect the active high chip select to phi2 to simplify decoding.

I've not used SST39SF010 in my 6502 designs, so this morning I tried a SST39SF010 instead of W27C512. I'm unable to run 14.7MHz, but I am able to run 12MHz, so I think your design should work fine at 8MHz.

Another comment regarding your schematic: you may want to pull up pin 3 (A15) of SST39SF010 so its addresses will match your memory map. This way you don't need to relocate your ROM code to $4000-$7FFF for the flash programmer in order to run it at $C000-$FFFF in actual hardware.
Bill

[DRG]

plasmo wrote:

Another comment regarding your schematic: you may want to pull up pin 3 (A15) of SST39SF010 so its addresses will match your memory map. This way you don't need to relocate your ROM code to $4000-$7FFF for the flash programmer in order to run it at $C000-$FFFF in actual hardware.
Bill

That's a great piece of advice - I think that would have stumped me as I just hadn't thought of it (having to relocate 65C02 code). Very opportune also, as I have just started breadboarding and have done the reset circuit, the address lines (orange) and half of the data lines (green).

Dave

[BigDumbDinosaur]

DRG wrote:

plasmo wrote:

* You can save a chip by combining 74HC11 function into 22V10. I didn't think I had the available pins left to do this.
...
* Instead of 22V10 controlling RAM and ROM chip selects, you can ground RAM and ROM chip selects and use 22V10 to control RAM and ROM output enables. This approach trading slightly higher power (because chip selects are always enabled) for faster operation (because output enables are faster). This will go into my memory banks for future use. I recall you mentioning it earlier in this thread when talking about ROMless.

I disagree with Bill on both of these.

1. Regarding the use of the 74HC11 to aggregate IRQ sources, VOH of a 22V10 is guaranteed to reach 2.4 volts minimum, regardless of loading.  In practice, the ATF22V10C usually does better if lightly loaded, but it is not assured.  The 74HC11’s outputs are guaranteed to exceed VCC × 0.7 under maximum loading, which is 3.5 volts in a five volt system.  If lightly loaded, the HC11’s VOH will reach approximately VCC - 0.1.  The 22V10’s unloaded VOH is nowhere near that.
   
   The problem isn’t merely one of can the device driving the MPU’s IRQB input get it high enough to clear an interrupt.  The problem is in how quickly that device can drive IRQB above the “trip point” at which the MPU will recognize that no interrupt is pending.  The rate at which the voltage at IRQB rises is determined by how quickly the device driving it can charge parasitic capacitance.  Depending on circuit design, PCB layout and how soon in your interrupt service handler the interrupt source is cleared, you could be inadvertently creating conditions for the generation of spurious (aka “ghost”) interrupts.
   
   Even with its relatively sedate output rise/fall performance, the HC11 will drive IRQB high enough to clear an IRQ faster than will the GAL.  This is because once the GAL’s output exceeds the theoretical 2.4 volt threshold, the rate of rise is not guaranteed and could be relatively slow under the not-insignificant loading imposed by parasitic capacitance.  As you ramp up the clock rate and hence reduce the time available to drive IRQB high, this lag could become a sticking point.
   
   Incidentally, I’d use a 74AHC11 to reduce prop time when an IRQ is cleared; prop time when an IRQ occurs is usually non-critical.  The AHC11 has the performance of 74AC logic, but the gentle edges of 74HC, reducing problems with ringing and other assorted noise.
    
2. Bill’s second point is true if chip select and /OE or /WE are simultaneously asserted by the glue logic.  This is not the case in your design; RAM or ROM will be selected well before Ø2 goes high and a read or write occurs (/OE or /WE will not go low until TPD nS after Ø2 goes high).  Hence you will achieve the same level of performance as would be achieved with chip selects continuously grounded and only gating /OE or /WE.  Don’t believe me?  Take a look at those devices’ timing diagrams for conditions in which chip select is asserted before /OE or /WE.
   
   As you plan to power your unit from a USB port, which is current-limited, not having the RAM and ROM continuously selected lessens the continuous minimum load on VCC and helps to avoid voltage sagging.  You already have a significant continuous load being imposed by the GAL, which draws over 100 mA, even when all inputs are quiescent.  Continuously selecting RAM and ROM needlessly adds to that loading.

It is my opinion that your design is correct for what you are doing.  I suspect 8-10 MHz will be the clock ceiling with using the 70 nS version of the 39SF010, depending on actual operating voltage and temperature.  Microchip makes a 55 nS version of that device, but it appears to only be available in PLCC.  A 55 nS ROM would be good for 12-14 nS, again depending on voltage and temperature.  Beyond that, wait-stating will be required for reliable operation.

[plasmo]

The counter to #1 is this figure in page 10 of ATF22V10B datasheet. It shows output can drive to 3.5V sourcing 12mA or 3.8V sourcing 2mA or 4.1V with no load.

Counter to #2 is my experience with BB6580 ( viewtopic.php?f=6&t=7868 ). It is a design with 6502, RAM, and 22V10. RAM chip select is grounded. power consumption is 75mA at 7.37MHz. My guess is 90mA at 7.37MHz with addition of SST39SF010. I had an epiphany this morning while testing SST39SF010 that a flash can be easily added to BB6580 thus emulating the design currently under discussion. I'll build up a modified BB6580 but publish the results under BB6580 topic so not to hijack this thread.

Experienced designers frequently have different opinions. These opinions are generally valid, but you should always push ahead. The worst outcome of design review is "paralysis by analysis".
Bill

[barnacle]

The traditional moderator for design paralysis is 'suck it and see'. We are uniquely fortunate to live in a time where circuit board manufacture is cheap and fast; we can try three versions and see which one works best (or indeed, at all!)

Neil

[BigDumbDinosaur]

I’ve never succumbed to design paralysis, but I also subscribe to the notion that haste can make waste.  I usually concoct a circuit, sleep on it for a day or two, go over it and if I can’t find any obvious reason why it shouldn’t work, I build it.  Once in a great while that doesn’t work out and I end up with an electrically-powered desk ornament. 

[DRG]

Well, it's been a while (Dec 24) since I did my last lot of 6502 tinkering. I ran out of spare time back then (and a little enthusiasm too), but I have a little more time on my hands now, so I'm picking up where I left off. In re-reading my posts to recall what configuration I had settled on, I'm not sure what was I thinking when I said...

DRG wrote:

I'm thinking my memory map will be as follows...

Code: Select all

C000-FFFF ROM (16k)
DD00-DFFF I/O (0.75k)
0000-DCFF RAM (47.25k)

Spot the obvious mistake of an address overlap! Maybe I was enjoying an early Christmas imbibe - in any event, that should read like this...

Code: Select all

C000-FFFF ROM (16k)
BD00-BFFF I/O (0.75k)
0000-BCFF RAM (47.25k)

Contiguous now at least.

W.r.t. the address decoding, if someone would be so kind as to double-check the following Wincupl code for me, please, I would be grateful...

Code: Select all

Name            DRG65C02 Address Decoder;
Partno          DRG65C02_ADA;
Revision        02;
Date            03/02/2025;
Designer        David Giblin;
Company         ;
Location        Edenfield, Lancs. UK;
Assembly        None;
Device          p22v10;


/* 
 * Pin Map
 
       --------
CLK   |1     24| Vcc
RW    |2     23| /WE
A15   |3     22| /OE
A14   |4     21| /RAM_CS
A13   |5     20| /ROM_CS
A12   |6     19| /IO_0
A11   |7     18| /IO_1
A10   |8     17| /IO_2
A9    |9     16| /IO_3
A8    |10    15| /IO_4
A7    |11    14| /IO_5
Gnd   |12    13| --
       --------
*/

/*
 * Inputs:  Signals from the 65C02 plus phi2.
 */

Pin 1  =  CLK;
Pin 2  =  RW;
Pin 3  =  A15;
Pin 4  =  A14;
Pin 5  =  A13;
Pin 6  =  A12;
Pin 7  =  A11;
Pin 8  =  A10;
Pin 9  =  A9;
Pin 10 =  A8;
Pin 11 =  A7;


/*
 * Outputs:
 */

Pin 23 = WE;      	/* to RAM and ROM chips */
Pin 22 = OE;      	/* to RAM and ROM chips */
Pin 21 = RAM_CS;  	/* to RAM /CS pin */
Pin 20 = ROM_CS;  	/* to ROM /CS pin */
Pin 19 = IO_0_CS; 	/* to IO_0 /CS pin */
Pin 18 = IO_1_CS; 	/* to IO_1 /CS pin */ 
Pin 17 = IO_2_CS; 	/* to IO_2 /CS pin */
Pin 16 = IO_3_CS; 	/* to IO_3 /CS pin */
Pin 15 = IO_4_CS; 	/* to IO_4 /CS pin */ 
Pin 14 = IO_5_CS; 	/* to IO_5 /CS pin */

/*
 * Local variables
 */

FIELD Address = [A15..A7];

/*
 * Logic:
 */

RAM       = Address:[0000..BCFF];
IO_0  	 = Address:[BD00..BD7F];
IO_1  	 = Address:[BD80..BDFF];
IO_2  	 = Address:[BE00..BE7F];
IO_3  	 = Address:[BE80..BEFF];
IO_4  	 = Address:[BF00..BF7F];
IO_5  	 = Address:[BF80..BFFF];
ROM       = Address:[C000..FFFF];

!WE       = CLK & !RW;
!OE       = CLK & RW;
!RAM_CS   = RAM;
!ROM_CS   = ROM;
!IO_0_CS  = IO_0;
!IO_1_CS  = IO_1;
!IO_2_CS  = IO_2;
!IO_3_CS  = IO_3;
!IO_4_CS  = IO_4;
!IO_5_CS  = IO_5;

This is based on the helpful advice in this thread on how to write these kinds of files. Hopefully, some of it stuck. It compiles with no errors or warnings.

Thanks.

Dave

[nora23169]

Sorry for being so late. My motivation was burnt out, so I focused on getting back on track. I'm currently creating an emulator for MOS6502 using Python. It will take some time, but I appreciate your help.

[BigDumbDinosaur]

DRG wrote:

Well, it's been a while (Dec 24)...W.r.t. the address decoding, if someone would be so kind as to double-check the following Wincupl code for me, please, I would be grateful...

It’s past my bedtime, so I can’t go into detail with your CUPL code right now.  I will say that your active-low output pin assignments, e.g., /OE, should be declared active-low and controlled with positive logic equations, which is opposite of what you are doing.  The CUPL programming guide (attached) explains why.

cupl_reference.pdf

CUPL Programmer’s Reference

(814.53 KiB) Downloaded 40 times

[DRG]

BigDumbDinosaur wrote:

I will say that your active-low output pin assignments, e.g., /OE, should be declared active-low and controlled with positive logic equations, which is opposite of what you are doing. 

Argh!! Yes, you did point this out earlier in this thread. So they should be more like this...

Code: Select all

/*
 * Outputs:
 */

Pin 23 = !WE;         /* to RAM and ROM chips */
Pin 22 = !OE;         /* to RAM and ROM chips */
Pin 21 = !RAM_CS;     /* to RAM /CS pin */
Pin 20 = !ROM_CS;     /* to ROM /CS pin */
Pin 19 = !IO_0_CS;    /* to IO_0 /CS pin */
Pin 18 = !IO_1_CS;    /* to IO_1 /CS pin */
Pin 17 = !IO_2_CS;    /* to IO_2 /CS pin */
Pin 16 = !IO_3_CS;    /* to IO_3 /CS pin */
Pin 15 = !IO_4_CS;    /* to IO_4 /CS pin */
Pin 14 = !IO_5_CS;    /* to IO_5 /CS pin */

/*
 * Local variables
 */

FIELD Address = [A15..A7];

/*
 * Logic:
 */

RAM       = Address:[0000..BCFF];
IO_0      = Address:[BD00..BD7F];
IO_1      = Address:[BD80..BDFF];
IO_2      = Address:[BE00..BE7F];
IO_3      = Address:[BE80..BEFF];
IO_4      = Address:[BF00..BF7F];
IO_5      = Address:[BF80..BFFF];
ROM       = Address:[C000..FFFF];

WE       = !CLK & !RW;
OE       = !CLK & RW;
RAM_CS   = !RAM;
ROM_CS   = !ROM;
IO_0_CS  = !IO_0;
IO_1_CS  = !IO_1;
IO_2_CS  = !IO_2;
IO_3_CS  = !IO_3;
IO_4_CS  = !IO_4;
IO_5_CS  = !IO_5;