6502.org

On the good advice of others here, I will now be posting my progress on one thread. I also decided to name the thing, and I suspect anyone around here will get the reference. (Heck, it's probably been used already!)

OK, in the spirit of one stop shopping to find info on what I'm up to, here's the current plan:

Simple 65c02 build, initially on a breadboard. 1 MHz.

6522 VIA

6551 ACIA. I currently have the buggy WDC part, but the improved Rockwell part is in the mail.

32k SRAM

32k ROM

Garth's simple single 7400 based address logic. (I prefer the simplicity over the slightly wasted memory for now)

FTDI chip to get the UART talking to my PC.

My future "stuff I wanna do when I am smart enough"

On board video processing with composite out

On board keyboard processing, hopefully period accurate, but that's not a necessity.

Here's the buggy that will really stretch me. I want to write some sort of compiler/assembler/interpreter (one of the three) for the thing. I love the idea of using an assembler I wrote on hardware I built. I think it would require a pretty well rounded knowledge, and thus would direct my learning in all the right places.

Here's what I have so far. Just the data bus is hooked up. The ribbon cables are all custom made by me so I can have the lengths I want.

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.

OK, trying to do a single step NOP test.

I'm not entirely sure how to set this up. My gut says the thing needs to free run for a few cycles at start up. It's this true?

My set up is as follows:

CPU with $EA hardwired to data bus.

IRQ held high thru 4.7k pull UP.

RST held HIGH through a 4.7k pullup on a switch that switches it to LOW. 10uF cap from RST to ground.

Arduino with the lower 8 bits of the address bus on 8 of its digital inputs. I read the inputs, store them as a byte, and send this to the serial terminal. Tested, and my code/hookups are right (I tested it with hardwired numbers to the inputs).


Output from Arduino to Ph0 pin that is set HIGH.

Arduino also has a software debounced switch, that when pressed, causes the Arduino to bring Ph0 LOW, then high again as fast as it can. On the scope, this pulse is pretty clean, and has a width of ~5.4us.

I write the contents of the address pins ( the lower 8 bytes anyway), to the terminal.

OK, should this work? I do get changing data on the address bus, but no noticable pattern. Also, I'm not certain that I should be able to single cycle the thing right away without letting it free run for a short period to set-up.

As far as I can tell from tests outside the CPU circuit, my Arduino code and hookups are correct. Also, $EA is verified on the data bus with a multimeter.

Thoughts?

Also, I do get a pulse on the Ph2 pin. It is identical, and perfectly in phase (as per the scope's phase measurement function) with my clock pulse. It is actually prettier (almost no ringing).

I also get a nice signal on the Ph1 pin. It appears identical, and 180° out of phase with the clock.

Hi Dan.

I seem to recall you need at least two PHI0 clock cycles while the 65C02 is held in reset. I suspect that's why I drove the 65C02 'reset' line from the PIC microcontroller when I started my research several years ago. I'll try to find the reference for you.

Cheerful regards, Mike

<added>
Both the W65C02 and the R65C02 Datasheets mention "two clock cycles" in the description of the 'reset' pin.

Successful NOP test! I think I was using an online example that didn't use a WDC part. Also I was looking at an original MOS pinout diagram. Doh!

So long story short, I started reading the actual WDC sheet, and find out about things like the bus enable pin and the ready pin. So I put pull ups on those, and voila!

So then I unhooked the crystal, and used my function gen as a clock source. Still good. Next, I set the function gen at 5 Hz. Yup! still good, and now I can actually read the output on the terminal screen. Sho nuff, its counting up!

So next I re instated my single cycle setup. BAM! Works a treat!

Such a simple milestone, but if dumb mistakes make it take all day, it sure is nice when it finally works.

Celebrating with a nice Deschutes Black Butte Porter.

Just for your future reference, the two clock outputs of the 65C02 are meant to allow the 'C02 function in a circuit that originally had an NMOS 6502. WDC does not test these outputs, doesn't quote any timing values for them and does not recommend their use in new designs (see pages 10 and 26 in the data sheet).

You can achieve the same pair of clock outputs with the below circuit:
This circuit offers several benefits:

2. The output is symmetric. Use of a symmetric clock becomes important as the Ø2 frequency closes in on the MPU's maximum ratings. Jeff Laughton (Dr. Jefyll) has discussion on his website on timing margins and what may happen with an asymmetric clock. There is also discussion on the forum on this topic.
   
   
   
3. The flop drives harder than a typical can oscillator. Stronger drive assures that you have a clock whose amplitude swings essentially from rail to rail.
   
   
   
4. The flop's outputs have very sharp rise and fall times, well within the limits required by the WDC processors. Note, however, that fast transitions can trigger significant ringing. Dubious construction methods will exacerbate this problem.
   
   
   
5. Ø1 and Ø2 are exactly 180 degrees out of phase. Although it isn't likely that you will need Ø1 in a 65C02 circuit, it is a useful signal in a 65C816 circuit that uses discrete hardware for latching the A16-A23 bits.

Ok, I'm doing the address decoding. I plan to keep it simple, so it's either Garth's single 74HC00 example with 16k SRAM, 32k ROM, or the next example with 32k RAM, 16kR ROM.

I'm leaning towards the larger ROM version for two reasons. It can be done on one logic chip, and I think I'll like having lots of room for stuff in ROM.

But I really don't yet have a frame of reference for which resource is more valuable.

Here is what my minimum ROM should hold in my current "dream" for this thing:

A simple monitor
A decent assembler
A version of BASIC good enough for my young son to enjoy
A disassembler (maybe, this one isn't a deal breaker)
A single screen where one can select amongst these options. Not really an OS, just a single menu.

Can that be easily done in 16k of ROM?

Will the typical stuff one runs on such a machine work in 16k of RAM?

Well, on my old SYM-1 BASIC took 8K (no graphics, and a few hundred bytes needs to be added if full trigonometric functions were required). The Assembler/Editor (you need an Editor as well ) called RAE requires 8K again. But there are smaller solutions around here.

The disassembler is something, I recommend to do by yourself! It is not very difficult to write such a program if you start with BASIC (you can use PEEK(address) to step through your source program). This will greatly help to understand everything. Written in assembler a disassembler might be as small as 1/2K, but 3/4K or 1K is pretty easy to schieve. Of course, this will be a primitive one, not as sophisticated as White Flames' one.
Your monitor could print a banner with that contents. Then you "select" one, say starting BASIC. When you finish BASIC you return to the monitor loop where the banner is reprinted.
This could be a problem. You didn´t say anything about your display. A "dumb" terminal might be something your son wouldn´t enjoy that much..

You should also take some thoughts about saving/restoring information/data to/from your machine. This may have an enormous impact to and how all other software will and can operate.

I'm leaning towards an SD card reader, possibly with a MCU as a go between if needed. I dunno, hadn't thought that far. Honestly, the coolest would be to get an old 5 1/4 inch floppy drive, but that's not even on my radar yet. No idea how hard a floppy controller is to do, or how easy is it would be to find a drive in decent condition. Those floppy sounds would sure take me back though...

Display... Yeah , that's a thing for sure.

Sounding like more ROM at the expense of SRAM is the way to go.

So is 16k of SRAM enough for my plans?

My workbench computer uses the simple address decoding, so I have a 32KB EPROM and 16KB of useful RAM space. The EPROM is about 3/4 full IIRC, and I've never needed nearly as much RAM as I have for program space, but sometimes it would be nice to have a lot more—many megabytes—for data. (Actually I do have that capability offboard, but access to it is very slow.) What I have in the ROM however is a rather full-featured Forth which serves also as a monitor, assembler, and other things; and once you have such a Forth in place, user programs are very memory-thrifty.

The EPROM is in a ZIF socket, so it would be really quick to change it out for different projects if necessary. (I've never needed to change it out though, since everything I need is there.)

EhBASIC might be a great thing to have in your EPROM. I haven't used it, but when I looked over it years ago, it looked really good considering the memory map it had to fit into.

Once you have a quick storage media you would appreciate more RAM . As long as it takes minutes to load something you would appreciate ROM

If you plan to have a VIA or something equivalent, you might use one or more of its outputs to select a portion of your ROM. This way you could have 32KIB RAM and much ROM.

Say you use a 128KiB EPROM you have 8 x 16KiB. Using 3 port pins PA0..PA2 (connect them to A15..A17) you can select which section of the ROM should be active. To make it easy, you should simply duplicate the topmost say 4KiB to all 8 sections. This way you can do switching w/o loosing the ground under your feet

If you add three pullup resistors (3K3) to PA0..PA2 the conditions after Reset are well defined.

I might try more advanced setups later, but for now I'm going with the 16 SRAM, 32 ROM route. Once I have a functioning specimen, I might try that kinda thing.

Dumb question...Do I just tie the WE pin HIGH on my 28c256 EEPROM? Seems like the thing to do.

I would recommend to insert a jumper or pushbutton and a pullup. The pullup assures write is disabled if the jumper is off. If you insert the jumper / press the pushbutton, you can write to your EEPROM without removing it. But without pressing the button or inserted jumper nothing can harm your EEPROM.

OK, you have to be careful. The program to program the EEPROM needs to stay in RAM. There are timing restrictions to fulfil, but that is nothing really difficult. This program to program may issue a "insert jumper now" then changing the contents of the EEPROM and then give you a message "done, remove jumper".