It seems that the parts I use cost less now than when I used them. I paid $10 for the 10 MHz Z80, $10 for the Amtel EEPROM, and $10 for CMOS SRAM. The three now cost about half as much.

The 10 MHz CMOS Z80 now costs $5.52: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=269-3898-ND
It's also at Mouser for $4.14, but they don't have the Amtel EEPROM, and ordering from two places doubles the shipping costs.

The AT28C256 now costs $6.49: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=AT28C256-15PU-ND

This CMOS SRAM costs $2.51: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=428-2158-5-ND

The FT245RL costs $4.50: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=768-1011-1-ND
...or you can use the UM245R, but it's expensive: http://search.digikey.com/scripts/DkSearch/dksus.dll?vendor=0&keywords=UM245R

You'll also need a 10 MHz oscillator for the Z80, which is $1.88: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=X114-ND

...and the other parts add up to $1.88:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=497-1777-5-ND
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=568-1400-5-ND
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=TC74HC08APF-ND
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=497-1819-5-ND

...oh, and the USB connector, $0.93: http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=151-1121-ND

Total so far: $23.71, or $38.28 if you use the UM245R.

What does prototype board cost these days? Last I looked I couldn't find it anywhere for a reasonable cost, so I've been drilling holes in plexiglass and using that instead. It doesn't melt like you'd think it would, and it's only $6 for an 24" x 18" piece.

...and you might want a ZIF socket for the EEPROM, and maybe normal sockets for everything else. ...and a few capacitors. ...and some sort of power supply and a connector for that. ...and perhaps a box of some sort. Maybe a power switch and an LED so that you can turn it on and off. ...and a USB cable, you don't want to forget that...

Wait a minute... Did I include the cost of an EEPROM in the cost of the programmer? Well, whatever.

Money, money, money.....!

Unfortunately, I have very little money. But I have a whole bunch of old chips. So I desire to use what I have on hand. I have everything but the EEPROM and four 74161(?) binary counters to generate a 16-bit address bus incremented by the clock. These are about 50 cents each.

Like I said, I already invested 32 dollars in a USB to RS232 serial port and so I'm sticking with it. Unfortunately, I ordered it exactly one day before I talked to you about a USB port, but there it is.

Today I breadboarded much of the system. I have to study the 6850 manual to get the gist of the software handshaking routine. And I'm waiting for the USB to Serial Interface converter. Plus I have to order the EEPROM and the counters, so there is a hold up. I'll try to send you a block diagram as soon as I figure out how to make it smaller.

 

No, I did not resize it. I don't even know how to do that. But I think that is indeed the problem.

There are apparently a few web sites that will do it:

https://duckduckgo.com/?q=resize+image+online
https://duckduckgo.com/?q=convert+image+online

If by chance you use Linux, you can use ImageMagick with these shell commands:

Reduce the color depth of a schematic while preserving resolution:
convert input.image -colorspace gray -normalize -threshold 66% -colors 2 output.png

Reduce the size of a photo while preserving color:
convert input.image -thumbnail 1024x1024 -quality 75 output.jpg

As for Windows, there's probably a guide somewhere on the internet. Most message forums have limits on uploaded files, and so I'm sure instructions have been written a million times over.

As for your programmer based on the serial port it lacks the ability to read the EEPROM for verification. Also, I don't understand why you needed to cascade 4 timers. It seems 1 would do.

For verification I made the code calculate a checksum of the ROM and display it, and I just made sure it was what the script on the PC said it should be. Obviously not what you want to do, of course.

As for the four timers:

When you receive a serial byte, you wait for the transition between the stop bit and the start bit, and synchronize your receive circuit with that. Then you want to clock your shift register in the middle of each data bit, so that if the oscillator speed is a little too fast or slow, you just end up clocking the shift register a little before or after the middle of the data bit, rather than in an entirely different bit. At the end of the byte, you similarly want to wait until the middle of the stop bit before looking for another start bit, so that if the oscillator is running fast, you don't mistake the last data bit for a start bit.

To that end, the two timers on the right are triggered by the start bit. The top-right timer times 9 1/2 bits in order to wait until 1/2 way into the stop bit before looking for another start bit. The bottom-right timer times the byte transfer so as to know when all bits have been received, and to latch the received byte into the shift register. The two timers on the left create an oscillator that times single bits, in order to clock the shift register. One has to run shorter than the other, because one has to be the first half of the cycle and the other has to be the second half, and making one time 60% of the bit and the other 40% causes the one that times 40% to re-trigger the one that times 60%, causing it to become the second half of the cycle while keeping the transition relatively close to the center of the bit.

 

There are apparently a few web sites that will do it:

https://duckduckgo.com/?q=resize+image+online
https://duckduckgo.com/?q=convert+image+online

Thanks.

As for the four timers:

When you receive a serial byte, you wait for the transition between the stop bit and the start bit, and synchronize your receive circuit with that. Then you want to clock your shift register in the middle of each data bit, so that if the oscillator speed is a little too fast or slow, you just end up clocking the shift register a little before or after the middle of the data bit, rather than in an entirely different bit. At the end of the byte, you similarly want to wait until the middle of the stop bit before looking for another start bit, so that if the oscillator is running fast, you don't mistake the last data bit for a start bit.

To that end, the two timers on the right are triggered by the start bit. The top-right timer times 9 1/2 bits in order to wait until 1/2 way into the stop bit before looking for another start bit. The bottom-right timer times the byte transfer so as to know when all bits have been received, and to latch the received byte into the shift register. The two timers on the left create an oscillator that times single bits, in order to clock the shift register. One has to run shorter than the other, because one has to be the first half of the cycle and the other has to be the second half, and making one time 60% of the bit and the other 40% causes the one that times 40% to re-trigger the one that times 60%, causing it to become the second half of the cycle while keeping the transition relatively close to the center of the bit.

This is complicated. And, like you said, you had to adjust the monostables with an oscilloscope. I think a serial port is a better solution in that it is bidirectional and it puts only the data on the data bus, so you don't have to worry about start and stop bits. Also, you're USB to parallel port is a great idea and is probably the best solution.

There seems to be a simple way to use a serial port. By disabling the interupts and ignoring handshake signals, it's possible to gather serial data from the host to the ACIA's data bus and load a RAM. And, as you did, a microprocessor could then use the data in that RAM as a program. In terms of my chip set this would mean a 6800 and a 6850 would be involved.

And, if this is the case, why not just develop the microprocessor system and ACIA port together. Burning EEPROMs with it after that is easy.

 

This is complicated. And, like you said, you had to adjust the monostables with an oscilloscope. I think a serial port is a better solution in that it is bidirectional and it puts only the data on the data bus, so you don't have to worry about start and stop bits.

Yes, I just didn't know of any chips that would do that at the time. All I knew about were like the 16550D, which must be initialized first. (...and is a piece of garbage, too. I bought two at $5 a piece, and neither one is reliable despite the most perfect input waveforms one could expect.)

And, as you did, a microprocessor could then use the data in that RAM as a program.

That's what I've always done. Initially I just built ROMless systems and always programmed them in this way. Then I added the ability to program EEPROMs as well just so that I could turn the system on and have it do something without first programming it with the PC, since it seemed kind of lame otherwise. Finally, I built a system that didn't have a means of programming, just to use EEPROMs which I programmed in the system that supports it.

The EEPROM burner I built a few days ago is the first one I've built that didn't have the ability to run the code in the EEPROM after burning it.

In terms of my chip set this would mean a 6800 and a 6850 would be involved.

Yes, you can use any CPU you want. The only requirement is that you need something like the Z80's WAIT signal, to delay bus transactions until the next byte from the PC is available, but most CPUs have that.

And, if this is the case, why not just develop the microprocessor system and ACIA port together. Burning EEPROMs with it after that is easy.

That's actually what I do. The last couple of days I've been trying to simplify how I do it, so that I can post the schematic to my web site. I think everyone should want to do it that way, since it really speeds up development to not have to swap ROMs between the programmer and the test system, but people seem to like EEPROM burners instead.

 

That's what I've always done. Initially I just built ROMless systems and always programmed them in this way. Then I added the ability to program EEPROMs as well just so that I could turn the system on and have it do something without first programming it with the PC, since it seemed kind of lame otherwise. Finally, I built a system that didn't have a means of programming, just to use EEPROMs which I programmed in the system that supports it.

I did pretty much the same thing back in the 90s, but I used the printer port to communicate with read or write modes via my black box. This was a hobby box which included the logic to read or write to the 8 bit parallel bus and also create control signals, all of which I brought to the top of the box via empty PIN recepticles. These I joined to a breadboard with telephone wires where they could access a 6800 uproc which was built on plexiglass and also had a data bus an address bus and a couple control lines. Later, I installed two 25 DB connectors to connect the black box to the 6800. It worked great, but I learned from this experience that if I were ever to do a similar project, it would be through a simple serial port so as to avoid all those external wires!

The EEPROM burner I built a few days ago is the first one I've built that didn't have the ability to run the code in the EEPROM after burning it.

I found you were right about posting pictures in JPEG. With my software I cropped a 3 MB photo down to 200 KB and then resized it to 75% and got it down to 100 kB or so. I hope it's readable. I attached it below. It shows the solution I came up with to initialize the serial port. Both RS and R/W* have to be held low while the defining byte is writen into the ACIA's control register. After that it should be clear sailing, I hope.

Yes, you can use any CPU you want. The only requirement is that you need something like the Z80's WAIT signal, to delay bus transactions until the next byte from the PC is available, but most CPUs have that.

The 6800 uses a HALT* signal for this. I would go with a Z80 if I had one, but I don't. I want to use what I already have on hand. I have three 6800s and when they're gone I'll probably buy more, since by that time, I'll have written an assembler for it and have become completely familiar with its code and architecture. I noticed they cost 7 dollars at Jameco. This won't break me.

That's actually what I do. The last couple of days I've been trying to simplify how I do it, so that I can post the schematic to my web site. I think everyone should want to do it that way, since it really speeds up development to not have to swap ROMs between the programmer and the test system, but people seem to like EEPROM burners instead.

I'm looking forward to seeing your schematic. Let me know when you've posted it. I agree that you've hit on the best way of getting it done. I'm still catching up with 20 years of ignorance. I built a 5 volt power supply today out of old parts an a hobby box. I had to scrape some of the leads. That's how old they are!

 

I'm looking forward to seeing your schematic. Let me know when you've posted it.

With some textual description of how it works and a Perl script to operate it:

http://www.ecstaticlyrics.com/electronics/Z80/EEPROM_programmer/

It's probably not what most people expect for a schematic, but I'm not drawing out how to connect all the data and address lines together. Is it fair to assume that someone who can't figure that stuff out probably also isn't able to build this circuit and have it work? Besides, the idea is that you combine it with whatever system you would otherwise build so that you have a means to program the EEPROM, and so it is assumed that you already have the rest of the system.

 

I have looked at your link in the post above and I'm a little confused. I just printed it out and I'll study it. Thanks for the diagrams.