Atari ST - 1990
24BIT

- Genre
- Patch / Driver
- Year
- 1990
- Language
- [unknown]
- Publisher
- [no publisher]
- Controls
- -
- Distributor
- -
- Players
- —
- Developer
- Atari Corporation
- Resolution
- VGA
- Licensed from
- -
- Programmer(s)
- [unknown]
- Country

- Graphic Artist(s)
- —
- Software
- English
- Game design
- —
- Box/Instructions
- English
- Musician(s)
- —
- License
- PD / Freeware / Shareware
- Sound FX
- —
- Serial
- —
- Cover Artist(s)
- —
- ST Type
- TT / 2MB
- MIDI
- —
- Version
- Revision 3
- Dump
- Download
- Number of Disks
- 1 / Double Sided / HD Installable
- Dump format
- MSA
- Protection
- —
OTHER VERSIONS WITH THE SAME TITLE (2)
INSTRUCTIONS
DOCUMENTATION FOR 24BIT.PRG Revision 3 / December 10, 1990 The ST uses a 68000 CPU, which has a 24-bit address bus. That means that the high-order eight bits of a 32-bit longword used as an address don't matter. Some programs use those bits to mean something, like the type or size of the thing a pointer points to. Those programs are "not 32-bit clean," won't work normally on the TT, because the 68030 CPU uses all 32 bits of a longword as the address. If you run them, you will get bombs or more horrible kinds of system crashes. Running the program "24BIT.PRG" in your AUTO folder programs the memory-management unit built into the 68030 so those eight bits are ignored again. Some programs which are not 32-bit clean will work after running 24BIT.PRG. If you run an ST program on your TT and it bombs, you can consider doing this: 1. Reboot. It's always a good idea to reboot after a program bombs, because it might have put things in a funny state without cleaning up after itself. 2. Put 24BIT.PRG in your AUTO folder and reboot again so it executes. 3. Run the program that bombed. If it works normally, then you know you have to use 24BIT.PRG before you can run that program. Microsoft Write and programs written in compiled GFA BASIC 2.x, as well as the GFA BASIC 2.x interpreter itself, are known to require the use of 24BIT.PRG. GFA BASIC 3.x probably does, too. There are a number of things to keep in mind: There might be more wrong with a program than not being 32-bit clean. programs that use the high eight bits of pointers might also play other tricks which render them incompatible. I used to think you had to disable the cache to run under 24BIT.PRG, but I was wrong. You can't access TT RAM using only 24 bits of address, so you can't be using TT RAM and use this program. If you have no TT RAM, or if you have some installed but aren't using it, you can run this program. The program will tell you if it can't run because there is something in TT RAM. If you have TT RAM but aren't using it, the program will run, and arrange it so the system "forgets" that there is any TT RAM until you reboot. That is the price these programs make you pay. Devices on the VMEbus can not be accessed using only 24 bits of address, either, so you lose access to them, too, when you run this program. Since this program can't "allocate" a VMEbus device the way it can TT RAM, there is no way to protect against this, and the system will probably just crash if you run a program that accesses the VMEbus after running this program. Programs which actually pass 32-bit addresses with nonzero high bytes as parameters to OS calls can still die, because all 32 bits are written to (e.g.) the SCSI DMA controller. 24BIT.PRG must run in the AUTO folder because the TT Desktop itself uses TT RAM if it's available, so 24BIT.PRG must run before the Desktop comes up. In addition, 24BIT.PRG must appear in the AUTO folder before anything which stays resident and has its TT-RAM-allowed bits set; otherwise 24BIT.PRG will find that TT RAM isn't empty and refuse to let you into "24-bit mode." The program 24BIT.PRG must not have its "load in TT RAM" bit set, because otherwise it will find that TT RAM is not empty (the PRG itself is there) and refuse to run. ---------------------------------------------------------------------- Technically speaking, this program rewrites the page tables in memory so bits 31-24 are always mapped to zero. This way programs which use the high bytes of pointers can run. If you have no TT RAM, 24BIT.PRG will program the 68030's memory management unit and exit without taking up any resources. It simply re-uses the memory where the TOS ROM memory-management tables are. The program will print a message and refuse to run if you aren't on a TT, or if there is anything in TT RAM. "Anything in TT RAM" is defined as follows: the system variables _ramtop and _ramvalid are used to find out if you have any TT RAM, and if you do, how much. Mxalloc() is used to allocate all of it. If the call fails, it means there's something in there and the program aborts. If there's nothing in TT RAM, the program rewrites the page tables and does a TSR so the TT RAM block it allocated isn't freed. That way subsequent programs which have their TT-RAM-enable bits set still won't load there. This remapping trick will be defeated by programs which somehow install themselves at the top of TT RAM and bump _ramtop down. Do not run any of these if you want to use 24BIT.PRG. If you write software, don't write programs that fool with _ramtop, or your users won't be able to use 24BIT.PRG to run their favorite "unclean" software.
