Serial Port Design for Z80 - Questions
in [Design]
|
From: don on 20 Oct 2009 22:13 Commander Dave wrote: > "petrus bitbyter" <pieterkraltlaatditweg(a)enditookhccnet.nl> wrote: > >> 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. 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. > > 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). 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 http://www.noicedebugger.com/ for a serial monitor. good luck don
From: Commander Dave on 20 Oct 2009 22:27 "CellShocked" <cellshocked(a)thecellvalueattheendofthespreadsheet.org> wrote in message news:u6msd5t834j4q2n1m9qimevdcra34c097q(a)4ax.com... > 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. 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
From: CellShocked on 20 Oct 2009 22:41 On Tue, 20 Oct 2009 21:27:33 -0500, "Commander Dave" <cmdr-dave(a)spamcop.net> wrote: > Just because it runs on MAME doesn't mean it runs correctly on >real hardware. 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.
From: CellShocked on 20 Oct 2009 22:45 On Tue, 20 Oct 2009 21:27:33 -0500, "Commander Dave" <cmdr-dave(a)spamcop.net> wrote: > Just because it runs on MAME doesn't mean it runs correctly on >real hardware. 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. http://www.bannister.org/forums/ubbthreads.php
From: Commander Dave on 20 Oct 2009 23:10
<don> wrote in message news:uMKdnTRT6Pql80PXnZ2dnUVZ_uydnZ2d(a)forethought.net... > 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. 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. >> 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). > > I am confused, your going to continue to burn EPROMs and debug with the > UART ? 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. > This does not say much about why no ROMulator, 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. :-) > but I am still confused about how the UART will be used. 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". > Check out http://www.noicedebugger.com/ for a serial monitor. 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. > > good luck > don Again, thanks for all the help and suggestions, -Commander Dave |