Grom Address wrapping

[Gazoo]

I think the confusion comes from definition here... I do not know what you are classifying as a "page", that's why I used my own terms and defined them.

A Grom 'page' is the complete address space from g>0000 to g>FFFF that responds to a single grom base, say> 9800. That particular memory area would be described as "page 1'. Page 2 would be the same address space that responds to grom base >9804, and so on. The term 'bank' has also been used to describe this. 'Page' is the term used with the Pgram, and 'Bank' is the term used with the HSGPL, both meaning the same thing.

 

A GROM "slot", in my terminology, is 8k.

OK, historically that's just a GROM.

 

There are 16 GROM access bases, which you can think of as 16 completely distinct ranges from >6000 to >FFFF.

...also known as 'Pages' or "Banks'.

 

 

In that range, each 8k is a "slot", so there are 5 "slots" in each access base.

Thats probably where the confusion lies, the inclination would be to think of the term 'slot' as a 'page' or 'bank'.

 

 

This is important, because GROM memory is NOT a continuous memory range from >6000 to >FFFF. It is a range from >6000 to >7FFF, then one from >8000 to >9FFF, then one from >A000 to >BFFF, then >C000 to >DFFF, and finally >E000 to >FFFF. If you try to read memory from a GROM and try to roll over from >7FFF to >8000, it actually wraps back around to >6000 - the high three address bits never autoincrement. Software that uses more than one GROM actually has to use a jump instruction to change chips.

That is not my experience. The Gram Kracker, Pgram, and HSGPL all increment to the next Grom. The lone exception being the case of the 2 byte 'Branch within a Grom' instruction falling on the last 2 bytes of the Grom which does indeed wrap around. The instruction being of the type >4xxx (branch to the first half of the Grom), or >5xxx (branch to the second half of the Grom).

 

So 5 possible slots, and 16 possible bases, means there are a total of 80 slots.

 

You can configure each slot to be any available block of memory or a peripheral. It is not mandatory to fill every slot.

 

So, you /can/ configure it as you describe. But you don't HAVE to. For instance, if you want to load 3 different 6k GROM cartridges, they all expect to load at >6000. So you put one at >6000 in base >9800, one at >6000 in base >9804, and one at >6000 in base >9808. You have used 24k (because my device always allocates 8k blocks), but used three distinct bases. You have just left most of it (the slots from >8000-FFFF in each base) unmapped - there is nothing there.

Okay, I understand your terminology now, it's just that it's inconsistent with pre-existing terminology and the way Grom emulators up to this point have been designed and used. Hence the confusion. I'm hesitant to suggest a solution to making your new terminology consistent with the pre-existing terminology. Unless you always refer to it as "Tursi's definition of Grom usage".

 

If you are not familiar with how memory mappers work, the concept is admittedly a bit confusing. it should be more straightforward when the GUI exists so I can show you instead of talking theory.

Yikes!!!!!! Didn't expect that. Know anything about the Geneve and how it works? (and how it boots? , and how the Permanent MDOS GPL version works?) :-D :-D :-D :-D :-D

 

 

Gazoo

Edited January 25, 2014 by Gazoo

[RXB]

As the only guy the works with GPL exclusively I stick with the guys that invented most of the terms and created the first 8K GROMs and decoded the most stuff Miller Graphics.

 

Just giving just rewards to those that did the work first. Any new terms work fine. I just insist that credit is due to the shoulders we stand on.

[Gazoo]

As the only guy the works with GPL exclusively I stick with the guys that invented most of the terms and created the first 8K GROMs and decoded the most stuff Miller Graphics.

 

Just giving just rewards to those that did the work first. Any new terms work fine. I just insist that credit is due to the shoulders we stand on.

 

Yes, but there will continue to be confusion unless one states which set of terms one is using when having a Grom-based discussion.

[Gazoo]

For instance, if you want to load 3 different 6k GROM cartridges, they all expect to load at >6000. So you put one at >6000 in base >9800, one at >6000 in base >9804, and one at >6000 in base >9808. You have used 24k (because my device always allocates 8k blocks), but used three distinct bases. You have just left most of it (the slots from >8000-FFFF in each base) unmapped - there is nothing there.

 

The traditional way of describing what you are doing in the example above is that you are using only Grom 3 on the first 3 pages. (assuming Groms 0, 1, and 2 respond to all pages). Much simpler and eliminates the confusing term 'slots'.

 

Gazoo

Edited June 15, 2013 by Gazoo

[Tursi]

Was it so important that you had to reply to my message twice?

 

It comes across as that all you want to say is "you're wrong". Sorry, the terminology is what it is. This is not a GRAMKracker replacement device. To call a programmable memory location that could at any time be RAM, a serial port, or an analog-digital device a "GROM" is confusing. Because you can "install" devices into each address, I chose slot. I don't see how that prevents you from achieving your goals.

 

That is not my experience. The Gram Kracker, Pgram, and HSGPL all increment to the next Grom. The lone exception being the case of the 2 byte 'Branch within a Grom' instruction falling on the last 2 bytes of the Grom which does indeed wrap around. The instruction being of the type >4xxx (branch to the first half of the Grom), or >5xxx (branch to the second half of the Grom).

 

Your experience aside, /real/ GROMs work that way. I don't have experience with the Gram Kracker, Pgram or HSGPL and did not set out to replace them.

 

Unless you always refer to it as "Tursi's definition of Grom usage".

 

I am only speaking in the context of this particular device.

 

Yikes!!!!!! Didn't expect that. Know anything about the Geneve and how it works? (and how it boots? , and how the Permanent MDOS GPL version works?) :-D :-D :-D :-D :-D

 

It wasn't an attack, nor am I being deliberately condescending. I don't know your experience level. No, I don't know anything about the Geneve and how it works - what does that have to do with this?

 

[Gazoo]

Was it so important that you had to reply to my message twice?

 

It comes across as that all you want to say is "you're wrong". Sorry, the terminology is what it is. This is not a GRAMKracker replacement device. To call a programmable memory location that could at any time be RAM, a serial port, or an analog-digital device a "GROM" is confusing. Because you can "install" devices into each address, I chose slot. I don't see how that prevents you from achieving your goals.

 

 

 

Your experience aside, /real/ GROMs work that way. I don't have experience with the Gram Kracker, Pgram or HSGPL and did not set out to replace them.

 

 

 

I am only speaking in the context of this particular device.

 

 

 

It wasn't an attack, nor am I being deliberately condescending. I don't know your experience level. No, I don't know anything about the Geneve and how it works - what does that have to do with this?

 

 

I was not saying 'you're wrong' other than the part about the rollover at the end of the Grom. And I do stand by my statements there. Since there are no real 8k Groms, we must rely on all the behavior of all the existing devices that have acted as 8k Groms. In that context real groms _DO_ act the way I described.

 

The term "Grom" is not confusing to a TI user, and while it might mean other things to the computer world at large, it is a very specific thing for us TI'ers. It's basically 8k of memory used for GPL code. (6k in a real chip)

 

The Geneve could not function without a memory mapper, couldn't boot, couldn't run GPL. I have a little bit of intimate knowledge there. Sure seemed like an attack when I was only pointing out confusing terminology regarding existing and yet-to-be-released devices.

 

I understand your liking the terms you have invented for your device, and your wanting to defend your terminology. My suggestion to stick to the already known terms takes into account the aging of many in our community, some of the elders simply won't understand different conflicting terms being applied to things they already know, they'll buy the cart and it will sit unused because it doesn't make the same sense the legacy devices did.

 

 

 

Gazoo

Edited June 15, 2013 by Gazoo

[Tursi]

I understand your liking the terms you have invented for your device, and your wanting to defend your terminology. My suggestion to stick to the already known terms takes into account the aging of many in our community, some of the elders simply won't understand different conflicting terms being applied to things they already know, they'll buy the cart and it will sit unused because it doesn't make the same sense the legacy devices did.

 

Actually, it's less a thing of "wanting to defend my definitions" as you asked for a description of capabilities, and then attacked the way I defined it. You know that technically I am "one of the elders", or at least, I've been a continual user

since '83.

 

So yes. I know what it means when you say "GROM 5". But I did not feel that adequately described my device function.

 

There is a problem with simple continual increment and that is when you cross the boundary from >5FFF to >6000 -- suddenly you can have two devices driving the bus. Now, you can argue that it's safe to override the console GROMs, you can also argue that will never happen, but I opted for a design where that wasn't possible. If it is that big an issue to you, I will show you where to make the one line change to the code -- obviously I had to explicitly add that behaviour. It's easy and the code will be available to everyone, so it's not a huge deal. Likewise, if you don't like the way I define the loader, it's fully documented and you can create your own.

 

The Geneve could not function without a memory mapper, couldn't boot, couldn't run GPL. I have a little bit of intimate knowledge there. Sure seemed like an attack when I was only pointing out confusing terminology regarding existing and yet-to-be-released devices.

 

I had a read of your profile, and you clearly have reason to be passionate about GROM emulation. But not everyone /does/ understand memory mappers and the history of memory mappers on the /4A/ machine is very, very limited. It was not a terribly unreasonable assumption. Nevertheless, I apologize for slighting you. That said, I was rather dismayed by the "YIKES!!!" response. Perhaps we're even!

 

So, yes. You have 16 pages available to you and a total ROM space of 120k, a total RAM space of 4k, a total EEPROM space of 12k, and a handful of peripherals that can be mapped to any GROM.

 

[Gazoo]

I was not saying 'you're wrong' other than the part about the rollover at the end of the Grom. And I do stand by my statements there. Since there are no real 8k Groms, we must rely on all the behavior of all the existing devices that have acted as 8k Groms. In that context real groms _DO_ act the way I described.

 

Before a discussion breaks out on this, I offer an example of proof of the statement above.

 

Find the 'Pgram utilities 2.3' disk. Load the Grom files 'DSKUARCMC' into any gram device or emulator. Select "Disk Utilities' from the menu, it runs, doesn't it? Look at the code to move the data from Grom to Ram. The code moves >5C00 bytes from Grom to Ram in one fell swoop. This spans a memory area of 3 Groms. If the grom counter 'rolled back ' at the end of a Grom, this code wouldn't work, but it does work. The only known exception (so far) that I know of is the 'Branch within a Grom' operand I previously mentioned.

 

Gazoo

Edited June 15, 2013 by Gazoo

[+Ksarul]

One useful note here for those following the discussion: all behavior of this module and the terms used are fully explained n the manual. Tursi is right when he notes that there is a "difference" between the capabilities of the AVR side of the cartridge when compared to a simple set of GROMs (6K or 8K). On 3rd-party code that works on any of the well-known GRAM devices, the real question is whether or not it would have worked when burned into an original set of GROM chips. If it followed the TI specifications, it might have (or it might not have). Tursi designed to the original hardware specification for behavior of a GROM device. P-GRAM, HSGPL, GRAM Kracker, the Wiesbaden Supermodul, the GRAMULATOR, and even the Geneve used a slightly modified behavior that we as a community are VERY comfortable with, as it makes certain types of programming much easier (as you so beautifully described, Gazoo). Tursi extended the possibilities of what kind of DEVICE could reside in the space normally occupied by a GROM chip. To make that extension, a GROM had to adhere to the original standard behavior addressing-wise, as failing to do so would interfere with the new GROM-constrained devices (as nicely described by Tursi). Thus we have five slots per GROM base, and those slots may include 5 standard GROMs (the norm) or they may include a mix of GROMs and other GROM-Constrained devices (a number of which are unique to this module, and which set the stage for some pretty interesting possible extensions of the TI through the cartridge port). As we use multiple GROM bases (original TI terminology for multiple sets of GROM), that has to be accounted for as well, since it activates the Review Library function on the console when it is detected. By definition from TI, the cartridge slot will recognize 16 GROM bases (as a side note, only 4 GROM bases are usable on the cartridge slot on the 99/8, per the design specifications). The AVR can use all 16, as the individual "slots" can be rearranged to any position of the five available to us in each GROM base. Thus we could be using only GROM 4 of GROM base 5, GROMs 3-7 of GROM base 1, and a smattering of individual or multiple slots in multiple GROM bases using the 9 remaining slots available to the cartridge. This IS very different from previous GRAM devices, as it is highly configurable as HARDWARE. The software we put into it is thus placed into an environment that makes it very happy. Some TI cartridges don't like to move around--now they don't have to if we want to program multiple cartridges into a single one. We just put the GROM in the proper position in one of the many GROM bases available to us and we don't WASTE any of our additional slots on that GROM base--we use them somewhere else, in a way that doesn't CONFLICT with the one we've used. Slots really is the most appropriate answer here, as we can now plug MANY small cartridges into the device without modification or wasted space.

 

Thanks for the spirited discussion, as it helped me crystallize what needed to be in this portion of the description of cartridge behavior in the manual. I'd explained much of it already, but this explanation is much more useful. Tursi and Gazoo, please add any additional thoughts to the thread, as both of you have given me much food for thought in this. Tursi: did I miss anything on the behavior? I realize that the PIO (or any of the other devices can be occupying available slots in a single GROM base next to utilized GROMs) can be used instead of a GROM (which might allow the cartridge to replicate the behavior of the DataBioTics cartridges that had a built-in PIO). I used that as an example--as I suspect that option would require someone to write a NEW program that put their word processor onto the ROM (and GROM side) of the cartridge and integrated the cartridge's existing PIO slot into their code, giving us a full-featured word processor on a cartridge. The possibilities are a bit endless here.

 

No slight intended to anyone--I'm just contributing to a very good discussion.

[+Lee Stewart]

... some of the elders simply won't understand different conflicting terms being applied to things they already know,

 

As one of those "elders" in his 70th year, who's been in the game for 50 years, I'm not having any problem with the concept.

 

they'll buy the cart and it will sit unused because it doesn't make the same sense the legacy devices did.

 

I think that would be rare, indeed.

 

...lee

[Gazoo]

As one of those "elders" in his 70th year, who's been in the game for 50 years, I'm not having any problem with the concept.

 

 

 

I think that would be rare, indeed.

 

...lee

 

You certainly would be one of the exceptions.

Having taught several users of advanced age how to use a pgram some years ago, I don't think it would be rare at all.

[Tursi]

@Ksarul: Regarding the PIO concept, there are only 4 GPIO pins, so it wouldn't be enough to drive a parallel printer. I don't have any simple ways around that off the top of my head.

 

@1980Gamer: The simple answer is yes... the more complex answer is "it depends". XB games, no, largely because XB won't be available (actually, I /can/ think of a way, if you copy the data into RAM and then switch to the XB cartridge... but I don't think anyone will develop that.) Compiled games should work, you would use the old trick of copying from ROM to RAM (and you can store the original code and copy loop in the ROM or the GROM.)

 

@Gazoo: When you support this product, you are welcome to preface the GROM explanation with "that idiot Tursi used these non-standard names", and map them that way.

 

I don't doubt that the GROM emulators run their address counter continuously -- it would require more hardware to go the other way. But this product is not intended to be a replacement for those devices - I really want that to be clear. Perhaps I should have left the GROM externally programmable as well, to avoid debate on purpose, because now it sort of blurs the line.

 

The point is that /I/ still see this (the entire cartridge) as a device that you would set up and program once, and then use as a cartridge, just like the previous ones. We are just adding the ability to do stuff with GROM space. As for the address counter wraparound, I'm just not convinced enough to go back and restart my testing for it. As that example program apparently just copies an EA#5 program to RAM, I'd point out my conversion tool http://harmlesslion.com/software/makecart which does the same thing, but uses multiple MOVEs.

 

But as I noted, I will happily show you (and everyone) where to make the change if you want a free-running address counter. I don't want to throw away all my testing at this point.

 

 

[RXB]

One useful note here for those following the discussion: all behavior of this module and the terms used are fully explained n the manual. Tursi is right when he notes that there is a "difference" between the capabilities of the AVR side of the cartridge when compared to a simple set of GROMs (6K or 8K). On 3rd-party code that works on any of the well-known GRAM devices, the real question is whether or not it would have worked when burned into an original set of GROM chips. If it followed the TI specifications, it might have (or it might not have). Tursi designed to the original hardware specification for behavior of a GROM device. P-GRAM, HSGPL, GRAM Kracker, the Wiesbaden Supermodul, the GRAMULATOR, and even the Geneve used a slightly modified behavior that we as a community are VERY comfortable with, as it makes certain types of programming much easier (as you so beautifully described, Gazoo). Tursi extended the possibilities of what kind of DEVICE could reside in the space normally occupied by a GROM chip. To make that extension, a GROM had to adhere to the original standard behavior addressing-wise, as failing to do so would interfere with the new GROM-constrained devices (as nicely described by Tursi). Thus we have five slots per GROM base, and those slots may include 5 standard GROMs (the norm) or they may include a mix of GROMs and other GROM-Constrained devices (a number of which are unique to this module, and which set the stage for some pretty interesting possible extensions of the TI through the cartridge port). As we use multiple GROM bases (original TI terminology for multiple sets of GROM), that has to be accounted for as well, since it activates the Review Library function on the console when it is detected. By definition from TI, the cartridge slot will recognize 16 GROM bases (as a side note, only 4 GROM bases are usable on the cartridge slot on the 99/8, per the design specifications). The AVR can use all 16, as the individual "slots" can be rearranged to any position of the five available to us in each GROM base. Thus we could be using only GROM 4 of GROM base 5, GROMs 3-7 of GROM base 1, and a smattering of individual or multiple slots in multiple GROM bases using the 9 remaining slots available to the cartridge. This IS very different from previous GRAM devices, as it is highly configurable as HARDWARE. The software we put into it is thus placed into an environment that makes it very happy. Some TI cartridges don't like to move around--now they don't have to if we want to program multiple cartridges into a single one. We just put the GROM in the proper position in one of the many GROM bases available to us and we don't WASTE any of our additional slots on that GROM base--we use them somewhere else, in a way that doesn't CONFLICT with the one we've used. Slots really is the most appropriate answer here, as we can now plug MANY small cartridges into the device without modification or wasted space.

 

Thanks for the spirited discussion, as it helped me crystallize what needed to be in this portion of the description of cartridge behavior in the manual. I'd explained much of it already, but this explanation is much more useful. Tursi and Gazoo, please add any additional thoughts to the thread, as both of you have given me much food for thought in this. Tursi: did I miss anything on the behavior? I realize that the PIO (or any of the other devices can be occupying available slots in a single GROM base next to utilized GROMs) can be used instead of a GROM (which might allow the cartridge to replicate the behavior of the DataBioTics cartridges that had a built-in PIO). I used that as an example--as I suspect that option would require someone to write a NEW program that put their word processor onto the ROM (and GROM side) of the cartridge and integrated the cartridge's existing PIO slot into their code, giving us a full-featured word processor on a cartridge. The possibilities are a bit endless here.

 

No slight intended to anyone--I'm just contributing to a very good discussion.

 

Very few cartridges will not function in a different GROM base.

XB for example will run from another base but many programs will crash as it is assumed that the base has not changed.

Games are an example of ones that do not care what base they are located on.

I had explored the idea of a RXB cart that used 2 GROM bases in order to make a 80K GROM cart that would support 9938 or 9958 VDP in XB.

But with no standards at all really it is almost impossible do do.

 

P.S. I should note that ONLY RXB has EA cart and RXB in same GROM Base and has been that way since before version 2000

Edited June 15, 2013 by RXB

[Gazoo]

@Gazoo: When you support this product, you are welcome to preface the GROM explanation with "that idiot Tursi used these non-standard names", and map them that way.

 

Extremely unlikely event. Already had dinner, not biting on any bait.

[RXB]

It's possible to add menu entries to Extended Basic instead of the one entry for "DSK1.LOAD". I have 4 additional menu entries for XB programs in my personal version of XB v2.7 that I use with an HSGPL card. The data is stored in the additional ROM area of the card and a small DSR added so XB can find and load the program.

 

I'm assuming the cart will be similar enough to the HSGPL to use the same process, but I don't have very much info about it yet to guarantee that fact.

 

 

Gazoo

 

RXB has multiple options for loading at start up:

 

Press any key for the drive to run "DSK#.LOAD" works for RAMDISK or disk drives.

Press 0 key and it looks for WSD1.LOAD, this works on the SCSI card also as it has this option so you do not need the name SCS1.LOAD instead.

 

Press ENTER and it looks for DSK1.UTIL1 and if you press any key it uses that for DSK#.UTIL1 so UTIL1 will load from any drive or RAMDISK.

If you press 0 after you press enter it looks for WSD1.UTIL1, this works on the SCSI card aslo as it has this option so you do not need the name SCS1.UTIL1 instead.

 

Press COMMA and it looks for DSK1.BATCH to run a USER file, or press any key for the DSK#.BATCH to run from that drive or RAMDISK. (sorry no option for SCSI or WSD)

Press ENTER after COMMA and it resets back to original DSK#.LOAD and other options again.

 

Press SPACE BAR and it goes to XB command mode.

Press any key that does not have a program named LOAD on it and it defaults back to XB command mode.

 

Press PERIOD and it goes to REA (Rich Editor Assembler)

When in REA press the PERIOD and it goes to RXB load screen.

 

I am really surprised people do not know this. I have more options for loading almost anything then any other cart ever made.

Can you name a cart with half these options?

Edited June 26, 2013 by RXB

[Gazoo]

RXB has multiple options for loading at start up:

 

Press any key for the drive to run "DSK#.LOAD" works for RAMDISK or disk drives.

Press 0 key and it looks for WSD1.LOAD, this works on the SCSI card also as it has this option so you do not need the name SCS1.LOAD instead.

 

Press ENTER and it looks for DSK1.UTIL1 and if you press any key it uses that for DSK#.UTIL1 so UTIL1 will load from any drive or RAMDISK.

If you press 0 after you press enter it looks for WSD1.UTIL1, this works on the SCSI card aslo as it has this option so you do not need the name SCS1.UTIL1 instead.

 

Press COMMA and it looks for DSK1.BATCH to run a USER file, or press any key for the DSK#.BATCH to run from that drive or RAMDISK. (sorry no option for SCSI or WSD)

Press ENTER after COMMA and it resets back to original DSK#.LOAD and other options again.

 

Press SPACE BAR and it goes to XB command mode.

Press any key that does not have a program named LOAD on it and it defaults back to XB command mode.

 

Press PERIOD and it goes to REA (Rich Editor Assembler)

When in REA press the PERIOD and it goes to RXB load screen.

 

I am really surprised people do not know this. I have more options for loading almost anything then any other cart ever made.

Can you name a cart with half these options?

 

You missed the point, Rich. All your extra options load something from a 'DSKx." device. I described a menu option to load an XB program stored in ROM as an image and loadable from there. You just chain the menu entry as you would in any other cartridge, example being the foreign language entries in many ti carts. But instead of loading fron a DSK device, it loads the program from ROM, plenty of extra rom in the HSGPL and in the yet-to-be-released cartrdge being discussed.

 

Gazoo

Edited June 29, 2013 by Gazoo

[Gazoo]

Thanks for the spirited discussion, as it helped me crystallize what needed to be in this portion of the description of cartridge behavior in the manual. I'd explained much of it already, but this explanation is much more useful. Tursi and Gazoo, please add any additional thoughts to the thread, as both of you have given me much food for thought in this.

 

 

After months of thought on the discussion of 'rollover', I've come to some clarity on the subject.

 

When using a Pgram, there are no 'real' groms present on the card. The same is true of the SOB and the Gram Kracker.

I have experience with all three.

 

Here's the important part - all 3 devices require the presence of a 'real' grom or they won't work.

 

So all three devices depend on the 'real' grom responding to a Grom access to provide the next grom address to address.

In my experience programming all three devices, the address g>xFFF rolls over to the next grom based on the response

of the 'real' grom, and DOES NOT wrap around to the start of the existing grom.

 

Try it out for yourself.

 

Gazoo, or "Kachoo" as Pebbles would pronounce it. "Bless you, Pebbles"

[RXB]

Quote from Gazzo :

So all three devices depend on the 'real' grom responding to a Grom access to provide the next grom address to address.

In my experience programming all three devices, the address g>xFFF rolls over to the next grom based on the response

of the 'real' grom, and DOES NOT wrap around to the start of the existing grom.

Try it out for yourself.

Yes that is true even if the cart has 6K GROM or GRAM boundaries it just jumps to the next valid address like >75FF jumps to >8000

[+mizapf]

So all three devices depend on the 'real' grom responding to a Grom access to provide the next grom address to address.

In my experience programming all three devices, the address g>xFFF rolls over to the next grom based on the response

I just had Ciro run a test on his TI-99/8, and I suppose it is using "real" GROMs. My test program set the GROM counter to 37FF. After a read, the next address is 3800 (read from the address counter). Also, the next address after 3FFF is 2000, as the address counter shows.

 

If you are interested and if you can transfer a D/F 80 file to a real TI, I can upload that tool here.

[JamesD]

This might be better discussed in a separate topic but...

Well if it has been done once, it can be done twice. Not saying it will be easy. However the UCSD Pascal is built in a very modular fashion. Thierry has an excellent article http://nouspikel.group.shef.ac.uk/ti99/pcode.htm

Basically the ROM in the p-code card must be patched to run from the cartridge space....

If patching the existing one is difficult someone could build one from scratch.

You can download the source for UCSD Pascal from here minus the p-machines:
http://techtransfer.universityofcalifornia.edu/NCD/19327.html?utm_source=TechListing&utm_medium=webpage&utm_term=ncdid_19327&utm_content=Campus~SD^RunSearch~True^ShowDetail~False^SortASC~False^SortColumn~NCDId^TechCategories~4%2c39%2c40%2c41%2c42&utm_campaign=NCD

 

And this page has a complete p-machine & environment for Unix that is designed to run Apple II Pascal programs (basically UCSD Pascal).

It's a bit more than you'd need but it could be a starting point.
I believe the core p-machine interpreter is ucsd-psystem-vm-0.11\ucsdpsys_vm\main.c You could compile it with gcc and add your own library of routines for the TI.
http://ucsd-psystem-vm.sourceforge.net

 

Apple II Pascal supported native procedures for speed and could load/unload segments of code from memory to run apps that were larger than memory.
With a little work to the file system you could load those segments from the cart as if it were a disk. That would make it really easy to support the multi-cart transparently to the apps themselves.

[Tursi]

I just had Ciro run a test on his TI-99/8, and I suppose it is using "real" GROMs. My test program set the GROM counter to 37FF. After a read, the next address is 3800 (read from the address counter). Also, the next address after 3FFF is 2000, as the address counter shows.

I've also tested this on 99/4A hardware the first time it came up. It behaves as described here.

Edited November 12, 2013 by Tursi

[+InsaneMultitasker]

I just had Ciro run a test on his TI-99/8, and I suppose it is using "real" GROMs. My test program set the GROM counter to 37FF. After a read, the next address is 3800 (read from the address counter). Also, the next address after 3FFF is 2000, as the address counter shows.

 

Did the 99/8 roll over to the next GROM address 0x2000 or to the same GROM at 0x2000? This isn't clear from your results.

[+mizapf]

Did the 99/8 roll over to the next GROM address 0x2000 or to the same GROM at 0x2000? This isn't clear from your results.

 

What is the "next" GROM address 0x2000? I did not switch the GROM base. Or do you think of the next GROM, i.e. the counter is 0x4000? Then why does it return 0x2000?

 

Without having exact details on the GROM internals, it seems to me that the address counter in the GROM holds all 16 bits, and the respective GROM only responds on the bus when its ID matches the first three bits of the address.

[+InsaneMultitasker]

 

What is the "next" GROM address 0x2000? I did not switch the GROM base. Or do you think of the next GROM, i.e. the counter is 0x4000? Then why does it return 0x2000?

 

Without having exact details on the GROM internals, it seems to me that the address counter in the GROM holds all 16 bits, and the respective GROM only responds on the bus when its ID matches the first three bits of the address.

Not sure -- I was only trying to reconcile your test results with Gazoo's comments. I am not all that familiar with GROM access or how it works within the TI.

[RXB]

I just had Ciro run a test on his TI-99/8, and I suppose it is using "real" GROMs. My test program set the GROM counter to 37FF. After a read, the next address is 3800 (read from the address counter). Also, the next address after 3FFF is 2000, as the address counter shows.

 

If you are interested and if you can transfer a D/F 80 file to a real TI, I can upload that tool here.

I was wrong!

 

I forgot that at the end of 6K GROMs normally you see a B table (Branch table to go to other GROMs)

 

So you are correct, thanks for that.

Edited November 12, 2013 by RXB