backspace119 wrote:
After studying the circuit in the docs, I've been looking at these two parts
here and
hereOne's an AHCT 245 and the other is a ACT 573 (non inverting).
A minor correction on what DerTrueForce said. If you use Garth's SIMM you will be working with SRAM that generates TTL-level outputs. Therefore, your bus driver should be a 74ACT245 or 74AHCT245 (note that the 74ACT245 is slightly faster than the AHCT equivalent, which isn't necessarily a good thing). The bank bits latch should be a 74AC573, as TTL-compatible inputs are neither necessary or desirable.
Quote:
I'm working out the logic on it right now, I think I need the non inverting 573, but there's an inverting one too, so I'm working on figuring that part out since it doesn't mention it in the docs.
You're thinking of the 74AC563, whose Qs are the complements of the matching Ds.
Quote:
Is there another part to this equation to make sure there's not bus contention?
If you correctly generate your /OE and /WE signals you should not see bus contention. Here's an example of a circuit for generating said signals.
Attachment:
File comment: Read/Write Generator Circuit
read_write_qualify_alt.gif [ 46.98 KiB | Viewed 754 times ]
The above circuit is what I use in my POC units. /OE and /WD cannot go low until after the rise of Ø2 (PHI2), at which time the '816 will cease driving bank bits onto D0-D7 and will switch to data mode. The prop delay in the above logic, added to the time required for the addressed device to respond to /OE or /WE will give the '816 some turn-around headroom. Understand that the state of RWB will have been set by the MPU before Ø2 goes high, so the time from the rise of Ø2 to when /OE or /WE will be driven low will be the prop time of the 74AC00, typically around 4-5 nanoseconds on 5 volts. If you want to increase that lag you could use the 74HC00, whose
tPD averages around 8-9 ns on 5 volts. Incidentally, it may come as a surprise to learn that the timing of /OE and /WE is not critical. As long as these signals are generated soon enough to meet the requirements of the slowest device at the highest Ø2 rate you plan to use it will all work.
Incidentally, if you use any 65xx I/O silicon, such as the 65C22, be aware that all control inputs must be set up before the rise of Ø2. These devices "understand" the 6502 bus cycle and will not attempt to get on the data bus while Ø2 is low. If you don't observe this requirement the device will not work.
Lastly, be aware of the 65C816's VDA and VPA outputs. At certain times during an instruction cycle the address bus could be in an indeterminate state. In some cases, that can result in improper selection and addressing of devices, which may cause some devices to malfunction. The NXP 26, 26C and 28L (mentioned below) series of UARTs is are such examples, the NCR/AMD/Buslogic 53CF94 SCSI controller is another one...
The general rule is if the expression
VDA || VPA is false (
|| meaning logical
OR) the address bus may be in an indeterminate state and no chip selects should be generated. This can happen during Ø2 high and may result in the '816 "touching" something it shouldn't.
<Cue a comment from Ed about VDA and VPA not being necessary.
>Quote:
I definitely want some io, planning on an acia...
DerTrueForce wrote:
On the ACIA you mentioned, I really wouldn't use that part...More info here:
WDC 65C51 chips defective and here:
UARTs: REPLACING THE 65C51.
I also recommend you stay away from the 65C51. Aside from it basically being a primitive 1970s vintage UART, it has a pernicious (in the archaic sense) hardware bug that prevents the use of PIO or IRQ-driven transmission. It's quite clear from recent revisions to the 65C51 data sheet that WDC has no plans to fix this part. If you use something like an NXP 28L92, as DerTrueForce suggested, you will get two high speed TIA-232 channels in one package, plus some programmable input and output pins, and as a bonus, a precision counter/timer (C/T) that has sub-microsecond resolution. My POC V1.1 unit uses the 28L92's C/T to generate a 100 Hz jiffy IRQ that ultimately is the time base for a software uptime counter, software time-of-day "register" and a software delay timer function. See the below attached on how to interface the 28L92 to your 65C816 system.
Attachment:
File comment: NXP 28L92 interfacing How-To
28l92_interfacing.pdf [381.39 KiB]
Downloaded 62 times
The problem with using a VIA timer for system timekeeping is said timer is usually slaved to the Ø2 clock and therefore will change speed if the Ø2 rate is also changed. That would mean you'd have to make changes to your timekeeping code in order to maintain accuracy should you decide to change the Ø2 rate. That won't be the case with using the 28L92's C/T, as it can be driven by the 3.6864 MHz X1 clock used by the 'L92 to generate bit rates.