Serial Port Design for Z80 - Questions

He's not kidding. I have a simple Z80, memory and output latches on a breadboard. Wires everywhere, of course:

There's actually more on the board now, since I moved the "ISP" device onto this board as well. Anyways, as far as signal quality, this board runs at 4MHz and works fine for the most part. Occasionally I have had random errors which cause it to freeze. The supply lines are well bypassed, so I'm guessing a signal line (possibly the clock itself) is bouncing slightly too far, corrupting the processor's internal state. Since it's an old NMOS chip, loss of clock =3D frozen up hard and needs to be reset.

What's most peculiar is, for a while, I've had it running a cute chaser on the LED display (scrolling text, flashing lights, that sort of thing). Recently I changed it so it generates pseudorandom noise on the display. Ah, but now it freezes up every couple of days. Sometimes within hours, sometimes a week goes by. Moved around a few wires, now it hasn't frozen since.

Signal quality is always worth keeping an eye on. If you're adding wires to your Z80 computer's bus, be mindful that you're changing its characteristics. More than 12 inches of length will probably lead to errors, even though those errors may not show up for a long time. Random numbers are good at *eventually* finding funny errors; programs running in identical loops forever aren't as good.

Tim

He's not kidding. Signal quality is always worth keeping an eye on. If you're adding wires to your Z80 computer's bus, be mindful that you're changing its characteristics. More than 12 inches of length will probably lead to errors, even though those errors may not show up for a long time.

Tim

While I'm not too swift on electronics, I understand and agree. Currently, I have the sub-board I am building right on the side of the card cage which is probably about 3 inches from the connections to the Z80 bus. I'm hoping that the short distance will be enough to keep away the buglings. Also, this game runs under 2 Mhz, so hopefully that will contribuite to some stability.

Thanks for the info and help!

-Commander Dave

"Commander Dave" schreef in bericht news:8b9da$4adb4823$18d64d18$ snipped-for-privacy@KNOLOGY.NET...

The original Z80 UART (USART) is the Z80SIO. A powerfull device yet hard to program correctly and it requires an external Baud-rate generator.

Instead of that Z80SIO an Intel 8251 was often used. Much easier to program though it has some bugs like all Intel UARTS and their clones at the time. It also requires a Baudrate generator.

The Intel 8250 was used in the first PCs. There were myriads of types (including the clones) all with small differences and bugs. They were harder to program then the 8251. Very hard to program if you had to anticipate for all types and bugs. On the positive side they had a programmable Baudrate generator build in.

When the PC-market boomed, Intel developped successors for the 8250: Among them the 16450 and the 16550. FAIK the 16550A was the first bugfree type. I guess your 16C550 to be a clone of that last one. As they were used in PCs there's a lot of information about them on the net. Look for instance at:

If I had to deal with those old hardware I'd go for a 8251 using a 4060 for the Baudrate generator as IMHO it is the most simple approach. As you have that 16C550 already I guess you will stick at it.

Which brings me to the main question: What do you really want to do? Because adding a serial interface to the existing hardware does not solve anything on its own. You will need to program a kind of monitor in the Gorf that communicates via that interface. Accepting commands and returning results. Then, when you want the Gorf to perform its original function, you need to get the firmware via the serial interface, store it in RAM and then pass control to it. I do not know the hardware of that Gorf but I suppose you will need to do some real hardware modifications. Not to mention the requirements if you want to do some debugging.

BTW. Next time you want to post the same question in several newsgroups, address them all at once instead of one at a time.

petrus bitbyter

Indeed. But through hole PLCC sockets also use a 0.1" grid so they should fit on you breadboard.

Or you could buy or a built a logic probe so you can at least see the level of a signal and whether it is changing.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------

Indeed, one can do a lot with just a logic probe. With one, it becomes possible to have some answers to basic questions like: Is the chip getting a clock at all? Or, is there an occasional write strobe?

Radio Shack used to carry them (hands up, everybody who is surprised that they don't any more) but there are some inexpensive on-line sources such as and

--
Rich Webb     Norfolk, VA

When I was considering UART's and based on my low level of experience, I decided against the Z80SIO because it looked to be much more complex than other solutions.

I considered the 8251 as there are tons of old Z80 books with instructions on exactly how to interface and program the 8251 to the Z80. I decided against it because the 8251 seemed to be an old chip and I wanted to try to stay with something that would be easily obtainable from mainstream companies like Digikey.

I think I have this site bookmarked already, but thanks for the link. Lots of helpful information there. :-)

Yeah, got to stick with it in this incarnation at least. As I said a few lines up, I didn't go for the 8251 because I am thinking it is an obsolete part and it might not be readily available from mainstream sources. I wanted to stick with parts I could get from a mainstream company. I mainly was wondering if there was anything better and newer than the 16C550 that I should have used.

A fellow named Don posted the same question yesterday. I like to modify the code on the Gorf machine and it has been a hassle in the past to burn a new EPROM every time I wanted to test on real hardware. I want to have a serial port attached so I can download code into memory.... kind of a dump and execute type thing. I have modified the original game code so it looks for an extra EPROM in a vacant socket if the debug switch is on. If it is there, it jumps to my code, if not, it just resumes the normal game diagnostics. I would have a monitor/debug program in the extra EPROM to control the serial port. In case you are curious, I have ruled out a Z80 ICE and a EPROM emulator for various reasons, not because they aren't a good idea, but for other personal reasons (which I think I covered in previous postings if you are curious).

Actually, since the Gorf machine already has static RAM (and some dynamic also) on board, the only hardware mods is the connections to the bus from the bottom of the cardcage (about 20 signal wires), power connections (again from the card cage power connector) and the custom EPROM's which are all in original sockets. One of my goals was to make as few changes to the original hardware as possible. As for the debugging, most would be done with the MAME emulator and only code that worked on the emulator would be tested on real hardware which usually requires minimal debugging (just a tweak or two). A simple monitor/debug program would be enough to do the job for me.

Yeah, that's my bad. When I first started looking for an electronics newsgroup to post in, I went to rec.electronics. Then I saw that it was pretty dead there, but then found another I thought might be better and posted it there. Then I found another and another and posted in those. I was a real cluster-flub on my part, but next time I will know which groups are active and will post to all at once as you have suggested. I apologize for the inconvenience.

Thank you for your help and suggestions!

-Commander Dave

Did you ever consider an eprom emulator?

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------

Yes, and decided against it for various personal reasons. I covered that ground in previous posts if you are curious.

Thanks,

-Commander Dave

Mame, the arcade machine emulator, emulates several processors, and the "rom" files are all just files. No more chips.

We are even emulating the Laser Disc based games now.

It is also a great exercise for your programmers to examine the source code of. With all the CPUs emulated, it is interesting to examine each processor's code module.

Awhile back I asked about your software. This is why.

Replacing the ROM chips with RAM chips would allow you to download to RAM as if they are ROM chips.

I am confused, your going to continue to burn EPROMs and debug with the UART ?

I checked all past messages and you said about a ROMulator: "I've considered that option, but for reasons that would be hard to explain, I decided against it. One reason is that the Gorf machine has many ROM slots (it's old technology) and also I'm looking for something that I can leave attached to the game permantly (so to speak). I also wanted to try my hand at actually designing and building something rather than a store bought solution. It's not all about the end result, you see... it's kind of a hobby thing too."

This does not say much about why no ROMulator, but I am still confused about how the UART will be used.

Check out

for a serial monitor.

good luck

don

"CellShocked" wrote in message news: snipped-for-privacy@4ax.com...

Thanks, but I use that already to program. The problem is that there are slight differences in how MAME emulates the hardware and the real hardware. For example (unless it has been fixed recently), MAME doesn't include the Gorf watchdog timer. The bottom line is that I use MAME for most of the programming, then I have to take that code and try/debug it on real hardware. Just because it runs on MAME doesn't mean it runs correctly on real hardware.

It's a good suggestion, but I still need the real hardware. :-)

Cheers!

-Commander Dave

That may differ now that the Laser Disc games are being correctly emulated, since they were RS-232 serial controlled... explicitly.

So, if any of them were Z80, you'd be in luck, and they have indeed come a long way as each year passes.

Make a debugger front end for mame so that you can still test the missing functions.

You could at least get onto R. Belmont and the others' chat site and ask them if certain things are being correctly emulated now. They know more about it than I at that level. All the developers hang out there. They may even be more able to help you with any realware problem you might be experiencing. Those guys are the old guard.

But how would I get the code into the new RAM chips (that replace the ROMs)? Wouldn't I still need a way of doing that like a communications port? But all that aside, there is another reason I can't replace the ROM's with RAM. The hardware has something called "Magic Memory". If you write to the addresses occupied by the ROM chips, it actually sends that information (with possible modifications) to the video RAM area (there are reasons why, but too long to go into that). So I wouldn't be able to write to the RAM in any case. I had forgotten about it until you asked the question again in this post.

No, not at all. The simple answer is that after the serial port/monitor program is working, I will write and compile code on my PC. I will then take that code, use the monitor program to download that code the the machines RAM and then use the monitor program to jump to my code. I might use the monitor program to do a *little* debugging, but it's main function is to download the code into RAM memory of machine and execute it.

Perhaps where you are getting confused is the end result... you see, downloading the code into RAM and executing it is just for testing to see if the code executes correctly and for experimentation. If I do finish a program that I want to make permanant, I would burn it into an EPROM and put it in one of the empty existing EPROM slots. I've actually done this before... for example, I wrote a video RAM test program that specifies which chip is bad in video memory so it can be easily identified and replaced. One of my future projects is to expand the test program and have it integrated into the game so that when the user flips the debug switch, it jumps to my code and runs some extensive diagnostics. There is also the possibility of writing a new (small) game and make it playable from the Gorf game itself. The serial port and ability to download code into RAM is just for testing and development.

Sometimes I just like to do things the way I want to do them. Human's are funny animals. Let me try to list a few of my reasons:

1. Gorf is in a card cage. The ROMulator plugs into the ROM socket, so it would get in the way when I needed to remove/replace boards. I also like to try to fix non-working boards, so I do a lot of board replacement.
2. I want something that I can permantly attach to the game. I don't want to have to remove it every time I pull a card out (pretty much the same as above). The serial port gets signals from the bottom of the card cage so I will never have to disconnect it in normal use.
3. I really wanted to try to build something instead of just using a store bought solution. It's just one of those hobby things... kind of like why people build remote control airplanes when they could just go buy one and get right to flying.
4. If I successfully add a serial port to the Gorf arcade game, I would be doing something pretty unique... and for me that has a coolness factor. :-)

I hope my explanation a few paragraphs up will clear things up. I really don't mean to be confusing on the subject, but I guess there is so much background on the Gorf arcade machine and what I am doing with it that I take it all for granted. And I admit that some of it is because "it's just what I want to do".

Thanks for the link... I will definatly check it out once I get the hardware working. I'm currently waiting on some more parts, so it might be a few weeks.

Again, thanks for all the help and suggestions,

-Commander Dave