Grom Wrap Test Program and results

[Gazoo]

Attached to this message is a test program for users of Gram devices, whether real hardware or emulation.

 

It is a .dsk file with Grom code that loads into the device to be tested. There are several formats on the disk to make for easy loading, Gram Kracker format loads with the file 'GKGROMTST' and HSGPL format loads with the file 'SNGROMTST'. The code loads into Groms 3, 4, & 5. After loading the Grom files and returning to the title screen, you will be presented with a menu entry that reads ' GROM WRAP TEST'. Press the key corresponding to that menu entry. You will get a message that either reads 'Wraps around same GROM' or 'Continues into next GROM'. Press any key to quit.

 

This test program determines whether the Gram device you are using continues execution of code at the end of the Grom into the next Grom or wraps around and continues execution at the beginning of the same Grom. The program is constructed by actually executing code across Grom boundaries. The header code is at the beginning of Grom 3 and sets up the VDP registers and character set so we can produce a message on the screen. The code then branches to address g>9FFE (the end of Grom 4) and executes the code >0720 which is 'fill screen with spaces'. If the Grom code execution continues at address g>A000 (the beginning of Grom 5), the code there displays the message 'Continues into next GROM'. If the Grom execution wraps back to adress g>8000 (the beginning of Grom 4), the code there displays the message 'Wraps around same GROM'.

 

Please post your results when you try this, and be as specific as possible about the device. For example, there are several different consoles emulated in MESS, and each can use the cartridge natively or with the Gram Kracker emulation or with the HSGPL emulation. The Geneve can also use the Gram Kraker format files, although I already know the results there as that's where I wrote the program. Let us know whether it is the real hardware or in an emulation program. What would be really cool and perhaps give the most insight to TI's original intent would be if someone could burn the files into eproms for TI's Cartridge Simulator, I know there are a few of them floating around out there in the wild.

 

GromWrapTest.zip

 

Gazoo

Edited January 26, 2014 by Gazoo

[Gazoo]

I'll go first.

 

The Emulated Geneve in Mess gives the result 'Continues into next GROM'.

 

Gazoo

 

[+arcadeshopper]

Real TI, Gram Kracker gives the result: "Continues into next GROM"

[RXB]

Well as a GPL programmer I can not see why a wrap back to the same page even exists?

 

Like I said in another post, imagine in VDP if you had to write a special section of code to cross the page boundary from >1FFF to >2000 or say move data you would need another special program code?

 

Now again explain to me how this wrap is a great idea for programming?

 

I see this as anti programming on purpose. Also anti memory expansion purpose. If VDP worked the same way it would be a disaster.

[Gazoo]

Well as a GPL programmer I can not see why a wrap back to the same page even exists?

 

Like I said in another post, imagine in VDP if you had to write a special section of code to cross the page boundary from >1FFF to >2000 or say move data you would need another special program code?

 

Now again explain to me how this wrap is a great idea for programming?

 

I see this as anti programming on purpose. Also anti memory expansion purpose. If VDP worked the same way it would be a disaster.

 

Hi Rich. Thanks for your input. But this thread is just about the test program that I offered in the first post and the results one might get from it. Maybe if there are enough results we can make a determination as to the behavior of Groms. Until then, it doesn't help to complain about a theory that doesn't make sense to you. Do you have any results to share with us regarding any devices, emulated or real, and the test program I uploaded?

 

Gazoo

[Gazoo]

Classic 99 QI372:

 

 

Win994a Simulator v3.009:

 

 

 

Gazoo

 

[+Ksarul]

I actually see a potential use for the wrap function within an individual GROM, Rich. You could set up a repeating sound list or screen background stored in DATA statements within a single GROM. It would automatically cycle back to the beginning each time it reached the end--but the GPL Interpreter would have to be massaged to also go back to the starting address for it to be of any use.

 

 

Obviously, there are other ways to do it--but it does provide a possibly useful alternative to loading the entire list into memory.

[Omega-TI]

I actually see a potential use for the wrap function within an individual GROM, Rich. You could set up a repeating sound list or screen background stored in DATA statements within a single GROM. It would automatically cycle back to the beginning each time it reached the end--but the GPL Interpreter would have to be massaged to also go back to the starting address for it to be of any use.

 

 

Oh yeah! I can envision a cartridge game with an amazing soundtrack....

[RXB]

I actually see a potential use for the wrap function within an individual GROM, Rich. You could set up a repeating sound list or screen background stored in DATA statements within a single GROM. It would automatically cycle back to the beginning each time it reached the end--but the GPL Interpreter would have to be massaged to also go back to the starting address for it to be of any use.

 

 

Obviously, there are other ways to do it--but it does provide a possibly useful alternative to loading the entire list into memory.

GPL already has a auto loop for music or sound built in and here is the GPL HOW 2 I made showing how to use it.

 

 

This list will repeat until you:

A.) Interrupt the sound list with a separated sound list or single sound.

B.) Exit the program.

 

GPL has 40K of memory that is rarely ever even close to being all used up. 8K of music would still leave 32K of GPL space left.

Besides music can be played from GROM/GRAM or VDP as the list id using the GPL I/O command.

Edited January 27, 2014 by RXB

[eck]

Moin, Gazoo!

 

I tested your program with a grom-port gram solution made by two local heroes from my home-town and it continues into the next gram. But the test failed when I tried it with my HSGPL-card. The console locks up. I downloaded the 1.48 KB file for more than 3 KB. Maybe my system "caught a cold"? I was forced to rename the file GRGROMTST to GRGROMTST0 for the second test. The files SNGROMTST et all are bringing down both gram devices I have. It is possible to corrupt files on a device while reading them? The grom-port solution claims to load all types of gram files that were known back in the old days. So my first attempt was to load the SNUG files into the grom-port device. Returning to the selection screen freezes the system with permanent noise.

[Gazoo]

Moin, Gazoo!

 

I tested your program with a grom-port gram solution made by two local heroes from my home-town and it continues into the next gram. But the test failed when I tried it with my HSGPL-card. The console locks up. I downloaded the 1.48 KB file for more than 3 KB. Maybe my system "caught a cold"? I was forced to rename the file GRGROMTST to GRGROMTST0 for the second test. The files SNGROMTST et all are bringing down both gram devices I have. It is possible to corrupt files on a device while reading them? The grom-port solution claims to load all types of gram files that were known back in the old days. So my first attempt was to load the SNUG files into the grom-port device. Returning to the selection screen freezes the system with permanent noise.

 

Do you have the GRACK_E program to convert Gram Kracker files to HSGPL files? An odd situation occurred when I was testing my real HSGPL also. The HSGPL files worked correctly under MESS, but I had to convert the Gram Kracker files to HSGPL files using the conversion program to use with the real HSGPL card. I think you'll find they run correctly if you use this procedure and you'll get a 'Continues into next GROM' message as I did.

 

Gazoo

[eck]

"I think you'll find they run correctly if you use this procedure and you'll get a 'Continues into next GROM' message as I did.", I suppose too, but I do not have the GRACK_E program. So the test with real HSGPL-card is made and that is fine.

[Gazoo]

"I think you'll find they run correctly if you use this procedure and you'll get a 'Continues into next GROM' message as I did.", I suppose too, but I do not have the GRACK_E program. So the test with real HSGPL-card is made and that is fine.

 

Here's the GKRACK_E program to convert Gram Kracker files to HSGPL files. No HSGPL owner should be without it.

 

GKRACK_E.zip

 

 

Gazoo

[eck]

He, he, gracias, Gazoo!

 

Michael Becker sent me with the HSPGPL-card some disks with gram-files on. Though, not all are working, but this does not bother me. The grom-port device is more flexible, has a reset-button and is able to load E/A 3 files, while the HSPGPL refused to do this. So, I am using this module, but I gone grab your offer. Thanks, says eck.