jdgabbard

Yeah, as mentioned above I would try cleaning the port and checking the pins to make sure they're not bent out of shape. I had a similar problem with my SNES last week. On that one it turns out it was the solder joints on the cartridge itself that had broken contact over time. Reflowing with a little 60/40 was all it needed in order to make it come back to life.

I do not have the means at the moment for doing any label work. My only printer is a B&W Laser, although I do have a laminator that would come in handy.... Anyhow, I'm looking for someone, or a web service, that can do custom labels without charging an arm and leg.

It was a few bad solder joints. From the looks of it, it has been reworked at least once. I cleaned it up with some 90% isopropyl, applied some fresh flux, reflowed with a little added 60/40, cleaned and tested. Works 100%. Thanks guys, now I'll be set to play some Gradius later.

The solder joints were one of my early suspicions. I'll probably try to tear it down in the next day or two and check. It's worth a try. I'll follow up with the outcome.

This is an unusual problems I'm having with my SNES. At first I thought it might be a dirty cartridge connector, but have since examining I have somewhat ruled it out. The console appears to be the first model with the eject lock. I've haven't played the console a lot, mostly due to lack of games. But after having purchased more games for the system, I have recently started to break the console out once a week or so to play. Now, I'll start with the fact that I purchase all my games from a local shop where they have been thoroughly cleaned and tested prior to my purchase of them. They have several consoles to test the games out on before taking them home. I have cleaned the cartridges as well, and they are spotless. I have also thoroughly cleaned the cartridge connector. It appears clean, and the pins all seem springy and without fault. So that is one of the reasons why I am looking for some help with the diagnosis. When a game is inserted into the console, about 2/3 time I get a black screen. However, this is not always the case. Many times if I push down and gently pull forward on the cartridge, and then power on, I get a proper boot, but then if I let go of the cartridge about 2/3s of the time it crashes the game. So I am pretty certain that this is a connection issue. I haven't torn into the console, but I have attempted to clean the connector through the slot, and it does not appear to have any gunk built up in it. Cloths come out clean without any hint of garbage on them. Of course I guess there could be trash in the lower connector. I do not seem to see any other posts around the net discussing this issue, unless I'm simply looking at the wrong search terms. Anyone have any ideas?

I typically run across code that isn't so much missing important pieces as it is not compatible with newer versions of compilers. This sucks because of convenience. But is usually workable once you get your ducks in a row. Personally I hate it when someone's code isn't documented very well. There is nothing like seeming code that points to some routine that gives no information on what the coder was attempting to do. Sure, I can deduce to a point. But it happens. I usually try to include a description of every routine in my code. What is really nice is when you're looking at someone else's code and you know that the two of you think much alike. It really helps fill in the gaps. I was looking over an assembly file the other night that I found online. I was blown away when I looked at a particular routine and it looked familiar. I pulled up one of my own and checked, there was a 4-Byte difference between the two. But otherwise identical. I'm pretty sure the two of use could conquer the world, and I've never met the guy.

My cousin had a dos PC that was having problems. He asked if I could format the drive and clean it up for him. After running the format utility I asked for his copy of DOS. I guess he didn't understand that he needed a copy. Good thing I knew how to make a boot disk.

I got this running today. As it turns out, it is an issue, I believe, with how he is using the MC6850 which conflicts with my slower clock. I had ordered some of the ST 68B50 UARTs, and tested them in my board. Sure enough, the exact same problem was realized, the board would send data to the terminal, but the terminal could not send data to the board. Having double checked all of my settings over and over, I finally decided tonight that it must be an issue with the RS232. So I decided to take that out of the equation, and wired in an FTDI adapter. Once this was done the board transmits regardless of whether CTS/RTS are used. Even when used, the UART looses about a third of the data. I believe this has to due with how slow the computer is in comparison to Grant's. His is running at four times the speed of my own. I believe this difference in speed is causing a problem where the z80 is still reading from the UART as the next Byte is trying to come in. So fast binary transfers are out of the question on by board. Thankfully, this is an easy fix in software. Simply adding a 1ms delay between byte transfers in TeraTerm resolves all the issues except for speed. I can already read faster than it can transfer a file. But in any case, the board is working.

I generally speaking, I prefer just about everything. From tell all stories down to the datasheets for components used. IMO, the technology of the time was simplistic enough that any educated person today should be able to learn just about whatever they could want to learn about the early systems. But I also really enjoy reading about the impact, or lack thereof, certain machines had. Or machines that were ahead of their time, yet never were successful.

I've seen that before. It's funny, I was just thinking about video integration for my own z80 Computer last night. And I remembered seeing this post some time back. So I took a look at it to see how he interfaced the card. There is another guy who did something similar with a VGA card. The nice thing about that CGA card is that it has Conposite Video out, I'm using it with my IBM XT since I do not have a CGA monitor. Now that I'm done with writing the monitor and the decoding for my external IO bus I am starting to think about the various peripherals I would like to add, as well as software. My front panel monitor takes up about 150 bytes out of 32k. So I have plenty of room for video and serial routines. I'll probably add a serial monitor as well as a version of basic. I just haven't gotten that far at this time. I'm learning everything from scratch, so it is fairly slow going. However, a good starting point is probably Grants rom, since the system calls and the Basic are broken down into two separate assembly files (one for the calls, the other for basic). Modifying the basic to work with whatever I end up going with shouldn't be too hard. The funny thing is, and I can't confirm this since I've never been able to actually get grant's computer working other than displaying the boot message over serial, his ROM appears to have a built in monitor. If you look at his page for the z80, one of the tokens is 'monitor' (or something similar). So that could be a good reason to port his code.

A little on topic...not entirely... But I thought I'd share a video since I got one of my projects running today. It still needs a little work to get the expansion port working (planned for serial I/O and storage), but it is operational. I haven't written the assembly code yet. It is currently examining locations in RAM and displaying the default garbage. I need to write a Memory Clearing routine... But hey, it's been a fun weekend getting this thing going.

I maybe be interested in a few of the laser disks for my cousin. I'm checking now, and will get back to you.

Probably where you see the examples of other computers. Take a look at them, how they operate, etc.

Generally speaking, it depends on two things. How fast you want it to run, and how much power you need it to use. The low current 20mhz models that are sold cheaply on various auction sites will be more than enough for most applications. If you want to simplify things, like James suggested, you can use one of the various flavors of the z180. Again, it depends on what you're trying to do.

Well, if you're looking at doing a z80, then http://z80.info is the place to go. It has most of the information that you will need. Another is Grant Searle's website, found here: http://searle.hostei.com. Obviously reading the datasheet for the z80 family is a must: http://www.z80.info/zip/z80cpu_um.pdf. As well as the actual datasheets for the devices, along with any third party devices you decide to use (as mentioned above, Grant's z80 uses the Motorola 6850 UART). What it comes down to, is you have a lot of reading and research to do. And if you're going to design your own, you'll need to do it.

I think it has more to do with with the 6850 itself in my case. These are not the 68B50s, just the plain Jane 1mhz versions. If I boot it up I get Garbage, unless I am using the Arduino serial terminal, then it displays correctly. However, it doesn't respond to input. I built it about a year ago. Just got around to digging it out and trying to mess with it. Tried out 5-6 different UARTs, all had the same problem. The only difference between my build and Grants is that I patched his ROM to work with a 1.8432mhz XO oscillator instead of the 7.something Mhz. When checking with my Saleae logic analyzer it show the z80 is running and executing code. However, I do not show any activity on the RX line, or the handshaking lines. So I suspect there that there is a bug somewhere that is preventing the 6850 from shifting the polarity of the handshaking signals, and as a result, it's not receiving anything from the terminal. I ordered some 68B50s to see if it fixes the problem. But considering they are old and of unknown origin, there is no way to tell if they are working or not. My experience is many old chipsets were pulled from working systems for a reason....they were faulty. It's a little hard to find new chips of that make in this day and age.

To be honest, I need to sit down and start soldering I have a few SBCs in the works. From Left to right in the photons below: Grant's z80, z80 SBC for 96-pin Backplane, and the largest is a z80 SBC for manually entering in code.

I had a itch to play Rise of the Dragon the other night. It's dated, but still a fun game.

Here is a preview of what I'm working on...

This is a whole pile of nonsense, as James pointed out. Generally speaking, the z80 seems to be the easier of the two to interface to a variety of other chipsets. I typically get away with a single IC being used for decoder logic, that is both memory and I/O. How hard it is can be said to be totallly dependent on what you want to do with it, what features you want it to have, and how thorough your design is. Simplistic machines, Like Grant Searle's 7-chip design are comparatively easy when you put it against any of the more complex designs. That said, I have built Grant's z80 computer, and personally believe it has stability issues. Mine works, with the exception of the serial port that I'm still trying to debug. Currently, as in this very moment, i'm working on a board layout for a 'non-Grant' design, with dual UART, RAM, ROM, 8-bit input port, 8-bit output port, and a USB interface for serial communication. It uses 8-chips as follows: Z80 20mhz 32k EEPROM 32k SRAM Z80 DART (Z8470) FT232RL 74HCT245 74HCT373 GAL16V8 (decoding logic) And a handful of passives and a Oscillator. It's a design that I'm doing as I lay the board out. So it's not guaranteed to work, but based on my previous builds just changing the I/O, which is straight foreword. Here is an idea of where I'm at in the process. Basically I'm down to designing the USB.

Done with your rant now? I wasn't talking about whether 78XXs are made any more. There absolutely are. I was referring to the machines themselves, and trying to preserve the integrity of them. It's his machine, he can do with it whatever he wants. I'm just pointing out my preference to buy new parts to repair machines when they are readily available.

It doesn't matter which software package you use, Opal or Atmel. It will product a fictional equivalent JEDEC file. I've programmed several different makes with the JEDECs created by WinCUPL. Honestly, WinCUPL is better in my opinion due to the simulator.

I get the not having parts on hand. I guess I'm a little, or a lot more, patient than some. I'd just assume order parts from China off FleeBay than robbing a machine that could be fixed. However, I have done it on machines that are beyond repair. To me, it's just as much about preservation as it is getting other machines going. Which itself is preservation too. I just don't want to sacrifice a machine that is capable of being saved. It's not like there are going to be more made... I guess I'm also spoiled having four radio shacks within driving distance, not to mention a surplus electronics store. But not too long ago I live 40mins away from the nearest parts store. I was just fortunate enough to have a job that requires me to drive by it about twice a week. And I absolutely understand what you're saying about only having time on the weekends. I rarely have the time to even do anything then. I did get a chance to draw up some schematics and layout some boards this weekend though. Even got them off to the board house. I understand where you're coming from. Still, you might try some of the troubleshooting guides on the net to revive it if you get a chance.

What makes it not worth fixing? Is there something horribly wrong with it? The reason I ask is that it appears as though you sacrificed one system to save another needlessly, when you could have bought the part at Radio Shack for $2.50. Don't get me wrong, I'm not attacking you. It's just that many of these systems can be easily repaired. And someone surely wants to give them a good home.

I never played Text-Based games in the 80s. But in the 90s-2000s it was Elendor.