Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store

qberries

New Members
 View Profile  See their activity

  • Posts

    10

  • Joined

  • Last visited

Recent Profile Visitors

888 profile views

qberries's Achievements

Space Invader

Space Invader (2/9)

1

Reputation

  1. qberries
    Only a month later....but finally SUCCESS!! It was just RAM chip U25 in the end! With the help of Allen and some of his good RAM chips and sockets he sent me, the Bally is now running without screen artifacts on lines 5-8. Thanks to Allen for initially pointing me to the RAM as the culprit in the first place and Adam and Michael for all their input to help me understand the system to allow me zero in on those 2 chips. I could have been done a month ago, but apparently I first had to go through the trial of learning the art of desoldering chips from a double-sided PCB after hours of initial failure. That was not fun! But with tips from Allen and a new desoldering/suction station, I was finally able to get the chips out to swap and test them this past week. In any case, after getting the U25 replaced tonight, screen artifacts are now history!
  2. qberries
    Thanks Adam. The FAQ was helpful but looks like I will need to learn assembly language to appreciate Fenton's AstroBasic source code. Yes, you are right, incredible amount of effort and creativity by the developers to squeeze out the maximum capability given those constraints. In any case, I can't seem to narrow my glitch down anymore than probably related to RAM chips U24 and U25 so will try replace those with Allen's help and guidance. Wish me luck!
  3. qberries
    Thanks Adam. That is actually good to hear as I was worried this was perhaps a result of something wrong with the address chip or the data chip. I didn't even realize that BASIC is stored there, didn't find it in the Nutting Manual that I could find, so need to understand the system better. Any suggestions on links to an article or doc that describes the memory handling like that? For example, I am interested in how the system ignores painting something on the screen if there is BASIC code in that part of the screen RAM? Thanks Cliff
  4. qberries
    Thanks Adam and Michael. I'll check the color of the pixels. One odd thing I noticed that may be another clue. If I Poke any values in the screen ram area in those top 7 lines when running the Basic program that does the Poking I produce pixels as expected but then some of the text in my Basic program is altered, question marks added, etc. on some of the lines of the program and have to fix those lines to rerun that program. I don't have that problem when Poking below those affected top 7 lines. Any ideas?
  5. qberries
    Hi Michael et. al.. Finally had some time to investigate this "stuck" pixel problem further before I started to swap any RAM chips. I couldn't try SetScreen but I was finally able to determine which lines and which pixels are being affected: On the display area, Michael is correct that lines 6 and 7 are affected for the first 16 bytes then only line 6 is affected for the next 16 bytes (bytes 17 to 32) then lines 5 and 6 for the last 8 bytes (33 to 40) All other lines are fine As far as pixels affected on each line, it is always pixel 0 (1st one from the right of the 4 pixels per byte) for every one of the 40 bytes per line. The "apparent" color of the pixels is program dependent...black if I am running Bally Basic, yellow if Incredible Wizard, red (I think) if Grand Prix, etc. So, if this were the only problem wouldn't this imply chips U24 & U25 ? But now here is the odd thing. If I PEEK any of the offending pairs of Bytes, the value varies. For example, in the Basic environment if I PEEK Line 7 Bytes 13 & 14 (memory address 16636 & 16637)..sometimes I get a value of 512 and sometimes I get 0 and sometimes I get a value 2. This also happens on lines 5 and 6 as well. This actually confirms what I am seeing as each pixel 0 is not steady and seems to be wavering on the screen, going from on to off a few times a second. Apparently, the Pixel 0 of each of the bytes in the pair I am PEEKing can turn or off independently...thus why I get more than two values. Pixels 1,2,& 3 don't waver at all and are always steady. Hoping Michael can help diagnose if this points to just a U24 & U25 issue or other possible chips given the behavior. Thanks Cliff
  6. qberries
    Thank you Michael (and Adam). That is very helpful. I will try the SetScreen2/3 approach to zero in on it.
  7. qberries
    Oh, I forget. Here is also some history on David's brother Bill that I found interesting since they joined forces for awhile. https://allincolorforaquarter.blogspot.com/2016/06/the-ultimate-so-far-history-of-nutting.html https://allincolorforaquarter.blogspot.com/2016/06/the-ultimate-so-far-history-of-nutting_10.html https://allincolorforaquarter.blogspot.com/2016/06/the-ultimate-so-far-history-of-nutting_21.html All these links are from the work of Keith Smith who has a blog called the Golden Age Arcade Historian: https://allincolorforaquarter.blogspot.com/
  8. qberries
    This may have been posted already but I didn't see it in our forum. I came across this 6 part article on the history of Atari's Night Driver that also has some interesting history on Dave Nutting and Jamie Fenton. Dave Nutting: https://allincolorforaquarter.blogspot.com/2014/07/the-pre-history-of-night-driver-part-4.html Jamie Fenton: https://allincolorforaquarter.blogspot.com/2014/07/the-pre-history-of-night-driver-part-5.html
  9. qberries
    Thanks Adam and Ken for both of your posts. I am trying to not take too much risk in de-soldering every chip but understand that may be necessary in the end. Allen has suggested using the KINGST LA1010 logic analyzer and given me some guidance on finding the bad chip by comparing pins 2 and 14 of the RAM chips to the corresponding pins on U23 which tends to be more likely to be fine, although he says that is not foolproof. I'm really not that well versed in digital electronics, but could one run a routine using POKE in the screen RAM that turns pixels on and off in that same screen area and then somehow "measure" each chip until you find the one that shows changing bit values to identify it?
  10. qberries
    Hi All. First time poster here. I recently bought a Bally. It has the overheating problem, but with a laptop cooler and having removed the RF shield it seems to run fine enough to play games without crashing. However, it has permanent, frozen stuck pixels at the top of the screen in the MENU screen and in every game (see pics). And these pixels annoyingly interact with and affect the game mechanics. Allen has been nice enough to work with me and suspects a RAM issue and suggests replacing the MK4096N-15's I have. I'd like to keep de-soldering and soldering to a bare minimum so does anyone know which of the 8 physical RAM chip of U24 to U31 would relate to the top of the 1/8th of the screen with the screen map? According to the Nutting Manual the screen RAM takes up 4K and there are 102 lines on the screen with each line using 40 bytes. So would it go sequentially top to bottom starting from U24 with each chip representing about 13 screen lines or am I missing something? Thanks, Cliff
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...