Even though I haven't figured out what to do about construction yet, today I hooked up my keyboard card and "ported" PAGIMON over to Blue August so I could do some more testing. (Does it count as porting if you only have to change 2 addresses?) I also ordered some more oscillators so next week I'll be able to try some different speeds and see how it responds.

In the meantime I think I've discovered a real problem. My output port for ROM banking doesn't work like how I think it should. *ANY* write to the output port's I/O range results in a total lockup, even a write of "0." I have a spare line on Port B of the VIA (the LCD only uses 7 bits) that I can use for testing, but in the long run I was planning to not have a VIA on the main board. I've checked the wiring 2 or 3 times to make sure it matches the schematic, so I must have made a real thinking error.

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

The 6502 doesn't drive its data bus immediately during write operations. For RAM this doesn't matter because by the time the operation ends (phi2 falls) the data is there, and the RAM writes continuously during the cycle. But your flipflop is edge-triggered so it only samples D0 at the start of the operation, when the data may not be ready yet. Using an OR gate may fix the issue as the sample would occur at the end instead.

Something there must also be qualified with phi2 - you need to sample D0 around its trailing edge. So if either /WRITE or /DEV0CS is already qualified then that's fine. If not then phi2 needs to feed in here as well.

The idea being that the OR gate will go high when the 6502 releases the write strobe at the end of Ø2, so the flip-flop will latch during tDH in immediately following Ø1, right?

Honestly, I'm experiencing some strange confusion here. I got the idea for a 1-bit output port from this article: https://www.atarimagazines.com/computei ... page17.php where the author clearly uses an OR gate (even though the text says AND). In my original glue logic, I used an HC32. In glue v2 it has changed to a NOR gate, but I don't remember changing it, or why!

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

Yes exactly. For these kinds of thing - whether they're asynchronous, continuously sampling their inputs while their activation signal is low, or synchronous like flipflops, only sampling it once at the rising edge - you can use the same active-low signal and it all works out.


HC32 should do the trick, yes. Perhaps they wrote "and" because logically it is an "and" operation, but with active-low signals so in positive-logic terms it's an "or".

`HC32 sorted it all out. I had just verified that my copy ROM to RAM routine worked and I was indeed running from RAM, when a tree fell down and took out power to the neighborhood for about 9 hours!

Updated schematic:

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

I started putting together a second try at Blue August over the weekend. If you've seen Peanutbutter-1, this will look familiar. I've gone back to the protoboard I built Peanutbutter-1 on. In fact, since Blue August is an expansion of Peanutbutter-1's design, you could think of it as Peanutbutter-2! It's the same construction concept; glue logic along the top, big ICs along the bottom. The edge connector is 30 signal pins and 30 ground return pins. I had wanted to get the whole 32 bit 65c02 bus onto those pins, but it doesn't fit onto this board (which is why I started out using different protoboard in the first place). Still, I probably won't ever need the full 16-bit address bus to be on the connectors; I could use up to 14 address lines if I wanted to use al 8K of the VGA board's dual port RAM, and I just have room for exactly that many lines after losing the 2 pins. But, I don't actually need all 8k for the frame buffer. I'm waiting for some pin headers to be delivered so I can finish the soldering and start wrapping. Meanwhile, I updated the schematic a bit:

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

Great! What do you use to drill out the tracks? I always found I got a really tired wrist from doing that!

A drill.





To be more specific, it's a regular Black & Decker electric hand drill with a 3mm brad point bit. The brad point keeps it centered in the hole and stops it from slipping.

Honestly, I'm not super happy with how it performed this go round. There are a few tracks that it peeled up rather than cutting, and in some spots it left quite a bit of copper behind in the circle. It all seems *functionally* good (connections are cut where they're supposed to be, and no shorts to neighboring tracks) but it looks messy, and I'm concerned the leftover copper will become detached later on and cause intermittent shorts. I may get a real "Vero" tool bit the next time I try this.

Edit: Well, it occurred to me that I haven't sharpened that drill bit in probably 2 or 3 years. So I did that; now it's working great. Those messy holes cleared right up.

BTW, anyone who is thinking of doing this at home, make sure you have a good mask. You don't want to breathe fiberglass!

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

The new board is all finished! I didn't take a lot of in-progress photos, since this isn't really new territory. I made a few mistakes right before powering it up for the initial test and got chaos. I ended up ripping out the first ground network and redoing it. Not sure if that was the problem or not, because as I was making a new ground network I realized I'd left the top two address pins of the ROM floating! Those are the bank-select pins, and they're supposed to be grounded until I have some front panel switches to select between banks. Anyway, here it is: I never did manage to get fx2pipe and the Cypress dev board working reliably. I tried to use it again just now and I'm *almost* certain I have everything hooked up the way I did a few days ago when I got at least something, but it just sits there spinning its wheels. Jumper on, jumper off, A4 grounded, A4 floating, it's all the same. The little 8-channel analyzer works great though. I'm using it with sigrok-cli, and hoglet's decoder works just great in 8-bit mode. I have a 32MHz oscillator installed right now, which makes phi2-fast 16MHz and phi2-slow 4MHz. Right now it's just nopping from the ROM, but this is an encouraging result, because it means the decode is getting done before phi2-fast goes high and is successfully stretching the clock for the ROM access.

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

It's great that the fresh build of your system is working now - a shame about the logic analyser though. Since it started working for me, it has been very reliable and I've left the jumper off.

The trouble with 8 bit sigrok captures is the decoder can't tell where the clock edges are, so it might not work well when you're decoding something more complex than a stream of NOPs!

Getting fx2pipe working with a test circuit was a useful step for me, taking the 6502 etc out of the equation temporarily. Simply driving it from an oscillator is enough to check the data capture is working, and all the pins are correct. I only have PA4, PA5, RDY1, and IFCLK connected these days. My clock stretching was causing problems until I figured out how to wire that into the logic analyser as well.

I feel there might be potential for a kind of "HAT" board to go on top of the Cypress board and provide a few helpers for this sort of thing... like better pin layouts and silkscreen tailored for this use case, jumpers to select between capture modes, and then maybe some electronics like latches for the data bus.

(Re data-bus analysis: it occurs to me that my STM PoC boot loader could be used in this way, particularly as it's providing the clock to the 6502 and so could generate timed reads automatically, slowing the clock if necessary to get data out to a host computer. Hmm, something for later... first I have to build it!)

Neil

I may give it another go today. Sometimes things go better at the start of a session than at the end of a session! I should clarify that it's the -ifclk mode that isn't working. I didn't try -a mode yesterday.

Edit: Derp, it's working now. I had the A5 (reset) wire plugged into A7. Now that I'm in my early to mid 40s I can't see as well...

Last week when I was reading everything I could find about this I came across a guy who made something like that for it and mounted the whole contraption in an Altoids tin! He was worried about current protection, so he added a bunch of resistors, and connected the input pins to a shrouded pin header that poked out of the side of the tin. That way he could just plug in an IDC cable with all of his leads on it. Was pretty cool. I just did a quick search to try and find it again, but I can't remember what he called it, so I came up with nothing.

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

Haha, well that's more good news then! I've made the same mistake with the same pin, and recently realised how long-sighted I am becoming - I rely on magnifying glasses way too much these days.

This is both cool and annoying. I replaced the NOP tester with BDD's ZP RAM test. I see it start working, then I get a prediction failure and a bunch of NOPs - but the NOPs are FB not EA - and then it picks up again. At first I thought that maybe the LA was just reading garbage off the bus and I needed to tweak it somehow, but when I looked more closely I saw it was working fine and, in fact, the prediction failures were unexpected resets! So I started looking at the reset line. It's at 4.8 volts, while everywhere else on the board is 5.1 volts. Why this voltage drop? I don't know. I also looked at it with my oscilloscope. VCC and GND both seem quiet - they don't trigger the scope. But reset is corrugated... it seems to be coupled to the clock signal. After lunch maybe I will add another bypass cap to the power rails near the DS1813 and see if that helps. It is fairly close to the `163, which I know from experience switches hard. A bit frustrating there. But, it's pretty cool to get a practical result from the LA and hoglet's decoder. It would have taken me a lot longer to track notice this problem without it!

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

This post turned into a kind of stream of consciousness troubleshooting log. I started out intending it to be an update, but then I kept thinking of things I wanted to try, and writing down the results. I'm going to go ahead and post it as is, because I'm too tired to try and edit it into anything entertaining! The short version is, I made some progress. All this troubleshooting has uncovered a few mistakes that I've corrected, but the main problem is still there. That main problem seems to be that the board freaks out whenever there's a "LDA 0,x" instruction. It does not freak out when there's a "ROL 0,x" instruction. I don't know what this means. I guess tomorrow I'll have to put together a test to see what addressing modes make it freak out. If there's bus contention reading from RAM, I would have thought that read-modify-write instructions would also cause it to happen. Anyway, if anyone feels like slogging through all this, I'd be grateful for advice!

Well, I have definitely made some progress. I'm not sure what it all means. I redid the VCC/GND connections for the DS1813 and the 74HC163, and added another bypass cap. RESET\ still looks a little bumpy, but it's better, and I don't *think* I'm getting glitchy resets any more. I'm not sure what I'm getting. Like I mentioned earlier, I copied BDD's ZP RAM test from that other thread:
I'm still not able to get good results with the -ifclk mode of fx2pipe. However, the -a mode seems to work fine: You can see it's executing the right code. It works fine for a while, and you can see .X counting up as it scans through RAM. But then it freaks out: It's nothing but 7D for ages. Then, suddenly, it changes to a different kind of junk: It does that for a while, the finally bombs out with: for the rest of the capture.

*HOWEVER*

If, without resetting the 6502, I immediately do a second capture, I get: which suggests to me that the garbage in capture1 represents the capture failing somehow. Clearly, the 6502 has completed the RAM test and is sitting in the result loop, as it's supposed to be. On the other hand, the result loop is one of the failure loops for bad RAM. Is it possible I actually have a bad RAM chip and that it is, somehow, freaking out the capture when I run into the bad spot? I don't know. I ran some more captures. They all fail at *about* the same place: .X = 37..3D. I also tried using a very slow clock (500Khz) and got the same results. At this point, I think I need to try a different RAM chip. I have a couple of spares, so... nope. Same thing, it bombs out at X=3C. This time, however, when I do my second capture, it's still spewing garbage! (55, 55, 55, 55, 55, with the occaisional 7D thrown in).

Well, is it something about that specific area of the address space, or is it something to do with how long we've been running? Let's tray starting .X at $35 and see how far we get. Aaand, it crashes immediately at LDA 0,X when .X is $35. That's something then. Wait a minute, I never tied off all those unused inputs on the `14, because I wasn't using it when I/O was in zero page. But then I moved IO into ROM so I could do the RAM test. (10 minutes later) OK, that's something. The decoder now has no "prediction fails." But this still happens: Could something be wrong with A4? When I beep it out it seems to go everywhere it's supposed to, and not other places. It seems like any read from $8090 - $80FF returns 55. That's about the same size as my I/O window. Once it gets out of the $8090-$80FF area it starts behaving properly... All those BRK / RTI is what it should really do when reading from that area of the ROM (it's full of zeros). And when it eventually works through all those it runs into the "RAM FAIL" loop at $A000.

I can test this really easily by having my reset vector start later in the ROM.

No that didn't fix it. There are still lots and lots of $55s, and this time when it read over $A000 and $B000 it didn't see what's in the ROM, just $55. It didn't start seeing what's in the ROM until $C000.

I went and checked all the wiring for yet another time. I would start to think maybe my ROM is bad, and just randomly freaks out and spews garbage, *except,* it always seems to happen after the instruction "LDA 0,x." That seems like bus contention. But why wouldn't it happen after ROL 0,x?

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