6502.org

Holy cow, for a hardware newb you're doing awfully well! Nice to see the plan unfolding per expectations. Go, Drass, go!!

-- Jeff

Drass, congratulations on building your first 6502 computer. Pictures look great !
It's always sort of a magical moment if the blinkenlights display patterns that make sense
for the very first time.

That 6502 SBC alone already would make a nice beginner's project...

not to mention that TTL CPU.

;---

Speaking of it:
I think you could try to order the CPU PCBs after finishing that 6502 SBC.

Haven't noticed any more errors in the schematics and PCB layouts...
what, of course, doesn't mean they really are free of errors.
Considering the complexity of the design, it is somewhat inevitable
that we have missed something, and that the CPU won't work as intended.

If you are running into trouble when testing the CPU later,
it feels like this might be caused either by timing issues...
or by K24 microcode.


Hey, the first prototype usually is "for the trash can",
please don't get discouraged if the CPU won't be working at first try.
Hmm... if the CPU would be working at first try, you _would_ need to be worried,
because the problems then usually will show up later.

Looking forward to watching the progress of this project.
Good luck and godspeed.
Go, Drass, go !!

Thanks for the encouragement gents - I've had a lot of help from my friends

Yes, the blinkenlights were definitely a magic moment. And thank you Dieter for reviewing the CPU schematics once again. It will be a bit still before I move on to the CPU itself. I still have some issues to track down here. For instance:

1) After running the SBC a little longer, I began to see the data bus change - not good. Probing around, I saw that the Chip Select for the ROM was not behaving and some reads were therefore happening on a floating bus. A quick look at the address decoder confirmed the issue: the 816BNKH signal from the absent K24 Card was intermittent. Re-soldering the associated pull-up solved the problem, and the data bus is now rock solid while reading.

2) The FAST clock was indeed broken due to a miss-wired inverter. Here is the change needed: To fix the problem, I had to lift IC3-pin 3 off its pad and jumper it to IC5-pin 4: I removed solder from the pin with a soldering braid, and gently bent the pin up with tweezers. It was then possible to solder a pre-tinned jumper on to the pin while leaving the pad below isolated. The wire I'm using is from a wiring pencil (something I acquired back when I thought this was going to be a through-hole protoboard build). The wire is insulated but makes a nice connection when soldered - perfect for a jumper! I then just soldered to the other pin and tacked the wire down to tidy things up.

And now it works perfectly! I'm able to switch from the SLOW clock to the FAST and then to MANUAL mode. I need more testing to validate that no runt cycles are generated in the process, but it's certainly coming along. Incidentally, MANUAL mode has proved valuable already, which is not something I had expected quite so soon. Nice bonus.

I'm not at all discouraged ... quite the contrary, I'm finding the debugging (and the patching!) to be very interesting and fun - and it seems required training for the next-level challenge ahead!

Cheers for now.

A quick update with some good news and some bad news ...

The Good: I set up a quick test to exercise the VIA, and SUCCESS! Writing a fixed value to the ports produced the correct results on the I/O headers, and connecting the two ports together confirmed that a value written into one could be read from the other. I also set up the shortest possible IRQ service routine to increment an I/O port register on rollover of the T1 16-bit timer. I gotta say, it was pretty rewarding to see the port pins blinking at different rates! In passing, I could verify that the FAST and SLOW clocks correctly speed up and slow down the blink rate, and, so far at least, no glitches switching clock rates on the fly - even with a regular IRQ in the mix. I can't confirm the frequency of the signals, but at least I can see things get faster and slower! It seems the wait-state logic is also slowing things down for ROM and I/O operations correctly, but with no RAM installed, I can't be sure it's all working quite yet.

Now The Bad: I'm having one heck of a time soldering the J-Lead components (RAM & UART). My suspicion is I need a smaller tip on the iron. I just can't get in close enough to heat the pads, and all I manage to do is bridge the pins with barely any solder making it to the pads. The result is a right mess. Unfortunately, I've had to take a heat gun to the poor RAM chip to pry it loose after a couple of botched attempts (gotta wonder whether the IC is damaged by now, ugh!) I'm using a pretty beefy chisel tip I purchased for through-hole soldering, so ... definitely time to sort that out now. With the successful test on the VIA, I have to believe the RAM should work without too much trouble - if only I could get it soldered in place!

Cheers for now.

The chance that you've damaged the IC with heat is just about zero. With the heat gun, you're probably more likely to damage the board than the IC. In a job I worked in 1984-85, I sometimes used an infrared microscope to thermal scan power transistors' uncovered dice (ie, the actual chips) operating under extreme loads, and I've seen them actually operating (not just in storage or in soldering, but operating) at over 350°C. I don't know how far over, because I wasn't allowed to get calibration data up that high. Granted, they would not have lasted long, but it didn't cause catastrophic failure.

Soldering the SOJ's is easy; but first you might have to forget all the conventional "wisdom" about soldering. I describe how to do the soldering with no special equipment, at viewtopic.php?p=48875#p48875 . That's how I soldered the SRAMs on the module you bought. I use a 1/8" chisel tip on the iron. BDD posted a close-up photo of another SRAM done this way. Maybe someday I'll be advanced enough to make a video.

There are a couple of ways to go about it. Both Garth and I (when I was able to see well enough) use a drag technique that doesn't try to avoid bridges. You can clean them up afterward—I used desoldering braid, Garth does it with heat and gravity.

The soldering iron tip shouldn't be very large (I used a 3/32" tip, which is actually a 1/8" tip I ground down slightly) and you want it good and hot so it will maintain temperature while in contact with the pins. I applied some liquid flux to the pads prior to placing the part, but that isn't essential—it mostly helps to keep the part from moving around. I also clamp the PCB down to the bench so it's not wiggling around and making things difficult. Just keep the tip clean and well tinned as you work so you get good wetting and flow.
Here's the close-up picture to which Garth is referring.

Thanks for the pointers gents. I re-read your instructions Garth, and made several attempts, but somehow it didn't work out. I can't seem to get reliable wetting of the pads with the bigger tip not matter how much solder I apply. My local electronics store had only a 1/16" tip, which seemed close enough, so I thought I would pick it up and try it. I wondered whether there would be enough thermal mass there to transfer heat from the iron, but it seemed to be fine. I had no trouble heating the pads with it, and managed to get the solder to flow nicely. Dragging worked very well with some flux added, and hardly any bridges were created. I found I could just reflow any one pad to tidy things up most of the time. A braid was only required once or twice. In the end, I was quite pleased with the result: Yup, exactly what I did. Wouldn't you know it ... I tore out a corner pad on the UART footprint when trying to remove the IC off the board after a failed attempt. I also lifted a second pad right next to the first but found it was still attached to the trace, barely. Yikes! It looked very nasty and I was a little despondent thinking the board might be ruined. But I decided to try a rescue mission instead ...

Some googling revealed a video on PCB repair, which seemed promising. I soldered the UART in place despite the damaged pads, and then used an sharp blade to scrape off the solder mask from a via next to the corner pin. I then ran a jumper to connect the pin directly to the via. The lifted pad was also a problem, so a jumper was required there as well. The missing corner pad is just visible (as a brown spot next to the pin) in the pic below, as is the jumper going from the pin to the via right next to it. The jumper on the second pin is harder to see, but I'm happy to report that both connections are solid and seem to have no shorts. And that's the last of the components on the SBC in place now. Happily the RAM seems to work properly (the IC was not in fact damaged, just as Garth had predicted). The next step is to get the UART working (I'll be referring to BDD's several helpful posts on the subject for that) and perhaps write a little basic monitor - the objective being merely to enable the SBC as a test harness for the TTL CPU. Looking forward to that!

Cheers for now.

Not bad at all, especially for a first try. That's better than how I did when I tried my first SOJ part.
I've almost got the first "white paper" on interfacing an NXP UART to a 65C02 or 65C816 ready for publication. Some proofreading remains to be done and then I'll add it to the topic I started. Obviously, you are already past that stage. The second paper will cover the software side of things.

Thx BDD. The various pointers you and Garth provided were very helpful. I did require a smaller tip (1/16"), thin solder wire (0.02"), and extra flux to make it work (not to mention plenty of magnification), but I can imagine it gets easier with practice. Ironically, the TTL CPU itself doesn't use any SOJ packages, so it's definitely easier sailing from here .
I saw that this was up, thank you! I read it with interest, as well Garth's RS-232 primer. I recall hooking up a 3-wire serial connection to a Televideo terminal back in the day, and mixing up pins 2 and 3. Of course, I managed to get it wrong once again now on the SBC's DB9 ports: thinking I would use use this adapter cable, I reversed pins 2 and 3 (RXD and TXD) but NOT pins 7 and 8 (RTS and CTS) - no man's land. Looks like I'll need to wire up a little custom adapter ...

That adapter is wired as a DTE. What I usually suggest is to wire your 6502 contraption as a DTE and use a null modem cable to link it to the other device.

Thanks BDD, that would have made more sense for this SBC as well. I am making a note of various changes to the schematics as I go, so I'll add this to the list! In the meantime, I cooked up a simple custom cable: straight-through for pins 3 & 4, and crossed-over for pins 7 & 8. After tinkering with the thing this weekend - yowza! Got something going ...There's not much there in terms of software at this stage, and the whole thing seemed a bit flaky for some reason. But as usual, I'm just amazed at how many things had to go right in order to get even this simple test going. I ran the serial ports at 1200 Baud just to make sure the hardware flow control is working, and it certainly appears to be. I managed also to get the UART's internal timer to trigger a regular 60Hz IRQ. As luck would have it, the UART's independent clock means that the frequency of the IRQ is constant and immune to the wait states afflicting PHI2 on this SBC. Currently, the IRQ simply increments one of the VIA output ports just so I can see the pins blinking correctly.

I might spend a little time writing a simple monitor, for old times sake mostly. Many years ago, I wrote an XMODEM implementation and a simple BIOS on an Apple ][e (I vaguely recall the application didn't leave enough room in memory for Apple DOS so I had to write something small and simple to talk to the floppy drive and transmit data through a modem - can't remember what the application was for though ). Incidentally, I really like the SC26C92's 8-byte FIFO and interrupt scheme. It looks like it could support some multi-threaded I/O, which would be very cool, especially in combination the TTL CPU's segmented memory and dynamic microcode switching. Lot's of fun.

BDD, I'm looking forward to the next installment of your UART article on the software side of things. Maybe it will help me shake out the flakiness I'm seeing currently ...

Cheers for now.

It's all part of the learning experience.
"Houston, we have lift-off."

You've leaped a major hurdle by getting your machine to scribble on the screen. As you noted, seeing that display tells you you've got functional hardware and a lot of the things that could go wrong didn't.
I'm curious as to your choice of 60 Hz.
You'll like the 28L9x's 16-deep FIFO even more. A lot fewer interrupts to steal time from the foreground task.
I hop to get rolling on it this week—the entire weekend was taken up with music activities, so no computing work got done. As you will see, there is a certain feng shui, for lack of a better term, to setting up and driving the NXP UARTs, especially the multi-channels ones.

Ha, so exciting! Thanks BDD. The SBC has several patches and hacks now, but otherwise seems to be performing nicely. I plunked in a 40MHz oscillator just for kicks, and I'm happy to say the thing runs off the divide by 2 flip/flop very well at 20 MHz. Ironically, the ROM wait-state mechanism tops out at 15MHz currently (I somehow neglected to account for the tpd of the additional gates for the Step and Manual clocks - I'll have to patch that somehow). For now, I'm using the SLOW clock to copy a test program to RAM and only switch to the FAST clock thereafter, and I can still use the single-stepping features as needed for debugging. Everything to this point suggests the SBC will be a great platform for testing the TTL CPU, even at top speed!
No strong rationale really. I just recall that the C64 had a 60Hz "raster IRQ" which was commonly used to time screen refresh in games. I also used it to trigger movement, animation and collision detection, so it's a very familiar interval. I didn't realize it then, but that means everything I did would have played very differently in Europe than in North America! And yet we tuned the speed of the games ever so carefully - crazy kids. I think I recall seeing a 100Hz IRQ in your POC 1 design, which is a nice round number (EDIT: which looks to be used for an uptime counter. Nice idea).
Agreed. I'm excited about this kind of thing. I can imagine effectively 'scheduling I/O" to occur and enabling the task to continue, or better yet switching to another task while the first waits for I/O. Some fun possibilities here, and all would be made more effective by larger FIFO.
I'm going to try a few experiments and see where I get to. I did find configuring the UART to be quite touchy, but I need to dig a little deeper. Ideally, I can get a simple download from the PC going so I can stop re-burning ROMs quite so much!

I use the same rate, and the IRQ\ output of VIA#1 (whose timer causes the 100Hz interrupt) is the only thing on the board that's on NMI\. There's no polling, because there's only one possible cause. (T1 timeout is the only interrupt enabled in that VIA.) The NMI ISR runs the clock and calendar, and alarms. Nothing else. Multiple programs can refer to it though for a wide range of things.

Actually, it was the C-128 that had the jiffy IRQ generated by the VIC through a raster interrupt.

In the C-64, timer A in CIA number 1 generated the jiffy IRQ. As the timer rate is ultimately slaved to the Ø2 clock rate, Commodore used a Ø2 rate in the C-64 that was almost evenly divisible by 60 or 50 so the IRQ would maintain reasonably accurate timekeeping (which it didn't—BASIC's TI and TI$ clocks routinely drifted to where they were useless). It was possible to configure the C-64's VIC to generate a raster interrupt, but that feature was mostly used to produce the illusion of more sprites on the screen or to toggle the VIC between bitmap and text mode when the scan reached a certain raster line.
Correct, also used in POC V2. The 100 Hz jiffy IRQ is the system time base that maintains the uptime counter, a UNIX-like time-and-date counter (starts at midnight October 1, 1752) and a user-programmable time delay function. The jiffy IRQ is generated by the DUART's counter/timer running in timer mode. I chose 100 Hz so I could get 10 millisecond resolution if needed.
There's also an NXP DUART, the SC28L202, with 256-deep FIFOs. I've skimmed the data sheet but haven't given any thought as to how it would be interfaced to the 65xx buses, although it does appear to be similar in that respect to the 28L92, but with more pins. Speaking of pins, the 28L202 is only produced in a 56 pin TSSOP package, which would represent a significant assembly challenge, at least for a blind old man such as me.
Setting up the UART is a bit tricky if you don't have complete understanding of the data sheet, an achievement that is in itself a challenge—NXP's expertise is in designing UARTs, not writing about them. I experimented a lot with the setup algorithm once I got working hardware going and came up with a method that seems to be foolproof and relatively easy to modify if changes to device operation are necessary.