Reading Data from Cartridge

[Cheung]

Hey all. I've been working on a few XB compiled games and I was taking a look at some of the cartridge files I have downloaded to see how large some of the more elaborate games like Flying Shark were and I noticed that a few were quite a bit bigger than the 32K my games are turning out to be.

 

Needless to say, the TI's lack of memory is a huge obstacle for writing the types of games I want so I was wondering if someone could describe to me in detail, how some of these programs are able to access additional data from the ROMs?

 

Any help would be much appreciated.

Edited February 16 by Cheung

[apersson850]

Today there are various hardware that allows for more memory in the TI 99/4A than the original 32 K RAM plus 16 K video RAM. How to access that memory depends on which hardware it is. Some will give you a megabyte or even more.

 

There are also various cartridge simulators that have more memory than the normal cartridges had back in the 1980's. But if we do look at them, then they had two basic methods.

• ROM available at cartridge address space >6000->7FFF.
• GROM available at the five highest grom chip addresses. The console occupies the three lowest of the eight possible.

The ROM address space is 8 K, but some cartridges, like Extended BASIC, supports a paging method, where you can switch the upper 4 K with another page. So a total of 12 K ROM.

Max number of GROMs in a cartridge were five, with the standard addressing. Extended BASIC has four. Each GROM held max 6 K back then. Extended BASIC had four, so in total 36 K GROM+ROM. A Maximem module (existed even back in the 1980's) was a RAM cartridge with up to 56 K RAM. The Gramcracker had up to 80 K RAM, I think.

[+chue]

I think you want to read up on "bank switching", although I do not know if compiled XB supports this. 

 

Example thread on bank switching: 

 

 

 

[Cheung]

7 minutes ago, apersson850 said:

Today there are various hardware that allows for more memory in the TI 99/4A than the original 32 K RAM plus 16 K video RAM. How to access that memory depends on which hardware it is. Some will give you a megabyte or even more.

 

There are also various cartridge simulators that have more memory than the normal cartridges had back in the 1980's. But if we do look at them, then they had two basic methods.

• ROM available at cartridge address space >6000->7FFF.
• GROM available at the five highest grom chip addresses. The console occupies the three lowest of the eight possible.

The ROM address space is 8 K, but some cartridges, like Extended BASIC, supports a paging method, where you can switch the upper 4 K with another page. So a total of 12 K ROM.

Max number of GROMs in a cartridge were five, with the standard addressing. Extended BASIC has four. Each GROM held max 6 K back then. Extended BASIC had four, so in total 36 K GROM+ROM. A Maximem module (existed even back in the 1980's) was a RAM cartridge with up to 56 K RAM. The Gramcracker had up to 80 K RAM, I think.

How would you access the additional GROM space from a program?

[HOME AUTOMATION]

TI994a Editor Assembler Manual - 16.5 GROM ACCESS

[Tursi]

It's worth noting no modern carts page only half the cartridge space - the use the Atarisoft mechanism and page the entire 8k.

 

But the only way to use the extra space is manually - assembly language is the usual. I'm planning to release my process for using it from GCC -- but it's still completely manual (as in, you decide the page layout and you need to remember which functions are where and manually swap them in and out before calling a function ).

 

While the GROM space can be large as well, if you are building a custom cartridge anyway the ROM is easier to access, faster, and can be much larger. The largest GROM simulation (I think) is the ubergrom which gives you 120k.

 

[Asmusr]

15 hours ago, Cheung said:

Needless to say, the TI's lack of memory is a huge obstacle for writing the types of games I want so I was wondering if someone could describe to me in detail, how some of these programs are able to access additional data from the ROMs?

Since you mentioned Flying shark, it's using a 512K ROM cartridge mainly for the graphics. Accessing this memory from assembly/machine code is simple if the code, as in Flying Shark, is running from the 32K RAM. But since you're working in XB, although your program is compiled to machine code in the end, it's a different story.

 

First there's the problem of how to use raw binary data in a BASIC program. Reading the data into a string would perhaps be the most straightforward option. Maybe there's some support for that in XB 2.9 GEM?

 

Then the problem is, as long as you are developing your program, you wouldn't be able to insert another cartridge with your data. So how would you test what you're doing? You could compile you program under emulation, and then run a script on the host to combine the compiled program with the data into a ROM cartridge, and then run the result in an emulator to test it. But it sounds like a lot of trouble.  

 

Perhaps using SAMS memory would be a better choice? But I don't think XB 2.9 GEM has any SAMS support. RXB has SAMS support, but if you depend on RXB features you won't be able to compile you program.

 

 

  

Edited February 16 by Asmusr

[RXB]

RXB 2024 just released with much more GPL converted to Assembly.

Not as fast as Compiled but you can run RXB with this speed in only a Console and FinalGROM cart.

TI Basic programs in RXB just are way faster then any other method in a Console only configuration.

[SteveB]

2 hours ago, Asmusr said:

Perhaps using SAMS memory would be a better choice?

I was thinking about this the other day, doing an assembly library for XB (including compiling) to store and retreive values in SAMS, but this is completely different than having a ton of graphics data ready waiting in your module. I can only thing of loading from disk to SAMS on startup as a work-around.

 

Would something like this be useful?

 

[Cheung]

4 hours ago, Asmusr said:

Since you mentioned Flying shark, it's using a 512K ROM cartridge mainly for the graphics. Accessing this memory from assembly/machine code is simple if the code, as in Flying Shark, is running from the 32K RAM. But since you're working in XB, although your program is compiled to machine code in the end, it's a different story.

 

First there's the problem of how to use raw binary data in a BASIC program. Reading the data into a string would perhaps be the most straightforward option. Maybe there's some support for that in XB 2.9 GEM?

 

Then the problem is, as long as you are developing your program, you wouldn't be able to insert another cartridge with your data. So how would you test what you're doing? You could compile you program under emulation, and then run a script on the host to combine the compiled program with the data into a ROM cartridge, and then run the result in an emulator to test it. But it sounds like a lot of trouble.  

 

Perhaps using SAMS memory would be a better choice? But I don't think XB 2.9 GEM has any SAMS support. RXB has SAMS support, but if you depend on RXB features you won't be able to compile you program.

 

 

  

Would it be possible to write the data in an assembly program to specific bank(s) but access and switch the banks in a compiled XB program?

[Tursi]

It might be interesting to come up with a handful of possible uses that XB (and possibly compiled XB) could call that could use the expanded ROM space (and heck, why not the same functions using AMS?)

Like perhaps, a function to load graphics from a bank (for instance, to load part or all of the character set quickly), copy data from ROM to RAM, VRAM or AMS, maybe automate a music player (like VGMComp2) to play from a particular bank automatically, play a digital sample from a bank... those seem like they'd be the most memory intensive functions?

 

Ultimately my usual motivation is "what will it be used for?". Since all the easy options would not expand the space available to your compiled XB program, I think that limits it. Now, if Harry wants to get really creative and implement XB overlays...

 

[SteveB]

3 hours ago, Tursi said:

It might be interesting to come up with a handful of possible uses that XB (and possibly compiled XB) could call that could use the expanded ROM space (and heck, why not the same functions using AMS?)

Like perhaps, a function to load graphics from a bank (for instance, to load part or all of the character set quickly), copy data from ROM to RAM, VRAM or AMS, maybe automate a music player (like VGMComp2) to play from a particular bank automatically, play a digital sample from a bank... those seem like they'd be the most memory intensive functions?

 

Ultimately my usual motivation is "what will it be used for?". Since all the easy options would not expand the space available to your compiled XB program, I think that limits it. Now, if Harry wants to get really creative and implement XB overlays...

 

Automatic overlays would surely be nice, but even now I have an issue with 6kb I can't really use in a compiled program when putting the runtime into low-memory, as in the program becomes to big to load in normal XB. Getting rid of much static data for CALL CHAR etc in the actual code for the main program would create more options.

 

I think, there are two options needed to get a BASIC support:

1. Loading of binary files into memory (currently only DV files supported by the compiler)
2. CALL MOVE extended to move data from and to SAMS or a similar SAMS-specific subroutine

What will it be used for? Fooling around with old hardware, I guess...

 

 

 

[Cheung]

On 2/16/2024 at 10:28 AM, apersson850 said:

Today there are various hardware that allows for more memory in the TI 99/4A than the original 32 K RAM plus 16 K video RAM. How to access that memory depends on which hardware it is. Some will give you a megabyte or even more.

 

There are also various cartridge simulators that have more memory than the normal cartridges had back in the 1980's. But if we do look at them, then they had two basic methods.

• ROM available at cartridge address space >6000->7FFF.
• GROM available at the five highest grom chip addresses. The console occupies the three lowest of the eight possible.

The ROM address space is 8 K, but some cartridges, like Extended BASIC, supports a paging method, where you can switch the upper 4 K with another page. So a total of 12 K ROM.

Max number of GROMs in a cartridge were five, with the standard addressing. Extended BASIC has four. Each GROM held max 6 K back then. Extended BASIC had four, so in total 36 K GROM+ROM. A Maximem module (existed even back in the 1980's) was a RAM cartridge with up to 56 K RAM. The Gramcracker had up to 80 K RAM, I think.

So would I be able to write data to GROM space by writing an assembly program that has graphic/sound DATA located starting at >8000 and then access that data using

 

CALL PEEK(>8000,VAL,...)

 

I'm going to guess it's more complicated than that. Maybe use the XB256's CALL LINK("READV", >8000, VAL1,VAL2,...)

 

When loading the GROM, how do do you put the program/data in a specific bank? Does the  ModuleCreator2 software handle that for you?

[apersson850]

Accessing GROM directly can't be done from BASIC unless it's some version that has been expanded with such support. The standard Extended BASIC does have PEEK and LOAD. LOAD is a more advanced version of what sometimes is called POKE in other computes.

But the TI has three kinds of memory. CPU memory (PEEK and LOAD), video memory (PEEKV and POKEV exists in some versions) and GROM memory, for which I've never seen support for direct access.

But you could have an assembly routine which would load a specific chunk of data from your GROM (or really GRAM in this case) to video memory to update a picture.

To get the images in there to begin with you probably have to make a special data loader software as well.

 

If I was to do such a program and had to do it in BASIC, I would begin with creating the images and store them in files on disk. Then I'll make code that can read these files and display the data for testing. Once I'm done with the design, I would make a program which reads all files and stores them according to some scheme in the module memory space, and modify my program to read them from there instead of from disk.

 

I used a similar approach once, when I wrote a program together with a friend. He wanted a program that ran in Extended BASIC with 32 K RAM expansion but only tape storage. He wanted a program which when read from tape and then run, would load a new file from tape, which contained the assembly program he needed. So I developed that assembly program, which would run from disk, first. Then I developed a loader program (also assembly) which we translated to CALL LOAD commands, so we poked it into memory. That program would then load the real assembly program from cassette, something BASIC couldn't do. Finally a developed a program which would move the orignal assembly program, which was loaded from disk, to the proper file on the tape.

[sometimes99er]

12 hours ago, apersson850 said:

But the TI has three kinds of memory. CPU memory (PEEK and LOAD), video memory (PEEKV and POKEV exists in some versions) and GROM memory, for which I've never seen support for direct access.

You're forgetting RXB. RXB has CALL MOVES for moving chunks of bytes between memory types. Here's an example copying the large TI font from GROM to VDP, making it available.
 

100 for c=32 to 95::print chr$(c); ::next c::print : :
110 call moves("GV",512,1204,1024)
120 input i$

[Cheung]

5 minutes ago, sometimes99er said:

You're forgetting RXB. RXB has CALL MOVES for moving chunks of bytes between memory types. Here's an example copying the large TI font from GROM to VDP, making it available.
 

100 for c=32 to 95::print chr$(c); ::next c::print : :
110 call moves("GV",512,1204,1024)
120 input i$

If only RXB could be compiled or 2.9 had CALL MOVES...

[sometimes99er]

1 minute ago, Cheung said:

If only RXB could be compiled or 2.9 had CALL MOVES...

Well. 2.9 should have the ability to run other compiled programs. So you could have the first program setting up graphics and more, and the second merely containing game logic - effectively moving you beyond 32K.

[Cheung]

5 minutes ago, sometimes99er said:

Well. 2.9 should have the ability to run other compiled programs. So you could have the first program setting up graphics and more, and the second merely containing game logic - effectively moving you beyond 32K.

How would you call the compiled program that's located on cartridge?

 

Normally, I would just read the additional data off the disk, but people seem to want everything off the Final Grom for the sake of convenience.

Edited February 18 by Cheung

[RXB]

1 hour ago, Cheung said:

If only RXB could be compiled or 2.9 had CALL MOVES...

Actually XB 2.9 GEM does have a CALL MOVE but it does not work with GRAM/GROM 

 

Oh and does not move from or to String Variables either.

Edited February 18 by RXB
comment added

[sometimes99er]

2 hours ago, Cheung said:

Normally, I would just read the additional data off the disk, but people seem to want everything off the Final Grom for the sake of convenience.

Yes.

2 hours ago, Cheung said:

How would you call the compiled program that's located on cartridge?

I don't think that's solved yet.

I think the easiest way forward for Wilhelm, is to make routines to allow copying data from a ROM bank above the compiled and banked 2.9, to either VDP or RAM. Care must be taken to ensure, that you do not overwrite bits that make the compiled program run. After MAKECART8 you append your databanks to the end of the cartridge. The edit-compile-test cycle by which a programmer iteratively remove errors becomes somewhat longer and more complex, but not impossible. I suggest you try out Assembly. There's a learning curve different from person to person. You could use 2 weeks or 2 years to get where you are today with your current game development project.
😉

Edited February 18 by sometimes99er

[Cheung]

Senior falcon seems to describe this feature in the latest version of Jewel:

 

There is another utility that can combine multiple cartridges into a much larger multiple cartridge. You can have a compiled program load and run any other program in the cartridge, allowing a large XB program with many program files to run from a single cartridge. Or you can have a cartridge start with a menu program that allows you to select from multiple compiled programs.

[sometimes99er]

1 hour ago, Cheung said:

Senior falcon seems to describe this feature in the latest version of Jewel:

 

There is another utility that can combine multiple cartridges into a much larger multiple cartridge. You can have a compiled program load and run any other program in the cartridge, allowing a large XB program with many program files to run from a single cartridge. Or you can have a cartridge start with a menu program that allows you to select from multiple compiled programs.

Oh. Nice. 🙂

[senior_falcon]

2 hours ago, Cheung said:

Senior falcon seems to describe this feature in the latest version of Jewel:

 

There is another utility that can combine multiple cartridges into a much larger multiple cartridge. You can have a compiled program load and run any other program in the cartridge, allowing a large XB program with many program files to run from a single cartridge. Or you can have a cartridge start with a menu program that allows you to select from multiple compiled programs.

Yes, that can be done.

Of course the ideal would be to have multiple pages of assembly code that could be paged in and run as necessary. But that's not going to happen, at least from me!

Much of the VDP is not used by a compiled program, so you could use it to store multiple fonts, character definitions, colors, sprites, etc. But the data has to get there first. One possibility would be to have the first program in the chain copy data from DATA statements into the unused areas of the VDP. It would be a little cumbersome, but it should work. For example:

5 I=8192  !vdp at >2000

10 READ A$

20 IF A$"" THEN run the next program

30 FOR J=1 TO LEN(A$)::CALL POKEV(I,ASC(SEG$(A$,J,1)))::I=I+1::NEXT J

40 GOTO 10

(I have not tested this so it may have errors, and of course in XB it is likely to crash the program)

 

Now that the vdp is loaded, then it gets easier. The next program in the chain could

CALL MOVE(1,8192,1024,768)    move 768 bytes from v>2000 to v>0400

[Cheung]

17 minutes ago, senior_falcon said:

One possibility would be to have the first program in the chain copy data from DATA statements into the unused areas of the VDP. 

Could I just write a program in XB2.9 that defines all the CHAR patterns and maybe loads the music data, compile it and then write another compiled XB2.9 program that has all the game code and can run the other compiled program from the cartridge?

 

That should be good enough for most of what I need.

[RXB]

LOL from a 1975 Motorcycle magazine:

 

"MAN DEARLY LOVES TO COMPLICATE THINGS, YOU NEVER SEE ANYONE FASCINATED WITH A CRESCENT WRENCH.'

 

The article was about a how easy it was to fix a Bultaco motorcycle that you could take apart and repair with just 

a pair of pliars, and a flat edge screwdriver. 

Edited February 18 by RXB
Spelling