Jump to content
IGNORED

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

Link to comment
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

Link to comment
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

Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
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

Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
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

Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
Share on other sites

  • 3 months later...

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

Link to comment
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

 

Link to comment
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
Link to comment
Share on other sites

  • 1 month later...

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

Link to comment
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

Link to comment
Share on other sites

  • 4 weeks later...

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

  • Like 1
Link to comment
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

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

I let a hi-res update slip by me a couple of weeks ago.  Here are two updates in one post.

 

Michael updated me again about his hi-res project(s) on January 13, 2020.  Here are Michael's comments:

 

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

Subject: Multi-Pager Test Demo Update


 
All 8 pages have been programmed with static graphics. A variable speed page flipper routine, including a flip sound, is finished and working. At maximum speed,  pages are flipped about every 1/4 second. I'm beginning to work on the moving critter who is getting very hungry to eat up most of the 8 pages of static graphics. It looks like the demo is going to be under 6KB leaving nearly 2.5KB for the upgraded hi-res Fish Demo. I have big graphic plans for this hi-res Fish Demo. I can already see it running in my mind. I'm hoping I can realize that vision with 2KB of EEPROM.

 

The static graphics in pages 6 and 7 get a real workout by the Z80 CPU. For example, when the demo text intro in page 0 is initially being viewed, not only is the Z80 utilizing multiple magic functions to write graphics into pages 6 and 7, but it is also working the stack area executing call/return and push/pop instructions in these 2 pages plus it is working with some variables in the scratchpad area. This is a significant test demonstrating that the Z80 can write to or read a user selected page while viewing another page on the TV screen.

 

The multi-pager hardware is working great. No surprise there, since the multi-pager hardware on my modified for hi-res static screen RAM Astrocade is a near copy of the Data Max UV-1R multi-pager hardware.

I am now being visually rewarded for all my hard work designing, building and testing this one-of-a-kind hi-res Astrocade. I am very pleased with its performance.

 

This new demo is looking really good to me. Wait till you see the hi-res Gunfight screenshot on page 7. In case you're wondering, MCM Design has no plans to convert the low-res Gunfight into hi-res. I chose a hi-res Gunfight screenshot for page 7 because it really shows off the hi-res screen resolution capability of the custom address and data chips in a "modified for hi-res" Astrocade.

 

Bye.
MCM

 

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

 

Lance Squire commented, "This sounds amazing.  I would love to see video of it when done."

 

This does sound fantastic to me too.  It's always a thrill to get an update from Michael... which is why I'm making this post, as he sent me his newest update this morning (February 4, 2020).  Here's what Michael says:

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

 

Subject: Multi-Pager Test Demo Update
 
I'm pleased to announce MCM Design has completed its multi-pager test demo/demonstration. It is an awesome demo. The demo description emailed to you previously has been 100% realized. The demo utilizes 5716 bytes leaving 2476 bytes for the hi-res upgraded Fish Demo, which will be attached to the end of the multi-pager demo.

 

Multipage programming is a new experience. Debugging the Move Critter routine was a challenge. This routine was another major test for the multi-pager. The Move Critter's main program is executed in the page 7 scratchpad area. The Z80 stack area is also switched to pages 0 thru 6 for the critter write routine. So, the challenge arose because the Z80 stack was switching back and forth from page 7 to the other pages, plus there was a screen interrupt countdown timer to deal with. You have to really pay attention to what is going on, always looking at the programming from the Z80's perspective. The screen interrupt issue was eventually resolved simply by adding a DI, EI instruction before and after the critter write subroutine, so this write routine couldn't be interrupted.

 

The vertical blank register is dropped all the way down during the Move Critter execution. You can easily see the Z80 working the stack PUSH/POP instructions during the critter write routine execution in pages 0 thru 6. You can also see the main Move Critter program of 98 bytes loaded into the bottom 2 lines in the page 7 screen RAM. This visual confirmation of what the demo is doing in the multi-pager during the Move Critter execution is a cool visual experience. The 98 byte main program was copied from cartridge ROM to page 7 screen RAM beginning at 7F20H. A jump to 7F20H followed the copy routine so that the Z80 would start executing the main program at 7F20H in page 7.

 

I decided to add one more short test demo. This demo will execute when a certain column key is held down while pressing the system reset button. There will be 3 connecting scenes (pages) with simplified static graphics to visually determine which scene is being viewed. A critter will initially appear in the center scene. The critter will be movable only using a hand control (input port #1).

 

This new demo will test how the multi-pager will react to the critter moving from the center to left scenes and back, plus the center to right scenes and back. This demo shouldn't take too many bytes. I am expecting at least 2K bytes available for the hi-res Fish Demo. I'm looking forward to seeing this hi-res Fish Demo executing. Hi-res rocks!

 

I also look forward to mailing you [Adam] my DVD so others can experience the New World of a hi-res multi-paging Astrocade. Too bad the Astrocade community doesn't have access to this kind of an Astrocade.

 

Bye.
MCM

 

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

 

Michael is really committed to sharing his worth with all of us.  I love it!

 

Adam

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

I have added five hand-written hi-res Astrocade documents by Michael Matte to a temporary area on ballyalley.com.  For now, and maybe for the next week or two, you can download them all as one zip archive, here:

 

https://www.ballyalley.com/temp/Hi-Res_Project_Update_MCM_Design_2020_02_pdf.zip

 

(January 28, 2021 - This file has been removed-- sorry for breaking the link, but there is an updated version of these documents, here: https://ballyalley.com/documentation/hi-res_packages/hi-res_packages.html#High-ResAstrocadeMLSubroutines).

 

The following five high-resolution projects for the Bally Arcade/Astrocade were created by MCM design and sent to me as photocopies in February 2020:

 

1) Convert Coordinates to Magic Address (2020 02)(MCM Design).pdf

2) Custom Hi-Res Graphic Routines for Astrocade (2020 02)(MCM Design).pdf

3) Custom Multi-Pager Write Routine (2020 02)(MCM Design).pdf

4) Update X and Y Coordinates in Vector Block (2020 02)(MCM Design).pdf

5) Write Relative from Vector Block (2020 02)(MCM Design).pdf

 

The documents mostly contain hi-res demo programs that work on the hi-res unit that Michael Matte built for himself.  These program will not run under emulation.  Below, in Michael's private emails to me, you'll get a general idea of that is in these documents.

 

These documents were all scanned yesterday and will eventually be added to ballyalley.com along with descriptions of each document.  As descriptions are written by the author of this documentation (see his email below), the files will be added to ballyalley.com.  In the meantime, the PDF files are available for those who are interested in them.

 

I won't be able to answer any questions about these projects, but here are the emails about them that Michael sent to me:

 

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

 

From: Michael Matte

Sent: Saturday, February 15, 2020 4:56 PM

To: 'Adam Trionfo'

Subject: RE: Scanned Feb 2020 Documents; was: Re: Mailed Documentation

 

All the scans look great. I wrote 4 pages of comments labeled A thru D attempting to briefly describe the purpose of each hi-res ML subroutine. Additionally, each subroutine is extensively commented on, including a note "This subroutine is similar to low-res sub #__" plus you might see a Nutting Manual reference page from where the hi-res sub was created. These ML sub docs are strictly for someone that has access to a modified hi-res Astrocade, is experienced in ML/AL programming and is looking for a custom hi-speed sub application. The docs intent is to help a hi-res programmer get started with custom programming hi-res graphic patterns and moving patterns around the screen without the need to create this particular hi-res application from scratch. If you want, I could summarize briefly the ML subs purposes on a document labeled E indicating if any of the subs are interconnected. You could also cut and paste each sub comments on docs A thru D and attach them separately as an intro to each of the hi-res ML sub postings. These ML subs, except the custom sub example for MCM Design's hi-res multi-pager, function similar to their low-res equivalent. However, these hi-res subs must be called directly. There is no processing UPI. Note MCM Design's up coming Hi-Res ROM will include sub's similar to these subs that you just scanned and will utilize an UPI. The ROM UPI and sub's will be well documented. No hand written docs for this project, I promise you.

 

Bye.

MCM

 

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

 

From: Michael Matte

Sent: Saturday, February 15, 2020 8:58 PM

To: 'atrionfo@hotmail.com'

Subject: Scanned Hi-Res ML Subs

 

If you are planning to post separately each one of those 5 hi-res ml subs that you recently scanned, I would be willing to text in the comments on pages A thru D, so you could copy and paste the comments as an intro to each posting. I guess I should have done that right off the bat. You wouldn't get my email with the comments until next week. I probably would expand upon the comments a little. I did do a rush job on those comments. The graphic pattern write subs do utilize the "Convert Coordinates To Magic Address" sub.

 

I'm maybe halfway through my 3 page interconnecting scenes with the hand controlled critter motion test demo. I am also planning to photocopy this demo program for posting because it is a short and more complete program utilizing the multi-pager. It could be a used as a lesson example on how to program the multi-pager for multiple scene games.

 

Regarding that DVD I mentioned a while back. I decided this DVD is going to be all hi-res demos with minimal comments. All BalcheckHR hi-res demo/test routines will be included. This way I can record the DVD pretty fast. I'm hoping you might find the time to possibly post each demo because I don't know how to do that. My expertise is pretty much related to the Bally/Astrocade low/hi-res hardware, its 8KB ROM operation and ML programming the Z80 on this computer system. That's about it. I'm also hoping that if the Bally/Astrocade community sees these hi-res demos, there might be an increased interest in modified hi-res Astrocades. There are a bunch of players out there with varieties of expertise. Perhaps a team effort could be utilized to generate a bunch of hi-res Astrocades. I know I would be interested in being a part of a team effort by volunteering to modify the motherboards for hi-res operation.

 

Bye.

MCM

 

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

 

Thanks, as always, to Michael for keeping us informed about his work on his on-going, high-resolution personal Astrocade project.

 

Adam

Edited by ballyalley
Updated the link
Link to comment
Share on other sites

  • 2 weeks later...

Michael updated me again about his hi-res project(s) yesterday.

 

In these comments Michael references pictures of the Perkins Engineering High-Res Astrocade from 1981.  Those picture can be seen here:

 

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

 

Here are Michael's comments (edited slightly per his request).

 

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

 

From: Michael Matte

Sent: Wednesday, February 26, 2020 12:45 AM

To: Ken Lill

Cc: Adam Trionfo; Lance Squire

Subject: Perkins Hi-Res RAM Scheme

 

Hi Ken. It's been a while since I have communicated with you. I have some hi-res news I believe you will be interested in. As you know, I am fascinated with the hi-res capability of the custom Bally Address/Data chips. Up to now, I have seen 6 hi-res screen RAM interfacing scheme variations. There are two Seawolf II schemes plus the DataMax UV-1R scheme which are posted on the Bally Alley. I created 2 scheme variations, one of which utilizes static screen RAM. The sixth scheme variation is by Perkins Engineering. The other day, I was browsing the Bally Alley, as I sometimes do, enjoying all the hi-res documentation. I looked at your photos of the Perkins hi-res scheme. I was intrigued once again by this scheme. I took time and made some notes related to what I was and wasn't seeing in these photos. I also checked out my emails related to Perkins scheme and its hi-res Basic. The other day, I was again on the Bally Alley, this time browsing the Perkins section. To my surprise, I accidentally stumbled upon the Perkins hi-res RAM interfacing schematic. Wow! Hopefully, the link below will get you to the Perkins hi-res schematic.

 

https://ballyalley.com/perkins/perkins.html#Perkins_Bally_Astrocade_Hi-Res_Schematics

 

This schematic is loaded with interfacing details. I believe, because of my experience in hi-res screen RAM interfacing and having discovered this Perkins schematic, I have unlocked a mystery related to the Perkins hi-res modification for the Bally/Astrocade motherboard. I believe I can decipher this schematic and figure out how the Perkins scheme works. I am excited about this discovery and am planning some time later on to spend more time investigating this scheme further. I already wrote down a bunch of comments related to this scheme. Below are a few of the comments I noted just looking at the Perkins schematic recently, that you might find of value. By the way, this may be the only documentation that Perkins drew up relating to this scheme. I say this because this drawing is very detailed and looks nearly complete. The only thing that is probably missing is the actual wiring to the screen RAM. That really would have to be drawn on a separate page but, in this case, is not necessary for anyone experienced with Bally/Astrocade screen DRAM interfacing.

 

 

1. Added Chips

 

All 39 chips are listed on the schematic.

 

There is no RAM address A0-A5 buffer 74LS244 (or equal) listed.

 

There is no RAM data in (DI) buffer 74LS244 (or equal) listed.

 

There is no RAM DI/DO transceiver 74LS245 (or equal) listed.

 

74LS165 chips are used instead of 74LS166.

 

DM81LS95 chips are used instead of 74LS253.

 

A 4K x 8 bit 2732 EPROM is listed.

 

 

Question A, Is there a wrapping wire soldered to the EPROM active low chip select (CS)?

 

 

Question B, Is this EPROM wired for 4k or 2KB? Check if the A11 pin is grounded or at +5V.

 

 

2. Seven Single Piggyback Chips

 

These 7 chips are labeled showing what motherboard U chip they are sitting on top of.

 

For example, at the bottom of Perkins schematic, LS175 (number 1) is labeled as being on the motherboard chip U8.

 

 

3. Logic Scheme At Very Top Of Perkins Schematic Using LS27, LS20, LS74, LS00

 

This is an output port outputting Z80 bits D0 and D1 to this port.

 

It's purpose is not clear at this time. Further investigation is required.

 

 

Motherboard ROMs active low chip select (CS) is wired to LS20B input.

 

 

Pin 11 of LS00B is wired to ROM U2, pin 20 (CS).

 

Is this labeled correctly? Should this be labeled as U4?

 

The Bally Service Manual on the motherboard layout drawing, indicates the EPROM location should be designated as U4.

 

Further investigation of this decoder is required.

 

 

4. LS175 Chip (Number 1, On Top Of U8)

 

RAS1, RAS2, and RAS3 are wired here to pins 4, 5 and 13 respectively. Pin number 12 is NOT wired to RAS0.

 

Looks like RAS0 is left pretty much "as is" on the motherboard.

 

There are some minor rewires to the motherboard indicated on the bottom of Perkins schematic related to RAS0 thru RAS3.

 

 

5. Bottom Left-Hand Corner on Perkins Schematic

 

Looks like there are only 5 breaks in motherboard traces.

 

Ditto marks mean?

 

 

6. Top Right-Hand Corner Of Perkins Schematic

 

There are 8 four-tier RAM towers.

 

The towers are located/labeled as 0 thru 7 matching the Bally motherboard layout.

 

The bottom tier, the standard DRAM chips U24 thru U31, are soldered completely into motherboard and are probably labeled as RAM Bank 0.

 

The top tier is probably RAM Bank 3.

 

 

7. Tower U23

 

Question C, Does this tower have only four DM81LS95 chips?

 

Line Side Of Chips (All 4 Chips)

 

MD0-MD7 are all wired to the custom data chip.

 

Not Shown! All MD0-MD7 lines are wired directly to the respective RAM data input (DI) pins 2 for all 4 RAM banks.

 

Looks like the custom data chip MD0-MD7 pins are driving all the RAM DI inputs. There is no buffer chip listed in the 39 chips list for this application. This is outside the norm. That means, for example, that the custom data line MD0, pin 28 is likely driving 4 RAM DI, pin 2 chips and is also wired to pin 17 of all  4 DM81LS95 chips.

 

Load Side Of Chips (all 4 Chips)

 

Perkins indicates where the load side wiring is connected to the data out (DO, pin 14) RAM chip pins by labeling the RAM connections at the right side of the four LS95 chips.

 

For example, at LS95 (number 0), pin 16 is wired to pin 14 of the RAM chip 1 in Bank 0.

 

 

8. Tower U20

 

Question D, Does this tower have 5 chips?

 

Question E, Is the bottom chip completely soldered into the motherboard?

 

If the Question E answer is yes, this is probably the standard U20, 74LS174 chip.

 

If this is so, this 74LS174 chip is likely driving all 32 chips for each of the address lines A0-A5. There is no buffer chip 74LS244 (or equal) listed in the 39 chips listing.

 

This means, for example, U20, output pin 15 is driving 32 RAM chip A0, pin 5 inputs. Ouch! This is outside the norm. If this is indeed the case for this modification scheme, apparently this bufferless set up still functions correctly.

 

There must be four 74LS165 chips on this tower. Ken's photos show multiple wrapping wires from tower U20 to tower U23. A total of 32 lines must be wired from the four LS165 chip RAM read inputs to the four LS95 chips. The four LS165 chips are used for the hi-res TV display scan. The RAM TV display read (scan) data is shifted serially along Serial 0 and Serial 1 lines to the custom data chip at its input pins 11 and 12. This scan may also serve to refresh the RAM row addresses.

 

Serial 0 is wired to pin 9, LS165 (number 0). Serial 1 is wired to pin 9, LS165 (number 2).

 

These 4 chips are clocked at pin 2 using the active low inverted 7M clock (pin 3 from U32).

 

The Shift Load line S/L is at pin 1 for all four chips.

 

A TV display read (scan) occurs when all four RAS lines are active high simultaneously. Four bytes at a time are read. The Shift Load line goes active low shortly after the four RAS lines are all active high simultaneously. The active low S/L line tells the four LS165 chips when to shift serially the four bytes of data into the custom data chip via the Serial 0 and Serial 1 lines.

 

Why was type 74LS165 chips used instead of the normal 74LS166?

 

Is this related to the medium-res mode?

 

Is the medium-res mode an undocumented optional mode for the custom address/data chips or is this mode generated using screen interrupts?

 

Why was the 74LS165 designation in this tower of chips "blacked out"?

 

Maybe only the top chip was "blacked out".

 

Note that MCM Design has accidentally found out that because the hi-res TV display is scanned and fed into the custom data chip Serial 0 and Serial 1 inputs, no screen RAM is actually required to display a simple hi-res graphic test pattern of vertical stripes on the TV. The test pattern can be created simply by "floating" and grounding specific "read" RAM data out lines at the four LS165 chip 32 read inputs. Think of the 32 inputs as four bytes or 16 pixels. Note also that to run this TV display test pattern, the 32 read input lines at the four LS165 chips can NOT be connected to the 32 RAM data output pins. To display a test pattern, a ML program must be executed to disable any screen interrupts, set up normal screen parameters, then "halt" the Z80 CPU. For more information on this unusual hi-res test, contact MCM Design.

 

Question E, When Ken had his Perkins hi-res motherboard running, did he actually see the low-res menu running in the upper left quadrant on the TV screen?

 

In one of Ken's Perkins hi-res motherboard photo, you can see 2 blue wrapping wires from the custom data chip, pins 11 and 12, Serial 0 and Serial 1 lines heading toward the tower 20.

 

 

Miscellaneous Comments

 

Question F, Does KEN have the power supply transformer to power his Perkins board?

 

MCM Design's BalcheckHR has a hi-res screen RAM test and also SetScreenHR to help troubleshoot a modified for hi-res Bally/Astrocade motherboard.

 

MCM Design plans to investigate Perkins hi-res scheme further sometime after the hi-res static screen RAM multi-pager demo and the hi-res demos on a DVD projects are completed.

 

Ken, at your convenience, could you take a look at your Perkins hi-res board and answer the above Questions A thru F? This would help me understand how Perkins hi-res scheme works. Who knows, after I complete my investigation, we might be able to troubleshoot your Perkins motherboard and get it up and running. Wouldn't that be cool.

 

Bye.

MCM

 

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

 

Today, February 26, I responded to Michael and said:

 

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

 

From: Adam Trionfo

Sent: Wednesday, February 26, 2020 11:57 AM

To: Michael Matte

Cc: Ken Lill; Lance Squire

Subject: Re: Perkins Hi-Res RAM Scheme

 

Michael,

(cc: Ken and Lance)

 

I didn't realize that there were so many different variations to make a Hi-Res astrocade.  You listed the following:

 

1) Hi-Res "Astrocade" - Seawolf II (Scheme 1)

2) Hi-Res "Astrocade" - Seawolf II (Scheme 2) - I didn't know there were two schemes!

3) Hi-Res "Astrocade" - DataMax UV-1R - Ken, are your UV-1/Z-GRASS schematics different from Michael's?

4) Hi-Res "Astrocade" - MCM Design (Scheme 1)

5) Hi-Res "Astrocade" - MCM Design (Scheme 2)

6) Hi-Res "Astrocade" - Perkins Engineering

 

There are also three more variations:

 

7) Hi-Res "Astrocade" - FPGA (Mike J's original Scheme)

8) Hi-Res "Astrocade" - FPGA (Mist Scheme)

9) Hi-Res "Astrocade" - Software Emulation - MAME (This properly supports the arcade games, but not the hi-res mode of a low-res Astrocade)

 

Ken, many years have passed since you took pictures of your modified hi-res board.  Do you think you could take pictures of it again using a modern camera or phone camera?

 

As a reminder, the pictures of the Perkins hi-res board are here:

 

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

 

Here are a few questions for Ken:

 

1) Lend Perkins Hi-Res Astrocade  - Might it be possible for Ken to lend his hi-res unit to Michael?  I'd be willing to pay the shipping if he is able to pack it up carefully.  Of course, please don't feel pressured by this question-- it's just an idea.

 

2) Re-Dump Hi-Res ROM - If Michael is able to get his hands on the board, it just might make it easier to understand how it works properly.  Also, I don't think that we were ever able to get a working dump of the Perkins engineering modified for Hi-Res ROM.  Maybe Michael could dump it either to another EPROM or two tape in a process it to make it working ROM image.

 

Michael, you have lots of questions-- most of which were very specific and over my head.  I hope that Ken is able to answer them for you.

 

Adam

 

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

 

Today, February 26, Michael responded to me and said:

 

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

 

From: Michael Matte

Sent: Wednesday, February 26, 2020 2:11 PM

To: Adam Trionfo

Cc: Ken Lill

Subject: Re: Perkins Hi-Res RAM Scheme

 

I would recommend first some clear top view photos of the motherboard (no angle shots), in particular the ROM area and by the Z80. If Ken has a tripod, he could tilt the motherboard so the entire motherboard would be at the same distance from the camera lens to eliminate areas that are not in focus. If there is any wrapping wire at the bottom of the board, Ken should take a photo of that. If I can get access to some clear photos, the photos plus the schematic may be enough to understand how Perkins scheme works. I plan to redraw a portion of Perkins schematic, so it is easier to read for me.

 

If Ken is not able to get the the board running perfectly, I would be willing to troubleshoot it, with the understanding that any tampering of the board would have to be approved first by Ken. Ken has a rare piece of Bally/Astrocade history. That would be cool to get that board running perfectly.

 

Regarding Perkins hi-res Basic. The Arcadian comments attached to Ken's photos indicates this Basic was intended to run on the medium-res mode. Also there is mention of a 12KB user RAM (possibly addressed 5000-7FFFH). The implication is that this hi-res Basic was to be loaded perhaps at 5000H, was 5KB long leaving 7KB left for Basic programs. Has anyone listened to the Wav file of this hi-res Basic? It sounds like there are 2 programs recorded together. One of the emails you sent to me suggests the first program may be used by Bally Basic or Astrobasic for tape loading purposes. Any comments?

 

 

Bye.

MCM

 

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

 

It's great that Michael found the Perkins hi-res schematics, which I think I added to BallyAlley.com in 2006 and completely forgot about placing on the website.  You see, even I "discover" what's on my own website from time to time.

 

Adam

Link to comment
Share on other sites

Over the past few days (February 28, 2020 to March 1, 2020), Michael Matte has been sending me updates on his hi-res project and his investigation into the astrocade that John Perkins modified for hi-res and medium-res modes that was created in the early 1980s.

 

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

 

From: Michael Matte

Sent: Friday, February 28, 2020 4:07 PM

To: Adam Trionfo

Cc: Ken Lill; Lance Squire

Subject: Hex Editor

 

Hi Adam. I'm going to need to use a hex editor to view some of the Z80 coding in the Perkins EPROM bin file. This may help me determine how Perkins modified ROM decoder and EPROM switch to the hi-res mode. It looks like I have 2 hex editor choices, HxD and Winhex. I remember downloading HxD some time ago, but couldn't find a user manual on it's website. [...] I can examine this coding gradually while I'm having breakfast. That also would be great if I could print out a hex dump of Perkins EPROM.

 

While I'm talking to you about Perkins modification scheme, I spent a little time and deciphered some of Perkins modified ROM decoder and found that the motherboard chip select (CS) line to ROM chip U2 was cut and rewired to Perkins modified ROM decoder. The EPROM is at location U4. Very peculiar at this time. Every one of the 2KB ROM chips on an unmodified motherboard seem to be identically wired. This makes me think that each custom 2KB ROM chip must have some additional internal address decoding connected to its chip select. Up to now, I was assuming that U1 was addressed 0000-07FFH. When I looked at the Bally PA-1 Service Manual, the parts list indicated U4 as ....HVSA and U1 as ....HVSD. Now I'm not so sure which ROM chip is addressed 0000-07FFH. Maybe the EPROM coding would help me make that determination.  Also, I need to determine how the motherboard ROM powers up in the hi-res mode. Somehow 01H has to be output to port 08H to get the custom address/data chips to run in hi-res. Maybe a keypad key has to be held down at the system reset to run the motherboard in hi-res or possibly low-res. This is another reason to look at the EPROM coding.

 

Bye.

 

MCM

 

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

 

From: Michael Matte

Sent: Saturday, February 29, 2020 2:58 PM

To: Adam Trionfo

Subject: Hex Editor

 

Hi Adam. I managed to install HxD 2.4.0.0 and dragged the "Hi-Res 2K chip data.bin" file into the HxD window. All 4096 bytes 0000-0FFFH where listed. I also managed to print out the entire 4KB file as a hex dump. That's the good news.

 

My interest today was to see if there was an indication of any kind of a power up routine (hi-res or even low-res) at the EPROM locations 0000H or 0800H.

 

At 0000H, the code 6B was there. If that code was a Z80 instruction, it would be LD L,E.

 

At 0800H, the first 2 codes are EB and FB. These codes if they were Z80 codes are EX DE,HL and EI.

 

So, these 2 EPROM locations do not initiate a power up routine. I was hoping 0000H would initiate a power up, thinking that this EPROM might reside at the ROM address 0000H when the motherboard runs in hi-res, which is where the Z80 jumps to when the system reset button is pressed.

 

Now, I'm wondering if access to the hi-res mode is thru the low-res menu via the normal menu linked list.

 

I recall Ken indicating that his Perkins modified hi-res motherboard was one time working and so I'm thinking he saw how access was made to the hi-res mode. I'd like to ask him if he can recall how the motherboard was set up to access the hi-res mode. So far, I haven't seen any interest by Ken via email related to my Perkins investigation other then his comment about my recent question regarding the wiring of the four 2KB ROMs. I don't want to bother him with email questions. [Later, Ken did contact Michael.]

 

I'm going to put my Perkins investigation aside now and get back to it after I finish recording my hi-res DVD. At this time, I have no reason to learn how to use a disassembler tool, so I won't be bothering you tonight with a phone call, even though I must admit I was excited about the opportunity to speak with you. Thanks for your willingness to help me.

 

Bye.

 

MCM

 

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

 

From: Michael Matte

Sent: Saturday, February 29, 2020 6:33 PM

To: Adam Trionfo

Subject: Perkins Hex Dump

 

Adam, for what its worth, I'm wondering about the accuracy of the Perkins EPROM .bin file. In my printed hex dump, there is a pair of character strings # OF PLAYERS # OF GAMES appearing in 4 different locations.

 

Bye.

 

MCM

 

Added Note

 

I think I confirmed my suspicion. This hex dump may be garbage. The first pair of char strings # OF PLAYERS # OF GAMES appears exactly at the same address in low-res ROM. If you work backwards and compare the hex dump codes with the low-res ROM codes, you will see similarities. I checked some bytes from 0000H-03FFH and the similarities appear to continue in this range. At 04FFH the similarities seem to end. It looks like at least the beginning of the EPROM is a near copy of low-res ROM.

 

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

 

From: Adam Trionfo

To: Michael Matte

Cc: Ken Lill, Lance Squire

Sent: Saturday February 29 2020 9:01:39PM

Subject: On Your Recent Emails

 

Michael,

(cc: Ken Lill and Lance)

 

I ended up being gone most of the day today [...], so I'm glad that you weren't waiting on me to help you out.  I probably still could have done it, but I would have had to do it while [at a show]:

 

I always suspected the ROM dump was bad (I think it was dumped to tape and then converted to "ROM").  Maybe the EPROM for the hi-res unit can be pulled out and dumped?  Even though the dump turned out to be bad, I'm glad that you were able to get a print-out of it, as that may prove useful to you in the future.

 

Your hex program questions have inspired me to make a video of how to use a hex editor to check out an Astrocade ROM image and maybe even how to start a disassembly of an Astrocade cartridge.  Of course, that would also require a video of how to assemble astrocade Z80 code... and then the list of to-do videos goes on and on until I don't know where to begin making any video at all.

 

Adam

 

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

 

From: Michael Matte

Sent: Saturday, February 29, 2020 9:45 PM

To: Adam Trionfo

Subject: RE: On Your Recent Emails

 

I know the feeling. Having projects you'd like to work on which creates more projects. I seem to be getting side tracked a lot these last several months.

 

Having no Perkins EPROM dump decreases my interest in my Perkins investigation. My interest has decreased, but it still hopeful. Ken's EPROM may have a pin or two bent straight out. Bending them back for a hex dump would risk breaking the pins. I've already broke a few EEPROM pins. A broken pin is fixable if there is still some pin left to apply solder, but it is a pain to fix.

 

My motivation on the Perkins investigation was directed toward that medium-res mode because I wanted to understand how it was generated. I suspect it is not an undocumented custom chip generation via an output instruction to port 08H. Perhaps it is related to the application of LS165 chips instead of LS166 chips or perhaps it is generated using hi-res screen interrupts. Anyway there is really only one thing more I can do unless Ken can provide missing info. That would be for me to decipher the 74LS165 chip interface and see if that would tell me anything. But, as I said previously, my investigation is now on hold until I finish recording my hi-res DVD. I'm really hoping your postings of the hi-res demos will stir up some more interest in the Astrocade community. I would like that. Thanks again for your desire to help me out.

 

 

Bye.

 

MCM

 

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

 

From: Michael Matte

Sent: Sunday, March 1, 2020 8:16 PM

To: Ken Lill

Cc: Adam Trionfo, Lance Squire

Subject: Perkins Investigation Report 1

 

 

PERKINS HI-RES MODIFICATION SCHEME, REPORT 1

 

BY MCM DESIGN

 

I have spent time investigating the logic scheme, at the very top of Perkins interfacing schematic, using the LS27, LS20, LS74 and LS00 chips. Here are my findings in my first report. First, thanks to Ken Lill's email statement to me relating to the custom 2KB ROM chips internal wiring of address lines A11 and A12, the 4 ROM chips are addressed as indicated below.

 

Board  MFGR

Label   Label

 

   U4      HVSA  0000-07FFH

   U2      HVSC  0800-0FFFH

   U3      HVSB  1000-17FFH

   U1      HVSD  1800-1FFFH

 

Operating System     0000-0E18H

 

3 Games, Calculator 0E19-1FFFH

 

A 24 pin wire wrap socket, with its posts trimmed, is soldered into the motherboard at the ROM chip location U4.

 

The 4K x 8 bit 2732 EPROM is installed into the WW socket.

 

Ken's photos do NOT reveal how the right side of the EPROM is wired, in particular, the EPROM's pin 21 (A11) and pin 18 (active low E?).

 

The Perkins photocopied schematic is "clipped off" on the very top of the schematic.

 

The LS27 chip contains triple 3-input NOR gates.

 

Because of the photo clip, 5 chip pins are subject to speculation regarding where they are wired to. One of Ken's photo may reveal one connection. Here's my speculation.

 

1. LS27A, pin 13 (on top of U13) is wired to the Z80 address A0 line, possibly at U9, pin 2.

 

2. LS20A, pin 13 (on top of U14) is wired to the Z80 address A3 line, possibly at U4, pin 5.

 

3. The LS74 A and B clear (clr) pins 13 and 1 (on top of U21) may be wired to the 1.0 MFD "reset" capacitor C13 (positive end). This cap is wired to the system reset button. This capacitor is shown on the Bally PA-1 Service Manual motherboard layout and schematic. Another option is that the 2 clear pins are wired to +5V.

 

4. LS00A, pin 9 (on top of U22) is connected to LS20B, pin 6 by wiring this pin 9 to its neighboring pin 13 on LS00B.

 

5. LS00A, pin 8 is wired to the U4 EPROM chip select, pin 20.

 

The LS27, LS20 and LS74 logic scheme is a custom output port 08H. The output D0 bit to LS74A, pin 12 is used to decode EPROM U4 and ROM U2 for hi-res and low-res operation. LS00B is used to decode and select ROM U2 in the low-res mode. This part of my speculation is not clear to me at this time, possibly because of the missing wiring in the photocopy "clip off". This is why I want to decode the EPROM power up routine. It is not clear to me at this time, how the EPROM can distinguish between a low-res or a hi-res mode request to output port 08H. A part of the EPROM must include the low-res operating system. How much of the 4KB EPROM is used for the hi-res and med-res modes is unknown at this time. An examination of the EPROM's hex coding would help answer that question.

 

The custom output port 08H, bit D1 is related to the hi-res video scan, to possibly enable the inverted 7M clock scan for hi-res and possibly inhibit this clock for low-res, so the low-res video scan can be fed into the custom data MD0-MD7 lines. This scheme will be investigated later.

 

I loaded Ken's EPROM bin file into a hex editor and printed out a hex dump of the entire 4KB. I have examined some of the coding and have deemed this bin file as bad (inaccurate). I emailed my reasons to Adam Trionfo. I can say the following with some certainty.

 

1. Some of the coding at the EPROM location 0000H+ is an inaccurate copy of the low-res ROM operating system.

 

2. There is NO low-res output request to port 08H at address 0003H.

 

3. At address 0005H, there is a Z80 jump C3 61 0C code to the power up routine (just like the low-res ROM). I will not attempt to decode the power up routine now because I have deemed the coding there as untrustworthy.

 

In conclusion, my Perkins hi-res modification scheme investigation is "on hold". I have gone as far as I can with my investigation of this 8 gate output port/ROM decoder scheme at the top of Perkins interfacing scheme. In order to further investigate this scheme to understand how the U4 EPROM functions, I need:

 

1. Clear photos or "word-of-mouth" info detailing the missing 5 pin wiring on the top of Perkins schematic described in my above speculation and also the wiring on the right side of the EPROM as mentioned above.

 

2. An accurate hex dump of the EPROM, so I can at least decode the power up routine.

 

I plan to, some time later, continue my investigation as to why Perkins chose to use 74LS165 chips instead of the normal 74LS166 chips. I plan to redraw the 74LS165 scheme and also the RAS0-RAS3 timing scheme shown at the bottom of Perkin's schematic, so the wiring is easier for me to read (interpret). Perhaps this future part of the investigation may provide clues as to how the EPROM is utilized. Wish me luck.

 

End Of Report 1

 

MCM Design

March 2020

 

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

 

Michael is making some good progress.  I can't remember the original source of the Perkin's hi-res schematic.  It either was in the Bob Fabris Collection or maybe Ken Lill or Michael White had it in their collection.  I don't know if the "clip-off" was on the original photocopy or if it happened when the photocopy was scanned.  I'll look into this matter.

 

Adam

Link to comment
Share on other sites

Thanks for uploading all of this great information! I would be very interested in purchasing some kind of High Res add on for the Bally Professional Arcade. I wish anyone who is currently trying to make this a reality the best of luck. It would be awesome to have an XM or SGM type module to fully realize the potential of this phenomenal machine.

Link to comment
Share on other sites

On 3/2/2020 at 1:56 PM, adamchevy said:

Thanks for uploading all of this great information! I would be very interested in purchasing some kind of High Res add on for the Bally Professional Arcade.

 

I'm glad that you're enjoying reading about the hi-res Astrocade updates.  The Astrocade was designed in a manner which doesn't allow a hi-res add-on to be created for it.  While RAM can be added to the system via the 50-pin connector on the back of the unit, in order to access hi-res mode, the Astrocade motherboard needs to be modified.

 

I've read theories that a pseudo hi-res-like "mode" could be used, but it would be a trick, as it would work in much the same manner that the Atari 2600 draws the screen-- line by line.  Rather than using a screen buffer as is normally done with the Astrocade, this machine-language only method of mimicking hi-res would use a line-buffer.  This goes against how the Bally Arcade console was designed, which was for ease-of-use.  Some preliminary work was done in this area under emulation, but the emulator doesn't support drawing in this manner so confirmation of this trick can't be confirmed with 100% accuracy.

 

Adam

Link to comment
Share on other sites

Here are the latest hi-res updates from Michael Matte concerning the one-of-a-kind hi-res Astrocade that was made by Perkins Engineering in the early 1980s.

 

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

 

From: Michael Matte
Sent: Tuesday, March 3, 2020 7:55 PM
To: Adam Trionfo
Cc: Lance Squire
Subject: Perkins Hi-Res Scheme
 
Last evening I just had to take one last look at the Perkins hi-res modification scheme, before I put aside my investigation of this scheme for perhaps a month or more. I have come up with 2 theories related to Perkins scheme.

 

Theory 1

 

The medium-res map of 160 x 204 pixels will be displayed on a TV/monitor by outputting 0000 0011 (03H) to port 08H. The Perkins scheme has the option to inhibit the inverted 7M clock that is used for the hi-res video display scan. This option maps out the medium-res video display. This is a very cleverly designed option.

 

The 74LS165 chip has a clock inhibit input. My 74LS data book indicated that the clock input is inhibited when the CI input is high. The Perkins inhibit logic scheme utilizes the LS74 (a custom 08H output port), LS00D and LS00C gates. The motherboard PX clock is input to the LS00D, pin 2. The PX clock frequency is twice as slow as the inverted 7M clock. Normally, the hi-res video scan reads 4 bytes (16 pixels) at a time. As I see it, when 03H is output to port 08H, every other 7M clock tick high will be inhibited (shut off). The hi-res video scan will continue reading 4 bytes at a time, but only 2 bytes (8 pixels) of the 16 pixel data will be shifted out, from the four 74LS165 chip inputs, into the custom data chip Serial 0 and Serial 1 input lines, mapping out only 160 pixels on the screen horizontal line instead of 320 pixels. All 204 hi-res horizontal lines will be scanned and mapped out onto the TV screen. The med-res mode utilizes only RAM banks 0 and 1.

 

Theory 2

 

74LS166 chips can be substituted for 74LS165 chips. However, the pin layouts are not compatible.

 

Action To Take

 

I plan much later to test these 2 theories on my hi-res static screen RAM prototype board, to see if the theories are correct.

 

I also may be able to utilize a portion of the Perkins scheme to simplify the hi-res video scan scheme on my hi-res static screen RAM board.

 

I will email you the results of these experiments when they are run.

 

Bye.

 

MCM

 

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

 

It neat to see this project evolve in small steps.  I really think it's great that despite the obstacles, Michael has been able to persevere and keep his heart and mind interested in his hi-res Astrocade project off and on since 1986 or so; that's kind of mind boggling to me.

 

Adam

Link to comment
Share on other sites

  • 1 month later...

Here are the latest hi-res updates from Michael Matte:

 

(Update, June 5, 2020: I realized that I didn't place Michael's April 3, 2020 update into this thread, so I'm adding it to the beginning of this post so that the order of the updates is preserved.)

 

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

 

From: Michael Matte

Sent: Friday, April 3, 2020 12:19 AM

To: Adam Trionfo

Cc: Lance Squire

Subject: Multi-pager Tests Update

 

I finished the test demo which moves a critter around 3 connecting page scenes using a hand controller. This test demo executes perfectly. The multi-pager hardware is very precise when a program instructs the Z80 CPU to read from or write to any of the 8 screen RAM pages, including the pointing of the Z80 from one page to another to work the Z80 stack or the scratchpad areas within any page. As a ML programmer, this is a new experience for me, programming a multi-pager. You really have to pay attention to what you are instructing the Z80 to do. It's pretty easy to create a bug in a ML multi-page program and can sometimes be a major challenge to see the bug. I was nearly stumped by one particular bug, but I eventually found it.

 

Now I am beginning to program the final and last hi-res demo, which will be exciting for me to create, to complete my 8 KB multi-page test demo package. I have nearly 2 KB to create an upgraded single page hi-res fish demo. That's quite a lot of memory to work with for this particular kind of demo. So, when I say upgraded, the demo will definitely show off hi-res graphics compared to my low-res fish demo in BalcheckHR. I chose to upgrade my low-res version of Bit Fiddler's Fish Demo because a lot of the creative work has already been done. This work can be revised and converted to hi-res quicker than creating a brand-new demo from scratch. The multi-pager hardware has now been tested and deemed by MCM Design to be very precise, so I want to finish this 8 KB package as fast as possible. I'm really looking forward to seeing the upgraded Fish Demo running. Graphics wise, it may be as cool as MCM Design's "The Pixel Stringer".

 

The hi-res fish demo will have some tiny minnows, a few sea horses and larger types of tropical fish, perhaps as many as 15 total swimming around the screen.

 

This demo will also have a sea bottom with some static graphics. I will try a screen interrupt to see if I can provide an additional 3 colors in and around this sea bottom. That would mean the demo would have 4 colors on top with 3 additional colors on the bottom of the screen.

 

Bit Fiddler's Fish Demo and my BalcheckHR Fish Demo used 2 graphic ROM patterns for a fish facing left and facing right. I am going to experiment in this hi-res demo using just one pattern per fish along with a magic flop for the other faced direction. The magic standard for low-res and MCM Design hi-res is to use bit 6 in the magic register value, which is output to the Magic Register, for a mirror image flopped coordinate system. This standard flop has limited applications. However, it is possible to flop the pattern anywhere on the screen using an "adjusted x-coordinate" once you understand how the pattern is flopped using the standard flop application. MCM Design is going to test a new idea. Since bit 7 in the magic register value is normally not used for a magic function, why not use that bit 7 for an extended magic flop application request. A subroutine could be written to check bit 3 for a magic flop request, then check bit 7 for an extended magic flop option request. This extended option would utilize the standard coordinate system, take the standard x-coordinate for a normal pattern write and automatically adjust the x-coordinate so the flopped pattern write would be written in the same location as the normal pattern write. With this extended option, a pattern could be easily written facing left or right in the same specified screen RAM location.

 

As mentioned in a previous email, this demo will also include a hr:min:sec elapsed timer and will be the last demo running in the 3 demo sequence, which cycles nonstop. There will be an option to run only the upgraded Fish Demo nonstop.

 

This is going to be a lot of fun creating this hi-res fish demo. Soon after the demo is finished, I'll record on DVD all of MCM Design's hi-res programs. I am hoping this collection of hi-res Astrocade programs will stir up some more interest for a modified hi-res Astrocade. A hi-res Astrocade rocks!

 

Bye.

MCM

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

 

From: Michael Matte
Sent: Wednesday, April 29, 2020 1:13 PM
To: Adam Trionfo
Cc: Lance Squire
Subject: RE: An update on ZGRASS
 
Hi-Res Fish Demo Update.

 

All the low to hi-res conversion coding is completed. The coding is set up for the motion of up to 18 fish. Whether or not the Magic RAM or possibly the Z80 can handle that much motion perfectly remains to be seen. My particular DRAM or SRAM  hi-res hardware design could impose some restrictions. I know for sure that 9 patterns can be moved around a hi-res map with no problems. This hi-res fish demo also utilizes 2 screen interrupts to split the screen horizontally, so I can add 3 more new colors to the sea bottom. Having 2 screen interrupts might create some problems writing multiple graphic patterns, I don't know. Anyway, I am soon going to begin my experimentation moving over 9 fish around a hi-res screen map.

 

I used Bit Fiddler's clever approach to move multiple fish around the screen using only one vector block. I came up with an idea to extend this approach for an application using multiple sizes of fish, each with its distinct vector limits table, so that the required Z80 coding would be minimized. If all goes well, there would be 6 types of fish. I replaced my sea horse pattern idea with a fish because I could not come up with a TINY sea horse pattern that was to my satisfaction.

 

My idea presented to you earlier, to use bit 7 in a Magic Register value as an extended flop request, to flop a pattern in the exact same pattern frame as a normal write, works great. It took me a while to figure out and come up with a routine to compute the required x coordinate adjustment for a flop. I forgot that a normal magic write shifts right and a flop write shifts left. Oops!

 

Bye.
MCM

 

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

 

Michael's continued progress is wonderful to watch.

 

Adam

Edited by ballyalley
Added Michael's April 3, 2020 update, which had been skipped by accident.
Link to comment
Share on other sites

  • 2 weeks later...

Here are the latest hi-res updates from Michael Matte:

 

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

 

From: Michael Matte

Sent: Sunday, May 10, 2020 9:02 PM

To: Adam Trionfo

Cc: Lance Squire

Subject: Hi-Res Fish Demo

 

I ran a program that moved 17 fish around the screen. The 2 larger fish type pattern frames were 20 x 18 pixels (W x H) and 16 x 20 pixels. I ran this program on both of my modified hi-res Astrocades, one with  DRAM, the other with SRAM. There were NO magic write problems.

 

Since this was more of a test program today, I am opting to reduce the fish count near 10, but increase the pattern frame size for some of the other fish types. Increasing the fish size really allows me to show off the hi-res graphic and color details.

 

The present tiny minnow will be replaced with a minor variation of Bit Fiddler's 8 x 7 pixels goldfish, because the goldfish pattern is better looking than my minnow pattern, plus the goldfish can be viewed as a "low to hi-res" comparison.

 

I also ran the multi-pager test demo, critter move/erase 8 pages routine and the hi-res fish demo in sequence, as originally planned, just so I could watch much of my hard work programming this 8KB hi-res demo project.  I'm very pleased with the results so far. I'm looking forward to detailing the sea bottom soon.

 

Bye.

MCM

 

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

 

Despite the highly unusual present circumstances, Michael just keeps on working on his hi-res demo.  It's great to see progress continue on his project.

 

Adam

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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