Which RAM maps to which part of screen?

[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

[ballyalley]

I recently bought a Bally [...] it has permanent, frozen stuck pixels at the top of the screen in the MENU screen and in every game

 

I've seen this issue before now, but not with so many pixels at one time. If the bad RAM was at the bottom of the screen then the system wouldn't start at all. The only way to tell which RAM chip maps to which on-screen pixel is to use the schematic in the service manual. I'm really surprised that this hasn't been done before now. Here is a link to the PA-1 Bally Service Manual, which also happens to have better scans of the schematic on the same page:

 

http://www.ballyalley.com/documentation/misc_hardware_docs/Bally/Bally.html#PA-1BallyServiceManual

 

Some revisions of the astrocade motherboard have less RAM chips, so it would be great to know which chips hold which area of the screen RAM when/if someone tracks this down.

 

Adam

[kenzre]

The 8 DRAM chips are clustered on the PCB. Using the Service manual they are U24-U31 inclusive. Your particular problem appears to be an address issue. Because they are all in the same row, It may be that one address line is causing this problem. Without a logic analyzer or oscilloscope, it would be next to impossible to figure out exactly which is bad, the address line or the data bits in the RAM. They only way to fix this other than with test equipment would be to replace each DRAM one at a time to see if that fixes the problem. However, do NOT mix the '64's with the original DRAMS. they have only one power connection and it is on a different pin. Please refer to the DRAM datasheets.

Ken Lill

[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?

[ballyalley]

I pointed Michael Matte to his thread. He designed the BalCheckHR unit, so he is very familar with fixing astrocade units. He sent me this information:

--------------------

Here is how screen RAM is mapped out. Refer to the Nutting Manual system description section, page 86, which shows the low-res screen map. It takes 2 bits to define one pixel giving you the possibility of four colors max for each screen pixel. So, each screen RAM byte can define only 4 pixels. Look at the drawing on page 86 in the upper left corner showing RAM byte 4000H. Pixel 0 is the right most pixel and pixel 3 is the left most pixel. Every RAM byte is defined like this. When you look at the Bally motherboard schematic, the 8 video data lines wired to the RAM chips are labeled MD0 thru MD7. These line designations correspond to the same bit numbers in every RAM byte. Bits 0 and 1 define pixel 0, bits 2 and 3 define pixel 1, bits 4 and 5 define pixel 2 and finally, bits 6 and 7 define pixel 3. Similarly, data lines MD0 and MD1 define pixel 0, MD6 and MD7 define pixel 3. Note that each DRAM chip defines one specific pixel only. A chip does NOT define particular RAM bytes.

Chips U25 and U24 define pixel 0, bits 1 and 0
Chips U27 and U26 define pixel 1, bits 3 and 2
Chips U29 and U28 define pixel 2, bits 5 and 4
Chips U31 and U30 define pixel 3, bits 7 and 6

Looking at your 2 screen shots shows some bad pixel displays starting around the 6th or 7th RAM line from the top of the screen RAM area. It also looks like only one color is being displayed as "bad" graphic pixels, which is suggesting to me that only one bit in this "bad" display area is not being reset (or set). It is hard to tell in the menu screen shot, but, it looks like the bad display pixels are showing up as only blue. Is that correct? These bad pixels should be appearing as red.

The menu colors are:

light gray, pixel set to 11
blue, pixel set to 10
white, pixel set to 01
red, pixel set to 00

If I'm reading that screen shot correctly, the bit(s) that are not being reset are 1, 3, 5 or 7 which correspond to chips U25, U27, U29 or U31. Like I said, it hard to read that menu screen shot. The Artillery Duel screen shot is much clearer, but is still hard to determine what pixel number(s) are not being displayed correctly. I don't know what the color table is for that game.

I find it rather suspicious that more than one RAM chip could be bad at the same time and so I am wondering if U20 or maybe the custom address chip U17 are acting up. I can't see a logic analyzer or even the diagnostic tool Balcheck helping you out because of the intermittent problem. But, the diagnostic tool SetScreen2 or Setscreen3 would help you zero in on the bad pixels and give you more info to diagnose the problem. Otherwise, it looks like your only option would be the "hit or miss" chip replacement method, which is not a good option.

Bye.
MCM

[qberries]

Thank you Michael (and Adam). That is very helpful. I will try the SetScreen2/3 approach to zero in on it.

Edited May 9, 2019 by qberries

[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

Edited May 30, 2019 by qberries

[Allen Schweitzer]

I'm very interested to see where this ends up!!! Keep the information coming in on this! Thank you!

[ballyalley]

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 [...]

 

Here is Michael's response that he sent to me yesterday - Adam

 

You do have a tough issue to diagnose. If you are convinced that the pixel 0 is the culprit, then U24 and U25 should be on your list of suspicious chips. But I have to ask what the chances are that both those chips are acting up? Another suspect might possibly be U23 which is used by the custom data chip for the video scan (read) and a Z80 CPU RAM read (peek) , but your issue is only on a few lines, so I would place U23 near the bottom of your suspicious chips list. Since you don't have access to SetScreen, I would take another look at the flickering or nonflickering bad pixels while running a program that you have a known color table for and where no moving graphics are in the troubled area. Maybe Scribbling would be a good choice. Scribbling is documented in the Nutting Manual. You can look up the color table and then determine what colors are used for pixels 00, 01, 10 and 11. Check to see if there is a consistency in a color appearing or not appearing. You may only have one bad RAM chip that is having a problem setting or resetting a bit in that area. In other words, if you are seeing only 2 or 3 different colors in those bad pixels, you might be able to determine if only one RAM chip is bad. It looks like you are stuck having to use the "hit or miss approach". That's about all I can offer you in the way of help. Good Luck.

 

Bye.

 

MCM

[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?

[ballyalley]

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?

 

A BASIC program is stored in screen RAM, so using POKE can have strange results and can absolutely scramble a BASIC program, even on a fully functioning astrocade, unless extreme care is taken with the area of RAM that is POKEd.

 

Adam

[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

[ballyalley]

I didn't even realize that BASIC is stored [in screen RAM], 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?

The Nutting manual will not describe how the BASIC cartridge screen memory set up. Probably your best bet to understand BASIC's very unusual memory mapping techniques is to read the broad overview in the astrocade FAQ, available here:

 

http://www.ballyalley.com/faqs/bally-astrocade_faq.txt

 

Specifically, the section called "1.8K available of 4K RAM" will give you an overview of how this works. I'll quote part of it here:

 

"Although the Astrocade has 4K (4096 bytes) of RAM, only 1.8K of RAM is available for Astro BASIC programming. This is because there is no separate memory area allocated for the BASIC program, variables or stack; the program shares space with the screen RAM (bit-mapped graphics area). This does mean the program is displayed on the screen, but it is not visible. This can be compared to a modern computer only using the memory on the graphics card.

 

"This cost-cutting technique is often called into question (viewed against today's computer standards) and it seems to fall short of a quality explanation in many people's eyes. Don't be fooled. The Astrocade uses 4-color bit-mapped graphics, one of the earliest such examples. The bit-map method of graphic data manipulation (now standard) allows for easier programming, with the overhead requiring more memory. The Astrocade's bit-mapped, 4-color, 160x102 pixel screen display requires 4080 out of 4096 bytes (see below), leaving no memory for storage or operating space. Machine language cartridges use slightly reduced screen resolutions (for stack space and arrays), but BASIC really trims this resolution; a 2-color, 160x88 pixel display is used so that there is operating space and room for a program."

 

If you read the entire section of the FAQ, then it goes into more detail on this matter. Since you seem to be a little bit familiar with the "Nutting Manual," then you will realize the strange quirks that Jay Fenton was working around when he was programming Bally BASIC. If you really want to dig into how this works into great detail (which, honestly, is beyond my understanding) then the complete commented Z80 source code for "AstroBASIC" is available in several formats here:

 

http://www.ballyalley.com/ml/ml_source/ml_source.html#AstroBASICSource

 

I am always amazed at what was able to be accomplished with Bally BASIC given the limitations that were placed upon it with its rather unusual use of the bitmap graphics available on the astrocade. Also, this example of a workaround that had to be used in the early days of computers to get the most out of RAM helps to put us into the mindset of the extremely limited resources computers of the 1970s and early 1980s had available to them.

 

Adam

[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!

[ballyalley]

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!

 

I'll be out of town for about a week. When I come back, I'd love to hear that your system is working 100%... so good luck!

 

Adam

[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!

[ballyalley]

9 hours ago, qberries said:

Only a month later....but finally SUCCESS!!  It was just RAM chip U25 in the end! 

 

Another Bally revived; fantastic job.  Now it's time to play some games!

 

Adam

[+intvsteve]

On 7/10/2019 at 2:41 AM, qberries said:

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!

This is so encouraging to hear!

 

Allen is helping me out now, as you may have already deduced by the thread I started recently. This weekend I extracted the U24 ROM - I think pretty cleanly. Maybe tonight I'll install a DIP socket and re-test to make sure that I haven't broken anything. That keypad scares the bejeebers out of me! All that crinkly crackly plastic...

 

Anyhow, here are two up-close pictures of what it looks like with U24 removed. 

 

    

[ballyalley]

1 hour ago, intvsteve said:

Allen is helping me out now, as you may have already deduced by the thread I started recently. This weekend I extracted the U24 ROM - I think pretty cleanly. Maybe tonight I'll install a DIP socket and re-test to make sure that I haven't broken anything. That keypad scares the bejeebers out of me! All that crinkly crackly plastic...

 

Anyhow, here are two up-close pictures of what it looks like with U24 removed.

 

Yeah, if you can insert sockets for any chips that you remove then that is (obviously) the way to go.

 

The keypad is pretty flimsy.  This year Allen walked me over the phone through getting a keypad aligned so that it worked properly.  If you get your Astrocade working but you have issues with the keypad, then maybe you can try an alternative.  See the pictures for the hi-res Astrocade for ideas:

 

https://ballyalley.com/pics/hardware_pics/Hi-Res_Astrocade_Matte/Hi-Res_Astrocade_Matte.html

 

I'm glad that you're trying to fix your unit; that's great!

 

Adam

[128Kgames]

On 7/10/2019 at 3:41 AM, qberries said:

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!

Nice job!  I've got a similar issue on an Astrocade that I need fixed but haven't gotten around to it.