nut@wet.UUCP (adam tilghman) (01/07/90)
After reading several descriptions of TOS 1.6, it sounds like it would not be an impossibility to drop a 68030 into a 1.6-equipped machine. Will Atari market 1.6 to us 1.0-1.4 peoples for that purpose? I like my Mega and do not plan on upgrading to an STe (for the same reasons that I sold my 1040). I realise that this is not exactly an easy question for those Atari employees on the net, as it is more a legal issue than a technical one =:( -- == Adam G. Tilghman - Trendy Quote: "Beware of Greeks bearing Trojans!" == === UUCP: nut@wet.UUCP BBS: Eleusesthai, (415)871-9451 12/2400, 24Hrs === ============= Disclaimer? My employer? What, me work? ==================
VBRANDT@DBNUAMA1.BITNET (01/10/90)
Hello all, In Info-Atari16 Digest #16, cca.ucsf.edu!wet!nut@cgl.ucsf.edu (adam tilghman) writes: > After reading several descriptions of TOS 1.6, it sounds like it would not >be an impossibility to drop a 68030 into a 1.6-equipped machine. Will Atari >market 1.6 to us 1.0-1.4 peoples for that purpose? I like my Mega and do >not plan on upgrading to an STe (for the same reasons that I sold my 1040). >I realise that this is not exactly an easy question for those Atari >employees on the net, as it is more a legal issue than a technical one =:( Sorry, but this technically impossible. The 1.6 version is bigger than the available ROM space in a regular ST/Mega, and is installed at a different location in the CPU address space. Also, I doubt that 1.6 checks for CPUs other than a 68000. TOS 3.0, on the other hand, does just what you want. 3.0 is the TOS that comes with the TT. It won't work in STs for the same reasons. The only way you still can achieve your goal of having an '020 or '030 in your machine is to take TOS 1.4, disassemble it, fix the '020/'030 problems and reassemble it. This works just fine, but it is a bit of work. As a side effect, GEM is 9 % faster using an 68000 (haven't measured other performances yet), and the ROM code size is decreased by several KB, giving you space to add some extra goodies on your own. While you're at it, you can fix all of those (known) bugs that still lurk in there. Of course, programs that illegaly use hardcoded ROM addresses will fail, but I haven't found such a program yet, at least not one that I'd miss. In Germany, this is entirely legal, as long as you don't distribute such a TOS to others (without written permission from Atari, which is probably hard to get :-) Me, all I need is an affordable 68030 board, like the one recently discussed here (if I remember correctly, Dave Small was one of the developers, but he has been silent on that topic for some while). ---------------------------------------------------------------------------- Bitnet: VBRANDT@DBNUAMA1 (will go away some day ...) Volker A. Brandt UNM409@DBNRHRZ1 (alternative) Angewandte Mathematik UUCP: ...!unido!DBNUAMA1.bitnet!vbrandt (Bonn, West Germany) ARPAnet: VBRANDT%DBNUAMA1.BITNET@CUNYVM.CUNY.EDU
ignac@electro.UUCP (Ignac Kolenko) (01/11/90)
In article <9001100808.AA18195@ucbvax.Berkeley.EDU> VBRANDT@DBNUAMA1.BITNET writes: > Sorry, but this technically impossible. The 1.6 version is bigger than the >available ROM space in a regular ST/Mega, and is installed at a different >location in the CPU address space. > > Also, I doubt that 1.6 checks for CPUs other than a 68000. TOS 3.0, on the >other hand, does just what you want. 3.0 is the TOS that comes with the TT. >It won't work in STs for the same reasons. actually, darek mihocka and myself have an STE and we've disassembled the exception handlers in TOS 1.6, and sure enough, it checks some system variable which tells the software what type of stack frame it can expect. therefore, if its a 68000 processor, it uses an offset begeinning at 6 from the current stack pointer to get params, and if its an 010 or higher, it uses an offset of 8. it does this in getting params, and also for reconstructing stack frames, etc. so, in actuality, tos 1.6 does indeed support cpus other than the 68000. also, i remember vaguely reading some review in ST world on the STE when it was unveiled at the dusseldorf show, and they were saying it was running tos 1.6 at the time. but i could be wrong ... -- =====Ignac A. Kolenko (The Ig) watmath!watcgl!electro!ignac===== co-author of QuickST, and the entire line of Quick Shareware!!!! "I don't care if I don't win, 'cause I don't care if I fail" from 'Youth Of Today' by SUBURBAN DISTORTION
saj@chinet.chi.il.us (Stephen Jacobs) (01/12/90)
In article <1252@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes: > >actually, darek mihocka and myself have an STE and we've disassembled the >exception handlers in TOS 1.6, and sure enough, it checks some >system variable which tells the software what type of stack frame it can >expect. therefore, if its a 68000 processor, it uses an offset begeinning This is what serious developers do when source to critical parts of an OS isn't made available, and when the documentation is sparse (in case there's any confusion, I think it's a good thing to do under the circumstances, as long as it doesn't lead to use of version-specific and accidental features. I attach no moral color, good or bad to Atari's reluctance to disclose TOS source to registered developers. The sparse documentation is unfortunate, but not evil). My point is that all the stuff Atari hopes to prevent by keeping the source confidential, even from those who have signed non-disclosure agreements can happen anyway. Here we have 2 people who've earned a reputation as cautious programmers doing their own dissembly. Guys with PC game experience and a lot less caution can do the same. On any timescale I can imagine, it would be better for Atari and its customers if developers had an easy way to check EXACTLY what TOS would do in a given situation (and any commented source, no matter how 'ugly', beats a dissassembly). [whining off] Steve J.
apratt@atari.UUCP (Allan Pratt) (01/13/90)
saj@chinet.chi.il.us (Stephen Jacobs) writes: >In article <1252@electro.UUCP> ignac@electro.UUCP (Ignac Kolenko) writes: >>actually, darek mihocka and myself have ... disassembled ... >This is what serious developers do ... to >check EXACTLY what TOS would do in a given situation (and any commented >source, no matter how 'ugly', beats a disassembly). The fallacy here is that you think we want you to know EXACTLY what TOS would do. Publishing the source would make it impossible to change it, because people would start relying on accidental side-effects of operations. When that happens, we can't change the code without breaking those programs or maintaining those previously-accidental side effects. This is a maintenance nightmare. Take this example: if you had source for the original Fsfirst call, you'd have seen that the only error it can return is EFILNF, file not found. You might have used that knowledge in your code somehow. In TOS 1.4 and beyond, Fsfirst can return EPTHNF, *path* not found. I consider this an improvement. If your code was expecting either success or EFILNF, and gets neither, how will it behave? In an extreme case, you might have seen that there was a bug in Cconout when stdout is redirected to a file; the HIGH byte of the argument is written to the file, not the low byte, or something like that. This is a bug, not a feature, but if you take advantage of it we can't ever fix it without breaking your program. Finally, take Malloc: you would know that Malloc uses OS POOL to keep track of memory, and that two successive Malloc calls are likely to result in two contiguous blocks of memory. People have in fact taken advantage of this, and the result is that we can't ever fix this brain-damaged approach to memory management. We're straitjacketed by the tricks people pull; imagine how much worse it would be if the whole OS were open to that kind of scrutiny! You needn't tell me that UNIX source is available (if you pay for it). UNIX is different, because (A) it was designed better, so people don't have to resort to these tricks just to do ordinary things, and (B) people on UNIX systems don't come from a tradition of 8-bit game-machine programming, where the first question they ask is, "Where can I POKE to change rez?" ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
matthews@umd5.umd.edu (Mike Matthews) (01/14/90)
In article <1956@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >The fallacy here is that you think we want you to know EXACTLY what TOS >would do. Publishing the source would make it impossible to change it, >because people would start relying on accidental side-effects of >operations. When that happens, we can't change the code without >breaking those programs or maintaining those previously-accidental side >effects. This is a maintenance nightmare. > [various examples deleted] > >============================================ >Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. >reflect those of Atari Corp. or anyone else. ...ames!atari!apratt Yes, but it would seem that if there was a bug in the OS, the program would crash anyway (or at least misbehave) if the code was written correctly, so it would work with future versions of TOS. There already IS a "maintenance nightmare" out there. Programs crash on new releases of the ROM because the programmers decided to ignore some rules. Or perhaps workaround some old bugs. That's gonna happen no matter what. (correct me if I'm wrong; I'm guessing at this mostly) Mike
VBRANDT@DBNUAMA1.BITNET (01/15/90)
Hello all, In Info-Atari16 Digest #39, cs.utexas.edu!jarvis.csri.toronto.edu!utgpu !watserv1!watcgl!electro!ignac@tut.cis.ohio-state.edu (Ignac Kolenko) writes: >actually, darek mihocka and myself have an STE and we've disassembled the >exception handlers in TOS 1.6, and sure enough, it checks some >system variable which tells the software what type of stack frame it can >expect. This sounds suspiciously like the Cookie Jar. Interesting... >also, i remember vaguely reading some review in ST world on the STE when >it was unveiled at the dusseldorf show, and they were saying it was running >tos 1.6 at the time. but i could be wrong ... This is true. There are two versions of TOS 1.6 out now, one being a bug fix release of the other. I haven't taken more than a quick look at 1.6 yet. PS: Ignac, I still can't get mail to you. If you still want to have your QuickST tested with Overscan, I could do that for you. ---------------------------------------------------------------------------- Bitnet: VBRANDT@DBNUAMA1 (will go away some day ...) Volker A. Brandt UNM409@DBNRHRZ1 (alternative) Angewandte Mathematik UUCP: ...!unido!DBNUAMA1.bitnet!vbrandt (Bonn, West Germany) ARPAnet: VBRANDT%DBNUAMA1.BITNET@CUNYVM.CUNY.EDU
pwp@iuvax.cs.indiana.edu (Paul Purdom) (01/16/90)
Having just posted a note saying how I feel for those of you that must maintains TOS, let me also say that I think it would be helpful to release the source for TOS (or as much as possible if Atari does not own it all). I don't think Atari has much to lose from copies of the ST (my guess is that if someone came out with a copy, ST sales would go up). Problems from bad code being written would be offset by occasional good suggestions for improvements (UNIX did not start out all that great). I think that Atari only needs to worry about the bad code that would end up in successful programs. Most of the bad code will have no effect and future operating system suggestions. I remember learning a lot by reading disassembled code for the first Radio Shack computer.