Hey Bally Alley! Long time no tt!

@@GORF_EMPIRE Glad to see you in these parts again and posting on the Astrocade discussion group.

MCMs REPLY TO ADAM'S COMMENTARY HOW LONG DID IT TAKE TO WIRE UP THOSE 2 PROJECT BOARDS SO EACH ONE WORKED PERFECTLY? Creating a schematic for use with the Astrocade, breadboarding the scheme, testing and if necessary, tweaking the scheme so it functions perfect, takes many, many hours to complete. The larger the scheme, the more time is required. Then, the scheme has to be wire wrapped on a permanent board requiring even more time. Patience and perseverance are usually necessary to complete a hardware add-on or upgrade project for the Astrocade. What I normally do to stay focused and motivated, is look ahead, seeing in my mind the end result of my efforts. USING A SMALL FAN TO KEEP HEATED MOTHERBOARD COMPONENTS COOL I haven't decided yet if my final hi-res Astrocade will have an internal forced air fan to keep the heat generating components on the motherboard cooler. My decision will be made when I see how wide the add-under rack set up will be. There is likely not going to be enough room to mount the fan to force air up through the Astrocade console bottom and over the motherboard top. I might have to add some kind of baffle to redirect the air through the bottom of the Astrocade console. Otherwise , I'll run the Astrocade with the console top off and my 6" fan placed behind the Astrocade to blow some air across the left side of the motherboard. MCM DESIGN's UPGRADED BALCHECKHR DIAGNOSTIC BOARD I upgraded the original BALCHECK 7-segment display decoder and its error display sequence. The original BALCHECK error display sequence could be hard to read at times. I know this because I did breadboard and run the original Balcheck scheme. The Bally Alley has the original Balcheck scheme and program code. The upgraded decoder also allows the hex numbers A b C d E F to be displayed. In the error code sequence, I added what looks like a capital I. It looks like this ][. I did this for 2 reasons. When ][ is displayed, it indicates the data error INFO byte is displayed next. The other reason was to distinguish the scenario when the error code and the info byte are the same number. For example 04 ][ 04 HE LP Without the capital I present, the error sequence can be confusing to read. In my example, without the capital I present you would only see 04 HE LP flashing. I made some other display changes. I did preserve most of the original Balcheck program. The additional changes that I made were to upgrade the original Balcheck so it would be a more useful diagnostic tool. THE BLACK SCREEN POWER ON I did some investigating and found out the custom address and data chips normally power on initializing the TV display as a black screen. A software program has to set up the four TV display parameters as desired. Unfortunately, the ROM BIOS power up routine utilizes the ROM User Program Interface (UPI) to call 2 onboard subroutines to set up the TV display. The UPI and onboard subs utilize a Z80 stack area in the screen RAM when executed. If there is a motherboard failure relating to the screen RAM, the UPI will fail to execute and the TV display will remain black. The motherboard custom chip TV display output ports may still function even if there is a failure in screen RAM or its interfacing. During a motherboard failure, using Z80 output instructions directly (not within a subroutine) to set up the TV display will INCREASE the chance of the TV display powering on with some kind of color or graphics, instead of a black screen. This is why I won't use a subroutine to initialize the TV display in several of my Astrocade diagnostic programs. Perhaps the creator of the ROM BIOS was not concerned about any black screen power on and was simply trying to save a few bytes by setting up the TV display utilizing the UPI to call the onboard subs labeled SETOUT+1 (Sub#22) and COLSET+1 (Sub#24). YOUR BREADBOARD 1 HAD 16KB OF SCREEN RAM RIGHT? The hi-res breadboard 1 actually had 4 banks of 32KB SRAM, but the 3 address lines A12, A13 and A14 were grounded providing the needed 4 banks of 4KB RAM for hi-res. MCM DESIGN's REMOTE ROM DIAGNOSTIC PROGRAM The Remote ROM diagnostic program is useful as long as the motherboard ROM is functioning enough so it can be disabled. If the motherboard ROM is so bad that it's creating an issue with the operation of the Z80 address or data bus, then the Remote ROM program will also not execute. End Of Reply MCMs Final Hi-Res Astrocade - Report 2 March 2022

@@mcmsastrocades9366 Thanks for your in-depth answer to my feedback. Also, thanks for re-posting your feedback to the Astrocade discussion group.

I would like to reply to your inquiry about the final hi-res Astrocade's: add-under Pattern Transfer Board 3, a possible modified Cartridge Connector Interface (CCI) and the major motherboard schematic error in the Bally PA-1 Service Manual. THE PATTERN TRANSFER BOARD 3 (PTB3) The PTB3 scheme will be taken from the coin-op Wizard Of Wor PTB scheme. I have already spent time on a feasibility study of the WOW PTB scheme and determined that this scheme is compatible with MCMs modified for hi-res Astrocade. The WOW PTB functions like a digital logic graphics subroutine. Even though the board utilizes some slow CMOS chips, overall, the PTB graphics subroutine can execute faster than a similar subroutine in memory processed by a Z80 CPU operating with a 1.78 MHz system clock. The PTB does not have to spend time fetching any Z80 instructions from memory. The PTB executes the graphics subroutine using digital logic gates. The Z80 has to fetch an instruction from memory before it can execute it. The fetch time delay can take 4 or more system clock cycles, depending on how many bytes of Z80 machine code an instruction utilizes. So, for the Astrocade's Z80 system clock of 1.78 MHz (560 nsec per cycle), there will be at least a 4 x 560 nsec delay just to fetch an instruction from memory. This fetch delay will add up when the Z80 executes a subroutine because every instruction executed within the sub has to be fetched in order for the Z80 to process the entire subroutine. The PTB3 project will be very time consuming. The scheme has to be breadboarded, tested and wire wrapped. I will have to determine specifically how the PTB scheme manipulates each graphic byte written to screen RAM for each of the 6 possible graphic write modes available. There is just minimal programming documentation for the WOW PTB. I will likely have to create graphic machine language programs during the testing phase to completely understand how the PTB can manipulate graphic bytes. It is not clear at this time if the PTB can utilize the custom address and data chip's magic functions. Why am I willing to spend an enormous amount of time to create the Pattern Transfer Board 3? Simply, because the possibility of having a fast PTB on a modified for hi-res Astrocade "is there" and could open the door to graphics manipulation never seen on an Astrocade. Combining that possibility with a multi-page (scene) option and up to 32KB available for a directly accessible program, addressed at 8000 - FFFFH, could provide the potential for some really awesome graphic games. The PTB challenge is there and I want to try to successfully interface it with the hi-res Astrocade. Two other ideas relating to the PTB3 are on MCMs table. 1. Break down the WOW machine coding for its "attract" mode to see how the WOW PTB was utilized? Program a close variation, as a hi-res demo, of that attract mode for execution on MCMs hi-res Astrocade? I am not planning to break down WOW's "play mode" because I want to convert the Astrocade's "The Incredible Wizard" to hi-res. 2. Create an upgraded variation of the PTB providing additional (extended) graphic manipulation? THE MODIFIED CARTRIDGE CONNECTOR INTERFACE (CCI) Another idea that is on MCMs table is the modified CCI. This interface scheme exists only on paper at this time. The modified interface is NOT related to the Astrobasic cartridge built-in audio interface. The interface would require a minor rewire of the motherboard CC decoder. Some of the wiring would be connected to 2 DPDT mini-toggle switches mounted on the right side of the motherboard with the toggles protruding through the bottom of the Astrocade console. With the 2 toggles in position 1, the CCI would be decoded normally at 2000 - 3FFFH. With the 2 toggles in position 2, the CCI would be decoded to function at 8000 - FFFFH. There are enough contacts in the cartridge connector to run a 32KB EEPROM (or EPROM). A cartridge PC board would need a rewire to accommodate the 32KB chip. There would likely be a need for the bottom of the cartridge to have a gnd contact which would make contact with a gnd contact on the bottom of the floor of the cassette connector. The intent of the modified CCI would be to optionally run 32KB cartridge programs at 8000 - FFFFH utilizing a 16KB hi-res BIOS at 0000 - 3FFFH. The hi-res BIOS, similar to the low-res BIOS, would be able to sense a cartridge at 8000H by checking for a cartridge sentinel at that address. Larger then 32KB programs would be possible using more than 1 cartridge as long as the program allowed the user to insert another cartridge to continue the program. This possibility could be accomplished by loading/executing a loop program in screen RAM or including a standard loop program in the hi-res BIOS. A MAJOR MOTHERBOARD SCHEMATIC ERROR IN THE BALLY PA-1 SERVICE MANUAL I have known about this error for years. The error correction is also documented on the Bally Alley. The correction appears in one of the handwritten scans within the BalcheckHR User Manual. The correction is in scan 9, The Bally/Astrocade Motherboard - Custom Address/Data. Here's the link to the listing of handwritten scans for the BalcheckHR User Manual. ballyalley.com/documentation/BallyCheck/BallyCheck.html#:~:text=BalcheckHR%20User%20Manual%20(Handwritten%20Scans) End Of Reply MCM's Final Hi-Res Astrocade - Report1 March 2022

@@mcmsastrocades9366 Thanks for the very informative reply. I also saw it posted on the Astrocade discussion group. I'm glad you included it there, as most people will see it.

Thank you for taking the time to write this awesome commentary. Yes, I still have my like-new Epson LQ- 850 printer, which is stored next to my Amiga 2000 computer. I don't recall when say the 4K x 4 bit Static RAM (SRAM) chips became available, but imagine what could have been, if a "next-generation" home computer/gaming system was designed around the low/hi-res Bally chip set, utilized say eight 4K x 4 bit SRAM chips for hi-res and included Zgrass. That would have been really cool. I was hoping the Perkins medium-res mode was mapped similar to the low and hi-res modes, but that is not the case. Its map is very unorthodox. Too bad. The #30 wrapping wire that I use in my prototype boards is indeed tiny, but it is very tough. Its Kynar insulation will easily stand up to a 25W soldering iron, which works very well when soldering the wire to the Astrocade motherboard. After recapping the larger power supply electrolytics, I can't say that I noticed any obvious improvement in my 20" Toshiba CRT TV display using a composite video or RF video output. MCM