Jump to content
IGNORED

Miller Graphics Memory Editor


Opry99er

Recommended Posts

 

Opry99er, Acadiel posted the production test routines that MG used to run on all new GKs. I would use that to check out your unit. It runs through all of the RAM and does an extensive test. Also, there was a modification that MG put out because some units were prone to losing "bits" of memory when the GK was pulled out of and reinserted into a console with the power on. It involves a diode, resistor, cap change on the lower board. That is also posted.

 

Yep, find the GK archives that I scanned in... the sheet with the 'repair' (just a few components you have to swap out) is in them. We probably want to get someone like Mainbyte to put it on his page since so many people hit his page.

 

Also, double check the battery holder. I was getting intermittent contact; fixed it by bending back the top + metal piece on the holder by pushing it in without a battery. Between that and replacing the three components, mine seems to retain stuff well now.

 

If I'm not mistaken, it was the three parts that I circled that I replaced (enlarge the pic to see them - circled in red).

post-22866-0-95187900-1528516298_thumb.jpg

  • Like 1
Link to comment
Share on other sites

Okay, I was able to get it up and going again, edited the title screen, etc.. It works fine on reset. When the TI power is physically turned off, however, it loses all stored data. I'm going to try to bend the positive terminal down as Jon suggested, and then go from there.

Link to comment
Share on other sites

Okay, I was able to get it up and going again, edited the title screen, etc.. It works fine on reset. When the TI power is physically turned off, however, it loses all stored data. I'm going to try to bend the positive terminal down as Jon suggested, and then go from there.

 

When you're done, run the GKTEST (it will pull in GKTESU, GKTESV) file from the GK load module selection. It will run the GK production software that checks a number of things including all of the volatile memory. Selection one is the main program. Selection two will check battery function; you must run selection one first then you can remove your GK, reinsert it, reload the program and go to selection two. Note a couple of things; it will wipe the GK so save your work first. Selection two will hang on "busy...." after the first switch change unless you have a printer hooked up to your PIO port. Just do a GK reset if that happens.

 

It is a bare bones program that doesn't give you much feedback on what it's doing, unless it finds something wrong then it will let you know. So, no news is good news. The source files are there if you want to dig into it.

 

DSKA0035.hfe

  • Like 2
Link to comment
Share on other sites

Can standard cartridge binary files be loaded directly into the GK, or does one need to add a header of some sort for the GK to recognize it? I had this information at one point, but I can't seem to find it.

 

Well, this is going back a few years. If memory serves, the GK adds six bytes as a header to the file when you use the "Save Module" function. 1st byte: tag >FF or >00, 2nd byte GROM/ROM number, 3-4 bytes number of bytes to load, 5-6 bytes GROM/ROM address. Don't hold me to this until I check but I think that's probably it. Attached are the source files for the GK loader. Its in GPL and I used the Weiand GPL assembler that Heiner Martin sent me (in German no less!!). Hope this helps.

 

DSKA0073.hfe

  • Like 1
Link to comment
Share on other sites

Bending the positive terminal down seems to have corrected the problem, at least temporarily. It is a very robust and sturdy terminal (and seemed to be making a good connection) so I didn't think it could possibly be the issue, but it seems to have had an effect.

 

I was able to save GROM0, load GROM0, edit GROM0, INIT module space, load a module, edit a module, etc., and it all seems to have been retained in RAM after power-down.

 

I tried to re-save the module to disk but it told me I didn't have enough disk space. I attempted to save it as the same name as the module that was re-loaded to avoid any redundancy, but it said I didn't have enough disk space. I'm guessing that the GK is attempting to save the entire 56k of initialized module space and that is why it won't let me save... I don't think I have 56k left on that disk. This would make sense, but I don't understand why it is trying to save 56k of module space when the module itself is only 8k. Perhaps I need to do some more investigating.

 

In the meantime, here are some pix of my GK.

post-24953-0-30488500-1528951363_thumb.jpeg

post-24953-0-02969400-1528951387_thumb.jpeg

post-24953-0-35895100-1528951460_thumb.jpeg

  • Like 2
Link to comment
Share on other sites

Bending the positive terminal down seems to have corrected the problem, at least temporarily. It is a very robust and sturdy terminal (and seemed to be making a good connection) so I didn't think it could possibly be the issue, but it seems to have had an effect.

 

 

Maybe the pressure affected a cold solder joint on the positive terminal or something underneath.

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