turn OS-B carts into XL/XE carts, please...

[Atari_Ace]

OK, I took a look at Slime.  Like Protector II, it uses PMBASE of 0 so page 3 is being used for missile data, which causes the GINTLK cart pull detection code to run.  I relocated PMBASE to $38xx like I did in Protector II to fix this issue (44 different locations in the code as best as I can determine).

 

The other problem is that the timer routine specified by CDTMA1 at $B797 uses RTI instead of RTS.  I believe this was a bug in several Synapse games that made them crash on the XL/XE.  To fix this, I patched the end of the routine (at $B7AE) to JMP to $BFF0, where I could place the correct epilog of PLA/TAX/PLA/RTS.

 

Attached is the patched cartridge, which appears to work in Altirra.

slimehack2.car

[Atari_Ace]

One more for today.  K-Star Patrol starts out with the same page 2 initialization code as Protector II, namely:

A2D4: A2 25             LDX #$25
A2D6: BD 80 E4          LDA VCTABL,X
A2D9: 9D 00 02          STA VDSLST,X
A2DC: CA                DEX
A2DD: 10 F7             BPL $A2D6

Unfortunately you can't skip this like in Protector II, as some needed vectors are only set up here.

 

To fix this, I decided to place a compatible table in the cart itself, but there isn't enough space left in the cart to fit a $26 byte table.  In the end I concluded I could get away with a $10 byte table, covering $216 to $225, which I located at $BFE0.  I set VIMIRQ ($216) to $AB6D (PLA, RTI), and VVBLKI and VVBLKD to SYSVBV and XITVBV.

 

With those changes you can start and play the game on an XL/XE in Altirra.  So that might be all that's needed.

kstarpatrol1.car

[FULS]

Thanks for doing all these.

If you press SELECT and put in # of players in K-Star Patrol it seems to lock-up.

[Atari_Ace]

 

13 minutes ago, FULS said:

Thanks for doing all these.

If you press SELECT and put in # of players in K-Star Patrol it seems to lock-up.

Well, I didn't set up the keyboard interrupt vectors, so boom!

 

Which got me thinking, why did skipping this code work in Protector II, but not here.  It's because K-Star Patrol is marked as a diagnostic cart, so it skips OS initialization.  If I change $BFFD from $80 to $04, the O/S will fill in the table and I can just NOP the STA here, which is a simpler fix (only 4 bytes).  So here's another go...

kstarpatrol2.car

[Atari_Ace]

The same fix appears to work for K-Razy Kritters as well.  I refined the approach it slightly to switch the STA to LDA instead of a NOP, so this is now a 2 byte change.

krazykritters1.car kstarpatrol3.car

[Atari_Ace]

OK, next in the series is Picnic Paranoia.

 

When looking at why a cart doesn't work, the first thing I do is dump the last three words of the cartridge, which are the cartridge start address, option flags, and initialization address.  This lets me know where I should start disassembling the code, since I usually want at least a partial disassembly of the cart to guide my debugging.  For Picnic Paranoia, I found this.

BFFA: 43 4D             .WORD $4D43
BFFC: 50 81             .WORD $8150
BFFE: 23 31             .WORD $3123

That's garbage.  If you hex dump the end of the cart you'll see why this is garbage.

  bf60  00 00 00 00 00 00 00 00-00 00 12 0a 00 3b 53 41   .............;SA
  bf70  56 22 44 3a 4d 4f 52 2e-53 59 4e 00 13 14 00 53   V"D:MOR.SYN....S
  bf80  51 53 48 83 4c 44 41 81-43 4f 4e 53 4f 4c 00 0b   QSH.LDA.CONSOL..
  bf90  1e 00 87 43 4d 50 81 23-36 00 0c 28 00 87 42 4e   ...CMP.#6..(..BN
  bfa0  45 81 2e 37 33 00 0f 32-00 87 4a 4d 50 81 4e 45   E..73..2..JMP.NE
  bfb0  57 47 41 4d 00 0f 3c 00-2e 37 33 84 4c 44 41 81   WGAM..<..73.LDA.
  bfc0  37 35 33 00 0e 46 00 87-42 45 51 81 53 51 2e 37   753..F..BEQ.SQ.7
  bfd0  34 00 0c 50 00 87 4c 44-41 81 37 36 34 00 0c 5a   4..P..LDA.764..Z
  bfe0  00 87 43 4d 50 81 23 33-33 00 0c 64 00 87 42 45   ..CMP.#33..d..BE
  bff0  51 81 2e 34 33 00 0c 6e-00 87 43 4d 50 81 23 31   Q..43..n..CMP.#1

So it looks like the end of the cartridge is some leftover memory fragments from the assembler (SynAssembler it seems).  Perhaps at the end of development they just copied 16K into the ROM, and forgot to modify the last six bytes.  The cart started up on the old OS quite by accident, and that's how it got shipped.

 

The last six bytes need to be fixed so the cartridge can initialize correctly.

 

I looked though an XEX version and concluded from that that the cartridge start address should be $9500.  I set the option flags to $0400 as usual, and hunted around for an RTS to use for the initialization routine ($84C3, but anyone would do). Changing those six bytes and the cart starts up on the XL/XE.  I haven't looked further, so there may still be other issues, but I suspect this is the only problem.

picnicparanoia1.car

[_The Doctor__]

On 7/28/2020 at 9:18 AM, Mclaneinc said:

 

Studio X ?

 

Tried looking for such a program but no joy..

the post doesn't really apply any more and doesn't matter, as indicated later, using any of the maxflash or other cart software with translations or soft OS wedged in doesn't get the job done as with a full crack or patch... that's why the later post came about

 

[_The Doctor__]

This is good stuff, getting the carts into a state usable by the entire line and all devices is a wonderful and welcome turn of events. Thank You!

[FULS]

3 hours ago, Atari_Ace said:

 

The last six bytes need to be fixed so the cartridge can initialize correctly.

 

I looked though an XEX version and concluded from that that the cartridge start address should be $9500.  I set the option flags to $0400 as usual, and hunted around for an RTS to use for the initialization routine ($84C3, but anyone would do). Changing those six bytes and the cart starts up on the XL/XE.  I haven't looked further, so there may still be other issues, but I suspect this is the only problem.

picnicparanoia1.car 16.02 kB · 5 downloads

The last 6 bytes are located at 9FFA or in a Hex Editor at location 8191.

They are  00 95 00 04 FE A0. If I recall correctly, on the 800 OS looks at 9FFA location first then at BFFA.

The reason is the 800 has a right Cartridge port. Monkey Wrench in the right slot initializes before the Basic Cart in the left slot.

Very interesting find. Nice catch Atari_Ace.

[Atari_Ace]

32 minutes ago, FULS said:

The last 6 bytes are located at 9FFA or in a Hex Editor at location 8191.

They are  00 95 00 04 FE A0. If I recall correctly, on the 800 OS looks at 9FFA location first then at BFFA.

The reason is the 800 has a right Cartridge port. Monkey Wrench in the right slot initializes before the Basic Cart in the left slot.

Very interesting find. Nice catch Atari_Ace.

I forgot about the 2nd cart code, thanks for reminding me and verifying the $9500 cold start address.

[Atari_Ace]

Today I took a look at Speedway Blast.  On the XL/XE, it triggers the cart pull logic due to this bit of code.

A6B0: A2 00             LDX #0
A6B2: BD 00 20          LDA $2000,X
A6B5: 9D 00 03          STA $0300,X
A6B8: E8                INX
A6B9: D0 F7             BNE $A6B2

At first, I couldn't find any usage of page 3, so I tried skipping this code, but I noticed graphical glitches right away.  Eventually with a little debugging I determined there was a routine at $B54B that copied bytes with a set of tables for the source, destination and number of bytes.  Two of the tables looked like this:

B537: 00 03             .WORD $0300
B539: 00 10             .WORD $1000
B53B: 2A                .BYTE $2A

B53C: 00 03             .WORD $0300
B53E: 00 20             .WORD $2000
B540: FF                .BYTE $FF
...

So near as I can determine those are the only 3 places that cause the cartridge to read/write from page 3.

 

The simplest fix is to find another page to use.  I think page $12 and $3E are unused, so I've changed $03 to $12 in the three locations in the ROM.  The game seems largely playable with this change, but I'm not sure this is working correctly or not so there might be other changes to be made.  Anyhow, here's a fix to try for the XL/XE.

speedway1.car

[Atari_Ace]

OK, I took a look at Danger Ranger.  It crashes because the code writes to $FE to PORTB, disabling the ROM.  This specific value suggests this was deliberate, but it didn't copy the OS to RAM first.  One fix is to change the $FE to $FF in the two places it does this.  With that change, the cart starts up and seems to work, but I didn't test it extensively.

dangerranger1.car

[jefffulton]

To all the rockstars on this thread who are creating .car files for use on real XL/XE hardware, i salute you! 

[Wrathchild]

3 hours ago, jefffulton said:

To all the rockstars on this thread who are creating .car files for use on real XL/XE hardware, i salute you!

Whilst the sentiment is agreed with, lets be clear here that the .car images are the basis for people replacing the PROMs on existing cartridge boards so that they can be played on XL/XE based h/w.

They could indeed be placed on a modern cart such as The!Cart, AVGCart and UNO/Ultimate cart and run on those, these are titles that already had xex/atr versions patched to play equally as well on XL/XE machines.

 

So whilst the target audience is limited, kudos to @Atari_Ace for enjoying and sharing the journey! 

Edited August 3, 2020 by Wrathchild

[jefffulton]

25 minutes ago, Wrathchild said:

Whilst the sentiment is agreed with, lets be clear here that the .car images are the basis for people replacing the PROMs on existing cartridge boards so that they can be played on XL/XE based h/w.

They could indeed be placed on a modern cart such as The!Cart, AVGCart and UNO/Ultimate cart and run on those, these are titles that already had xex/atr versions patched to play equally as well on XL/XE machines.

 

So whilst the target audience is limited, kudos to @Atari_Ace for enjoying and sharing the journey! 

There is a new project up on atariprojects.com to do just that...: 
http://atariprojects.org/2020/08/02/make-an-atari-8-bit-computer-cartridge-1-2-hours/

 

[FULS]

Great thread.

Are Gorf and Seafox the only ones left to be fixed?

Are these possible to fix?

 

Thanks for all your work.

 

[Atari_Ace]

18 hours ago, FULS said:

Great thread.

Are Gorf and Seafox the only ones left to be fixed?

Are these possible to fix?

 

Thanks for all your work.

 

Gorf is a ~12k image compressed into an 8k cart which decompresses and runs from RAM, so any small patch to the code is likely to change most of the ROM data, so I stopped there.  It's possible a small patch could be developed, but more likely the patch will look like a completely different ROM.

 

I couldn't quite work out what was wrong with Seafox, it seems to play fine in Altirra.  I saw some comments not being able to fire horizontally but I didn't have that problem.  I did an initial disassembly but didn't notice any obvious OS-B only code.  I'm willing to look further if someone can clue me in to the problems and how to reproduce them.

[Bobo Cujo]

24 minutes ago, Atari_Ace said:

Gorf is a ~12k image compressed into an 8k cart which decompresses and runs from RAM, so any small patch to the code is likely to change most of the ROM data, so I stopped there.  It's possible a small patch could be developed, but more likely the patch will look like a completely different ROM.

 

I couldn't quite work out what was wrong with Seafox, it seems to play fine in Altirra.  I saw some comments not being able to fire horizontally but I didn't have that problem.  I did an initial disassembly but didn't notice any obvious OS-B only code.  I'm willing to look further if someone can clue me in to the problems and how to reproduce them.

There are apparently two versions of Seafox floating around.

 

The cartridge image allows you to shoot up and forward, but only one projectile at a time per direction (matching the original Apple II version).  It also uses more of the built in atari fonts.

 

The .xex file (found on homesoft and elsewhere) instead only allows shooting upward, but allows up to three projectiles at once.

 

Having recently hacked the former version for 2 button joystick support, I can definitively say that those differences have nothing to do with 400/800/xl/xe differences...

[FULS]

Yes you are right about Seafox. I put my cart of Seafox into my 130xe and it ran fine.

Press the button fast for shot to the surface, Press button longer for shot to the right.

The disk version is different like you said, three projectiles to the surface only.

So I think the cart Seafox should be taken off the OsB only list.

 

So only Gorf is left and that one might not be solvable in an 8k cart.

[Atari_Ace]

23 minutes ago, FULS said:

So only Gorf is left and that one might not be solvable in an 8k cart.

The Gorf cartridge uses a PMBASE of 0, so page 3 gets cleared and the cart pull logic triggers.  In principle I can find all those accesses and update them to another PMBASE.  The problem is there's no room on the cart left to place that patch, so I will have to reverse engineer the compression algorithm and restream the image onto the cart with the updates applied.

 

I could make a 16K cart version though without changing the decompression code, maybe I'll start with that.

 

 

[+Allan]

Interesting. I just downloaded the cart and ATR of Seafox from Atarimania and tried the cart version Atari800MacX emulator and it works with the 400/400 roms but not the XL/XE roms. The cart just freezes with the XL/XE roms. I will have to try it on a real Atari when I get a chance.

[Bobo Cujo]

The cart image (via Ultimate Cart) definitely works without issues on my real NTSC Atari 800XL ?

[FULS]

Have the Astro Chase carts been fixed?

Parker Brothers only works on OsB.

First Star only works on XL/XE.

 

Astro Chase (1982) (Parker Brothers)(Osb).bin

Astro Chase (1982)(First Star Software)(XL_XE Only).bin

[Wilheim]

On 9/17/2020 at 9:31 PM, Atari_Ace said:

The Gorf cartridge uses a PMBASE of 0, so page 3 gets cleared and the cart pull logic triggers.  In principle I can find all those accesses and update them to another PMBASE.  The problem is there's no room on the cart left to place that patch, so I will have to reverse engineer the compression algorithm and restream the image onto the cart with the updates applied.

 

I could make a 16K cart version though without changing the decompression code, maybe I'll start with that.

 

 

Maybe you can add an inmediate vertical blank interrupt that refresh GINTLK with TRIG3 every frame. That way, you can avoid a cartridge pull hang up.

[FULS]

Also, besides fixing the Astro Chase Carts, is there a Monster Maze cart that works on the OsB and XL machines.

 

 

Monster Maze (1982)(Epyx)(OsB).bin

 

Monster Maze (1982)(Epyx)(XL_XE).bin

 

Thanks