6502.org

Hi everyone.

First, a little bit about me. Sorry if this is boring. I got my first computer when I was eleven, a Timex 1000 (a rebranded ZX-81). My dad built it as a kit and once he was done building it he lost interest, and I took it over. A little while later the family got a VIC-20 and shortly after that, I got a paper route to buy my own Atari 600XL. A little while later the family upgraded the VIC-20 to a C64. I was hooked and fell in love with programming. I was writing my own games in 6502 assembly at 12 and eventually went on to do professional software development as a career. So in other words I am no stranger to the 6502 or software development. The hardware side, not so much.

After getting a great sense of nostalgia watching my kids enjoy my collection of 8-bit machines and building an RC2014 kit I now have the urge to build my own 6502 based computer. I have wanted to do this for a number of years now and have spent many countless hours reading and rereading about the projects others have built and have been devouring every bit of information on the subject so generously shared by others. Many of whom are on this very forum. Thank you so much!

So a little bit about what I have planned.

I am definitely someone that would be considered a novice when it come to the double E side of computers. Well, novice would probably be generous.

I plan on building this in stages starting with a breadboard implementation at low speed <= 1Mhz. I'll be starting with a free run (the hardware equivalent of "hello world"?) and start adding functionality from there.

Once I have a design proven out on the breadboards at ~1Mhz, I'm planning on having PCBs made and a somewhat modular backplane design a'la RC2014 style. Then I will start bumping up the clock speed and attempt to get to ~7-8Mhz.

Now for some more specifics.

This will be primarily a 3.3v design. new 5v parts seem to be hard to find these days in any configuration, let alone through hole, breadboard friendly packaging, and some of my design choices kinda force me to go with 3.3v. This is also why my speed limit will ultimately be around 8Mhz as those are the limits on the CPU at 3.3v according to the datasheet.

Here are my initial component choices:

CPU: WDC 65C816
ROM: SST39SF040 512k x 8 Flash used as ROM
RAM: AS6C4008 512k x 8 Static RAM (x4)
IO: WDC 65C22 VIA (x2) and others TBD. Probably 65C51 for serial.

The vast majority of the glue logic I plan on implementing on an FPGA (hence the 3.3v limitation). I have had an FPGA development board for about 4 years that I have played around with and feel confident I can implement what I need.

The FPGA I have chosen is a Spartan 6 XC6SLX9 in the form of the Mojo V3 development board since it has lots of available IO. It will be the backbone of the design. I plan on using it to provide the system reset circuit, system clock with a selectable run/single step mode, 65C816 data/address bus demuxing, address decoding providing up to 16 chip/slot selects, address remapping, and if I have enough room on the FPGA, video out to VGA, and stereo audio out.

The Flash ROM is actually a 5v part, but the inputs according to the datasheet are supposed to be 3.3v compatible, the data out pins will need to be level shifted and I have an 8 channel level shifter on my parts list. The speed of the ROM and the propagation delay in the level shifter will make this ROM unusable at higher speeds so I may implement emulated ROM in RAM using the FPGA. At startup the FPGA would hold the system in a suspended state while copying the ROM into RAM at a speed appropriate for the limits of the ROM. After copying the ROM, the ROM will be taken off the bus and then the FPGA will then start the system and enforce write protection on the RAM. I have an external programmer to get data into the ROM so the board should never require a 5v input into it except for Vcc.

For video I plan on using the FPGA to implement a 320x200 pixel display and have it provide a VIC-II like register set to the processor. The FPGA will provide a 64k area of dedicated video RAM. The video RAM will be implemented using the internal block RAM on board the FPGA and will be dual ported, the register set for video will also be implemented in dual port block RAM. I hope that by using dual ported memory, it will allow me to keep the slow clock domain (1-8Mhz) of the overall system and the high speed clock domain (50Mhz) of the video implementation separate. This should also allow the processor and video to access video RAM and registers simultaneously without having to implement wait-states or cycle sharing like on the C64.

I have not given a lot of thought to sound output yet, but I would think it would be similar to video, possibly providing a SID like register set implemented as dual port block RAM and sound output using PWM. A proper retro computer has gotta have beeps and boops.

So, now a couple of questions.

The first question is what is your general sense for what I have planned? Does what I have planned sound workable? Does anyone have any suggestions?

The 65C816 has the multiplexed address and data bus. Does anyone know if the upper 8 bits of the address are driven on the data lines during PHI2 low when the processor is in emulation mode? I saw a couple of 65C816 to 6502 adapter boards and they did not seem to be doing anything to isolate the data bus during PHI2 low. I haven't found anything indicating it is not driven when in emulation mode in the datasheet. Just wondering if I need to handle demuxing for a free run.

I also have a question about decoupling caps. Are the cap values that are generally used in 5v designs applicable for 3.3v or do I need to figure out different values specific to 3.3v? I have a general understanding of the digital side of things but analog might as well be black magic to me at this point.

If you got this far, thanks for hanging in through the rambling.

Brad

Welcome, Brad!

It wasn't boring to read about your way - there are always similarities where one found oneself

Coming to your plan, it looks to me pretty well considered. As you have little practical experience in electronics it is most likely a good idea of breadbording a little bit, just to get familiar with this technique. It may be helpful to consider a first approach using the 65C02 instead of the 65C816 as the former is even simpler to handle. Perhaps just for the very first few steps. Once you feel familiar with the various signals, timings, and levels you simply switch to the 816 to verify your knowledge and to explore the additional constraints dealing with the latching of A23..A16 and its decoding.

The planned system sounds very well to me its quite a lot of work to do though The ROM should work with the FPGA as voltage levels >2V are considered as 1. You may check if simple current limiting resistors (<= 1K) in the data lines and schottky diodes to 3V3 will work - as I assume. Then 55ns types should run at your planned system speed.

The multiplexed address is always present no matter if the 816 is running in emulation or native mode. If one does not use more than 65K one could them ignore. But some sort of techniques that will access the bus during Phi2 = 0 (e.g. reading a memory mapped video buffer) would require an additional buffer between the CPUs data lines and the memory to isolate DB0..7 during that "hidden" access. This wouldn't be necessary in case of a 65C02.

Decoupling caps should be used plenty. As usual 100nF as close to the power pins as possible. AFAIK there are no 100nF caps that would not work at either 3V3 or 5V0. You should use X7R or X5R types. A few 10µF caps here and there might assist the 100nF caps. Again X7R will do a fine job.

As a suggestion - but you may have already read enough about it: there is the WDC65C265 µC as well. It could run fine at 8 MHz and has some peripherals and some predecoded /CS outputs. Getting this thing up and running might be even easier. The worst thing about it is the so called "data sheet".


If wish you good luck and much fun. And keep us informed!

Arne

Be sure to go through the 6502 primer at http://wilsonminesco.com/6502primer/ which has a lot of sections that will relate to the '816 as well, including about construction methods and precautions to observe.

GaBuZoMeu, thanks for info on the data bus in emulation mode. I suspected that was the case since the data sheet did not say anything about it.
I think I have read that primer about 20 times now. Very good read and one of the things that actually spurred me on to giving this a shot. That a problem with all this info on the internet. Someone like me reads something and suddenly thinks they are an expert Next thing you know they are trying to build their own computer!

I actually have an '816 sitting on my desk right now so I will probably give that a go first. I have an 74HC573 and a 74HC245 to handle the demuxing. I just wasn't sure if I would need them immediately, but it sounds like I will. If I get to frustrated I may go ahead and get a 65C02 and start over from there.

Thank you both.

Welcome Brad! That's a very large FPGA, but if you already have it, no problem. Maybe you need a large capacity just to get the number of pins you need.

Just possibly you could do without the 5v flash ROM: if your plan is to prefill RAM then the FPGA could do that - it will necessarily have a large serial EEPROM for its program, which can be read serially after configuration, and it has 64k RAM on board which can be initialised to your desired ROM contents for pumping into the RAM. So that's two approaches. Or the 64k can even be accessed as ROM, as part of the system, if that suits your purpose.

Oh yes, a serial EEPROM or faster a FRAM (or MRAM) is really a nice recommendation BigEd did!

Of course then you have to pay attention: booting the FPGA, then booting the 816, then booting the OS, ... don't compete with Windows!

Welcome aboard!
Since this is a first-time effort, I recommend you scale back a bit and implement the glue logic in a CPLD, rather than an FPGA. Unlike the latter, the former doesn't require a configuration ROM. In my current project (POC V2), I use a Microchip ATF1504AS CPLD, programming it in-circuit via JTAG. My recommendation is based upon the fact that it's possible to design in more complexity than your troubleshooting skills can accommodate, possibly resulting in something that refuses to run.

512k × 8 SRAM is available in 5 volts. The linked device is SOJ36, which despite the 50 mil pin centers, can be manually soldered. If you use a CPLD, you can build a 5 volt system and substantially broaden your I/O choices.

WDC's version of the 65C51 has hardware errata, which will complicate your driver code. There are much better, non-WDC, UARTs available, such as those produced by Exar and NXP (I use the latter).
As I said above, I think this is too much complexity for a first-time design.
At 8 MHz, I doubt that shadowing ROM into RAM will realize any performance improvement, unless you use an exceptionally slow ROM.
See above.
The '816 drives the bank bits onto D0-D7 in both modes. Your hardware has to be able to account for this characteristic regardless of operating mode.
I use 0.1 µF X7R MLCCs, rated at 50 volts. The usual item I order is AVX's part number SR215C104KARTR1. Be liberal in your use of bypass capacitors. Each active device should have one attached to each Vcc pin on the device, with minimum possible lead length. I also recommend placing one right at the power input jack to keep switching noise from wandering into the power source.

We have a sticky topic on construction methods, which I highly recommend you read.

Hi Brad, and welcome to the forum. I think your plans sound very good, and somewhat similar to what I am doing. I'm relatively new to this hobby but did do a bit of experimenting when I was much younger. I used to spend a lot of time in my early teens drawing out designs for 6502 systems on paper, and I always regretted not actually getting them built. So now's my chance to rectify that.

I started out by building a 65C02 breadboard system with a 65C52 for serial communications. I probably couldn't have gotten it going without the advice from here, but looking at it now I appear to have ignored quite a bit of advice too, and I'm amazed that it actually works. I used an ATF1508AS (similar to what BDD uses for his POCV2), and included the ROM in there (very limited, I was continually running out of space, but it was enough to test it out and easy to reprogram). I ran the whole thing at 1.8MHz and fed that clock into the 65C52 so that it ran at 115,200 serial speed, on a very messy breadboard and with no bypass capacitors. So you don't have to do things perfectly to make it work. Still, looking back I'm amazed that it did work. I never posted a photo of this project as it's probably the messiest breadboard ever seen on this forum. Some others are very tidy but I used jumper wires for everything so it looks a real mess. Take a look:
My next step, which may be something you want to try, was to directly hook a 65815 up to a FPGA. I did this with a pipistrello board, but it should be an easy conversion to your Mojo board if there is enough IO available. The FPGA code (in verilog) was based on Arlet's 65C02 sandbox project. I've implemented 4k block RAM, block ROM containing OSI Basic, and a simple 6850 serial emulation so that the basic runs through the serial port. This is connected through the pipistrello UART-USB chip so it can be programmed and used with the one cable. You might want to try building this yourself as I think you have all the parts available. I've been meaning to write up the project and publish the code but haven't had time for that yet.

Attached is a photo, it's just connected with jumper wires and was quite quick to assemble. The 65C816 is running at a little over 4MHz (it was an easy divisor) and 3.3v. There should be a pullup resistor on the RDY line, that's the only other component required.
My next step is to make it load the ROM from the unused space in the SPI FLASH and copy that into RAM before boot. Also it's not making use of any more than 64k at the moment, I'm working on getting the Pipistrello LPDDR RAM working, then it'll have a full 16MB address range of RAM available.

Well, first attempt at a free run, first failure, first lessons learned.

Built up a bread board with the processor and address demuxing, generated a clock and reset signal with the fpga, and had the address and data bus feeding into the fpga so I could see the address lines and data bus on the on the leds on the fpga. Ran the clock really slow at 4hz, so I could see everything happening.

90 percent of the time the processor starts and I see addresses inline with what I am expecting, I see the fetch from the reset vector and then things quickly go off the rails, I see maybe a couple of $EAs on the data bus but then quickly start seeing garbage until the processor jams and all of the busses seem to go high impedance. Sometimes it would go down hill right from power up.

Started poking around with the oscope and, WOW! I know solderless bread boards are noisy but it was bad enough that I was having a hard time getting the scope to trigger on edges. After looking at things for a while I am convinced that had I been running at 5v everything would probably have worked, but at 3.3v the margin between low and high logic levels is just too small and makes everything even more susceptible to the noise. Oh well, I figured my odds of success were going to be somewhere south of 50/50.

So back to the drawing board. I think I am going to go ahead and move the demuxing logic into the fpga and just have the processor on the breadboard with the data, address, and control lines wired directly into the fpga. As I started removing components while troubleshooting I noticed that the noise decreased and I think if I did not have all those little antennas between the discrete logic for demuxing and just kept it to what I needed to get signals into and out of the fpga, I might be able to get things working. Besides, I feel a lot more confident working with VHDL than working with a bunch of wires that look like a drunk pigeon's attempt at building a nest. If I get that working, maybe I will try to build something on perfboard, or do some simple home-brew pcbs.

I think I will re-read that construction techniques post again for what is probably the tenth time. Maybe something will sink in this time around

Thanks again for all the comments, suggestions, advice, and warnings.

A learning experience. These sorts of considerations spring to mind:
- solid power supply, good power wires
- bypass caps to each chip and an electrolytic on the main rail
- set drive and slew rates on FPGA pins to minimum
- shorter wires and especially make the clock direct and tidy
... probably in that order.

The lack of a solid ground plane doesn't help as well. As noted, running at 3.3 volts tends to increase noise susceptibility, which is where power and ground planes tend to mitigate the noise issues.

As you know, CMOS inputs should not be floated, as noise can cause repeated switching between states and produce random device behavior. Presumably you've already taken care of this, but be sure that all inputs to the '816 are pulled up to Vcc through a 3.3K (typical) resistor. In that list would be ABORTB, BE, IRQB, NMIB and RDY. Note that RDY is a bi-directional pin, which is pulled low by the MPU if a WAIt instruction is executed (intentionally or not). Do not connect RDY to Vcc or to any device output that continuously drives it high.

As an aid to troubleshooting, here are the typical reactions that you might see if one of the above inputs is not properly terminated.

• ABORTB - The '816 will continuously execute an abort interrupt and eventually auger in due to stack underflow caused by the abort interrupt being interrupted by an abort interrupt, which is interrupted by an abort interrupt, which is interrupted by...you probably get the picture.
• BE - The '816 will float A0-A15, D0-D7 and RWB.
• IRQB - If IRQs are enabled, the '816 will continuously execute an interrupt request, which means no foreground code will ever be executed and the '816 will have effectively augered in.
• NMIB - The '816 will continuously execute a non-maskable interrupt, which means no foreground or IRQ code will ever be executed. Adding insult to injury, the '816 will eventually auger in from stack underflow.
• RDY - The MPU will halt, with the buses and RWB held in their current state. Negating RDY internally stops the Ø2 clock in the high phase, which of course means the '816 will stop running until RDY goes high again. Incidentally, WAI does in software what negating RDY does in hardware. The difference is the effect of WAI can be "broken" by a hardware interrupt.