john13@garfield.UUCP (10/20/86)
[]
Some questions and observations about having 512K of memory to work with:
- the ram disk handler is great; however, if you try to copy too much into
memory, you will get a guru. No warning beforehand. Why not?
- Matt Dillon's shell is great; if you try to copy too much into memory,
you get a warning, "Volume is full". However I have had this happen
when mem said there was ~170K free and I was moving around 10K files.
PS Matt, where did ps go?
- Manx is great; if it gets low on memory while compiling, it just does
less optimizing, builds smaller tables, and sometimes doesn't delete
the .asm file. It knows it is running out and takes steps to prevent
it. However, (but I'm not 1,000,000% sure on this) if not enough memory
can be saved by the above steps, it seems like it crashes with the
prettiest pattern on the screen you ever saw (too bad I couldn't
SaveILBM it *:^). This was when I forgot about all of VT100's include
files. Off the topic: when I receive files Kermit-wise, they become
double spaced. Any way to avoid this?
- Multitasking is great; as long as there is some memory to be had, start
up another program. I have the Manx compiler, linker, and system
library in memory right now as I use VT100 on a seperate screen.
- Editors are not great. Ed and Emacs both hold their breath & turn blue
when a lot is in memory. In the case of emacs, it told me it could not
allocate 80 more bytes (this is with 100K+ free, according to mem).
Fine, sez I. I remove several K worth of .o files and such (with
emacs still running), but it still can't find those 80 bytes. At this
very moment, ed (not in memory) refuses to work with a file that is...
lemme see...1997 bytes long. Hang on a sec again...mem tells me I
have 85968 bytes left. Since boot up, I've done nothing but copy some
(big) files into ram:, 1 assign, invoke vt100, and the failed ed, so I
can't see how fragmentation could be that big a problem.
Those #$#$%$%$^$^& disks:
- now I know why blue was always my favourite colour. Blue disks work.
Tan-coloured ones don't. This is not theory, it is (suitably disclaimered)
fact. Blue disks, whether they have some company's name on them or are
no-names, last forever. Never had one go bad (except for an original
Deluxe Paint). All the important stuff goes on them.
- Tan coloured disks, whether they have some company's initials on them or
are no-names, cannot stand up to writing. Copy something onto them, fine.
As long as you don't alter it, you are safe (so far, in my experience).
But if you do a lot of writing to one of them, expect at some point to
encounter the following scenario:
------------------------------------
| Volume Foo has a read/write error|
------------------------------------
Sweat starts to trickle down your brow; what should you do?
I've Disksalv'ed and Marauderized disks that have done this.
Disksalv refuses to read almost all of the directory blocks,
and Marauder copies the read write error onto the other disk.
Too bad you can't save the situation a la Infocom, because the VERY
NEXT THING that happens is that the drive(s) start grinding, and
you go from read/write error to disk is unreadable and the dreaded
DF?:NDOS icon. Bye-bye files (yesterday all the ray-tracing images,
before that a slideshow, before that a work disk with C sources).
Hello bulk tape eraser, if you are brave and/or foolish.
- the jury (me) is out on red disks (from a famous name I won't mention).
I've only put things onto 3 of them, so I can't comment on their
reliability. Except that I noticed a missing spring on the third one...
right out of the box.
Flicker:
- why are there 2 Amiga monitors? The one in front of me is a 1080, with
the brightness, etc controls written in black on the little door on the
front. The screen is much more glare-prone, flicker-prone, and colour-
not-as-good prone than the other monitors, also 1080, with the controls
labelled with raised words the same colour as the rest of the case (the
same colour as those tan disks!).
- even so, I frequently work in hi-res, without going blind yet. I change
the "white" in hi-res to a medium grey, and the title bars stop flickering.
If I need to use white, I make a different colour white; same with black.
According to a rumour (and Lord knows there are enough of those, with
precious little in the way of official announcements) the first 2 colours
on the palette (called the "clear colours" by the rumourer) are not
well liked by the Amiga's video chip, which results in their being more
flickery than the others. Sometimes experience seems to bear this out,
sometimes not (maybe it depends on the bleary-eyedness of the viewer *:^),
but I use other colours for background/primary foreground anyway, just in
case. Results, especially on the other monitors with screens not in direct
sunlight and lights dim, are rock-steady and extremely impressive.
Disclaimer: Only I know what I'm talking about, and sometimes not I always
though don't.
Interesting thing to do: Naw, that's enough for now, I'll put it in next time.
John Russell
UUCP: {akgua,allegra,cbosgd,ihnp4,utcsri}!garfield!john13
CDNNET: john13@garfield.mun.cdnchiu@princeton.UUCP (Kenneth Chiu) (10/26/86)
In article <2834@garfield.UUCP> john13@garfield.UUCP (John Russell) writes: >. . .if it[Manx] gets low on memory while compiling, it just does less >optimizing, builds smaller tables, and sometimes doesn't delete the .asm file. >It knows it is running out and takes steps to prevent it. However, . . .if not >enough memory can be saved by the above steps, it seems like it crashes. . . Hmm. . . I've never had it crash on me like that. Mine says "Out of memory!" BTW, how do you know it takes these economizing steps? >Off the topic: when I receive files Kermit-wise, they become double spaced. Any >way to avoid this? Make sure both ends are on the same wavelength, either image or CR/LF. >Blue disks work. Tan-coloured ones don't. This is not theory, it is (suitably >disclaimered) fact. Blue disks, whether they have some company's name on them >or are no-names, last forever. . . Tan coloured disks, whether they have some >company's initials on them or are no-names, cannot stand up to writing. Maybe blue disks aren't as permeable to cosmic radiation. Why don't you try putting the tan ones under a pyramid. :-) -- Kenneth Chiu UUCP: princeton!chiu Princeton University Computer Science Department BITNET: 6031801@PUCC
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/27/86)
>Some questions and observations about having 512K of memory to work with: My system is 512K also. >- the ram disk handler is great; however, if you try to copy too much into > memory, you will get a guru. No warning beforehand. Why not? > >- Matt Dillon's shell is great; if you try to copy too much into memory, > you get a warning, "Volume is full". However I have had this happen > when mem said there was ~170K free and I was moving around 10K files. > PS Matt, where did ps go? My shell has nothing to do with the RAM: drive.. must be something else. I didn't put a PS in because I thought it was too costly to make resident. I'm glad you like my shell though. (it also sounds like you are using a 1.1 system). >- Editors are not great. Ed and Emacs both hold their breath & turn blue > when a lot is in memory. In the case of emacs, it told me it could not > allocate 80 more bytes (this is with 100K+ free, according to mem). > Fine, sez I. I remove several K worth of .o files and such (with > emacs still running), but it still can't find those 80 bytes. At this > very moment, ed (not in memory) refuses to work with a file that is... > lemme see...1997 bytes long. Hang on a sec again...mem tells me I > have 85968 bytes left. Since boot up, I've done nothing but copy some > (big) files into ram:, 1 assign, invoke vt100, and the failed ed, so I > can't see how fragmentation could be that big a problem. The problem is fragmentation.. ED tries to allocate huge chunks of memory and can fail even when you have 200K free!!!! (this has happened to me!). Hacker types like most developers become unconciously adept to doing things in the right order to avoid it. The real solution, however, lies in the software... they shouldn't expect to be able to allocate 100K contiguous memory. -Matt
perry@well.UUCP (Perry S. Kivolowitz) (10/27/86)
Use of ram: causes a lot of fragmentation to take place (true in versions previous to 1.2 gamma 1 - unknown yet if gamma 1 also does this). Although I don't intend this message as a plug...this was one of the reasons we (ASDG) wrote our recoverable ram disk driver. Perry
daveh@cbmvax.cbm.UUCP (Dave Haynie) (10/28/86)
> Keywords: *subject_line > > - now I know why blue was always my favourite colour. Blue disks work. > Tan-coloured ones don't. This does appear to be true; I've had lots of success with blue disks, only a few have gone bad. I tried very light tan disks once; never again! Black disks seem almost as good as blue :-). > - why are there 2 Amiga monitors? The one in front of me is a 1080, with > the brightness, etc controls written in black on the little door on the > front. The screen is much more glare-prone, flicker-prone, and colour- > not-as-good prone than the other monitors, also 1080, with the controls > labelled with raised words the same colour as the rest of the case (the > same colour as those tan disks!). They're probably from different vendors. Commodore OEM's the monitors. If the newer one is the better one, its called an improvement (if not, its called a cost reduction). > - even so, I frequently work in hi-res, without going blind yet. I change > the "white" in hi-res to a medium grey, and the title bars stop flickering. > If I need to use white, I make a different colour white; same with black. > According to a rumour (and Lord knows there are enough of those, with > precious little in the way of official announcements) the first 2 colours > on the palette (called the "clear colours" by the rumourer) are not > well liked by the Amiga's video chip, which results in their being more > flickery than the others. Nope. The video chip itself (Denise) puts out 4 bits of digital info for each of R, G, and B. The D-A conversion is done with a precision resistor network. The chip doesn't see any difference between a white and a grey. It most likely your eye. In interlaced mode, the perceived flicker is based of the apparent persistance of the image. This is a combination of how long the image actually remains on the screen, and how long the image is retained after that by your eye. The eye will retain a low brightness image longer than a high brightness image, that's why grey flickers less. Also, you'll see less border flicker between similar colors than between contrasting colors. If you really want some flicker, fill and interlaced screen with something like alternating lines of black and white. Also, in rectangular images, you get lots of boundary flicker, since you have large boundaries along two neighboring scan lines. A natural image, like what you see on TV, breaks boundaries up along several neighboring scan lines, so you wouldn't see as much, or even any flicker (compare Dave W.'s HAM images to a CLI or terminal in interlaced mode). This isn't a fault of the Amiga video per se, other than the fact that its a fault of the NTSC standard and the Amiga was designed to be compatible with this standard. > Disclaimer: Only I know what I'm talking about, and sometimes not I always > though don't. > > Interesting thing to do: Naw, that's enough for now, I'll put it in next time. > > John Russell > UUCP: {akgua,allegra,cbosgd,ihnp4,utcsri}!garfield!john13 > CDNNET: john13@garfield.mun.cdn -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "Laws to supress tend to strengthen what they would prohibit. This is the fine point on which all the legal professions of history have based their job security." -Bene Gesserit Coda These opinions are my own, though for a small fee they may be yours too. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner) (10/29/86)
You can't judge a disk by it's color. But you can often judge a disk
by the look and feel of it's shell. One the back of the disk, near the
write-protect slider, there is a small lozenge shaped depression.
You will find either "JAPAN", "USA", or nothing in this area.
This tells you where the shell was made. Nothing usually means USA.
We have found that many of the "USA" or "nothing" shells have occasional
problems seating in the drives. And an "occasional problem" is all you
need to trash a disk. The root block gets written out a bit off-kilter
and becomes unreadable when the disk is seated properly. Most of the
"JAPAN" disks that we get have shells that feel sturdy and thick, and
they generally seat very solidly in the drive.
I've had black, and tan, and blue "JAPAN" disks and I've never had
to throw one out. I've had blue and maroon "nothing" disks and have
flung several of these in the trash when they suddenly decided they
were Not DOS Disks.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Carolyn Scheppner -- CBM >>Amiga Technical Support<<
UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn
PHONE 215-431-9180
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=hamilton@uiucuxc.CSO.UIUC.EDU (10/31/86)
there hasn't been much mention of white disks :-). since i buy 'em locally in boxes of 50 (for $95), i'd be interested in hearing of any problems. these are "supposed" to be Sonys; so far i've gone thru 75 of them without a single glitch. wayne hamilton
danny@convex.UUCP (11/01/86)
On the subject of disks, I've found that the standard Sony's are simply the best and nothing else will do. I saved a few dollars buying Maxell's and found out why I was saving a few dollars. The Maxell's case is not completely sealed - you can get it open enough to fit a dime in. Also, the Maxell disks tend to make extra noises kinda like: shhhh shhh shhhh shhh shhh shhh I've never ever ever had a problem with my older Sony disks. The worst thing is that sometimes I'll insert one of my Maxell disks and it will imediately ask me for the Workbench - if I cancel it says it can't find the disk validator. Otherwise, it happily loads the disk validator then says insert my maxell in df0: I put it in, it asks for the maxell again in any drive, realizes it has it, then goes on. bIZzARe stuff. MORAL: Don't but Maxell disks (they were even BLUE!) but spend the extra few dollars on Sony's (by the way, you save bunches of money by just going to a clone shop or warehouse/mail order place - I got the Sony's for $25 when they are $50 at a major Mac store.......) Dan Wallach ...!ihnp4!convex!danny