Classic99 Updates

[+Torrax]

Here's your modified "classic99.ini" file and new .BIN files. You need to use a hex editor to merge the rxb20012.grm - rxb20016.grm files into a single grom file "RXB2001G.bin". Rxb2001.grm and rxb20011.grm need to be seperate files called RXB2001C.bin and RXB2001D.bin.

 

Whoops forgot to mention the first 6 bytes need to be removed before merging. These bytes also help in figuring out the order of merging the various files.

 

rxb2001.grm FF0A20006000 --> removed and named to <filename>C.bin

rxb20011.grm FF0920006000 --> removed and named to <filename>D.bin

rxb20012.grm FF082000E000 \

rxb20013.grm FF072000C000 \

rxb20014.grm FF062000A000 > removed and merged in the order of rxb20016 + rxb20015 + rxb20014 + rxb20013 + rxb20014

rxb20015.grm FF0520008000 /

rxb20016.grm 000420006000 / (FA5672AE23A3 - yours)(replaced with a working one)

| |

---------------- GRAM/RAM to load - 1st byte - FF next; 00 done

- 2nd byte - 00 RAM; 01-08 GRAM Bank; 09-0A ROM >6000 Bank 0/1

| |

------------ Length

| |

-------- Address

 

(Hope the ASCII art works out here)

 

It also looks like your 20016.grm is corrupt. Not sure if Classic99 supports the ".grm" gram kracker format, need to re-read the docs again. Tursi please jump in and reply if it does.

classic99.zip

Edited March 14, 2011 by Torrax

[Tursi]

Sorry for the spam, but it's my thread, I guess. Let me do one more here!

 

You have to admit is is odd that GRAM is not supported as there were like 70 companies making Carts or GRAM devices for the TI. Where do you think all those cartidges came from?

 

In fairness, the main reason is that it's not really been needed. The GROM files are easily tweaked outside of the emulator. But you are right, it does not support those of you who want to do development of GPL programs!

 

Also the Classic99 is very clean and good looking. I just need to work with it more. I wish it had 80 column support as GPL like Assembly is much better in 80 columns.

 

VDP rewrite may support this, it eventually will either way, as I found the 9938 code that Roland Mier (sorry if I spelled that wrong) gave me years and years ago for the DOS version, and I can use that to reimplement the most important modes.

 

Now let me have a look at your file....

 

You got the basic idea right... the first issue is this:

 

[RXB2001] 

The section name MUST be "UserCartx", where 'x' is an incrementing number starting with 0. You aren't even allowed to skip numbers, sadly, but that will be rectified eventually.

 

name="RXB" 
rom1=X|6000|2000|MODS\rxb2001.bin 
rom0=C|6000|2000|MODS\rxb2011.bin 
grom=G|E000|2000|MODS\rxb2012.bin
grom=G|C000|2000|MODS\rxb2013.bin
grom=G|A000|2000|MODS\rxb2014.bin
grom=G|8000|2000|MODS\rxb2015.bin
grom=G|6000|2000|MODS\rxb2016.bin

 

I notice the extensions are all GRM, even for the ROM files. In the INI file you have them as ".bin", but if you renamed them, that should be okay. Also make sure they are in the MODs subfolder.

 

The next issue is that the file specification lines must all be "romX=", where 'X' is, again, an incrementing value starting with zero.

 

The first character is the TYPE of ROM, which you seem to have correct in your entry. Likewise, I'm guessing that you have the addresses correct.

 

The other issue is the filenames in the zip don't match the filenames in the INI. Specifically, you have filenames like "rxb20011.grm", but in the INI it's "rxb2011.bin" (ie: not enough zeros!)

 

When you run this, and it doesn't work, it can sometimes be helpful to open the debug window and look at the last error. In this case, Edit->Debugger gives a log that shows this:

 

Failed to load 'MODS\rxb2011.bin'

Failed to load 'MODS\rxb2001.bin'

Initializing AMS mode 2, size 1024k

Loading file from resource: Type D, Bank 0, Address 0x1100, Length 0x0180

Loading file from resource: Type S, Bank 0, Address 0x0000, Length 0x8000

Loading file from resource: Type P, Bank 0, Address 0x0000, Length 0xF800

Loading file from resource: Type G, Bank -1, Address 0x0000, Length 0x6000

Loading file from resource: Type C, Bank -1, Address 0x0000, Length 0x2000

Failed to load 'MODS\rxb2011.bin'

Removing header from MODS\rxb2001.bin

Loading file (MODS\rxb2001.bin) from disk: Type X, Bank 0, Address 0x6000, Length 0x2000

 

The "Removing header" is correct, it means Classic99 successfully detected and ignored the PC99 header.

 

Fixing all that up, I DO manage to get in and see the screen come up! Close Classic99, put this in your INI, and restart (note that Classic99 only reads the INI on startup, so modifying it means you have to close the emulator first - that might also have caused some frustration).

 

It crashed when I tried to select RXB (.), but I was not sure what I was expecting to see. At any rate, this should get you past the first step!

 

[usercart0] 
name="RXB" 
rom1=X|6000|2000|MODS\rxb2001.bin 
rom0=C|6000|2000|MODS\rxb20011.bin 
rom2=G|E000|2000|MODS\rxb20012.bin
rom3=G|C000|2000|MODS\rxb20013.bin
rom4=G|A000|2000|MODS\rxb20014.bin
rom5=G|8000|2000|MODS\rxb20015.bin
rom6=G|6000|2000|MODS\rxb20016.bin

 

I'm not entirely sure if it is working correctly beyond that, but it's running at any rate!

 

(Sometimes, what do you use to make the animated GIF presentations that you make? )

 

So now.. what do we need to make your GPL loader work? Is writable GROM enough?

[Tursi]

Thanks for jumping in to help, Torrax! Looks like we were both working on it at the same time!

 

Classic99 can detect and remove both PC99 and GRAM Kracker 6-byte headers, so in most cases you don't have to strip them. Also, as I showed in my file, you don't have to combine the GROM files (There used to be a limit of 4 ROM files total which often mandated that, but I raised the limit to 16 files some time ago just for cases like this).

 

I just looked at your file -- the fact that there were two separate RXBs in there probably didn't help... RXB, your solution will probably lean more towards Torrax's than mine, except that you can simplify things a tad by not combining the GROMs or stripping the 6-byte headers (as long as Classic99 properly detects them all.)

Edited March 14, 2011 by Tursi

[Opry99er]

Very nice!!

 

http://www.youtube.com/watch?v=OViiev8dnz8

[Opry99er]

| |

---------------- GRAM/RAM to load - 1st byte - FF next; 00 done

- 2nd byte - 00 RAM; 01-08 GRAM Bank; 09-0A ROM >6000 Bank 0/1

| |

------------ Length

| |

-------- Address

 

(Hope the ASCII art works out here)

 

 

 

use code boxes... bracketed code "

" and then put the same thing AFTER your ASCII art, only with a slash before the word "code".  =)  Great to have you here, Torrax.  Hopefully you'll stick around and have some fun with us!

Edited March 14, 2011 by Opry99er

[RXB]

Sorry for the spam, but it's my thread, I guess. Let me do one more here!

 

You have to admit is is odd that GRAM is not supported as there were like 70 companies making Carts or GRAM devices for the TI. Where do you think all those cartidges came from?

 

In fairness, the main reason is that it's not really been needed. The GROM files are easily tweaked outside of the emulator. But you are right, it does not support those of you who want to do development of GPL programs!

 

Also the Classic99 is very clean and good looking. I just need to work with it more. I wish it had 80 column support as GPL like Assembly is much better in 80 columns.

 

VDP rewrite may support this, it eventually will either way, as I found the 9938 code that Roland Mier (sorry if I spelled that wrong) gave me years and years ago for the DOS version, and I can use that to reimplement the most important modes.

 

Now let me have a look at your file....

 

You got the basic idea right... the first issue is this:

 

[RXB2001] 

The section name MUST be "UserCartx", where 'x' is an incrementing number starting with 0. You aren't even allowed to skip numbers, sadly, but that will be rectified eventually.

 

name="RXB" 
rom1=X|6000|2000|MODS\rxb2001.bin 
rom0=C|6000|2000|MODS\rxb2011.bin 
grom=G|E000|2000|MODS\rxb2012.bin
grom=G|C000|2000|MODS\rxb2013.bin
grom=G|A000|2000|MODS\rxb2014.bin
grom=G|8000|2000|MODS\rxb2015.bin
grom=G|6000|2000|MODS\rxb2016.bin

 

I notice the extensions are all GRM, even for the ROM files. In the INI file you have them as ".bin", but if you renamed them, that should be okay. Also make sure they are in the MODs subfolder.

 

The next issue is that the file specification lines must all be "romX=", where 'X' is, again, an incrementing value starting with zero.

 

The first character is the TYPE of ROM, which you seem to have correct in your entry. Likewise, I'm guessing that you have the addresses correct.

 

The other issue is the filenames in the zip don't match the filenames in the INI. Specifically, you have filenames like "rxb20011.grm", but in the INI it's "rxb2011.bin" (ie: not enough zeros!)

 

When you run this, and it doesn't work, it can sometimes be helpful to open the debug window and look at the last error. In this case, Edit->Debugger gives a log that shows this:

 

Failed to load 'MODS\rxb2011.bin'

Failed to load 'MODS\rxb2001.bin'

Initializing AMS mode 2, size 1024k

Loading file from resource: Type D, Bank 0, Address 0x1100, Length 0x0180

Loading file from resource: Type S, Bank 0, Address 0x0000, Length 0x8000

Loading file from resource: Type P, Bank 0, Address 0x0000, Length 0xF800

Loading file from resource: Type G, Bank -1, Address 0x0000, Length 0x6000

Loading file from resource: Type C, Bank -1, Address 0x0000, Length 0x2000

Failed to load 'MODS\rxb2011.bin'

Removing header from MODS\rxb2001.bin

Loading file (MODS\rxb2001.bin) from disk: Type X, Bank 0, Address 0x6000, Length 0x2000

 

The "Removing header" is correct, it means Classic99 successfully detected and ignored the PC99 header.

 

Fixing all that up, I DO manage to get in and see the screen come up! Close Classic99, put this in your INI, and restart (note that Classic99 only reads the INI on startup, so modifying it means you have to close the emulator first - that might also have caused some frustration).

 

It crashed when I tried to select RXB (.), but I was not sure what I was expecting to see. At any rate, this should get you past the first step!

 

[usercart0] 
name="RXB" 
rom1=X|6000|2000|MODS\rxb2001.bin 
rom0=C|6000|2000|MODS\rxb20011.bin 
rom2=G|E000|2000|MODS\rxb20012.bin
rom3=G|C000|2000|MODS\rxb20013.bin
rom4=G|A000|2000|MODS\rxb20014.bin
rom5=G|8000|2000|MODS\rxb20015.bin
rom6=G|6000|2000|MODS\rxb20016.bin

 

I'm not entirely sure if it is working correctly beyond that, but it's running at any rate!

 

(Sometimes, what do you use to make the animated GIF presentations that you make? )

 

So now.. what do we need to make your GPL loader work? Is writable GROM enough?

 

 

Thank you very much Tursi.

Yea if you do a flag of some kind like the GRAMULATOR or GRAMKRACKER or PGRAM or GRAMPRAM (custom made carts using EEPROMS) would work fine. A hardware radio button on the main Classic99 interface where the Cartridge is or somewhere would be best. That way it would be like the real thing. On PC99 I can load the GPL*LOADER to load Object code into GRAM and run my new versions of RXB but the minute you restart PC99 it reverts back to the old Cartridge. I hate that as you can never really assume the test is correct or the Emulator is jacked up. As long as there is some way to save the Cartridge to disk then put it into the Classic99 I could crank out cartridges. A 80 column XB would be first on my list of to do. If you included the 512K of VRAM that the chip can support, or was it 384K, anyway a 80 column bare bones version of XB would be first XB80 or RXB80, of course most of my RXB stuff would have to go to make room for 80 column support but then later I could addin stuff. You know at one time there was a thought of allowing me to use more then one bank of GRAM at a time I could do a ton with 80k or GRAM instead of just 40K, lol with 640K you name it Disk management, RXB, 80column, TIWriter, EditorAssembler, ToD Editor, and name it one package.

 

I will look at what you said about the ini and try again with the new info again thanks. I was up late so forgot to copy the files with the bin extensions. I am a noob with Classic99 so the Debug is not something I know much about yet.

 

The header is not PC99 it is the header for all GROM files saved in disk format. All the GRAM loaders copied the GRAMKRACKER format of the 6 byte header invented by Crig Miller of Miller Graphics. The GRAMULATOR by Mark VanCopanella (My old business partner) invented the MBX option making it a 8byte header. V9T9 and PC99 and others adopted this format for the emulators. That header creates lots of problems for DOS files, but for the TI it was standard.

[Opry99er]

ToD editor??? You're talkin' my language.

[unhuman]

I'm moving from Context to Notepad++ (since there's Retroclouds' E/A syntax highlighting)... Want to know if there's similar for Extended Basic?

 

 

 

We like to use Notepad++ and assemble using Classic99. 80 column editors?? How about complete and total freedom with Notepad++ and syntax coloring using Classic99 as an assembler? It accepts .txt suffixes. I do all my assembly this way.

 

As to your other comments/questions, Tursi will have to address them, as I am not an expert. Good luck!!!

[RXB]

I'm moving from Context to Notepad++ (since there's Retroclouds' E/A syntax highlighting)... Want to know if there's similar for Extended Basic?

 

 

 

We like to use Notepad++ and assemble using Classic99. 80 column editors?? How about complete and total freedom with Notepad++ and syntax coloring using Classic99 as an assembler? It accepts .txt suffixes. I do all my assembly this way.

 

As to your other comments/questions, Tursi will have to address them, as I am not an expert. Good luck!!!

 

 

The note pad has a real problem with special characters used in the TI so it works great but there are limitations and you can not really test for these. XB has the same thing, in tokenized format the characters have to be in ASC format and when you convert to the format in the TI they would be using the format you see in the OS version your run the Emulator with. Not sure how much work that would amount to on the Classic99 side. Cut and paste in XB or EA works great and hats off to Tursi for that work.

I have a similar thing in RXB that you can write a DV80 file and run XB from that DV80 file doing anything you would type in even Assembly or multi XB programs and AMS use.

CALL USER("DSK#.DV80FILE")

the example in RXB is a file called BATCH, format a disk DSDD and put BATCH on it IN DISK 1. Then in RXB type: CALL USER("DSK1.BATCH)

This will create XB programs and show you why you use a TEXT EDITOR to make XB programs instead of typing in programs to XB. (By the way that was back in 1998 before the first emulator came out)

[Tursi]

Yea if you do a flag of some kind like the GRAMULATOR or GRAMKRACKER or PGRAM or GRAMPRAM (custom made carts using EEPROMS) would work fine. A hardware radio button on the main Classic99 interface where the Cartridge is or somewhere would be best. That way it would be like the real thing. On PC99 I can load the GPL*LOADER to load Object code into GRAM and run my new versions of RXB but the minute you restart PC99 it reverts back to the old Cartridge. I hate that as you can never really assume the test is correct or the Emulator is jacked up. As long as there is some way to save the Cartridge to disk then put it into the Classic99 I could crank out cartridges. A 80 column XB would be first on my list of to do. If you included the 512K of VRAM that the chip can support, or was it 384K, anyway a 80 column bare bones version of XB would be first XB80 or RXB80, of course most of my RXB stuff would have to go to make room for 80 column support but then later I could addin stuff. You know at one time there was a thought of allowing me to use more then one bank of GRAM at a time I could do a ton with 80k or GRAM instead of just 40K, lol with 640K you name it Disk management, RXB, 80column, TIWriter, EditorAssembler, ToD Editor, and name it one package.

 

I'm sorry for being a bit dim, but you went off tangent a little bit and I got lost about what you actually need.

 

So just to be clear, if I have an option for writing to GRAM in the normal locations, that will work for you? That's not too hard to add to the upcoming release. You would still need your own code to save the GRAM to a file. If you do not have that, I could add it to the debug/save options. Please clarify?

 

The header is not PC99 it is the header for all GROM files saved in disk format. All the GRAM loaders copied the GRAMKRACKER format of the 6 byte header invented by Crig Miller of Miller Graphics. The GRAMULATOR by Mark VanCopanella (My old business partner) invented the MBX option making it a 8byte header. V9T9 and PC99 and others adopted this format for the emulators. That header creates lots of problems for DOS files, but for the TI it was standard.

 

I knew they were similar, just that PC99 used a lot of codes that I never saw in GRAM Kracker files (some of which I still haven't identified). Interesting to know it was deliberate though. That said, V9T9 did not normally use that header, it decided where files loaded based on what the filename ended with. I know when I started Classic99 I had ROMs both with and without the header, but I can't remember if they both worked in V9T9 or just the raw ones.

[RXB]

Here's your modified "classic99.ini" file and new .BIN files. You need to use a hex editor to merge the rxb20012.grm - rxb20016.grm files into a single grom file "RXB2001G.bin". Rxb2001.grm and rxb20011.grm need to be seperate files called RXB2001C.bin and RXB2001D.bin.

 

Whoops forgot to mention the first 6 bytes need to be removed before merging. These bytes also help in figuring out the order of merging the various files.

 

rxb2001.grm FF0A20006000 --> removed and named to <filename>C.bin

rxb20011.grm FF0920006000 --> removed and named to <filename>D.bin

rxb20012.grm FF082000E000 \

rxb20013.grm FF072000C000 \

rxb20014.grm FF062000A000 > removed and merged in the order of rxb20016 + rxb20015 + rxb20014 + rxb20013 + rxb20014

rxb20015.grm FF0520008000 /

rxb20016.grm 000420006000 / (FA5672AE23A3 - yours)(replaced with a working one)

| |

---------------- GRAM/RAM to load - 1st byte - FF next; 00 done

- 2nd byte - 00 RAM; 01-08 GRAM Bank; 09-0A ROM >6000 Bank 0/1

| |

------------ Length

| |

-------- Address

 

(Hope the ASCII art works out here)

 

It also looks like your 20016.grm is corrupt. Not sure if Classic99 supports the ".grm" gram kracker format, need to re-read the docs again. Tursi please jump in and reply if it does.

 

 

Thanks will try the download. I am using the .ini from the folder that Classic99 is in and that does not work, so have tried every location to replace with no luck. Will try you download next.

[Opry99er]

I have RXB working using the DL that Torrax posted... I can load either 2001 or 2002. If you'd like, I can email you a zipped folder of my working ini and MODS folder... but I'm sure you'll have it up and running in no time flat. =)

 

By the way, I really like the look of the editor in RXB. Much better than the cyan I've been staring at for years. =)

Edited March 15, 2011 by Opry99er

[RXB]

Yea if you do a flag of some kind like the GRAMULATOR or GRAMKRACKER or PGRAM or GRAMPRAM (custom made carts using EEPROMS) would work fine. A hardware radio button on the main Classic99 interface where the Cartridge is or somewhere would be best. That way it would be like the real thing. On PC99 I can load the GPL*LOADER to load Object code into GRAM and run my new versions of RXB but the minute you restart PC99 it reverts back to the old Cartridge. I hate that as you can never really assume the test is correct or the Emulator is jacked up. As long as there is some way to save the Cartridge to disk then put it into the Classic99 I could crank out cartridges. A 80 column XB would be first on my list of to do. If you included the 512K of VRAM that the chip can support, or was it 384K, anyway a 80 column bare bones version of XB would be first XB80 or RXB80, of course most of my RXB stuff would have to go to make room for 80 column support but then later I could addin stuff. You know at one time there was a thought of allowing me to use more then one bank of GRAM at a time I could do a ton with 80k or GRAM instead of just 40K, lol with 640K you name it Disk management, RXB, 80column, TIWriter, EditorAssembler, ToD Editor, and name it one package.

 

I'm sorry for being a bit dim, but you went off tangent a little bit and I got lost about what you actually need.

 

So just to be clear, if I have an option for writing to GRAM in the normal locations, that will work for you? That's not too hard to add to the upcoming release. You would still need your own code to save the GRAM to a file. If you do not have that, I could add it to the debug/save options. Please clarify?

 

The header is not PC99 it is the header for all GROM files saved in disk format. All the GRAM loaders copied the GRAMKRACKER format of the 6 byte header invented by Crig Miller of Miller Graphics. The GRAMULATOR by Mark VanCopanella (My old business partner) invented the MBX option making it a 8byte header. V9T9 and PC99 and others adopted this format for the emulators. That header creates lots of problems for DOS files, but for the TI it was standard.

 

I knew they were similar, just that PC99 used a lot of codes that I never saw in GRAM Kracker files (some of which I still haven't identified). Interesting to know it was deliberate though. That said, V9T9 did not normally use that header, it decided where files loaded based on what the filename ended with. I know when I started Classic99 I had ROMs both with and without the header, but I can't remember if they both worked in V9T9 or just the raw ones.

 

 

 

Ok this time will stay on target:

Writing to GRAM would be perfect as then I could use the normal software I always use, and if a button is used like a real TI99/4A to turn off GRAM R/W then that would act just like GRAMKRACKER or GRAMULATOR (PGRAM is harder it uses a software one you have to load).

 

Adding a save module would be great as I could give tips for people to customize modules for everyone and cut back re-writes of modules for them.

 

 

 

***************************

Now off topic:

12 years ago I got the idea of RXB switching 40K GROM banks with a small Assembly routine loaded into Scratch pad RAM and switching 40K banks of module, but I had to come up with a different version for every single GRAM device.

i.e. GRAMULATOR, PGRAM, GRAMKRACKER, GRANDRAM, GRAMPRAM and more custom ones people released.

I demoed this at the Festwest Fair and do not remember what year. It only worked on the GRAMULATOR or GRAMKRACKER, a PGRAM version was alway buggy for some reason.

 

Classic99 would be a big bonus if I can pull this off with a small 32 byte Assembly program in FAST RAM and flip one bit to indicate 0 to F bank of Module. Then I could move to a 80K or 160K RXB. Down the line a full blown 80 column RXB cart.

I do not need ROMs as the way AMS is set up in RXB I saved 32K there for future use when I needed it.

[Tursi]

Okay, I got it. I will see about adding GROM write switches to this release.

 

I don't want to add switching of GROM banks with a new piece of hardware - but Classic99 already supports the standard 16 GROM bases. Using those (and this works on the real life console too), you can have up to 640k of cartridge GROM space. (The memory map supports up to 256 banks at 40k each, assuming 6k GROMs, but Classic99 I think only supports the 16 bases that the console does).

 

It's very easy to access these other banks, all you do is change your GROM base. Where 9800/9802/9C00/9C02 is base 0, you add 4 bytes for every subsequent base. So, base 1 is 9804/9806/9C04/9C06. Base 2 is 9808/980A/9C08/9C0A, etc. If you want to do multiple banks of GROM, I would suggest that this method which is already existing (and works in MESS too!) is a better path to take. My GROM simulator chip also supports this on a single chip - I demo'd a single chip 128k GROM solution at the faire.

[Willsy]

Tursi: "if I have an option for writing to GRAM in the normal locations, that will work for you?"

 

It'll work for me! TurboForth has G@ and G! (GROM fetch and GRAM write)... Well, it was easy to do, and you never know... It would be nice to be able to test G!

 

All I'm doing is setting the GROM address, and then writing to the GRAM write address.

 

What the heck, here's the code:

; store BYTE value (as 16 bit right justified cell) at GRAM address
gramsh	data grmfh,2
text 'G!'
grams	data $+2
movb *stack,@grmwa	; send high byte of GRAM address
swpb *stack		; swap address
movb *stack,@grmwa	; send low byte of GRAM address
dect stack		; point to value
swpb *stack		; get byte in high byte position
movb *stack,@grmwd	; write to GRAM
dect stack		; pop value
b *next			; see ya

 

I'm using exactly the same principle for V! (VDP write) which works fine, so I assume there are no other gotcha's with GROM auto-incrementing? Do I have to set bit 1 or bit 0 like we do when doing writes to the VDP? Or is that a special with VDP? Enquiring minds want to know!

[RXB]

Okay, I got it. I will see about adding GROM write switches to this release.

 

I don't want to add switching of GROM banks with a new piece of hardware - but Classic99 already supports the standard 16 GROM bases. Using those (and this works on the real life console too), you can have up to 640k of cartridge GROM space. (The memory map supports up to 256 banks at 40k each, assuming 6k GROMs, but Classic99 I think only supports the 16 bases that the console does).

 

It's very easy to access these other banks, all you do is change your GROM base. Where 9800/9802/9C00/9C02 is base 0, you add 4 bytes for every subsequent base. So, base 1 is 9804/9806/9C04/9C06. Base 2 is 9808/980A/9C08/9C0A, etc. If you want to do multiple banks of GROM, I would suggest that this method which is already existing (and works in MESS too!) is a better path to take. My GROM simulator chip also supports this on a single chip - I demo'd a single chip 128k GROM solution at the faire.

 

 

Excellent! Accessing the GROMS that way is great, but how would I save them? I mean if I load one how do I save the other bank in the bank I am in already? Matter of fact the only way to load then would be to have duplicate code in both banks so I can switch banks. I am sure you have a workable solution for me.

 

By the was RXB 2001 is working in Classic99 thanks to Opry99er sending a download. But why does the AMS not work at all? I checked and it is selected in the Options and in the .ini file, but RXB says it is not there at all. I know it works in RXB as the version came straight from PC99 and the other one works on my real TI, checked the code and is fine. Looked at grom in Classic and it is the same so what is going on?

 

You can try your version by just doing a CALL AMSINIT then SIZE in command mode. It should report that the AMS is there and the size it is and banks you can use.

Edited March 15, 2011 by RXB

[Willsy]

It's very easy to access these other banks, all you do is change your GROM base. Where 9800/9802/9C00/9C02 is base 0, you add 4 bytes for every subsequent base. So, base 1 is 9804/9806/9C04/9C06. Base 2 is 9808/980A/9C08/9C0A, etc. If you want to do multiple banks of GROM, I would suggest that this method which is already existing (and works in MESS too!) is a better path to take. My GROM simulator chip also supports this on a single chip - I demo'd a single chip 128k GROM solution at the faire.

 

Ah! I didn't take that from the Editor Assembler notes. I'll need to add an extra parameter in TF to allow the GROM base to read/write to be specified.

 

This is a VERY interesting thread. Thanks to RXB for bringing this up.

 

I personally have been VERY interested in GROM/GRAM on the TI. The holy grail for me is a cart board that has a multi-bank ROM space (say, 16 or 32K) and some GROM space. That would be nirvana. It would mean my Manic Miner game (languishing) could be radically re-structured, with the graphic data and speech data placed in GROM, in line with TI's own strategy back in the day. In fact, if I did that, I wouldn't need a multi-banked ROM at all (for that particular game) as the game engine would probably comfortably fit in ~4K.

 

Mark

[sometimes99er]

I personally have been VERY interested in GROM/GRAM on the TI. The holy grail for me is a cart board that has a multi-bank ROM space (say, 16 or 32K) and some GROM space. That would be nirvana. It would mean my Manic Miner game (languishing) could be radically re-structured, with the graphic data and speech data placed in GROM, in line with TI's own strategy back in the day. In fact, if I did that, I wouldn't need a multi-banked ROM at all (for that particular game) as the game engine would probably comfortably fit in ~4K.

Yeah, we probably all have our own feelings about how true we want to be to things back then, and from project to project, but I like what I'm hearing.

 

In fact, if I did that, I wouldn't need a multi-banked ROM at all (for that particular game) as the game engine would probably comfortably fit in ~4K.

I have underestimated the size of code in my Destroyer game (8K ROM) putting some nice to have effects on halt and being a bit minimal about a few other things. I will be compressing graphical data before having to consider GROM and/or bank-switching.

 

[RXB]

I personally have been VERY interested in GROM/GRAM on the TI. The holy grail for me is a cart board that has a multi-bank ROM space (say, 16 or 32K) and some GROM space. That would be nirvana. It would mean my Manic Miner game (languishing) could be radically re-structured, with the graphic data and speech data placed in GROM, in line with TI's own strategy back in the day. In fact, if I did that, I wouldn't need a multi-banked ROM at all (for that particular game) as the game engine would probably comfortably fit in ~4K.

Yeah, we probably all have our own feelings about how true we want to be to things back then, and from project to project, but I like what I'm hearing.

 

In fact, if I did that, I wouldn't need a multi-banked ROM at all (for that particular game) as the game engine would probably comfortably fit in ~4K.

I have underestimated the size of code in my Destroyer game (8K ROM) putting some nice to have effects on halt and being a bit minimal about a few other things. I will be compressing graphical data before having to consider GROM and/or bank-switching.

 

 

You know you could do the XB ROMs way of doing it. In a nomal XB cart the ROMs are 1 lower 4K and 2 upper 4K and as the cartridge is write protected writing to an address in the lower 4K on odd numbers will use bank 1 of upper 4K and writing to even address of lower 4K will switch to the bank 2 of upper 4K. Now GRAMKRACKER and GRAMULATOR both used full 8K banks and just had copies of the lower 4K in both, but with your game that would not matter as you only need a small section the same and the rest you would switch. You only need a section that is the same to switch banks the rest is free to use. As Classic99 supports XB Carts you are good to go using only the ROMs. Besides the code to switch banks is like 32 bytes, not exactly a huge problem to find space for.

[sometimes99er]

You know you could do the XB ROMs way of doing it. In a nomal XB cart the ROMs are 1 lower 4K and 2 upper 4K and as the cartridge is write protected writing to an address in the lower 4K on odd numbers will use bank 1 of upper 4K and writing to even address of lower 4K will switch to the bank 2 of upper 4K. Now GRAMKRACKER and GRAMULATOR both used full 8K banks and just had copies of the lower 4K in both, but with your game that would not matter as you only need a small section the same and the rest you would switch. You only need a section that is the same to switch banks the rest is free to use. As Classic99 supports XB Carts you are good to go using only the ROMs. Besides the code to switch banks is like 32 bytes, not exactly a huge problem to find space for.

Thanks for comments. We've discussed that in connection with projects related to retroclouds (Filip), acadiel (Jon) and more. I think I'm like AtariSoft style oriented, and might keep all my production at 8K ROM only - something nice and challenging to me. Most of my work since 2004 has been almost one hundred demos in the 8K ROM cartridge format. When GROM becomes readily available as hardware cartridge solution, I might change direction. Generally I also try and avoid the need for 32K RAM Expansion.

 

[Tursi]

Excellent! Accessing the GROMS that way is great, but how would I save them? I mean if I load one how do I save the other bank in the bank I am in already? Matter of fact the only way to load then would be to have duplicate code in both banks so I can switch banks. I am sure you have a workable solution for me.

 

I would suggest that the best solution to all of the "how to save" issues is to write a save program in assembly. There are limits to how much I can support in the emulator itself, having the TI itself save the data is the best approach all around. My suggestion would be to copy the GROMs to VDP and save as PROGRAM image, that takes the least code and provides the simplest output file.

 

But why does the AMS not work at all? I checked and it is selected in the Options and in the .ini file, but RXB says it is not there at all. I know it works in RXB as the version came straight from PC99 and the other one works on my real TI, checked the code and is fine. Looked at grom in Classic and it is the same so what is going on?

 

I don't know much about AMS -- see the other thread where I asked for details of how to reproduce. I need the smallest, simplest case possible as I need to step through the assembly code and see what it is trying to do.

[Tursi]

I'm using exactly the same principle for V! (VDP write) which works fine, so I assume there are no other gotcha's with GROM auto-incrementing? Do I have to set bit 1 or bit 0 like we do when doing writes to the VDP? Or is that a special with VDP? Enquiring minds want to know!

 

I believe that's what it takes, but of course I haven't tried any third party tools.

 

The setting of special bits is VDP specific - remember that those two MSBs have meaning to the video chip:

 

>8000 - this write is going to a VDP register

>4000 - do not execute the data prefetch for this address write

 

So far as I know GROMs don't have any such additional bits -- the full 16 bits of GROM address is meaningful (the top three bits are how a GROM chip knows whether to respond to reads, as there is no specific chip select in this system like normal ROMs would use).

[Tursi]

I personally have been VERY interested in GROM/GRAM on the TI.

When GROM becomes readily available as hardware cartridge solution, I might change direction.

 

It's kind of neat to see this... when I first announced my replacement GROM solution, I felt like the only real response was "why would anyone want GROM today?", so I sort of abandoned development on all but the parts I would personally be using. I also used this interface for my Linux prototype, by dedicating a GROM address to the serial port on the AVR.

 

Some people did encourage a little bit insofar as my adding modes to also access the AVR's EEPROM and RAM, as well as write modes, but overall it didn't feel needed. Also, the project I was working on with Jon and Jim (bank-switched flash plus my AVR GROM) seemed to stall due to issues with the flash chip.

 

My GROM code is complete for read-only mode, though, and available to anyone who wants to use it. I'd also be happy to program and ship chips for people (if you give me some lead time and pay for the parts). My code is at http://harmlesslion.com/software/grom

[RXB]

You know you could do the XB ROMs way of doing it. In a nomal XB cart the ROMs are 1 lower 4K and 2 upper 4K and as the cartridge is write protected writing to an address in the lower 4K on odd numbers will use bank 1 of upper 4K and writing to even address of lower 4K will switch to the bank 2 of upper 4K. Now GRAMKRACKER and GRAMULATOR both used full 8K banks and just had copies of the lower 4K in both, but with your game that would not matter as you only need a small section the same and the rest you would switch. You only need a section that is the same to switch banks the rest is free to use. As Classic99 supports XB Carts you are good to go using only the ROMs. Besides the code to switch banks is like 32 bytes, not exactly a huge problem to find space for.

Thanks for comments. We've discussed that in connection with projects related to retroclouds (Filip), acadiel (Jon) and more. I think I'm like AtariSoft style oriented, and might keep all my production at 8K ROM only - something nice and challenging to me. Most of my work since 2004 has been almost one hundred demos in the 8K ROM cartridge format. When GROM becomes readily available as hardware cartridge solution, I might change direction. Generally I also try and avoid the need for 32K RAM Expansion.

 

 

 

Well there is after all 640K of GROM 16x40=640K so not like you could use it all up and if you have a SuperCart (8K RAM at >6000) then you could just put all the software in that area and do all from a CART!

 

By the way not many people know this but if you put a Basic program in RAM or GROM or VDP it will run fine as long as you have a header there for it to see it and then it will run it.

 

So it would be possible to write a 640K Basic Program and put it all into one Cartridge and only run this from a TI console and nothing else.

(Not using any simulator it is all built into the TI OS.)

Edited March 16, 2011 by RXB

[+OLD CS1]

By the way not many people know this but if you put a Basic program in RAM or GROM or VDP it will run fine as long as you have a header there for it to see it and then it will run it.

 

So it would be possible to write a 640K Basic Program and put it all into one Cartridge and only run this from a TI console and nothing else.

(Not using any simulator it is all built into the TI OS.)

This may sound weird, but I silently posed this question to myself a number of times in my younger years, whether it would be possible to run a BASIC program outside of VDP RAM. I really have no idea why. In any case, it would be really cool to see this demonstrated.

Edited March 17, 2011 by OLD CS1