verwer@ruuinf.cs.ruu.nl (Nico Verwer) (11/29/89)
In article <1820@atari.UUCP>, kbad@atari.UUCP (Ken Badertscher) writes: > walkerb@tramp.Colorado.EDU (Brian Walker) writes: > | What did you do with the line F compression? > It's gone. Because of the larger ROM space in the STE, (and TT), the line F > compression is no longer required to make the TOS ROM image fit. With the > exception overhead gone, the AES moves along noticeably faster, too. Why didn't Atari use large ROMs for the 1040 in the first place? Using line-F makes upgrading to a 68020 and a floating-point coprocessor really difficult. Now it also appears that exception overhead seriously affects AES-speed 8-( ! Were ROMs so expensive at the time that Atari felt they should decrease ROM-size at any cost, or is this a problem of the MMU, or what? Will there ever be a chance for 1040 owners to use a larger ROM-set, thus being able to painlessly use a 68020 running standard TOS? Is it possible to make a hack and solder the extra ROMs in? Or would you have to replace the whole motherboard with an STE-board (which has the same case anyway)? I'm not complaining, just wondering, so send flames to /dev/null (or the trash can). Nico Verwer @ Dept. of Computer Science, University of Utrecht, The Netherlands verwer@cs.ruu.nl +31 30 533921
R_Tim_Coslet@cup.portal.com (11/30/89)
>Why didn't Atari use large ROMs for the 1040 in the first place?
I don't know, but my GUESS is that Atari made the same "mistake" that
the company I work for frequently makes... they underestimated the size
of the code when they specified the amount of ROM space needed while designing
the hardware, by the time they realized that they needed more ROM the hardware
was "set in stone" and could not be changed... so they got an "expert code
compression" type programmer to try to squeeze every byte out that they could
thru ANY trick possible. This is probably also part of the reason the TOS
sources are so "disorganized" and difficult to read.
This happened on a machine that I worked on several years ago (and was
especially bad). The system spec called for 50% unused ROM... software
estimated the code could easilly fit in <2K, so the hardware was designed
with 4K of ROM... However the first COMPLETE version of the code needed 5K!!!
That took some VERY strange recodings to squeeze 5K of code into a 4K ROM.
R. Tim Coslet
Usenet: R_Tim_Coslet@cup.portal.com
BIX: r.tim_coslet