Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 GARFIELD 20/11/84; site garfield.UUCP Path: utzoo!utcsri!utai!garfield!john13 From: john13@garfield.UUCP Newsgroups: net.micro.amiga Subject: Memory && Disks && Flicker Message-ID: <2834@garfield.UUCP> Date: Mon, 20-Oct-86 14:43:56 EDT Article-I.D.: garfield.2834 Posted: Mon Oct 20 14:43:56 1986 Date-Received: Sat, 25-Oct-86 16:45:57 EDT Sender: perry@garfield.UUCP Reply-To: john13@garfield.UUCP (John Russell) Organization: Memorial U. of Nfld. C.S. Dept., St. John's Lines: 100 Keywords: *subject_line [] 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.cdn