=============================================================================== Document source: Original backup tapes owned by Dutchman2000, obtained by Atarimania. Documentary research and PDF layout by Laurent Delsarte. Note that these backup tapes contain A LOT of information spread out in many folders, meaning it will take time to process the important bits. =============================================================================== Document identification: Original file name: RIKER_NOTES Title of document: Initial note from Greg RIKER on a translator for the 1200XL Author(s): (presumed, to be confirmed) Greg RIKER Original file date: (unknown) Presumably before the version 1 of the translator, dated 1983-09-20 Type of document: Memo Target audience: Internal Status: Ready Reference (Atari): (unknown) Reference (Laurent Delsarte): For any discussion, this PDF has been given the reference BKUP-19XX-XX-XX-MEMO-0001A-C which should be quoted in any communication. Tags: #Atari #8bit #6502 #400 #800 #1200XL #OS #REV.B #REV.10 #REV.11 #NTSC #Translator =============================================================================== =============================================================================== =============================================================================== I have investigated the feasibility of installing an 800 Operating System in a 1200 XL. This capability is an advertised feature of the 1200 XL architecture (Soft OS), so it is necessary that Atari support a means of doing it. I have successfully implemented a disk version of the switch. It required minor modifications to the 800 OS in three spots. In each of the three cases, I was obliged to NOP code that stored values to the B register of the PIA. Since the B register of the PIA controls the source of data from $C000-$FFFF, it is necessary to remove standard OS writes to this port. With these patches, a user can boot an AUTORUN.SYS from disk. The code executes, and the user is prompted to install the disk or tape to boot in the 800 mode. If BASIC is required, the user would install BASIC prior to running the installation code. At the time that the user is prompted to make the switch, the message indicates that he should press SELECT when he is ready to boot the new code. The user is also prompted to press SELECT and START if a tape boot is desired. Following this procedure brings the user up into an 800 environment. There are some potential problems to consider. If the user presses while in the 800 environment, a true Reset occurs on the PIA, restoring the 1200 OS to control. Therefore, even if the application program has 'hooked' the 1200 OS will re-appear. There are three solutions to this problem. The first is a patch to the user's code. The second is a patch to the 1200 OS. The third is to force the user to power down and start over. Ideally, shouldn't be necessary in an application program, so it would be nice (albeit unreasonable) to think that we didn't have to worry about it. Proceeding in a reasonable vein, implementing the first solution would require user code to inspect the environment and detect the presence of a 1200 OS. If found, assume that the 800 OS is alive in RAM under the 1200 OS ROMs, switch to the 800 OS and do a cold/warm start. The second solution, patching the OS, would require a test in the very early stages of INIT to inspect a flag that says 'We WERE running in an 800 environment BEFORE the that brought us here'. Presumably, this flag would be implemented in a similar fashion to the WARMST flag, i.e. a <0> indicates that we were in fact running an 800 environment. If this test is successful, then toggle back to the 800 mode and jump to the WARMST vector. The third solution is self explanatory. Several other factors must be considered in the diskette implementation of this approach. First of all, when the 800 OS does its RAM sizing, it will determine that free RAM exists all the way up to $D000, and set RAMTOP accordingly. This is 4096 bytes more than normally exists in an 800. It should also be noted that this extra RAM is not available as an extension of contiguous RAM in a BASIC environment. However, it is still RAM, and as such could be used. Therefore, the booting environment will size RAMTOP at $D000 if booting an application from disk or tape, and it will size RAMTOP from $8000 to $B800 (depending on the cart size) in a cartridge environment. This 'extra' 4k could cause compatibility problems if the goal is strictly a clone of the 800 OS. Another major factor to consider is the patches that were made to common OS routines between the 800/RevB and 1200/Rev11 Operating Systems. It would be wise to take advantage of these improvements, as long as address compatability was maintained. We could thereby accomplish a 'Super-800' Operating System that essentially gives the best of both worlds - full 800 compatability, with improved OS features. Specific routines that would benefit would be the keyclick routine, the screen clear routine, and providing the appropriate signals to light the LED's on the 1200 console. Accomplishing the switch from a cartridge environment proves more difficult. The problem arises when a user pulls a 'hot' cartridge out of the cartridge space. At least 50% of the time, the user is obligated to press after making a 'hot' switch, which invokes the problem described earlier - the 1200 OS reappears. My conclusions are based upon the assumption that absolute transparency is the goal. If that is the case, then the disk environment is the approach that must be taken. The issue of the extra 4k is still something that must be contended with, but should not be as much of a problem as address incompatability.