6502 Design & concept questions.

[GARTHWILSON]

BigDumbDinosaur wrote:

GARTHWILSON wrote:

I wonder though if those diode arrays help much, since they basically duplicate the protection diodes at the inputs of CMOS ICs. If they're fast enough though, having a sudden change in the slope of the curve (where the diode starts conducting), and a sudden increase in current right there, can show up as a spike elsewhere on the transmission line.

The protection diodes at CMOS inputs are there for ESD purposes and aren't guaranteed to have any particular recovery time. Also, the diodes' zener voltage is not specified as well, but would presumably be somewhat higher than the device's rated input voltage maximum (Vin) to avoid inadvertent input signal clipping.

The Schottky array that I earlier linked is designed to both limit over- and under-shoot, and has a typical recovery time of 8ns. I doubt that a device's internal protection diodes can do that.

As far as I can tell, they're Shottky diodes in the very same arrangement, and they're not zener. In the '138 data sheet at http://www.ti.com/lit/ds/symlink/cd74hc138.pdf that we were recently talking about, it says in the absolute maximums that

Quote:

DC Input Diode Current, IIK
For VI < -0.5V or VI > VCC + 0.5V . . . . . . . . . . . . . .±20mA

That voltage is too small to be non-Shottky diodes (0.5V outside either rail), and if their maximum safe current is 20mA and the input capacitance is as low as it is, those things are tiny, all adding up to mean pretty darn fast.

[Arlet]

Also keep in mind that a bit of reflection and ringing isn't necessarily the end of the world. Data signals only need to have a valid level when they are sampled. The most important signal is the clock, and the easiest way to prevent problems is to make sure it doesn't have razor sharp edges due to very high drive strength. This won't be a problem with older logic families, and can be easily trimmed in newer devices by including a small series resistor on the output.

Let's also not forget that it's okay to make mistakes. Nothing teaches you more than making something that doesn't work, and figuring out why.

[lordbubsy]

Arlet wrote:

Let's also not forget that it's okay to make mistakes. Nothing teaches you more than making something that doesn't work, and figuring out why.

well, if someone tells me there is a brick wall right around the corner, I’ll not necessarily close my eyes just to find out for myself

Meanwhile I’ve read and learned a lot and thought some things over.
First of all I may be too eager making something touchable and I’m uncertain of some factors with the WDC design. Furthermore I’ve never made such a large PCB. I also have a very tight budget plus I want to include the SID. That’s why I chose an NMOS design.

On the other hand I want to create a computer with which concept I’m 100% satisfied. One of the factors would be to be able to run it at 8 MHz. For that it has to be a WDC CPU. Than I’d probably get the 65C816. Even if it means choosing the harder way. I have 128x8 KiB 55ns SRAM and 128x8 KiB 55ns Flash ROM which would be fast enough. As you noticed I insist on using at least one SID. The SID may be usable at 1 MHz. only, and may be disconnected from the bus at higher clock speed settings. I hope I can get all the AC logic parts I need, they have a limited selection. I am thinking of two VIA’s, one DUART (or two UART’s) and 65SPI as I/O.

I know I’m pretty inconstant, but I (uhm, we)’ll get there eventually...

Another attempt for a satisfying concept of my SBC design:

• POC1.1 / SBC-2 / SBC-3 as guideline and reference
• Whole system on one board
• 55ns SRAM and Flash memory
• 48k RAM and 16k ROM
• Using 65C816
• I’m considering page $BF for I/O rather than $FE. [???]
• Two VIA’s
• One via port could serve as a control register for system settings (speed / ROM-bank / writeprotect)
• AC logic
• SC26C92 DUART
• 6581 R4 AR SID
• Daryl’s 65SPI
• The rest of I/O will all be connected to the SPI ports
• Daryl’s Compact Flash SPI-IDE Interface including the DS1302 RTC
• Daryl’s PS/2 keyboard preferably through SPI
• Gameduino as VGA color graphics through SPI


IC’s:

Code: Select all

•	CPU	W65C816S PDIP-40 or PLCC-44
•	RAM	AS6C1008-55 Alliance Memory SRAM 128K x 8 55ns PDIP-32
•	ROM	AM 29F010-55 AMD Flash 128K x 8 55ns PLCC-32
•	I/O	2 x W65C22S VIA PDIP-40
•	UART	SC26C92 DUART PLCC-44
•	SPI	65SPI PLCC-44
•	GLUE	74ACxxx
•	RESET	MAX1232 / 705
•	RS232	MAX232 / 238

Memory map:

Code: Select all

0000-BFFF	RAM
C000-FFFF	ROM
BF00-BFFF	I/O
BF00-BF0F	VIA0
BF10-BF1F	VIA1
BF20-BF2F	DUART
BF30-BF33	65SPI
BF40-BF5C	SID

[Arlet]

For a design like that, I'd be very tempted to include a CPLD. It can probably do all your address decoding in a single chip, at the required speed. In addition, it will give you flexibility to update your address map, or fix errors without having to modify the board. Also, it can help interface slow devices such as the SID by adding some RDY cycles.

Of course, the downside is that you'll need a JTAG programming cable, and there's a learning curve.

[lordbubsy]

Arlet wrote:

For a design like that, I'd be very tempted to include a CPLD. It can probably do all your address decoding in a single chip, at the required speed. In addition, it will give you flexibility to update your address map, or fix errors without having to modify the board. Also, it can help interface slow devices such as the SID by adding some RDY cycles.

Of course, the downside is that you'll need a JTAG programming cable, and there's a learning curve.

as I learned by now, I don’t count out anything.
I’m building on this project:
http://www.ulrichradig.de/home/index.ph ... linx_cplds
for those who can’t read German, it’s obviously a programmer and a test board for the XC95xx 44-pin PLCC series. Which is the same as Daryl’s 65SPI. So I’ve made a start toward that.

At this point I’d like to thank Daryl Rictor for providing a great deal of material which will be included in my SBC! It would be very impolite not to, so thank you!

Edit, attached picture.

[lordbubsy]

I’d like to implement this memory map:

0000-BFFF RAM
C000-FFFF ROM
BF00-BFFF I/O

I’m not sure if this can be simplified?

I took over BDD’s address qualification. Is this only necessary for the I/O block?

[GARTHWILSON]

You have RAM from 0 to $BEFF (which is as it should be), not $BFFF, and I/O from $BF00 to $BFFF.

Eliminate IC3E. Otherwise, RAM and ROM can get selected at the same time.

I would replace IC2 and IC3E with a 74xx521 or '688 8-bit identity comparator.

For your VADR on the '138, you want VDA=1 and VPA=0 to select I/O, because I/O always looks like data, not instructions. Having them both high is for op code fetch, which is never from I/O. You could bring one in on G1 and the other on G2A, and get rid of IC4 completely. That will leave A7 out of the picture and give you a set of mirrored addresses, but it doesn't matter. You're throwing away $BE80-BEFF anyway, which is a pretty miniscule amount of memory-map space.

Now if you just had one extra NAND section to use to replace IC3D, you could also get rid of IC3. I would simplify it more and then you could indeed eliminate two whole ICs and keep the same memory map, but I know you're going with others' recommendations about OE and WE, even though I made a commercial product without them, for aircraft no less, and we sold that model for 13 years and it proved to be 100% reliable.

[lordbubsy]

I believe this is what you mean:

Looks a lot neater!

GARTHWILSON wrote:

you want VDA=1 and VPA=0 to select I/O, because I/O always looks like data, not instructions.

OK, now it makes sense to me.

Quote:

...others' recommendations about OE and WE,

on my breadboard I have it also wired with only two NAND’s, which works fine indeed. I just thought it would be better regarding the discussions...

I could use the 74AC00, 74HC138 and 74HC688. I hope they are fast enough for 8 MHz?





Next I’ve created a symbol for the 65816 and tried to connect it as far as I understood.

Would this be correct?
I'm not sure if I'll be using that reset IC though.

[8BIT]

lordbubsy wrote:

At this point I’d like to thank Daryl Rictor for providing a great deal of material which will be included in my SBC! It would be very impolite not to, so thank you!

It's always nice to get a thank you. You are welcome. I'm glad to see you are interested in my work. I shared it for just this reason. FYI - the SBC-3's ATmega8 was both an RS-232 port and a keyboard decoder connected via SPI.

Daryl

[BigDumbDinosaur]

lordbubsy wrote:

I took over BDD’s address qualification. Is this only necessary for the I/O block?

Address qualification needs to be applied to all cases, not just the I/O block. The reason has to do with how the 65C816 handles the data bus during Ø2 low, as well as the potential for false address bus states that may confuse some hardware (the 2692 is in that category). The data sheet alludes to this but doesn't really explain it well. In the following explanation, && means logical AND, || means logical OR and ! means logical NOT.

The general rule to follow with the '816 is that no RAM, ROM or I/O should access the data bus unless the expression Ø2 && (VDA || VPA) is true. If the condition is !Ø2 && (VDA || VPA) then the '816 is multiplexing the A16-A23 component of the effective address onto D0-D7, which constitutes a write operation by the '816, regardless of the state of RWB. Therefore, a chip's /OE or /WE (output-enable or write-enable) should not be asserted when Ø2 is low, as the bit pattern on D0-D7 would be A16-A23 at that time. If a chip's /OE is asserted at that time bus contention will occur. If /WE is asserted, the A16-A23 bit pattern will be written into the device. The lone exceptions to this rule are WDC's 65C21, 65C22 and 65C51, which are slaved to Ø2 and "know" what the bus states are during the instruction cycle.

As a general rule, note that no RAM, ROM or I/O should ever be selected unless VDA || VPA is true, as otherwise the address bus may be invalid. This applies to the WDC I/O devices, as well as others.

As Garth noted, you normally wouldn't expect the '816 to be fetching instructions from the I/O block. I don't make that distinction in POC V1.1, but it should be made to forestall accidental access to I/O device registers during an opcode fetch that is directed to the I/O block caused by an errant value in PC. Opcode fetch is indicated by the expression VDA && VPA being true. So if you want to be really careful with I/O device selection, only allow it when the expression VDA && !VPA is true.

To summarize, the possible states of VDA and VPA, and what they mean are as follows:

Code: Select all

VDA    VPA    Ø2
—————————————————————————————————————————————————————————
 0      0      X   buses are invalid
 1      0      0   data address setup: DB —> D0-D7
 X      1      0   instruction address setup: PB —> D0-D7
 1      0      1   data read/write
 0      1      1   operand read
 1      1      1   opcode read
—————————————————————————————————————————————————————————
X = don't care

In the above, DB refers to the data bank register and PB refers to the program bank register.

[GARTHWILSON]

Ah yes, a couple of my earlier comments were oriented toward the 6502, not the '816. My apologies.

Quote:

I could use the 74AC00, 74HC138 and 74HC688. I hope they are fast enough for 8 MHz?

Check the timing specifications in the data sheets, and use the worst-case numbers for at least 25°C, or, if you anticipate running in a wider temperature range, use the worst-case numbers for that, whether -40° to +85°C or whatever they tell you. I half expect you'll find that cascading MSI logic, you'll need 74AC to reach 8MHz.

[BigDumbDinosaur]

GARTHWILSON wrote:

Ah yes, a couple of my earlier comments were oriented toward the 6502, not the '816. My apologies.

Quote:

I could use the 74AC00, 74HC138 and 74HC688. I hope they are fast enough for 8 MHz?

Check the timing specifications in the data sheets, and use the worst-case numbers for at least 25°C, or, if you anticipate running in a wider temperature range, use the worst-case numbers for that, whether -40° to +85°C or whatever they tell you. I half expect you'll find that cascading MSI logic, you'll need 74AC to reach 8MHz.

The 74HC138 is available in AC logic. The 74HC688 doesn't appear to be available in faster logic. An alternative to the '688 would be to synthesize one in a 20V8 GAL. The logic isn't very complicated and most GALs have 10ns or less pin-to-pin prop time.

[GARTHWILSON]

BigDumbDinosaur wrote:

The 74HC138 is available in AC logic. The 74HC688 doesn't appear to be available in faster logic. An alternative to the '688 would be to synthesize one in a 20V8 GAL. The logic isn't very complicated and most GALs have 10ns or less pin-to-pin prop time.

I have 10 74AC521's here but I don't remember where I bought them, so I looked at the usual distributors and they didn't have them anymore! Darn! It wasn't very long ago that I got them. The '521 is the same thing as the '688, so you can search for both.

[lordbubsy]

BigDumbDinosaur wrote:

/OE or /WE (output-enable or write-enable) should not be asserted when Ø2 is low

OK, than I can change it back to the previous version to prevent access whenever PHI2=0.


• no RAM, ROM or I/O should access the data bus unless the expression Ø2 && (VDA || VPA) is true
• /OE or /WE (output-enable or write-enable) should not be asserted when Ø2 is low
• no RAM, ROM or I/O should ever be selected unless VDA || VPA is true
• careful I/O device selection, only allow it when the expression VDA && !VPA is true

Code: Select all

VDA    VPA    Ø2
—————————————————————————————————————————————————————————
a 0      0      X   buses are invalid
b 1      0      0   data address setup: DB —> D0-D7
c X      1      0   instruction address setup: PB —> D0-D7
d 1      0      1   data read/write
e 0      1      1   operand read
f 1      1      1   opcode read
—————————————————————————————————————————————————————————
X = don't care

So I/O selection applies to d. I named it VAIO (= VDA && !VPA)
(For simplification I could use VDA || VPA as you did on POC1.1.)

However, for accessing RAM, it could be data, an operand or an opcode. That applies to d, e and f.
In that case the expression VDA || VPA must be true? And can be connected to CS2 of the RAM. I named that VAMEM (= VDA || VPA)

I haven’t done any simplification yet.

Since my ROM is actually Flash memory, and has no second Chip Select, I need to include VAMEM into /ROM-CS. Right?

[BigEd]

We have debated VPA and VDA before: while BDD holds his line, an alternate and reasonable view is that you don't normally need to use them. BDD got burnt once with an unusual situation, and has taken a very conservative line. That's fine, if it's known to be a very conservative line.

You very probably don't need them, so if it makes your design more difficult, know that there's two ways to do it!

Specifically, if an unwanted read can never cause trouble, or if you never access addresses near I/O devices using indexed addressing, you'll be fine.

cheers
Ed