[comp.sys.atari.st] TOS 1.4 Incompatibilities

MEGGIN@vm.epas.utoronto.ca (David Megginson) (12/09/89)

Please stop posting arbitrary incompatibility lists for TOS 1.4. Most of
the problems posted come from using a disk-based version of the TOS.
First, the disk-based version is a BETA version, with many bugs still in
it; second, the disk-based version takes up RAM and changes the location
where some poorly-written, non-portable games expect to find things in
your computer; finally, the disk-based version takes up about 200k, so
your big GDOS program (like DTP) may not be able to run correctly.

Even if you have the chip set for TOS 1.4, take everything off your
computer (QuickST, accessories, other auto programs, _everything_!),
do a _cold_ boot, and then try it again. There has been way too much
mis-information floating around about TOS 1.4.


          David Megginson, Centre for Medieval Studies, Toronto

steveg@SAIC.COM (Stephen Harold Goldstein) (12/27/89)

Add Mark Williams' CSD (source level debugger) to the list of
software incompatible with TOS 1.4.  It comes up with something like
"TOS version dated 04061989 unknown" and terminates.  

I haven't had a chance to contact them on the availability of an
update yet.  Anyone know of one, or why they'd explicitly not allow
their code to run on a new TOS version? Highly illegal calls made
perhaps?

---
Stephen Goldstein     steveg@saic.com
My first Atari system? A 24K Atari 800, Rev. A ROMS, C(not G)TIA graphics
Disclaimer:  That's not what I said.

hcj@lzaz.ATT.COM (HC Johnson) (12/28/89)

In article <8912261631.AA04656@SAIC.COM>, steveg@SAIC.COM (Stephen Harold Goldstein) writes:
> Add Mark Williams' CSD (source level debugger) to the list of
> software incompatible with TOS 1.4.  It comes up with something like
> "TOS version dated 04061989 unknown" and terminates.  
> 
I think you mean DB not CSD.  (At least my CSD does not do this).

MWC db plays with tos data that was 'private' in tos 1.0.
Afterward, tos 1.1 and on have a formal table of pointers to this info.

Some one at MWC got carried away and coded it roughly as:
	if(tos1.0) {
		there is no table , rough it;
	}
	else if(tos 1.1)
		goto ok;
	else if(tos 1.2)
		goto ok;
	else
		goto h..l;

Use a binary editer to look for the date string of the releases and patch
the latest one to what tos1.4 uses [hint: change offset 0x1a0d from 22 to 6;
change offset 0x1a0e from 87 to 89].  Then db will work. Sort of.

It corrupts the system clock, and the console and memory are screwed
until you  reboot.


Isn't nice when the OFFICIAL developer software is not compatible with 1.4,
AND MWC claims that it is.

Howard C. Johnson
ATT Bell Labs
att!lzaz!hcj
hcj@lzaz.att.com

fischer-michael@CS.YALE.EDU (Michael Fischer) (12/28/89)

In article <8912261631.AA04656@SAIC.COM> steveg@SAIC.COM (Stephen Harold Goldstein) writes:
>Add Mark Williams' CSD (source level debugger) to the list of
>software incompatible with TOS 1.4.  It comes up with something like
>"TOS version dated 04061989 unknown" and terminates.  

My copy of CSD works just fine under TOS 1.4.  It came with my version
3.0 update quite awhile ago.  The version of csd.prg as returned by
the MWC "version" utility is
	e:\src\csd\csd\1988\4\11\14\51

I did have the problem you describe, not with CSD but with DB, the
machine-level debugger.  I fixed it by patching the executable to
accept TOS 1.4, and it seems to work fine.  I don't know why it was
checking the TOS version in the first place.  Maybe they were just
being conservative about new versions of TOS for which the code had
not been tested.
==================================================
| Michael Fischer                                |
|    Arpanet:    <fischer-michael@cs.yale.edu>   |
|    Bitnet:     <fischer-michael@yalecs.bitnet> |
|    UUCP:       <fischer-michael@yale.UUCP>     |
==================================================