6502.org

Here are some more pictures of my first-design POC computer:

• PCB with SRAM and glue logic installed. As can be seen, I wasn't stingy with the decoupling capacitors.
  
  PCB undergoing initial testing.
  
  My technically advanced test setup. I use an old Antec PC power supply as the power source. The power input connector on the PCB is a standard Molex part used on 5-1/4 inch disk drives. In this view, I have the 'scope and DMM connected to the /RESET line to observe its behavior.
  
  The Ø2 clock signal as seen on my ancient Beckman Industrial 20 MHz 'scope. The 'scope is set to 0.1 volts/division, with the probe set to 10:1 attenuation. The display clearly shows that the Ø2 signal is flipping between 0 and 5 volts, just as it should be. The slight distortion of the square wave reflects the bandwidth limitations of the 'scope. Whaddya expect from something that's older than dirt and still has the original CRT?
  
  The fully populated PCB ready for launch.

The next step will be to burn an EPROM and see if the MPU can execute some instructions. Initially the EPROM will be nothing more than:
which should be sufficient to check for the presence of activity on the buses. If that test fails then I'll have to use a NOP generator to see why things aren't working. Otherwise, I will burn more complicated code into the EPROM to generate a display on a terminal screen.

Speaking of EPROMs, here's what I use to erase them. This device, of course, represents a significant financial investment:

• EPROM Eraser
  
  Close-up of the EPROMs awaiting their lethal dose of UV radiation.

This rig will erase a whole bunch of EPROMs in a little more than 10 minutes. The white background in the first picture is actually the protective cover that I place over the eraser to avoid stinking up the place with ozone and developing a mid-winter suntan. The eraser is nothing more than an old under-the-cabinet kitchen light fixture fitted with an antiseptic UV fluorescent lamp. I modified the fixture to increase the space between the lamp and the fixture housing so there's sufficient room for the EPROMs. As can be seen, a lot of EPROMs can be erased at one time with this contraption.

In keeping with the general motif of this device, I use, of course, a cheap kitchen timer to tell me when the erasing operation is done. Some day I might actually get fancy and rig up a timer to automatically turn it off for me.

Progress is being made.

Connected to a Wyse 60 Terminal

Banner Display Following Power On

BTW, that power-up display is via buffered, IRQ-driven code, with the serial port running at 38.4 Kbps, which is as fast as the old WY-60 can go. The DUART can do 115.2 Kbps, but I don't have anything that can run that fast. Now I need to get to work on a ROM that can do more than just write to the screen and read some typed characters.

Nice! And you kept all the smoke in!

A list of inexpensive places to get PCBs from. When I've specified two countries, the first is where they are based, and the second is where they fab their boards.

• BatchPCB - Reasonably cheap 2 & 4 layer prototyping, though expensive for large boards. Slow. [US/CN]
• Gold Phoenix PCB - Have a number of low price specials, useful for getting multiple copies of a PCB. Do 1, 2 and 4 layer boards. Also accept some PCB software's files directly. BatchPCB actually manufactures at Gold Phoenix by agreement. [CN]
• Olimex - Reasonably priced but generally have less features than above; Chinese manufacturers will generally offer a better price per unit (but in higher quantities). [BG]
• PCBCart - Another Chinese manufacturer. Offer a ridiculous number of features - this may make placing an order difficult. Have a per design setup fee. [CN]

Both BatchPCB and PCBCart are fully automated services. In PCBCart's case, the website contains a sizable quantity of Engrish, which may make some things incredibly confusing. Olimex and Gold Phoenix handle orders by E-Mail, and can generally offer sane defaults. As I've never dealt with either (I'm going off information I've gleaned)

BatchPCB, as a low cost service, does only limited testing of the boards - you will want to perform some testing of your own when they have arrived. On the other hand, if Gold Phoenix have to re-run the panel because of some defective units, expect extras.

I only have first hand experience with BatchPCB (Though my boards haven't arrived yet - Gold Phoenix are closed down till Jan 03), which has been pretty pleasant. I've possessed boards made by all of the above for others in the past, though note the complexity of the Olimex board was limited (It was single sided for a start). A friend of mine has raved about PCBCart, and a bunch of people have been happy with Gold Phoenix. I haven't heard much about Olimex' service as of late, but it was reputedly good in the past.

What you didn't see was the big exhaust fan that I cropped out of the pictures.

Actually, there was one boo-boo. As I was laying out the PCB I neglected to connect an address line to one of the gates. Everything worked except the 'AC138 decoder, which wasn't responding to any activity in the $D000 block. A short piece of wirewrap wire took care of that.

Now that I have working terminal I/O I can get busy with working on getting the DS1511 watchdog timer (WDT) running. As usual, Maxim's app notes leave something to be desired in clarity.

I want to have the WDT generate an IRQ at 10 millisecond intervals. Initially, all the IRQ will do is run a simple 32 bit counter, incrementing it at one second intervals. The problem with the Maxim docs is that they don't make it clear as to exactly what happens when the WDT underflows. It supposedly sets a register flag and depending on how the part is configured, generates an IRQ or pulses a reset line (which can be tied to the MPU's reset). It's not doing either, according to the logic probe.

I know the IRQ works on the board because terminal I/O is IRQ-driven. Therefore, I have to presume that I'm not correctly configuring the part. However, after reading the DS1511 data sheet until my eyeballs are cubical, I can't determine what I'm doing wrong. Guess I'll have to resort to contacting Maxim's tech support and see what they have to say about it. <Sigh> I recall having this same problem with the 1216E smart-watch years ago and it turned out to be nothing more than some missing info in the data sheet.

I use ExpressPCB. They always meet their delivery commitments and in the nearly 10 years I've used them, have only once delivered a faulty board (a component through-hole was filled with reflow). Depending on what I am ordering, EPCB isn't always the cheapest, but I weigh cost against quality and service. As is usually the case, you never get more than what you pay for. In the case of some of these Chinese board houses, the quality and service are not to my standards.

I have two simple problems with ExpressPCB:

• They require you to use their own software
• They can't generate industry standard Gerbers

As for quality... Well, both PCBCart and Gold Phoenix' produce PCBs of the same quality as ExpressPCB, and I know that Gold Phoenix will bend over backwards to help you. As long as you remember that, yes, they aren't native English speakers and therefore there are going to be some communication issues, it's no different from doing business with anywhere else in the world.

Edit: In related news, BatchPCB just shipped my PCBs.

PCB Express in Oregon (similar name, easy to confuse, http://pcbexpress.com/ ) is good too, inexpensive, and they take standard Gerbers, unlike ExpressPCB in Santa Barbara, CA. Recently I've used Imagineering at http://pcbnet.com/ and was pleased.

Another place I've heard good things about is PCBPool, who I would choose if I wanted a short turn around time (They have the advantage of having a fab located in the UK with me, so postage would be lower and faster). Their prices seem competitive with the ExpressPCB miniboard service. They're slower, but again more flexible, and they'll throw in a free solder stencil (For anyone who wants to reflow their boards).

They work out slightly more expensive than ExpressPCB - but - they offer the option of ordering only a single board

Definitely good resources. Always been using Express PCb, got certified in a job forPADS but can't afford it and am having lots of fun with Kicad which I swear by now for Gerbers. If only it had some good 6502 libraries (making my own as I go along, and yup, will release to here)

Got that issue put to bed and the WDT is generating IRQs at a 100 Hz rate. The ROM's IRQ handler now has a simply 32 bit jiffy clock running. I have it rigged up to send a BEL character to the terminal at one second intervals to tell me it's working. That incessant beeping, however, can get a bit annoying...

Where were you able to souce 10GHz 65816s to keep up with the watchdog?

Simple! I overclocked the daylights out of the 14 MHz parts I have here.

That was supposed to be 100 Hz. I fixed the post.

Okay, I figured that there had to be at least one hardware bug somewhere in the POC V1.0. Sure enough, I seem to have found one. It's kind of hard to explain...

Early in the reset handler, a bunch of parameters are written into the DUART registers. For the first version of the ROM, I just did a bunch of LDAs...STAs, figuring I'd devise a more elegant method later on. After getting all that EIA-232 stuff running to where I could do reliable CBAT I/O, I decided to clean up the DUART setup code by use of a pair of data tables, one a list of parameters and the other a list of the corresponding registers into which the parameters are to be written. A simple loop took care of everything.

Well, imagine my surprise when my new, improved DUART setup routine didn't work. Depending on the speed and direction of the wind, phase of the moon and the state of the economy, either the system would not boot at all, or it would come alive but random drivel would be scribbled on the screen. The behavior seemed to change each time I pressed the reset button.

Thinking the ROM was whacko, I burned a new one and manually verified it against the code buffer. I plugged it in and got the same results. I put in the last good ROM (the one with all the LDAs...STAs) and the POC fired up without a hitch. Okay, I had to have somehow made a serious coding error, as it was clear the DUART was being improperly set up. I must have stared at the code and data tables until my eyes were triangular, but could not see anything wrong. The code loop looks something like the following:
The time delay, by the way, takes care of the case where consecutive writes are made to the same register—in some cases, a delay is necessary to give the DUART time to react to the effect of the previous write.

Anyhow, if you can't see anything wrong with the above loop, it's because there is nothing wrong. I ran that code in the Kowalski simulator, step-by-step, and verified each register and parameter against what I knew worked. All was okay. Then it hit me. The only thing really different was that I was writing to the DUART using indexed addressing, whereas previously I was using absolute addressing. It seemed that the STA DEVICE,X instruction was malfunctioning.

To verify my suspicion, I wrote the following linear alternative to the above loop and burned it into another ROM:
The results were the same: garbage on the screen, more garbage when typing, etc. It was patent that STA DEVICE,X was either writing bogus values into the DUART's registers, or was writing good values into the wrong registers.

Now here's the fun part: I was already using the loop and data table method of setting up the watchdog timer (WDT), which works fine. It's supposed to generate an IRQ 100 times per second, and according to the scope, it does. Unlike the DUART, the WDT has no problems with consecutive writes to the same register, so there's no 10 millisecond delay involved. So STA DEVICE,X per se isn't the culprit, only the way in which the DUART reacts to it.

I have a vague idea as to what may be going on here, but haven't gotten it to fully gel in my mind as yet.

At first, I thought your code might have had an off by one error. In an attempt to locate it, I annotated your code with proof assertions. However, not taking the effects of the tmstd procedure into account, I've succeeded in proving the freedom of bugs of your loop code.

Is it possible to post the code for tmstd as a next step? Process of elimination boils things down to either hardware bug or a bug with tmstd.