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

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

I put them in there not because I thought the '816 couldn't adequately drive the buses but instead to get a feel for how they will work on a more complex system where there's a lot of memory and other hardware (hence a lot more loading). Remember, this is a "proof of concept" design.


It does? According to the 74AC138 data sheet, prop time from any input to any output will not exceed 10ns at 5 volts. Perhaps you're thinking of the 'LS version, whose performance is up around the 40ns range? All gates are 'AC logic and in the case of the 'AC04 inverters, you're looking at less than 6ns prop time.

In any case, I did see where I could remove one gate from the 'AC138 select circuitry. As a result, the delay to enable an I/O chip select is now equal to that of the 'AC20 quad NAND plus the 'AC138 itself. That works out to around 16-18ns on average. Assuming an 8 MHz Ø2 clock, that should be well within allowable timing limts.

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

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

I had figured propagation time to select an I/O device as follows, based on an 8 MHz Ø2 clock (125ns cycle time) and disregarding the prop times of the address and data bus drivers—I'll get back to that in a minute:

1) Ø2 goes low. At tADS (in this case, approximately 40ns following Ø2 low) the MPU asserts the address bus. The 40ns time is pessimistic, since that number is based upon the data sheet specs for an 8 MHz clock with Vcc=3. In reality, CMOS logic tends to run faster with higher voltages, which would in practice reduce tADS to some degree.

2) Approximately 51ns following Ø2 low, U9 (74AC20) will have reacted to the address bus and will have driven /E1 low on the 74AC138. /E2 on the 'AC138 will have already been driven low by A13 at the end of tADS (A13 is low if the address is in the range $D000-$DFFF). Therefore, after tADS+tIPHL (the latter the 'AC20 input delay), the 'AC138 will have been selected. tIPHL for the 'AC20 is 11ns worst case. Hence the worst-case delay from the time Ø2 goes low until the 'AC138 has been selected will be 51ns.

3) Worst-case prop time for the 'AC138 following assertion of /E1 is 9ns—A0-A2 on the 'AC138 will already be valid, since they were valid at tADS. Hence, the relevant I/O chip select will be asserted no more than 60ns after the fall of Ø2. The slowest device on the board, the dual ACIA, will be ready to read/write approximately 25ns after the rise of Ø2. So, at least on paper, it should work at 8 MHz.

If you think about it, the prop times on the bus drivers don't matter, since they are symmetric to the rise and fall of the clock. Everything sees the same prop time through the 'ABT245 and 'ABT541. Also the read/write line is qualified by Ø2, which itself is subject to a small delay going through U3 and U5. However, I did make some parts that could be plugged in place of the line drivers so A0-A15 and D0-D7 are directly coupled to the MPU. I suspect, however, I won't see anything of note.

One thing I have concluded from my timing analysis is that it would be difficult to take advantage of the MUxed A16-A23 address at higher clock rates. With a quoted 30ns tADS at 14 MHz, I'm hard pressed to see how discrete silicon could react quickly enough to make A16-A23 valid before the rise of Ø2. Even then, only really fast SRAM could respond to the tiny bit of address setup time that would be created before Ø2 high. At 20 MHz, I'm of the opinion that it can't be done except by using a PLD with a single digit prop time. It's probably safe to say that the circuit illustrated in the '816 data sheet is mostly wishful thinking.

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

Here's my theory. The datasheet calls for a transparent latch 74x373/573. With PHI2 low, the high byte address outputs (A16-23) follow the data bus inputs with little delay, and well before the rising edge of PHI2. When PHI2 goes high, the values are latched.

My SBC-3 runs at 8MHz and uses a 15ns CPLD and 12ns SRAM. I have the logic programmed as a transparent latch and it runs well.

Now, I have not tried to run it up faster. Purhaps I'll experiment with that when I get some time. I think I have a 14 MHz oscillator floating around somewhere. That gives me about 35ns of PHI2 low time.

Got a busy week planned... will try this weekend.

Daryl

Assuming a clock speed of 14 MHz, the timing diagram says that the A16-A23 address is present on D0-D7 about 30ns after the fall of Ø2. The address persists for about 5ns after the rise of Ø2, after which D0-D7 is momentarily invalid and then becomes valid with data.

Now, at 14 MHz, Ø2 is low for only 35ns, which means A16-A23 has to be latched in a very small time, basically less than 10ns. A 74ABT573 can barely react in that time. I say it can't be reliably done with discrete silicon.



My guess is the CPLD won't be fast enough to support anything much over 10 MHz. You are still banging up against the very small time that the A16-A23 address is present on D0-D7. Even if the CPLD could get it onto the corresponding address lines on the SRAM, the latter would have scant time to get set up for access. BTW, a 15ns CPLD is actually fairly slow by today's standards. For example, an Xilinx XC9500 CPLD, which is considered already dated technology, has a claimed propagation time of 5ns pin-to-pin. That probably would be fast enough to handle the A16-A23 address latch with the '816 running at full throttle.

However, I think the MPU's design is the real bogeyman here, in that the time required for A0-A23 to become stable after the fall of Ø2 is really too long relative to the length of the clock phase and can't reliably support the MPU running at its maximum speed. From my perspective, it borders on an outright design defect—the bank address setup time is too short to be workable at elevated speeds. For that reason (and others), my more ambitious computer design will not use the A16-A23 MUXing feature and will instead use other methods to manage a large amount of RAM.

My thinking revolves around the fact that the '816 is incapable of true linear addressing—wrapping the program counter doesn't autoincrement the A16-A23 address. Therefor the MPU really has a segmented memory scheme, despite the fact that it is possible to span banks to some extent with the 16 bit index registers. This isn't as bad as one might think, as a true multitasking operating system could use such an arrangement to produce a form of automatic memory protection (as well as use the /ABORT line to trap illegal memory accesses). The logic would be too complicated to implement with discrete gates but shouldn't be too tough with a CPLD or FPGA.

Accordingly, I concocted a scheme more or less like the following for my "high-powered" '816 computer, should I be sufficiently motivated to design and build it:

Only RAM segment $00 or code running in common RAM would have unrestricted read/write access to anything above $00BFFF. The ability of other processes to access that area would be contingent on whether code in segment $00 or common RAM allows such access. That, combined with logic to assert /ABORT if such an unauthorized access is attempted, would produce the hardware memory protection needed to allow multitasking without the danger of a wild process trashing the OS or other processes.

Obviously, this will not be a trivial system to implement, but given the capabilities of today's PLDs, shouldn't be impossible. Thinking about it will give me something to stay occupied with as Father Time slowly turns me into an old codger (which my wife thinks has already happened).

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

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

I have no plans to use the VIAs or other 65xx I/O devices, so the timing "glitches" that have seemed to dog 65xx hardware since day one won't get into the picture. Actually, with what I have planned, the 6522 would be of no particular value.


The problem, of course, with using the '573 to latch A16-A23 it that the BA7-BA7 value MUXed on the data bus vanishes too soon after the rise of Ø2. From what I've worked out, the '573 wouldn't have latched by the time the bank address on D0-D7 becomes invalid. As I said, I don't think it can be done in discrete silicon. It would take a very fast PLD.


It's a lot of silicon to use to solve a single design problem. I see the '816 being of value for its 16 bit wide registers, extended instruction set and hardware features like /ABORT and a properly functioning /RDY. I don't see the segmented 24 bit memory addressing as a workable scheme.


I have a function generator that produces a clean square wave out to 40 MHz. However, in this first design, I will socket the oscillator thet is responsible for the generation of Ø2. I've got a number of these oscillators around, so I can bump the clock in increments of 2 MHz to see how fast it will go.

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

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

This depends on many things. The CMD SuperCPU for the Commodore 64 and 128 ran the 65C816 at 20MHz and used an FPGA. Many CPLDs are at least as fast as an FPGA, often faster due to the shorter internal wire lengths for comparably complex logic formulae.



Interesting -- one of my longer-term plans was to explore implementing an external MMU for the CPU (employing paging with support for virtual memory), both multi-address and single-address-space variants, and explore the differences and opportunities between them.

Although I assume you know about my 6502 with MMU.. I just couldn't resist :-)

64k CPU address space divided into 4k blocks, each selectable from 1MByte physical memory. Even including no-execute, write-protect, and illegal address (i.e. not mapped) bits per page.
And an operating system using the virtual memory to support memory separation between processes...

http://www.6502.org/users/andre/csa/index.html

André

Which issues would you find by using that approach? I have that approach on paper using a 374 latch for a higher address bank and allocating a variable to monitor the status of that extra byte. Am interested in knowing your thoughts on that bugger....

_________________
"My biggest dream in life? Building black plywood Habitrails"

That, and the annoying implementation of the IRQ. I won't even mention the equally annoying R/W timing issue. I've never liked the 6522 and see it as a throwback to the bad old days of the Commodore VIC-20 and its royally screwed-up architecture. You notice the 6522 was not used in any Commodore 8 bit machine after the VIC-20. Even the much-maligned Plus-4 doorstop didn't use that crappy piece of silicon.

Anything I might do with a homebrew design I can just as easily implement with other, more modern silicon. Now, if WDC were to develop a high speed CMOS analog to the old MOS Technology 6526 CIA found in the C64, C128, etc., I'd consider it. The 6526 is what the 6522 should have been, especially with its much saner IRQ setup, better timer arrangement, and AC-driven TOD clock. That said, the Dallas 1511 RTC has what I need in a timekeeper (plus 256 bytes of NVRAM) and has a straight-forward bus interface and IRQ arrangement.


Garth, it's a "proof of concept" unit, and is not intended to be a "practical" design. It has enough I/O for me to drive a terminal plus exchange bytes with another machine. I will use it to develop a ROM BIOS, which will become the basis for a more ambitious design with more I/O capability (possibly including SCSI—SCSI and I are old friends dating back to when it was known as SASI).

BTW, the 2692 DUART can run up to 115.2 Kbps CBAT simultaneously on both ports, and has numerous programmable I/O pins that I'm not using (two each are used to implement CTS/RTS on the two serial ports). Also, I can add more serial ports in the future with one or more SCC2698 octarts—that's eight ACIAs in a PLCC84 package. No more logic is required to select one of the eight ACIAs than is needed to work with the 2692.

Also in the back of my mind while I was designing this thing was the desire to keep the board size at or below the 21 square inch limit of ExpressPCB's ProtoPro product. Adding more I/O would have used more board real estate, and staying under 21 square inches would have been difficult to achieve. As it is, I created an alternate design in which the bus drivers are absent, further reducing the board size. I may build both for comparison purposes. What the hell, it's only money.


That's because I decided to extend the RAM address space up to $CFFF. If I had used the simpler method of mapping SRAM in and out with A15 alone I would have been able to eliminate some logic. Also, you should note I more thoroughly qualified R/W to the SRAM to avoid any possibility of a timing glitch during write ops. Both the DUART and RTC have /CE, /OE and /WE inputs, which demand more qualification than can be gotten with a simple two-state read/write line.

The amount of glue logic isn't really a liability in this design. The next version will definitely use a PLD and do away with the discrete gates.


Back in the early 1990s I wrote code to run on an SBC powered by a 65C02, with up to 8 megs of RAM (on 30 pin SIMMs), a 2698 octart and a GAL to handle the logic. The memory map was as follows:



I was told the above map was the best that could be done with the available GALs of the time. Basically, it came down to not having enough I/Os on the GAL to map anything more ambitious.

The thing ran on an 8 MHZ clock and due to memory mapping being controlled by a single register in the GAL, a context switch was accomplished with a simple STA instruction, taking only a few clock cycles to complete.


Unfortunately, the computer press at large continues to treat Microsoft as though they invented the computer, just as Al Gore supposedly invented the Internet. In the words of an author who wrote a scathing piece on the way the press treats Barack Obama, it's a "slobbering love affair."


I've extensively perused your website. You obviously have more than a little experience with UNIX-like operating systems. Now if I could only get your assembler to generate an output listing...

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

So far, I've found the 6522 quite pleasant to work with. That being said, I have spent many hours of my youth interfacing to the world with the 6526A and 8520A chips. I miss them dearly.

Still, I'd be interested in hearing your critique of the 6522 relative to the 6526.



I want to emphasize here, to everyone concerned, that one should never under-estimate what you can do with a single piece of copper wire.

By multiplexing a single copper wire using protocols, from something as simple as ATM cell relay to something as complex as HDLC-derived protocols, you not only can control a single terminal, but you can control the world. Indeed, the very Internet we're using to communicate is fundamentally predicated on this idea.



An interesting idea here is to perhaps "bond" the multiple ACIAs into a single logical connection, thus providing greater throughput over your link. Though, presumably, if you're going to consider that as a solution, you probably would be better served by using an FPGA with a bus interface not unlike your DUART selection, but managing communications at a much faster bit-rate.



Actually, this rumor that Gore "invented" the Internet, or that he claimed as such, is demonstrably false. The transcript of his speech shows that he supported or authored the legislation which "enabled" the growth of the Internet industry, which history shows he did.

The popular press, dominated as they are by right-wing interests, coined the phrase we all know and love to make fun of Gore for today.

There are plenty of other things to poke fun at Gore for legitimately -- this isn't one of them.