Yes, I suppose that's rather quaint... modern systems hae solved that problem -- by not having BASIC built in, which is not necessarily a solution. On the other hand, it is true that the two file types are supposed to work differently. Would you want to load a machine-language file and have BASIC interpret it as tokens? The result would be a disaster. You could use a UNIX-like approach and have one file type (binary) or maybe two (binary and text) and leave it up to the user and programmer to choose the right commands. I'm not sure that fits in with the "easy-to-program" mentality of the Apple, though. Besides, BASIC had already been created when DOS was designed. This brings up another point -- given that you have multiple file types, wouldn't it be safe to have one command that acts differently on all of them? (This is the reverse of the UNIX-like apporach.) It's a pain that DOS made you use separate commands for all of the filetypes. Someone published a chunk of code that added a - command like ProDOS', and some other goodies. (I think the code was published by the A.P.P.L.E. user group, which BTW was a local and very productive group.) Actually, some of the types aren't really accessible at all! (There are no useful commands for displaying text files, for example. Though EXEC is nice and not used often enough.) Did you know that there are EIGHT file types in DOS? They are: T text I Integer BASIC A Applesoft BASIC B binary (absolute) S system -- not used by anything except simple protection schemes R relocatable binary -- requires a relocating loader (usually called RBOOT or RLOAD, I think). The relationship between the loader and the OS is very weak; I don't know if the loader checks the types of files it loads, and I doubt that the OS knows about the loader at all. A Another type A -- not used by anything B Another type B -- not used by anything If you look through memory, you can find the string BARSBAIT. That is kind of silly. I assume you couldn't do anything with USR files? Again, I object to the lack of available actions more than the artificial distinction of file types. Can you get a directory of selected filenames or types on the Commodore? Apple DOS doesn't do any wildcards at all (unless you use FID). -- Derek

In _Beneath Apple DOS_, *everything* is documented. Well, practically everything. There's a fairly specific breakdown of the DOS machine code (with entry points, the purpose of each routine, etc.) which was made by disassembling the code. It's good enough that you would have a chance of understanding the code if you disassembled it yourself. There are also sample listings for a small disk editor, individual track formatter, etc. Hmm. The Commodore OS is more powerful than I thought. I still think the syntax and implementation is rather clunky. I'll admit that Apple DOS is crude, but in some ways (mostly control of the disk drive) it's very flexible since it's all done in software! And of course the Apple drive combines its amazing simplicity with respectable speed, unlike the shamefully slow Commodore drive. What light? The "look at the data types and actions" approach? I guess I would call that the object-oriented viewpoint. It sounds like you're saying you understand more about the reasons why DOS is the way it is... is that right? -- Derek

On Thu, 17 Dec 1998, John Foust wrote: Oooh, cool! Any chance of this being exhibited at VCF 3.0? Sellam Alternate e-mail: dastar(a)siconic.com ------------------------------------------------------------------------------ Always being hassled by the man. Coming in 1999: Vintage Computer Festival 3.0 See http://www.vintage.org/vcf for details! [Last web site update: 12/07/98]

I Found a SCSI CDROM Drive with a Trantor MiniSCSI Plus printer port adaptor with that was going to the trash can.. The CDROM unit looks like it works , however I do not have the Software Drivers for the Trantor Printer port adaptor unit.. (This is a cable/interface that allows the SCSI drive to be plugged into the printer port of a computer).. After looking on the Web I could not find a good phone number for this company, apperantly went out of business.. Does anyone know where I can get the Trantor drivers so I can use this drive ? Any information would be much appericiated.. The following is on the unit: Trantor Systems, Ltd. MiniSCSI Plus Model T348 Copyright 1992 Thanks for your help... Phil...

Trantor was bought out by Adaptec. You might try them. There were three models that I'm aware of: T338 (rectangular thin box) that hangs off of the parallel port, or screw it on so that it gets enough leverage to break the connector. The black labelled earlier sub-model is significantly less reliablke than the later blue labelled one. Also marketed briefly through NEC (they once had the drivers on the web) T348 cable based model. T358 cable based model with ECP/EPP support NONE of them are very reliable; but it's a handy way to hook things up to laptops, etc that don't have provision for a "real" SCSI controller. Would you like me to snail mail a copy of the disk? Or would you prefer e-mail attachment? -- Fred Cisin cisin(a)xenosoft.com XenoSoft http://www.xenosoft.com 2210 Sixth St. (510) 644-9366 Berkeley, CA 94710-2219 On Fri, 18 Dec 1998, Phil Clayton wrote:

Phil, Here is an idea. Hook the drive up to a computer running Windows98. Hopefully this will pull up your driver for this drive. I do not know if this will be backwards compatible. John Amirault Phil Clayton wrote:

Wow! That was quick response... Many Thanks to everyone here that responded. I did find Adaptec.com as suggested and there it was complete with Manual and software drivers.. Looks like I may have me a Free working (To be determined) CDROM drive.. Thanks again everyone.. Phil...

On Wed, 16 Dec 1998, Cameron Kaiser wrote: Huh? AppleSoft files were files tokenized under AppleSoft BASIC, and Integer BASIC files were ones tokenized under Integer BASIC...a big difference. Binary files held machine code or data of some sort. Sellam Alternate e-mail: dastar(a)siconic.com ------------------------------------------------------------------------------ Always being hassled by the man. Coming in 1999: Vintage Computer Festival 3.0 See http://www.vintage.org/vcf for details! [Last web site update: 12/07/98]

A non-text attachment was scrubbed... Name: not available Type: text Size: 838 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/19981217/3398baec/at…

A non-text attachment was scrubbed... Name: not available Type: text Size: 1326 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/19981217/7e7fe98a/at…

I don't think that's true -- it's possible to create a file with no sectors corresponding to certain parts. There was a serious bug involving APPENDing to random-access files (i.e., it didn't work). Apple came up with some patches. I don't know how they work, but I doubt they solved the problem since the information DOS needed (the size of the file in records, or the last byte in a record, or something) just wasn't there. At least I think that's the story. ProDOS didn't have that problem because it kept enough info. Doesn't that also point to the ability to have holes in files? Later I'll dig out _Beneath Apple DOS_ and see what it says. -- Derek

On Thu, 17 Dec 1998, Hans Franke wrote: The Unix philosophy is simplicity. The filesystem is simple -- everything's just a byte stream, but that doesn't mean that information can't be embedded into the file that describes its content. That's what "magic numbers" are all about. See file (1). And what the heck does that have to do with X configuration? X may be big, cumbersome, and somewhat ugly, but don't blame Unix for that! ObCC: Does anybody remember a nice small GUI that came out for Unix around the same time as X? I think it was called MGR, or something like that. -- Doug

Zane H. Healy wrote: MGR continues to be popular on surviving AT&T 3B1 and 7300 Unix PCs. Took a small hardware mod to run it, but it's been stable for years. Since the Unix PC can't be upgraded to enough RAM to make X useable. -- Ward Griffiths <mailto:gram@cnct.com> <http://www.cnct.com/home/gram/> WARNING: The Attorney General has determined that Alcohol, Tobacco, and Firearms can be hazardous to your health -- and get away with it.

Ward Donald Griffiths III wrote: Doug asked: In a stock 7300 or 3B1, the video memory can't be mapped into the user address space. The "VIDPAL" mod fixes this (at the risk that any process can scribble on the screen memory). There actually is a way to run MGR without the modification, but it is extremely ssslllooowww. Eric

That's it so simple, that it's only a covered disk driver. From an OS I want OS services for common jobs and common solutions to avoide the millionth invention of the weel. Take the simple Apple DOS and their relave files - Within Unix not even this simple kind of optimization is available - From a _real_ OS I like to have services like SAM/ISAM fileslibrary management etc. not just stupid, slow and clumbsy byte streams - If you do it to simple, you miss the chance of geting high level optimizations. It just developed to the all-is-simple-and-therefore-every- know-how-is-just-a-local-and-random Philosopy of Unix. Isn't there a Linux implementation ? Gruss H. -- Ich denke, also bin ich, also gut HRK

Hans wrote: No, even a file system supporting only a byte-stream model still provides much more service than a disk driver. Why do you think it's better to put this functionality into an already-bloated monolithic kernel, rather than implementing it as a shared library in user space? By keeping as much stuff as possible out of the kernel, you will generally end up with a more robust system. I'm at somewhat of a loss to understand what optimizations the kernel could do better than a shared library with regard to fixed-length record access (as done by Apple DOS). Eric