I've been working on putting together Blue August's I/O board. I actually finished the first construction stages a week or so ago, but then I had to leave town and didn't get a chance to do much testing. I haven't hooked up the serial port or keyboard circuit yet; I thought a good first step would be to get the VIAs working. After some fussing with the glue logic the VIAs are working at 16MHz. The ALS520/521s are a bit slower than I'd hoped; the board only runs at 15MHz using them. But, after adding a bank of 1k pull-up resistors and switching out the ALS520 for an F521 I have working I/O ports.

I think I must be cutting it pretty fine in terms of VIA_CS timing, so I'm not sure how much margin I have for operating conditions. It's about 70ºF in my workshop. Maybe at some point I'll fire a hair-dryer at the board and see how long it takes before it starts crashing!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Do I see correctly that your VIA's are on a separate board connected with ribbon cables?

I am by no means an expert in going fast, but I figure that having something like that would increase noise or ringing? Even short cables can do that. [ Well, all cables/traces can do that I guess. ]

Was your goal to run the VIA's at that speed too? It's neat to see of course!

Maybe I missed it, but what is the "ALS520" vs. "F521"? Is this what you mean? (https://media.digikey.com/pdf/Data%20Sh ... 20,521.pdf)

Glad to see you are still working on this, good outcomes!

Chad

Hi Chad!

That's correct. The ACIA is on there too, but it's not doing anything yet.

Not very much. I think this is partly because the kynar wire-wrap wire has such low impedance that you can basically ignore it, and partly because I have a robust ground return network. The ribbon cables are 20-wire cables, but only carry 10 signal wires. The other 10 wires are all GND return wires, so every signal wire is next to at least one (and usually two) ground wires, as recommended by the Primer. Unless a single run of wire starts getting into antenna territory (8 inches or so, IIRC) there's not much to worry about. There are a few places where I hit ~6 inches for individual wires that I was worried might cause some, but they all look OK on the scope.

Edit: Just to say that, if those long wires *had* been problematic, it's not too difficult to twist a ground wire along with the signal wire, which will usually clear things up. This is what I do with long wires on breadboards to get long-distance signal integrity.

Yep, that was the whole point of the design: to run the VIAs off of the constant clock (at RAM speed) so that their timers aren't messed up when the CPU slows down for slow I/O (ROM, ACIA).

Yeah, except mine are TI parts. The first versions of this design (Peanutbutter-1, earlier Blue August tries) used HC688 for I/O decoding, which is far too slow for any kind of overclocking. The ALS520 has internal pullup resistors, which I thought might save me some soldering, but was also slightly too slow, so I ended up with an SN74F521.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Nice, very tidy looking boards too! Are the empty sockets related to the missing keyboard circuit, or something else?

Thanks George! The 3 empty sockets on the top left are for the keyboard circuit: two `595 shift registers and a `14 hex inverter. The 2 empty sockets on the right are for a MAX232 and baud-rate generator oscillator can. The single already-populated socket on the right is an HC11 3-input AND gate that is managing IRQ\ sources.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Yes. It is THE Primer indeed Nowhere else have I seen such a detailed explanation than on Garth's Primer.

Cool! Glad everything is working so well. It'll be exciting to see what you can do with all these new capabilities on the new board!

Chad

Continuing on with adding well tested and understood functionality from previous projects, I've adjusted PAGIMON to run on Blue August, and attached an LCD to the general I/O pins (Port A of VIA2). Encouragingly, it started right up first try! This makes Blue August interactive (or, it will do as soon as I cobble together a keyboard adapter) which will give me much more freedom in testing and troubleshooting future additions.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

I love it when old code works right off without much modification. That's good news!

So if you are 'cobbling' things together, eventually you'll also add in your video circuitry, right?

Chad

Yep! That will require a whole 3rd story board.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Three storeys? You'll need planning permission for that, then

Another mini-update! I finished up the keyboard circuit yesterday and today. The hardware worked fine immediately, but it took me a while to realize that the reason I wasn't reading any key-presses is that when I updated the firmware addresses for VIA #1 in my code I changed all of the Fs to 9s, instead of changing all of the As to 9s! ($7FA0 -> $7F90, not $79A0). Oops.

Sadly, as I've added functionality to the I/O board, I've come across some timing glitches and have had to slow down to 12.6MHz. The system doesn't crash at higher speeds (the main board still runs at 16MHz just fine all on its own), but I get some display errors. For example, I have a little test editor program that lets you type around on the LCD screen. It displays a message "Welcome to TE!" when you jump to it. At faster speeds the message isn't reliably displayed. Sometimes I get "lcome to TE!" or "e lcome to TE!" and so on. I'm not sure if this is the VIA occasionally not being selected by the rising edge of Ø2 and therefore just missing out on a character write, or if it's an LCD communication error. I'm inclined to think the first one, but I haven't investigated too closely yet. It definitely seems like a marginal timing issue.... some days it works better than others!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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

Is the start up delay on the LCD set in software, and if so, does the software know how fast it's running? It the initial pause on many LCD chipsets is insufficient, weird stuff happens...

Neil

It does; but the VIAs run off of the fast clock. (That was the initial point of Jeff's clock stretcher, after all - to let the VIAs run at a constant fast clock so their timers are not interfered with, while the CPU slows down for slow I/O).

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Yes, and sort of. I tuned the delay loop to be 1ms at 1MHz. You pass the number of ms you want to delay to the delay subroutine when you call it, and it will run the loop that many times. Then I defined a constant that is set to the system clock speed, so at higher frequencies the routine repeats the 1MHz delay more times. There's a little bit of overhead from the extra loop so that, e.g., at 16MHz a 100ms delay lasts just a bit longer than 100ms compared with running at 1MHz when the 100ms delay is fairly precise. But in no case is the delay *too short,* since the LCD data sheet says "wait at least X microseconds."

_________________
"The key is not to let the hardware sense any fear." - Radical Brad