As a prelude to testing a PIC-based UART replacement, I find myself in need of a simple 6502-based computer for testing and prototyping purposes. To that end, I've put together a simple design and started building it.

The goals of this system are as follows:

• Breadboardable
• Little (preferably no) soldering required
• No EPROMs
• No DRAMs

The only potentially interesting thing about this system is the ROM Emulator. It should probably come as no surprise that I'm using another PIC microcontroller to create it. The PIC holds the 65C02 in reset and causes it to release (tri-state) the address and data lines by setting BE low. Then it loads the contents of the upper 8K of CY7C199 SRAM with a user-specified program. Once that's done (hopefully not more than a couple of seconds), the PIC releases the address and data lines it was controlling, enables the 65C02 BE and releases it from reset. Here are the preliminary schematics for the hardware buffs. When it gets closer to final form, I'll redraw it as several sheets in AD for readability and archival purposes.



(sheet 2):



And here is the breadboard work in progress for those who prefer eye candy:



The only testing I've done so far is to wire up the data lines to return NOP and then check the address lines for expected operation.

Here is the memory map I have in mind:

0000-7FFF: CY7C199 SRAM #1
8000-9FFF: CY7C199 SRAM #2
A000-BFFF: CY7C199 SRAM #2
C000-DFFF: HW PERIPHERALS
E000-FFFF: CY7C199 SRAM #2 (read only)

The address decoding logic is straightforward. The only thing special it needs to do is to disallow writes to the last 8K of the SRAM by the 6502, but allow it by the PIC. I was originally accomplishing this by putting a 74HC245 tri-state buffer on the decoder logic output to the WEn lines on the CY7C199, but it occurs to me that I may be able to slightly simplify the design using another 74HC139 and a leftover gate instead. Need to check the gate delays though to make sure it's not worse. There's probably other simplifications to be made that I haven't found yet as well.

Initially, I'll be clocking the 65C02 at 1.8MHz in order to test it with the "real" UARTS I have on hand (68B50s). Once the system is up and running correctly, I'll replace the 68B50 with my PIC UART and begin development and testing of that subsystem. Eventually I will turn up the clock speed further to see how close to 14 MHz I can get.

A larger PIC (I don't have anything in DIP form larger than 28-pins at the moment) could control a display, and interface to a FAT filesystem stored on a microSD card. In fact, there is nothing stopping the PIC from programming all 56K (64K-8K) of SRAM either so it could serve not only a role in ROM emulation, but also as a program loader in much the same way flash is used with FPGAs.

[10/11/15 - Updated schematic and board image]

The 65C02 data sheet doesn't indicate or even imply if BE is effective while RESB is held low. Have you determined if this will work?


You will need logic that is faster than 74HC to go much over 8 MHz. Most 74HC logic is no faster than the 74LS equivalents. I recommend 74AC if you want to go up to 14 MHz. However, the much faster output transitions of 74AC may give you grief with your breadboard.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

This is extracted from the WDC data sheet:


You make a good point that I should test to insure it is still effective when RESB is low and I will do so soon and report back here. I would like to think that if it is not effective when RESB is asserted, however, that they would have called that out in the datasheet.


I have a strong aversion to the 74AC logic family and will avoid it at all costs on breadboard designs. Instead, I prefer the 74AHC and 74LV logic families. The reason is -- as you suggest -- the 74AC logic requires a better ground than is usually possible to achieve on breadboard and this leads to lots of difficult to resolve problems for circuits placed close to the AC logic. Unfortunately, I can't find all of the logic gates I'm using in DIP form in the AHC and LV logic families, but I will cross that bridge when I get there.

Thank you for your input! It is appreciated and may well end up saving me a lot of debugging time!

I can tell you that BE does work during /RES on the 65816, as my SBC-4's RAM get's loaded from an AVR microcontroller during /RES. Hopefully the logic works the same with the WDC 65C02's.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I can also verify that Bus Enable is functional while Reset is asserted.
Using the same SRAM loader method as you, but with an AVR.

Brad

Thanks Brad! I'll focus on finishing the wiring instead of testing this.

P.S. Let me just add my voice to the clamor of well deserved praise for your Vulcan 74 project!

Edit: addressed semantic ambiguity

Thanks!

On thing I did consider when handling both BE and RS, is the IO timing from the microcontroller.
Instead of toggling bits one at a time, I used a single port, and output the state in one cycle.
Not sure if this was necessary, but it assured that both changed state at the same time.

Good luck on your project!

Brad

This is what I've done, too. Mostly because I'm using a 28-pin DIP for the microcontroller, and once you subtract the 3 I/O lines used for the programming/debug interface, that leaves only 22 I/O lines left. They are distributed as follows:

Port A: D0-D7
Port C: A0-A7
Port B: 6 bits available, distributed as follows:

2 bits for controlling the 74HC4094 that controls the upper 8 address bits
1 bit for a reset switch (debounced by the PIC)
1 bit for RW
1 bit for PROGn (run or program)
1 bit left over (maybe an indicator LED or serial output for a display)

Still working out the logic for the RW (need to update the schematic), but that shouldn't take long.

Could have used a 40-pin PIC and eliminated the 74HC4094, but I went with what I had in the parts box at the time.

Some of the PICs have an 8-bit parallel port built into them complete with address lines and registers for high-speed I/O. Didn't seem important to use that for loading the contents of the SRAM here, but that's what I'll be using for the UART so that the hardware interface is indistinguishable from a dedicated UART.

Jason

I've got the basic circuit working with the PIC now. There were a couple of errors in the schematic which I found and corrected and I will upload the corrected version over the weekend. Even with the 74HC4094 shifting out the upper 8 address lines on every read and write, the system is capable of loading 64 kB of SRAM in under 1 second, which is more than fast enough for my needs at the moment.

Next step is to either put the 68B50 UART on the bus and then try a hello world program for it, or I could be more conservative and put a 74HC374 register on the bus with some LEDs connected and try to use that to verify the rest of the hardware is functioning as intended first. Either way I think I'm not far off from being ready to start on the PIC-based UART. Time to order a second PIC programmer for that too.

Congrats!
Yeah... it's always impressive to see how fast something will run, especially when it outperforms your expectations.
574 is also a good alternative to 374 if you need the input and output on opposites sides of the package.

Brad

Thanks Brad. The 574 would have been a better choice to use if I had them in my parts box. But I'm only using it to verify correct operation of the 6502 and will rip it out and replace it with a 68B50 as soon as that's done. Then I'll R&R that with a second PIC once that's working. I'm starting to see the advantages of your approach of building a giant breadboard first before starting the whole project to cut back on the necessity to R&R parts to make room for new ones.

The 374 has been added to circuit and wired up to 8 LEDs already and the decoding tested with the PIC (working). Next step is to write a little 6502 program to manipulate the LEDs and verify it works. Might take advantage of the opportunity to crank up the clock rate on the 6502 as well to see how far I get before it fails with all my slow "HC" logic in place. When I remove it and put in the 68B50 I will be limited to 1.8 MHz for a bit.

The test system is now up and running and flashing LEDs on the HC273 Battlestar Galactica cyborg style. I see now why Phil P. used a latch instead of a register in his design as it was a bit tricky to get the timing of the arrival of the clock pulse to arrive within the window of arrival of data from the 6502. Thanks to the placement of a patented delay device (a resistor), it's working now. During testing, I discovered that the 16 channel logic analyzer limitation of my PICO-scope was a real PITA to work with. I've got an old HP logic analyzer with something like 128 or 256 channels on it but it has some bad electrolytics in it or I would already have switched to it. Can't decide whether to take the time out to repair it now or if I will be able to make do with the PICO. Guess I'll see how it goes.

I did take the opportunity to up the clock rate as high as 12.5 MHz and the system continued to correctly flash the LEDs. I'm a bit surprised as my decoding uses four levels of HC logic which seems like it would have a worst-case delay of more than half the clock period. I didn't have the right signals connected to my logic analyzer when I did this test in order to be able to see the correct signals. For all I know it won't work reliably at that speed either as it was a simple program and I left it running for only a few minutes at that speed.

I'm adding the 68B50 today and hope to have a, "Hello World" program working with that shortly. Once that's done, I'll freeze the 6502 code, remove the 68B50, and install another PIC in my attempt to build a clone of the 68B50 that is virtually indistinguishable in software from the real thing (and that will run at up to 32 MHz, not the 1.8 MHz the 68B50 is limited to). If you hate the 68B50 UART, never fear. For so long as your favorite UART doesn't have more than 4 registers, it should be a straightforward matter of changing the firmware to change the personality of the device.

Edit: re-tested up to 12.5 MHz before ripping out the HC273 (which I used instead of the HC374 due to the availability of the CLRn signal and the lack of need for a tri-state output) to make room for the 68B50.

I guess that leaves out the 28L198.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes, unfortunately, it does leave out that one, the 8250, the 16x50, and others too, I'm sure -- at least if you want software transparency which is my goal.

But the 68B50 and 65C51 should be simple enough since they require only 1 or 2 address lines respectively.

I started down this path when I realized the 65C51s Western Design Center is selling are defective as that was what I was originally going to use.

[Edit -- changed Western Digital to Western Design Center -- oops]

Fortunately the real timings are usually quite a bit better than specified. But if you make a product to sell, you can't count on it unless you test them yourself at the extremes, like temperature. IIRC, one of the commercial 6502 computers (was it the Beeb?) was usually crashing when the ambient temperature was kind of hot, like maybe upper 80's of degrees F.


Um, make that Western Design Center.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?