Remaining OS-B games still not fixed to be XL friendly?

[Xuel]

Here is a nifty game menu with Fuji symbol that I've patched for XL/XE OS per ACML's request:

fujimenu.zip

Changes:

• Moved loader from print buffer, $3C0, to cassette buffer, $3FD, so it doesn't conflict with new XL/XE vectors
• Fixed loader handling of INIT segments (Multi-part executables like Ridiculous Reality and X:8 should now work)
• Shortened "LOADING" message to fit within new constraints
• Got rid of memory clearing routine to save space (Clearing memory before loading shouldn't be necessary)

Description from ACML:

My all time favorite DOS menu loader I had back in the early 80's. It needs to be on a DOS 2.0/MYDOS disk. It will create an Atari Fuji animated logo and create a menu of any "locked" file on the disk. It looks great, but it won't run on an XL OS. It only runs on the OSB or Omniview OSs. Do you think you could look at it and see if it is a simple fix to allow it to be compatible on an XL OS?

[Rybags]

It'd be handy if Atarimania had a section dedicated to "OS fixed" games.

No doubt these games have probably been fixed many times but archive sites generally have near to original as possible copies.

 

Also it applies the other way around, there's the odd game that won't work on 400/800 and it's only the OS difference, not RAM that's the problem.

[ACML]

I wanted to thank Xuel, xxl and Rybags for fixing some classic titles and making them easily executable on XL operating systems. It's certainly gotten to the point that there are many more titles that won't run on a 400/800. Over 30 years, the roles have reversed. The incompatibility of the 1200XL (Rev 10 OS) was the primary reason the 1200XL became an "Edsel". For those not familiar with American idioms, the Edsel (named after one of Henry Ford's sons) was Henry's flop of a car that sold miserably and was pulled from production quickly. I was there, 1983, when word spread of many games not working on the 1200XL. My brother and I rushed out and bought 800s before they were gone (I had a 32K 400 with an 800 style keyboard). For many years, most XL owners added the OS-B operating system on their 1200XL and 600/800XLs to avoid the "translator" disk. Some even just put the OS-B in outright to simplify the compatibility problem. No one was making games that required more than 48K back then.

 

Anyway, the list has dwindled to just a handful. The ones I don't have XL friendly version for are;

 

1) Acrobat

2) Dark Star

3) Final Flight

4) Run for the Money (ATR works, but XEX requires OS-B)

5) (Dual player) Star Raiders like prototype. Not sure this one is fixable as it may have used a null modem cable on joystick ports 3 or 4 to link up two 400/800s.

Edited June 17, 2014 by ACML

[Xuel]

Acrobat:

 

acrobat.zip

• Based on Atarimania XEX
• Moved PRNBUF code to CASBUF
• Fixed BRK due to bad copy routine
• Fixed calls to illegal OS entry points
• Fixed uninitialized PM graphics at start

[Xuel]

Dark Star:

 

darkstar.zip

• Based on XEX from Atarimania
• Moved code from PRNBUF to CASBUF
• Fixed calls to XITVBV

[ACML]

I wanted to thank Xuel, xxl and Rybags for fixing some classic titles and making them easily executable on XL operating systems. It's certainly gotten to the point that there are many more titles that won't run on a 400/800. Over 30 years, the roles have reversed. The incompatibility of the 1200XL (Rev 10 OS) was the primary reason the 1200XL became an "Edsel". For those not familiar with American idioms, the Edsel (named after one of Henry Ford's sons) was Henry's flop of a car that sold miserably and was pulled from production quickly. I was there, 1983, when word spread of many games not working on the 1200XL. My brother and I rushed out and bought 800s before they were gone (I had a 32K 400 with an 800 style keyboard). For many years, most XL owners added the OS-B operating system on their 1200XL and 600/800XLs to avoid the "translator" disk. Some even just put the OS-B in outright to simplify the compatibility problem. No one was making games that required more than 48K back then.

 

Anyway, the list has dwindled to just a handful. The ones I don't have XL friendly version for are;

 

1) Acrobat

2) Dark Star

3) Final Flight

4) Run for the Money (ATR works, but XEX requires OS-B)

5) (Dual player) Star Raiders like prototype. Not sure this one is fixable as it may have used a null modem cable on joystick ports 3 or 4 to link up two 400/800s.

The dual player Star Raiders like prototype is probably not easily accessible. I found this in a San Diego user group meeting in 1984. I contacted Doug Neubauer, author of Atari's Star Raiders, and he said he did not code this variant. I believe Rybags has taken an initial look at this and he mentioned that it may call Port B (joys 3 & 4). If so, a null modem cable was used in port 3 or 4 to connect the two computers in dual head to head mode. Solo mode appears to work, its just dual that crashes on an XL. If it does use joy port 3 or 4, maybe it could be changed to use port 2.

Star Raiders Dual (ATARI) OS-B.XEX

Edited June 18, 2014 by ACML

[ACML]

Here is a nifty game menu with Fuji symbol that I've patched for XL/XE OS per ACML's request:

 

fujimenu.zip

 

Changes:

• Moved loader from print buffer, $3C0, to cassette buffer, $3FD, so it doesn't conflict with new XL/XE vectors
• Fixed loader handling of INIT segments (Multi-part executables like Ridiculous Reality and X:8 should now work)
• Shortened "LOADING" message to fit within new constraints
• Got rid of memory clearing routine to save space (Clearing memory before loading shouldn't be necessary)

Description from ACML:

 

I added a modified title;

Atari Fuji Menu loader Atari Home Computers.XEX

[tschak909]

This has turned out to be a _very_ productive thread. Makes me smile. Seriously.

 

-Thom

[Xuel]

Final Flight:

 

finalflight.zip

• Based on XEX at Atarimania
• Replaced calls to illegal OS entry points with new code

The new plot pixel routine is faster than the OS version so it has an artificial delay loop to match the OS performance. I included another executable without the delay for comparison.

 

 

Edited June 21, 2014 by Xuel

[ACML]

Final Flight:

 

finalflight.zip

• Based on XEX at Atarimania
• Replaced calls to illegal OS entry points with new code

The new plot pixel routine is faster than the OS version so it has an artificial delay loop to match the OS performance. I included another executable without the delay for comparison.

 

 

Thanks Xuel! Which XEX has the delay (fast plot or regular)?

[+Philsan]

On my game selection I have three game that need Atari 800 OS:

 

Crush Crumble and Chomp

Helcat Ace

MASH

[+Ripdubski]

Is Kid Grid one? I cant get it to run on my XE.

[ACML]

Is Kid Grid one? I cant get it to run on my XE.

Go to the link below. There are a few versions on Kid Grid that work on the XL/XE.

 

http://www.atarionline.pl/v01/index.php?ct=katalog&sub=K&tg=Kid+Grid#Kid_Grid

[+Ripdubski]

Thx

[Xuel]

Thanks Xuel! Which XEX has the delay (fast plot or regular)?

 

finalflight.xex has the delay. finalflight-fastplot.xex doesn't have the delay.

[ACML]

BUMP

[+therealbountybob]

We're playing Hunch Back as a bonus game in the HSC, please can someone can patch it (the file version) for XL/XE? (atarionline.pl also have the ATR and XEX versions)

Thanks

 

[Looks like the code is BASIC with machine code routines - if you hammer break as you start the game you can list it]

Edited October 11, 2014 by therealbountybob

[Xuel]

We're playing Hunch Back as a bonus game in the HSC, please can someone can patch it (the file version) for XL/XE? (atarionline.pl also have the ATR and XEX versions)

Thanks

 

[Looks like the code is BASIC with machine code routines - if you hammer break as you start the game you can list it]

 

I got it working in Altirra and Atari800 with XL OS but I don't have a DOS-friendly executable:

 

hunch.xex

 

I found three problems:

 

1) It's using some kind of trick to make BASIC interpret a RUN command which doesn't work on XL OS. I don't know how to fix this so the above executable is made from a memory dump after that point on OSB.

2) It prints a long string at some point that makes the screen scrolling routine go off the rails and trash memory. I was able to fix this by shortening the string by one byte by replacing the $28 at $58DB with $27.

3) It calls a routine in page 6 that has a BRK instruction. It's not fatal but can be avoided by replacing $67F and $680 with NOPs.

 

I think I'll have to admit defeat on this one as I don't know enough about the RUN command trick.

[phaeron]

The RUN mechanism is pretty standard -- putting "RUN" on screen and stuffing the ENTER scan code into CH. What's not is how it initializes the system: it loads the entire zero page from disk. This breaks the load mechanism on the XL/XE OS because on that OS the two bytes at $78-79 in the line drawing area were repurposed for the keyboard translation table (KEYDEF). OS-B didn't have this, and so the ENTER key is mistranslated. Other problems could also be related to XL/XE system variables being corrupted. Looks like a sloppy memory dump. The parts that are needed are the cursor position (ROWCRS/COLCRS), and the BASIC variables ($80-FF). Honestly, probably easier just to ditch the loader and replace it with a new one that just loads the BASIC program, $0600-06FF, and looks like some graphics/DLI routine data up around just before $8000.

 

The memory trashing bug is harder to deal with. The game does some pretty hinky stuff with the Screen Editor, particularly directly modifying the display mode variable (DINDEX). What appears to be happening is that it is trying to change the display mode to GR.0 and then printing out part of the screen with ? #6 at lines 5010-5020:

$319A: 5010 FOR Y=37 TO 54: POKE DL+Y,4: NEXT Y: POKE 559,OTT: POKE 87,0: POKE 710,0: POKE 709,0: POKE 708,0: POKE 711,200 {end $3229}
$3229: 5020 POSITION 0,21: ? #6;BR$: IF SHE=15 THEN OTT=0: GOTO 5025 {end $326D}

Problem is, it doesn't reset BOTSCR, which holds the height of the split-screen. OS-B only checks this variable if the split screen is active, but the XL/XE OS expects it to be set to 24 otherwise. Because ROWCRS > BOTSCR, this causes a bogus scroll that trashes memory. I was able to get around it by patching the program as follows:

5015 POKE 703,24

...but it looks like there are other issues besides that.

[+therealbountybob]

I knew you guys like an Atari challenge

(the original version is the ATR as far as I know it it's any help)

[+JAC!]

Haha, creating a BASIC program that's incompatible with the XL OS deserves a special price for creativity actually.

[_The Doctor__]

The dual player Star Raiders like prototype is probably not easily accessible. I found this in a San Diego user group meeting in 1984. I contacted Doug Neubauer, author of Atari's Star Raiders, and he said he did not code this variant. I believe Rybags has taken an initial look at this and he mentioned that it may call Port B (joys 3 & 4). If so, a null modem cable was used in port 3 or 4 to connect the two computers in dual head to head mode. Solo mode appears to work, its just dual that crashes on an XL. If it does use joy port 3 or 4, maybe it could be changed to use port 2.

multijoy candidate?

[a8isa1]

[Looks like the code is BASIC with machine code routines - if you hammer break as you start the game you can list it]

I was surprised to read that Hunch Back is a BASIC program since it runs on my 800 without a BASIC cartridge installed.

 

This explains why it took so long to load. It had to load BASIC into RAM before running itself.

[Neo-Rio]

BUMP again.

 

Wanting "Eggnapper" to get fixed.

It seems to work until the game starts, at which point it hangs with a white square at the top of the screen.

 

Reason for this request is that I used to work with someone who's friend was the coder of this game, and he always talked about it and how silly the game's plot was.

Would like it to work on my XE

[FULS]

Has the "Embargo" (OSB) cart ever been fixed to run on an xl or xe? File or rom?

 

Thanks,

Doug