atari65xenajm Posted September 12, 2018 Share Posted September 12, 2018 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 Quote Link to comment Share on other sites More sharing options...
Kylev Posted September 12, 2018 Share Posted September 12, 2018 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. Quote Link to comment Share on other sites More sharing options...
atari65xenajm Posted September 12, 2018 Author Share Posted September 12, 2018 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). Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted September 12, 2018 Share Posted September 12, 2018 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. 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 12, 2018 Share Posted September 12, 2018 so try with tranlsator disk or ultra translator 2.0 Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted September 12, 2018 Share Posted September 12, 2018 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? Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted September 12, 2018 Share Posted September 12, 2018 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 4 Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted September 12, 2018 Share Posted September 12, 2018 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. Quote Link to comment Share on other sites More sharing options...
atari65xenajm Posted September 13, 2018 Author Share Posted September 13, 2018 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted September 13, 2018 Share Posted September 13, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
+Nezgar Posted September 13, 2018 Share Posted September 13, 2018 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 2 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted September 13, 2018 Share Posted September 13, 2018 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. 2 Quote Link to comment Share on other sites More sharing options...
Wrathchild Posted September 14, 2018 Share Posted September 14, 2018 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 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.