Did a little poking just now. Here's channel one triggering on the VIA's chip select going low (top), compared with the 16MHz clock (bottom) at .01µs per division: I'd say that's cutting pretty close to the edge of reason!

Interestingly, with the probe attached to the clock pin on the VIA, all the problems seem to disappear. I wonder if a series resistor added to the clock signal would help.

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

What is the vertical scale?

Horizontally that does look close. I've found the address bus tends to settle around 10ns-15ns after PHI2 falls. At 16MHz you should have about 30ns in total before PHI2 rises again, into which you need to fit the propagation delay of the decoding circuit and the setup time for the 65C22. I think you have a 74ALS520 and a 74AHCT138 between the address lines and that chip select signal. Perhaps one thing you could try is temporarily changing the address decoding so that the VIA is selected more broadly, requiring less intervening circuitry? It wastes address space but at least you could test whether it resolves the problem.

1V per division.

That agrees with my observation as well. It seems to me that the 65C02 performs the 10ns tADH time hard and fast. After that, the address bus and R/W\ switch to their new values more or less immediately, which takes about 5ns. The 30ns tADS shown on the data sheet doesn't seem to exist in real life, which I think is why we're so easily able to "over"-clock these devices. We get about 20ns of extra time for free where the 65C02 normally just sits around twiddling its thumbs (bits?).

I switched out the ALS520 for an F521. It's quite a bit faster. Going by the "typical" column on the data sheet, I'd expect their combined delay to be about 15ns. The datasheet says the 65C22 needs 10ns of setup time before Ø2 goes high, but who knows if that is in any way real. Anyway, at 16MHz, on paper I'm definitely within a couple of ns of missing Ø2 going high, and thanks to difficult-to-predict factors (such as my bio-electric field!) and voltage level differences, sometimes it misses and I get glitchy performance. (I notice it works slightly better with my wall wart - 5.1V or so - vs. my little home-made bench supply - 4.8V or so.)

I have quite a few F521s and AHCT138s - 10 or so of each, I think. I might try just going through them and seeing if I can find some outliers that lean towards the "min" end of the propagation spectrum.

I think changing oscillator speeds does more or less the same thing; watching the scope, as the rising edge of Ø2 "moves" away from crossing the falling edge of chip-select, the glitches disappear. 13.5MHz (37ns) works fine, 15MHz (33ns) is a bit glitchy, and 16MHz (31ns) won't boot.

Edit: I forgot to mention, I tried adding a series resistor to the VIA clock where it comes onto the I/O board. I tried a 47Ω and a 100Ω resistor. The I/O board was not happy with either of them. Then I added a twisted ground return wire to the clock line. That helped make the board a little more robust (it doesn't crash when I poke it with my finger any more), but of course that can't fix the basic problem of chip-select lagging Ø2.

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

Welp, I did a little more thorough poking this evening. To follow up with more exact timings, on this board R/W\ etc. seem to settle about 17ns into Ø1, so a little (but not much!) more slowly than I allowed for. Meanwhile, the AHCT138 is quite a bit faster than I expected, lagging the I/O signal by only about 2ns. Meanwhile, the F521 takes about 10ns from the time it's enabled to the time its output switches. This is close to its maximum, so I'm not sure why it's switching so slowly. Maybe my board is not supplying it enough current? I guess I could try putting a bigger capacitor on its power pin.

Anyway, it takes just about exactly 30ns from Ø1 to chip select going low. At 16MHz, that does not leave much time for the VIA to wake up and be selected before Ø2. Unless I can figure out a way to speed up the F521, I guess I'm going to have to accept that I'm not going to hit my target speed for the I/O board. I will have to think about how to proceed. As I see it, my options are:

1. As George suggested, change the VIA decoding so that it's faster, but wasteful of address space
2. Just accept a lower speed limit than I like until I get around to learning programmable logic (conceptually distasteful, but practical, and also historical)
3. Put the VIAs on the slow clock, which will give up accurate VIA timers, but still allow the board to run at 16MHz for RAM access.

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

On (1), you might not need to compromise much in practice. Note that you can chain '138s together very effectively to decode quite a lot of address lines all at once - I think each one can decode most combinations of six address lines, so although it's harder to configure than the '521, two together can partially decode even up to 11 address lines, which is more than you need for a pretty small I/O window - and in particular, two chained together can be set up to detect any chosen single page of address space. You'd then use a third to decode individual I/O devices, as you already are doing. The only constraint is whether two in series will be fast enough for you - but it sounds like they will at least be faster than the '521. I haven't used the '521 though so can't really comment on it.

Regarding (3), this evening I have been designing a circuit similar to Jeff's one which can also generate a slow and consistent I/O clock, e.g. PHI2 divided by 2 or 4, and stretch PHI2 by the right amount to match that clock during slow cycles. e.g. given a 32MHz input clock, generate a generally-16MHz PHI2 with a 4MHz or 8MHz I/O clock, and support stretching PHI2 to match the I/O clock on demand. When it stretches the clock, it ensures the I/O devices are properly selected for a full phase of the I/O clock - low then high - with PHI2 held high throughout, so the address and data buses from the CPU are stable.

I think I have it fully-designed now, requiring two '163s and a '74, with a bit of glue that may or may not be reusable from elsewhere. I believe - but haven't fully thought through - that in addition to supporting slow hardware, this would take some pressure off the I/O decoding time, as once the cycle is a stretched cycle we have a lot more time to figure out what should service it. This was very much the plan with my fast PDIP system, and seems to have allowed me to dodge a lot of bullets.

It was intended eventually for a synchronous version of my fast PDIP system, and I'm fairly confident it will work, but I need to test it, which I'm hoping to do at the weekend - however I can share it sooner without testing it or explaining it properly, if you're interested.

The last thing to do at this stage of Blue August's development (before moving on to building a video card) is to finish the I/O module by wiring up the ACIA and attaching a serial port.

Previously I've made a couple of half-hearted tries at getting this working without much success. There were just too many variables... are my ACIAs bad? Do I have the COM port on my old thinkpad enabled? Do I have the right kind of serial cable? Is everything wired up right? etc. This week it was finally time to really concentrate on getting the ACIA working.

Well, let me start by being critical of Ben Eater. I generally an a fan of Ben, and don't have much patience with the negative view of his videos expressed by some of our regulars. This particular time, though, I think he really let us down. Here's a screencap of my schematic for the RS232 interface. I made this in KiCAD while following along with Ben's short series of videos where he adds a serial port to his breadboard 6502. If you check Ben's own schematic on his website, it's pretty similar. I bet Garth will immediately spot the problem... Fortunately, I recently read this very useful thread: viewtopic.php?f=12&t=7790 and remembered this important quote from the Primer: Well a 2 wire + GND interface is exactly what Ben is building in this video. He even mentions leaving those pins unconnected while he's configuring the ACIA. His build seems to work with those pins floating... don't ask me why. Anyway, I grounded those pins.

It still didn't work. I checked the thinkpad's bios. Yup, the serial port was disabled. *sigh* Eventually, I became pretty confident that everything was wired up according to the schematic, that the thinkpad was configured correctly, and yet Blue August *still* was not receiving anything. So I hooked up the scope probes to the two serial lines. It's hard to get an analogue scope to produce useful information on signals that don't repeat, but I was able to get it dialed in to a setting where I could see that the thinkpad was indeed sending data (I just held down a key on the thinkpad and let it repeat). The thing was, the line that thinkpad was trasmitting on was pin 2, which is connected to the *output* of the MAX232. I unwrapped those wires, switched the connection from pin 2 over to R1 instead of T1 and boom, suddenly it works. Well I'm happy about that. But, I want to solve the mystery. Why did I need to switch those pins? Looking at this site: https://web.archive.org/web/20170913121 ... tinfo.html it appears that pin 2 is in fact the input pin in a serial port. Why does Ben's work? Does he have a through cable instead of a cross-over cable?

Oh well, whatever. Here are a couple more pictures, one showing the whole field of battle, and the other one zoomed in on my little serial header.

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

Part one was only about receiving data. This afternoon I went ahead and hooked up the transmit side of things, and encountered a new mystery. If you recall, my ACIA is an old 4Mhz Rockwell part - at least it purports to be. Blue August's system clock is not quite as fast as I'd hoped, but it is substantially faster than 4Mhz. Today, I was running it at about 12.5Mhz, using the 25.175Mhz can oscillator from my VGA circuit.

In order for the ACIA (and the ROM!) to work, I'm using Jeff's amazing `163 clock switcheroo circuit to slow down to πMHz when accessing them. The ACIA appears to have no problems with this when receiving data. To troubleshoot transmitting, I set up a stub subroutine to just send the letter 'X' over and over again, spamming my serial terminal. I mostly saw nothing. Except, while probing the clock lines, a few Xs made it through. So, just for kicks, I dropped in my 1MHz can oscillator, which makes the system run at super slow 500Khz and 125Khz fast/slow clocks. And suddenly, transmitting began to work! I tried again with an 8MHz (4MHz/1MHz) oscillator, and that also worked. I'll poke around in my bins and see if I have any other oscillators between 8MHz and 25.175MHz and see when it stops working. Looking on the scope, I don't see any clock glitches at any of the speeds I tried today - the slow-downer seems to be working right on time.

So, I wonder if maybe my ACIA is actually one of those ones where the silkscreen has been sanded off of an old 1MHz part. Maybe receiving is easier, and it can just about manage it at 3MHz, but transmitting is harder, and it chokes?

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

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

Hi Garth,

I tried building one of those last year and couldn't get it to work. Maybe I should have another go now that my construction skills have improved some.

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

if you're not affraid of ordering some parts you could try out my DS1086 based Clock Module. though that requires either an Arduino to program, or if your SBC has some GPIO you could have the system set it's own clock.

Great job making it work eventually! Sorry for all the back and forth though. I guess sometimes that's just how things go.

What's your ultimate goal with this? Is it to be able to new data to the board quickly without needing to reprogram ROM's and all that? Or do you have other plans?



Only because you mentioned it: My main complaint is that he should acknowledge Garth's 6502 Primer. Not only because it's a great resource for folks that are buying his kits, but also that it appears his design was *heavily influenced* from Garth's "potpourri" design and no credit goes to him for it. Not even a mention. Although Ben is the 'lowest common denominator' on this stuff [i.e. floating ACIA pins, non-debounced reset circuits, etc. ] and I understand that, I am going to continue to critical of his videos simply because of my prejudice, right or wrong.

Good update, great job, and thank you!

Chad

Hi Chad,



If you remember from way back when, Blue August is going to be an actual home computer style machine, in a case, with mass storage, etc. So for the serial port I don't exactly have an ultimate goal. Uploading programs like you mention is something I want to be able to do. I'd like to run WOZMON, too. But, in the long run, I just want to have a serial port mounted on the case that I can attach whatever things I might want to it. Maybe someday I'll get inspired by you and add a serial mouse to the machine. Also, the ACIA is part of the 6502 family, and at least a basic working understanding of it is something I want to have.



I won't argue too much with you about that, except to say that it seems like Ben often gets hit from both sides with that one. That is, people castigate him for not following the advice of the Primer, while at the same time complaining that he doesn't credit the Primer for similarities. There aren't all that many ways to decode a 6502 address space. Maybe Ben did get the idea for the 1IC NAND decoder from the Primer, or maybe he got it from Grant Searle (the first place I saw it, actually), or maybe he came up with it on his own.

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

A worthy cause indeed! Over this past week I actually have been working on a PIC16F886 + FT232RL USB Module to transmit and receive serial data from the Linux-box, though connecting the PIC to the 6502 is not an easy task!

BTW, my mouse is just a PS/2 Mouse, but because it requires bi-directional communication the way you build hardware for it is particular.



Well, I can see that, you make a point. And perhaps I don't understand how business works, or how I feel it should work in a perfect world. He might be making more money on his kits by not mentioning the Primer. Still, it's only nice to give credit where credit is due. I've slapped a "Garth Wilson's 6502 Primer @ wilsonminesco.com" in silkscreen on every one of my boards, and will continue to do so.

Good progress overall, glad you are doing this.

Chad

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

True, but there are "cool points" when putting WozMon on your SBC. It's not as useful but it has history and can fit on practically anything. Keeping it under 256 bytes even when you modify it for your own use is part of the challenge too (as Ben Eater has been doing recently, I do appreciate those videos of his).

If I were to actually code on my SBC, for my SBC, I'd want something far more powerful than WozMon.

Chad