mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (05/25/87)
In article <159@tahoma.ARPA> bakken@tahoma.ARPA (Dave Bakken) writes:
<I bought my Amiga in December of '85, and I chose it over the Atari
<because it was (and still is) the only PC to offer true multitasking.
Horsefeathers. OS/9 has been available on a fair number of machines
for years, and it has true multitasking. It even does it better than
the Amiga. (Can you say "resource tracking?" I knew you could. If
you're an Amiga hacker, you probably preceeded it with some
four-letter words and "missing.")
It's been at least three years since Radio Shack starting selling OS/9
for the Color Computer (I started 32 shells on one once, just to see
how it would run. Not bad...). With the introduction of the CoCo III
last year, Tandy announced only OS/9 for an OS. They also put in an
MMU. With the release of OS/9 level II early this year, you got a
windowing system, as well.
Of course, there are other multitasking OS's around for micros (CDOS,
MP/M, UnixFlex, BOSS (?), and probably others), but OS/9 is the only
one of them to get into widespread use. And having it on a CoCo meant
that I could buy a system that ran a pretty fair Unix clone (fair in
the sense of features; it was smaller & faster) for less than $1000
_complete_ three years ago.
You can run OS/9-68K on the Atari-ST, as well. But you then get the
problems of an OS that's not supported by the hardware vendor.
Anyone trying to decide between the ST and the Amiga ought to go look
at a CoCo (but be prepared for salesmen who'll try and sell you an
IBM-PC clone). If it does what you need, you could save a bundle.
<mike
P.S. - In spite of the above, I *do* think the Amiga's a wonderful
machine, and have only seen two personal computers that I'd be willing
to trade it for: Mark Crispin's DEC 20 and John Gilmore's Sun 3.
--
How many times do you have to fall Mike Meyer
While people stand there gawking? mwm@berkeley.edu
How many times do you have to fall ucbvax!mwm
Before you end up walking? mwm@ucbjade.BITNETmu106sbn@sdcc13.ucsd.EDU (Stephen Hartford) (05/27/87)
In article <3708@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) writes: >In article <159@tahoma.ARPA> bakken@tahoma.ARPA (Dave Bakken) writes: ><I bought my Amiga in December of '85, and I chose it over the Atari ><because it was (and still is) the only PC to offer true multitasking. > >Horsefeathers. OS/9 has been available on a fair number of machines >for years, and it has true multitasking. >It's been at least three years since Radio Shack starting selling OS/9 >for the Color Computer (I started 32 shells on one once, just to see >how it would run. Not bad...). With the introduction of the CoCo III >last year, Tandy announced only OS/9 for an OS. They also put in an >MMU. With the release of OS/9 level II early this year, you got a >windowing system, as well. > <mike I've been involved with the CoCo for over five years. Since the Atari ST and the Amiga have been released, I've purchased both, and sold my CoCo. True, the CoCo runs OS-9. I work at Computeware and we had Level 2 and CoCo 3's before almost anyone. This machine is a dog. I would hardly call the CoCo 3's "Data Address Translator" a MMU in any but the most primitive sense of the word. The windowing system Mike mentions, called "Multi-View", is NOT out yet, and Tandy has yet to announce when, if ever, this will be released. Graphics primitives are present in the Level 2 package, but the operating system barely uses them at all. When you get a chance, visit comp.sys.m6809, the newsgroup for the CoCo. Besides the fact that there's only 2-3 messages a day, you will notice all they ever talk about is the bugs in OS-9. Without going into further detail, I can assure everyone the CoCo is a computer from the past, and either an ST or Amiga is far superior. Even as far as price, the CoCo can not compete! Going by standard prices today, a CoCo with 512K, one drive, and a RGB monitor lists for $219+149+299+299= $950. With a similar 520 ST costing about $799, and an Amiga 500 (or discounted 1000) costing $950, there's no reason to buy a CoCo. The CoCo was a great machine in its day (1981 ~ 1985), I know, but it just doesn't cut it today. -- Stephen Hartford, programmer (a.k.a. student) /// -- \\\/// Internet: mu106sbn%sdcc13@sdcsvax.ucsd.edu \/// UUCP: ...!sdcsvax!sdcc13!mu106sbn
knudsen@ihwpt.UUCP (05/29/87)
In article <879@sdcc13.ucsd.EDU>, mu106sbn@sdcc13.ucsd.EDU (Stephen Hartford) writes: > Since the Atari ST and the Amiga have been released, > I've purchased both. Must be nice to be single with no kids. Some of us have to think bang per buck, or maybe just bucks. If I were starting from scratch, I'd get a mono 520 ST, but see below... > I would hardly call the CoCo 3's "Data Address Translator" a > MMU in any but the most primitive sense of the word. Better primitive than non-existant, which describes the MMUs on the Big A machines. Amiga's memory usage is a family embarrassment. I recall a posting by an Amiga user who found her AMiga used up 512K RAM faster for the same functions than OS9 on a 64K Coco! > When you > get a chance, visit comp.sys.m6809, the newsgroup for the CoCo. > Besides the fact that there's only 2-3 messages a day, you will Cuz we can play with our Cocos for days without finding any new bugs to post about... > notice all they ever talk about is the bugs in OS-9. Not "all." Funny you missed how they're still talking about the 40-folder bug in TOS, tho they've figured out how to mix single- and double-sided disk drives (which we Coconuts did two years earlier). I read the Amiga group in the early days, and it was nothing but guru meditation numbers (crashes) and who can-or-cannot stand the flicker on the 400-line interlace. A major "bug" in OS9 windows turned out to be a manual misprint. I won't repeat the things said about Atari and Amiga documentation; I mean, this is a family group here... Let's face it, these newsgroups are like the American press, for washing dirty laundry in public. Foreigners think the USA is a terribly corrupt place, because we talk about problems openly. Should we stop talking about bugs and fixes and how our machines could be BETTER, and just start cheerleading about how great our machines are? Leave that to the ads and salesmen! > > Even as far as price, the CoCo can not compete! Going by standard > prices today, a CoCo with 512K, one drive, and a RGB monitor lists > for $219+149+299+299= $950. Try 170+80+180+260 = $690 using mail-order discount prices. Of course, for REALLY overpriced 8-bit machines, we could go over to .Apple and flame about the II-GS -- gawd what a rip! > The CoCo was a great machine in its day (1981 > ~ 1985), I know, but it just doesn't cut it today. I think what you mean, Steve, is that given the costs of keyboard, cabinet, and peripherals, it makes more sense to build a NEW system around a 68000 than any 8-bit micro. I'll agree there. But for someone already heavily invested in Coco hard/soft ware, a Coco-3 upgrade gives lots more bang/buck than any other path, and lets us develop GEM-type features. PS: I don't want to start religious wars over, but this grenade landed in my newsgroup, so I just pulled the pin and tossed it back.... -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: <memory failure, too many digits> "Just say NO to MS-DOS!"
hah@isum.intel.com (Hans Hansen) (06/01/87)
In article <1710@ihwpt.ATT.COM> knudsen@ihwpt.ATT.COM (mike knudsen) writes: >In article <879@sdcc13.ucsd.EDU>, mu106sbn@sdcc13.ucsd.EDU (Stephen Hartford) writes: >> Since the Atari ST and the Amiga have been released, >> I've purchased both. > > [Some totally absurd nonsense by Mike Knudson to a good comparison of 3 > computers by Stephen Hartford.] > >PS: I don't want to start religious wars over, but this >grenade landed in my newsgroup, so I just pulled the pin >and tossed it back.... >-- >Mike J Knudsen Mike, while you found it necessary to defend the honor of your PET computer. Your total ignorance of the other computers that you mention is a massive miss use of net bandwidth. I am not saying don't post, just have your facts straight before you start typing. Please E-Mail all replies to hah@intelos Hans
rca@fico2.UUCP (06/01/87)
Hans, you describe Mike Knudsen's rebuttal to Stephen Hartford's critique of the Tandy Color Computer as a "massive misuse of net bandwidth" and "totally absurd nonsense" posted to "defend the honor of (his) pet computer" out of "total ignorance" towards the Amiga and ST. Without mentioning any examples of factual errors on Mike's part to back up this assertion, you then proceed to slap his hands by suggesting he "have his facts straight" before posting again. Could you please lower the flame level? I found Stephen's critique of the Color Computer, and Mike's subsequent rebuttal, to both contain some very good points. Please note that Mike freely admits that if he were to start over, he'd get a 520 ST rather than a Color Computer since, as he put it, "it makes more sense to build a new system around a 68000 than any 8-bit micro" (such as the Color Computer). This does not sound like "defending the honor of his pet computer" to me. It sounds like a very honest and frank assessment of reality. Your reply, on the other hand, was utterly unconvincing (though I am sure it was very emotionally satisfying to type it in). Sorry, "Nyah nyah nyah nyah nyah" just doesn't cut it. This "my computer can beat up your computer" stuff is pointless, anyway. Although I normally work with a Color Computer, I also have worked with, and very much appreciate, Amigas, Macs, and ST's. They are all very fine machines, and I can easily think of applications for which I would gladly use one of them over my present machine. -- "186,000 miles per second: it's not just a good idea--IT'S THE LAW!" [ Rick Adams -- Color Central Software -- Rohnert Park, CA ] [ USENET: ...!sun!lll-crg!well!fico2!rca Delphi: RICKADAMS ]
jimomura@lsuc.UUCP (06/02/87)
In article <749@omepd> hah@isum.UUCP (Hans Hansen) writes: >In article <1710@ihwpt.ATT.COM> knudsen@ihwpt.ATT.COM (mike knudsen) writes: >>In article <879@sdcc13.ucsd.EDU>, mu106sbn@sdcc13.ucsd.EDU (Stephen Hartford) writes: >>> Since the Atari ST and the Amiga have been released, >>> I've purchased both. >> >> [Some totally absurd nonsense by Mike Knudson to a good comparison of 3 >> computers by Stephen Hartford.] Hans, it's very easy to make a great generalization like this when it suits your purpose. What exactly was "totally absurd nonsense" in what Mike wrote? Having bought an ST and had a fair bit of contact lately with the Amiga and owned a CoCo3 I can say that what Mike said was essentially correct. While the OS's of the Amiga and ST have had massive bugs, which make up the bulk of the postings in the net postings regarding those machines, the OS-9 Level II port on the CoCo is amazingly bug-free. As Mike *correctly* noted, the biggest *alleged* bugs found on the OS-9 port boiled down to vague or misleading points of documentation. That and problems arising from mixing old version hardware with new version hardware. If you have doubts of this, I have printed transcripts of almost all the postings regarding the Level II and if you care to pay for photocopies and my time ($100.00/hr.) I'll send them to you. I have not kept transcripts of the "column feet" of bug reports regarding TOS/GEM and AmigaDOS/Intuition. Mike also pointed out quite correctly, that if you want to compare *discount* prices of Amiga and ST equipment then you should compare *discount* prices of CoCo3 equipment which are proportionally lower than the list prices that Stephen pointed at. Stephen has shown that he wasn't totally conversant with the CoCo situation, but you, you've shown utterly *incredible* ignorance. Anyone who has paid reasonable attention to the postings of the 'm6809', 'amiga' and 'atari.st' newsgroups know darned well that Mike was right on these points. It's almost beyond debate. As such you didn't even bother to *try* to allege any factual basis for your posting. If you clearly don't know what you're talking about, why bother to post *anything*? Does it make you feel good? Please don't post anymore unless you have something to say worth reading. >>PS: I don't want to start religious wars over, but this >>grenade landed in my newsgroup, so I just pulled the pin >>and tossed it back.... >>-- ... >Mike, while you found it necessary to defend the honor of your PET computer. >Your total ignorance of the other computers that you mention is a massive >miss use of net bandwidth. I am not saying don't post, just have your facts As noted before, Mike easily showed more knowledge about the computers mentioned than you. >straight before you start typing. Hans, practice what you preach, and don't even bother to post. You didn't even allege any facts to have straight--totally worthless posting. >Please E-Mail all replies to hah@intelos No, I think it's worth it for people to find out what a stupid thing you have posted. Hopefully your employers don't find your day to day work as utterly worthless as your posting on this topic was. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura
knudsen@ihwpt.ATT.COM (mike knudsen) (06/02/87)
In article <749@omepd>, hah@omepd.UUCP writes: > Mike, while you found it necessary to defend the honor of your PET computer. PET? Not that "pet!" Please! > Your total ignorance of the other computers that you mention is a massive > miss use of net bandwidth. I am not saying don't post, just have your facts > straight before you start typing. It was not my intention to badmouth the other machines, nor to use faulty facts. The intended IRONY of my posting was that every bad thing I said about the other machines was quoted from their newsgroups! What got my goat was the claim that "all we talk about in m6809 is bugs in OS9." When of course every newsgroup talks about bugs in their respective machines. So I reiterated the complaints that I remembered from those groups. I stand by my claim that the ST has no memory mgmt. This was beaten to death in discussing UN*X on the ST. I recall that the Amiga doesn't have MMU either. I guess Steve called the Coco's MMU "primitive" because it lacks write-protect and execute-only. True, but it still affords some protection from wayward programs--since upgrading to Level 2 OS9 I have crashed my own program to hell without always killing the OS and needing to reboot. The Amiga's multi-tasking OS insists on loading separate copies of the executable code for each process using that code, instead of sharing one re-entrant version like OS9 or UNIX. Thus memory can go away fast in an Amiga. This too, from an Amiga user in her newsgroup. That covers the only "facts" I mentioned. Help me out where I'm wrong. I don't deny the superiority of the 68K machines, or even their better bang/buck for someone starting from scratch (the new cheaper Amiga looks like a killer; the ST always has been). But just as the Apple II-GS will probably sell only to current Apple 2 owners, the Coco-3 is a very cost-effective upgrade, at least for those more interested in writing their own applications than buying off-the-shelf software. -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: <memory failure, too many digits> "Just say NO to MS-DOS!"
knudsen@ihwpt.UUCP (06/04/87)
In article <1835@lsuc.UUCP>, jimomura@lsuc.UUCP (Jim Omura) writes: > said was essentially correct. While the OS's of the > Amiga and ST have had massive bugs, which make up the > bulk of the postings in the net postings regarding those > machines, the OS-9 Level II port on the CoCo is amazingly > bug-free. I have not kept transcripts of the "column feet" of > bug reports regarding TOS/GEM and AmigaDOS/Intuition. About the bugs in the As' OSes -- I guess OS9 is relatively clean because it was around for some years before the Coco port (and Microware didn't try to rush it out at KMart prices). People probably think OS9 was written for the Coco (I've seen it referred to in consumer computer mags as "Tandy's proprietary OS"). Just like people think IBM wrote MSDOS (oops, excuse the profanity...) > Anyone who has paid reasonable > attention to the postings of the 'm6809', 'amiga' and 'atari.st' > newsgroups know darned well that Mike was right on these > points. It's almost beyond debate. > Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 > ihnp4!utzoo!lsuc!jimomura > Byte Information eXchange: jimomura Thanks for the spirited defense, Jim! Tag-team computer wars. BTW, I got a perfectly nice email response from an Amiga user to the effect that Intuition does indeed support shared libraries and routines, but you have to write them in 68K assembler; their C compiler won't make sharable code--he was rather burned up about that! I have the opposite problem--I wish I could make the Microware C put out non-sharable code, which could be much smaller in the initialized data department. Have to go to assembler to beat that. Or go to Level 2 since most of my data are graphics icons. -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: <memory failure, too many digits> "Just say NO to MS-DOS!"
bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) (06/04/87)
>The Amiga's multi-tasking OS insists on loading separate >copies of the executable code for each process using that >code, instead of sharing one re-entrant version like OS9 >or UNIX. Sorry, but that is not correct. Sharing one re-entrant version of code is quite easy, no insisting needed. Not all programs written for the Amiga *ARE* re-entrant (or even re-usable) simply because it's not enforced. The RESIDENT command will make a hunk of code "resident". (very obscure loader joke intended) It's not automagic, but could easily be once a special "trust me, I'm reusable and/or re-entrant" flags are added to the load format. (See previous posting in comp.sys.amiga about the RESIDENT compatible command) >--------- > Thus memory can go away fast in an Amiga. Just goes to show... if you can run 6 programs you WILL run 6 programs. For what you get memory usage is not overly high. However, consider how much memory you need just for those nice graphics screens, say 16 colors/line on a 704*464 pixel display. Or H.A.M where you get to play with any of the 4096 all on one line? An extra 1/2 - 12 megabytes is a much welcome addition to an Amiga. (Of course you could use Macintosh emulation mode and drop down to a 1 bit-plane monochrome display...)
hadeishi@husc4.UUCP (06/04/87)
In article <8706040024.AA10895@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: > >>The Amiga's multi-tasking OS insists on loading separate >>copies of the executable code for each process using that >>code, instead of sharing one re-entrant version like OS9 >>or UNIX. > >Sorry, but that is not correct. >Sharing one re-entrant version of code is quite easy, no insisting needed. >Not all programs written for the Amiga *ARE* re-entrant (or even re-usable) >simply because it's not enforced. >The RESIDENT command will make a hunk of code "resident". (very obscure loader >joke intended) Actually, shared text (i.e., shared executable) is not particularly essential on a single-user machine since most processes will be different executables anyway. But the real memory hog is the UNIX machines, not the Amiga, since the Amiga has shared libraries which make executables that access shared system resources and functions (windowing interface, etc.) much smaller than their UNIX counterparts, which have to link in a HUGE run-time library to EACH executable that uses them. Thus UNIX windowing applications tend to run quickly up into the multi-megabyte range, where the equivalent Amiga executable would be MUCH smaller. Things would be even better if someone wrote a shared run-time stdio library and other Sys V function library; then multiple executables, even totally different executables would have shared text automagically. But even with only windowing and DOS functions in shared libraries the Amiga executables tend to be far smaller than their Sun (for example) counterparts. So even ignoring the "resident" command (which only works with specially prepared executables) the Amiga tends to have better memory usage than similar UNIX-based windowing systems. -Mitsu
jack@mcvax.UUCP (06/04/87)
In article <2194@husc6.UUCP> hadeishi@husc4.UUCP (mitsuharu hadeishi) writes: >... But the real memory hog is the UNIX machines, not >the Amiga, since the Amiga has shared libraries which make executables >that access shared system resources and functions (windowing interface, >etc.) much smaller than their UNIX counterparts, which have to link >in a HUGE run-time library to EACH executable that uses them. Thus >UNIX windowing applications tend to run quickly up into the multi-megabyte >range, where the equivalent Amiga executable would be MUCH smaller. This might *seem* true, if you look at the sun et. al., but it isn't if you design your window manager carefully, and make the right decisions about what to put in the kernel, what to put in a system-wide daemon, and what to put in user libraries, (and what to put in hardware, if you have that option), you can end up with a powerful environment that doesn't need 200Kb for each program that displays a dialog box. On the Whitechapel MG-1, as an example of a window manager that did this split right, the average size of a program that uses windows is ~80K. I find this acceptable. Sun just did a bad design (not even speaking of the so-called user interface they give you. Yuck. Not even being able to type without the mouse obscuring your window. Blech), and now they'll have to fix it with concoctions like shared libraries.... -- Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp) The shell is my oyster.
scotty@l5comp.UUCP (Scott Turner) (06/06/87)
In article <2194@husc6.UUCP> hadeishi@husc4.UUCP (mitsuharu hadeishi) writes: >executables anyway. But the real memory hog is the UNIX machines, not >the Amiga, since the Amiga has shared libraries which make executables >that access shared system resources and functions (windowing interface, >etc.) much smaller than their UNIX counterparts, which have to link >in a HUGE run-time library to EACH executable that uses them. Thus [...] >But even with only windowing and DOS functions in shared libraries the >Amiga executables tend to be far smaller than their Sun (for example) >counterparts. So even ignoring the "resident" command (which only >works with specially prepared executables) the Amiga tends to have >better memory usage than similar UNIX-based windowing systems. > > -Mitsu First, un*x does NOT have this huge run-time library forced upon each and every program. The library is VERY comparable to the libraries that get linked into Amiga programs. Where the Amiga has shared libraries to draw upon, un*x has it's kernel. The un*x kernel provides quite a few of the functions provided by the shared libraries on the Amiga. After all, most of the "stock" shared libraries on the Amiga are pretty much the same in concept as the un*x kernel. Second, shared code IS possible under un*x. But it's machine dependent and most un*x code is written to be portable. If I wished to code up shared libraries on my un*x box I could certainly do so. It's true that quite a few un*x programs are HUGE. GNU Emacs for example is 558080 bytes on my UniStride 2.1 computer (l5comp). I have no doubt that it would be smaller on the Amiga. But then several features would be missing from the Amiga version since the Amiga couldn't support them. (Like the stuff for talking to the mail system) Zoo is 49350 bytes on my un*x system. As I remember this is pretty competitve with the Amiga Zoo in size. Third, the reason the Amiga tends to have better memory usage is really quite simple. Un*x systems tend to have TONS of memory lying around. This affects how you code. If ram is available and using it will simplify something then why not use it rather than spend days coding around the lack of ram? Scott Turner -- UUCP-stick: stride!l5comp!scotty | If you want to injure my goldfish just make UUCP-auto: scotty@l5comp.UUCP | sure I don't run up a vet bill. GEnie: JST | "The bombs drop in 5 minutes" R. Reagan Disclaimer? I own L5 Computing. Isn't that enough?
rap@dana.UUCP (Rob Peck) (06/08/87)
In article <2194@husc6.UUCP>, hadeishi@husc4.HARVARD.EDU (mitsuharu hadeishi) writes: > Things would be even better if someone wrote a shared run-time stdio > library and other Sys V function library; then multiple executables, even > totally different executables would have shared text automagically. > > -Mitsu I agree. Using shared libraries can significantly reduce the size of the code that any program needs to have. I have, for example, suggested to the JForth folks that it might be useful to create a version of JForth that was actually a library rather than a program so that calling a version of JForth would be a small program that opened the library effectively passing to the library a new stack frame and local variables for HERE and so on. (BTW, they listened with interest, but are busiest writing the standalone environment compiler and may not be able to tackle this sort of thing for a while.) This would place the entire of a forth kernel accessible on a read-only basis, so to speak, to many programs, with their own individual extensions accessible on a per-application basis. Other programs could do the same. The main limitation, as I see it, is the need to always write reentrant code (as is necessary for libraries for libraries anyway). Library of stdio ... good idea, anyone want to tackle it? Rob Peck ...hplabs!dana!rap
barnett@vdsvax.steinmetz.UUCP (Bruce G Barnett) (06/09/87)
In article <7409@boring.cwi.nl> jack@boring.UUCP (Jack Jansen) writes: >Sun just did a bad design (not even speaking of the so-called >user interface they give you. Yuck. Not even being able to type without >the mouse obscuring your window. Blech) I don't understand. You can split the focus, having the mouse in one window and keyboard input going to another. You can change this with a mouse command or a function key. see swin(1), etc And how can the cursor obscure your window? -- Bruce G. Barnett (barnett@ge-crd.ARPA) (barnett@steinmetz.UUCP) -- "The difference between a Buddha and an ordinary man is that one knows the difference and the other does not."
knudsen@ihwpt.UUCP (06/11/87)
In article <178@dana.UUCP>, rap@dana.UUCP (Rob Peck) writes: > Library of stdio ... good idea, anyone want to tackle it? > Rob Peck ...hplabs!dana!rap I'm just a "lowly" Coco-3 (6809) hacker, but I seem to recall that OS/K (68000 OS9) does indeed share the whole stinkin' StdIO library, so when you have a half dozen C programs loaded, there's only ONE copy of printf() in memory! No longer need "hello world" take 4K ... mike k PS: there was quite a discussion couple months back on mod.os about ways to implement shared libraries. Somewhat after the fact, but there are several approaches each with good & bad points. -- Mike J Knudsen ...ihnp4!ihwpt!knudsen Bell Labs(AT&T) Delphi: RAGTIMER CIS: <memory failure, too many digits> "Just say NO to MS-DOS!"
dibble@rochester.ARPA (Peter C. Dibble) (06/11/87)
In article <1735@ihwpt.ATT.COM>, knudsen@ihwpt.ATT.COM (mike knudsen) writes: > In article <178@dana.UUCP>, rap@dana.UUCP (Rob Peck) writes: > > Library of stdio ... good idea, anyone want to tackle it? > > Rob Peck ...hplabs!dana!rap > > I'm just a "lowly" Coco-3 (6809) hacker, but I seem to recall > that OS/K (68000 OS9) does indeed share the whole stinkin' > StdIO library, so when you have a half dozen C programs loaded, OS-9/68K supports "trap handlers." Two of them come with the system: a stdio trap handler and a floating point trap handler. The program does some fussing around to "install" the handler, then it uses a trap to access the routines in the handler. You need a trap per trap handler, so there is a limit on the number of separate libraries a program can use without swapping trap numbers around. The technical manual describes the protocol for the floating point handler. The stdio handler is undocumented, and it looks a bit tricky to call. (Nice thing about the floating point handler: if you have a 68881 you just install the handler that uses it. Programs start using the coprocessor without any changes.) On the 6809 subroutine modules could be used to achieve almost the same effect. Peter Dibble
peter@sugar.UUCP (06/12/87)
> Third, the reason the Amiga tends to have better memory usage is really quite > simple. Un*x systems tend to have TONS of memory lying around. This affects > how you code. If ram is available and using it will simplify something then > why not use it rather than spend days coding around the lack of ram? Some of us remember the days when UNIX systems didn't have tons of RAM. At one place we had 8 users running on a PDP 11/40 with 256 K words of RAM. On the PDP-11 you had 128K MAX per process. When faced with these constraints and the lack of incentive to do much graphics (because you didn't have any) UNIX programs tended to be small and tight. It used to be that you could code the world in 64K. Amiga programs should also be small and tight if they just use CLI. After all, the AmigaDOS functions are pretty close to isomorphic to the UNIX ones. Why they aren't is a matter to take up with the likes of Lattice and Manx. I still haven't figured out why they tend to put two or three extra layers in between you and the DOS. open() should be nothing but a little argument massage and a call to Open()... file descriptors should be isomorphic to file handles.
jec@nesac2.UUCP (06/13/87)
Since this has turned into a discussion of Suns, windows, and operating system design, perhaps it should be moved to comp.os.???? instead of being in comp.sys.m6809. -- John Carter AT&T Communications - Atlanta RWC USnail: 3001 Cobb Parkway, Atlanta GA 30339 E-mail: ...ihnp4!cuea2!ltuxa!ll1!nesac2!jec Voice: 404+951-4642 (The above views are my very own. How dare you question them? :-)
dragon@trwspf.UUCP (06/18/87)
In article <163@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) writes:
*Some of us remember the days when UNIX systems didn't have tons of RAM. At
*one place we had 8 users running on a PDP 11/40 with 256 K words of RAM. On
*the PDP-11 you had 128K MAX per process. When faced with these constraints
*and the lack of incentive to do much graphics (because you didn't have any)
*UNIX programs tended to be small and tight. It used to be that you could code
*the world in 64K.
Amen, brother, Amen! And we did code the world in 64K, too, clobbering some
of our competitors in the process. I struggled for five years ('75->'80) to
get UNIX established in our company only to watch it expand during the next
six years like a cost overrun on some government contract. Yuki! I hope
that this does not happen to AmigaDOS or any other operating system which
may be written for the Amiga. Graphics does not have to add that much either.
I have worked with Liliths and Modula-2 for the past three years which have
shown that you can do some pretty neat stuff with a small simple system.
Although C is not my cup of tea, the Amiga is neat. Let's keep it that way.
--
-- Roger A. Vossler
TRW, Bldg O2-1395, One Space Park, Redondo Beach, CA 90278
BIX: rvossler UseNet: dragon@trwspf.UUCP
...!sdcrdc!trwrb!trwspf!dragonhatcher@INGRES.BERKELEY.EDU.UUCP (06/20/87)
In article <307@trwspf.TRW.COM> dragon@trwspf.TRW.COM (Roger Vossler) writes: In article <163@sugar.UUCP> peter@sugar.UUCP (Peter DaSilva) writes: *UNIX programs tended to be small and tight. It used to be that you could code *the world in 64K. >Amen, brother, Amen! And we did code the world in 64K, too, clobbering some >of our competitors in the process. I struggled for five years ('75->'80) to I recall that one of the first versions of vi that Bill Joy wrote on a PDP 11/70 running Version 6 Unix (around 1977, I think) had some interesting features like automatic spelling correction (by choosing from a list of replacements), and document preparation features like continuous paragraph reformatting. He eventually deleted them, though (much to some people's dismay) because "I only have 5 bytes left in the 64k code segment; I can't include *everybody's* favorite features!" So I'd say that while the blessing was that many programs were small and tight, the curse was that this was at the expense of some functionality in the largest programs (at the time vi was considerably larger than the entire version 6 Unix kernel in terms of pages of printout). For some years I've luxuriated in having more than 64K to build sophisticated programs, but over the last couple of years I've found that there is *always* something to be said for "small and tight", too. Like many others, I have often written code that took up an extra 60K unnecessarily because it was easier to write it that way, and the 60K was available. Sometimes this is reasonable, but it is a very bad *habit* to get into when performance is an issue. One fun thing about the Amiga is that it is giving me an opportunity to consider making things smaller to conserve *disk* space, if nothing else, which helps me break some sloppy habits. But it still has plenty of RAM (and disk space) for programs that *need* to be big. What fun! For those of you that don't care much for issues of disk space, note that smaller programs tend to run faster, too, if you can trim them down enough to use 16 bit rather than 32 bit pointers. This is not true of all architectures, of course, but note that what *is* universal is that the more memory a program uses, the more memory cycles it will use to fetch/store/execute, and therefore is slower than the same program rewritten to be smaller and use fewer memory cycles (all other things being equal, of course...often the algorithm chosen is the most important thing [flame avoidance :-] ) Doug Merritt ucbvax!ingres!hatcher (thru Jun 28) or ucbvax!unisoft!certes!doug
peter@sugar.UUCP (Peter DaSilva) (06/23/87)
> when performance is an issue. One fun thing about the Amiga is that > it is giving me an opportunity to consider making things smaller to > conserve *disk* space, if nothing else, which helps me break some sloppy > habits. But it still has plenty of RAM (and disk space) for programs that > *need* to be big. What fun! Given the tendency of people to daemonize programs on the Amiga (I know I do: I often want to keep an extra CLI or utility around while I'm compiling), there's another reason to keep them small: conserve RAM space. You're more likely to be able to keep a 5K program around while compiling than a 50K one.
waterman@cory.Berkeley.EDU.UUCP (06/29/87)
[eat this. I dare ya'...] >Some of us remember the days when UNIX systems didn't have tons of RAM. At >one place we had 8 users running on a PDP 11/40 with 256 K words of RAM. On >the PDP-11 you had 128K MAX per process. When faced with these constraints >and the lack of incentive to do much graphics (because you didn't have any) >UNIX programs tended to be small and tight. It used to be that you could code >the world in 64K. And some of us remember when you could code the world in 4K (that's CORE, buddy) on a PDP-8 or a PDP-12 running TECO to edit your assembly files. That is, after you had booted the machine by coding in from the front panel switches the 8 word program to start up the PAPER TAPE reader to read in OS-8 from the tape drive. One of the cooler memory-tight hacks on this machine was Space-War, an arcade- type game with a gravitational sun, in which you piloted the enterprise and a klingon ship around blowing each other up. This game, incidentally, eventually made it to the video arcade ( I don't remember who made it, though :-( ). This is 4k, remember. Just remember, tight code is good code. These 12K "ls" look-alikes drive me nuts. T.S. Waterman "When in the course of human events, it becomes necessary for one people to disclaim themselves....."
ford@crash.CTS.COM (Michael Ditto) (06/30/87)
In article <2952@zen.berkeley.edu> waterman@cory.Berkeley.EDU.UUCP (T.S. Alan Waterman) writes: >One of the cooler memory-tight hacks on this machine was Space-War, an arcade- >type game with a gravitational sun, in which you piloted the enterprise >and a klingon ship around blowing each other up. This game, incidentally, >eventually made it to the video arcade ( I don't remember who made it, >though :-( ). This is 4k, remember. It was called "Space Wars", manufactured and sold by Cinematronics (now called "Leeland Corp." I beleive) in El Cajon, CA. This is the same company that later made "Dragon's Lair", the first Laser Disk game. By the way, this arcade version was done entirely in discrete hardware; no CPU or memory as such. It was just "bil-yuns and bil-yuns" of random TTL chips, which drove a monochrome vector monitor. I'm not sure whether I'm more impressed by the 4K PDP-11 version or the hardware version. -- Michael "Ford" Ditto -=] Ford [=- P.O. Box 1721 ford@crash.CTS.COM Bonita, CA 92002 ford%oz@prep.mit.ai.edu
farren@hoptoad.uucp (Mike Farren) (07/01/87)
In article <1306@crash.CTS.COM> ford@crash.CTS.COM (Michael Ditto) writes: > >It was called "Space Wars", manufactured and sold by Cinematronics (now called >"Leeland Corp." I beleive) in El Cajon, CA. This is the same company that >later made "Dragon's Lair", the first Laser Disk game. > >By the way, this arcade version was done entirely in discrete hardware; no >CPU or memory as such. It was just "bil-yuns and bil-yuns" of random TTL >chips, which drove a monochrome vector monitor. I'm not sure whether I'm more >impressed by the 4K PDP-11 version or the hardware version. Not true. The Space Wars arcade game was based on a TI bit-slice processor. I've still got the machine code dump for the ROMs somewhere around. I'm much more impressed by the 4K PDP version, which was on the PDP-1, by the way, long before the 11 was even a dream. (I'm also directing follow-ups to rec.games.video, by the way.) -- ---------------- "... if the church put in half the time on covetousness Mike Farren that it does on lust, this would be a better world ..." hoptoad!farren Garrison Keillor, "Lake Wobegon Days"
whorfin@pixar.UUCP (Rick Sayre) (07/02/87)
In article <1306@crash.CTS.COM> you write: >In article <2952@zen.berkeley.edu> waterman@cory.Berkeley.EDU.UUCP (T.S. Alan Waterman) writes: >>One of the cooler memory-tight hacks on this machine was Space-War [...] >>[...] This is 4k, remember. BTW, this game also came out on the Vectrex, a nifty home vector graphics video game. It was 4K here also. 'course 64K of general ROM routines doesn't hurt :-) Unfortunately, Milton Bradley bought the company, GCE. Squish! Can you say "nonexistent marketing"? Let's hope the same doesn't happen to everyone's favorite computer... -- Rick Sayre "Use more honey; {sun|ucbvax}!pixar!whorfin find out what she knows"