Design challenge: 6502-based EPROM programmer

[BigEd]

It's a reasonable point, once you have a programmer, to ask to be able to program a larger target device. However...

Isn't 16k enough, to set up an SBC which can then program a larger device? I think the idea of bootstrapping is a powerful one, and it's good to have the experience, of starting with minimal hardware and software and building up capability to a fully-featured system.

[plasmo]

Michael wrote:

Bill, forgive me for all the questions... If a user simply needs a Flash ROM programmer, is there a way he could easily write something like Daryl Rictor's 32K SBCOS image to a Flash ROM chip with your device?

Let me answer the question again. The first time I was caught up with porting Daryl's SBCOS to my programmer and forgot the question is how to program Daryl's binary file to a EPROM to be used on Daryl's SBC2.

I took SBCOS.ROM and generated a 20K hex file start from $3000-$7FFF; modified the ProgSST to program 20K instead of 16K; burned the flash; and verified it OK on my TL866II programmer. So yes, it can program 20K with very small software modification. By relocating the ProgSST program into lowest 4K of RAM, I can program up to 28K data to flash, but it will take more software efforts to program 32K data to flash. In the RC2014-Z80 world, SST39SF040 (512KB flash) is very popular; this programmer is definitely not usable for programming SST39SF040.

I'll be the first to say this programmer is not meant to be a general-purpose programmer like the $60 TL866II. It serves as an interesting 6502 project and an usable programmer for newcomers to 65xx community who are not sure they want to invest in a relatively expensive specialized equipment that has little utility outside of retrocomputing.
Bill

[Michael]

BigEd wrote:

It's a reasonable point, once you have a programmer, to ask to be able to program a larger target device. However...

Isn't 16k enough, to set up an SBC which can then program a larger device? I think the idea of bootstrapping is a powerful one, and it's good to have the experience, of starting with minimal hardware and software and building up capability to a fully-featured system.

I think we have incompatible assumptions and goals, BigEd. I'm assuming some users may just need a simple, inexpensive, easy-to-use "tool" to program 28C256 EEPROMs and 39SFxxx Parallel Flash ROMs as an alternative to purchasing a commercial programmer. If a user needs to program a 512-KiB Flash ROM for his/her RC2014 Z80 system, he/she may not be interested in learning about the 65C02 or necessarily in a position to be able to "re-use" an expensive W65C02 CPU and FT-245 module on their Z80 system. And while building an expensive and crippled "minimal" programmer and gaining the experience to build a more capable programmer may be appealing to some users, I suspect other users might consider that a barrier and unnecessary burden when all they want is a simple easy-to-use $10 programmer "tool" that they may only ever use a few times.

Happy Holidays. Cheerful regards.

[BigEd]

Yes that makes sense - on the one hand, a minimal bootstrapping project, on the other hand, a generally useful programmer.

[plasmo]

I actually do have a ROM-less Z280-based EPROM programmer that can program 512KB SST39SF040. However, in support Michael's perspective, very few people were interested in it in spite of my offer to give away bare pc board free. I suspect the ROM-less 6502-based EPROM programmer won't be popular, either. That doesn't matter, bootstrapping is an interesting problem in itself, In fact, the concept is universal, I'm thinking of a ROM-less Z80-based EPROM programmer...
Bill

Additional thought: G8PP was a concept to develop a common platform to experiment with 8-bit and some 16-bit processors of 70's and 80's. Bootstrapping of the various processors was a challenge. In G8PP it was solved with CPLD which was a big hurdle for many. The FT245 approach may be more friendly.

[plasmo]

I'm brain-storming another bootstrap approach for Prog65; this time it does not use FT245 but use 6551 instead. I don't have actual experience with 6551, but reading the W65C51 datasheet it seems to be set up to receive/transmit serial data immediately after reset. By providing a 1.8432MHz clock, it is ready to receive & transmit at 115200. Assuming that's true about 6551, the idea is this:

While in programming mode 6551 is mapped to $C000 to $FFFF. Access to a smaller region, say $E000-$FFFF, drives the RS0 and RS1 low so transmit/receive data registers are always accessed. Furthermore, clock to 6502 is in single step mode for read operation in $E000-$FFFF. The source of the single-step clock is a monostable multivibrator triggered by activities on the serial receive line such that every byte of serial data will trigger one clock pulse to 6502. In order to send one byte of data over serial port at a time, the terminal software transmit delay is set to 1 millisecond per character. 6551 is also accessible from $C000-$DFFF but without the single-step clocking and RS0/1 forcing to low; another word, 6551 while mapped to $C000-$DFFF appears as a normal ACIA device.

To bootstrap in programming mode, reset 6502 and sent a sequence of opcode over serial port that builds up a small loader in RAM (RAM is in $0-$7FFF) and jumps to RAM to run the small loader. The small loader reads 256 bytes of data from serial port to RAM and jumps into that 256-byte program. The 256-byte program is an Intel Hex loader that can loads EPROM image and runs EPROM programming software.

I should receive some W65C51 this week to try out this concept.
Bill

[Dr Jefyll]

I like it! An innovative use of the ACIA for bootup, then afterward it's usable in the usual fashion.

There are some miscellaneous details to manage -- I mean the glue that allows the system to function. As noted, the CPU clock will have both a free-run and a single step mode.

And will the ACIA's Phi2 input simply get tied to the CPU's Phi2 input? I expect the ACIA will continue to require Phi2 activity even during single step mode, because Phi2 is probably what triggers the transfers between its internal registers. The question is, can you get away with just a single Phi2 clock pulse for each incoming byte? One may or may not be enough.

And the datasheet won't have answers for questions like that! I guess that's why you're planning some experimentation!

-- Jeff

[plasmo]

I plan to tie ACIA's PHI2 as well as XTLI to 1.8432MHz. Only the clock to 6502 will be switched between 1.8432MHz or single-step.

You are right about the glue logic may be complicated. So I plan to "cheat" by first emulating the glue logic with a CPLD which will give me maximum flexibility and observability. Once I have the glue logic tested out, I'll implemented it in TTL logic.
Bill

[plasmo]

I received four W65C51 ACIA last week and built up a board to explore ROMless bootstrapping with ACIA. Because of my inexperience with W65C51 and plan to use features not well documented in datasheet, I use a CPLD as glue logic instead of discrete TTL logic. The CPLD allows me to change design easily, often without changing any wiring. Another baby step is configuring the board as a normal computer booting out of EPROM so I can checkout ACIA a little bit at a time.

The first obstacle I ran into is the W65C51 documentation is rather poor. The relationship between RxC, XLTI, PHI2 are unclear. PHI2 is system clock, that part is clear, but can I tie the same system clock to XLTI AND RxC? XLTI is nominally 1.84MHz, but I'm not sure it can be driven to higher clock.

Another obstacle is the ACIA transmitter does not work immediately after reset; it needs some kinda initialization first. The document is unclear, but somehow RTSB (an output of ACIA) needs to set low in order to transmit data out.

The one I'm worrying about is whether ACIA receiver works immediately after reset without initialization. I need that to work in order to bootstrap with ACIA.
Bill

[GARTHWILSON]

plasmo wrote:

The first obstacle I ran into is the W65C51 documentation is rather poor. The relationship between RxC, XLTI, PHI2 are unclear. PHI2 is system clock, that part is clear, but can I tie the same system clock to XLTI AND RxC? XLTI is nominally 1.84MHz, but I'm not sure it can be driven to higher clock.

PHI2 and XTLI are not related. XTLI is normally 1.8432MHz to get the standard bit rates, but I've heard of people doubling it to 3.6864MHz to get 38.4kbps with 1111 in the BRG. It's not guaranteed to work with 3.6864MHz, and I have not tried it myself, but apparently everyone who has tried it, with every brand, has had success. RxC is just 16 times the receive bit rate, regardless of how you come up with that rate. (Note that it can be an input or an output.) You'll usually have the transmit rate locked to the receive rate though (with control register bit 4 = '1'). If you input 1.8432MHz into RxC, you'll get 115.2kbps (which I do for programming our bluetooth devices for work). I've also done MIDI at 31.25kbps by inputting 500kHz from a VIA's PB7 toggled automatically from its T1 timeout in free-run mode.

Quote:

Another obstacle is the ACIA transmitter does not work immediately after reset; it needs some kinda initialization first. The document is unclear, but somehow RTSB (an output of ACIA) needs to set low in order to transmit data out.

The transmitter is automatically disabled if CTS\ is high. The receiver is disabled if DCD\ is high. The transmitter will be turned off if bits 3 and 2 of the command register are 0's.

Quote:

The one I'm worrying about is whether ACIA receiver works immediately after reset without initialization. I need that to work in order to bootstrap with ACIA.

Hardware reset leaves it in 8,N,1, 16x external clock, no echo, transmitter off, RTS\ high (ie, false), receiver disabled; so I don't think it will work for this particular idea.

[plasmo]

GARTHWILSON wrote:

Hardware reset leaves it in 8,N,1, 16x external clock, no echo, transmitter off, RTS\ high (ie, false), receiver disabled; so I don't think it will work for this particular idea.

I believe you are right. W65C51 documentation does not explicitly said receiver and transmitter are disabled at reset. It says DTRB and RTSB are high at reset. My mistake is thinking DTRB and RTSB are programmable output discrete that do not reflect the internal state of the receiver and transmitter. Not so; if DTRB is high that means receiver is actually disabled and if RTSB is high that means the transmitter is disabled. So if I want to bootstrap off the W65C51, I'll need a way to jam a value into its command register immediately after reset. Sigh...
Bill

[GARTHWILSON]

plasmo wrote:

W65C51 documentation does not explicitly said receiver and transmitter are disabled at reset.

It does however tell the reset status of the command and control registers, and I looked up the meaning of each of those bits which are all 0's after hardware reset.

[plasmo]

I'm not quite giving up on W65C51, yet. 6502 does something after reset and before pulling reset vector so that may be a window of opportunity to jam data into ACIA's command register. I'm glad I have a CPLD already wired in to explore that window of opportunity.
Bill

[Dr Jefyll]

plasmo wrote:

6502 does something after reset and before pulling reset vector

I'm pretty sure the reset sequence is much the same as an interrupt sequence. AIUI, reset is an interrupt, but it has its own vector; also, the three writes to stack are replaced with dummy reads.

Perhaps you could arrange things so the low byte of the reset vector is also the value you need written to the ACIA...

-- Jeff

[plasmo]

I'm still thinking about how to initialize W65C51 to receive data after reset, but the photo shows the design I sent off to JLCPCB. The design file for the prototype is documented here. It is a simple idea of using USB-FIFO to bootstrap and communicate so the programmer itself is quite simple with only RAM, 6502, a couple TTL logic, and a socket for EPROM. A toggle switch selects whether it is a programmer or a 6502 SBC. The pc board has plenty of prototype area to try other ideas. It fits in a Pactec CM5-125 enclosure.
Bill