GRAM DEVICE

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

 

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.

 

You might have noticed that I push stuff out pretty fast with GPL compared to Assembly. GPL has disadvantages but development time is less then 1/3rd of Assembly. I still have to compile and test it.

But the writing of code is so much faster to get done. It is not as good a Assembly, but combined with Assembly it beats everything else hands down.

 

I think the SAMS card should be used for RAM as no one yet has come near to using all of it that I have seen, nor anyone used all the GRAM yet either.

Biggest use of SAMS I ever did was only 128K, biggest GPL was GRAM 0 to 7 which is 64K. If you count PDISK (Phoney disk drive in GRAM bank 2) then 124K.

 

You can not count GRAMPACKER as that just puts stuff into GRAM like a disk drive. My PDISK was read/write. With GRAMPACKER I used 240K. So I have far to go.

[marc.hull]

 

You might have noticed that I push stuff out pretty fast with GPL compared to Assembly. GPL has disadvantages but development time is less then 1/3rd of Assembly. I still have to compile and test it.

But the writing of code is so much faster to get done. It is not as good a Assembly, but combined with Assembly it beats everything else hands down.

 

I think the SAMS card should be used for RAM as no one yet has come near to using all of it that I have seen, nor anyone used all the GRAM yet either.

Biggest use of SAMS I ever did was only 128K, biggest GPL was GRAM 0 to 7 which is 64K. If you count PDISK (Phoney disk drive in GRAM bank 2) then 124K.

 

You can not count GRAMPACKER as that just puts stuff into GRAM like a disk drive. My PDISK was read/write. With GRAMPACKER I used 240K. So I have far to go.

 

Although I am an assembly or bust kinda guy I am not knocking GPL and it does appear to be much easier than doing everything one step at a time as in assembly.

 

I agree that the SAMS card is Waaaaaaaayyyyy over sized for the TI and most likely will not ever get fully utilized. But since this memory is available and there is really no need to watch your bytes, it just seems to make sense to utilize it for GPL storage (although I admit I don't know the logistics.) How about a partitioned SAMS arrangement that would accommodate both GPL and assembly .

 

It seems to me that the biggest drawback to GPL is the fact that it requires special hardware for the most part (read as GROMS or GROM emulation.) If you removed that obstacle then perhaps it would become a bit more utilized by the masses.

 

I am not sure how GROM is addressed. Is it banked in or can the GPL interpreter see all that memory at once ?

[John Doe]

Edited February 22, 2014 by Tony Knerr

[RXB]

The HSGPL card makes the SAMS look dinky as it is 2.5 times larger.

Edited April 23, 2011 by RXB

[RXB]

You might have noticed that I push stuff out pretty fast with GPL compared to Assembly. GPL has disadvantages but development time is less then 1/3rd of Assembly. I still have to compile and test it.

But the writing of code is so much faster to get done. It is not as good a Assembly, but combined with Assembly it beats everything else hands down.

 

I think the SAMS card should be used for RAM as no one yet has come near to using all of it that I have seen, nor anyone used all the GRAM yet either.

Biggest use of SAMS I ever did was only 128K, biggest GPL was GRAM 0 to 7 which is 64K. If you count PDISK (Phoney disk drive in GRAM bank 2) then 124K.

 

You can not count GRAMPACKER as that just puts stuff into GRAM like a disk drive. My PDISK was read/write. With GRAMPACKER I used 240K. So I have far to go.

 

Although I am an assembly or bust kinda guy I am not knocking GPL and it does appear to be much easier than doing everything one step at a time as in assembly.

 

I agree that the SAMS card is Waaaaaaaayyyyy over sized for the TI and most likely will not ever get fully utilized. But since this memory is available and there is really no need to watch your bytes, it just seems to make sense to utilize it for GPL storage (although I admit I don't know the logistics.) How about a partitioned SAMS arrangement that would accommodate both GPL and assembly .

 

It seems to me that the biggest drawback to GPL is the fact that it requires special hardware for the most part (read as GROMS or GROM emulation.) If you removed that obstacle then perhaps it would become a bit more utilized by the masses.

 

I am not sure how GROM is addressed. Is it banked in or can the GPL interpreter see all that memory at once ?

 

GRAM/GROM is built into the address lines of the TI just like VDP is, but there are more lines for GRAM/GROM. To switch banks you just change address lines for another 40K bank of GRAM/GROM. >9800 is first one.

>9800 first bank read GRAM/GROM 40K

>9802 second bank read GRAM/GROM 40K

>9804 third bank read GRAM/GROM 40K

and so on...

>9C00 first bank write GRAM/GROM 40K

>9C02 second bank write GRAM/GROM 40K

>9C04 third bank write GRAM/GROM 40K

and so on...

 

So nothing needs to be installed except the cartridge with memory. The SAMS needs a DSR but GRAM/GRAM does not. 16 banks of 40K is 640K.

I would like to see things like LISP or UNIX or Linux imbedded into GRAM/GROM and the GPL and SAMS to run it .

XB runs similar to this, 32K GPL and 12K ROM to assist it, just scale it up for closer to PC uses. Even a mouse is possible on the TI OS using 9958 VDP chip.

[Tursi]

Forgive me for jumping in, RXB, I think you may not have quite answered Marc's question, so just to add the part that I thought might be missing, GROMs are accessed like the VDP - you write an address to one port, and then reads/writes are handled at another port, with the memory autoincrementing. There's 64k of GROM space available at each base address, but the console GROMs do not honor the multiple bases so they are always visible, which costs you the first 24k of that space.

 

The 16 GROM bases is all that is scanned by the console - Thierry's page points out that nothing in the memory map stops you from using more bases than that, as long as your code handles it. In theory there's enough room for 256 bases, at 40k each.

[John Doe]

Edited February 22, 2014 by Tony Knerr

[matthew180]

Thanks again to everyone for the suggestions and help. I fixed both cards last night. Removing all ICs, reflowing all the socket pins, and reinstalling the ICs did the trick. So chalk it up to age, crappy sockets!, some bad solder joints, old flux from previous repairs that was not cleaned off the board, etc.

 

I tested both boards by saving my XB and EA carts to disk, then loading XB in bank 1, and the EA in bank 2. When I powered on the machine (without any carts installed), I could select XB or the EA using the normal 99/4A cart menus. I ran some programs in XB, and loaded the editor with the EA. Are there any other tests I should perform before sending these back to RXB?

[+InsaneMultitasker]

Thanks again to everyone for the suggestions and help. I fixed both cards last night. Removing all ICs, reflowing all the socket pins, and reinstalling the ICs did the trick. So chalk it up to age, crappy sockets!, some bad solder joints, old flux from previous repairs that was not cleaned off the board, etc.

 

I tested both boards by saving my XB and EA carts to disk, then loading XB in bank 1, and the EA in bank 2. When I powered on the machine (without any carts installed), I could select XB or the EA using the normal 99/4A cart menus. I ran some programs in XB, and loaded the editor with the EA. Are there any other tests I should perform before sending these back to RXB?

 

Good news One thing I've noticed while repairing cards is that some of the single wipe an even a few double-wipe sockets may be corroded "inside". If you have a loupe or similar, and have not done so, inspect the wipes (where they meet the IC pin) for trouble under a good light. Otherwise, looks like a few more cards are back in business

[matthew180]

Well, the sockets are about as cheap as they get and I cleaned them as best I could. I have actually never even seen "single-wipe" sockets until now! I was very surprised. Like how much money could you possibly be saving with sockets like that?? I buy cheap sockets some times, and even those have always been double-wipe.

 

The boards are also pretty fragile (not as durable as the stuff TI made) and it seems many people are not very gentle with repairs or handling them. There were a few giant solder blobs, and when I went to clean them up I found that the pads where missing! Nice. You have to be really rough on a board to pull a pad! I have a pad repair kit and fixed them the best I could. There were also vias that had wires soldered in to them then cut off, lots of left over flux, and a lot of other questionable "work". These boards also *really* need a shell!

 

Anyway, they are back in business.

[+InsaneMultitasker]

Well, the sockets are about as cheap as they get and I cleaned them as best I could. I have actually never even seen "single-wipe" sockets until now! I was very surprised. Like how much money could you possibly be saving with sockets like that?? I buy cheap sockets some times, and even those have always been double-wipe.

 

The boards are also pretty fragile (not as durable as the stuff TI made) and it seems many people are not very gentle with repairs or handling them. There were a few giant solder blobs, and when I went to clean them up I found that the pads where missing! Nice. You have to be really rough on a board to pull a pad! I have a pad repair kit and fixed them the best I could. There were also vias that had wires soldered in to them then cut off, lots of left over flux, and a lot of other questionable "work". These boards also *really* need a shell!

 

Anyway, they are back in business.

Pad repair kit? Hmmm, I'll have to look into that.

 

There are certainly some cards prone to pad removal. I've encountered many MYARC cards, primarily HFDCs and Geneves, with pad and core hole problem: look at the pad wrong and it literally jumps off the board Corcomp and Horizon cards seem a little better and you'd probably need a crowbar to pull traces and pads off of TI's boards. There are some cards I will not upgrade because they are so brittle and sensitive...

[matthew180]

Pad repair kit? Hmmm, I'll have to look into that.

 

I bought it to fix coin-ops with damaged boards. The one I have is thin copper with a heat sensitive adhesive on the back. There are some pre-punched pad "doughnuts" and the rest is just a sheet that you cut traces out of as necessary. It is not perfect, since you still have the problem of binding the new pad to an existing trace, and solder does not like to flow over a gap like that. But, when faced with nothing vs. something, it is better than nothing.

 

I bought it a long time ago, but I'm sure some form of repair kit is still available.

[RXB]

Pad repair kit? Hmmm, I'll have to look into that.

 

I bought it to fix coin-ops with damaged boards. The one I have is thin copper with a heat sensitive adhesive on the back. There are some pre-punched pad "doughnuts" and the rest is just a sheet that you cut traces out of as necessary. It is not perfect, since you still have the problem of binding the new pad to an existing trace, and solder does not like to flow over a gap like that. But, when faced with nothing vs. something, it is better than nothing.

 

I bought it a long time ago, but I'm sure some form of repair kit is still available.

 

 

Sent you my Address by private message. Thanks again.

I have had Prototype boards to write for or to test and some of them were almost all wire on a board with wires running in and out of holes

to get from one side of board to other for all the chips that were glued to the board. Gladly I do not have any of them left, I can not imagine

how anyone would fix those Prototypes.

[sjt]

Hi

I recently got one of these cards. I need some clarification.

It is a Pgram + , I ran the tests and it passed. I saved xb and loaded it and it worked...so far so good.

However, it appears that only the page1 has rom space available. If I initialize the pages , only page 1 shows rom 1 and 2 checked.

However it completes tests on the other pages fine with no error (just doesn't put a star on the roms) . If I load a grom only cartridge into the banks past 1 they work.

But it the cartridge has Roms it issues an error asking if I want to overwrite that space.

 

Is this normal?

[RXB]

Sent you private message on this issue. Power supply for PGRAM is critical. Also the connection to the Console.

[Gazoo]

Hi

I recently got one of these cards. I need some clarification.

It is a Pgram + , I ran the tests and it passed. I saved xb and loaded it and it worked...so far so good.

However, it appears that only the page1 has rom space available. If I initialize the pages , only page 1 shows rom 1 and 2 checked.

However it completes tests on the other pages fine with no error (just doesn't put a star on the roms) . If I load a grom only cartridge into the banks past 1 they work.

But it the cartridge has Roms it issues an error asking if I want to overwrite that space.

 

Is this normal?

 

Yes, this is normal. There are only 2 banks of Rom at >6000. All the Grom Banks share them. You normally only load them from page 1. So If you're loading Extended Basic into the card, you could load 4 different versions as long as they all have the same Rom and they'll all work fine. I know, I've done it.

 

In regards to RXB's message, I haven't found any special requirements as to the power supply, and I have some knowledge of this. But he is on the right track as to the connection to the console, the logic chips in the flex cable card and the foot are critical, they must be up to spec. As you have the necessary skills, it wouldn't be a bad idea to replace them.

 

Gazoo

 

edit: Check out the attached disks, too. You may find some useful stuff.

 

PgramUtilities23.dsk

PGRAMY2K.dsk

Edited September 24, 2014 by Gazoo

[sjt]

If the y2k disk you posted works for you...I've give it a spin. Maybe the dsr is NG that i'm using.

 

If I load XB for example in page1 - which will take gram3,4,5,6 and both ram spaces.

Then if I load in page 2 EA which as you know is grom3 when I re-boot all that is there is EA XB is now gone.

If I load groms that do not over lapmultiple selections are available. such as a rom based cartridge and groms that do not overlap.

 

Later I'll try the software you sent.

 

Steve

[Gazoo]

If the y2k disk you posted works for you...I've give it a spin. Maybe the dsr is NG that i'm using.

 

If I load XB for example in page1 - which will take gram3,4,5,6 and both ram spaces.

Then if I load in page 2 EA which as you know is grom3 when I re-boot all that is there is EA XB is now gone.

If I load groms that do not over lapmultiple selections are available. such as a rom based cartridge and groms that do not overlap.

 

Later I'll try the software you sent.

 

Steve

 

Well, the y2k version worked for me when I had a Pgram card. And I happen to think it worked pretty well as I'm the one that updated the DSR for that version.

 

Gazoo