Jump to content
ballyalley

Hi-Res Bally Arcade/Astrocade Correspondence

Recommended Posts

Michael updated me again on March 25, 2019.

Here are Michael's comments:

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

I indicated I would email you when I have something positive to report to you. I wired up the quick-connect breadboard starting off with the standard motherboard chips scheme U22 and U21 for the RAS and CAS (both active low) RAM timing lines. This was my preliminary first test for correct wiring operation. The low-res menu and Checkmate ran nearly perfect, which was a good start for this breadboard idea of mine. Just for the heck of it, I decided to wire up the hi-res serial feed TV display circuitry with the simulated 3 static RAM chips as I indicated previously, just to see how this standard timing scheme would operate in the hi-res mode.

I first ran my simple hi-res SetScreen and Z80 halt routine. The hi-res TV display ran perfectly with NO flickering of pixels or bytes. I was really surprised. I then ran my "write only" Screen Fill routine and there was just one hi-res pixel at 4000H that was flickering. These two experiments are indicating that my latest static RAM scheme is a good scheme. The scheme needs to be tweeked. The timing may need to be adjusted and/or a series resistor may need to be inserted/adjusted. Pull-up resistors may not help. I plan to use my logic analyzer to take some measurements with this hi-res test and also on a standard perfectly working motherboard for comparisons.

Today's 2 tests in hi-res are indicating to me that there is a very good chance that the custom address and data chips can indeed operate in hi-res using 4 static RAM chips if one can get the timing right and the degradation down. I am still hoping for success with this project.

Bye.
MCM

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

Michael's progress is moving along faster than I expected to see. That's great!

Adam

Share this post


Link to post
Share on other sites

I added "BalcheckHR User Manual - Scans" by Michael Matte from December 2018.

This 32MB pdf document contains 23 pages of handwritten notes, schematics, and board layouts for the BalCheckHR. These scans supplement the BalCheckHR User Manual. You can download it here:

http://www.ballyalley.com/documentation/BallyCheck/BallyCheck.html#BalcheckHRUserManualScans

Among the documents in these handwritten scans are:

  1. SetScreen3 Initial Display
  2. BalCheckHR Board
  3. BalCheckHR Board - EEPROM Interface
  4. DualBalCheckHR Board - Display
  5. BalCheckHR Board - Power Line
  6. Bally/Astrocade Motherboard - ROM Decoding
  7. Bally/Astrocade Motherboard - RAM Timing
  8. Bally/Astrocade Motherboard - Microcycler
  9. Bally/Astrocade Motherboard - Custom Address/Data
  10. Bally/Astrocade Motherboard - RAM Decouplers
  11. Bally/Astrocade Motherboard - Detailed Motherboard Layout
  12. Bally/Astrocade Motherboard - Notes
  13. Balcheck RAM Test Flow Chart
  14. BalcheckHR in a Cartridge
  15. Factory Tests
  16. Hi-Res Demo Magic Writes

Hardware gurus will find plenty to sink their teeth into here! Have fun, and report back with what you find!

Other BalCheckHR updates:

1) BalCheckHR Manual - This has not been uploaded anyplace yet. I'll do that this week.

2) BalCheckHR Software - The 32K EEPROM on the BalCheckHR has been dumped, though it also isn't available yet. The nearly 200-pages of handwritten Z80 source code for the BalCheckHR software has been photocopied, but Michael hasn't sent it to me yet.

When all of the BalCheckHR information is online, then all of the documentation required to build your own BalCheckHR and use it will be available.

Adam

Share this post


Link to post
Share on other sites

I added Michael Matte's "BalcheckHR User Manual" from from December 2018:

http://www.ballyalley.com/documentation/BallyCheck/BallyCheck.html#BalcheckHRUserManual

For ease of use with future updates to this manual, all documents are separate text files. Altogether, this manual is 85 pages long. It is made up of 17 different documents. They look best when printed with left and right columns of .8 or less using the 10 pt Courier New font.

Make sure to download the handwritten scans for this manual too, as together they are the complete BalCheckHR manual.

The complete manual is made up of a "Read First" file plus these 16 documents:

  1. BalcheckHR Introduction
  2. Keypad Usage
  3. Set Up
  4. Blank Power On
  5. Reducing RF Interference
  6. BalcheckHR Performance Check
  7. Standard Balcheck Tests
  8. Error Reports
  9. Balcheck Optional Programs
  10. More Options
  11. SetScreen3
  12. Optional Troubleshooting Programs
  13. High Resolution
  14. Doc References
  15. Miscellaneous Text Docs
  16. Miscellaneous Scans

Now I just have to confirm that the 32K EEPROM from the BalCheckHR was dumped correctly. If so, then someone can build their own BalCheckHR.

Adam

Share this post


Link to post
Share on other sites

BalCheckHR Pictures and screenshots for Bally Arcade and Astrocade
by Michael Matte (MCM)

I added 48 pictures of the BalcheckHR hardware along with screen shots of the device working. These were sent to me on January 29, 2019. You can view them on Archive.org, here:

https://archive.org/details/BalCheckHRPicturesandScreenshotsBallyArcadeAstrocade

MCM created the a new version of the BalCheck hardware called BalCheckHR for the Bally Arcade/Astrocade. These are pictures of the hardware and some screenshots of the software running. The pictures of Pixel Stringer are running on the Astrocade in Hi-Res mode-- a 320x204 pixel mode that he modified his astrocade to run on his hardware.

Here are the details he wrote to me when he sent me these pictures:

Well, here they are. The screen shots look pretty good to me. I'm sending a 2nd email with the Pixel Stringer photos. Most of the photos have a label to the left of the screen telling you what you're looking at. Hope you like them.

Here are the many photos for the Pixel Stringer. Unfortunately, my camera couldn't capture what I see when I run this demo on my 20" Toshiba CRT. The clarity and color is just not in the photos. Plus you are only getting a freeze frame of each 16 sec show. Half the fun is watching the pixel string move and grow. Sometimes the string moves really fast and sometimes slowly. That's part of the entertainment. Seeing the variations in the program. It's up to you which photos you would like to post. There are a bunch of them. If I can get that video to play on my desktop, that will be more fun watching the demo in action. But, this group of photos will give you an idea what this demo will display graphics wise.

Here are helpful link:

BalCheckHR User Manual:

http://www.ballyalley.com/documentation/BallyCheck/BallyCheck.html#BalcheckHRUserManual

BalCheckHR Handwritten Scans:

http://www.ballyalley.com/documentation/BallyCheck/BallyCheck.html#BalcheckHRUserManualScans

Nice!

Adam

Share this post


Link to post
Share on other sites

I added the BalCheckHR 8K ROM Image and the Z80 source code to BallyAlley.com.

1) BalCheckHR (ROM Image)
By MCM Design (Michael Matte).
2019.

This is the 8K ROM image for the software for the BalCheckHR unit. This hardware allows experienced electronics users to diagnose many problems with a Bally Arcade/Astrocade game console. This device has many improvements over the original BalCheckHR hardware, including special routines to test Astrocade units that have been modified to use high-res mode. On the BalCheckHR hardware, this is bank 0 of the 32K ROM on the BalCheck hardware. This programs requires a keypad overlay, which is described in the user manual.

http://www.ballyalley.com/emulation/cart_images/cart_images.html#BalCheckHRAstrocadeROMImage

2) BalCheckHR (Z80 Assembly Language Source Code)
By MCM Design (Michael Matte).
2019.

This is about 180 pages of handwritten, Z80 assembly language software for the BalCheckHR unit.

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

The above two links also have links to the BalCheck manuals and scans. I think all of the information required to build your own BalCheckHR is now available. The BalCheckHR ROM image is the last piece of the puzzle to get everything required to use this diagnostic hardware/software combination.

The BalCheckHR also has two other pieces of software on the 32K EEPROM on the hardware:

Bank 1 - Remote ROM - A slightly modified on-board ROM that can be used from the BalCheckHR in case the original ROM has problems.

Bank 2 - Z80 Check - A program that checks the Z80 without using screen RAM.

I don't have either the "Remote ROM" or the "Z80 Check" software.

Thank you, Matte, for your dedication to this project!

Adam

Share this post


Link to post
Share on other sites

Michael updated me again on April 21, 2019.

Here are Michael's comments:

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

Did some experimenting with my hi-res static RAM scheme on my quick-connect breadboard. The single static RAM chip is now running perfectly in low-res and hi-res using my variation of the Datamax UV-1R RAS and CAS timing scheme. This timing scheme puts out one RAS line and four CAS0, CAS1, CAS2 and CAS3 lines, essential for operating 4 static RAM chips in hi-res. The RAS line latches in the row address from the custom address chip using a 74F373 for the static RAM chip A0-A5 pins. Each CAS line is used as the static RAM's chip select. The column address from the custom address chip will appear at the static RAM A6-A11 address pins. Three Datamax drawings are archived on the Bally Alley in my hi-res Package 3 doc located within the website's Documentation section. Besides the hi-res write only routine for the first hi-res chip, I also wrote a write/read RAM test routine similar to the commercial Balcheck low-res RAM test. Both of these 2 hi-res routines are running perfectly on this single static RAM chip. The other 3 required hi-res static RAM chips are "simulated", described in a previous email, and display constant vertical TV graphics (colors) defined by grounding or floating specific 74LS166 input pins. I am going to use my logic analyzer to take a closer look at the RAS and CAS timing during a write and a read attempt and maybe do some more experimenting with the scheme on my breadboard. After that, I will try to get 2 static RAM chips running perfectly in hi-res. I am expecting to have to debug this next step because it will utilize two 74LS245 chips, which may pose problems I won't describe here.

Allen called me yesterday. He's using BalcheckHR on a failed motherboard powering on with a blank TV screen. I would have loved to see the look on his face when he ran SetScreen3 for the first time and saw it display TV graphics. He's already saved himself time and frustration by running Balcheck and Setscreen3.

I am putting aside my hi-res static RAM project for a while. I'm going to work on the 2 Wav files for my BalcheckHR slightly revised, remote 8K on-board ROM and the Z80 Check routine. After that, I will attempt to record an hour long DVD running my hi-res MLM and BalcheckHR including the hi-res routines. This DVD will not go in-depth, but will simply be an introduction to the 2 software packages. The hi-res Pixel Stringer will be the last recording. I plan to introduce it verbally and then just let it run to fill up the hour long (or longer?) DVD.

Finally, I will be spending less time daily on my Astrocade projects so I can work on a big pile of chores and pursue additional interests. [...]

Bye.

MCM

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

There's a lot about this update that I like, but probably the best news is to see that a BalCheckHR unit has gotten into the hands of someone who can use it.

Adam

Share this post


Link to post
Share on other sites

Michael updated me again on April 23, 2019.

Here are Michael's comments:

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

I implemented my "tweeked wiring change'', used on my quick-connect breadboard, to my previously wired static RAM wire wrap board. I have good news and bad news to report.

I ran on the WW board, a single static RAM chip in both the low-res and hi-res modes, observing what was and was not working. I added the 2nd static RAM chip and 74LS245 chip, ran the board in the hi-res mode only and observed the run. Based on what I was observing, I decided to add the remaining two static RAM chips and last two 74LS245 chips to see what would happen.

The good news is that I was able to adjust the RAS line trimmer pot, so my hi-res SetScreen, write only, "Fill Screen" routine would execute perfectly. This is the first time I have seen my "modified for hi-res" Astrocade motherboard run perfectly in hi-res using only 4 static RAM chips.

However, my write/read, first chip only, RAM test routine would not execute. It looks like the Z80 CPU can write to all 4 hi-res static RAM chips, but is having difficulty reading bytes from the hi-res screen RAM. I have seen this difficulty before using just one static RAM chip.

My "Fill Screen" routine is a simple plop write to screen RAM. The next step will be to run some magic writes on the hi-res screen to confirm my present wiring scheme on my WW board is indeed working perfectly in the "write only" mode. I will program a "write only" version using a portion of my original hi-res demo. If I can write magic static graphics with no problems, then I will try to move a hi-res critter around the screen using XOR write/blanks. I will not be able to use Z80 Call/Ret instructions, which require a readable stack area in screen RAM. Instead, I will use JP(IX), JP(IY) or JP(HL) instructions as a substitute for a Ret instruction. I am taking this particular next step, because there's a pretty good chance this new, write only, magic graphics test routine will work perfectly. If so, this progress will keep me highly motivated to continue my work on this project, which lately has been a struggle and time consuming. Another issue has been related to the use of my logic analyzer, which at times, has been puzzling me, because I am seeing portions of waveforms that don't seem to be displaying as expected. So, I am questioning the accuracy of my LA.

It looks like I'm going to spend time using my LA on the static user RAM in my hi-res Astrocade, to see if I can determine approximately how much time it takes the output data to appear at the chip's data pins when the Chip Select line goes low, during a Z80 read request. Then, use that observation and compare it with my WW board's read issue. Hopefully, I'll be able to resolve this hi-res screen RAM read issue.

I've spent a lot of time on this project and will continue to work on it until I run out of ideas to debug the wiring scheme. But, I will now work on this project at a much slower pace, so I can pursue other interests.

Bye.

MCM

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

Michael is making some good progress here, and I'm glad he shares these in-progress reports.

Adam

Share this post


Link to post
Share on other sites

Michael updated me again on April 29, 2019.

 

Here are Michael's comments:

 

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

 

In my last report, I indicated I ran my hi-res "Screen Fill" graphics routine on my hi-res static RAM wire wrap board with all 4 static RAM chips installed. I was surprised to see the routine execute perfectly. I also indicated, I wanted to test the present wiring scheme on the wire wrap board using magic graphic writes. Because I was so excited about this latest successful attempt, I decided to create a magic "write only" program right away. I didn't want to wait 2 or more weeks to see if the present wiring scheme could handle magic writes perfectly.

 

The last several days, I made a big push to create a 1100+ bytes "write only" program similar to my 1980's original hi-res demo. I was able to write the fish tank plus 14 static graphic patterns with magic function variations. Since this program was a "write only" test, I could not utilize a screen RAM stack area, save data in screen RAM or execute call/ret instructions. This limited me to only 6 alternate Z80 CPU registers plus the Z80 I register to save variables. Because of this limitation, I could not include moving a critter around the screen using magic XOR write/blanks.

 

After creating, debugging and running the magic test program on my hi-res Astrocade, I ran the program on my hi-res static RAM wire wrap board. I'm excited to report it executed perfectly. Attached to this report is a screen shot of the test. The shot is a bit crude being a RF modulated TV display, but it proves my claim of successfully writing magic graphics on a 4 static RAM chips configuration. Also attached are some photos of this project's circuit board set up, including the "modified for hi-res" motherboard, static RAM wire wrap board and the quick-connect breadboard. The motherboard used is MCM Design's 2nd "modified for hi-res" board. This 2nd board has all 28 clocks/data lines, necessary for operation in the hi-res mode, wired to a 28 pin wire wrap socket mounted on the bottom of the motherboard. The motherboard's 50 pin expansion is not required for this wiring scheme. The keypad was removed long ago to be utilized as a remote keypad for MCM Design's hi-res Astocade.

 

[There are the seven photos that Michael provided. Descriptions of each are throughout this post.]

 

Hi-Res Test Cartridge:

 

post-4925-0-82887300-1556816163_thumb.jpg

 

Magic Writes Test:

 

post-4925-0-97054200-1556816164_thumb.jpg

 

Modified Motherboard

 

post-4925-0-10901000-1556816166_thumb.jpg

 

Power On Test:

 

post-4925-0-33908900-1556816167_thumb.jpg

 

Quick-Connect Breadboard:

 

post-4925-0-55109700-1556816168_thumb.jpg

 

SRAM Project Set Up:

 

post-4925-0-72209300-1556816169_thumb.jpg

 

Wire Wrap Board:

 

post-4925-0-94878500-1556816170_thumb.jpg

 

The wire wrap board is sized to fit inside the hi-res Astrocade as an optional replacement board. This wire wrap board has room for the optional multi-page screen RAM interfacing plus user RAM. The wire wrap board is powered by a single +5V supply. The board also has provisions for 5V, 12V and -5V connections to a future composite video and audio driver board that will replace the Aztec RF modulator.

 

The set up photos are preliminary since this project is still in its development phase. Whether or not there will be a 2nd final wirewrap board for use with a custom console will be dependent on the success of this project. This 2nd hi-res console by MCM Design may be strictly a hi-res game player.

 

There is also a screen shot of the hi-res static RAM wire wrap board powering on with a minimal screen set up and Z80 CPU halt instruction. This shot shows all 4 static RAM chips powering on normally (perfectly). The test routine does not clear or write any data to the hi-res RAM, so what you see is the graphics (data) in RAM immediately at power on. This minimal hi-res power on routine was used initially to test the 1st static RAM chip in hi-res.

 

The next issue for this project is to get the Z80 CPU to read all screen RAM perfectly, which apparently requires more precise timing. This issue will probably be the most challenging of this project to resolve. I am hoping to debug this problem. Should I successfully tweek the timing so the Z80 can read screen RAM, then all that would be left on this project to implement would be the 8 hi-res multi-page screen RAM interfacing.

 

OK, now I am ready to put this project aside for 2 or 3 weeks, take a break from the project's frustrating challenges and work on something easy. I will now work on the 2 ROM BalcheckHR files not released yet and also my 1 hour DVD introducing BalcheckHR and hi-res MLM.

 

Bye.
MCM

 

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

 

It's great to see these pictures along with the reported progress.

 

Adam

Share this post


Link to post
Share on other sites

I added two additional cartridges images for the BalCheckHR hardware by MCM Design (Michael Matte).

This hardware allows experienced electronics users to diagnose many problems with a Bally Arcade/Astrocade game console. The new 8K ROM images included in the archive are the following:

1) BalcheckHR RemoteROM - A slightly revised 8K on-board ROM that can be run from the BalCheckHR hardware.

2) BalcheckHR Z80check - The intent of the "Z80 Check" program is to visually confirm the Z80 CPU is operating by watching the dual display to see if it counts up from 00 to FF in hexadecimal.

http://www.ballyalley.com/emulation/cart_images/cart_images.html#BalCheckHRAstrocadeROMImage

The Z80 sourcecode for "Z80 Check" is also in the archive. It can be assembler with the ZMac Z80 assembler.

Enjoy!

Adam

Share this post


Link to post
Share on other sites

Michael updated me again on August 26, 2019 about his Hi-Res Static RAM Project.

 

Here are Michael's comments:

 

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

 

The last several days I have been working again on my hi-res static RAM project. I am very excited about this update and have seen major progress on the project last Saturday. I won't mention the changes I made to my wire wrapped hi-res static RAM project board.

 

First, the board runs perfectly in low-res. The board is strictly wired for hi-res operation. If I do build a second hi-res Astrocade, it will run  strictly in hi-res. To run the project board in low-res, one chip must be removed from its WW socket, then one socket pin must be wired to the socket's ground pin using a small jumper wire. I tested the board in low-res with a bunch of games and demos. My 10 Fish Demo is a good test for run perfection because it moves around 10 fish using the magic XOR write and blank. I ran that demo for 1 hour. Perfect!

 

MCM Design has now proven, using 2 different hardware schemes, that a modified Bally motherboard can run perfectly using one static RAM chip. A minimal setup requires one static RAM chip, one 74F373 chip (or two 74LS75 chips) and one 74LS32 gate. A 74LS373 chip will likely work. Eighteen timing lines are required, which are all available where the standard Bally motherboard 8 dynamic RAM chips are located. There may be enough room in this motherboard area to place the required 3 chip PC board for such a modification.Yes, I know that is a lot of wiring to work with. So, as long as replacement dynamic RAM chips are available, a static RAM chip modification would be a last resort. One last note. The insulation on #30 wrapping wire stands up easily to a 20W soldering iron. Wrapping wire was used on MCM Design's hi-res Astrocade as tap wiring soldered to the Astrocade motherboard.

 

I have also made progress with the project board in the hi-res mode. In my last report, I indicated the Z80 CPU was writing great to hi-res screen RAM, but was having difficulty reading from the hi-res screen RAM. Now, the project board is executing nearly perfectly all of my hi-res demos and programs which I attempted to run. I changed a few bytes in my BalcheckHR 8KB EEPROM, so the entire chip can run in the hi-res mode. All of these demos and programs executed. This is the first time I saw my new hi-res "Pixel Stringer" demo execute on this project board. That is a really cool demo.

 

However, even though the project board is executing hi-res demos nearly perfectly, now the video display is producing a lot of narrow, short horizontal glitches. These gliches are a part of the custom data chip's TV display scan from hi-res RAM. The project board is also having some trouble moving hi-res patterns around the screen using magic XOR writes and blanks. I have seen this particular difficulty before during this project. The problem is a visual indication that the timing is a little off somewhere on the board. I think the problem is with the active-low CAS line, which is used as the static RAM chip select (CE). So, I'm going to focus, for now, on that timing signal using a logic analyzer and try to clean the signal line up, because I know it isn't quite acting as it should.

 

 I was really surprised and excited last Saturday when I saw the project board executing hi-res demos nearly perfectly. This new progress has indeed refreshed my motivation to continue working on this project.

 

Bye.
MCM

 

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

 

Michael is still making good progress, and he is inspiring himself-- that's fantastic!

 

Adam

Share this post


Link to post
Share on other sites

Michael updated me again on August 30, 2019 about his Hi-Res Static RAM Project.

 

Here are Michael's comments:

 

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

 

Adam, I had to send you this quick note. I think I resolved the magic XOR graphic write and blank issue. I replaced the RAM chips with faster chips, 85ns access as opposed to 120ns access. As I speak, I'm running the low-res 10 Fish Demo on the hi-res screen map. This demo was producing the most pixel glitches. Now, it's been running for over 40 minutes and there is not one pixel glitch. I'll run some more demo tests.  Looks like the project board is executing hi-res graphic programming perfectly. The TV display scan glitches are still there though. The CAS0 thru CAS3 lines may be running a little dirty, I'm guessing. I'm forced now to use a "hit or miss" approach to resolve this last issue. I'm going to try first a series resistor, then a pull-up resistor in these 4 CAS lines to see if that will eliminate those display scan glitches. Man, I'm so close to perfecting this project. Just one last issue to fix. I'm really excited about this achievement today. I can't tell you how many hours I have put into this project. Will I reap the fruit of perfection in this project? Time will tell.

 

Bye.
MCM

 

Share this post


Link to post
Share on other sites

Michael updated me again on September 11, 2019.

 

Here are Michael's comments and pictures:

 

(These can also be seen on BallyAlley.com, here:)

 

https://ballyalley.com/documentation/hi-res_packages/hi-res_packages.html#HighResolutionStaticRamUpgradeMCMDesign

 

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

 

A MCM Design Announcement

 

MCM Design is pleased to announce a breakthrough in the high resolution RAM configuration for the 1970s Bally Arcade 3 custom chip set. Up to now, four 4KB banks of dynamic RAM were required to operate the 2 Bally custom address and data chips in the high resolution mode. Since each bank utilizes 8 DRAM chips, a total of 32 DRAM chips was necessary. However, MCM Design has developed, built and tested a prototype wire wrapped RAM board which can operate the same 2 custom chips in high resolution using only 4 static RAM chips. MCM Design's breakthrough static RAM configuration also offers single +5VDC power supply operation with optional user programmable multipage screen RAM capability.

 

Below is a listing showing the major chip differences between MCM Design's new hi-res static RAM scheme and the coin op arcade Seawolf II.

 

                                                                MCM Design                                      Seawolf II

                                                                scheme                                                scheme

 

RAM                                                      4 static RAM chips                            32 DRAM chips

                                                                4KB x 8 bit                                           4KB x 1 bit

                                                                4KB capacity minimum                   4KB capacity minimum

                                                                120 nsec access time

                                                                (or faster)

 

video data bus                                  four 74LS245                                      one 74LS245 (optional)

                                                                bidirectional receiver                     four 74LS253 (read only)

 

data bus enable                                74LS138

                                                                enable selector

                                                                74LS132

                                                                selector decoder

 

active-low RAS clock                       74LS123

                                                                2 inverter gates

 

row address latch in                        74LS373

 

active-low                                           74LS175

CAS0, CAS1, CAS2, CAS3

generation

                                                                _______                                             ______

 

Total chips                                                13                                                          37

 

 

 The total chip count for MCM's new scheme is 25 chips. A few more chips must be added to:

 

1. Run the screen RAM in low or hi-res modes.

2. Multipage the screen RAM.

 

 

HOW THE NEW SCHEME WORKS

 

The new RAM timing scheme is a variation of the scheme used by the DATAMAX UV-1R computer. Three DATAMAX UV-1R schematics are archived on the Bally Alley website in the Documentation/ High-Res Astrocade Upgrade/ High-Res Package 3 section.

 

Memory Address Selection

 

The active-low row address strobe RAS is generated from the negated system clock ɸ (phi) using a 74LS123 chip and 2 inverter gates. The memory row address, from the custom address chip lines MA0-MA5, appears first and is fed to a 74LS373 latch. This row address is latched at the static RAM chip A0-A5 input pins by the active-low RAS line.

 

The memory column address on the same MA0-MA5 lines appears next and is also wired to the static RAM chip A6-A10 input pins.

 

Both the row and column addresses now present at the static RAM address pins are then latched into the static RAM chip by the active-low CAS line which acts as the RAM chip's enable (select) line.

 

Bank Select

 

The four custom address chip lines RAS0, RAS1, RAS2 and RAS3, which are used as the RAM bank select, are fed thru two 74LS175 quad D-type flip-flops to generate the four static RAM chip  active-low enable lines CAS0, CAS1, CAS2 and CAS3.

 

The 8 Bit Data Bus

 

A static RAM chip shares its 8 bit data in/out lines. The two DATEN and active-low Write Enable (WE) lines determine if data on the 8 bit data bus MD0-MD7 is to be written (input) into the RAM chip or read (output) from the RAM chip.

 

The  8 bit data bus from each RAM chip is wired to one of four specific 74LS245 bidirectional receivers. The line side of each of these 4 chips are all wired to the custom data chip MD0-MD7 pins. The custom data chip DATEN line is wired to the Direction (DIR) pin of each 74LS245 to direct the data flow as a write or read. A decoded enable line is also wired to each 74LS245 enable input so that only the appropriate 74LS245 will be enabled (turned on) at the right time to avoid any data conflicts.

 

Screen Refresh (Scan)

 

When all 4 RAS0, RAS1, RAS2 and RAS3 lines are simultaneously active-high, a TV display refresh (scan) is generated. All four 74LS245 receivers are disabled at this time. This scan acts like a memory read. One byte from all 4 RAM banks is read simultaneously. So, these 4 bytes (32 bits) of data are fed to the four 74LS166  chip shift data inputs. An active-low Shift Load (S/L) input to the four chips indicates when the data is valid and ready to be shifted serially, two bits at a time by the 7M clock, into the custom data chip using the two Serial 0 and Serial 1 lines. Apparently, there is a 12 bit address counter in the custom data chip which keeps track of the row and column addresses, so the entire screen RAM is scanned. So, 4 bytes (16 pixels) at a time are shifted into the custom data chip every time the S/L line goes low.

 

 

MCM DESIGN's  INTENT WITH THIS NEW HI-RES SCHEME

 

This new static RAM scheme was developed for personal use with the Bally/Astrocade home computer system to supersede MCM Design's original hi-res Astrocade and to utilize this second modified Astrocade as a purely hi-res gamer. In order to implement the new static RAM scheme, modifications MUST be made to the Astrocade's motherboard. The primary modifications are listed below.

 

1. Remove the 8 DRAM chips and also chip U23.

2. Remove from ground, the Serial 0 and Serial 1 input lines at the custom data chip.

3. Move the 27 ohm, 1W power resistor R1 over about 1 inch, so a 28 pin ribbon cable WW socket can be     mounted on the motherboard.

4. Tap 28 specific motherboard lines to the WW socket using #30 wrapping wire, one end soldered to the motherboard, the other end wrapped to the WW socket.

 

No connection to the Astrocade motherboard 50 pin expansion is necessary to operate this new hi-res static RAM scheme.

 

MCM Design is announcing this new scheme and plans to post detailed scheme documentation on the Bally Alley website for a high tech minded individual desiring to take the challenge and build a "modified for hi-res Astrocade" which can run in the low or high resolution modes. MCM Design also plans to convert certain low-res Astrocade games into hi-res. Note that over 8KB conversions will need to run on 32KB user RAM addressed 8000-FFFFH. Some hi-res demos are already included in the 8KB BalcheckHR package already archived on the Bally Alley website.

 

MCM Design is extremely pleased with the results of this new hi-res static RAM prototype board. It runs perfect in low and hi-res and has a low chip count. It is awesome! MCM Design will now develop  and test the option for multi-paging the screen RAM.

 

I would like to thank Ken Lill for his recommendation to me in purchasing the 16 channel Kingst logic analyzer, which resolved several project problems. I would also like to thank Anthony Miller for his detailed "A Description Of The Bally Professional Arcade Video Hardware And Associated Coin-Operated Hardware" and the Bally Alley for posting the documentation. This doc detailed the hi-res screen refresh (scan) function and circuitry, which was a major help in understanding and resolving this project's final problem. Without this outside help, I would have never successfully completed my hi-res static RAM project scheme. Thanks for your help.

 

 

MCM Design

Sept 2018

 

 

HR Static RAM1.jpg

HR Static RAM2.jpg

HR Static RAM3.jpg

HR Static RAM4.jpg

Edited by ballyalley

Share this post


Link to post
Share on other sites

Since my last update here on September 11, 2019, Michael Matte has sent me many updates.  This posting, and the next few postings in this thread, will include his updates on his high-resolution Astrocade project since that time.

 

As Michael said to me on September 16th: "Our agreement is unless I say otherwise, any info I send to you is at your discretion as to what you would like to do with the info. The only non change is that you are not to reveal my email address, home address or phone number to anyone without my permission. Thanks."

 

So, basically, I've included nearly 100% of what he has sent to me.  Sometimes the formatting get messed up in his emails to me, but the information should still carry across just fine.  I have not edited these emails at all, except on a few occasions where I placed bits of information in brackets for clarification.  Also, sometimes the earlier of these emails to me get updated by Michael in later emails, so be sure to read everything here for a complete picture of what's going on with the hi-res project.

 

Let's get started...

 

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

 

Subject: Hi-Res Static RAM Project Update
From: MCM
Date: 9/12/2019, 1:52 PM

 

Thanks for posting the announcement/photos and emailing me the feedback from Lance. As usual, you did a great job. As much as I would like to supply interested users a low/hi-res Astrocade upgrade, it would be for me a lot of work and time consuming to do so being all custom work. I do not have the expertise to create a professional hi-res multi-page static RAM pc board add-under or plan to develop a faster means of saving or loading data. This new scheme could open the door to indirect accessing of additional ROM or user RAM in the order of 128KB or more each plus extend multi-paging to 256KB.  I might be interested in modifying Astrocades for hi-res operation, I don't know. That modification is not difficult, but is time consuming. As I mentioned previously, my hi-res projects are really for personal use and I am sharing the projects with the Bally/Astrocade community in case there is someone out there with the expertise and the interest to modify their Astrocade to run also in hi-res.

 

Bye.
MCM

 

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

 

Subject: Hi-Res Static RAM Project Update
From: MCM
Date: 9/13/2019, 6:06 PM

 

Just wanted to let you know I mailed this afternoon the 6 schematics documenting the hi-res static RAM board as it is currently wired including required motherboard modifications. You may see these drawings as early as Monday. These schematics are very detailed. The 11 x 17" drawing is not an easy read. Experience in reading schematics is necessary for this particular drawing.

 

I think the Datamax UV-1R multi-paging scheme (16 pages) is set up so a program can be loaded into one or more pages of screen RAM and then executed to display graphics on the remaining available screen pages. So my variation for 8 pages, may have the option to use hi-res MLM with the custom built-in 2000 baud audio tape interface to load demos or games into one or two pages of screen RAM and execute them there instead of a 32KB User RAM AT 8000-FFFFH. This multi-page scheme could take 6 chips.

 

I will also supply for posting other options like a simpler multi-page scheme that allows writing only to screen RAM pages for just fast screen scene changes. Another option will include adding User RAM at 8000-FFFFH, switchable User RAM at 6000/2000H for 8KB cartridge development and also an 8K ROM enable at 0000-1FFFH containing an UPI with hi-res subroutines similar to the low-res ROM plus extended custom graphic routines. Another option would be running the screen RAM in low or hi-res, software selectable. I'm not sure at this point if the multi-pager will work in the low-res mode.

 

Bye.
MCM

 

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

 

Subject: Bally/Astrocade Hi-Res Upgrade
From: MCM
Date: 9/14/2019, 8:32 PM
To: Lance and Adam

 

Hi Lance. Adam emailed me your 2 responses to my announcement of the new hi-res static RAM scheme for the Bally/Astrocade home computer system. I'm happy to hear someone is interested in modifying their Astrocade to run in the low and hi-res modes. It is a lot of work. However, once you get a taste of hi-res graphics, you most likely won't want to program in low-res any more. There is some hi-res software available now and I have 2 hi-res software projects under development with future plans for more hi-res demos and games. I will be writing soon a machine language hi-res multi-page demo that will unquestionably show the viewer that the program is multi-paging hi-res screen RAM. This kind of graphics from an Astrocade has never been seen before and I am excited to begin writing this demo once I build the multi-page hardware scheme. I asked Adam if you would be interested in the forwarding of Adam's and myself emails discussing the hi-res static RAM upgrade. Adam said you definitely would be interested in receiving the forwarding emails. In saying that, I would like to welcome you to the land of hi-res for the Bally/Astrocade. I just wanted to make contact with you today. Let me know if you want to receive the emails and I will send you the recent and future emails.

 

Bye.
Michael
MCM Design  

 

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

 

Subject: Hi-Res Static RAM Project Update
From: MCM
Date: 9/15/2019, 10:35 PM
To: Lance and Adam

 

If you check out the photo [not included here] I sent to you showing my wire wrapped hi-res static RAM board connected to the motherboard, you will see that the RAM board is oddly shaped. That's because it is sized to fit into my Viper cabinet that is underneath my modified for hi-res Astrocade. The idea is that the hi-res RAM board is to be mounted underneath the Astrocade's console bottom. This allows the motherboard 50 pin expansion to be connected to the rear of the upside down RAM board underneath the Astrocade. My wire wrapped board has room to add circuitry for a multi-pager, hi-res ROM and user static RAM addressed 6000-FFFFH, all which must be connected to the 50 pin expansion.

 

A wire wrapped hi-res static RAM board needs a 50 pin wire wrap header socket with straight thru wrapping posts mounted on the board to make the ribbon cable connection to the motherboard. I did some checking yesterday and found out that this header socket along with a 50 pin ribbon cable IDC header connector and card edge connector are still available for sale at Elliot Electronic Supply, which also sells a full line of wire wrap sockets. That's the good news.

 

Here's the bad news. When purchasing 32K x 8 bit static RAM chips, you must check the data sheet for pin compatibility for your particular application. Sad to say, there is not a standard pin layout for this chip. For example, the Cyprus Semiconductor Corp (CSC) 32K x 8 bit static RAM chip CY62256 is not pin compatible with my hi-res static RAM interfacing schematic, DWG 5. The RAM pin layout used for this project will also be used for the optional User RAM scheme because the pin layout is compatible with Jameco's 32K x 8 bit EEPROM, which is still available, part # 74878. I need to add a note to DWG 5 "check for RAM pin compatibility. Wire to suit pin layout". Jameco is still selling 32K x 8 bit static RAM, 28 pin, 70ns chips, part# 82472, $3.95, 10 at $3.59. There has been a substantial price increase since 2018.

 

I'm developing "on paper" a multi-paging scheme. My idea for a simpler scheme is "out the door". It won't work as drawn up. So, I will be using a variation of the DataMax UV-1R  five chip multi-pager, which allows the pager to separately read one page while writing to another page. You can also select which page should be displayed on the TV. It uses 2 output ports 74H and 75H to set up the pager. It also can easily be expanded using 64K x 8 bit static RAM chips (16 pages, 256KB).  Because the Astrocade low-res power up routine is "set in stone" and can't be revised, the multi-pager will only function in hi-res, which to me is okay. If one has access to hi-res graphics, why would you want to multi-page in low-res anyway? I will also have to add circuitry to this pager to deal with hi-res programs that don't utilize a multi-pager. Finally, I will continue with the Astrocade requirement, even in the hi-res mode, where the Z80 stack area, variables, data blocks, subroutine flags, etc. will reside in the bottom of screen RAM. This way the multi-pager will not need User RAM above address 8000H to function.

 

Bye.
MCM

 

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

 

Subject: Hi-Res Static RAM Project Update
From: MCM
Date: 9/16/2019, 7:24 PM
To: Lance and Adam

 

This morning I was thinking about my hi-res multi-pager and an idea just popped into my head. The idea was a way to tell the multi-pager that a hi-res program is or is not requesting the multi-pager to function (turn on). I have reason to believe this idea will really work. What a cool idea! The multi-pager has now grown to 10 chips. The additional 5 chips will tell the static screen RAM to operate in the low or hi-res modes, software select able. The extra chips will also act like a decoder to tell the multi-pager that a hi-res program wants or does not want the multi-pager to operate. Ten chips is a bunch, but check out the features below for the scheme. They are awesome!

 

When a program outputs the low/hi-res request byte to port 08H, the byte will request one of the following:

 

00H   Operate screen RAM in low-res using screen page 000 only.

 

01H   Operate screen RAM in hi-res using screen page 000 only.

 

81H   Operate screen RAM in hi-res using any of the 8 screen pages 000 thru 111 (0 - 7).

           User must set up output ports 74H and 75H within the user program to suit the program's application.


Output Port 74H Set Up For TV Display

 

Bits 0 - 2   Display on TV one of the 8 pages of screen RAM, pages 000 thru 111 (0-7).

 

Bit 3           Available for expansion to 16 pages (256 KB).

 

Bits 4 - 7  Not used.


Output Port 75H Set Up For Z80 To Read/Write Screen RAM

 

Bits set up for Z80 read


Bits 0 - 2   The Z80 will read the byte from screen RAM in the selected RAM page 000 thru 111 (0-7).

 

Bit 3           Available for expansion to read a byte from one of 16 pages (256KB).

 

Bits set up for Z80 write


Bits 4 - 6  The Z80 will write the byte to screen RAM in the selected RAM page 000 thru 111 (0-7).

 

 Bit 7          Available for expansion to write a byte to one of 16 pages (256KB).


Notes

 

1. A up to near 16KB ML program, depending on the program's required scratch pad size, can be loaded (written) to a selected screen RAM page. The output port 75H read bits 0 - 2 must point to the loaded page so the Z80 can fetch ML instructions and execute the ML program once the Z80 PC register points to the loaded page. The program must point to the desired screen page using output port 75H write bits 4-6 when writing graphics to screen RAM.

 

2. MCM Design's hi-res MLM with a built in 2000 baud audio tape interface will load a ML program into a selected screen RAM page from an audio cassette player. The MLM may be able to automatically execute the program or provide an optional menu listing.

 

3. Low-res or hi-res programs must use the scratchpad area at the bottom of the screen RAM page area for the Z80 stack, data blocks, variables, flags, etc.

 

4. Hi-res multi-paging programs can also be executed using the 2000H cartridge format, the 6000/2000H User RAM switch or 8000-FFFFH User RAM. A hi-res 8KB on-board ROM is under development by MCM Design which will be similar to low-res ROM (excluding the 4 on-board games) providing UPI access to hi-res subroutines and will include extended hi-res graphic subroutines. This hi-res ROM is usable on MCM Design's optional User ROM/RAM scheme as part of the hi-res static RAM board.

 

Needless to say, I am really thrilled that my hi-res static RAM project has advanced to the implementation of a multi-pager. I can't wait to work on the 10 chips scheme schematic, wire up the scheme, run a quick 2 page program tester and then program that awesome 8 page hi-res demo. Let the fun begin.

 

I will also return to writing lesson 7 of my "An In-Depth Look At ..." series trying to spend some time each day on the series. I must admit though, it will be a bit challenging to spend time on my series rather than the hi-res static RAM project.

 

Bye.
MCM

 

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

 

[Lance sent Michael a message that said, "Being able to Read one page while writing another and viewing yet a third, I think is awesome.  I'm just wondering, If writing to Magic RAM, does it end-up on the first page the designated Write page or possibly the display page?"]

 

Michael responded:

 

Subject: Re: Hi-Res Static RAM Project Update
From: MCM
Date: 9/16/2019, 8:40 PM
To: Lance and Adam

 

When writing graphics to magic RAM or to Screen RAM, you include two Z80 instructions just prior to the graphics write routine which tells the hardware which of the 8 screen pages the graphics will be written to. Bits 0-2 point to the page the Z80 reads and bits 4-6 of the output port 75H point to the page the Z80 will write to. So, you load the Z80 Accumulator with the both bit pointers and then execute OUT (75H), A. That's all you do. The hardware takes care of the implementation of the output instruction and graphics write routine. I haven't actually confirmed this statement yet, but that's what I believe will happen. Once I wire up my multi-paging scheme, it will be thoroughly tested for bugs.

 

The custom address and data chip are always scanning the TV display page selected by output port 74H, bits 0-2. The constant scanning of all the selected page pixels are loaded into the four 74LS166 shifter chips inputs (32 bits, 4 pixels at a time) and then serially fed into the custom data chip through its two serial 0 and serial 1 input lines. This scanning is independent of the Z80s reads and writes to a screen page. The multi-pager knows when the video scanning is being executed and sets the the address pins A12, A13 and A14 (eight 4KB banks) of the 4 RAM chips according to output port 74H, bits 0-2. Three bits gives you 8 possibilities and in this case, 8 screen RAM pages to point to. Some design application engineer came up with this multi-pager scheme. Very clever. The DataMax UV-1R computer used this scheme. I just changed one chip because static RAM is being used not DRAM and added some more chips for decoding the multi-pager a little more and also the screen RAM video data bus R/W enabling for both the Astrocade low and hi-res modes. I believe I have the right scheme for my desired application and hopefully will not have to debug it.

 

Bye.
MCM

 

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

 

Michael's next update to me was on September 20, which is after I sent him the scanned schematics that he mentioned mailing to me in his September 13th email to me.

 

I'm going to look over those schematics and probably post them to BallyAlley.com and then link to them in my next posting, which will be in the next couple of days.  I got really behind on these updates and I'm happy to be catching up a bit now.

 

Adam

Share this post


Link to post
Share on other sites

Here are additional updates (and links to schematics) from Michael Matte from September 20, 2019 - October 18, 2019.

 

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

 

Subject: Re: Hi-Res Static RAM Project Update

From: MCM

Date: 9/20/2019, 12:10 PM

 

The schematics look excellent. They are very clean with no missing or cut off details. I will submit to you soon a schematics overview with some descriptions. This overview will grow when the multi-pager,  hi-res ROM and user RAM schemes are tested and finalized. After that, some kind of building procedure will follow to wrap up the hi-res static RAM project.

 

Bye.

MCM

 

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

 

Subject: Hi-Res Static RAM Project Update

From: MCM

Date: 9/20/2019, 12:40 PM

To: Adam and Lance

 

I ran a simple ML hi-res screen fill with vertical colored stripes to see if I could output 81H to port 08H without any problems setting up a hi-res screen map. No problems were visible. When you normally output 00H for the low-res and 01H for hi-res modes, the custom chip(s) probably only examine the output bit 0 to see if it is at logic 1 or 0. This is a significant discovery because it will allow a user to request, within a program, the multi-pager to function or not function in the hi-res mode. The multi-pager includes a custom output port 08H which latches in the output data bit 0 and bit 7. These 2 bits will be fed to the multi-pager so it will respond appropriately to an output of 00 (low-res), 01 (hi-res with no multi-paging) and 81H (hi-res with multi-paging) to port 08H.

 

I am going to start wiring up the 10 chip multi-paging scheme beginning today. I will let you know when I'm finished with the wiring and ready to begin testing the scheme.

 

Because the wire wrap project board will also have an 8KB hi-res ROM (0000-1FFFH) option and user RAM option, I will also add three 74LS245 chips to buffer the Z80 address and data lines for use with the multi-pager and user ROM/RAM scheme.

 

Bye.

MCM

 

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

 

Subject: Re: Hi-Res Static RAM Project Update

From: MCM

Date: 9/20/2019, 5:37 PM

 

The DWGs 1 thru 6 are finalized. You can post/forward these first 6 drawings as desired. DWG 5 as shown is for hi-res operation only with no multi-paging. The upcoming, additional drawings will be submitted to you as options to the original hi-res static screen RAM scheme (DWG 5). A user interested in building the new hi-res static screen RAM scheme can choose what option he/she wants to add on. There WILL be an option drawing for someone that just wants to operate the static screen RAM in low or hi-res with NO multi-paging. An option drawing will include and indicate any rewire necessary to DWG 4 or 5.

 

I just finished writing my overview. I will send it to you in a few minutes after I proof read it.

 

Bye.

MCM 

 

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

 

Subject: Hi-Res Static RAM Project Update

From: MCM

Date: 9/20/2019, 5:54 PM

To:

 

HI-RES STATIC SCREEN RAM SCHEMATICS OVERVIEW

 

 

[The schematics and drawings can be downloaded here:]

 

https://ballyalley.com/documentation/hi-res_packages/hi-res_packages.html#MCMDesignHi-ResStaticScreenRamSchematics20190920

 

DWG 1

Modified Hi-Res Motherboard, Mounted 28 Pin Socket Wiring

Details the necessary motherboard modifications for hi-res operation. Includes 28 wiring lines from the motherboard to the 28 pin WW socket mounted on the motherboard.

 

DWG 2

Bally Motherboard To Hi-Res Screen RAM Board

Shows some of the necessary interfacing from the 28 pin ribbon cable connection on the motherboard to the static screen RAM board scheme and the TV display scan circuitry detailed in DWG 5.

 

DWG 3

Bally Motherboard To Hi-Res Screen RAM Board

Shows additional interfacing and timing circuitry. Reference above DWG 2 description.

 

DWG 4

74LS138 Enabler Decoder

Details the 74LS138 decoder for proper operation of the Z80 screen RAM read/write data bus and the TV display scan 32 bit read (scan) data bus.

 

DWG  5

Static Screen RAM Interfacing

Details interfacing and all connections to the 4 banks of static screen RAM. Includes connections to the four 74LS166 TV display scan serial shifter chips.

 

User Notes

 

1. Check your static RAM pin layout for compatibility with the static RAM pin layout in DWG 5. If your static RAM pin layout is NOT compatible, wire your RAM to suit proper operation (or purchase compatible chips) and revise your version of DWG 5 for future reference.

 

2. DWG 5 as shown is wired for hi-res operation only with no multi-paging. To manually run this DWG 5 scheme in low-res, remove the IC12 chip 74LS138 from its socket. Add a jumper wire from the socket pin 15 to gnd pin 8. This jumper enables the Bank 0 RAM data bus for low-res operation only and "floats" (disables) the IC14, IC15 and IC16 data buses.

 

DWG 6

Simplified Video Screen Scan Diagram

The entire TV (video) screen scan circuitry is spread out over drawings 2,3 and 5. DWG 6 lays out the entire scan scheme in this one drawing 6, attempting to simplify the scheme so a user can grasp how the scanning scheme functions. A brief operation description is also included. For more details, reference the doc "A Description of the Bally Professional Arcade Video Hardware and Associated Coin-Operated Hardware" by Anthony J. Miller, which is archived on the Bally Alley website. This doc details the screen scan operation for the coin-op arcade Seawolf II. The scheme in DWG 6 is a variation of the scan scheme used in the DataMax UV-1R computer, which is documented on the Bally Alley website in MCM Design's original hi-res upgrade package 3. The original hi-res upgrade by MCM Design utilized dynamic RAM (DRAM) for it's hi-res screen RAM scheme. 

 

Bye.

MCM

 

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

 

Subject: Hi-Res Static RAM Project Update

From: MCM

Date: 9/26/2019, 2:45 PM

TO: Adam and Lance

 

Just wanted to let you know, I finished wiring the multi-pager scheme. I will now run tests on the scheme.

 

I also documented a brief building procedure for this scheme. My factory tests run on the multi-pager will also be documented.

 

Bye.

MCM

 

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

 

Subject: Hi-Res Static RAM Project Update

From: MCM

Date: 9/28/2019, 3:20 AM

To: Adam and Lance

 

My hi-res static screen RAM board, with its new multi-pager, is now mounted underneath the console bottom holding my second modified for hi-res Astrocade motherboard. It has the 28 conductor ribbon cable connector in front and the 50 conductor ribbon cable connector in back. The setup is a bit crude looking, but it works great.

 

Good news! I ran 3 tests on the new multi-pager and they all passed. 

 

The first test checked if the static screen RAM would map out in low-res when a program outputs 00H to port 08H. The RAM board now powers on automatically with the low-res menu.

 

The second test checked if the RAM would map out in hi-res when a program outputs 01H to port 08H not utilizing a multi-pager.

 

The third test checked if the RAM would map out in hi-res with a working multi-pager, if a program outputs 81H to port 08H.

 

I wrote a simple hi-res ML program utilizing just 2 screen RAM pages. The program, located at 2000H, fills only (using nonmagic writes) the 2 pages with pixel colors. This was a write only program that required no Z80 stack area in RAM, no screen RAM reads of any kind. The TV display was initialized to page 0. Page 0 was written to first, then page 1 was written to with vertical colored stripes. After the 2 page writes, the TV display then alternated displaying page 0, then page 1 about every 3 seconds using a ML time delay routine. The multi-page program executed with no problems. I'm pleased to announce I now have an Astrocade that will multi-page in hi-res. I did not have to debug this new multi-paging scheme for the 3 tests.

 

I am going to run more tests utilizing magic writes and page reads. I'm also going to check if a program can be loaded and executed in one page, while the TV display shows a different page. Before I run more tests, I am going to wire up on this project board a portion of the optional hi-res ROM/user RAM scheme, so I can program an EEPROM at 6000H using MLM and then easily switch the program to 2000H to run/debug the additional multi-pager tests. I can't do that on my first hi-res Astrocade because it has no multi-pager. This user RAM setup on my new hi-res Astrocade will also allow easy changes (variations) to the test programs by MLM.

 

This project has turned from being difficult to work on, to now being exciting to explore a new, unexplored Astrocade graphics application.

 

Bye.

MCM

 

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

 

Subject: Hi-Res Static RAM Project Update - Photos

From: MCM

Date: 9/28/2019, 11:42 PM

To: Adam and Lance

 

Thought you might be interested in viewing some preliminary photos. These photos are not to be posted at this time. The multi-pager has not yet been fully tested. Hopefully, I will not have to make any changes to the scheme that is wired as of today.

 

Bye.

MCM 

 

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

 

Subject: Hi-Res Static RAM Project Update

From: MCM

Date: 10/18/2019, 7:23 PM

To: Adam and Lance

 

I finally finished wiring and testing a good portion of my user ROM/RAM scheme for my hi-res static screen RAM project board. I can now use MLM to program a pin compatible EEPROM at 6000H and then switch it to 2000H, using a mini toggle switch, to run the tests. I will soon begin creating some hi-res programs to test the multi-pager. Included will be an 8 page demo to show off the multi-paging static screen RAM board. This demo will probably not be a full 8KB program.

 

The 28 pin user RAM socket addressed 6000-7FFFH is multi-carted for four 8KB banks using a 32KB EEPROM or 32KB static RAM chip. The 28 pin 32KB user RAM socket addressed 8000-FFFFH is also wired out. The 28 pin hi-res ROM socket will be wired out later when I actually begin working on the hi-res ROM project.

 

When I first wired up the user RAM 6000H socket, the Z80 was having difficulty reading the RAM chip there. It took me quite some time to isolate the problem. I'm going to take another look at this issue later after I finish testing the hi-res multi-pager. For now, the two Z80 address lines A0 and A1, used to enable the appropriate hi-res 4KB bank data bus for a Z80 read or write to screen RAM request, are now wired to the address buffer chip IC27, instead of a direct connection to the motherboard Z80 address bus via the custom 28 pin WW socket mounted on the modified motherboard.

 

That means a 50 pin ribbon cable connection is necessary to operate the screen RAM in hi-res. This is acceptable to me since this ribbon cable connection is required anyway to operate the hi-res multi-pager. Note also that a user RAM add-on like the Lil' White RAM cannot be used with this scheme unless the user has the expertise to rig up some kind of a 50 pin cable adapter.

 

This second hi-res Astrocade, the hardware nearly finished, is an upgraded version of my first hi-res Astrocade. This new modified Astrocade is intended to run strictly in hi-res. It can also power on automatically in low-res if desired. The low-res mode, fully useable, however, will be in my case simply a troubleshooting aid for any future board failure.

 

MCM Design's hi-res MLM will include a 2000 baud audio tape interface so hi-res games/demos can be saved and loaded at 8000H. I am not crazy about loading a possible 32KB program from tape and waiting say 160 sec hoping the load was successful. I would prefer utilizing 32KB EEPROMs.

 

A long time ago, I sketched out a motherboard modification scheme that would allow operation of a internally rewired Bally/Astrocade game cartridge utilizing a 32KB EEPROM programmed to run at 8000-FFFFH. This scheme requires a minor rewire of the cassette ROM decoder on the motherboard and utilizes two DPDT mini toggle switches that would be mounted on the motherboard near the light pen connector and protrude through the right side of the console bottom. With the toggles in position 1, the cassette ROM decoder and cassette connector would operate in the standard low-res mode. With the toggles in position 2, the ROM decoder would decode for 32KB addressed 8000-FFFFH. A internal game cartridge PC board would require a rewire to support 32KB. There would also be a ground contact at the bottom exterior of the cartridge to mate with a ground contact on the floor of the cassette connector. I plan later to test this scheme idea to see if it will work perfectly.

 

Since the 28 pin hi-res ROM socket on the project board will accept a 32KB EEPROM, I would like to utilize the entire 32KB for hi-res operation. I am looking to wire the hi-res ROM socket on the project board to optionally run 16KB at 0000-3FFFH. There would be a mini toggle switch on the back of the project board. In position 1, the 16KB ROM would be mainly 2 UPI supported onboard hi-res subroutines including extended graphics and a few test demos. In position 2, the other 16KB would run as one or more hi-res demos or games. I like this idea, but whether the idea will be implemented remains to be seen. I definitely have big ideas for this upgraded hi-res Astrocade. There is really not too much left to work on hardware wise. The worst part of this hi-res project is over. Now the fun part, programming graphics, begins.

 

My original hi-res 8KB ROM project, which was partially developed a long time ago, is essentially a hi-res conversion of the low-res UPI onboard subroutines. I will likely have to revise the hi-res on board subroutines to support multi-paging. The remainder of this 8KB ROM will include some extended graphic routines. There may also be a few simple test demos, possibly menu driven. The power up routine will also check for a program sentinel at the 2000H cassette connector and at 8000H.

 

Attached are 2 photos of my project board with the optional user ROM/RAM scheme added.

1435312555_HRStaticRAM16.thumb.jpg.e599816c2424cabe910f1e3cf3ec04e8.jpg

 

920326246_HRStaticRAM17.thumb.jpg.ecfb8d1d16bb18717dcb263a0ae2ab6f.jpg

 

Note the total chip count has increased to 45 chips. That's a lot of chips. However, compare that chip count to the coin-op arcade Seawolf II. Keep in mind, that MCM Design's new hi-res static RAM Astrocade operates in low or hi-res, includes 8 pages of hi-res screen RAM (128KB) expandable to 16 pages (256KB) using a RAM board that operates off a single +5Vdc ($10) power supply. What a sweet set up.

 

Bye.

MCM

 

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

 

That brings all of the updates by Michael up to date as of today.

 

Michael is currently working on an EEPROM project for the Astrocade.

 

Adam

Share this post


Link to post
Share on other sites

Michael updated me again about his hi-res project(s) on November 28, 2019.

 

Here are Michael's comments:

 

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

 

I have run some tests on my hi-res multi-pager. For example, while viewing page 0, which displayed narrow hi-res vertical colored stripes on the screen, a second program was written to page 1 and then viewed after a 5 second time delay. This second program was used during the development of my hi-res static RAM scheme. The program utilizes variations of the magic functions and "writes" 15 graphic patterns on the screen. A large fish aquarium is also written. I found out that anytime you are utilizing the magic xor/or functions to write graphic patterns to a specific page, the multi-pager output port 75H must be pointing to that page for writes and also reads. Otherwise, the magic hardware will not be able to read that page for the xor/or logical operations. So far, the multi-pager is working as expected.

 

I am now working on an 8 page test/demonstration demo. I'm not sure how many 1K bytes this demo will require. This demo will be in the 2000H cartridge form allowing up to 8KB to be used. Page 0 will display first the demo text intro. While viewing this page, the other 7 pages will be written to with static graphics. There will also be a short "move critter" program copied to the page 7 scratchpad area. After the page 0 text intro view time counts down to zero (or any key on the keypad is pressed), the multi-pager will start flipping through each page nonstop. View time will start at about 10 seconds. After a pass of viewing all 8 pages, the view time for each pass of 8 pages will decrease. The multi-pager will just keep flipping thru each page faster and faster, down to 1 second (or less?) per page. I am hoping to add an audio "flip" sound to each page flip to make the demo more entertaining.

 

When this page view time counts down to its minimal view time, page flipping will cease. Then the "move critter" program in page 7 will be executed. The critter will be seen moving through each of the 8 pages of graphics "erasing" the graphics as the critter moves.

 

Once the critter finishes erasing graphics in page 7, a hi-res fish demo similar to the low-res fish demo in BalcheckHR will run on page 7. Depending on how many of the 8K bytes are available for this fish demo, I am hoping to use up the remaining bytes to move around the screen multiple varieties/sizes of fish. This fish demo will perhaps test the limitations of moving multiple large patterns, say 16 pixels wide by 18 pixel lines high (or larger?), around the screen using the normal  Z80 data block transfer LDIR instruction (opcode ED B0).

 

The fish demo will run for 2:00 minutes, then a jump back to the multi-pager demo will be executed to repeat the demos again. A viewer will have the option to run the fish demo nonstop by pressing any key on the keypad, in which case, an elapsed timer 00:00:00 will appear at the bottom of the screen. Pushing the system reset button will also start up the multi-pager demo.

 

Below is a listing of the hi-res static graphics that will appear on each of the 8 pages during the execution of the multi-pager demo.

 

Page Page Graphics

 

  0 Demo Text Intro

  1 Narrow Vertical Stripes

  2 Aquarium +15 Magic Writes

  3 "Multiple Page Demo" Title Page

  4 Narrow Horizontal Stripes

  5 Textured 10 Color Test Pattern

  6 Narrow Vertical + Horizontal Stripes

  7 Hi-Res Gunfight Snapshot

 

Based on what I've seen the multi-pager do so far, the above program description is feasible. I look forward to seeing just how fast the multi-pager can flip thru pages without any problems. I think this 8KB hi-res demo package is going to be really cool to watch.

 

Bye.

MCM

 

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

 

This page-flipping idea reminds me of Michael Garber's graphics demo that he made for the 256K unreleased bank-switched cartridge for the Astrocade.

 

This first one has two Pikachu slapping one another.  This was converted from an animated GIF.  Here's the video:

 

https://www.youtube.com/watch?v=aZaN4WJyj4k

 

The second one has a large object ("RiffRaff") that scrolls acros the screen.

 

https://www.youtube.com/watch?v=qkUY3iMoaqw

 

Both of the binary cartridges and some of the source code for these two demos are on BallyAlley.com, here:

 

https://ballyalley.com/documentation/bally128k-com/maxflash/maxflash.htm

 

Since the 256K/512K bankswitched cartridge was never released and the MAME emulator doesn't support this format, the only was to experience these demonstrations is in these videos:

 

For more information about these bankswitched cartridges, visit Michael Di Salvo's website devoted to the bankswitched cartridge:

 

https://msdconsulting.wixsite.com/128kgames

 

(There sure are a lots of people named Michael in the Astrocade community!)

 

I really am looking forward to seeing the page-flip demonstration cartridge for hi-res that Michael Matte is proposing in this latest update.

 

Adam

Share this post


Link to post
Share on other sites

Michael updated me again about his hi-res project(s) on December 3, 2019.

Here are Michael's comments:

 

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

 

I just wanted to let you know 6 pages of hi-res static graphics have been written. The multi-pager has no problem flipping through these 6 pages with a 10 sec view time per page. Its pretty cool. Since the graphics are already in 6 pages of screen RAM, except for the initial write to page 0, you don't see any graphics actually being written into a screen page. When the multi-pager switches to another page, the page just instantly appears. I'm going to wait until all 8 pages are written and the flip audio sound is added before I speed up the view time. I'm looking forward to that surprising demonstration ending.

Bye.
MCM

 

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

 

Michael's making fast progress!

 

Adam

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...