Jump to content

Brad Nelson

Members
  • Content Count

    14
  • Joined

  • Last visited

Everything posted by Brad Nelson

  1. Perhaps relevant to this topic (of chip-swapping to fix an XL problem, keyboard or otherwise)…If the chips had been soldered, can any of you recommend a decent but inexpensive soldering/desoldering kit? I mention this as well because I have a Dreamcast that needs a new internal battery. And for some batty reason, they soldered it to the controller board. It’s nice to have that XL working now. I have a main game XL machine attached to a CRT. And it’s very convenient having a second one now that can be dedicated for attachment to a PC via the APE/SIO2PC (serial) interface. Yeah, weird bug. I wonder if the decimal register was damaged as someone (you?) speculated, Bob. I know very little about assembly language, but for that to have been the case, it would seem that that register would have been used not for game logic (or OS logic) but for simple alphanumeric output to the display for most things. I think someone mentioned on this thread (or I read it elsewhere) that certain Atari power bricks could cause damage when they expired. I don't know what happened in this case. The motherboard of the machine that is now fixed didn't look abused or anything. No residue of Diet Coke or anything like that.
  2. Success! It turned out to be a bad CPU chip. Pac-Man Junior (and other games) now keep score correctly. And BASIC no longer exhibits flakey behavior. I ran the FPTEST.BAS program and it passed with flying colors. Many thanks to all of you for the help. It was a bit nerve-wracking pulling and replacing the relatively long CPU chip. While trying to put the new one back in, a couple pins got mildly bent, as careful as I was trying to be. But I finally got it in. I’m sure there’s a proper chip-pulling and replacing technique, but I was simply flying by the seat of my pants. And now (knock on wood…or maybe silicon) I’ve got a perfectly good 800 XL for maybe $10.00 if you count the $5.00 for the one that I just fixed that I got from Goodwill and the one I got a year or so back from eBay for very little. (It was the working drive that came with it at the time that I really wanted.)
  3. Okay, I ran a binary load of BASIC and I still got the checksum value of 192 when running FPTEST. It would seem that the problem is not the BASIC chip. Thanks for the help. I'm going to try to swap in the OS-ROM chip and will report back. Okay, swapping in a new OS-ROM chip did not fix the problem. But, also, I didn't break anything either. Now I'll try swapping in a new CPU.
  4. Thanks. Wow. I can't believe the expertise here. I'll try that, Russg.
  5. Many thanks, rdea6. That’s a great chart. I now know for sure which chip is which. I can’t imagine the problem being the BASIC chip since games exhibit the same odd behavior even when booted without BASIC loaded. So my working theory (based on the advice I’ve been given here) is that either the OS-ROM chip is screwed up or the one of the CPU registers is messed up. Because the ROM chip is near one of the keyboard chips that was bad, I’m going to start with that and then report back. That could be a day or two.
  6. Okay, I didn’t notice the numbers you listed with your earlier post. I found a chip with the number “CO61598B-29, which I assume is the ROM chip. I was able to pull it off the “parts” XL without much problem. The only chip I can find that has a number anywhere similar to “CO14806” is one marked “CO-14806-12.” Is that the CPU?
  7. Yes, I was running that FPTEST.BAS program from an H-drive via the emulator. When I removed the lines 60, 70, 80, and 90 it worked just fine on the emulator and gave the correct checksum value. That program also ran without an error message on the bad hardware XL. It gave a final checksum value of 192. But there was something strange about it because on the emulator XL, it took a good minute or so to run the program. On the bad hardware XL, it gave the value of 192 almost instantaneously.
  8. Swapping the OS ROM chip sounds good. Is the chip identified as such on the motherboard? Is it a soldering job? Thanks again for the advice, Russg. I have an old “parts” XL that I can draw from for this…if swapping the chip doesn’t require soldering. If it does, then I need to practice on something first.
  9. Sorry, Russg. The problem was on my end. I originally had downloaded the BAS file to my Mac. For whatever reason (even when I took the zipped file and unzipped it on my PC), that was the problem. When I booted up my PC and downloaded straight to it, the BASIC file worked just fine. Using the serial cable and APE I loaded, listed, and ran the FPTEST.BAS program on the bad XL. It immediately gave me an error. There's certainly something bolluxed up so that Atari BASIC programs do not run right or at all. I also ran this on my Atari800Win Plus emulator and it ran for quite a while (20 progress-bar "dots") but eventually ran into an error 130 at line 70. I just assume that the program is meant for hardware, not emulators. Thanks for you help. Any other suggestions?
  10. Thanks for the suggestion, Dragonstomper. I couldn’t get that BASIC program to load, even on a good machine. What version of BASIC is that? I'm thinking that it isn't Atari BASIC.
  11. Thanks for the suggestions, Bob. The bad XL passed the ROM/RAM test. (By the way, what does a failure look like? I’ve never seen that.) I tried programming a for/next loop via BASIC on the bad XL but got an error (error #3). I had to therefore manually peek at the first 10 addresses. This is what I got. The good XL that I have is the first number. The bad XL is the second number. They are separated by the backslash character. But all other characters are exactly the output that I got. Peek 55296: 161 / 192 Peek 55297: 219 / 15:1 Peek 55298: 32 / 1499 Peek 55299: 187 / 192 Peek 55300: 219 / 15<7 Peek 55301: 176 / 1499 Peek 55302: 57 / 15;6 Peek 55303: 162 / 377 Peek 55304: 237 / 15:2 Peek 55305: 160 / 1517 Here’s the simple little program I had typed in. It worked on the good XL 10 FOR X=1 TO 10 20 PRINT PEEK(55295+X) 30 NEXT X When I re-list this on the bad XL, everything is the same except the line numbers are listed as: 10 180 190 It will do simple addition and subtraction in BASIC on the bad XL for answers under 20. But it will do some (but not all) division with answers above 20 just fine. I’ve not spent enough time with this to come up with a rhyme or reason for what it’s doing. A failing decimal mode makes sense to me, but I don’t know what that would look like. Maybe it looks like this. If so, are their any non-soldered chips I could try swapping?
  12. Bob, I'll try running the internal memory test, but I *think* I already did that. Still, it can't hurt to do it again. And there's no sign of the OS being hacked. Yes, you would think a computer's inability to do math would make it fail on power-on and be unable to play a game. But the computer works just fine. It plays every game I throw at it. It doesn't crash. But it just does bad at math at least in regards to the *output* of the math to be numerically displayed. I have no clue as to the inner workings of these things. But it would seem to be some kind of output problem only. If the 800xl were incapable of doing precise calculation, the machine just couldn't run and it couldn't play a game. I've never seen anything like this.
  13. Wow. I’m so lucky I found this thread. I found an old 800xl in a Goodwill store and bought it for $5.00 several months ago. It works but it had two columns of keys that didn’t. I swapped in a 4051 chip from a “parts” XL that I have and the keyboard is now totally functional. Luckily neither was soldiered to the board. Thanks for the expert advice, Urchlay. But this machine has one more issue, and it’s an odd one. Some of the games (but not all of them) do not display the score correctly. I’m playing Pac-Man Jr., for example, and you still *logically* get the extra man at 10,000 points (you can tell about how long this normally takes) but the score increases so fast that at the point you get the free man the displayed score could be a couple hundred thousand. And it increases in huge increments. It does this for many games, not just Pac-Man Jr. I can confirm that something is messed up because if you type “Print 10 * 2” in BASIC you get 180 as an answer. 20 times 2 is 200, by the way. I don’t see a rhyme or reason for what is going on. But the machine functions fine in all other ways. It will play any cartridge I throw at it. Is there some chip that could be causing this? Is it one I could try swapping out?
  14. I’m very much amazed and appreciative that people are still creating original (or derivative) works for the 8-bit Ataris. And it may be shocking news to some, but people who do so need to at least recoup their costs and it is their right to make a profit. Yes, due to demagoguery, many see “profit” as a dirty word. But it isn’t. I’m hoping that this 8-bit version of Pac-Man will be released again as a cartridge for the Atari 800 series of computers. If it’s priced within about $40.00 or so, I’m in.
×
×
  • Create New...