>Many of his points seem to miss some of the key ideas about it being made from parts >easily obtainable by anyone and geared towards beginners as well as more advanced >users.
I agree Mike.
>I have noted that you are using what looks like a pair of 2x20 IDC headers for possible >board interconnection. Perhaps it might be easier to manage this with a single DIN41612 >(e.g. VME) 96-pin connector. These are inexpensive and ubiquitous,
I would say that a VME connector is not nearly as cheap and easy to find as a Berg type (which I guess is the same as what he calls "IDC").
>It puzzles me that you're using the 6522 on the board. This circuit is almost useful, but >seldom fully so. In dozens of 6502 applications that I turned out in the '70's and '80's, I
>found the 6522 seldom offered an advantage over logic which was smaller, cheaper, and >faster, [ snip ]
I'm sure it's not bug-free, but it does several useful things.
Also, it's a "65xx"-series part, which has some appeal for me, whether it works very well or not. If the goal was to make something that was 100% 'practical', then we should just buy an off-the-shelf CPU card with a more modern CPU and all the goodies built-in (like one of the many 68HC11 boards, for example).
>Is there an objective specification for this board, i.e. a spec indicating what its purpose is >intended to be?
No. If there was, then most of the basic design criteria are automatically 'wrong'. Again, the point (I think) is "6502", not "best design". Our criteria for low chip count, low cost, etc., *are* valid in any case.
The spec could be summarized as "simple, low-cost, 6502" - that's it.
>Why was it decided that bus drivers were not needed? If a cable is to be attached to the >board, that represents significant capacitance. What's supposed to drive that capacitance?
Getting too 'practical' again. I believe that for *most* apps that this board will be used for, 1 Mhz is fine. At that speed, the bus can be (probably) a foot or two without doing anything special. Some (perhaps "many") apps will not use the expansion connector at all.
>I notice there's no Phase-1 or Phase-0 clock, nor is there a RDY signal on the "bus" >you've tentatively designed. I guess this means that you can't run your CPU any faster >than the slowest device on the bus. Since performance is of no concern, why use the >16C550?
As we've discussed before (Mike and I), I tend to agree with him here - the 16550 is perhaps overkill. *But*, if we can't get our hands on 6551's faster than 2 Mhz (I think it's iffy at best, without doing a bulk order from WDC), then the 16550 still makes sense.
>In place of two 32Kx8 SRAMS, have you considered a single 64Kx8?
Unless I'm mistaken, we were only considering *one* 32K X 8, not two. Also, total RAM must be less than 64K, to leave room for PROM and I/O. On a board of this scale, with the likely apps for it, the difference between 32K of RAM and (say) 56K is minor.
>Just to be safe, I'd suggest you consider timing the read and write operations from the >CPU circuit rather than having the I/O circuits do it at each locale.
I think he's misinterpreted something here. If we generate what I'm calling RAM-R/W, OE (inverted R/W), and Chip Selects on-board, then no other logic is needed for most I/O and memory devices.
>If you put a set of more pragmatic strobes out on your
>bus, i.e. MemRd, MemWr, IORd, and IOWr, more peripherals become available, and it's >possible to time them such that all the strobes are comfortably provided with the desired >margins.
I think these are high-end considerations that don't really concern us. And, it sounds suspiciously like an x86 design (we should probably ban him from the group for that
).
>[snip] Many classic peripherals can't do without this data hold time.
I don't see what peripherals he's talking about here - we're not going to be plugging disk drives and things directly to our CPU bus...
>One of the silliest things that makers of the '70's vintage 6502 application boards, e.g. >KIM, SYM, AIM, etc, did was to use address lines as part of the decoding scheme for >their LSI's, e.g. 6530, 6522, etc. This chopped up the memory map, and while they, >probably correctly, assumed that no one would ever really need more than 1K of RAM >space, but the stupid decoding made that a self-fulfilling prophecy. If you simply use an >I/O input to your CPU circuit, the fact that valid addresses significantly preceed the rising >edge of phase-0 will allow the presence of a peripheral to make itself observable by its >assertion of that signal, thereby causing the CPU circuitry to produce IORd instead of >MEMRd.
I don't really follow the relevance of what he's suggesting here. It sounds like he's wanting to convert a memory-mapped-I/O architecture to the x86 style.
And, some of his statements in the above paragraph sound "just plain wrong" to me.
Pete