Subject: My 80K GramKracker is losing it's memory

From: Bill R Sullivan <[email-masked]>
Date: Fri, 08 Nov 2013 13:44:47 -0700

Well it looks like some of my fun hobby times are coming to an end, as 
GRAMS 1 & 2 are no longer holding all of their loaded code for more than 
a few minutes.  Specifically the E/A CALLs added to TI BASIC by Rich 
Gilbertson and modified by Tursi for MSAVE'd BASIC programs.  Even if I 
use it for BOOT MENU which only needs to be switched in for the transfer 
to high memory, and then switched out, eventually gets corrupted.

Previously before I moved to Bullhead City (BHC) I believed I was 
causing it by using the GK reset switch, and due to the fact that GRAMS 
1 & 2 are not protected by the RAM Bank 1/2 protection switch as all 
other GRAM & RAM are, but the BOOT MENU corruption proves that is not 
the case.

This prompted me to test GRAMS 1 & 2 using the GK memory editor.  
Filling >g2000->g5FFF with >FF was 100% OK, but filling both GRAMS 1 & 2 
with >00 was not good at all. especially GRAM 2, >g4000->g5FFF had many 
random locations showing >20, and trying to change one address caused 
other addresses in the GK view to change to >20 from >00 or from >20 to 
 >00 in the view.  I don't seem to have any problems with GRAMS 3-7 or 
0, but I'm not currently using a modified GROM 0 (OPSYS), but have 
considered loading a true lowercase character set there.

As the GK manual doesn't inform me as to what the 8K GRAM chips that are 
used for GRAM 0-2 are, I was hoping some one in the community could tell 
me, as I haven't had to open up my GK to change batteries since I 
modified it to change out the battery through a hole in the bottom of 
the case.  I would prefer to wait until I have the replacement chips 
first.  I might also need to know where I can purchase the chips if 
someone knows what they are.  Please help me if you can, as this GK is 
my most important peripheral for my CF7A+/NanoPEB systems.
-- 
Bill R Sullivan (fdos)

---

From: [email-masked]
Date: Sat, 09 Nov 2013 17:20:49 -0500

Hi Bill,

Based on your observations, the problem may not be with a ram chip, but 
with a logic chip.
If multiple bytes are being altered when you change one, a 'switch' in 
one of the logic chips
may not be turning off. You may want to change out the logic chips that 
affect Grams 1 & 2,
as well as the associated Ram chip.

Tony

On 11/8/2013 3:44 PM, Bill R Sullivan wrote:
> _

---

From: Bill R Sullivan <[email-masked]>
Date: Sun, 10 Nov 2013 10:26:47 -0700

Ah so, I never thought of that. I just believed it was a flaky memory 
chip or two.  However, I don't get much inspiration these days due to 
the meds.  I have mush for brains and muscles besides not seeing 
clearly.  It's very unsettling.

Thanks a lot Tony, but I don't know what or which logic chip controls 
any of the memory in the GK other than the front panel switches.  In 
fact, I used the "Loader" switch to select and save the GK memory 
editor/GRAM loader&saver to disk and use it on my HSGPL cards to save 
HSGPL modules to GK format, and to edit/patch HSGPL GRAM/RAM modules.  
So other logic controls just did not enter my feeble mind.

However, what does come to mind is a question for you.  Is there a way 
to adapt your HSGPL module loader program to an 80K GK? Saving GK 
modules doesn't require any manual switch operations, but loading 
modules require manual switch control of the W/P switch to Bank1 & 
Bank2; either one when loading normal GRAM, Bank1 for single RAM bank at 
 >6000, but usually Bank2 then Bank1 for XB modules (switch remains on 
Bank1 during the GRAM loads).  The loader provides prompts for all 
switch activity during the module load process, and also directs us to 
use both banks for some single ROM bank modules with no GRAM.  COMMAND 
DOS (AKA 4ADOS) for one.  This is common for the HSGPL module loader. 
80K units require OPSYS/GRAM0 and TIBASIC/GRAM1&2 to be in the 
appropriate GRAM position to load these areas.  Only GRAM0 requires the 
W/P switch to be in Bank1 or Bank2 when loading.

It looks like I will have to take the thing apart before ordering memory 
or logic chips, and that is very unsettling in my current condition as I 
was hoping to order the parts and have them on hand when my grandson the 
Marie comes home for Thanksgiving.  I'm sure I can disassemble it 
without doing any damage, but I definitely can't re-assemble it without 
really good help.  This means it will be unusable until he gets here, 
even though the standard GRAM/RAM part works well for the modules I 
normally use in TIB+ development or just having hobby fun.

Bill R Sullivan (fdos)

On 11/9/2013 3:20 PM, [email-masked] wrote:
>
> Hi Bill,
>
> Based on your observations, the problem may not be with a ram chip, 
> but with a logic chip.
> may not be turning off. You may want to change out the logic chips 
> that affect Grams 1 & 2,

---

From: [email-masked]
Date: Sun, 10 Nov 2013 13:40:11 -0500

Hi Bill.

You know you don't have to load HSGPL modules in the Gram Kracker to 
edit them, don't you?
Load the Module to be edited into bank >10, have an EA module loaded in 
another bank.
Do a "CALL GRAM" from TI Basic. Select EA option 5, load MEMEDIT, which 
is the Editor
I 'lifted' from the Pgram DSR. Turn on CRU bit >1B02 01. Bank >10 will 
respond as the first
page of the editor due to the 'CALL GRAM' command. Edit to your heart's 
content. :-)
Save from the HSGPL MENU when you're done.

Link to Pgram Editor stand alone EA5 file:

ftp://ftp.whtech.com/utilities/MEMEDIT.DSK

The HSGPL loader program could be adapted to the Gram Kracker, but I'd 
probably need a
Gram Kracker to do it. Unfortunately at this point, I don't have one, 
nor a console, nor a flex
cable. Just a Snug system, a Geneve, and some spare parts at this point.

Tony

On 11/10/2013 12:26 PM, Bill R Sullivan wrote:
> Bank2; either one when loading normal GRAM, Bank1 for single RAM bank 
> at >6000, but usually Bank2 then Bank1 for XB modules (switch remains 
> on Bank1 during the GRAM loads). The loader provides prompts for all 
> appropriate GRAM position to load these areas.  Only GRAM0 requires 
> the W/P switch to be in Bank1 or Bank2 when loading.
>
> It looks like I will have to take the thing apart before ordering 
> memory or logic chips, and that is very unsettling in my current 
> condition as I was hoping to order the parts and have them on hand 
> when my grandson the Marie comes home for Thanksgiving.  I'm sure I 
> can disassemble it without doing any damage, but I definitely can't 
> re-assemble it without really good help.  This means it will be 
> unusable until he gets here, even though the standard GRAM/RAM part 
> works well for the modules I normally use in TIB+ development or just 
> having hobby fun.
>
> Bill R Sullivan (fdos)
>
>

---

From: Bill R Sullivan <[email-masked]>
Date: Mon, 11 Nov 2013 09:24:04 -0700

Hi Tony,

I guess I didn't explain the GK editor process very well.  It is stored 
in the first GROM of TIBASIC in the GK when the loader switch is 
activated, but when selected it can load GROM/GRAM files or EA5 program 
files into expansion memory.  I simply operated the loader switch, and 
saved the first GROM of TIBASIC (actually the GK loader program in this 
case) to disk, then converted it to HSGPL format for use in my HSGPL 
cards using Harold's GK to HSGPL program.  In this case no E/A module or 
P-Gram Editor program required.  I usually keep it in GROM1 of the last 
HSGPL GROM page.  It can load files from hard disk sub-directories, if 
path is not too long, and I'm very familiar with it's usage, so no need 
to learn another editor's operation.  I do own a P-Gram+ card, but I've 
never used the editor.

Bill R Sullivan (fdos)

On 11/10/2013 11:40 AM, [email-masked] wrote:
> Load the Module to be edited into bank >10, have an EA module loaded 
> in another bank.
> Do a "CALL GRAM" from TI Basic. Select EA option 5, load MEMEDIT, 
> which is the Editor
> page of the editor due to the 'CALL GRAM' command. Edit to your 
> heart's content. :-)
>> HSGPL modules to GK format, and to edit/patch HSGPL GRAM/RAM 
>> modules.  So other logic controls just did not enter my feeble mind.
>>
>> However, what does come to mind is a question for you.  Is there a 
>> way to adapt your HSGPL module loader program to an 80K GK?  Saving 
>> GK modules doesn't require any manual switch operations, but loading 
>> switch activity during the module load process, and also directs us 
>> to use both banks for some single ROM bank modules with no GRAM. 
>> COMMAND DOS (AKA 4ADOS) for one.  This is common for the HSGPL module 
>> loader.  80K units require OPSYS/GRAM0 and TIBASIC/GRAM1&2 to be in 
>> the appropriate GRAM position to load these areas.  Only GRAM0 
>> requires the W/P switch to be in Bank1 or Bank2 when loading.
>>