Jump to content
IGNORED

Creating a cartridge from XB compiled program?


1980gamer

Recommended Posts

Is it possible to create a cartridge from a program complied using Harry Wilhelms' XB Compiler v2.1?

 

I am looking to turn my "pac man" into a cart, for a Christmas gift to me!

 

If anyone can do this and let me know what it would cost? That would be great!

 

If it is cheap enough, I would like a few to give away randomly to people that have helped me through this project.

 

Thanks in advance for the help!

Gene

 

 

  • Like 1
Link to comment
Share on other sites

Harry can speak better than me, but my thinking is that you'd use a "copy" cartridge - that is, a cartridge that copies the program from ROM to RAM before starting. The net effect from the user's point of view is it's a cartridge, from the machine's point of view it's the same as loading it from disk! The one drawback is that the cartridge will require 32k RAM to run. If that's okay, it's pretty straightforward to build.

 

To run without the 32k will probably not be possible with the current compiler...?

  • Like 1
Link to comment
Share on other sites

Tursi is right on the money here, though being straightforward to build is in the eye of the beholder. To run without the 32K means using 8K banks of ROM at >6000. Mirror maze would require 3 banks and the compiler would have to be rewritten to deal with the necessary bank switching. That's beyond my payscale.....

Link to comment
Share on other sites

Harry can speak better than me, but my thinking is that you'd use a "copy" cartridge - that is, a cartridge that copies the program from ROM to RAM before starting. The net effect from the user's point of view is it's a cartridge, from the machine's point of view it's the same as loading it from disk! The one drawback is that the cartridge will require 32k RAM to run. If that's okay, it's pretty straightforward to build.

 

Tursi, do you have general high level instructions on how one would go about creating this "copy" cartridge?

Link to comment
Share on other sites

Hmmm, sounds like a long shot :(

 

Do any cart designs include onboard ram? That is, would it be possible to put the ram on the cart, so no expansion to the TI would be needed?

Well, I guess mini-memory would be a case where memory was added??

 

But I was thinking a game like Intellivisions Chess has a 2k ram chip on the cart to help speed up and hold variables in memory.

 

Would it be worth designing this? I have 3 or 4 things in the works that could use this!

 

Actually, any XB game that uses sprite collision detection can use the compiler to make that weekness go away! I use sound to slow the execution

of the games where they run to fast.

 

Anyway, having a game on cart was a dream since I was 11 years old. But I guess it may have to stay a dream.

Gene

Link to comment
Share on other sites

The MiniMemory offers 4K from >7000 - >7FFF, no bank switching. The SuperSpace modules have 8K or 32K RAM in cartridge space >6000 - >7FFF, with the 32K version using CRU-based bank switching.

 

You run into the same problem moving compiled XB programs from 32K RAM (>2000 - >3FFF, and >A000 to >FFFF) into the cartridge space, irrespective of the bank switching employed. That said, there are instructions on Mainbyte on making your own "SuperSpace" type module, or there have been some up on eBay recently (I picked up a 32K unit.) There is an 8K unit (which can be upgraded to 32K with the right chip and some jumpers) which is priced way too high, though the seller is accepting offers.

Link to comment
Share on other sites

Tursi, do you have general high level instructions on how one would go about creating this "copy" cartridge?

 

Started this before work, but didn't have time to finish - I'll finish the write-up after work -- assuming the compiler doesn't require the XB cartridge to be in place to run?

 

So far as a cartrdidge with RAM for data storage goes, it is of course possible any number of ways, but you can also ask yourself what the goal is. 90% of needs can be met storing the data in VDP memory, only code /must/ live in CPU memory, and code rarely needs to be in /RAM/ specifically. The VDP memory is only slower than CPU memory when you need to change the address, so if you can arrange your data so that it is arranged in the order you need it, you can be very close to CPU memory performance on your variables. The worst case is 30% the speed of CPU memory, which is still not bad if you don't need it too often (compare the overhead of data access to how much time you spend NOT accessing data).

Link to comment
Share on other sites

Ah! Well, I'm starting with the XB version.. the EA#5 version would be easier to convert.

 

I did hit a snag, though. In the program startup, it branches to a utility at >205A that looks like this:

 

   205A  C060  mov  @>2004,R1              (34)
         2004
   205E  0281  ci   R1,>4000               (22)
         4000
   2062  130E  jeq  >2080                  (14)
   2080  0200  li   R0,>2500               (20)
         2500
   2084  C800  mov  R0,@>8322              (30)
         8322
   2088  02E0  lwpi >83e0                  (18)
         83E0
   208C  0460  b    @>00ce                 (24)
>00CE, which it branches to at the end, is one of the entry points into the GPL interpreter. I'm not sure if this is a GPLLNK function or not, but it crashes shortly thereafter, having no way to return to the caller.

 

In this particular program, I skipped over that jump and went to the next one, which jumped into the game, and it appeared to work, but I don't know what that call was supposed to do. :) Doing this is probably more than I can easily explain how to do.. it just takes practice.

 

So.. ignoring that one hack, here is the procedure I followed, which you can more or less adapt to any program. (Again, it's much easier if you wrote it and know what it needs :) ).

 

For the software side, Classic99 makes it simple:

 

-The first thing to do is to get it into memory and breakpoint at the start address - so open the debugger with Edit->Debugger and make sure that Scroll Lock is on on your keyboard.

 

-I downloaded PacMan to have a look, and it's an XB program which launches embedded assembly.

 

10 CALL INIT :: CALL LOAD(8192,162,030):: CALL LINK("RUN")
The CALL LOAD seems to set the start address for RUN - I have to admit I don't know what linkage this is, but all that we need to know right now is the assembly code starts at >A21E (162 = >A2, 30 = >1E). If you were doing your own assembly program, you probably already know the start address. :) In cases where you don't know the exact start address (but you know it's in the 24k memory bank), you could enter a range, like (A000-FFFF) to find it. I did that here. You will need the exact address later.

 

-Enter the start address (>A21E) as a breakpoint and click 'add'. Then start the program (in this case, enter 'run'. For EA, load and run as normal). It should breakpoint right away.

 

-In the debugger, select Make->Save Memory as Program. You need to know what memory ranges to save - it's okay, if wasteful, to save too much. Change the Save Type to 379 Bank-Switched Copy.

 

-We start with the full high RAM block, since we know that's all used. Check it and enter A000-FFFF.

 

-I learned by experimenting that the game needs utilities in low memory. By looking with the debugger, I could see that 2000-25ff was used, so that's easy. Check low memory and add that.

 

-Start address will default to the current PC, make sure it's right. (A21E)

 

-To determine VDP RAM, we need to load the XB tables. In the Classic99 debugger, we see the "PDT" is the pattern descriptor table, and loads at >0000. We know that the first active character in XB is character 30, and that XB adds >60 to all characters, so it's /really/ >7E. So the needed characters start at >0000 + >7E*8, which is >3F0. The last character defined in XB is 127, and so that's 128+>60=E0 -> >700. So for characters, we need from >3f0 to >700. This will cover sprite patterns too.

 

-To be sure, we also need the color table. That's 'CT' in the debugger, and starts at >0800, and is >20 bytes long. If your program sets all the colors yourself, you don't need it, of course, but we'll assume.

 

-So that gives a needed VDP range from >3F0 to >81F

 

-type a cartridge name (upper-case only!)

 

-Select Initialize Keyboard and Restore VDP Registers, you'll need them as well.

 

-Click build, and give it a filename. End the filename with "3.bin" and Classic99 will be able to open it with Cartridge->User->Open automatically.

 

-In this case, the cart created was 32k (24k of program, plus VDP data and the loader).

 

pacm3.zip

 

To make the cartridge with this file, you need to burn a 32k EPROM with it, and then get one of the Guidry 64k boards to install it on. (If you PM me, I can probably help you with that). As-is, though, you can open this cartridge directly in Classic99 with Cartridge->User->Open.

  • Like 2
Link to comment
Share on other sites

(I noticed after posting that with the patch I made, it doesn't need the utilities in low memory anymore, so that step probably wasn't needed. But since it didn't make the cartridge any bigger (sizes are 8k, 16k, 32k, 64k, etc, so it would have been 32k anyway) there's no need to redo it.

Link to comment
Share on other sites

Tursi, This is so cool.

 

Should the execution be faster? This is an older version, before I added joystick, before I re-wrote the ghost logic.

 

I was completely out of space, so I wrote a single ghost logic with a loop to save space.

 

I then had a ton of free space so I added joystick support, I also gave all for ghosts different speeds.

They also slow down 10% when pacman is in power up mode.

 

The ghost logic, each is attracted to pacman's x,y position, but they cannot reverse direction when at an intersection.

So, at any node, a ghost has Number of possible directions -1. It is random.

 

If a value is below a threshold, the ghost tries to go to pacmans position, over that value, the turn is random.

 

Wow, all that above was to say things changed and I think the new version runs slower?

But is it actually faster execution because it's a cart and things are in a different memory location?

 

Either way, it seems as though a cart is very possible!

 

I need to do a ton of testing now!

 

Thanks so much for the effort.

Gene

Link to comment
Share on other sites

Trying to get the cart image working in MESS 150, it starts ok but seems a little glitchy and the controls don't work properly, ok with Classic99 though.

I built an RPK for use with MESS with the following layout.xml file -

 

<?xml version="1.0" encoding="utf-8"?>
<romset version="1.0">
<resources>
<rom id="romimage1" file="PACM3.bin"/>
</resources>
<configuration>
<pcb type="paged379i">
<socket id="rom_socket" uses="romimage1"/>
</pcb>
</configuration>
</romset>

Any ideas what's wrong here?

Edited by OX.
Link to comment
Share on other sites

Well, if I converted an old version, maybe you guys should try the final version. ;) There should be no difference whether it loads from ROM or loads from disk.

 

1980gamer -- if you can post a link here to your final version, I'll convert it over as well (unless you want to try! :) )

Link to comment
Share on other sites

OK, Here is the latest version.

I play tested for a few hours.

I see one little bug, not bad and 1 Giant goof up... The goof is I do not reset all the variables when the game end.

Everything works, but Iif you are 6 or seven levels in when the game ends, the next game starts at the harder level.

 

This only happens because I have a hidden screen to change some variables.. Debug mode ( displays ghost 1's choices and the random values for him )

Attract variable, this is how attracted the ghost are to pacman

Number of ghosts, 1-4

Screen 1-3 but 4 would be 1 with invisable maze when on the backside or after the power up. Maze comes back when pacman powers down.

So 1-6 would be a better way to list this...

 

To get to the HIDDEN screen...Press anykey at start up on the left side of the keyboard...... Not really hidden... SHIFT 838 style....

 

In the zip.... A text version, an EA5 version and an XB compiled version.

 

I will look at the variables to see if it easy to move the initialization....and still let me change them. I am just a little tired...so it may be tomorrow.

 

Should I remove the debug/hidden stuff?

 

Oh, if you debug ( that is say yes to this question, you must press a key to advance the game, it is single step.... thus, debug mode! )

 

Gene

Link to comment
Share on other sites

A little easier to work with the E/A version :)

 

Look at the first file (PACMAN-A) in a hex editor, and the header shows FF FF 1F FA A6 A0

 

The FF FF is just a flag that says more files are coming.

The 1F FA is how many bytes are in this file.

The A6 A0 is where to load this file (it's also the start address, so we remember this one.)

 

Then look at the last file (PACMAN-C), and the header shows 00 00 19 53 E6 94

The 00 00 is a flag that means last file.

The 19 53 is how many bytes are in this file (we need this!)

The E6 94 is where to load this file (we need this too).

 

We add the size to the load address to get the last address: E694 + 1953 (windows calculator can do Hex in 'advanced' or 'programmer' mode) gives FFE7. The loader only copies words, so although the true last byte is FFE6, we need to round up to an odd address anyway.

 

So now we have the information we need for the debugger. Set a breakpoint at A6A0, then start Editor/Assembler and #5 run PACMAN-A. When it stops, select Make->Save Memory as Program in the debugger window.

 

-Change the Type to 379 Bank-Switched Copy

-enable High RAM and set the start address to A6A0, and the end address to FFE7

-the VDP character set and color table is set up for us, so we don't need to copy any VDP memory, load character set, or restore registers (you should initialize keyboard, though - it's only a couple of instructions and almost always wanted).

-Give it a cartridge name and save - I selected PACM3.BIN again. (End the name with 3.BIN and Classic99 can load it with Cartridge->User->Load).

-That's it! test loading in Classic99

 

pacm3.zip

Link to comment
Share on other sites

I would love to have this type of cartridge version for my Ultimate Planet program (when it eventually gets finished!). I am way too far into it to even dream about converting it to a regular banked version for a classic cartridge conversion, but a "copy cartridge" will work great for me. Tursi, you and I will have to talk more about this when the time comes (poor you) :)

  • Like 1
Link to comment
Share on other sites

OK

 

I have fixed the 2 problems I was seeing.

 

This needs a bunch of play testing. I will try to follow the very detailed steps from Tursi.

 

Hex Editor? Can I just use the old DOS Debug? I haven't done this type of thing since DOS 6.22 or I can google it ;)

 

Anyway... Here is the latest version. No known issues.... But, I am certain something will pop up the very next time I test!

 

Enjoy.

Gene

 

I also zip in PINV-C Just a started demo... I forgot to change the bullet color, so it is not seen, but heard at least! And the results are seen.

Very un-tested! But what do you think? keyboard controlled S-left D-right E-shoots.

DSK2.zip

Edited by 1980gamer
Link to comment
Share on other sites

Hi Tursi,

I was able to follow your instructions ( for the most part ) and create a cart!

 

However, I had to PAUSE the debugger to make it.

 

The instructions sound like the debug should hit the memory location and stop.

This never happend. I checked the values a few times. Anyway, it works, it starts I played thru 4 screens.

 

I had a moment when the screen changed to the default color, I could not see the sprites but could finish the maze as I only had 2 dots in the corner left!

 

Strange, The round ended and the screen worked for the next round.

 

Gene

Link to comment
Share on other sites

Hi Tursi,

I was able to follow your instructions ( for the most part ) and create a cart!

 

However, I had to PAUSE the debugger to make it.

 

The instructions sound like the debug should hit the memory location and stop.

This never happend. I checked the values a few times. Anyway, it works, it starts I played thru 4 screens.

 

I had a moment when the screen changed to the default color, I could not see the sprites but could finish the maze as I only had 2 dots in the corner left!

 

Strange, The round ended and the screen worked for the next round.

 

Gene

 

Yes, but for the debugger to interrupt, Scroll Lock on the keyboard must be active. I had forgotten to mention that - that is probably why it did not stop for you. Usually stopping it later will still work, unless the program modifies some of the saved data before that point.

 

Congratulations on your first cart! Now we just need to get you some PCBs so you can make a physical cart. :)

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