Jump to content
ralphb

xdt99: New TI 99 cross-development tools available

Recommended Posts

I think I know what's wrong -- your MAME cart wouldn't work either.

 

Of course xdt99 needs to know where your program starts.  There are two ways to define that: Doing nothing, and the very first word* is the entry (like E/A 5), or providing the start symbol with the END instruction (like auto-starting E/A 3 programs).

 

So as an easy fix, add your start symbol to END, like "   END FIRST".  I'd better be adding some explanation to the documentation.

 

*) more accurately, it's always address >6030

 

EDIT: example

Edited by ralphb

Share this post


Link to post
Share on other sites
1 hour ago, Airshack said:

After researching .rpk files I discovered they’re essentially zip files which contain all dumps along with the information required to set up the cartridge in emulation.

If I may shortly elaborate on that:

 

RPK files are in fact ZIP archives, containing dumps of ROM and GROM space, metadata information (not used), and a layout file that says what the dump files actually are. The dump files do not need any special naming convention (like *c.bin), as all information comes from the layout file. The RPK files were designed to simplify the handling of cartridges; before, all dumps had to be mounted separately (e.g. three dumps for Extended Basic: GROM space, first ROM bank, second ROM bank). I decided not to call them "*.zip" so that people are not motivated to unpack them. (By the way, the same concept of non-proper zip files is used by LibreOffice or MS Office; try to unzip a DOCX file to see.)

  • Thanks 1

Share this post


Link to post
Share on other sites

When I look up RPK in Google I get this:

The rpk file extension is associated with the NeverForget, an easy to use scheduling and reminder software for Microsoft Windows operating system.

The rpk file contains backup of reminder data.

This rpk file type entry was marked as obsolete and no longer supported file format.

 

https://www.google.com/search?sxsrf=ALeKk02cqtz3WADU2ZWO_Bdw-QReJJW5uw:1596740814477&q=difference+between+ZIP+and+RPK+file+format&nirf=difference+between+ZIP+and+APK+file+format&sa=X&ved=2ahUKEwiC862Io4frAhUJgp4KHesmBiUQ8BYoAXoECBIQKQ&biw=1920&bih=937

 

I assume the reason for RPK format is that it was abandoned by Microsoft and requires a special app to open them?

Share this post


Link to post
Share on other sites
3 hours ago, ralphb said:

Of course xdt99 needs to know where your program starts.  There are two ways to define that: Doing nothing, and the very first word* is the entry (like E/A 5), or providing the start symbol with the END instruction (like auto-starting E/A 3 programs).

 

I accomplished this so the last line in my code reads: 

 SLAST  END SFIRST
 

The change does in fact result in the xas99 generated EA3 file auto-starting, since the first line of code (after EQUates) follows the EA SAVE routine's conventions:  


SFIRST
SLOAD  JMP    START

Unfortunately this does not remedy the xas99 -b (or -c) resulting .bin file loading issue.

 

It appears Ralph's example is unintentionally incomplete in the post 351 of this thread? 

 

  • Like 1

Share this post


Link to post
Share on other sites
39 minutes ago, Airshack said:

I found that link as well but then pressed on to find this more topic specific definition:   https://www.ninerpedia.org/wiki/MESS_cartridge_handling

BTW, the ZIP section on that page is really outdated; the ZIP format is now more advanced than the RPK. The page was last updated by me in April 2016; must have been around MAME 0.173 ... 50 releases back in the past.

  • Like 2

Share this post


Link to post
Share on other sites
7 hours ago, Airshack said:

    Uh oh Mike — yikes! My suggestion to improve “Auto-Guess” was based on the belief that you were joking about the existence of such a feature. As in, “the emulator does not have auto-guess <insert snicker>, so you need to tag your files.”  Most certainly I will tag my files as it’s no big deal. I just forgot about tagging them as it has been a while since I read about it. 

I love when people reply to me with "yikes"... you haven't seen me get grumpy for years. ;)

 

The "cart->user->open" function has to guess what you are providing it, because it needs to turn what is nothing more than a filename into the entire Classic99.ini structure that other carts get. It needs all that information - load address, size, memory type and banking type - to bring it in. It's pretty easy with the tag since that tells us memory type and banking type in a single character. We can get the size from the file size. That just leaves load address, which it guesses is >6000 cause that's usually right for a cartridge. So, it's auto-guessing. ;)

 

If the tag's missing, it assumes it's a 378 - non-inverted banked ROM - since that has become the standard for the FinalGROM. But that has high risk of being wrong - the filename just needs to end with a letter that matches one of the tags. ;)

 

I wasn't being facetious about the request for suggestions. When I do it by hand, the only way to know if I'm right is to actually run the cart and see if it works. It's very difficult to make an emulator do that, but if the tags are going to keep disappearing and we aren't going to replace them with anything, I'm open to other ideas. ;)

 

Share this post


Link to post
Share on other sites
5 hours ago, mizapf said:

If I may shortly elaborate on that:

 

RPK files are in fact ZIP archives, containing dumps of ROM and GROM space, metadata information (not used), and a layout file that says what the dump files actually are. The dump files do not need any special naming convention (like *c.bin), as all information comes from the layout file. The RPK files were designed to simplify the handling of cartridges; before, all dumps had to be mounted separately (e.g. three dumps for Extended Basic: GROM space, first ROM bank, second ROM bank). I decided not to call them "*.zip" so that people are not motivated to unpack them. (By the way, the same concept of non-proper zip files is used by LibreOffice or MS Office; try to unzip a DOCX file to see.)

And IMO this was a great solution -- but are you still trying to obsolete the embedded metadata file? That was the main reason I hadn't put any urgency behind implementing them, you had announced it was going to change again. If they ARE going to stick around though, I'll happily throw my weight behind them too!

 

I suppose I could look at history and see they /haven't/ gone anywhere, but I might as well ask while you're right here. ;)

 

Share this post


Link to post
Share on other sites
3 hours ago, Airshack said:

Unfortunately this does not remedy the xas99 -b (or -c) resulting .bin file loading issue.

 

It appears Ralph's example is unintentionally incomplete in the post 351 of this thread? 

 

Do you want to post the cartridge binary, and we'll humanly auto-guess it to see what's wrong? ;)

 

Share this post


Link to post
Share on other sites
On 8/6/2020 at 4:23 PM, Tursi said:

Do you want to post the cartridge binary, and we'll humanly auto-guess it to see what's wrong?

Sure! 

 

<removed, 20K file too large for -c or -b  8k limit>

 

I've been able to use the E/A cart and the SAVE utility to create an EA5 set of three files 8K+8K+4k. With these three files I can create a functional .bin via Fred's Module Creator. It would be nice to streamline the process with xdt99, mainly to avoid the EA3 load plus SAVE utility.  

Share this post


Link to post
Share on other sites
13 hours ago, Tursi said:

And IMO this was a great solution -- but are you still trying to obsolete the embedded metadata file? That was the main reason I hadn't put any urgency behind implementing them, you had announced it was going to change again. If they ARE going to stick around though, I'll happily throw my weight behind them too!

 

I suppose I could look at history and see they /haven't/ gone anywhere, but I might as well ask while you're right here. ;)

 

By metadata, do you mean the meta-inf.xml or the layout.xml?

 

The first one was intended to hold data about publisher, year, version, language etc. This one was never really used; instead, the ZIP cartridges have these metadata in the software list file that is delivered with MAME. If you want to have a look, this is the file that takes the role of the layout.xml and the meta-inf.xml:

 

https://github.com/mamedev/mame/blob/master/hash/ti99_cart.xml

 

As for the RPK future, the goal would be to have something like this software list file focused to this one cartridge, and it could then be stored inside the ZIP file. I suppose the reason why this is still not finished can be found in many larger projects: I brought up the topic lots of years ago. Someone said, hold it, I have a solution for that. But nothing changes. Another one said that the command line argument handling should generally be revisited, and that he had something at work right now, but after months or years you still don't hear a thing... The good thing is that the replacement of RPK is at priority MIN+1 or less. Since they are working, and since other computer systems or arcade machines just don't have that demand for homebrew cartridge implementation, no one really feels like moving.

 

My concern is that one nice day, the core developers could decide on some freaky new feature for the command line which could make it impossible to keep the RPK loading, and then I am f***d because I am the only one that really needs it.

  • Sad 2

Share this post


Link to post
Share on other sites
8 hours ago, HOME AUTOMATION said:

Hmm, I don't see anything resembling a HEADER, or any program name.

 

Maybe I'm confused...

It is my assumption that xas99 will "auto-build" the header information much in the same way Fred Kaal's Module Creator appears to do. This may be my error?

 

@HOME AUTOMATION Which hex editor do you recommend?

  • Like 1

Share this post


Link to post
Share on other sites
16 hours ago, Tursi said:

Do you want to post the cartridge binary, and we'll humanly auto-guess it to see what's wrong? ;)

 

Tursi as I posted previously auto guess is basically just a feature that has to consider any possible option someone might take with a app or feature option.

I think the size of Classic99 would be increased by way more added size to pull this off.

My CALL CAT routine is 3 times the normal size for what it does to be auto-guess of user demands.

A PC does not have a size limitation, but it might be much more work than you need to attempt.

Share this post


Link to post
Share on other sites
6 hours ago, Airshack said:

@HOME AUTOMATION Which hex editor do you recommend?

  

I wouldn't say recomended... I use this because it's simple... I must have downloaded it in about '99-'00. It did help me to brick my FG99, a few months back. 

 

Depending on the settings, it will double a file's size when opening. After closing the program, it may take several seconds to restore the files original size.

 

...getting hard to find a download for this version, nowadays.

 

hhd20.thumb.JPG.712745b1fbd243d986f9db0b306ee7f4.JPG

:)

 

EDIT:

 

 

Edited by HOME AUTOMATION
Finally, found it!
  • Thanks 1
  • Haha 1

Share this post


Link to post
Share on other sites
23 hours ago, Airshack said:

I've been able to use the E/A cart and the SAVE utility to create an EA5 set of three files 8K+8K+4k. With these three files I can create a functional .bin via Fred's Module Creator. It would be nice to streamline the process with xdt99, mainly to avoid the EA3 load plus SAVE utility.  

Hi James,

So you want to be able to create a cartridge binary from an .asm program that would normally load and start at >A000?  I've been experimenting with modifying xas99.py (see attachment) to streamline the process of creating banked cartridges. So I made it possible to split the program at >A000 into 6K chunks with a GPL header and a small loader for each chunk into a 4-bank 32K cartridge file.  The options to xas99 would look something like this:

xas99.py -a 0xa000 -R -B enk.asm -n "ESCAPE FROM NK" -L enk.lst

The -a 0xa000 tells the assembler to use a base address >A000, and also indicates that the GPL header and loader should be used.

The -R option enables the "Rn" register names.

The -B is a new option I added to create a banked binary cartridge image.  Here it will create a file named "enk8.bin" unless you use the -o option to set the output filename.

The -n ... option is used to set the TI menu text; it should be all uppercase.

The -L ... is the listing file option, this lets you see the address of labels in your program so you can set breakpoints in the debugger.

xas99.py

  • Like 2

Share this post


Link to post
Share on other sites
11 hours ago, mizapf said:

As for the RPK future, the goal would be to have something like this software list file focused to this one cartridge, and it could then be stored inside the ZIP file. I suppose the reason why this is still not finished can be found in many larger projects: I brought up the topic lots of years ago. Someone said, hold it, I have a solution for that. But nothing changes. Another one said that the command line argument handling should generally be revisited, and that he had something at work right now, but after months or years you still don't hear a thing... The good thing is that the replacement of RPK is at priority MIN+1 or less. Since they are working, and since other computer systems or arcade machines just don't have that demand for homebrew cartridge implementation, no one really feels like moving.

 

I don't know the contents of any of the files in there right now, so I can't answer your question about which file, but obviously I'm only concerned about the metadata that describes the layout of the memory files inside the archive. My understanding was that you were trying to move that metadata into MAME itself for all known software, meaning there'd be nothing useful inside the archive itself except to MAME.

 

Sounds like the betting on inertia is the best bet though, hehe. Thanks for the thoughts!

 

Share this post


Link to post
Share on other sites
9 hours ago, RXB said:

Tursi as I posted previously auto guess is basically just a feature that has to consider any possible option someone might take with a app or feature option.

I think the size of Classic99 would be increased by way more added size to pull this off.

My CALL CAT routine is 3 times the normal size for what it does to be auto-guess of user demands.

A PC does not have a size limitation, but it might be much more work than you need to attempt.

Hey Rich. :) The discussion was limited solely to cartridges, not all software, and I was resisting attempting to make it any smarter than it is today. So we're good there. :)

 

  • Thanks 1

Share this post


Link to post
Share on other sites
On 8/6/2020 at 6:05 PM, Airshack said:

I've been able to use the E/A cart and the SAVE utility to create an EA5 set of three files 8K+8K+4k. With these three files I can create a functional .bin via Fred's Module Creator. It would be nice to streamline the process with xdt99, mainly to avoid the EA3 load plus SAVE utility.  

I don't know that XDT can auto-build a header... if it did, there would need to be a way for you at least specify the cartridge name. Cool feature if it's there!

 

It's trivial to add the header to your source code though... something like this will do it (assuming your start label is START).

* Cartridge Header
		AORG >6000

		DATA >AA01	* AA for valid cart, 01 is version by convention
		DATA >0100	* 01 is number of programs by convention only, 00 unused
		DATA >0000  * not used on ROM carts
		DATA PROG1  * address of first program information block
		DATA >0000  * not used on ROM carts
		DATA >0000  * not used on ROM carts
		
* program information block - this is what shows in the list		
PROG1	DATA >0000	* link to next program (0000 means no more)
		DATA START	* start address of program
		BYTE >06	* length of display name (note that it's a BYTE, not DATA)
		TEXT 'MYFILE'  * the actual string to display
		EVEN		* good idea to always do this after the header in case text misaligns it ;)

* This takes us to >6018
    
		END
		

Naturally the rest of the code needs to be in the ROM space as well (6000-7FFF). To run from memory expansion RAM instead, you would need to write a little bit of software to copy it there.

 

  • Like 1

Share this post


Link to post
Share on other sites
On 8/7/2020 at 3:05 AM, Airshack said:

I've been able to use the E/A cart and the SAVE utility to create an EA5 set of three files 8K+8K+4k. With these three files I can create a functional .bin via Fred's Module Creator. It would be nice to streamline the process with xdt99, mainly to avoid the EA3 load plus SAVE utility.  

Sorry, but I have to ask if you are sure that this file is from the .rpk archive?  As others have mentioned, it doesn't have a header.  But I rechecked that -c does indeed produce a header.  @Tursi It's using the uppercased source filename without extension as program name, unless you override it with -n.  Still, I recommend not to use -c.

 

I'm slightly confused that SAVE did produce 20 KB of data -- that is way to much for a cartridge, unless you're using bank switching.

 

Another xdt99-specific way of doing what you want to is to use the "menu.mac" macro (located in the lib/ folder) and create a header like this (at the top of the program, but after the AORG statement)

 

    copy "menu.mac"
    .menu 'ENK', SFIRST

 

With menu.mac, you still have to assemble with -b.  Once you did this, you might as well copy the header from the list file to your source file. 😉

 

But anyway, could you perhaps post or PM me the source file, and then I can try to reproduce the original issue with -c?

  • Like 1

Share this post


Link to post
Share on other sites
18 hours ago, mizapf said:

My concern is that one nice day, the core developers could decide on some freaky new feature for the command line which could make it impossible to keep the RPK loading, and then I am f***d because I am the only one that really needs it.

I would assume that users of other computers (Atari and Vectrex, in particular) are also creating homebrew software in cartridge form?  Not to mention consoles (can't remember if they're part of MAME) ...

Share this post


Link to post
Share on other sites

I like the rpk format because it's one program one file. In a browser you cannot load a file that the user didn't ask for, so you cannot load digdugd.bin if the user asked for digdugc.bin. One thing I believe the rpk format is missing is the ability to load GROMs at different bases.

Share this post


Link to post
Share on other sites

As I explained above, it is not really a question of preference. As a matter of fact, RPK is not the standard cartridge format of MAME, regardless of whether we consider it useful or not. The only reason it survived so long is that it has not bothered anyone else right now. As soon as it gets into conflict with some future MAME feature, I'll have a hard time to defend it. For that reason, I added the ZIP support some years ago, to be on the safe side at least for the old cartridges. It just needs to be enhanced to allow for homebrew stuff, and if we once have a solution for that, it should not be too difficult to convert the RPKs to ZIPs.

 

As for the homebrew stuff of other systems, either the people found another solution, they don't care, or they edited their hash files; I don't know. I only know that no other MAME system is using it, since the code was moved many years ago into the ti99 subtree, and no other code includes it.

Share this post


Link to post
Share on other sites

I think we should still maintain the rpk format in the TI community, even in the event that MAME stopped supporting it. And I would very much like to see Classic99 supporting it too.

Share this post


Link to post
Share on other sites
2 hours ago, mizapf said:

As for the homebrew stuff of other systems, either the people found another solution, they don't care, or they edited their hash files; I don't know. I only know that no other MAME system is using it, since the code was moved many years ago into the ti99 subtree, and no other code includes it.

MAMEs in a strange place there. The system was designed to run dedicated computers for which the software was complete and no new software was being designed. With that fact in place, it was a trivial choice to put all the metadata into the executable. No arcade system is ever going to use a cartridge system from an 8-bit micro - it doesn't make sense to change all that. It's fixed.

 

Consoles and computers, even old ones, are different. They constantly get new software and emulators are used for development. So restricting software to what the emulator already knows about is incredibly limiting.

 

As far as I know though, everyone else has a single file format for their ROMs. Nobody else uses the RPK format - well, why would they? Nobody but the NES uses the NES cartridge format either. The NES cartridge format isn't appropriate for the TI. Conceivably it could be adapted, but that would be silly. Likewise, the NES community isn't going to let MAME dictate to them that all NES ROMs should change their file format. So it makes sense that every system would have its own file format.

 

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

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...