Jump to content
IGNORED

Setting up a 632k cart


Gazoo

Recommended Posts

The code is done as far as I can test it. As long as the GPL Move command for moving from CPU memory to CPU memory in the GPLmove example file is correct, everything should work correctly. In the attached zip file is the Rom file, a .dsk image of the Gramkracker format Grom files, and the jpg of the menu screen. The Grom files are named for the bank (or Grom base) that they should be loaded into. The cartridge is autostart, so the menu should come up without any user intervention other than pushing it into the cartridge slot.

 

Fingers crossed,

 

Gazoo

 

Edited by Gazoo
  • Like 3
Link to comment
Share on other sites

<File attachment removed>

 

The previous attachment was flawed, sorry :( . The GPL moves from CPU to CPU were all backwards in the Grom files.

It's been corrected, please delete the previous file if you've downloaded it and use this one instead.

 

Gazoo

Edited by Gazoo
  • Like 2
Link to comment
Share on other sites

Tested this in Classic99 - I had to invert the ROM banking (since Classic99 doesn't support non-inverted bank switching yet), but other than that everything worked fine. Looks like you got the ROM side just fine!

Edited by Tursi
Link to comment
Share on other sites

We can probably use the MultiCart software (with some defined data statements for the programs instead of the bank n read subroutine) to launch these same EA/5 programs, and put it in one of the first banks in place of the XB ROMs (for powerup), and have an uber EA/5 cartridge too, for those folks using 512K ROM-only carts.

 

I'll have to check out Tursi's source code for MultiCart to see if I can adapt it or not.

Link to comment
Share on other sites

Tested this in Classic99 - I had to invert the ROM banking (since Classic99 doesn't support non-inverted bank switching yet), but other than that everything worked fine. Looks like you got the ROM side just fine!

 

Thanks for testing. I found one little quirky thing when testing with my HSGPL. If you select Disk Manager 2, and select Disk Commands, attempting to catalog a disk will foul up VDP and give a garbage screen. However, if you first select File Commands, then press Back, then select Disk Commands, the catalog function works fine.

 

Would you mind checking that out?

I think it might have something to do with a VDP register setting, or I'm not clearing or setting something that Grom0 does.

 

Gazoo

  • Like 1
Link to comment
Share on other sites

Thanks for testing. I found one little quirky thing when testing with my HSGPL. If you select Disk Manager 2, and select Disk Commands, attempting to catalog a disk will foul up VDP and give a garbage screen. However, if you first select File Commands, then press Back, then select Disk Commands, the catalog function works fine.

Would you mind checking that out?

I think it might have something to do with a VDP register setting, or I'm not clearing or setting something that Grom0 does.

Reproduced on Classic99.

 

I don't see any differences in the VDP registers, oddly. I compared memory dumps at the main menu on cold start and after selecting File Commands then pressing Back - there were fortunately only a few differences (2 in VDP and a handful in scratchpad). I went through them starting with the VDP ones to reproduce the 'success' case without the workaround, just to see what the trigger was... it was neither of the VDP cases (but there is a potential bug! When you hit back from the FILE COMMANDS menu, the code that clears the screen clears one line too many. This actually overwrites the sprite table at >300 with >20 bytes (it's originally initialized with a >D0 byte to disable sprites). I don't see any side effects from it, but if you are patching anyway, it's probably a MOVE instruction somewhere around GROM address >3230...?? (I don't have my GPL references at work! It's in the interpreter at CPU address >06CA anyway.)

 

Looking at the scratchpad diff, there was only one changed value that wasn't constantly updating - >8372. It's >00 on entry and >9E after pressing back on the FILE menu. Setting it to >9E manually via the debugger makes the catalog function work... I can't trace why at the moment - but if you patch that initialization value my testing here suggests that will do the trick!

Link to comment
Share on other sites

>8372 is the Data Stack pointer and I can't imagine it should ever be 0 if you're doing anything with GPL. The data stack is at >83A0, so the initial value of the byte at >8372 usually "points" to the word address before that, viz., >9E (for >839E), i.e., the data stack is empty.

 

...lee

  • Like 1
Link to comment
Share on other sites

Reproduced on Classic99.

 

I don't see any differences in the VDP registers, oddly. I compared memory dumps at the main menu on cold start and after selecting File Commands then pressing Back - there were fortunately only a few differences (2 in VDP and a handful in scratchpad). I went through them starting with the VDP ones to reproduce the 'success' case without the workaround, just to see what the trigger was... it was neither of the VDP cases (but there is a potential bug! When you hit back from the FILE COMMANDS menu, the code that clears the screen clears one line too many. This actually overwrites the sprite table at >300 with >20 bytes (it's originally initialized with a >D0 byte to disable sprites). I don't see any side effects from it, but if you are patching anyway, it's probably a MOVE instruction somewhere around GROM address >3230...?? (I don't have my GPL references at work! It's in the interpreter at CPU address >06CA anyway.)

 

Looking at the scratchpad diff, there was only one changed value that wasn't constantly updating - >8372. It's >00 on entry and >9E after pressing back on the FILE menu. Setting it to >9E manually via the debugger makes the catalog function work... I can't trace why at the moment - but if you patch that initialization value my testing here suggests that will do the trick!

 

Yes, it did the trick. Thank you!

 

Why does it work? I don't know.

Do I really care why it works? No.

I just care that it works. :-D

 

Corrected file is attached. As before, delete the old one. Hopefully for the last time. :)

 

[deleted attachment=337187:632kCart.zip]

 

Gazoo

Edited by Gazoo
  • Like 1
Link to comment
Share on other sites

We can probably use the MultiCart software (with some defined data statements for the programs instead of the bank n read subroutine) to launch these same EA/5 programs, and put it in one of the first banks in place of the XB ROMs (for powerup), and have an uber EA/5 cartridge too, for those folks using 512K ROM-only carts.

 

I'll have to check out Tursi's source code for MultiCart to see if I can adapt it or not.

 

It might be better to start from scratch. A menu program could be created in Rom similar to the one that I created in Grom. The catch is that the bank and move code would have to be moved into scratchpad for execution upon a selection being made, as the combined memory usage of all the programs take up most of the 32k memory space. However there's a little space left at the top of low memory that none of them use, if scratchpad isn't enough.

 

I'd be willing to give it a shot if you'd like.

 

Gazoo

Link to comment
Share on other sites

 

It might be better to start from scratch. A menu program could be created in Rom similar to the one that I created in Grom. The catch is that the bank and move code would have to be moved into scratchpad for execution upon a selection being made, as the combined memory usage of all the programs take up most of the 32k memory space. However there's a little space left at the top of low memory that none of them use, if scratchpad isn't enough.

 

I'd be willing to give it a shot if you'd like.

 

Gazoo

 

We can... but I kind of like Tursi's font, title, joystick selection, etc, in MultiCart. :) Tursi did use scratchpad and some creative engineering to get it to bank switch and then reset the console (and thus, you saw the selection on the cart screen.) We'd just have to figure out if we could add the copy to 32K functionality in the same constraints, like you mentioned.

 

Tursi, is that on Harmless Lion somewhere? Or do you mind me attaching that to this thread (the source zip)?

Link to comment
Share on other sites

I should add... without looking at the code again, it should be fine loading to the whole 32k, because it runs from cart space, and the copy loop itself is in scratchpad for performance.

 

Heck, I'll post it here too (though I think it has a thread), just to ensure the latest version is out there (this is the one that also scans GROM).

 

Multicart.zip

Link to comment
Share on other sites

Several bugs have been corrected regarding loading code for menu items and the annoying beep that went on too long.

Here's the fully tested files.

 

[deleted attachment=337911:632kCart.zip]

 

Gazoo

 

 

 

Edited by Gazoo
  • Like 1
Link to comment
Share on other sites

Put fixes in place as in 512k cart. Keyunit changed to 5 before starting selected menu program and Disk Fixer background color changed to dark blue.

 

[deleted attachment=339036:632kCart.zip]

 

Gazoo

Edited by Gazoo
  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

Well if RXB is not going to be included at least use my REA 2012 that has both GPL Assembler and EA Assembler built into a single EA Cart slot and resides in any GROM area.

 

REA 2012 kicks the crap out of anyone else's version of the EA Cart as hit has a built in Catloger and loader for everything. I even have a SAMS version that works with the SAMS.

 

 

If someone has a better one I will upgrade REA 2012 to smoke it.

  • Like 3
Link to comment
Share on other sites

Rich--it will get onto one of the ÜberGROM images soon--but probably not before we get the menu-driven loader done. I want to make sure I get your RXB and Winkler's XB3 onto ÜberGROMs o that both of them become more available to the community. Tony's XB 2.7 is already on an image, so that pretty much covers the three most recent versions of XB out there--all three of which had very limited distribution in the past due to their reliance on GRAM devices (for the most part, as a very small nimber of XB3 cartridges exist).

Link to comment
Share on other sites

Well if RXB is not going to be included at least use my REA 2012 that has both GPL Assembler and EA Assembler built into a single EA Cart slot and resides in any GROM area.

 

REA 2012 kicks the crap out of anyone else's version of the EA Cart as hit has a built in Catloger and loader for everything. I even have a SAMS version that works with the SAMS.

 

<snip>

 

If someone has a better one I will upgrade REA 2012 to smoke it.

 

Rich, where exactly does "Well if RXB is not going to be included" come from? What is being discussed and file images created for is the combination ROM/GROM cart that has recently been built. One particular set of files has been created so far, by me. I don't believe anyone ever said that was the only set of files that was allowed to be created.

 

The specs of the cart are available. The file format is defined. Why don't you put together a set of files for the cart? All you need is a hex editor to create it. You seem to be a fairly intelligent guy as you can create and compile source code for the TI. All you have to do is put that in the format for this cart. Instead of whining that nobody's doing it for you, why don't you just do it yourself. It's actually not that difficult.

 

Gazoo

Edited by Gazoo
Link to comment
Share on other sites

RXB uses the same ROMs as GKXB so is your XB2.7 using the same GKXB ROMs?

 

If so then no need for RXB ROMs as they are the same.

 

Also from the config files you posted I do not see your GROMs for XB2.7 so where would I put the RXB GROM files as I do not see yours there?

 

By the way how am I whining when you said no more room for RXB? I only suggested REA as a alternate. Could you be a little less hostile please?

Link to comment
Share on other sites

RXB said:

"RXB uses the same ROMs as GKXB so is your XB2.7 using the same RXB uses the same ROMs as GKXB so is your XB2.7 using the same GKXB ROMs?


I would assume they're the same. If the TI XB roms are the same as the GKXB Roms then the answer is yes.


RXB said:
"If so then no need for RXB ROMs as they are the same."

OK.

RXB said:
"Also from the config files you posted I do not see your GROMs for XB2.7 so where would I put the RXB GROM files as I do not see yours there?"

The XB v2.7 Groms are in the .dsk file. Filenames are '9800G', '9800G1', '9800G2', '9800G3', and '9800G4'. When you create the files for your cart, you can call them anything that you want. You have 120k of Grom space, arrange it however you want to.


RXB said:
"By the way how am I whining when you said no more room for RXB?"


I never said anything like that. Please do not put words in my mouth. You said "Well if RXB is not going to be included...(yadda,yadda,yadda)". That's whining as I see it. If you want to put RXB in the Ubergrom cart, you have every right to do so, nobody's stopping you. Post the files you want in the cart, and I'll bet someone will make one. And I'll bet some people will buy it, too. As I'll bet someone will buy the XB v2.7 cart and utility programs that I've posted the files for.



RXB said:
"I only suggested REA as a alternate."


As an alternate to what? Please explain.


RXB said:
Could you be a little less hostile please?"


I'm not being hostile. You are complaining about RXB not being included in something, but none of us have any idea of what it is not being included "IN". If you want it to be in a version of the Ubergrom cart, look at the specs of the cart and the file layout. Then provide the files. As I mentioned, you can do it all with a hex editor. It should take you all of a few minutes, as you've probably already got the Grom files in the proper format and just need to create the '.bin' file.


Gazoo

Edited by Gazoo
Link to comment
Share on other sites

Though Rich is voicing his disquiet here, it may be a very good idea to document the entire manual process of creating a GROM file for the UberGROM cartridge. There are a lot of less capable folks than you out there, Gazoo--and having a path to follow may actually get them thinking about what to put into their own UberGROM. I've had several back-channel requests for a how-to guide more detailed than what is already in the manual, and I'm not able to provide them a better answer than to direct them to this thread--which has a lot, but it is scattered amongst a lot of posts right now, so it is a bit daunting.

 

Many thanks for all you've done so far, as each of your files significantly increases the use case for the cartridge :) I just got half a dozen Atmel 1284s in the mail today (and my AVR programmer arrived from Ukraine a week ago), so I'm going to load one with Tursi's current test code to see what I can see. I'm not so much of a software geek, so that may not be much, but I will look at it.

 

I'll add the process to the manual too if you do put it up (for what you've done with both sides of the cartridge), assuming you give me permission to do so. :)

Link to comment
Share on other sites

<snip>

 

I'll add the process to the manual too if you do put it up (for what you've done with both sides of the cartridge), assuming you give me permission to do so. :)

 

No permission needed other than the beer-ware license. :-D

 

Gazoo

Link to comment
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.
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...