💾 Archived View for mirrors.apple2.org.za › archive › apple.cabi.net › Languages.Programming › GSOS.… captured on 2023-01-29 at 04:47:48.
-=-=-=-=-=-=-
Subj: GS/OS 88-10-18 21:59:50 EST
From: Alan33 Msgs: 29 (89-01-27)
Gang,
I got a copy of the new GS/OS and some strange things are happening.
Some Prodos 8 applications are crashing off the desktop. the only one that works is
appleworks. The others work great off the older (3.0)sys disk. I tried replacing the
Prodos 8 on the new disk with that of the old and that didn't work either.
The main ones I'm having problems with are ProTerm (terminal program from Checkmate)
and Blu 2.28. All my prodos 16 stuff works fine.
Any ideas what I can do to make them work with the new sys disk? Have I neglected to
install something from the Tool disk?
If anyone has any experience with this please let me know.
Alan33
Subj: GS/OS and P8 88-10-18 22:59:20 EST
From: AFL Jim
I've been running all of my ProDOS-8 applications after booting GS/OS. I haven't had
any crashes yet. That included utilities, AppleWorks, AppleWriter, AppleLink-PE,
Mousetalk, Kyan Pascal, BASIC.SYSTEM, etc.
Jim
Subj: Re: GS/OS 88-10-18 23:16:56 EST
From: Dave Lyons
I don't know what would make your P8 applications crash, Alan...if it gives you any
readable stuff on the screen, let me know what it is (even if it's a register dump
with a bunch of numbers and letters...that's my favorite sort of thing!).
--Dave L
Subj: Re: GS/OS Crashes 88-10-19 20:41:37 EST
From: DennisDoms
Just for reference..I've been running both Proterm (v2.01) and BLU 2.28 with GS/OS
since AppleFest, with no problems...
If you have doubts about the "completeness" of your operating system setup (tool set
compatibilities, etc.), and you didn't use the Installer to set things up, you may
want to go back and use the Installer. It should make sure you have the right
combinations installed.
Subj: Re: GS/OS 88-10-19 23:39:45 EST
From: Alan33
DennisDoms,
I did run the stuff I nstalled (5.25 driver was about the only thing and some NDAS
from Stylewares DeskWorks including the Menu Clock) with the intaller program. What
else should be installed?
Maybe the option "install everything possible"?
Alan33
Subj: Re: GS/OS 88-10-19 23:43:40 EST
From: Alan33
Dennis,
Could I have a bad copy of the GS/OS disk or tool disk?
Everything else seems to work fine.
Alan33
Subj: Re: GS/OS 88-10-20 23:22:08 EST
From: AFA Gary J
Alan,
Certain desk accessories have been known to cause problems from time to time. I'm
not saying for SURE that this is your problem, but it is certainly a possibility.
Problems with desk accessories seem to pop up when system software is changed. You
might try removing ALL your desk accessories from your DESK.ACCS folder, and then try
re-booting and run your program. If the program works...then try putting your desk
accesories back onto your boot volume, one by one, testing your program after each
installation. Using this method you can identify the desk accessory that is causing
the problem, and remove it. Let us know if you discover the problem.
Gary
Subj: Re: GS/OS 88-10-21 08:13:23 EST
From: AFL Floyd
Styleware's Menu.clock is probably one of the problems. It is known to cause
crashing on a lot of programs. I'd ditch that one for sure.
Floyd
Subj: Re: GS/OS & P8 88-10-21 21:13:25 EST
From: TMH2
Why does P8 still exist on a GS/OS system?? Why don't we have a 'P8 emulator' which
creates P8-style tables & MLI entry, but calls code which calls GS/OS?! Worst of
all, I can't write one, because GS/OS now vectors to old P8-only space in bank 0.
What's the deal?!?
T. Mike Howeth
Subj: Re: GS/OS 88-10-22 22:51:02 EST
From: Alan33
Gary,
I thought the NDA thing was the problem.
It wasn't. My stupidity was.
I went back and looked at the installer program again. There was this neat line that
said "install system files". I did that and low and behold all my prodos 8 programs
now run.
I don't know how I missed that one. Although since the file names were in the system
folder I figured the stuff should work. I was mistaken.
Oh well, live and learn (and spend lots of money)
Thanks for everyones help.
Alan33
Subj: Re: GS/OS 88-10-30 17:49:53 EST
From: WalterP12
I am having a problem with GS/OS, 5.25 and ramdisk (RamFactor). The operating system
will recognize all three, but if I have the driver for the 5.25 disk in I don't know
how to get the ramfactor to show up. It does so only when the driver for the 5.25 is
out.
Am I doing something, not doing something or is it the operating sytem ?
Thanks for the help.
Subj: Re: GS/OS cache & ramdisk size 88-11-20 03:22:52 EST
From: AndyBoy1
SamT2:
I just finished leaving a somewhat lengthy message under "GS/OS Bugs" - the folder -
describing the operation of the GS/OS cache. Making a long story short, 512k cache is
-way- too much. For the most part the system only caches directory & bitmap blocks
anyhow, so it's probably never all used. And you pay a penalty in large caches, not
only in memory use but in the time spent searching through them.
Andy Stadler
Apple II System Software
Subj: Re: GS/OS cache size 88-11-20 12:32:41 EST
From: Founder
Andy thats interesting (512k cache too large). What would be the optimum cache size
then? I suppose something on the order of 64k or less would be all that is needed
for caching dir blocks.
Mark
Subj: Re: GS/OS 88-11-21 21:42:19 EST
From: AFA Parik
You must have one big directory if it takes 128 blocks...:-)
So thats why in Orca shell, if I delete a file off the HD on the other CMS, it won't
register on this GS... any way to FORCE it to read the directory from the disk
itself, instead of cached ram?
Subj: GS/OS and caching shared devs 88-11-22 03:10:30 EST
From: Dave Lyons
Ouch! Caching anything at the block level from a shared device is _very_ dangerous
to the integrity of your volume. You are badly in need of a GS/OS device driver for
your drive that _never_ caches any blocks. Even without caching, your volume is
still in danger if you have no way to prevent two machines from fiddling with a
particular file or directory at the same time, not to mention the bitmap blocks.
Don't even want to _think_ about that....
Subj: Re: GS/OS 88-11-22 21:37:15 EST
From: AFA Parik
Living on the wild side...:)
Actually I've been pretty safe so far, one will be in ProDOS 8 while the other is in
GS applications. Works out well.
Subj: shared devices 88-11-22 21:39:41 EST
From: Dave Lyons
As Arthur Dent said in Episode 1 of _The Hitchhiker's Guide to the Galaxy_ (by
Douglas Adams),
"Ah. This is obviously some strange usage of the word 'safe' that I wasn't
previously aware of."
<grin>
What happens if you create a file with the machine running P8 and then create a file
with the machine running GS/OS? Doesn't GS/OS have a cached image of the volume's
bitmap block(s), and therefore an outdated idea of what blocks are free?
This is not the only problem I can imagine, but it's the one most likely to trash
your disk completely in the shortest amount of time. :-) [For other amusing ways to
fry disks, try shifting all the bytes in block 6 forward one & inserting a $55 at the
beginning! This has happened to me, unfortunately.]
I'd run MR.FIXIT on that volume _very_ frequently...
Subj: Re: GS/OS 88-11-23 01:23:29 EST
From: JSchober
This has nothing to do with GS/OS, but speaking of that thing on block 6... back when
I was still using the <shuddddder> Rev. A SCSI ROM on the GS, the system had this
disconcerting habit of taking an index block -- of a LARGE, IMPORTANT file, such as
the PASSWORDS/user accounts file on my BBS <small, unchanging files aren't any fun to
trash, now, are they??? ;) > -- and replicating the first 256 bytes on the second 256
bytes. That is, it would take all the low bytes of block numbers and copy 'em onto
where the high bytes of the block numbers were.
Loads of fun. Searching every 256th block on a 40,000 block disk isn't much better
than searching EVERY block on that disk. Took 7 hours of dedicated block editing to
fix. And it happened TWICE.
'Twas definitely a good incentive to get the SCSI upgrade.
<sigh>
Subj: Re: cache size 88-11-23 02:55:06 EST
From: AndyBoy1
Cache size:
This is purely opinions. I tend to run mine pretty small, 32k or 64k. However, when
more true GS/OS apps start to appear (like the one I'm writing :-) ) and they use
class 1 read calls with intelligent caching control ( like the one I'm writing :-) )
the optimum cache size is going to go up. A bit.
Multi-drive systems:
As has been so eloquently described, caching on multi-cpu peripherals is DANGEROUS.
In a word, -don't-.
--Andy
Subj: disabling GS/OS caching 88-11-26 23:11:54 EST
From: Dave Lyons
I think you'll have to write your own loaded device driver if you want to avoid
caching. That will solve _part_ of the problem--you still have to avoid doing
certain sorts of things, like doing _anything_ that allocates blocks on the volume
using one machine while any files are open & may be written to on the other machine.
And you'd want to avoid simultaneous operations that make any kind of change to a
directory, unless you're sure it's different directories & neither directory will
grow [which would cause the bitmap to be fiddled with].
There is no concurrency control built into the ProDOS volume structure (I mean, no
way to mark a directory block or a bitmap block as "WAIT! I have a copy of this in
RAM and will rewrite it shortly"), so you still need lots of intestinal fortitude to
share a device.
I don't know whether P8 or the ProDOS FST does any caching with no files open other
than through the device drivers. If it does, you could still be out of luck with
those bitmap blocks, for example
Subj: directory caching (Floyd) 88-11-26 23:19:00 EST
From: Dave Lyons
Forwarded message (from the wrong folder :-)
----
Subj: Disable directory cacheing 88-11-24 10:17:26 est
From: AFL Floyd
I don't think it is possible to disable the directory cacheing feature. If you don't
want to use the benefits of GS/OS, you might want to go back to using P16. :)
Floyd
Subj: Re: GS/OS 88-11-27 20:28:30 EST
From: AFA Parik
Heheh, Floyd was obviously enjoying his holiday so much he staggered through the
folders. :)
For those with the same problem, what I do is reboot upon a write by a different
computer. Obviously I am rebooting FREQUENTLY. I do have Orca on ROM disk so its
not very bad. Every time you are writing to the disk with a different computer, you
need to reboot. *sigh* Also NEVER, EVER, EVER read & write at the same time with a
CMS, you can read/read at the same time, but thats the extent of it. Even on
different volumes [ie, the second partition]. What I'm going to do is create a
image of my first hard drive on the second hard drive, so I'll have two systems that
are different but are identical. Gotta find time to copy 40 megs now...*Grin
Subj: GS/OS Pathname Storage 88-12-29 01:29:19 EST
From: AFA Parik
Does GS/OS *really* change Storage Types 1-3 to 1? I mean the storage types as in
SPARSE,TREE,etc -> STANDARD, EXTENDED,DIRECTORY/SUBDIRECTORY as per the GS/OS
documentation. Well, I keep getting storage type #2 instead of type #1 when I'm
editing a file, I do play around with the storage type however and before I go in and
find out what is going wrong I want to make sure GS/OS does indeed change all storage
types that are NOT $05 and $0D into $01.
Subj: Re: GS/OS 88-12-29 20:29:42 EST
From: TMH2
It does on a create.
Subj: storage type in Create parmlist 88-12-30 00:21:54 EST
From: Dave Lyons
Yes, the storage type parameter is changed to a 1 after a CREATE call if it was a 2
or 3. 5 (extended) and $D (subdirectory) are left alone.
Subj: Re: GS/OS 88-12-30 21:34:52 EST
From: AFA Parik
Heh, thanks, I thought I imagined the docs said the OPEN call returned with the
values as standard/extended/dir ONLY (since those were only listed :), a few minutes
of fiddling settled that question. :-)
Subj: Re: File Storage Types 89-01-27 03:55:06 EST
From: AndyBoy1
Regarding 1, 2, and 3 changing to 1:
At the application level, GS/OS only supports 3 storage classes:
1 = data only file
5 = data + resource file
D = subdirectory
That's it. For P16 compatibility, storage types 2 and 3 are mapped to 1.
I have just described the application level interface to GS/OS. Now, the Pro.FST
implements a file system which we all know and love, which has a 32 MB limitation,
etc, etc. And supports type 2 and 3 storage classes. But "gs/os" applications only
know file/resource/subdir, so those values on a ProDOS disk are mapped back to 1.
Remember: The Application Level interface is not necessarily the ProDOS disk
structure.
--Andy Stadler
Apple II System Software
Subj: Re: GS/OS Bugs 88-10-22 20:20:54 EST
From: Matt DTS
Pardon my bluntness, but I don't believe any of it. We tested most of what you say
and had no problems. Please be more specific:
1) "GS/OS wrote to the wrong file." Are you sure the program didn't use the wrong
reference number, or "assume" some device name when it shouldn't have?
2) Tools are locked down while executing and therefore can not be compacted. If what
you're saying is that the Window Manager has an unlocked handle that it doesn't
re-dereference after compaction occurs, then that's a different story. Please give
more details and we'll try to track it down.
3) The disk cache and /RAM5 both use memory obtained by the memory manager, and there
is no conflict. What do you mean by "don't get along"?
4) Same thing with the APW Linker. However, if you have your cache set too large,
the linker could possibly run out of memory. Again, what do you mean by "don't get
along"?
(I'll address the other one in the next memo since I have to go back and look to see
what it is again.)
--Matt
Subj: Re: GSOS Bugs 88-10-23 13:22:44 EST
From: HErwin
GSOS wrote to the wrong file--just so. The application had about 20 files open at
the time (it's a full-fledged RDBMS) and it was using C file i/o calls. The block
ended up in one of the index files, not in the underlying data file. Simultaneously
the event queue went blooey. I had to do quite a bit of work to recover.
Cache and /RAM5 don't get along--In the finder I was having trouble copying files
into /RAM5. The cache was set to 64 blocks. I would consistently get a blowup in
/RAM5 after transferring about 63 blocks. Memory is OK. Similar blowups were
occurring when I ran the linker.
Window manager problems--I have a game under development that redraws a window
frequently. Eventually, the redraw got garbled. I also have the TML calculator and
clock as NDAs. I brought them up and left in the corners of the screen while running
Hodge Podge. I went through a number of windows, and eventually when the screen was
being restored after closing a window, the face of the TML calculator became
garbaged.
Signed, "Black Thumb" Harry Erwin, an experienced beta tester.
Subj: Re: GSOS Bugs 88-10-23 17:13:02 EST
From: AFA Parik
Harry, have you tried some of the problems under the old
system disk? Obviously not the 20 open-file problem (heh, I
would imagine you'd have INSTANT problem there ;), but the
window manager stuff? In the orca/desktop I'll have multiple
windows open at once without a problem.
What does it do to the /RAM5 volume? Garbage up the entire
disk, or just stop copying things?
Subj: Re: GSOS Bugs? 88-10-23 17:47:42 EST
From: Dave Lyons
>GSOS wrote to the wrong file--just so. The application had
>about 20 files open at the time (it's a full-fledged RDBMS)
>and it was using C file i/o calls.
There isn't enough info to determine whether it's a GS/OS problem, a ProDOS FST
problem, an APW C library problem, a bug in your C program, or a bug in *any* other
part of the system. Anything that stomped on memory not belonging to it *could*
cause damage to GS/OS code or data structures, with the end result that you
experienced.
Whereever the problem is, I want to help you find it. If it *is* a GS/OS problem we
need to find a way to duplicate it so we can present it to Apple.
>Cache and /RAM5 don't get along--In the finder I was having
>trouble copying files into /RAM5. The cache was set to 64
>blocks. I would consistently get a blowup in /RAM5 after
>transferring about 63 blocks. Memory is OK. Similar blowups
>were occurring when I ran the linker.
I've never had trouble with the Cache and /RAM5 myself. What sort of trouble were
you having copying to /RAM5? If the minimum and maximum on /RAM5 are not equal, the
Finder will be unable to copy large amounts of stuff to it at one time. This is
because /RAM5 requests memory as it is written to when max>min, and the Finder may
already be using all the available memory for the stuff it just read and is trying to
write.
What is a "blowup"?
Window manager/hodge podge/TML Calculator problems--again, there isn't enough info to
narrow down the problem. There may be a problem with Window Manager, Hodge Podge,
the TML Calculator, or *any* other part of the system. The first step is to be able
to to duplicate the problem reliably if possible. Utilities like Nifty List can be
very useful in helping track down problems. (Nifty List is Shareware, available in
the library, by me.)
--Dave Lyons
Subj: /RAM5 clarification 88-10-24 01:10:39 EST
From: Dave Lyons
To clarify, /RAM5 starts out allocated to its MINIMUM size setting, and it grows up
to its maximum as necessary. If you set min=max, /RAM5 won't have to allocate memory
on the fly.
Subj: GSOS Bugs or Bad RAM? 88-10-24 16:10:32 EST
From: AFL Jim
I might ask how you *know* you've got good RAM?
Apple's built-in (closed-apple/control/reset) won't find anything but completely dead
RAM - either will Apple Dealer Diagnostics. They both read too quickly after writing
to catch chips that don't like the CAS before RAS refresh method. I could use a
better test if anyone has one :)
Jim
Subj: Re: GSOS Bugs 88-10-24 17:35:41 EST
From: HErwin
I had a work-around for the 20-file problem (actually 35--I counted)--close when not
in use.
Window manager problem is new. It's OK on 3.1.
RAM5 condition is trashed. The OS tells me so when I try to mess with it.
Looks like I've got a new one. With 35 files open, lseek (C) gets lost. Location is
5880 (base 16) into the file. Whence is 0. File is #13 (base 10). Record before
can be found easily. lseek had just found the record, and I was about to do a random
write. Interesting. Further reports later this week.
Harry
Subj: Re: GSOS Bugs 88-10-24 17:42:33 EST
From: ScottG25
Jim,
I mentioned almost the same thing to Harry on StarPort (he's a regular user there),
and outlined how to write an efficient memory diagnostic. To make a long story
short, ram was my problem with GS/OS as well _AND_ the diags (from disk) did not
catch it, either.
Scott
Subj: Re: GSOS Bugs 88-10-24 17:44:41 EST
From: HErwin
I'll put together fuller problem descriptions over the next few days. The Hodge
Podge problem is easiest to recreate. Recompile it in C, change it to S16, and
launch it. Do some up and downs with font windows with the TML calculator and clock
underneath. I'll spend some time putting together a procedure this week. . . .
Harry Erwin
Subj: Re: GSOS Bugs 88-10-24 17:47:28 EST
From: HErwin
RAM is 1.28 Meg. Settings were 256/256. Nothing on RAM5 at the time. Cache was
64K.
Harry
Subj: Re: GSOS Bugs 88-10-24 17:49:36 EST
From: HErwin
Possible problem. I used the dealer diagnostics to check. The chip numbers are
supposedly good.
Harry
Subj: Re: GSOS Bugs and RAM 88-10-24 22:14:57 EST
From: AFA Gary J
Is it just me, or is GS/OS more sensitive to RAM timing than previous operating
system versions? (And if so, why??) I had to replace some of the chips on my RAM
card when I got GS/OS because it wouldn't even boot properly with the RAM I had (it
kept giving weird file errors, like end of file error, and stuff like that). Before
I got GS/OS, I had NO problems with my memory (at least that I noticed). Things have
been running smoothly since I changed the chips. (Anyone else have these problems?)
The memory test I use for testing my chips is the Checkmate MultiRAM GS software. In
order to obtain reasonably accurate results, you must run any IIGS memory test for
two hours or more (overnight, if possible).
Gary
Subj: Re: GSOS Bugs 88-10-24 22:49:41 EST
From: ScottG25
Gary,
Yes! I had a problem that I posted to earlier in the large GS/OS folder. It
concerned an _Open call (P16 type) resting on a page boundary. The program the call
was in always got loaded at the same place (my system configuration didn't change at
any time). It turns out that I had some bad ram that the GS dealer diags, didn't
catch. The way I found it was to write a small program that just kept reading -
comparing - and writing the call sequence back into ram at that page boundary. After
about 5 mins the small program bombed with the A-reg not what it should be (the
compare was done with immediate values isolated from the bank in question after
loading the A-reg with the suspect addresses value--of course this assumes the A-reg
is not bad). Maybe the problems are surfacing because of the speed increase in GS/OS
(timing as you mentioned). I've seen quite a few of these type problems surface on
other computers (DEC-VAX) after a major OS release (rare, but the do occur).
Perhaps Matt knows others who have had similar experiences with Apples.
Subj: Re: GSOS Bugs 88-10-26 19:38:09 EST
From: DennisDoms
I don't know of any of the "generic" RAM tests that will catch the (non)
CAS-before-RAS problems. I do know that my IIgs passed all the Apple diags repeatedly
(we're talking >12 hour run times here) and never reported a problem with the memory,
which ultimately *was* the problem (confirmed with the chip manufacturer, thanks to
Checkmate Technology). Moral: don't trust the diags. My experience is that programs
are much better (unfortunately) at finding problems (ain't they always?). :)
AFL Jim called me today and was hot on the trail of a proper RAM test method. I can
tell you what I used to demonstrate a problem on the IIgs: create a RAM5 volume the
size of your RAM card, fill it with files, and start verifying the files S L O W L Y
(that is, pause several minutes). I noticed that I couldn't re-boot off the RAM disk
if I left it (and the computer) "idling" with 8-bit software (ProDOS 8 or Apple
Pascal OS) for about 15-20 minutes. Apparently the key is to have a sufficient time
lag between accessing the address lines of the memory card chips so that you can see
if the internal refresh circuitry is working (Jim is tracking down a suitable way to
implement this in a test).
Subj: Re: GSOS Bugs 88-10-26 20:42:16 EST
From: SkipS
I can verify from personal experience that the Dealer Diagnostic
doesn't catch many RAM problems. RAM failures can obviously cause all kinds of
strange results, which is what I was having after upgrading to GS/OS. The diagnostics
reported no errors, yet I just knew there was something fishy. I decided to inspect
the RAM chips and reseat them anyway and low and behold I found a bent pin that was
very well desguised. I haven't had a problem since and I can't explain why the
failures began after I upgraded. I never opened the machine so I know it was like
that before the upgrade. Moral: check and double check your RAM chips for bent pins
and proper seating! The diagnostics are not fool proof!
Skip
Subj: Re: GSOS Bugs 88-10-26 20:43:37 EST
From: ScottG25
That's quite interesting, I wonder, did it do it every time, Dennis? This almost
implies that it is a memory synchronization problem (interaction of MegaII and FPI
chips)... Interesting... Please post more information, when you get it! I hope Jim
comes up with something good... I wonder just how the diags tests, and if they test
for crosstalk by writing to one address, and then reading the addresses to either
side of the one being written to and checking for a change... Interesting stuff!
Subj: Re: GSOS Bugs 88-10-27 11:45:45 EST
From: AFL Jim
Maybe we should start a new topic on memory test routines??
Subj: Re: GSOS Bugs 88-11-03 18:20:46 EST
From: Chip65816
I have had problems which I think I have traced to the Cache DA.
I am using a Battery-backed RAM disk in slot 6 with 1MEG. I did not have any
problems until GS/OS. After Installing the system files, everything seems to work
fine, but after a few hours of file manipulation etc., I get Bad Blocks out of range
according to Mr. Fixit. Data is missing in the RAM volume. If I don't do anything,
eventually enough files get messed up that GS/OS won't boot (it crashes into the
monitor on load or other bad things). If, however, I set the Cache to 0K, I have no
problems at all. (At least not yet) Any ideas?
Chip Welch
Subj: Re: GSOS Bugs 88-11-04 15:34:22 EST
From: AFL Jim
Chip, this could be another in the series of bad DRAM problems.
Subj: Re: GSOS Bugs 88-11-05 16:43:00 EST
From: AFA John
Jim,
You mentioned bad RAM in the previous message and I was wondering whether this is
becoming prevalent now days. This is not the first time I have heard mention of bad
RAM and would like to know what is causing it, or who's chip are the problems.
John
Subj: Re: GSOS Bugs 88-11-05 21:53:40 EST
From: JimLaz
The easiest solution is to keep your Catche set at 0K. Apparently GS/OS is thinking
the RAM/ROM Disk is a 800k drive and is acting strangly. I have RAMKeeper and the
Catche works fine with it.
JimLaz
Subj: Re: GSOS Bugs 88-11-06 03:19:45 EST
From: Dave Lyons
Mmm...I dunno about that--if you've got bad RAM, setting your GS/OS cache to 0 is
only a temporary solution at best. & I'm confident that GS/OS does *not* think your
disk cache is a disk device. I use a variable-sized 0-1024K /RAM5 with a nonzero
GS/OS cache with no apparent problems.
--Dave L
Subj: Re: GSOS Bugs 88-11-06 21:27:07 EST
From: JSchober
Excuse me for being ignorant (again), but does the GS/OS Cache cache ONLY directory
blocks, or also data blocks?
Anyway, what's the verdict .... is the Cache too dangerous to be worth using? :( You
people seem to use GS/OS much more than I do.........
--Joe
Subj: GS/OS cache 88-11-06 23:05:03 EST
From: Dave Lyons
Joe, *if* you trust my memory:
GS/OS *always* has a 16K cache for directory blocks. In addition to that, you can
use the Cache NDA to set a nonzero size for your data block cache; data blocks are
cached *only* during class-1 GS/OS calls that specifically request it (so stuff that
was written before GS/OS came out will never cache data blocks).
Subj: Re: GSOS Bugs 88-11-09 22:46:42 EST
From: JSchober
Alright, I'll buy that...
And that's where the SESSION feature comes in??
<no, I STILL haven't gotten the GS/OS Ref. It costs more than $2.32. :( >
Subj: Re: GSOS Bugs 88-11-10 02:19:13 EST
From: Matt DTS
Joe:
Don't be cheap. We worked hard to make it a good book. :-)
GS/OS automatically caches "system" blocks (directories, bit-maps, etc.) and will
cache "application" blocks (non-system blocks) on request. See GS/OS TN #3,
"Pointers on Caching", arriving upon your steps sometime this month, certified
developers.
--Matt
Subj: Re: GSOS Cache 88-11-20 02:57:01 EST
From: AndyBoy1
Matt already answered part of this, but I'll throw in my $0.02.
CACHE SIZE
The GS/OS cache is a variable-sized cache, adjustable by the user from 0-n where n
depends on the total system RAM size. However, turning off the cache would hurt the
system so much that it actually bottoms out at 16k.
ONLY ONE CACHE
There is only one cache. Caching is -handled- by device drivers but is -controlled-
by FST's with some guidance from the applications. What the heck does that mean?
First, although a driver receives a "cache-request" flag as part of a read or write
call, it is up to the driver whether to cache or not. This is because some devices
should not ever be cached, and only the driver knows for sure. For example, a RAM
disk driver knows that RAM disks should never be cached.
The FST's make the cache requests because the FST's can make better cache decisions
on a block-by-block basis. There is no such animal as a "directory" cache or a
"data" cache. The ProDOS FST (-not- GS/OS) makes the following cache priority
decision: "system blocks" are cached, and "data blocks" aren't.
APPLICATION CONTROL OF CACHING
An application using Class 1 calls may override the cache priority and request
caching of data blocks. Matt mentions a technote which describes this aspect better,
but to summarize, don't cache entire files. Only cache segments of files which are
repeatedly used.
SESSIONS
The GS/OS cache is a 'write-through' cache. This means that while a read call may
simply copy from the cache, every write call generates disk activity whether cached
or not. This is a safer cache because the disk itself is always up-to-date.
Sometimes, however, an application may be able to 'group' disk activities. These
should be sequences of disk activities which will always occur together, with no
opportunity for the user to remove the media. For example, if I made an entry in my
home accounting package and it had to go out and update the ledger, payroll, finance,
taxes, and misc files all together, this would be a place to use a session.
When you turn on sessions, the cache becomes write-deferred. If you write to a block
in the cache, it will simply update the data in the cache. If the cache is full and
a dirty block must be purged, it will first be written to disk. The application must
now make a complete sequence of disk activities.
Finally, when the session is ended, the entire cache is scanned and all dirty blocks
are written to the disk. BUT: They are written in block order, so the head won't
thrash; and blocks which were updated more than once during the session, are still
only written once.
Hope that clears up some of the confusion.
Andy Stadler
Apple II System Software
Subj: Re: GSOS Bugs 88-11-23 01:18:39 EST
From: JSchober
Dave... I agree totally! I usually don't stay in GS/OS long enough to have gotten any
directory blocks majorly scrambled (only one bad-file-count error), but I'm not
particularly looking forward to that day, either. Checksums are easy to do, and
practically foolproof. (Yeah, yeah, you could do CRC's or triplicates of every block
for verification purposes, but all you NEED is something simple like a checksum!) If
we get lucky, maybe we'll see that added in System 4.1. :)
Matt... Well, $2.32 is an approximate figure, yes, but it's roughly accurate. It'll
be a while before I can afford any books, <sigh>.
And we won't even think about where my certified developership went to, so I'll just
wait for the TN's to hit ALink.
Bloop.
--Joey
Subj: Re: GSOS Bugs 88-11-25 21:38:25 EST
From: Guy Rice
I have my GS/OS cache set to 256K (I have 2.25megs of total RAM, so I can afford to
set that much aside), and I've never had any problem with it either interfering with
/RAM5 (set to 128K on my system) or with it having its contents scrambled with random
stuff like Dave's font-list-in-the-directory problem. However, I'd feel safer
knowing there was a checksum of some sort - I've accidently trashed memory before
while programming in assembly. (I really hosed over APW once... well, more than
once, actually... :) If you think it would take too much time, maybe you could make
a "checksum cache" bit in the system preferences or something that could be left
normal by all programs except assemblers, compilers, and stuff like that...
GTR
Subj: Re: GSOS Bugs and Disk cache 88-12-24 12:46:03 EST
From: KKASHMAREK
I have found the discussion about cache all very interesting. Micol Advanced Basic
loads up my cache, set at 512K, and seems to lock in about 160K, and no application
is able to use cache again after that. For example, using ORCA/Pascal, first CMPL
command for a source file loads up the compiler and linker in memory. Second CMPL is
much faster since these modules are memory restartable. Also, second CMPL does not
access hard disk for link library searching. After running Micol Advanced Basic, this
is no longer true. Compiler and linker must be reloaded from disk, and second CMPL
does not take advantage of cache for link library searches (much disk I/O during
linking).
Sure wish the default for cache use was yes by the ProDOS FST. Could make everything
faster, and force use of the cache LRU algorithm to see if it really works.
Certainly glad directory blocks are cached and bit maps. The bit map is critical for
large volume hard disks that are almost full. I don't use RAM5 since I have a slot
based RAM card available. I keep the cache set to 128K normally, although it seldom
gets above 32K.
Subj: GS/OS Bugs 89-01-24 19:37:22 EST
From: BrianG19 Msgs: 35 (89-02-07)
I have found several bugs in GS/OS, bugs which have been verified with other
developers:
1] When saving large files consisting of mostly $00's, the file size in the
directory are very,very wrong. EX. Create a black picture with a paintprogram (all
$00) and save it. Some programs will not load it back in, because the filesize is
wrong. Or, if you go to the finder and try to copy a previously created file of the
same genre, the new copy will have the wrong file size also.
2] It seems that on occasions, the loader will write a few bytes into the program,
thus crashing it occasionally, or the relocator does not work.
I am interested in what other bugs have been found.
-Brian Greensto
Subj: Re: GS/OS Bugs 89-01-24 20:43:02 EST
From: DennisDoms
Item 1 ("small" files) is probably due to the ProDOS FST making files with long runs
of $00 bytes sparse; check the endfile for the file size (not the block count). If
the application is not identifying the file correctly because it's checking the block
count rather than endfile, then it's the application's fault.
Subj: Re: GS/OS Bugs 89-01-25 14:05:05 EST
From: AFL Floyd
Dennis is quite right. Certain paint programs, like PaintWorks, look at the block
count instead of the EOF size like they're supposed to. Lousy programming.
The ProDOS FST *automatically* creates sparse files when writing out zeroed blocks.
This would be invisible to any application that was written properly.
Floy
Subj: Random Bytes? 89-01-25 22:41:08 EST
From: AFA Gary J
Brian,
What do you mean by random bytes being written into the code? Could you be more
specific?
Gary
Subj: Re: GS/OS Bugs 89-01-25 23:27:39 EST
From: DaviesDoug
Yah, I noticed the sparse file creation too. I was doing a SHR screen save (desk
accessory) and my file kept coming out to 43 blocks instead of 65. Man was I
confused. But I did a CMP in ORCA and sure enough the files are the same. Pretty
neat! I am working on an application that copies files and was worried I would have
to treat sparse files differently, but GSOS is going to do this for me automatically!
DEFINATELY NOT A BUG, it is a wonderful feature, just confusing at first.
I've gone through and recopied alot of my files to make them smaller. Alink.Sys16
gets cut down by like 100 blocks if you copy it under GSOS, and loads a little bit
quicker!!!
Subj: Re: Random Bytes 89-01-28 12:40:58 EST
From: BrianG19
What I mean... and I have heard of the same thing happening to other developers... is
that my application which I am writing will crash 100% when I used GS/OS, not Prodos
1.6. Its not the program's fault, because if I link the files in a different order,
then it crashes in a different part of the program, and when I was trying to find the
bug, I eliminated it down to the first 50 lines of my program which is just tool
startup calls which are perfectly valid unless there has been a change in the tool
call protocol with GS/OS. Other people have reported the same thing, but its
impossible to trace the bug anyfarther back than to the ToolStartUp calls. I
dunno...
-Brian
Subj: random memory trashing 89-01-28 16:14:06 EST
From: Dave Lyons
Brian, I seriously want to get to the bottom of any random memory trashing which may
be going on anywhere in the system. It _is_ possible to trace this kind of thing--it
may not be fun, but it is possible.
If you are willing to e-mail me part or all of your program via "Send File By
Mail..." in the post office (either source or object), I will see what I can figure
out. There are a _lot_ of things you can do wrong in tool startups, etc, that will
not always cause problems, or at least not noticable problems.
It's also certainly possible you're being bitten by a legitimate bug in the system,
but either way, I want to get to the bottom of it: either to restore your confidence
in the system or to get the bug repaired.
--Dave Lyons
Subj: Re: GS/OS Bugs 89-01-29 20:44:19 EST
From: AFA Parik
The only thing I can think of is the #$012000 reservations... it could be crashing
there since $012000+ will PROBABLY be used when running (especially if you are in
Orca/M, etc). Try running the program through the debugger and seeing where it
crashes exactly...
Subj: Re: GS/OS Bugs 89-01-30 20:20:56 EST
From: BrianG19
I am using Merlin 8/16, but I dont think thats the problem, because EVERYTHING works
PERFECTLY under P16... Its GOT to be GS/OS.
Subj: Finding the bugs 89-01-30 22:12:18 EST
From: Dave Lyons
Brian, the reasoning "It works with P16; it doesn't work with GS/OS; GS/OS is buggy"
is wrong. In the GS environment there are a lot of things your program can do wrong
that will _eventaully_ cause you a problem, when you get unlucky enough to have the
memory you trash be important.
In the case of the code you posted a few messages back, the problem is that your code
assumes the B register is set to some particular bank, when in fact it has a no
defined value at that point. (I'm assuming that the code you showed is everything
that has executed starting with the beginning of your program.) All your loads and
stores of MyID, MasterID, XHandle, CharSetHandle, etc, are happening in a _random_
64K bank of memory, usually one your program doesn't own. As "luck" would have it,
it seems that when you run your program under GS/OS with your particular set of DAs &
drivers installed, your "global variables" bank is in a different bank from your
program code, and the B register happens to be set to your program code bank! So
your own STAs are trashing your code. [At least, that's how it appears to me w/
limited info about your program--I don't know how many segments it has, for example.
You might take a look at Nifty List in the library {Shareware, $15, by me}, since it
will easily show you what memory your program owns, among many other things.]
If your globals are in the same segment as your code, you can use PHK PLB to set the
B register. If they are in a different segment, use something like
LDA #MyID|-16
XBA
PHA
PLB
PLB
Let me know if this solves your problems!
--Dav
Subj: non-GS/OS bugs 89-01-30 22:22:26 EST
From: Dave Lyons
Forgot to mention 2 other things in your code, Brian: you should check for an error
code after the NewHandle that tries to allocate the $600 bytes of direct page space;
and be careful about using the CharSet value, because your code leaves the handle
unlocked. CharSet will become invalid on the next operation that can allocate memory
[which is not the same as saying it will fail in an obvious way...using the pointer
anyway might not cause a crash for a long time...like until you release your
program!].
--Dave
Subj: Dave do you really waste 2 bytes 89-01-30 23:12:04 EST
From: DaviesDoug
Dave:
PEA MyId|-16
PLB
PLB
works a lot better than the way you did it (saves 2 bytes)
Subj: Re: Wasting 2 bytes 89-01-31 00:07:57 EST
From: DaviesDoug
Ooooops goofed:
PEA MyID|-8 ; not |-16 sorry
PLB
PLB
:)
Subj: Re: GS/OS Bugs 89-01-31 19:17:47 EST
From: BrianG19
Dave,
The data bank stuff is NOT the problem. The 2 lines before the routine I listed is
called the following lines are executed:
phk
plb
so, that's not why it crashes... I dunno.. my instinct says GS/OS.
-Brian
Subj: wasting 2 bytes 89-01-31 20:22:17 EST
From: Dave Lyons
Doug, no--typically I don't waste two bytes. Instead, I write in Pascal or C and
waste a whole bunch of them.
Subj: finding the bugs 89-01-31 20:24:46 EST
From: Dave Lyons
Brian--Okay, fine. Let's start again, then. Before you blame GS/OS, you're going to
have to show us all the code your program executes up until the point that something
has definitely been trashed. Don't leave anything out. If it's too large to post
the source, then use "send file by mail" in the Post Office to send me either the
source or the object, as your prefer, and I'll take a look at it.
Your code may or may not be at fault; if it is, I'll find the problem, and if it
isn't, then I'll be well on the way to finding a bug in the system somewhere.
Subj: Re: GS/OS Bugs 89-01-31 21:56:05 EST
From: AFA Parik
Brian,
running the program under the APW Debugger would be the EASIEST way to see where it
crashes. You did say it crashes definitely, didn't you (as in BRK $00, etc)? The
debugger is INVALUABLE in this aspect, you can see *EXACTLY* where it crashes as it
runs.
Subj: Re: GS/OS Bugs 89-02-01 20:27:51 EST
From: BrianG19
As I already told Dave Lyons:
This is the ONLY code that is executed once GS/OS has passes control to my program
before I am able to notice the 25 trashed bytes:
shortA (sep #$30 or whatever it is rep #$30.. i dunno)
stal $c010
:loop ldal $c000
bpl :loop
...
That's it! Either those lines are screwing up 25 bytes, or its GS/OS screwing them
up before control is passed to my program.
-Brian
Subj: finding the bugs 89-02-01 23:29:09 EST
From: Dave Lyons
(ShortA is SEP $30, and it also tells the assembler to generate appropriate-length
immediate-mode instructions.)
Other possibilities: The bytes were wrong to begin with, rather than getting
trashed. (If the program works under ProDOS 16, is there something out of the
ordinary about the OMF file that the GS/OS Loader deals with differently or
incorrectly?)
The 25 possibly-trashed bytes appear to be valid code; WHAT WERE THEY SUPPOSED TO BE?
Are you Listing them with the proper m/x register settings? Use Ctrl-N for 16-bit
registers or Ctrl-R for 8-bit registers immediately before Listing in Nifty List to
make sure you've got the right settings. (I say to do it immediately before because
Listing through a SEP, REP, or XCE instruction affects Nifty List's settings.)
Subj: Re: GS/OS Bugs 89-02-02 13:17:38 EST
From: Dave HDS
From what I recall, GS/OS was originally not able to correctly load OML Version 1
files. A long shot, but worth checking, especially if the code is being genorated
from Merlin 8/16...
If this is the case, just use the APW Compact (or ORCA/M equiv.) to update/convert
the file to the lastest/most compact OML format and then try executing it...
Dave
Subj: Re: GS/OS Bugs 89-02-02 18:46:23 EST
From: AFL Scott
Hmm... I bet you mean OMF #1... Funny, I've had no problems, and I always have
problems, very wierd ones (most are my fault, tho...)...
Subj: The Final Say 89-02-02 19:34:03 EST
From: BrianG19
Ok, folks, I screwed up. To make a long story short, those things that I thought
were bugs in GS/OS are not bugs, but rather mistakes that _I_ made. I guess I jumped
the gun. Sorry. As far as I know now, there are no fatal bugs in GS/OS.
Subj: GS/OS & OMF1? Locating bugs 89-02-02 20:18:26 EST
From: Dave Lyons
Hmmm...I haven't had any trouble with GS/OS and OMF v1 files--has anybody had
problems? (With the GS/OS on System Disk 4.0, I mean--not the development versions!)
Brian, I'm glad you found the problem w/ your code. Brian described the problem in
more detail by e-mail, and I'm going to summarize it because it may save other
programmer's some frustration. It turned out that under ProDOS 16 the program's
direct page was pre-filled with zeroes (or, at least, it typically had zeroes in it
by accident), and a two-byte value's high byte was never being initialized.
This suggests a good defensive-programming technique: consider having your program
fill its direct page with something Weird like $77s at the beginning--that way you'd
be more likely to uncover problems with uninitialized values right away.
On the other hand, if you're worried that you're assuming some direct-page values are
$00 when they have never been initialized, you might as well have your program fill
the thing with $00s in the first place!
To get back to the topic at hand: GS/OS bugs probably exist, but finding them hard
and time-consuming, and you should blame your own program _first_, partly because
it's easier to look in your own program than in the system!
--Dave
Subj: Re: GS/OS Bugs 89-02-02 21:51:19 EST
From: AFL Scott
Dave,
I agree 100% as you WELL know!:)
Scott
Subj: OMF #1 89-02-03 10:38:14 EST
From: MikeW50
GS/OS loads OMF #1 just fine. There may well be some bugs with some features of the
OMF, but if so, I have never encountered them.
Mike Westerfield
Subj: Dave's punctuation 89-02-03 19:52:34 EST
From: Dave Lyons
(Oops! Pardon my extra apostrophe 3 msgs back. :)
Subj: stack/direct-page segment, etc 89-02-04 14:22:48 EST
From: Dave Lyons
Ummm...Coach, how are you typing in your messages? The up-arrow key should be of
great utility for making changes to previous paragraphs. :)
A couple notes on filling the stack/dir-pg segment. (1) Be careful _not_ to
overwrite part of the stack that already has useful stuff on it! You can safely fill
up to and including the byte that the S register points to. (2) When you look for
the _pattern_ remaining to decide what the peak stack use was while your program ran,
keep in mind that at least one toolset does (or used to) allocate a whole _page_ (256
bytes) of stack space, and I bet it doesn't use all of it! It could "hop over" your
pattern and use some more memory below where you think it got. Just to confuse you.
Subj: Stack Overflows 89-02-06 15:38:07 EST
From: MikeW50
Also, if you happen to be using high-level languages, ORCA/Pascal has an option to
check for stack overflows.
Mike Westerfield
Subj: discovering stack overflows 89-02-06 23:38:43 EST
From: Dave Lyons
Mike, I'm curious...how does the ORCA/Pascal stack overflow detection work? Given
the problem I mentioned a few messages ago (if this is the right folder), I don't see
a nice reliable way to do it.
Subj: Stack Overflows 89-02-07 16:55:14 EST
From: MikeW50
It isn't 100% reliable, Dave, at least not with tool calls. Basically, though,
Pascal knows how much stack space it will need in a given subroutine (this
information is available from the compile step), and it knows where the bottom of the
stack is. The check subtracts the amount of space needed from the current stack
location, and then looks to see if the result is above the min stack location. If
not, it generates a run time error.
Mike Westerfield
Subj: Re: Compliments To ORCA/Pascal 89-02-07 21:54:39 EST
From: Coach101
A simple check (the stack check) that does not take a lot of time
and could save some real frustation in finding "random" disasters
in a "finsihed" program.
Dave, with respect to editing my message, I knew there were a
bunch of the "mentioned" typo and since I still put in my own
carriage returns (makes it easier to read when you download a
folder since I have not updated my "print" program to do "word
wrapping") making simple changes back up in the text can take
some time if you are a "neatnik". Ergo, I put the _EQU_ at the
end of the message in the folder.