trb@stag.UUCP ( Todd Burkey ) (09/19/87)
Rats. I tried HDSCAN 2.3 out today on a 4 meg ST and got three bombs as soon as the 'fat table scanning routine' started up...Now, I don't do any assembly calls, just some simple bios calls to read raw sectors, and recursively mush through the data building up a directory tree (how else do you suppose I could read an entire 30 meg disks directory contents in <3 seconds)...I can only think that 1) the new ROMS return some different info on bios/xbios calls, or 2) gremlins are at work. I would really appreciate it if Atari would at publish a little hint list on the network of the info that they put onto the $serve systems. I really don't feel that I should have to take the time and money to log onto Genie and Compuserve just to keep up on 'important' information like this. I actually do own a Developer Kit second hand (purchased from a now non Atari developer), but I use OSS Pascal and MW C. I seem to remember being told in the developer kit docs that if I used the BIOS and XBIOS calls and didn't make use of memory locations, then I would be safe. If this isn't so then we (both developers and the casual programmer) need to know this or Atari is going to have another 1200XL fiasco on their hands (i.e. when even dedicated Atari users tell friends not to touch the computer with a 10 foot pole.) Right now, I really can't do anything about the code, because 1) the only mega in town is owned by a store that bought if from a developer (so I can't do much testing on it), and 2) I am not really convinced that what is in the current ROMS will be what is in there 3 months from now...maybe if I bring cash out to COMDEX this year, I can talk Atari into selling me the ROMS? Any comments anyone? Oh...almost forgot...the stuff that I did get around to testing on the 4 meg ST ran a bit faster...doing simple scrolls of text using my own vro_cpyfm moves ran around 25% faster with the blitter, nothing dazzling. Screen updates in gem seemed significantly faster (window fill redraws), but that could have just been done in the OS as well. Still no reason to sell the 520 and buy a mega...would rather put the money into a transputer addon... -Todd Burkey trb@stag.UUCP
dclemans@mntgfx.MENTOR.COM (Dave Clemans) (09/21/87)
The new ROM's DO NOT change anything in regards to the filesystem. As an
example, I have a commercial product out that reads disk directories
similar to HDSCAN that works fine under the new ROM's.
When using the new ROM's, here are some things to look for
the memory clearing bug is fixed; i.e. the new ROM's are SIGNIFICANTLY!
faster (without this, a 4 megabyte system would not be very useful)
the problems with mouse button detection are fixed; responses to mouse
button hits are faster (though note that this can cause slight problems
in programs, such as FLASH, to do mouse button detection in a non-standard
way)
scroll bars auto-repeat
a serious bug in the floppy driver was fixed; i.e. if you try to read a
floppy "fast" it will work (for those interested, this bug was the real
reason why the "Meg A Minute" backup program published in STart a while
ago had to have code to fall-back to reading a sector at a time when
trying to restore from a floppy).
However, this floppy driver bug fix does break the copy protection
scheme used by some software companies (they depended on a side-
effect of the bug).
To get back to the original question about a crash under the new ROM's;
as you read directory and file entries do you dynamically allocate space
for them an entry at a time using "malloc"? If so, you might be unknowingly
hitting the 20-Malloc bug (still there in the new ROM's, but it will show
up differently). This is very easy to hit in Megamax C (and possibly in
Mark Williams C; check the code for the "malloc" routine). Megamax C
(at least the copy I have) "malloc" allocates memory from "Malloc" in ~6K byte
chunks (as long as you are requesting < 6K bytes). If you make enough requests
such that you've allocated more than about 120KB, you've hit the "20 Malloc"
bug and GEMDOS will tromping on some random parts of memory. Depending on what
you are doing, something critical may or may not get hit. Because of different
memory organizations the old and new ROM's will hit different parts of memory.
The "20 Malloc" bug (and the "40 folder" bug, which is partially related) will
not get fixed until the Atari finishes the rewrite of GEMDOS. That rewrite is
now finally starting to show signs of progressing; a status report on it from
John Feagens has shown up in the Compuserve ST developers sig. In the meantime,
there's "foldrxxx" (which works fine on the new ROM's) and "gemboot" (some
people say it works fine on the new ROM's, some people say it doesn't).
dgctrb@stag.UUCP (09/27/87)
In article <929@dclemans.mntgfx.MENTOR.COM> dclemans@mntgfx.MENTOR.COM (Dave Clemans) writes: > >To get back to the original question about a crash under the new ROM's; >as you read directory and file entries do you dynamically allocate space >for them an entry at a time using "malloc"? If so, you might be unknowingly >hitting the 20-Malloc bug.... I had that problem at first using Megamax, but when I switched to MWC 2.0, it went away. I have gotten reports from other users of HDSCAN saying that it seems to work fine under the new ROMS, so assuming that the 4 meg ST's have the same 'NEW' Roms as everyone else, then there is some more fundamental problem here (i.e. either MWC's malloc is getting confused with 4 meg available-which I find hard to believe, or some phantom drive is being reported when my code checks for existing drives on a mega, or its' back to gremlins...). I will check this out further if Atari ever starts selling mega's for real here (this is kind of a Deja Vu situation...I remember getting into a similiar disussion in the fall of 1984 about whether my DISKEDIT, ULTRACOPY, and SOFTBASE would work correctly with the new ROMS on the Atari 1450XL...remember how certain we all were that there really was such a beast, what with pictures and first hand accounts of the machine?) -Todd Burkey trb@stag.UUCP