Atari Pilot Diskette Image on Atari XE

[atari65xenajm]

When I attempt to boot Pilot to an emulated Atari 400/800, it works just fine. However, trying to do the same thing with emulated Atari 65XE/130XE, or even XL series, I end up with this garbled screen output.

 

Why is this so? How can this be fixed?

 

Atari 400/800 works fine.

 

Atari XE crashes and shows garbled screen output.

 

I attached a diskette that has PILOT in it for your reference.

 

Programming.atr

 

Thanks

[Kylev]

atari65xenajm,

This may be a simple case of not removing the internal BASIC on the XL/XE machine. Try either holding the OPTION key (I forget which Fn key this is in Altirra) down during the boot or choosing the option to not use BASIC from the menus.

[atari65xenajm]

atari65xenajm,

This may be a simple case of not removing the internal BASIC on the XL/XE machine. Try either holding the OPTION key (I forget which Fn key this is in Altirra) down during the boot or choosing the option to not use BASIC from the menus.

 

Thanks @Kylev, but Internal BASIC was removed in both cases (otherwise the title bar would show XE PAL / 320K RAMBO / BASIC).

[+Nezgar]

Just tried this on real hardware. 800XL OS Rev 2 with basic OFF or ON same result with garbled screen like above, when booting off of the disk.

 

Then I tried with a real dos - SpartaDOS X - "X PILOT." and same garbled screen result.

 

Using the "800 Compatible" OS in the 32-in-1 OS it works fine booting from the disk, as well as from within SDX.

 

Using 1200XL Rev 10 OS on the 800XL, instead of a garbled screen, it prints 1 garbage character to E: before locking up.

(I also tried this on a REAL 1200XL with Rev 10 OS, same behavior) - which definitely has NO BASIC ROM. I also pressed CTRL-F1 to make the L1 LED light up, and it did not get turned off at the time of the crash, so its not because of BASIC being enabled by a spurious PIA write, which may have cleared that LED as well.

Using 1200XL Rev 11 OS, i get garbled screen like the XL OS.

 

Back to the 800XL, with XL OS Rev 2 selected, since I have the TF_HH 512K SRAM, i ran the MOFF.COM to disable all extended memory, and still get garbled screen. (Further supporting its not a spurious PIA write causing a bank switch)

 

I'm guessing it's purely an incompatibility with anything but the 400/800 OS, some bad OS entry point, or proper vector not being used.

[_The Doctor__]

so try with tranlsator disk or ultra translator 2.0

[+Nezgar]

Looking at the executable, it loads data from $6000-$7FFF, then $600-$633, then RUNs at $600

 

I disassembled the 51 bytes that get loaded at page 6:

                  * = 0600
0600   A5 6A      LDA $6A
0602   C9 90      CMP #$90
0604   90 2A      BCC $0630
0606   A9 90      LDA #$90
0608   85 6A      STA $6A
060A   20 F6 F3   JSR $F3F6
060D   AD 00 60   LDA $6000
0610   EE 0E 06   INC $060E
0613   D0 03      BNE $0618
0615   EE 0F 06   INC $060F
0618   8D 00 A0   STA $A000
061B   EE 19 06   INC $0619
061E   D0 03      BNE $0623
0620   EE 1A 06   INC $061A
0623   A9 C0      LDA #$C0
0625   4D 1A 06   EOR $061A
0628   D0 E3      BNE $060D
062A   20 31 06   JSR $0631
062D   6C FA BF   JMP ($BFFA)
0630   60         RTS
0631   6C FE BF   JMP ($BFFE)
0634   E0 02      CPX #$02
0636   E1 02      SBC ($02,X)
0638              .END

Maybe someone else is better at interpreting this, but I'll try!

1. Check if RAMTOP = $9000 (36K RAM) - if there's 36K or less RAM available, then RTS (exit to DOS)

2. Set RAMTOP to $9000, and JSR $F3F6 (Initialize display handler)

3. Copy $6000-7FFF to $A000-BFFF (Relocate loaded 8K program into RIGHT cartridge area)

4. JSR to the right cartridge initialization address

5. JMP to the left cartridge start address

 

so if RAMTOP is set at $9000, and the program code starts at $A000, that leaves 4KB RAM free from $9000 to $9FFF - maybe for PILOT internal use...

 

Anyhow - the main suspect:

$F3F6 - According to Mapping the Atari: "The display handler begins at 62454 ($F3F6)" - In the XL/XE OS, this jumps right into the middle of the "Move Cursor Down" Keyboard GET-BYTE routine - explaining the garbage character printed on the screen, or if it succeeds and continues, the 8K program relocation writes right on top of the display and display list since the screen did not reinitialize.

 

The little page 6 initializer is not necessary with cartridge-based PILOT, since the OS will automatically already have moved RAMTOP out of the way of the cartridge, so reinitializing the screen is not needed. This was probably a hack done by someone who dumped the cartridge, in the early days before the XL/XE OS and didn't use the proper display initialization vector.

 

I *think* maybe replacing $F3F6 with $EF6E? or somewhere around there might work...

EDIT: Nope, $EF6E doesn't work. $E400? Nope. X register needed?

[Wrathchild]

As per this recent post, the $F3F6 is updated to $EF8E. The reason for the failure is that when no cartridge is present the screen RAM is at the $BC40 area (assuming 48K or more memory available). The above call is initialising the screen again so that the screen RAM will be below the cartridge area.

Programming_XLfix.atr

[+Nezgar]

Right! I remember that thread now.

 

So since the AtariWiki page you mentioned lists $E410 as the vector for S:OPEN, I presume using that, 1 version would work on all OS's.

 

Also reading in Mapping the Atari, it mentions you need at least 800 bytes above the screen area since the editor tends to clobber ram above RAMTOP..., and for Gr7 and Gr8 drawing routines to work properly, RAMTOP needs to be set at 4KB boundaries.. So for RAM based PILOT in the Cartridge space to be 'safe' from the E: handler clobbering it (A 'feature' of the 800 OS fixed in the XL OS's), they move RAMTOP down to the next 4KB boundary below 40KB - 36K. This would probably have been prudent for a RAM based BASIC, ASM/ED, etc for the 800 too...

 

So this RAM based PILOT will have 4KB less working RAM than if you use the cartridge version. I guess a more enhanced 'XL/XE' update to the page 6 initialization code could add a check for XL/XE OS, and set RAMtop to $A0 vs $90 for 400/800 OS.

[atari65xenajm]

As per this recent post, the $F3F6 is updated to $EF8E. The reason for the failure is that when no cartridge is present the screen RAM is at the $BC40 area (assuming 48K or more memory available). The above call is initialising the screen again so that the screen RAM will be below the cartridge area.

 

Thank you from the bottom of my heart. I wish I understood the architecture of the 8-bit Atari. But never had the time to. Your post from the other thread is "If you find that a program Jumps to F3F6 to open the screen, (20 F6 F3) and you have an 800XL, change the code to (20 8E EF). Remember: Low byte/High byte." gives an excellent remedy of the problem. I also learned now that the address that XE/XL use to open S: is $FE8E, and that 6502 used Little Endian! Thanks again and again.

 

I edited the post to ask if you could please do the same magic for FORTH. It has a similar problem. I used Altirra to copy FORTH to my harddrive H: and opened the binary file using a hex editor, but searching for $F3F6 took me no where

Edited September 13, 2018 by atari65xenajm

[Wrathchild]

The FORTH has a couple of problems... firstly the loop to copy some of the pre-launch code used a BNE check when it should have used a BPL as it therefore didn't copy the first byte and so crashes when jumped to. Secondly, this code is copied to page 3 and so overwrites the XL's cartridge-present check value and so when the next vertical blank occurs, the machine goes into an infinite loop. That should be possible to patch though.

[+Nezgar]

I edited the post to ask if you could please do the same magic for FORTH. It has a similar problem. I used Altirra to copy FORTH to my harddrive H: and opened the binary file using a hex editor, but searching for $F3F6 took me no where

If you searched for F6F3 you would have found it (Remember Little endian, so byte order reversed )

 

Upon further reading, and confirming in the other "Designers Pencils" thread, I found it's best to use the S: OPEN vector, which is $E410 ( 10 E4 in the file)

 

This will result in a single executable that will work on ALL THREE main variant groups of the Atari 8-Bit OS's, as the $E410 vector contains the pointer JMP to the correct location, usually one of:

- $F3F6 - 400/800

- $EEED - 1200XL Rev 10

- $EF8E - 1200XL Rev 11, XL/XE OS Rev 1/2/3/4

 

So... trying out my limited assembly skills..............

 

I didn't realize you can't JSR directly to $E410, so just replacing the 2 bytes didn't work. Looking at Wrathchild's initializer for "Designers Pencil" I saw the way is to push the address to the stack, then JSR... and to insert the extra code to do that meant shifting all the addresses by 6 up or so, which I tried failed at when trying manually... so i added it at the end, and JSR'd to the additional code then update the 2nd stage loader length 10 bytes longer, and removed the "FF FF" inter segment header to save 2 bytes wasted in the original, so overall file size increase is only 8 bytes.

                  * = 0600
0600   A5 6A      LDA $6A
0602   C9 90      CMP #$90
0604   90 2A      BCC $0630
0606   A9 90      LDA #$90
0608   85 6A      STA $6A
060A   20 34 06   JSR $0634 ; replaced
060D   AD 00 60   LDA $6000
0610   EE 0E 06   INC $060E
0613   D0 03      BNE $0618
0615   EE 0F 06   INC $060F
0618   8D 00 A0   STA $A000
061B   EE 19 06   INC $0619
061E   D0 03      BNE $0623
0620   EE 1A 06   INC $061A
0623   A9 C0      LDA #$C0
0625   4D 1A 06   EOR $061A
0628   D0 E3      BNE $060D
062A   20 31 06   JSR $0631
062D   6C FA BF   JMP ($BFFA)
0630   60         RTS
0631   6C FE BF   JMP ($BFFE)
;new code starts here - thanks Wrathchild!
0634   AD 11 E4   LDA $E411
0637   48         PHA
0638   AD 10 E4   LDA $E410
063B   48         PHA
063C   60         RTS ; actually JSR to $E410's vector
063D   60         RTS ; then actually return
063E              .END

Tested and working on both a real 800XL OS rev 2, and real 1200XL OS Rev 10!

 

Maybe someone better than I can optimize this further.... like moving the additional code in place of the first JSR, and restoring memtop after exit back to DOS? I noticed it remains artificially low after exiting. Even after pressing reset. Though, I could get it back in Sparta 3 or RealDOS is BASIC ON, then BASIC OFF.

 

Fun challenge for an assembly novice!

PILOT4ALL.XEX

[Wrathchild]

Just a note... your second RTS at $63D is redundant.

The JSR is actioned at $60A and so the return address is pushed to the stack.

The extra code puts a new return address onto the stack and this is popped to the program counter by the RTS at $63C.

Once the O/S routine is done it returns via its own RTS and so the original JSR return address is restored and execution continues at $60D.

[Wrathchild]

The FORTH has a couple of problems... firstly the loop to copy some of the pre-launch code used a BNE check when it should have used a BPL as it therefore didn't copy the first byte and so crashes when jumped to. Secondly, this code is copied to page 3 and so overwrites the XL's cartridge-present check value and so when the next vertical blank occurs, the machine goes into an infinite loop. That should be possible to patch though.

 

The small pre-launch code only uses branches so was OK to relocate to Page 1 instead (stack area @ $100).

Programming_XLfix.atr