One more question. (doing a legit schematic seems to be exposing these )

I'm using the address decoding in Garth's primer that is for 16k RAM, and 32k ROM, using a single quad NAND.

Looking closely at it, I see something I'd like to confirm. The /OE pin of the RAM chip is tied to A14. So any address that puts that pin HIGH won't allow reads from RAM. As expected.

But if I read this correctly, there is nothing in hardware stopping one from WRITING to addresses that pull that pin HIGH, correct? In other words, I could create a software bug that, in attempting to write to I/O, could corrupt RAM.

Am I reading this right?

If you corrupt write-only memory, and no one is there to read it, does it make a sound?

Meh, I think I got that quote slightly wrong, but it fit better than asking if a bear was Catholic or something ...

Mike B.

???

Is a bear Catholic? Does the Pope crap in the woods?

Is my assumption correct?

Connect Ø2 on the UART directly to the oscillator. You may want to refer to WDC's statement concerning clock signals on page 10 of the W65C02S data sheet. Here is the relevant excerpt:

An external oscillator is recommended for driving PHI2 and used for the main system clock. All production test timing is based on PHI2. PHI2O and PHI1O were used in older systems for system timing and internal oscillators when an external crystal was used.

Further on on page 26 in the data sheet, there is this:

Timing Notes:


1. Timing measurement points are 50% VDD.
   
2. PHI1O and PHI2O clock delay from PHI2 is no longer specified or tested and WDC recommends using an oscillator for
   system time base and PHI2 processor input clock.

I cannot overstress the importance of reading everything in the data sheet, including those notes in small type below the timing diagram.


It depends on which 65C22 you have. The W65C22N has an open-drain IRQ output, so it will work in a wired-OR circuit. The WC65C22S has a totem-pole IRQ output that positively drives in both directions. It cannot be directly connected to a wired-OR circuit and instead must be isolated with a Schottky diode or all IRQ sources have to be wired to the inputs of an AND gate, with the output of the gate driving IRQB on the MPU. With a single W65C22S, the diode is a suitable approach.

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

designing my PCB, and I have an observation:

The address pins on memory chips must have been laid out by evil folk indeed. So random!

That is all.

Try to remember that SRAMs don't care how you scramble the address lines (or the data lines!) to make your interconnections as easy as possible to route. As long as every address (and every data bit) is unique, it doesn't matter if you hook SRAM's A0 to CPU's A9 and SRAM's D5 to CPU's D3, as long as you get them all connected ... ROMs are a slightly pickier matter, of course.

Mike B.

There is slight differences on the power dissipated when
randomly addressing most RAMs. The lowest power is
when addressed with a grey code.
As for ROM's, it depends on if the ROM was programmed to
have the lines swapped around.
On my 6530 to 6532 adapter, I swap data and address lines on
the 28C64 for routing convenience. If I were using a programmer
to initialize them it would be an added pain but a relatively easy
translation to code.
Since I program it in place, it doesn't make much difference. in
that sense it is like RAM.
Things like the data lines and address to the I/O functions and timers, on
the 6532 need to be correct.
As for using A14 to /OE, as long as /CE is not selected, /OE has no effect.
For writing, it means writing has to be done at the high address to
avoid periods of bus contention when /WR is not low, which will be for
parts of the cycle.
It may not be an issue if the writes are /CE driven. I'm not sure how
/OE and /WR interact on all RAM chips.
Dwight

I'll bite. What's a "grey code"?

https://en.wikipedia.org/wiki/Gray_code
It's where only one bit at a time changes as you advance in values (in this case, addresses).

_________________
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?

Ah interesting, thanks. I had never heard the term before.

Laying out my PCB.

I want to keep the option open of etching my own. I've done 8 mil track/ 8 mil clearance before at home with success, just not this much complexity. Anyway, I enjoy doing it and know I can. I know the gut response to DIY PCBs here is often "don't", but I know the difficulties involved, and am comfortable with them. No need to give me the "don't speech.

Ok, so I'm laying the thing out as if I'm doing it myself, but I'd say its 50-50 right now if I'll have it made.

My question is, how big a sin is it considered to have vias under chip sockets? I've heard it said that it is bad practice, but It would help so much!

I'm aiming for having horizontal tracks on the back, and vertical on the front. I like the look, and I like the way it can simplify some sticky routing situations.

Problem is, to do this, it seems that vias under sockets are needed. in fact, it seems to necessitate allot of vias in general. I feel if I have the thing mad professionally, vias under chips is not a big deal. If I do it myself, it just means they need to be reliable if I can't access them after the fact. Again, I think I can get them good enough, buts another variable.

I've looked at some 6502 single board stuff from folks here, and still am.

Also, I plan to have a connector for each bus on one side so I can add UARTS, VIAs, ect. I have pin headers, but some sort of edge connector kinda thing (think PCI slot sort of thing), but don't know what exactly to search for.

BTW, Darryl's SBC2 is exactly in the realm I want to do. He seems to have vias under the chips. I think that layout is beautiful actually.

It's no problem at all. What you probably heard is to not put vias in SMT pads. The reason is that in automated assembly, the solderpaste gets silkscreened on, and if there's a hole, a whole bunch of paste shoots through the hole and makes a mess on the other side. If you're assembling by hand and not silkscreening solderpaste, you can put vias in pads if you like. Actually, there is a way they can make boards with vias in the SMT pads suitable for automated assembly. After the via is made and thru-plated, they put a plug in it that's a little bit shorter than the hole, then put a plating over it so you can't even see the via.


If you really must do that, at least distribute your ground and bypassed power connections so no signal pin is more than some distance from one, say .300". It used to be common to bunch all the power and ground connections at one end; but that was back when parts were slower. With the faster parts we have today, it causes AC performance problems.

_________________
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?

As Garth noted, it's not a sin at all. I have plenty of via under sockets and even in SMT pads (at one end of the pad, not in the middle) without ever having run into problems. Only difference is I have my boards made, so that does eliminate an element of risk that you may encounter with a homemade board.


Vertical on top, horizontal on bottom is how I do it as well. Things just seem to come together better with that pattern.


Bringing out the MPU's buses onto connectors is something we routinely discourage. Several issues can arise that will either limit performance or cause instability. If you are going to do this you might want to consider the use of bus drivers to strengthen the signals, 74AC541 for the address bus (two required) and 74AC245 for the data bus. You'll also need to give some consideration to how you will wire up the interrupt circuit (all the while avoiding spurious interrupt problems), and in the case of the 65C22, arrange for Ø2 and RWB to be brought out to it. Of course, chip selects have to be brought out to the sockets as well.

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