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

Very cool. When I was searching for just the right protoboard to build Blue August on I seriously considered that it might be time to learn PCB making... just so I could make the exact protoboard I wanted! I felt like if I went so far as to do that, though, I probably might as well just make the whole thing on a custom PCB and skip the protoboard altogether.

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

This is the product info page from the manufacturer, where I read that the current version of the tool has a plastic handle:

https://jonard.com/hand-wrap-tool-wsu-tool?v=629

Amazon sells it for a pretty penny. This is the one I ordered earlier this week; it was just delivered this afternoon:

https://www.amazon.com/Jonard-WSU-30M-S ... 006C4D50U/

It works FANTASTIC; totally worth the seemingly ridiculous price. I've been wrapping for about 2 - 3 hours, and have had only a few bad wraps that were probably pilot error. The handle also seems fine... I can't tell that it isn't aluminum. It looks just like the one in the picture and says "Jonard Tools" on it.

Here is the Amazon page for the first tool I bought a year or so ago:

https://www.amazon.com/gp/product/B08H9P1R1L/

This is a representative listing; there are quite a few similar ones in the $20 - $30 price range. They look just like the one in the picture from the Primer: http://wilsonminesco.com/6502primer/OKI ... tools2.jpg Notice the silkscreened lettering. On your own personal tool (http://wilsonminesco.com/6502primer/CMP_WWtools.jpg) and on some vintage OK M&T WSU30 tools I found online, the lettering looks like it was originally stamped / embossed.

I don't know for sure, but I suspect this is the situation: at some point OK Industries, like a lot of companies, moved their manufacturing to China. This is probably also when they switched to silk-screened rather than stamped lettering. Typically, companies that do this perform their own quality control. At some point, the Chinese manufacturing company was nationalized. The same original production machines continued to make lots and lots of units, but without the oversight of the OK Industries quality control. Plus, as the machines wear down with time, manufacturing tolerances get looser. This is exactly what happened with the Parker Pen Company, so I'm reasoning by analogy that something similar happened with these wire wrap tools. When Jonard acquired the OK brand, they found that they were, in a way, competing with themselves. They had to make some changes to their real, high quality tool, to distinguish their product from the floods of in a way also real but much lower quality zombie tools.

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

Just wanted to appreciate that again

Neil

Control signals wired up!
Before I forget, here's the solder side:

Let's talk clock stretching for a minute. One of my plans for this project is to have an RS-232 serial port. Even though I follow along with Ben Eater's videos, this is something I haven't done before. I know there are some clever tricks to get around the bug in the WDC 6551, but I'd prefer to solve that problem simply by not using buggy parts. I have some late '90s / early '2000s CMD parts that I like a lot, but the G65SC51 seems to be a lot harder to find than the G65SC02 and G65SC22, so I don't have any of them. I do, however, have a couple of 4MHz Rockwell ACIAs. This is a bit of a drag, since I was hoping to operate Blue August at 14MHz or above. Fortunately, Jeff (Dr Jeffyl) gave us a nifty clock stretching technique. I have adapted it in a way that looks very clever (I think), but I'm afraid I accomplished it in a non-clever way. I have to concede that what Jeff is doing there is right at, or just beyond, the limit of my ability to visualize while reading a forum post. Luckily, four binary inputs and four taps is only 64 combinations, so a few weeks ago I spent a few hours of downtime between West Side Stories to brute force the problem: The most interesting one to me is loading 9 (1001) on Q3 low: This gives you symmetrical slow clocks at 1/2 and 1/4 of your VIA clock (1/4 and 1/8 of the oscillator frequency). Here it is in operation during a Blue August ROM access: This is with a 32MHz oscillator using the divide-by-four slow clock to go from 16MHz to 4MHz. I don't know if I will be able to keep going this fast once I actually get RAM on board. My RAM is 15ns, and my address decode is a little slow thanks to the `688 (I couldn't find any `521s). Still, pretty happy with this result.

Edit: One additional thought; since the load inputs to the `163 can be wired up as a register, you could in theory have a software controlled clock. It should also be possible to control what tap you're using, although that would require more complicated logic, and I haven't thought about it much. This could be dangerous, in that there are plenty of non-useful configurations that you could fall into due to a glitch or a programming error. Still, I think it's a cool idea!

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

This is a really cool idea!

_________________
BB816 Computer YouTube series

Nice. If it's working with ROM, I'd expect the RAM speed to not be an issue at all, as the ROM is surely much slower. However, the extra address decoding delay would put more pressure on the ROM access times, so I'd expect that to be where the challenge lies.


I've used that method with 74HC40103 8-bit downcounters to create audio tones, but not for the CPU clock before. For selecting taps I would think a multiplexer could be good - you need to make sure that when you're switching taps you don't send glitches on the clock or high/low periods that are shorter than intended.

I've reached that annoying part of the process - trying to figure out why the board still doesn't work even though it is (or seems to be) wired up properly! So I pulled out my Arduino and my slow clock module and fired up Ben Eater's bus module. Instead of pictures, I made a little video: https://youtu.be/Oc070ZULVoM

This baroque monstrosity actually runs at 13.5 MHz (yay!) but not 16 MHz (boo! but not unexpected). In the video, for testing purposes, however, the clock module is running at about 3 Hz. The clock stretcher is in place, so the ROM accesses (which is most cycles) are actually about .75Hz. I grabbed a bunch of random LEDs from the drawer; turns out half of them are UV party lights, and two of them are those random blinky fireworks ones, giving my test rig a little more bling than I'd planned!

Edit: Actually, that's not quite accurate. While I was writing that I forgot to take into account that the clock stretcher divides the oscillator frequency by 2. So the VIA is actually running at 1.5Hz, and the ROM accesses are one-fourth of that, roughly 3/8 Hz!

So far I have verified that the OE/WE signals of the RAM and ROM were connected to each other, but not to READ and WRITE. I think what happened is I was wiring up the control signals, had to break for dinner, thought "OK, after dinner I will finish hooking up READ and WRITE," instead after dinner watched Star Trek, came back the next day and though "OK, yesterday I wired up the control signals, so today I'll do the bus wiring!" Whupps. Anyway, things that actually are working:

1. Reset controller (DS1813) - happy to find I didn't fry it while hooking it up. I had some soldering adventures in that corner of the board.
2. Clock stretcher - It's kind of fun to watch it in slow-mo after a reset. It zips through its internal reset stuff, then hits the brakes when it starts reading from ROM.
3. ROM - reading / executing instructions just fine (now that OE is attached to something!)
4. I/O decoding - the VIA on the breadboard is clocked by the unstretchy Q0 output of the `163; the 6502 is clocked by the stretchable Q2 output.

Next up: put the RAM back in and try running some code with subroutines. (y/n)

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

Well, this is looking interesting! I do like the soldering job you did, very clean looking! Those wires are fun to see all over the place. And 13.5 MHz, wow wee! That's a lot!

I myself have had that same annoying part of the process today, so I feel you there.

Thanks for the pictures and video!

Chad

Great progress, and very fancy LEDs!

The bus monitor is not working properly. This is very common - with all those wires to hook up it is easy to miss one or connect it to the wrong pin or have a loose connection, etc. It especially looks like your D2 pin isn't quite right.

Yes, I've had some problems getting a solid connection on each line, and its easy to swap neighbors. Every time I use this thing I renew my vow of hatred for Dupont wires. Last night I rebuilt the bus monitor connections a little more tidily. RAM seems to be working. I didn't test all of it (or the banking), but I did fill each zero page location with its own value (i.e, lda #$72, sta $72), then read through zero page and write the values found to the VIA. I also tried a few fast oscillators. 1MHz is too fast for the Arduino bus monitor, of course, but I can see that the VIA initializes and the LEDs flicker. At 8MHZ the LEDs just look on. At 16 MHz the VIA doesn't initialize, so it either doesn't like being overclocked, or my decoding is too slow for 16MHz. At 13.5 MHz the VIA initializes and some of the LEDs look on and others look off. I'm not sure if that's because the program is crashing at the exact same spot every time, or if it's just an emergent feature of switching the LEDs so fast with the resistors / breadboards I'm using. I'll need more I/O before I can test further at 13.5MHz.

I don't seem to be able to get my LCD to initialize at *any* speed. It's possible I've... forgotten how it works! I thought I would be able to just change a few I/O addresses and port my LCD initialization subroutine over from Blue April. I'll investigate more closely today.

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

This is a frustrated update. Peanutbutter-1 worked at 12.6MHz practically the first time I turned it on. Since Blue August is an expansion of that design using the same construction method, I had high hopes, but this board has turned out to be disappointingly fussy.

Yesterday I went through the whole troubleshooting process step by step. After a comedy of Dupont wire errors I did get the LCD to initialize (my old code worked fine). Then I tried each of my oscillator cans in turn. I have 1MHz, 8MHz, 27MHz, and 32MHz. (The Ø2 rates are 1/2 and 1/8 of the oscillator frequencies for fast and slow clocks.) It worked with the 1MHz can and the 8MHz can, but not the 27MHz can - until as I was tidying up some loose wires I happened to push down on the can and it booted right up. I could do this every time: turn on the power, nothing. Push down on the can, zip, it starts working. I figured that I must have a bad solder joint in the socket, so I resoldered it. Now I can push on the oscillator can as hard as I want and it doesn't make it work any more!

I moved the oscillator to the breadboard and supplied the clock over a wire. I got it to work a few times in this configuration, again by applying mechanical pressure to the board, either pressing down on this or that IC, or by flexing the board. More worryingly, I noticed low level current flow through the output LEDs of the test rig that would react to the board flexing. As hard as I worked on tidy construction, I seem to have some kind of systemic failure.

I'm not sure what I will do next. I might try rebuilding it; maybe the perfboard I selected is part of the problem? It's thinner than what I built Peanutbutter-1 on, so I could switch to a sturdier one. Or maybe this is a sign that it's time to start making PCBs!

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

That's a shame. Could you measure the clock signal at the CPU pin and check how stable that is? You could also measure the input to the counter and watch out for ringing etc. The other thing I was wondering was how good your ground network is - you have a lot of signal wires floating around there, what are the ground return paths like for those?

If the clock signal arriving at the counter is dubious, it's possible that adding a series resistor close to the oscillator pin will improve it, e.g. 10 ohms or 47 ohms sometimes work for me. It's not scientific but just enough to take the edge off parts that drive very sharp edges... at least that's my goal with that.

Also, did you connect the fourth pin of the oscillator? Sometimes this is an "enable" pin. If it's floating maybe that's why it's erratic and likes having your finger there.

In terms of bus monitoring I highly recommend hoglet's decoder rather than the Arduino, it is easier to connect reliably and it can deal with much faster clock speeds. The cheap logic analyser I got seems to support sampling at up to 48MHz, enough for a CPU clock of up to about 8MHz I think, and I haven't tried synchronous capture but that might support even higher rates. Hoglet's decoder decodes the data stream into disassembled CPU instructions. You don't get the address bus, but it adds addresses when it's worked them out based on other instructions... very clever.

I'm sorry for it not working as expected! Pushing down the oscillator like that is very strange to me. George's idea to connect the oscillators enable pin was a good idea. And re-soldering it made it worse?! Very odd behavior.

So, what do we know? We know that it works at 0.5 MHz and 4 MHz. It seems completely stable? Reliable? Good to go? Then we know it's not a concept design issue. You want it to go fast, that's your goal, so either it's timing margins or connections. It's something physical, essentially.

And these are my most hated issues personally. Being a software-leaning guy, hardware hiccups are not my thing. I am quick to discard and start new, even if that means printing new boards and waiting a couple of weeks. I'd rather not invest my time in a failing project than just get it done right the first time. Plus you can use that time in between for software! Build an emulator/simulator for yourself and rock on!

If your goal was to get a working system, you got it. But that's not what you are wanting here, right? You want it to go fast. And although I know you haven't been wanting to dive in just yet, a printed board would absolutely be the best for this. I highly recommend KiCad + freerouting to make it, and JLCPCB to print it. [ I also recommend DHL for shipping, totally worth the extra dollar or two over the alternatives. ] If you have any questions at all, we can talk. Apparently I've been printing boards for a year and a half now, and loving every moment of it.

Thank you for the update.

Chad