I was wondering if anyone would be interested in participating in a group design project. I call it the Black Box. But, essentially, it's a parallel EEPROM programmer that uses a serial port to interface with a host computer.

The EEPROM can then be used to develop microprocessors. It is not code specific so it can program any processor, especially one having an 8-bit data bus and a 16-bit address bus. But at this point I don't see why it couldn't be used with any sized address or data bus.

I'm putting out this invitation to anyone willing to participate. I anticipate using 15 or 16 chips, but I think fewer are called for, given certain changes from what I have in mind.

I advocate The Black Box using a serial port to interface with a host. If you don't have one you can buy one that connects to a usb port for about $25. This ACIA then places addresses and data in registers according to the logic generated by a sequencer. The latches output to an address and data bus extenal to the black box and placed next to a small breadboard. You use solid telephone wires to connect the busses to the EEPROM stuck in the breadboard. The busses are just PIN sockets.

The black box can both read and write to the EEPROM. The need to write to it is obvious, but reading is necessary for verification by a small software program in the host.

Below is a general block diagram of the idea. If anyone is interested, let me know.

 

I'm looking for participants in a group forum project. The end is to design an EEPROM programmer by interfacing a black box to a host computer. The thread is in the Projects forum under a title that is something like Group Forum Project. I'd sure appreciate your input!

 

One thread is sufficient.

hgmjr

 

You just wiped out a very long and interesting thread. Shame on you.

 

I think this is the thread that you were speaking of. I have reinstated it as the primary thread.

I would still request that in the interest of confining the discussion to one thread that you make this your only thread on this topic.

hgmjr

 

The block diagram seems to be lost.

I'm not too interested in helping to design something, but I've built a few EEPROM programmers for Z80 projects, so I think I have a few useful ideas. Whether you'll like any of them, however, I don't know. ...but, here's what I've done, and what I'd recommend you do, for whatever it's worth:

The first I built using the parallel port. The PC would, sending the correct signals, use the BUSRQ signal to take control of the data bus, write the bytes to the EEPROM, then reset the CPU. It worked, but just barely. The parallel port is rotten, just barely working for anything you might use it for, since the voltages suck. Every program had to display a checksum because so often the code was written incorrectly.

The second used the serial port. It used a collection of 74-123s and some shift and latch registers to decode the serial data stream. When serial bytes were first detected, the CPU was reset, and afterwards, all memory reads were redirected to the serial data latch, activating the CPU's WAIT signal until the byte was actually available. The PC would sent a byte stream of Z80 instructions which wrote the bytes into the EEPROM, which was relocated to a different address space during the process. Once serial data stopped arriving, the circuit would reset the CPU again, and the program would execute. It was far more reliable than the parallel port version, and so I used it for quite some time. However, the circuit is the most complex thing I've ever built.

The third worked much like the second, but replaced the serial port with a FT245RL. It's much faster than a serial port, and provides an 8-bit parallel I/O port, and so there's no messing with serial data, which makes the circuit simpler. So I also configured the circuit to supply some RAM when in programming mode, so that I could first send a Z80 instruction stream that wrote a small program in to RAM, then that program could read data from the port and program the EEPROM 64 bytes at a time, which turns programming a chip from something that takes five minutes into something that takes five seconds. (Each byte requires a certain amount of time for the burn process, but it can burn 64 bytes in parallel.) I also added the ability to activate the read-only mode on the EEPROM so that the Z80 couldn't accidentally write data into it.

The fourth used the FT245RL along with an AT89S52 to replace most of the logic. It uses the BUSRQ on the CPU, and supports fast programming and read-only mode, and, theoretically at least, it should be possible to have it monitor RAM bytes while a Z80 program is running. I'm not all that happy with it, mostly because of all of the pull-up resistors I had to use because of the AT89S52's weak outputs.

I'd assume you want something someone can build without already having a programmer of any sort. That leaves out the AT89S52, but you can still use the Z80 if you feed it an instruction stream over an FT245RL. Decoding serial data with logic chips is a real pain, so I wouldn't suggest it. Just use the FT245RL and you get a modern USB interface without any dual supply voltage nonsense. If you use Linux, you can use a UDEV rule to make your programmer show up with a specific device name rather than the generic /dev/ttyUSB0. It's nice when your software just knows which device it should access rather than have to inquire about which serial port it is connected to, leaving the user to wonder which port is which.

You can use a Z80 memory map like this: EEPROM from $8000 to $FFFF, SRAM from $4000 to $7FFF, and $0000 to $3FFF accessing the FT245RL, activating the CPU's WAIT when a byte isn't yet available or when the CPU wants to write one but the FT245RL isn't ready. Then just send an instruction stream that writes a program into the SRAM, then have that program read/write to the memory range for the FT245RL to communicate with the PC and program the EEPROM. Having a program run by a CPU rather than logic chips means that you can make use of special EEPROM features like fast multi-byte programming and write protection, and reading EEPROMs for verification is simple enough as well.

As far as cost goes: The FT245RL is $4.50, or $20 for the UM245R development board (it's a surface mount chip). Z80 CPUs are $2.50 for something Jameco pulled out of some garbage or $10 for a nice new 10 MHz CMOS from Mouser. SRAM is $10 for the low-power CMOS type, I forget what the cheap stuff costs, but it's really cheap since it used to be used as cache RAM on 486 motherboards. Wiring involves just a few chips: a 2-to-4 decoder for the memory mapping, some logic gates / inverters to piece it all together, and some sort of reset circuit for the Z80, a clock crystal, and a lot of "connect D5 to D5 and D5 and also D5" and the like.

I'm not sure how much EEPROMs differ, but the ones I used are Amtel's AT28C256. They cost about $10, can be written in 5 seconds if you program in 64 byte blocks, and they feature software write protection. Supporting just this one chip is easy enough, but if you want to support a lot of others, obviously that would be more work. I don't see a problem with only supporting one chip. What isn't 8-bit with a 64k address space? I mean, that you might actually want to use this for. The 32kB EEPROMs are all there are as far as I'm concerned.

 

Hello, Syniva, glad to meet you! I attached the block diagram of my original idea. I used a serial port because I don't know how to use a USB port as yet. I'm just getting back into microcomputers. Ten years ago I made a RAM programmer and interfaced it with a PC. The RAM held the OS and programs downloaded from the host. It was based on the PC's printer port and required way too many wires between my old black box and the M6800 processor I was working on. I wanted to make a full-fledged PC with KB input, screen monitor, and ff drive. But I got depressed and bagged the whole project before it was finished.

I like your ideas about using a USB port, but I need to look into it. I already bought a USB to serial port interface but it hasn't arrived yet. It represents a 30 dollar investment so I think I'll go ahead and use it.

The proposed 'Black Box' EEPROM programmer will program any parallel chip such as the 28C17A and it's big brothers. I propose putting a small breadboard on top of a project box and interfacing it via DIP sockets and telephone wire. The DIP sockets will contain the address bus, the data bus and the control lines. A 16-pin socket for the address and another 16-pin socket for the data and control lines. The box will have a couple switches for read/write and hardware reset. Also, a 9-pin serial port connector.

It works together with a C++ software program in the host. Basically, the host sends a byte, the BB puts it in upper address register, the host sends another byte and the BB puts it in the lower address register; the host sends another byte and the BB puts it in the data register. Then the byte is sent to the eeprom with along with the addess to put it in. Round and round it goes until the EOF.

The sequencers perform the hardware logic step by step. One sequencer is for read, the other for write. Note the latches are actually bidirectional and 3 state, each one being made up of two 74373 octal D latches.

Well, there it is. Please let me know what you think. I'm quite interested!

 

This sounds like a great project!

I'm interested in how it comes out, but I don't think I could be part of it as a group project, because I'm in the middle of a project of my own, learning how to get a microcontroller to operate and read a ATAPI CDROM drive.

The diagram looks pretty much what I did when I made an EPROM programmer, except that I used the PC parallel port, and the EPROMs I used needed something like 12.5 volts to be applied to a programming pin, so my board had to have extra circuitry for that.

I never had reliability problems with using the parallel port, but it has its share of annoyances, like if you use Windows, you can't do very fast or very fine timing with it, and for newer Windowses like Win2K and probably later, Windows by default blocks access to the raw IO ports, so you have to jump through a few more hoops to gain access to it.

But for my EPROM programmer, it worked perfectly well.

 

Hi Dave! Thanks for the encouragement. I thought it was a good project to start with since I'm getting back into microprocessor design. The ability to program an EEPROM gives me the ability to design microcomputers, etc. As I mentioned above, I, too, used the parallel printer port to do this about 10 years ago. The project worked, but I discovered I would have had an easier time of it if I used a serial port.

I have attached a page showing one of three bidirectional octal latches and their controls. This one is the data bus. The other two are upper and lower address buses respectively.

By the way, Dave, good luck with your project!

 

I used a serial port because I don't know how to use a USB port as yet.

You should look at the FT245RL. It works pretty much like the ACIA, except that it works for USB instead of serial. On the PC side it shows up as a serial port and on the microcontroller side it shows up as an 8-bit I/O port. It's so nice, you'll never want to use serial ports again.

I wanted to make a full-fledged PC with KB input, screen monitor, and ff drive.

Here's a pic of a Z80 system I put together a year or two ago:
http://www.ecstaticlyrics.com/secret/Z80_system.jpg

I don't have a photo handy, but I've built an I/O card so that it can access SD cards. They're really easy, surprisingly. I even made a "BIOS" ROM that just copies the first 32kB from the SD card and runs it, sort of like a PC "boot sector" except not the bare minimum of a single sector. The plan was to have that be a program that displays a menu and allows me to chose from all of the software on the card, but so far all I've done is bootable cards that print a sentence or two on the LCD as a test.

I also made a Z80 system that is round:
http://www.ecstaticlyrics.com/secret/Z80_bus_window.jpg

The most interesting thing is that the bus connectors are address decoded, so what slot you put a card in determines which port address range it gets. This has the advantage that you often don't need any address decoding on the card, and so the I/O cards tend to be really simple. The one for SD cards has only the SD card slot and two latch chips. The one for the LCD display just has a circuit to generate the negative contrast voltage, but otherwise just rearranges the pins between the Z80 bus connector and the LCD connector.

I got depressed and bagged the whole project before it was finished.

I know what that's like. I hate PCs, and I'd love to replace them with something a lot cooler, but it's a seemingly impossible task. So I've settled for just using PCs for what they are: cheap general purpose terminals. I use the PC to write and compile code for the Z80, and let the Z80 do things that PCs suck to much to do. It's a lot less depressing that way. Less time wasted trying to re-invent the PC and more time spent working on cool little projects.

I propose putting a small breadboard on top of a project box and interfacing it via DIP sockets and telephone wire. The DIP sockets will contain the address bus, the data bus and the control lines. A 16-pin socket for the address and another 16-pin socket for the data and control lines.

Do you really expect to be using a lot of different ROM chips with it? I'm a fan of wiring stuff on solderless breadboard and leaving it, but to make something half-permanent and half-temporary like this just sounds yucky. ...but, I guess anyone can wire it together in whatever temporary or permanent way they like. It's the schematic that is important, not the implementation. People like me who only care to use one chip can wire a socket for just that one chip.

However, I'm worried about "portability" nonsense. For example, libpng is a pain in the butt to use because, in the interest of making it portable to systems that don't actually exist, the thing supports any bit depth and any bit ordering and any byte ordering, and it's just a nightmare. If this is designed for people creating home-made systems, then I imagine support for 32kB 8-bit chips is all the vast majority of people need. It isn't like there's a lot of money to be saved by using 8 kB chips instead, and I don't think there even are 16 or 32-bit EEPROMs, but instead you have to use two or four in parallel. I just wouldn't complicate the project by adding compatibility for things people don't need. Judging from my limited experience, people just need to burn an EEPROM, any EEPROM, for use in systems they build, and they just don't want to pay $300 for an EEPROM burner. So something that is simple to build and designed for just one EEPROM is just what they need.

The sequencers perform the hardware logic step by step. One sequencer is for read, the other for write.

I don't see much detail on that, unless I'm just not looking closely enough at the schematics, but I think it's where this can get really complicated. To transfer a byte into a latch, you need multiple steps. The ACIA has to be told to put the byte on the bus, the latch has to be told to latch it, then the ACIA has to be told to remove the byte. At the least, the byte has to be on the bus for some time after the latch is told to do its thing, so at least two timing steps are required. I suppose it is possible, but I've never sequenced anything with decade counters and been happy with it.

What I'm talking about doing with using a Z80 for the sequencing is really simple, and it gives you a CPU in the EEPROM burner to do more complex things like fast burning and write protection. Check out the attached schematic, it's really simple. (...and hopefully it's correct since I just now drew it. I've built it before, but I've never drawn a schematic since it's so simple.) What isn't in the schematic is just a reset circuit for the Z80 and the wiring of the address and data pins which is just connecting all similarly named pins together and so it's really simple too. The software end is tricky, but only one person has to do that, and I have some crummy Perl scripts that technically already do it, just in an overly-complicated, poorly-written and Linux-only way.

Anyway, though my idea doesn't call for any latch registers, I like to use '573 and '574 since the pins aren't arranged all absurdly like with the '373 and such. The '573 is active-high level triggered, the '574 is positive-edge triggered. I usually use them for I/O ports, using the '573 for input ports where I just tie the latch enable high, and the '574 for output ports where I use the write signal to drive the edge-triggered latch.

 

OK, I might have lied about not wanting to help with this. I got bored so I went ahead and built it, and fixed up the programming scripts so that they're half-way presentable.

Here's a picture of it:

http://www.ecstaticlyrics.com/secret/eeprom.jpg

It's not too much, only two pieces of solderless, but the wiring is unforgiving. Screw up one connection and good luck figuring out what you did wrong. ...or, well, every time I mess something up, simply going over every connection one at a time would have caught the problem, but I'm just too dumb to do that. Instead I insist on figuring it out with the oscilloscope or with some special programming. So I spent hours writing code that eventually figured out that the SRAM wasn't working, then with literally ten seconds of verifying connections to the SRAM, I realized the OE and CS were reversed.

Anyway, it isn't a big project, so someone with no soldering skills can just spend $15 on solderless and keep it that way. It's also a bit easier to insert the EEPROM into the solderless than into a standard socket.

Here's the programming scripts (for Linux only):

http://www.ecstaticlyrics.com/secret/eeprom.tar.bz2

I recorded 3.8 seconds to burn and verify, and 1.0 seconds to read and verify, with another 5 seconds in 10% of cases to unplug the thing and try again, since Linux's FTDI driver is lame. ...but, even with the occasional hiccup, it's still faster than serial.

 

You should look at the FT245RL. It works pretty much like the ACIA, except that it works for USB instead of serial. On the PC side it shows up as a serial port and on the microcontroller side it shows up as an 8-bit I/O port. It's so nice, you'll never want to use serial ports again.

I believe you're right. I downloaded the FT245RL data sheet and I'll study it. I realize I'm out of touch with today's technology. I had a hunch I wanted to use a USB port but I couldn't find any hands-on literature about it until now. This data sheet -- 25 pages -- is an eye opener.

Here's a pic of a Z80 system I put together a year or two ago:
http://www.ecstaticlyrics.com/secret/Z80_system.jpg

Cool.

I don't have a photo handy, but I've built an I/O card so that it can access SD cards.

Pardon my ignorance, but what are SD cards?

They're really easy, surprisingly. I even made a "BIOS" ROM that just copies the first 32kB from the SD card and runs it, sort of like a PC "boot sector" except not the bare minimum of a single sector. The plan was to have that be a program that displays a menu and allows me to chose from all of the software on the card, but so far all I've done is bootable cards that print a sentence or two on the LCD as a test.

Reading your stuff, I take it you always make ROM be 32k bytes. It seems to me that if you restrict yourself to a 16-bit address and an 8-bit data (as I do), then you lose the flexibility of having as many bytes of RAM as possible for programming. The early PCs, in order to provide for greater programming possibilities with their limitted memories, made up for this by having boot-strap loaders, and even then the operating systems were kept minimal.

I also made a Z80 system that is round:
http://www.ecstaticlyrics.com/secret/Z80_bus_window.jpg

Cool, again.

The most interesting thing is that the bus connectors are address decoded, so what slot you put a card in determines which port address range it gets. This has the advantage that you often don't need any address decoding on the card, and so the I/O cards tend to be really simple. The one for SD cards has only the SD card slot and two latch chips. The one for the LCD display just has a circuit to generate the negative contrast voltage, but otherwise just rearranges the pins between the Z80 bus connector and the LCD connector.

That LCD display is interesting. Can it do graphics?

I know what that's like. I hate PCs, and I'd love to replace them with something a lot cooler, but it's a seemingly impossible task. So I've settled for just using PCs for what they are: cheap general purpose terminals. I use the PC to write and compile code for the Z80, and let the Z80 do things that PCs suck to much to do. It's a lot less depressing that way. Less time wasted trying to re-invent the PC and more time spent working on cool little projects.

You may have a good point about reinventing the PC, but to me it's all just a way to pass the time. I want to know how keyboards write to PCs (pretty simply, really) and how PCs make CRTs display what they want them to display (haven't done it yet). I want to control a printer and a floppy disk drive with a cpu and integrate this whole system into a single PC in and of itself. I'm not worried about making money at it. And time is irrelavent in that we're all going to die and we can't take anything with us. Naked we came, naked we go. It's just about passing the time in such a manner that my interest is absorbed in something.

Do you really expect to be using a lot of different ROM chips with it?

I like the flexibility.

I'm a fan of wiring stuff on solderless breadboard and leaving it, but to make something half-permanent and half-temporary like this just sounds yucky. ...but, I guess anyone can wire it together in whatever temporary or permanent way they like. It's the schematic that is important, not the implementation. People like me who only care to use one chip can wire a socket for just that one chip.

I understand.

However, I'm worried about "portability" nonsense. For example, libpng is a pain in the butt to use because, in the interest of making it portable to systems that don't actually exist, the thing supports any bit depth and any bit ordering and any byte ordering, and it's just a nightmare. If this is designed for people creating home-made systems, then I imagine support for 32kB 8-bit chips is all the vast majority of people need.

I'm thinking of a generic all-purpose computer. Otherwise, why not use a microcontroller instead of a microprocessor?

It isn't like there's a lot of money to be saved by using 8 kB chips instead, and I don't think there even are 16 or 32-bit EEPROMs, but instead you have to use two or four in parallel.

Again, it's about flexibility.

I just wouldn't complicate the project by adding compatibility for things people don't need. Judging from my limited experience, people just need to burn an EEPROM, any EEPROM, for use in systems they build, and they just don't want to pay $300 for an EEPROM burner. So something that is simple to build and designed for just one EEPROM is just what they need.

I think having 16 address bits available makes for great flexibility in the EEPROMs you can program. After all, you don't have to use all the address lines.

I don't see much detail on that, unless I'm just not looking closely enough at the schematics, but I think it's where this can get really complicated. To transfer a byte into a latch, you need multiple steps. The ACIA has to be told to put the byte on the bus, the latch has to be told to latch it, then the ACIA has to be told to remove the byte. At the least, the byte has to be on the bus for some time after the latch is told to do its thing, so at least two timing steps are required. I suppose it is possible, but I've never sequenced anything with decade counters and been happy with it.

Agreed. My proposed scheme is too darn complicated and leads to too many chips. As I thought it out, the chip count grew exponentially! And that's why I'm changing to another scheme. To wit: The addresses need to be generated on the black box side of the serial port. This gets rid of the 4 address registers and the two sequencers. And, as if complexity wasn't bad enough, there is the issue of initiallizing the 6850 ACIA.

What I'm talking about doing with using a Z80 for the sequencing is really simple, and it gives you a CPU in the EEPROM burner to do more complex things like fast burning and write protection. Check out the attached schematic, it's really simple. (...and hopefully it's correct since I just now drew it. I've built it before, but I've never drawn a schematic since it's so simple.) What isn't in the schematic is just a reset circuit for the Z80 and the wiring of the address and data pins which is just connecting all similarly named pins together and so it's really simple too. The software end is tricky, but only one person has to do that, and I have some crummy Perl scripts that technically already do it, just in an overly-complicated, poorly-written and Linux-only way.

I would love to start this project with an already programmed EEPROM and a microprocessor to direct traffic. But I need to be able to program an EEPROM from scratch so to speak. I have no way of making the UProc do anything until ROM is present.

Anyway, though my idea doesn't call for any latch registers, I like to use '573 and '574 since the pins aren't arranged all absurdly like with the '373 and such. The '573 is active-high level triggered, the '574 is positive-edge triggered. I usually use them for I/O ports, using the '573 for input ports where I just tie the latch enable high, and the '574 for output ports where I use the write signal to drive the edge-triggered latch.

I used the 74373s because they were transparent, not edge-triggered, and in my scheme that was important. But I'm done with that scheme so the issue is irrelavent.

The present scheme is to use the 6850 ACIA in the Black Box to put data on the data bus (or read from that data bus) and to generate addresses with 4 cascaded binary counters. After all, any verification program would be sequencial.

It's the hand-shaking signals I'm working on. When my USB to Serial Port arrives, I will experiment with it and see what's what. I have read the literature, but I need to be sure I understand what is going on in order to build a step by step programmer.

 

OK, I might have lied about not wanting to help with this. I got bored so I went ahead and built it, and fixed up the programming scripts so that they're half-way presentable.

Here's a picture of it:

http://www.ecstaticlyrics.com/secret/eeprom.jpg

Very cool.

It's not too much, only two pieces of solderless, but the wiring is unforgiving. Screw up one connection and good luck figuring out what you did wrong. ...or, well, every time I mess something up, simply going over every connection one at a time would have caught the problem, but I'm just too dumb to do that. Instead I insist on figuring it out with the oscilloscope or with some special programming. So I spent hours writing code that eventually figured out that the SRAM wasn't working, then with literally ten seconds of verifying connections to the SRAM, I realized the OE and CS were reversed.

Anyway, it isn't a big project, so someone with no soldering skills can just spend $15 on solderless and keep it that way. It's also a bit easier to insert the EEPROM into the solderless than into a standard socket.

Here's the programming scripts (for Linux only):

http://www.ecstaticlyrics.com/secret/eeprom.tar.bz2

I recorded 3.8 seconds to burn and verify, and 1.0 seconds to read and verify, with another 5 seconds in 10% of cases to unplug the thing and try again, since Linux's FTDI driver is lame. ...but, even with the occasional hiccup, it's still faster than serial.

I could not download any schematics, only pictures. But I think your design calls for pre loaded PROMs and I can't do that yet. So I have to start with something that will do this via hardware. Can you think of a ROMless way of programming EEPROM?

 

So I have to start with something that will do this via hardware. Can you think of a ROMless way of programming EEPROM?

The only EEPROM in the circuit is the one that you want to program.

The circuit creates a memory layout where any access to the first 16 kB of memory address space is in reality an access to the FTDI chip. So after power-on reset, the Z80 reads its instructions from the link to the PC. The PC sends it an instruction stream that causes it to write some code into the SRAM which it then uses to program the EEPROM.

So it's exactly what you need.

I could not download any schematics, only pictures. But I think your design calls for pre loaded PROMs and I can't do that yet.

Was it the .tar.bz2 file? Here's a .zip instead:

http://www.ecstaticlyrics.com/secret/eeprom.zip

There really isn't much schematic-wise that you haven't already seen, just a text file with some basic instructions. It's really about as simple as the image I posted earlier. You can look at the scripts (they're text files) but they won't do anything for you unless you use Linux. Someone will have to write software to do it in Windows, since I can't. ...and someone might even want better Linux software, really.

Pardon my ignorance, but what are SD cards?

The flash memory cards used in digital cameras, and occasionally in MP3 players and cell phones and such. You can get a 2 GB card for about $7. Unfortunately, the smaller ones aren't much cheaper. I'd love to pick up a bunch of old used 16 MB cards for a dollar or less each, but no one sells them.

Here's a picture of one and my card reader for my Z80:

http://www.ecstaticlyrics.com/secret/sd_card_reader.jpg

You can access them with an SPI interface. They're supposed to be 3.3 volt devices, but I haven't encountered one yet that doesn't work with 5 volts as well. The SPI mode doesn't seem to be well defined. I used to have one card that wouldn't work with the same code that worked with all of the others unless I modified the code so that the other cards wouldn't work. I think I just threw it away.

Since the size of the SD card is so huge compared to the Z80 memory space, I haven't yet seen any point in implementing a filesystem. It's far easier to just put everything at a fixed address. Even the smallish 256 MB cards I have are 8192 times the size of the Z80's RAM, which is probably 100 times as much data as I might ever want to write to one.

Reading your stuff, I take it you always make ROM be 32k bytes. It seems to me that if you restrict yourself to a 16-bit address and an 8-bit data (as I do), then you lose the flexibility of having as many bytes of RAM as possible for programming.

Yes. At first I wanted to load the thing up with more ROM and RAM and use some sort of bank switching, but once I actually started writing code for it, having more than 32 kB of each seemed totally pointless. I've never had to optimize my code to make it fit into 32 kB, and so to expand the address space beyond the natural limits of the CPU would just be silly. There's enough there for anything I might want to do, short of having a multitude of programs to choose from, in which case loading them from an SD card is an option.

That LCD display is interesting. Can it do graphics?

It sure can, though the only photo I have is from when a friend and I were talking about uses for the Z80 and he suggested pornography:

http://www.ecstaticlyrics.com/secret/lcd_porn.jpg
(It's line art nudity, not real porn, for those afraid to click.)

Also, I once made a Perl script to split a video into dithered images to display on the LCD, and send them to the Z80 for it to display. It sort of worked, but the LCD fades out a bit with constant access like that.

http://www.allelectronics.com/make-a-store/item/LCD-101/256-X-128-LCD-PANEL//1.html

The spec sheet that comes with it tells you to set a few bits incorrectly, resulting in the display not doing anything. You have to look through the comments where someone kindly posts a link to better instructions.

I want to control a printer and a floppy disk drive with a cpu and integrate this whole system into a single PC in and of itself.

Floppy drives are really difficult, since they lack on-board controllers. An IDE hard disk would be easier since the controller is on the drive, so you just send it commands. SD cards are the easiest thing I've found (other than EEPROM) and they offer all the storage space you could possibly need, so they're the clear winner.

I'm thinking of a generic all-purpose computer. Otherwise, why not use a microcontroller instead of a microprocessor?

1. You don't have to buy an expensive programming device.

2. You don't have to buy expensive development software.

3. Non-proprietary CPUs mean multiple compilers to choose from.

4. You can't run out of I/O bits, you just add another I/O port.

5. Parallel data access is faster than serial data access.

6. Microcontrollers are for pansies who'd rather be writing code instead of actually building something.

Well, perhaps before anyone gets upset, I should say that I know that microcontrollers aren't for pansies, but I still get that impression every time I look at one. With a small number of I/O pins, its as if the things are designed for people who just want to write a sorting algorithm and don't really care to interface with anything.

I use the AT89S52, which is really the only one I've seen so far that I find to be acceptable, since it is reprogrammable, doesn't require special programming hardware, doesn't require the use of special development software, and has 32 I/O bits rather than the typical 6 or 8, and only cost $1.25. Every other microcontroller I've seen has been unacceptable for most of the listed reasons. As for the AT89S52, it's 256 bytes of RAM mean that it can't so much as access an SD card (with 512 byte sectors) despite the microcontroller-appropriate SPI interface. It's still useful for small projects, which is why I use it, but it's no replacement for a microprocessor system, and other microcontrollers are even less so.

I think having 16 address bits available makes for great flexibility in the EEPROMs you can program. After all, you don't have to use all the address lines.

Adding an output port to my Z80 design would allow the addition of more address lines. It's 15 address lines as it is. Adding one 8-bit latch would bring it up to 23 and may not require any additional circuitry other than the latch chip. At most it'd require another OR gate chip, there are no other I/O ports and so address decoding isn't necessary. ...or, you could remove the OR gate from the Y2 and Y3 outputs of the 74-139, and use Y3 for the EEPROM and Y2 for the latch, which would give you 22 address bits while adding only the latch chip.

That may actually be necessary to program flash memories. I tried looking today, but I couldn't find any 28-pin 8-bit parallel 32 kB (256 kb) DIP flash memories. It seems that 32-pin 512 kb is the minimum. I forgot to check prices, though. If they aren't cheaper than EEPROMs, then I don't see the point in using them.

...but even if I could program larger and cheaper flash memories, I'd probably only use 32 kB of them anyway. If anything, my future Z80 systems will have less ROM so that they can have more RAM to use for programs loaded from SD cards. In fact, I usually have the EEPROM swapped out for an SRAM anyway, since my system uses something like the EEPROM programmer but a little more complex to automatically reboot the Z80, rewrite the SRAM, then reboot the Z80 again. That way I just compile the code and I get to see if it works a few seconds later without having to swap chips in and out of the programmer.

So I really think that more than 15 address bits ares useless, but at the same time, they'd be easy to add, and the schematic could just say "leave this chip out unless you want to program memories greater than 32 kB" which would make it the best circuit for everyone. Also, increasing it to 16 data bits could be done in much the same way, though the added circuitry would be more complex, but again, optional for those who only need the simpler 8-bit programmer.

I used the 74373s because they were transparent, not edge-triggered, and in my scheme that was important.

The '573 is the same way. It's the same latch, just with the pins in an arrangement that causes less confusion when wiring circuits.

 

Well!! I really donno what I can do, but from the looks of it, it seems rather interesting.

Count me in.
I'll do what ever I can to help.
I want to join the group cause I want to learn more.

 

Well!! I really donno what I can do, but from the looks of it, it seems rather interesting.

Count me in.
I'll do what ever I can to help.
I want to join the group cause I want to learn more.

Hi Rif!

I, too, am learning from Syniva. He makes me feel antiquated. He is right on all counts about using the USB and flash memory. I am an old timer. My experience with microprocessor design goes back to the '90s.

Today we can find data sheets on the internet with ease. Back then, I couldn't. I had to write to the venders and ask for the information I needed.

Syniva's solution to programming EEPROMs is simple and elegant. I recommend listening to him. If you're going to make an EEPROM programmer, use the USB port with the chip: FT245SRL.

Unfortunately, I bought a USB to serial port one day before I talked to Syniva. I'm stuck with it and I'm going to use it. I tried to attach a new block diagram, but this website refused to post it. I wrote a note to the website and perhaps this will be fixed. This one is much more simple than the previous block diagram in that it eliminates all those data registers and both sequencers. However, it adds an initiallization of the 6850 serial port. This port resets on wake up but it needs to be told how to configure itself for an 8-bit serial transaction with the host. I don't know how the USB port gets around this, but I suspect there is no need for a configuration as all USB ports do the same thing. This is a plus for Syniva's design.

 

The only EEPROM in the circuit is the one that you want to program.

The circuit creates a memory layout where any access to the first 16 kB of memory address space is in reality an access to the FTDI chip. So after power-on reset, the Z80 reads its instructions from the link to the PC. The PC sends it an instruction stream that causes it to write some code into the SRAM which it then uses to program the EEPROM.

So it's exactly what you need.

Woah! This scheme calls for a RAM chip and a microprocessor to be in the black box. I would rather program the EEPROM directly from the data coming in from the host computer. I simplified my original scheme by generating addresses within the black box. This eliminates all those bidirectional latches and the sequencers. Only the data bus remains as standing between the EEPROM and the ACIA. Both of these chips have a bidirectional data busses.

There really isn't much schematic-wise that you haven't already seen, just a text file with some basic instructions. It's really about as simple as the image I posted earlier. You can look at the scripts (they're text files) but they won't do anything for you unless you use Linux. Someone will have to write software to do it in Windows, since I can't. ...and someone might even want better Linux software, really.

My hope is to learn enough of Visual C++ (free download) to write a program that can do the job.

Adding an output port to my Z80 design would allow the addition of more address lines. It's 15 address lines as it is. Adding one 8-bit latch would bring it up to 23 and may not require any additional circuitry other than the latch chip. At most it'd require another OR gate chip, there are no other I/O ports and so address decoding isn't necessary. ...or, you could remove the OR gate from the Y2 and Y3 outputs of the 74-139, and use Y3 for the EEPROM and Y2 for the latch, which would give you 22 address bits while adding only the latch chip.

I think you're right, except with respect to a general purpose computer.

 

I tried to attach a new block diagram, but this website refused to post it.

Did you resize it first? Images have to be smaller than 100 kB or something like that. Also have to be JPEG or PNG files, I think.

I've always wondered why web sites force users to deal with converting and resizing images. The website could just accept the image, convert it to a suitable format, resize it to a reasonable size, and use that. It'd be a lot more user friendly.

However, it adds an initiallization of the 6850 serial port. This port resets on wake up but it needs to be told how to configure itself for an 8-bit serial transaction with the host.

I never used a serial chip with my serial port EEPROM burner for reasons just like that. I needed something that worked without configuration, so I did this instead:

http://www.ecstaticlyrics.com/secret/crazy.png

Despite all the analog timing, it worked really well. It just required calibration with an oscilloscope after you built it, before it would work.

I don't know how the USB port gets around this, but I suspect there is no need for a configuration as all USB ports do the same thing.

I think USB has a few modes of operation, but the chip figures out what to do all on its own, so you don't have to configure it.

Woah! This scheme calls for a RAM chip and a microprocessor to be in the black box. I would rather program the EEPROM directly from the data coming in from the host computer.

The SRAM speeds up the programming process by a factor of 100. Without the SRAM, you have to program one byte at a time, because the 64 byte programming mode has timing requirements that can't be assured without caching the data. Also, some code in the SRAM polls the EEPROM to determine when the write process has completed to save a little extra time. So, with the SRAM, it requires requires 3.8 seconds to program a 32 kB EEPROM. Without it, it would require 5 1/2 minutes.

(Sadly, my friend's $200 EEPROM burner takes 5 1/2 minutes to program an EEPROM. You'd think that for $200 they could implement the page programming mode, but apparently not.)

Anyway, why do you want to call this "the black box?" Why not something less phreakish like "an EEPROM programmer." It tells people exactly what it is. In any event, I'm not at all happy with the idea of calling my idea "the black box." I'd rather call it "an inexpensive and fast AT28C256 EEPROM programmer." Very descriptive, that name.

 

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.

 

Did you resize it first? Images have to be smaller than 100 kB or something like that. Also have to be JPEG or PNG files, I think.

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

I never used a serial chip with my serial port EEPROM burner for reasons just like that. I needed something that worked without configuration, so I did this instead:

Initialization was easy, just requiring a push button and a 74373 latch. When I can post another schematic this will be clear. 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.

The SRAM speeds up the programming process by a factor of 100. Without the SRAM, you have to program one byte at a time, because the 64 byte programming mode has timing requirements that can't be assured without caching the data. Also, some code in the SRAM polls the EEPROM to determine when the write process has completed to save a little extra time. So, with the SRAM, it requires requires 3.8 seconds to program a 32 kB EEPROM. Without it, it would require 5 1/2 minutes.

That's commendable.

Anyway, why do you want to call this "the black box?" Why not something less phreakish like "an EEPROM programmer." It tells people exactly what it is. In any event, I'm not at all happy with the idea of calling my idea "the black box." I'd rather call it "an inexpensive and fast AT28C256 EEPROM programmer." Very descriptive, that name.

Agreed. Let's call it an EEPROM Programmer, for that is what it is.