GRAM DEVICE

[RXB]

Ok, I guess I still need some steps since the manual makes too many assumptions for my primitive brain. Also, since I'm troubleshooting the boards, I need to know what *should* happen vs. what *is* happening.

 

This is what I'm doing so far, please let me know if I'm missing some step and if I'm using the card correctly.

 

Setup: Card in PEB, CRU base >1700 set on DIP switch, XB cart in console.

 

1. Power on. Press 2 2 to get to XB. Auto load takes over and loads the UTIL1 program.

2. Initialize PGRAM DSR (works fine)

3. Load DSR from DSK1.PGDSR (and PGDSS automatically)

4. Pull XB cart, insert E/A cart.

5. Select 5 to reset.

6. Press 1 1 to get to BASIC.

7. CALL PG - loads PGRAM menu

8. Press 1 to initialize GRAM/RAM (works fine)

9. Press 3 to save E/A GROM (at least I assume this is what I'm doing??) Saves fine.

10. Pull E/A module.

11. Press 2 to Load PGRAM and specify E/A file just written. Loads fine.

12. Press 6 to quit.

 

At this point I guess I should expect to have the E/A available to me via the PGRAM card? Am I thinking about this correctly? However, when I power on the machine, the master title screen does not appear and the screen just sits on a blank cyan display. If I disable the PGRAM card with the switch, or have a cart installed, the system works as usual.

 

My question is, did I set up the card correctly? If the blank screen is part of the problem, then fine, I can work on that. But I don't even know if I set the thing up right to begin with...

 

Exaclty what happens to me. Just locks up and nothing happens. I guess the problem is the power up cycle and that is where I was stuck at. It does not appear to be a software problem as I used several versions of the PGRAM DSR.

Some chip or circut is causing the problem. I suspect it is a CRU problem or a DSR chip problem.

[John Doe]

Edited February 22, 2014 by Tony Knerr

[RXB]

The main thing I see is if it is a Pgram+ that you are using, you should initialize all 4 pages during step 8. You may have some stray corrupted GPL power up code in one of the banks taking control and going nowhere.

 

You also didn't need to switch cartridges, the E/A cart will work for all the steps, and is probably a better choice to keep things consistent.

 

Is the Pgram Menu screen light or dark blue? The light blue one is the old one, and the dark blue one is the one I cleaned up some bugs (seems like another lifetime ago), and corrected the clock routines for y2k. The newest version is on whtech.

 

Tony

 

 

Ok, I guess I still need some steps since the manual makes too many assumptions for my primitive brain. Also, since I'm troubleshooting the boards, I need to know what *should* happen vs. what *is* happening.

 

This is what I'm doing so far, please let me know if I'm missing some step and if I'm using the card correctly.

 

Setup: Card in PEB, CRU base >1700 set on DIP switch, XB cart in console.

 

1. Power on. Press 2 2 to get to XB. Auto load takes over and loads the UTIL1 program.

2. Initialize PGRAM DSR (works fine)

3. Load DSR from DSK1.PGDSR (and PGDSS automatically)

4. Pull XB cart, insert E/A cart.

5. Select 5 to reset.

6. Press 1 1 to get to BASIC.

7. CALL PG - loads PGRAM menu

8. Press 1 to initialize GRAM/RAM (works fine)

9. Press 3 to save E/A GROM (at least I assume this is what I'm doing??) Saves fine.

10. Pull E/A module.

11. Press 2 to Load PGRAM and specify E/A file just written. Loads fine.

12. Press 6 to quit.

 

At this point I guess I should expect to have the E/A available to me via the PGRAM card? Am I thinking about this correctly? However, when I power on the machine, the master title screen does not appear and the screen just sits on a blank cyan display. If I disable the PGRAM card with the switch, or have a cart installed, the system works as usual.

 

My question is, did I set up the card correctly? If the blank screen is part of the problem, then fine, I can work on that. But I don't even know if I set the thing up right to begin with...

 

 

Before I sent the card that is exactly what I did. Cleared the pages over and over tried taking out battery and letting if go dry on power for any stray static in anything. I see it is GRAM 1 that is the problem it was the only one since the day I got the card that it would not load that bank. I used the version of DSR that Tony sent me and nothing I did worked. It just has a Cyan screen and locks up computer when you try to access by power up. So the power up cycle is what is wrong.

 

It acts the same way as if you had something else with the same CRU address. Could there be a short in the board under a chip socket that is changing the CRU?

[matthew180]

I didn't clear all the pages individually, no. But, the battery has been out of the board for at least a day, and I pulled every chip to test them in my chip tester (every chip, individually, tested fine.) Since the PGRAM is just logic chips and SRAM, I don't think there could be anything residual data left in there. I'll clear each page individually though. I guess I thought the initialize option would clear everything. Also, I'm not real clear on the "pages" thing. This is one of the aspects of the GRAM that the manual assumes you "naturally" understand what they are and how they should work. Also, is there any way to see what is currently loaded in a page before you load something over it?

 

I think the PGRAM menu is dark blue, but I did not pay that close attention. I got my disks from RXB, so I'm going to assume they are the latest. I also ran the PGTEST1 and PGTEST2, which did not seem to really "test" anything - nothing that I could tell though. It seems test1 fills the cards with random data, and test2 just dumps the data to the screen... I'm not sure what that is supposed to accomplish? I don't see any "validation" of the data going on.

 

Also, no one said if I was using the card correctly? Or what I *should* see if everything is working correctly.

[marc.hull]

I didn't clear all the pages individually, no. But, the battery has been out of the board for at least a day, and I pulled every chip to test them in my chip tester (every chip, individually, tested fine.) Since the PGRAM is just logic chips and SRAM, I don't think there could be anything residual data left in there. I'll clear each page individually though. I guess I thought the initialize option would clear everything. Also, I'm not real clear on the "pages" thing. This is one of the aspects of the GRAM that the manual assumes you "naturally" understand what they are and how they should work. Also, is there any way to see what is currently loaded in a page before you load something over it?

 

I think the PGRAM menu is dark blue, but I did not pay that close attention. I got my disks from RXB, so I'm going to assume they are the latest. I also ran the PGTEST1 and PGTEST2, which did not seem to really "test" anything - nothing that I could tell though. It seems test1 fills the cards with random data, and test2 just dumps the data to the screen... I'm not sure what that is supposed to accomplish? I don't see any "validation" of the data going on.

 

Also, no one said if I was using the card correctly? Or what I *should* see if everything is working correctly.

 

 

I don't now much about the Pgram card but I do know a little about Horizon design have had a year long wrestling match with a 3000b ram disk. And the description of the symptoms mimic my experiences.

 

With the battery in check the voltages at the ram chips supply and the *CE line. If it has the same write protect circuit that some of the RAM disks have then your problem could be low voltage on either of these pins. Is the voltage below spec or borderline ?

 

If it does have the horizon write protect circuit and low voltage then you will get bizarre behavior from the card even without powering down as the *CE line may be getting pulled low by the circuit itself and corrupting the RAM.

 

Of course all this conjecture depends on Horizon reusing the write protect circuit .

[John Doe]

Edited February 22, 2014 by Tony Knerr

[John Doe]

Edited February 22, 2014 by Tony Knerr

[RXB]

I don't now much about the Pgram card but I do know a little about Horizon design have had a year long wrestling match with a 3000b ram disk. And the description of the symptoms mimic my experiences.

 

With the battery in check the voltages at the ram chips supply and the *CE line. If it has the same write protect circuit that some of the RAM disks have then your problem could be low voltage on either of these pins. Is the voltage below spec or borderline ?

 

If it does have the horizon write protect circuit and low voltage then you will get bizarre behavior from the card even without powering down as the *CE line may be getting pulled low by the circuit itself and corrupting the RAM.

 

Of course all this conjecture depends on Horizon reusing the write protect circuit .

 

Interesting, might be a good idea to try the card without the battery.

 

Tony

 

Tony you may have a idea there. I used the older of the 2 PGRAM cards with out a battery for a few days as I was to lazy to go to store and get one. Just had to load the DSR and GRAM everyday. Either way I still think the problem is with some kind of pull up resister or something in the power up cycle because that is where it hangs at. Both of the cards are hugely modified from the diagrams I have of the PGRAM and PGRAM+

Edited April 19, 2011 by RXB

[John Doe]

Edited February 22, 2014 by Tony Knerr

[RXB]

Tony you may have a idea there. I used the older of the 2 PGRAM cards with out a battery for a few days as I was to lazy to go to store and get one. Just had to load the DSR and GRAM everyday. Either way I still think the problem is with some kind of pull up resister or something in the power up cycle because that is where it hangs at. Both of the cards are hugely modified from the diagrams I have of the PGRAM and PGRAM+

 

There were never any hardware modifications done to either of the Pgram+ cards I owned. They came directly from Bud to me. Other than cleaning of card contacts, or exercising dip switches from time to time, they were always rock-solid. One of the cards (not sure which one) had it's voltage regulator replaced some years ago, but it was at a TI club meeting and not done by me. I have only heard good things from the gentleman that purchased the other card. I find it odd that you experienced any sort of problem with the card as I had left it powered-up in a system for about a month and put it through it's paces daily. I would not have sold any TI device that I was not sure was operating 100% correctly and took many precautions to insure that it was. This card had a new battery, but I can't guarantee how long the battery sat on the shelf in the store.

 

Tony

 

The card you sent me was not the PGRAM+ card, I got that as a replacement sent to me as a mine with custom switches (put on it by Bud Mills and Don O'neil) was to hard to fix for the vendor. Later saw my card being sold on EBAY by someone else.

The transport of the card by mail may have been the problem I do not know. When I got the one you sent and put it in my PBox it worked fine the first few days then GRAM banks 1 and 4 just stopped working, so I used GRAM banks 2 and 3. But then a week or so later even they started to get flaky so then the PGRAM just started to lock up on power up. Why I sent them out to be repaired. I have two standard PBoxes and both do the same thing, one PBox is totally stock and the other has a couple of heat sinks on back that were put there by a vendor for me at a fair. The older PBox I bought a brand new transformer from TI and installed. (Did not know I could replace the fuse)

So I am at a loss to explain the problem.

[marc.hull]

Tony you may have a idea there. I used the older of the 2 PGRAM cards with out a battery for a few days as I was to lazy to go to store and get one. Just had to load the DSR and GRAM everyday. Either way I still think the problem is with some kind of pull up resister or something in the power up cycle because that is where it hangs at. Both of the cards are hugely modified from the diagrams I have of the PGRAM and PGRAM+

 

There were never any hardware modifications done to either of the Pgram+ cards I owned. They came directly from Bud to me. Other than cleaning of card contacts, or exercising dip switches from time to time, they were always rock-solid. One of the cards (not sure which one) had it's voltage regulator replaced some years ago, but it was at a TI club meeting and not done by me. I have only heard good things from the gentleman that purchased the other card. I find it odd that you experienced any sort of problem with the card as I had left it powered-up in a system for about a month and put it through it's paces daily. I would not have sold any TI device that I was not sure was operating 100% correctly and took many precautions to insure that it was. This card had a new battery, but I can't guarantee how long the battery sat on the shelf in the store.

 

Tony

 

The card you sent me was not the PGRAM+ card, I got that as a replacement sent to me as a mine with custom switches (put on it by Bud Mills and Don O'neil) was to hard to fix for the vendor. Later saw my card being sold on EBAY by someone else.

The transport of the card by mail may have been the problem I do not know. When I got the one you sent and put it in my PBox it worked fine the first few days then GRAM banks 1 and 4 just stopped working, so I used GRAM banks 2 and 3. But then a week or so later even they started to get flaky so then the PGRAM just started to lock up on power up. Why I sent them out to be repaired. I have two standard PBoxes and both do the same thing, one PBox is totally stock and the other has a couple of heat sinks on back that were put there by a vendor for me at a fair. The older PBox I bought a brand new transformer from TI and installed. (Did not know I could replace the fuse)

So I am at a loss to explain the problem.

 

 

How about some hi res pictures of the components side?

[RXB]

I do not have any PGRAM cards I mailed them all out to be repaired. Being a GPL programmer this sucks so much you can not believe it.

[marc.hull]

I do not have any PGRAM cards I mailed them all out to be repaired. Being a GPL programmer this sucks so much you can not believe it.

 

OK.... How about some Hi Res pictures Mathew .

 

There are GPL emulators/loaders (at least that is what I think they are) that run in CPU. Can't you just use those in conjunction with your SAMS card to load your GPL stuff ?

[John Doe]

Edited February 22, 2014 by Tony Knerr

[RXB]

The card you sent me was not the PGRAM+ card,

<snip>

 

I never owned a straight (one page) Pgram card. Both of them were Pgram+ (4 bank) versions. There was no choice involved.

The card I mailed to you was a Pgram+.

 

Tony

 

 

OMG you are right, the PGRAM+ has the clock and I never wanted the clock. Sorry I got them backwards. I always just opted for the most number of banks of GRAM.

[RXB]

I do not have any PGRAM cards I mailed them all out to be repaired. Being a GPL programmer this sucks so much you can not believe it.

 

OK.... How about some Hi Res pictures Mathew .

 

There are GPL emulators/loaders (at least that is what I think they are) that run in CPU. Can't you just use those in conjunction with your SAMS card to load your GPL stuff ?

 

GPL will run on the TI from Linkers like the one in my GPLHOW2 video, but all linkers use VDP to fake GROM. That is the problem as VDP is only 16K and GROM banks are 40K.

 

Also why it impossible to run RXB or XB or SuperSpace or XB2.5 or SXB or MyarcXB or many others from a Linker.

 

Really anything you could depend on to work will not run from a Linker. Only games or small utilities will run from such a small space of memory. The SAMS card is not VDP so does not matter.

[John Doe]

Edited February 22, 2014 by Tony Knerr

[matthew180]

These are photos of the cards as I received them from RXB

[matthew180]

You can page through the banks using Review Module Library to see what is on each page, just count as you're going.

 

Yeah, that is probably the easiest way to see what is in each page, however, since neither card is working I have never seen the Module Review menu.

 

Thanks everyone for the info and suggestions, I'll try some of them later today. At this point though, my gut feeling is leaning more towards a cold solder joint and I'll probably remove the chips and reflow the sockets.

[marc.hull]

These are photos of the cards as I received them from RXB

 

As a starter I would suggest replacing those 3V batteries with 3.6V ones. May do nothing, may fix the issue.

[marc.hull]

I do not have any PGRAM cards I mailed them all out to be repaired. Being a GPL programmer this sucks so much you can not believe it.

 

OK.... How about some Hi Res pictures Mathew .

 

There are GPL emulators/loaders (at least that is what I think they are) that run in CPU. Can't you just use those in conjunction with your SAMS card to load your GPL stuff ?

 

GPL will run on the TI from Linkers like the one in my GPLHOW2 video, but all linkers use VDP to fake GROM. That is the problem as VDP is only 16K and GROM banks are 40K.

 

Also why it impossible to run RXB or XB or SuperSpace or XB2.5 or SXB or MyarcXB or many others from a Linker.

 

Really anything you could depend on to work will not run from a Linker. Only games or small utilities will run from such a small space of memory. The SAMS card is not VDP so does not matter.

 

Makes sense. AFAIK the GPL interpreter is completely located in ROM correct ? Seems to me that a person could rip and modify the code to run out of RAM, add in SAMS support and then do everything from CPU memory. That would negate the need for GRAM devices. Is that sound plausible or am I missing a piece of the puzzle ?

[marc.hull]

These are photos of the cards as I received them from RXB

 

As a starter I would suggest replacing those 3V batteries with 3.6V ones. May do nothing, may fix the issue.

 

Looking at the PGRAM schematic it appears to have a similar write protect mechanism as the RAM disks do. In effect when power goes off, the battery back-up powers the three SRAMS and also supplies power to the DSR SRAM's *CE in order to prevent power cycling/resetting from corrupting the DSR. If this line is not held high (enough) then the undermined bus at power up/down can write garbage to the IC.

 

You might also want to check CR2 and CR3. If they are bad or failing then they could be causing the parasitic loss which would be dragging *CE low (and lord knows what else.)

[Tursi]

Makes sense. AFAIK the GPL interpreter is completely located in ROM correct ? Seems to me that a person could rip and modify the code to run out of RAM, add in SAMS support and then do everything from CPU memory. That would negate the need for GRAM devices. Is that sound plausible or am I missing a piece of the puzzle ?

 

If I understand correctly, that's what some of those older ripped modules do, so I guess there's already a relocated interpreter floating around.

[RXB]

Makes sense. AFAIK the GPL interpreter is completely located in ROM correct ? Seems to me that a person could rip and modify the code to run out of RAM, add in SAMS support and then do everything from CPU memory. That would negate the need for GRAM devices. Is that sound plausible or am I missing a piece of the puzzle ?

 

If I understand correctly, that's what some of those older ripped modules do, so I guess there's already a relocated interpreter floating around.

 

But still the GRAM has access to 640K of memory that you just threw away. 40K * 16 banks is 640K. What is the difference between the AMS and GRAM.

 

Bank switch AMS and it is only 4K per bank but you can do up to 32K at a time but still have to have 4K there to control it.

Bank switch GRAM and you get 40K per bank, that is a huge difference in size. Speed wise RAM is faster but why so in the emulator?

 

Those GRAM address lines need something and somewhere to go or just get wasted. Assembly is great but no one is ever going to write XB totally in assembly.

[marc.hull]

Makes sense. AFAIK the GPL interpreter is completely located in ROM correct ? Seems to me that a person could rip and modify the code to run out of RAM, add in SAMS support and then do everything from CPU memory. That would negate the need for GRAM devices. Is that sound plausible or am I missing a piece of the puzzle ?

 

If I understand correctly, that's what some of those older ripped modules do, so I guess there's already a relocated interpreter floating around.

 

But still the GRAM has access to 640K of memory that you just threw away. 40K * 16 banks is 640K. What is the difference between the AMS and GRAM.

 

Bank switch AMS and it is only 4K per bank but you can do up to 32K at a time but still have to have 4K there to control it.

Bank switch GRAM and you get 40K per bank, that is a huge difference in size. Speed wise RAM is faster but why so in the emulator?

 

Those GRAM address lines need something and somewhere to go or just get wasted. Assembly is great but no one is ever going to write XB totally in assembly.

 

I think the point is that it makes no difference how the data is stored, be it GRAM or CPU RAM. If the interpreter can be ported to run in RAM (and apparently it has) then combined with a SAMS card you could easily get your 640K of code/data. Correct me if I am wrong but isn't that about 8 times more capacity than the largest GRAM device ever made and sold to the public ?

 

Seems to me that this would be a dream come true for a GPL guru. The hardware component is all ready in place in a lot of systems or readily available. Unless the source is available The interpreter may be a bit tricky but I wouldn't put that past the people on this group.

 

As far as the XB goes, perhaps you are right but I don't see the relevance to having the GPL interpreter running out of RAM and utilizing the SAMS card as GRAM.