Hi guys

Just putting together an idea for a firmware dev board for my (WD) 65c02 / 65c816 designs.

The PCB will consist of an Atmega microcontroller, 32KB SRAM, octal latches, connections for address/data busses, ROM select, RWB, RESB, USART.
The main 65c02 PCB will have it's DIP ROM removed and the address/data busses, ROM select, reset & read/write lines connected to the dev board.
When a new image is sent via the USART from an attached PC, the dev board will (in this order) pull RESB low, ROM select low, RWB low, write the image to the 32KB SRAM, set RWB to high-z*, set RESB high-z*, the 65c02 then starts.
The octal latches will be used to feed the address & data busses during write operations from the Atmega and will be deselected prior to RWB & RESB being set to high-z*.

* make the associated pins of the Atmega inputs with pull-ups disabled.

Question:
I've read elsewhere that when RESB is held low, the 65C02 address and data busses are high-z (as if BE were asserted). Is this definately the case? Are the there any gotches or issues that you can see with using RESB in this way?
Another solution is to use BE, but the above method saves me a pin as I'll still need to read RESB.

I don't recall reading that. Have you looked at some datasheets, specifically the pin descriptions (ie, what they say about the /RES pin)?

Just a reminder that RWB mustn't remain continuously low. It needs to be high during the times when a new address is being sent to the latches.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Hi Jeff

I checked the data sheet after reading the post in question, and it doesn't say one way or the other. Usually, I would assume that RESB doesn't release the busses, but as they said their testing showed it working that way, I thought I'd ask. I may just sacrifice a pin and connect BE as well just in case as I'm not wire wrap prototyping, but going straight to PCB manufacture.

RWB: Definitely. I'll probably have to play around with the timing, but I'm also routing PHI2 so I have the option of controlling that. The dev board is really just to save me prying the ROM out of the board everytime I want to change the firmware/OS code.

You haven't shared the post with us, so I'm at a loss. But as for datasheets, they seem to be unanimous in saying nothing about /RES tristating the buses.

Oh! Well, if you're able to stop PHI2 then you can probably get away with tying BE and /RST together and treating them as just a single signal!


Just so you know, there are other options... ones which don't demand the takeover of 16 address lines, 8 data lines and sundry control signals.

An extreme example is my own Ultra-minimal 3-wire Interface boots up 65xx CPU's.

And somewhat less fanatical is the so-called "blind" loader espoused by forum member Michael and others; the Search can help you find references to this. The address bus is not taken over; only the data bus and a couple of control signals. The CPU gets all its instruction bytes single-stepped from the remote host. But it's still capable of writing to its own RAM. And the "program" the host feeds it consists of a series of repetitions of the following pattern:... with each repetition containing an actual address and byte that's desired.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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

Thanks Jeff. I'll have a think on my approach. With regards the post that I read: I can't find it now, which is quite annoying.

I've been using one of these soldered to a DIP socket (for height clearance) and that's ok, but it's just annoying to have to take the EEPROM out, program it, and then put it back, especially when bebugging rom code which cam involve lots of minor changes.

It sounds like you want to add some handy features to an EPROM Emulator of sorts. If that's the case, you might take a peek at San Bergmans' Raspberry Pi EPROM Emulator project. I modified San's design (see below) to use an Arduino Nano in place of the Raspberry Pi and to allow the use of a Flash ROM for persistent storage or a regular SRAM but I didn't proceed past the design stage because I don't really need an EPROM Emulator and I also realized that I could further simplify the design by using a 40-pin PIC microcontroller (5 chips total) and get it all to fit on an inexpensive 4" PCB.

Good luck with your project. Happy Holidays. Mike

Earlier Jeff mentioned a 'loader' that uses a 'blind interface' and I just wanted to mention that while you could build a ROM Emulator with the 'blind interface' method, it may not be easy to connect to an existing board. That is, in addition to the eight data lines, it needs to drive or control the CPU clock and reset lines and the board needs to support a single line that will turn memory on or off. It's much easier to design a new board with "blind interface" requirements in mind.

If you're interested... I just ordered PCBs for a design to demonstrate some capabilities of the "blind interface". The design uses a Nano and includes ROM Emulator capability of sorts and could be used as an entry level trainer or as an economical alternative to the Ben Eater 6502 kits. Please note: NO PROGRAMMER REQUIRED.

Cheerful regards, Mike, K8LH

that's why my first SBC had such a simple and tiny ROM, all it could do was load a program from serial and executed it. so programming the ROM was only done a few times, but after it was working i never had to reprogram it again.
so after that when developing software, it was very easy to test the code by just presssing the reset button on the SBC and dragging&dropping the binary file into whatever terminal software was being used.
the CPU would do all of the loading so no extra hardware is required, just a CPU, some RAM, the simple boot ROM, and a serial connection (USB in my SBC's case, cause that was more convenient than RS232 or similar).

and if you plan on making the ROM more feature rich, you could still start with the ROM only having the required bootloading code, and then develop the rest of the ROM's features in RAM until they're done (enough) so they can be added to the ROM permanently.

using a microcontroller is a neat alterantive since it completely avoids the need for a ROM Programmer (like the TL866). but has the downside of requiring the MCU to take over the bus each reset, which can make the hardware more complex.

anyways, those are just my 2 cents.