Jump to content

Recommended Posts

The uberGROM cartridge simulates a GROM... It is in this way RXB can be put on cart now, along with XB2.7. You can run GPL code from the cart space when the blue board is pluged in and configured properly. :)

Thanks. Will order one uberGROM soon then.

Thanks Lee. I will read all that I can find on GPL. I think that actually compiling and running a GPL Hello World might be more difficult than I am anticipating. It is not just the code but how to get to the point that I set up the environment to fire a GPL program on a real TI. :) any newbie tips will be appreciated.

Rich is the expert here. :) He has a whole series of videos on how to do GPL.

 

http://atariage.com/forums/topic/180471-gplhow2

 

It's worth noting that there is not often call to mix the two. GPL can be a little more compact but getting in and out of the interpreter cleanly is a little tricky and places restrictions on your use of the scratchpad RAM.

  • Like 1
  • 3 weeks later...
  • 2 weeks later...

RXB 2015E has been out for a few months now so wondering why the link only has RXB 2012 listed?

 

Also RBASIC that puts the EA cart TI Basic commands into the TI Basic area for use without a EA cart is not even listed?

(Granted both RXB and RBASIC both require a GRAM device on real hardware)

Can I use Classic99 to run GPL cartridges (.BIN files) created with XGA99?

 

When I selected the BIN file generated using the USER mode in Classic 99 I could not see the program I wrote (Only 1 TI BASIC) could be seen. I know that in the documentation I read that XGA99 produces .BIN for MESS. But I prefer Classic 99. Maybe the GPL Header in the BIN file is not compatible with Classic 99?

Let alone that MESS does not run plain BIN files since about four years ago... :)

 

Sorry my bad.. I am new to XGA99. I used XGA99 with -i option and it created a BIN file but it was not intended for MESS but a GROM/GRAM device. Classic99 recognised the BIN but did not list it in the startup screen. I could only see 1 TI BASIC. It might be that the GPL header is not being auto scanned by classic99.

 

When I used XGA99 with -c to create a file for MESS it created an RPK file.

 

Can I use the RPK in classic 99?

Edited by Davvel

Post the file and I can tell you why it doesn't show up. But likely it's because you have a 6-byte GRAMKracker header in front of the data, and Classic99 didn't figure it out. Strip those 6 bytes and it will probably work.

 

Classic99 does not support RPK today.

  • Like 1

Post the file and I can tell you why it doesn't show up. But likely it's because you have a 6-byte GRAMKracker header in front of the data, and Classic99 didn't figure it out. Strip those 6 bytes and it will probably work.

 

Classic99 does not support RPK today.

Thanks Tursi, much appreciated. I will retry when I am back at home after work.

 

Do you suggest that I go for Assembly rather than GPL to be easier/cheaper to make a cartridge if and when I succeed in creating any kind of app/game?

The boards and the parts are not significantly different in price (a few dollars), so that may not be a major consideration. There are only a few folks programming in GPL right now, so the fact that you are learning it is a very good thing. And cartridges can mix GPL and Assembly, so it is not necessarily an either-or thing. You can do both and you may end up with something truly awesome. . .

Post the file and I can tell you why it doesn't show up. But likely it's because you have a 6-byte GRAMKracker header in front of the data, and Classic99 didn't figure it out. Strip those 6 bytes and it will probably work.

 

Classic99 does not support RPK today.

I opened the BIN file with a Hex Editor but I did not see any obvious 6 bytes to strip. Is it easy to explain which 6 bytes? I tried the first 6 bytes but to no avail. Thanks.

I have to look at the data to advise what to do. If you don't want to post the whole thing, maybe just the first 128 bytes? :)

 

To answer the question, I would personally advise assembly, yes, but it's a preference thing. Header wise, though, it's the same ;)

Edited by Tursi

This should really move to a different thread now such as the xdt99 thread or the Classic99 thread, but if you're using xga99 then the -i option will add

.

AA 01 00 00 00 00 addr
00 00 00 00 00 00 00 00
00 00 start name...

.

to the raw byte code. From Tursi's comment I would assume that you should delete the first six bytes

.

AA 01 00 00 00 00

.

If those intro bytes are uncommon I might adjust the image generation, or add another option to xga99 to turn them on or off. MESS does require (or at least doesn't mind) those bytes.

This should really move to a different thread now such as the xdt99 thread or the Classic99 thread, but if you're using xga99 then the -i option will add

.

AA 01 00 00 00 00 addr
00 00 00 00 00 00 00 00
00 00 start name...

.

to the raw byte code. From Tursi's comment I would assume that you should delete the first six bytes

.

AA 01 00 00 00 00

.

If those intro bytes are uncommon I might adjust the image generation, or add another option to xga99 to turn them on or off. MESS does require (or at least doesn't mind) those bytes.

Thanks to all for your kind help. The small demo/POC finally executed. It was not the header but the filename. I should have read the Classic99 document well before I posted here as it was clearly explained that the filename should be xxxxxG.bin where G means that the cartridge file contains GROM code. Sorry for that.

The 'AA' tells the system that a valid ROM is present, so you wouldn't remove that. GRAM Kracker and PC99 (and other) files have an /additional/ 6 byte header that resembles the PROGRAM image header for EA#5, specifying the type of ROM and where to load it. That's what I was talking about, but it's not in the bytes you show there. :)

  • Like 1

Tursi, Please note that your program "Classic99" works perfectly with the output BIN file of the "XGA99" compiler.

 

It was my mistake for not renaming the BIN file to be compliant with your documentation.

 

We do not need to remove any bytes from the BIN header. The BIN file produced is 100% compatible with Classic99.

 

All, kindly note that if you are compiling GPL programs simply name your output file <any file name>G.bin example MyDemoG.bin or Program1G.bin.

 

Thanks.

Tursi, Please note that your program "Classic99" works perfectly with the output BIN file of the "XGA99" compiler.

I understand, thank you, I was just expanding on the other question.

 

Also, it's only necessary to rename files to use the automatic Cartridge->User->Open option. If you're willing to describe the cartridge requirements in Classic99.ini, the filename can be absolutely anything. Most people use the simple way, though, so I tend to recommend the naming scheme. ;)

I understand, thank you, I was just expanding on the other question.

 

Also, it's only necessary to rename files to use the automatic Cartridge->User->Open option. If you're willing to describe the cartridge requirements in Classic99.ini, the filename can be absolutely anything. Most people use the simple way, though, so I tend to recommend the naming scheme. ;)

Agreed, I tried the classic99.ini way too, and it worked as you explained. Well done for a great emulator, I love it. I feel surrounded by humble giants.

Tursi, on a separate note, I have followed the progression of your work towards VGM during the last 5 years, man there is a lot for me to read to catch up with you lot. I could not find your compression software and assembly player as the links are not working for some reason but apart from that, my question is, am I understanding well that using VGM you can actually create any sound or music on PC (WAV), Convert, compress and create assembly byte code which can be played back directly through the TI sound chip (using your assembly player) and that it is possible that you can even playback voice snippets without having a speech synth? maybe I am mixing things up when I read articles from various time periods and authors.

I slacked off on restoring my download database, sorry. I'll get to that this weekend.

 

In the meantime, sort of. The VGM protocol itself does support timing of any sort, so it can handle sampled speech, but my playback code runs on the 60hz interrupt, which doesn't offer enough resolution for sample playback.

 

The TI is capable, of course. You wouldn't want to use VGM, as it uses multiple bytes per sample - raw data would be far more memory efficient. :)

  • Like 1

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...