Dan's 6502 build, aka, The WOPR Jr.

[Dan Moos]

Sounds like I've fallen with some crochety old farts I hope so. Thems the kinda folks you learn from!

[GARTHWILSON]

GaBuZoMeu wrote:

Add a pushbutton to your arduino (well debounced of course)

The key debouncing can be done in software, to simplify the hardware. OTOH, if you don't have the experience with software to get that going easily, maybe hardware is best (an RC followed by a Schmitt-trigger inverter for example).

Quote:

When the programs becomes more complex, single stepping is usually not helpful.

Totally agreed. The usefulness is gone when you get to where you have to single-step hundreds, maybe thousands of times to get to where the problem shows up. Then suppose you realize the problem started happening several steps earlier, but you can't back up.

Dan Moos wrote:

Dumb question...Do I just tie the WE pin HIGH on my 28c256 EEPROM? Seems like the thing to do.
<snip>
That clarified, a simple wire tying WE HIGH is what I want, right?

You can use the circuit at http://wilsonminesco.com/6502primer/pot ... ml#BAS_CPU, paying attention to note 6 about JW3 particularly if you want to write to the EEPROM in-circuit. If you do write to it in-circuit, you'll want to have some degree of safeguard that you don't accidentally overwrite you monitor or accidentally do any damage that's hard to recover from.

Quote:

Another question. I'm getting close to the next major test phase. I have both buses, the memory, and the decoding logic just about complete. I kinda want to test all that before I start talking to the VIA. I figure I need to hand enter something really simple into the ROM that does something with the data bus that I can confirm on my Arduino terminal connection.

Since I'll be entering this thing in machine code, it needs to be super simple. Any ideas for what I can tell the thing to do that basically tests RAM and ROM?

The debugging chapter of the 6502 primer relates: http://wilsonminesco.com/6502primer/debug.html

Quote:

Also, what is the standard easy [way] to code a delay? Some sort of loop full of NOPs? I was thinking a simple test would be to blink some LEDs. I can clock the CPU with my function gen to slow it down, but when it's running on the crystal oscillator, I'll need some delay if things are to blink at human speeds.

Something like:

Code: Select all

DELAY:  LDY  #$FF       ; Put the desired value in X before JSR'ing to DELAY.
 d1:    DEY
        BNE  d1
        DEX
        BNE  DELAY
        RTS
 ;-------------

If I calculated it right, the delay in cycles N, including the JSR & RTS, would be 1283X+13, so the value in X when you call it should be X=(N-13)/1283. So if you're running at 1MHz and want a 100ms delay (ie, 100,000 cycles), (1E5-13)/1283 is 78, or $4E. Getting it exact is seldom necessary though. If you need to preserve X or Y, you can push them onto the stack before, and pull them back off after.

Quote:

Yeah, it would be like a poor man's harddisk. I can definitely see the advantage. It's the big picture plan, but my attitude is as little plumbing, no matter how trivial, until she's running.

Then after you do get it going, a poor man's hard disc could be something like the 26VF064 8MB SPI serial flash in an 8-pin SOIC, and if you want it removable like an SD card, you can use my tiny hobbyist-friendly SPI-10 boards shown in the middle of the front page of my website. Yes, it takes some code for the driver, but it's much, much simpler and easier to understand than doing an SD-card driver. If doing file system is too complicated, you could just keep track of what files start at what addresses on which tiny memory modules, like we used to do with cassettes on Apple II's and C64's before the disc drives were available and affordable.

[GaBuZoMeu]

barrym95838 wrote:

Dan Moos wrote:

Someone mentioned that my star scheme with the data bus could cause problems. Care to elaborate?

I'm interested to hear the theory behind this as well. I'm mostly a software guy, so I have nothing much to contribute, just curiosity.

Mike B.

Well, this is theoretical stuff about transmission lines, signals and impedance (mis-)matching. A very simplyfied view:
You have a signal generator (e.g. your oscillator), a transmission line (copper wires with more or less ground return), and an end of the transmission line (whether there is something connected or not doesn't matter now). A rapid signal transition from the generator is coupled into the transmission line, travels along it and reaches the end where it should be terminated. This will work perfectly if (and only if) the generators source impedance, the TL impedance, and the terminating impedance matches precisely. If there are mismatches a more or less amount of energy is "reflected". That is, a fraction of the signals energy (may appear either as voltage or current) travels back to the generator where it causes an additional load which in turn causes distortions. The amount of energy that is reflected depends on the mismatch. Worst cases are open end and short circuit - both causing 100% reflection (theoretically, omitting the influence of ohmic resistance). The faster the rise and fall times are and the longer the TL is the more curious distortions will appear.

Now to the question bus vs. star:

The bus looks like: GEN - TL - RCV1 - TL - RCV2 - TL - RCVn
Because all intermediate receivers are only light loads the amount of impedance disturbance is small, and therefor they do not cause much reflections. Furthermore the reflected energy may travel along both TLs (backward to GEN, and forward to next RCV). Only at the end RCVn needs to be well matched, otherwise that reflection travels back and may ruin the signal.

In a star like connection ALL receivers are at the end of a short TL. That means ALL require well matching otherwise ALL will reflect some energy. And the sum of all reflections will bang back at the generator. If they were in phase, this could be very ugly.

With older LS-TTL logic you have slow rise and fall times, relative high source impedances, and relative low receiver impedances. So the mismatch wasn't very strong, usually a series resisitor near the generator sufficiently increases the source impedance and damps reflections (at least for a moderate line length). But modern AC-MOS has a very low generator output impedance and a very high input impedance. So the "natural" mismatch is ways higher. Additionally rise and fall times are much faster. With modern AC-MOS it is much more difficult to tame the signals especially those that are widely distributed.

Hmm, I hope this was not too academic

[BigDumbDinosaur]

Dan Moos wrote:

Yeah, but the "toys" are sort of a subset of the hobby. Most of my testing so far has been with a DVM checking for ones and zeros. But watching things on the scope from a fun standpoint is a pretty neat thing. I know my learning curve skyrocketed when I started using one. Everything I'd ever read was right there to be seen!

No question that a scope can be useful. I have a nice 275 MHz H-P scope on my bench. Strange thing is I mostly look at audio stuff with it. I have connected it to my POC contraptions on occasion to observe signal quality, or lack thereof, but with one exception, have not used it to actually debug any computer hardware.

Quote:

Sounds like I've fallen with some crochety old farts I hope so. Thems the kinda folks you learn from!

I'm more curmudgeonly than anything else, although I have been known to break wind with gusto.

I started working with electronics at a time when the RCA receiving tube manual cost a US dollar, was two inches thick (in paperback) and no electronics technician worthy of the name would be caught dead without one. Things have changed a bit since then, but not the underlying physics. And I still have my receiving tube manual so I can stay fresh on the technology of yesteryear when it comes into my shop (meaning the occasional tube-power instrument amplifier in need of repar).

[Dan Moos]

My intro to the hobby was tube guitar amps. I actually have a 60's era ( if I remember) RCA manual! It's actually still handy. I also have the Radiotron Designers Handbook 4th edition that is the go-to tome for valve stuff. Thing's like three inches thick. Not sure how they got "Handbook" out of that! I have an older edition that's a lot thinner, do maybe that's what happened.

[BigDumbDinosaur]

Dan Moos wrote:

My intro to the hobby was tube guitar amps. I actually have a 60's era ( if I remember) RCA manual! It's actually still handy. I also have the Radiotron Designers Handbook 4th edition that is the go-to tome for valve stuff. Thing's like three inches thick. Not sure how they got "Handbook" out of that! I have an older edition that's a lot thinner, do maybe that's what happened.

That RCA manual has a circuit in it that I built while in high school. It was an audio power amp good for about 45-50 watts RMS, using 7027A tubes in the output stage. I built two for my stereo, with each amp sitting on the floor behind a speaker enclosure.

Not too long after I built those amps, I was given some Sylvania 8417 beam power tetrodes by an uncle who was a partner in a company that built and installed PA systems. With a little help from my high school science teacher, who was an audiophile who built some of his own stuff, I came up with a circuit that would produce 100 watts RMS into an 8 ohm load. I built two such amps for my stereo and then built another pair for a buddy. I used those two amps until 1984, when I replaced them with a Dynaco 400 watt solid state power amp.

Ah, the good old days, when the stereo not only reproduced music, it helped keep the house warm in the wintertime.

[whartung]

GARTHWILSON wrote:

Quote:

When the programs becomes more complex, single stepping is usually not helpful.

Totally agreed. The usefulness is gone when you get to where you have to single-step hundred, maybe thousands of times to get to where the problem shows up. Then suppose you realize the problem started happening several steps earlier, but you can't back up.

When I was debugging my Forth, the single stepping capability at the CPU quickly became pretty useless as it was far too low level. You spends zillions of cycles in NEXT. You need Forth to debug Forth.

I ended up adding features to my simulator to trap and trace memory access to specific locations. But that's a lot harder to do on hardware. But then, this could suggest that perhaps you may have better luck debugging software on a simulator before it even gets to the hardware (for such things that are able to be done correctly in the simulator).

Also, don't be afraid to wire up LEDs or suck and use those as debug traps in your code. You can use those as indicators of where the code goes, until you get your serial port working, then you can just spit stuff out to the console stream.

[floobydust]

BigDumbDinosaur wrote:

Dan Moos wrote:

My intro to the hobby was tube guitar amps. I actually have a 60's era ( if I remember) RCA manual! It's actually still handy. I also have the Radiotron Designers Handbook 4th edition that is the go-to tome for valve stuff. Thing's like three inches thick. Not sure how they got "Handbook" out of that! I have an older edition that's a lot thinner, do maybe that's what happened.

That RCA manual has a circuit in it that I built while in high school. It was an audio power amp good for about 45-50 watts RMS, using 7027A tubes in the output stage. I built two for my stereo, with each amp sitting on the floor behind a speaker enclosure.

Not too long after I built those amps, I was given some Sylvania 8417 beam power tetrodes by an uncle who was a partner in a company that built and installed PA systems. With a little help from my high school science teacher, who was an audiophile who built some of his own stuff, I came up with a circuit that would produce 100 watts RMS into an 8 ohm load. I built two such amps for my stereo and then built another pair for a buddy. I used those two amps until 1984, when I replaced them with a Dynaco 400 watt solid state power amp.

Ah, the good old days, when the stereo not only reproduced music, it helped keep the house warm in the wintertime.

The good ole days are still here, at least at my place. I still use a lot of vacuum tube gear which I've designed and built myself... and yes, spinning vinyl is a requirement as well. I also have the RCA Radiotron Handbook (a thick one) plus numerous tube data manuals and more. I also have my original copy of Jack Darr's Guitar Amplifier Handbook, which has hundreds of classic schematics.

Tubes I have good stock of today are all NOS and include KT88, EL34, 6550, 6L6GB and GC, 5881, EL84/6BQ5 and a nice quantity of vintage DHTs, including 71A, 45, 2A3 and WE300b triodes. I also have good stock of rectifiers and smaller tubes for input/drivers and phase-inverters. And no... none are for sale. I've been collecting these for over 4 decades and they will be handed down to my kids and their amplifiers/preamps, etc. as needed.

Not to be one-sided, I also have a fair amount of solid-state gear but I stopped doing design/build on that back in the 80's, preferring to buy specific pieces, mostly A/D-D/A units, Genelec monitors and audio interface cards to external converters. Funny how so many of us have the overlap into other electronics based hobbies

[Dan Moos]

Ok, back to build.

I have gotten to the point where I'm trying to output a pattern on the VIA ports that I can probe. Nothing comes out, but I did find what I think is a problem.

The following scope shot is the CS2 pin on the VIA. I'm at 1V/10ns per division. Its just a quick blip! By comparison, the CS1 pin goes HIGH for 3us, which sounds about right.

I have activity on all the pins I'd expect, and so far this is the only signal that looks suspicious.

I'm using the first decode circuit on Garth's primer. all connections seem good, and the meter says I have continuity. On the scope, the CS2 goes LOW at the same time the CS1 goes HIGH. This tells me at least that portion of the decoding is good. Also, since the VIA is being selected at regular intervals, along with all the other activity, I feel that my program is running (it is an endless loop of setting the VIA ports, and yes, I set the DDRs to all ones). If my program is running, then that means ROM addresses are being decoded too.

So I'm pretty shir that skinny pulse is my problem.

Ideas?

[BigDumbDinosaur]

Dan Moos wrote:

The following scope shot is the CS2 pin on the VIA. I'm at 1V/10ns per division. Its just a quick blip! By comparison, the CS1 pin goes HIGH for 3us, which sounds about right.

Have you posted a complete schematic of your machine somewhere? I don't recall seeing one. It's going to be kind of difficult to help you troubleshoot this problem without a schematic.

[Dan Moos]

Yeah, that's probably a good idea.

Coming soon.

[Dan Moos]

Also, it is some sort of decoding error I think. A14 should go HIGH and A15 should go LOW every VIA access. I only have A14 going HIGH when A15 is HIGH. What I think is causing the short pulse is that the NAND gate that selects the VIA is getting a nearly, but not perfectly simultaneous LOW and HIGH at the same time, and that the sight delay briefly allows a short output.

That would just be a symptom though. Those signals shouldn't be doing that.

I will try and post a schematic soon. I'm actually really similar to the schematic Garth has posted on. 6502.org. In fact, I'm not sure if they have any differences.

But yes, I'll create one and post it.

[Dan Moos]

OK, semi success!

The original problem was that in the melee, I'd over written the crucial part of the ROM that tells the thing what to go do with itself when it turns on. Fixed that, and BAM, output on the VIA!

It's strange though. I put $AA on both ports, which to me should be 10101010. I get 01010101. Both ports have this. I'm gonna Change the desired output and see what's up. Maybe all ones to one port, all 0s to the other.

Standby

[Dan Moos]

OK, definite success. I tried outputting various bit patterns on the VIA, and anyways got what I expected.

Of course I haven't tried a RAM operation yet. I guess I'll put some byte in RAM, retrieve it, and output it. Maybe do some math on it. Just to prove its working.

Actually, I really should go to bed.

Good night all!

[Dan Moos]

Having great success. I wrote a simple program that puts a number in RAM, adds to it, and outputs the result on port A of the VIA. I figure that simple operation proves out my decoding, and that I got my RW pins right. It works as it should, so I think I'm in good shape.

Here's a current pic. My wife was unimpressed with the two lit LEDs, but I'm ecstatic because they meant my computer added 1 +2 successfully