spock@wrkof.incom.de (Martin Georg) (09/08/90)
Hi you Apple II folks all around!!!
I would like to post two problems that have been reported by friends
of mine in the last few days:
1) One friend tried to use a Laser 800KB Unidisk-compatible disk drive
connected via the UCD on his IIgs under GS/OS (System 5.02). On boot-
up, the System popped up a message stating something like: Unidisk re-
quires a driver. Please install driver and reboot system". He did that
and rebooted but the message still popped up. Of course the driver was
turn on (active) using the Finder's IconInfo dialog.
Does someone use this configuration on his IIgs??? Is there a special
driver needed (I think the system will use a generated driver if no
special driver is available...). Is there a special Laser 3.5"-driver
available???
2) Recently, another friend of mine bought a Seagate ST-1096N SCSI
harddisk (3,5", 85MByte, 18ms) and planned to use that driver with
his old Revision C Apple SCSI card on his IIgs. Formatting and parti-
tioning with the Advanced Disk Utilities worked fine, and even in-
stalling the System Softwar with the Installer caused no problem. Then
he copied AppleWorks 3.0 onto the harddisk and launched that from a
8Bit program launcher. That also worked OK. But when he tries to boot
the harddisk into GS/OS the system crashes on bootup after 3/4 of the
red boot thermometer into the monitor. I think that Apples SCSI driver
must have some timing problems with that very fast harddisk... Does
someone know more about that problem??? Perhaps Dave or Matt, haven't
you got some reports on that???
Thanks in advance for all replies!
Yes, the IIgs is still alive in Germany!!!
---> Apple II forever! <---
Martin Georgfadden@cory.Berkeley.EDU (Andy McFadden) (09/09/90)
In article <1990Sep8.073212.2278@wrkof.incom.de> spock@wrkof.incom.de (Martin Georg) writes: > >1) One friend tried to use a Laser 800KB Unidisk-compatible disk drive >connected via the UCD on his IIgs under GS/OS (System 5.02). On boot- >up, the System popped up a message stating something like: Unidisk re- >quires a driver. Please install driver and reboot system". Isn't that great? The system recognizes it as a UniDisk, but the UniDisk driver doesn't. I gave my Laser drive to my parents for their //e (in exchange for an old Epson RX-80), and bought a used Apple drive for $200. I'd recommend getting an AE 3.5" drive and using the Laser one as a second drive; the speed difference alone is worth it. >Does someone use this configuration on his IIgs??? Is there a special >driver needed (I think the system will use a generated driver if no >special driver is available...). Right. You just can't boot from it. Probably Apple's engineers trying to save you from disk switched problems. >Martin Georg -- fadden@cory.berkeley.edu (Andy McFadden) ..!ucbvax!cory!fadden
q4kx@vax5.cit.cornell.edu (Joel Sumner) (09/09/90)
In article <1990Sep8.073212.2278@wrkof.incom.de>, spock@wrkof.incom.de (Martin Georg) writes: > 2) Recently, another friend of mine bought a Seagate ST-1096N SCSI > harddisk (3,5", 85MByte, 18ms) and planned to use that driver with > his old Revision C Apple SCSI card on his IIgs. Formatting and parti- > tioning with the Advanced Disk Utilities worked fine, and even in- > stalling the System Softwar with the Installer caused no problem. Then > he copied AppleWorks 3.0 onto the harddisk and launched that from a > 8Bit program launcher. That also worked OK. But when he tries to boot > the harddisk into GS/OS the system crashes on bootup after 3/4 of the > red boot thermometer into the monitor. I think that Apples SCSI driver > must have some timing problems with that very fast harddisk... Does > someone know more about that problem??? Perhaps Dave or Matt, haven't > you got some reports on that??? Does he have the INNERDRIVER driver installed? He will have to remove it. I experienced this problem when I got my hard drive. The INNERDRIVER and Apple's SCSI driver are incompatible. I don't know why the INNERDRIVER was shipped already in the */SYSTEM/DRIVERS subdirectory on the System 5.0.2 disks but that was a MAJOR headache for me until I finally figured it out. Then again, if he doesn't have the Innerdriver installed, I don't know what the problem is. (The symptoms sound exactly like the problems I had though) -- Joel Sumner GENIE:JOEL.SUMNER These opinions are q4kx@cornella.ccs.cornell.edu q4kx@cornella warranted for 90 days or q4kx@vax5.cit.cornell.edu q4kx@crnlvax5 60,000 miles. Whichever .................................................... comes first. Never test for an error condition that you can't handle.
mattd@Apple.COM (Matt Deatherage) (09/10/90)
In article <1990Sep8.073212.2278@wrkof.incom.de> spock@wrkof.incom.de (Martin Georg) writes: > >1) One friend tried to use a Laser 800KB Unidisk-compatible disk drive >connected via the UCD on his IIgs under GS/OS (System 5.02). On boot- >up, the System popped up a message stating something like: Unidisk re- >quires a driver. Please install driver and reboot system". He did that >and rebooted but the message still popped up. Of course the driver was >turn on (active) using the Finder's IconInfo dialog. >Does someone use this configuration on his IIgs??? Is there a special >driver needed (I think the system will use a generated driver if no >special driver is available...). Is there a special Laser 3.5"-driver >available??? > This is partly Central Point's fault and partly Apple's fault, and partly the fault of copy-protected programs. For every SmartPort device there is a type and a subtype. The type identifies the generic type of device connected (such as "3.5 disk" or "SCSI hard disk"). Unfortunately, there's no place in the definition to identify the *specific* kind of device (such as "Unidisk 3.5" or "Apple 3.5 drive"). What some people did, encouraged by faulty Apple documentation, is look at the "subtype" byte which is really a byte of flags. Bit 7 is set if the device supports Extended SmartPort, bit 6 is set if the device supports disk-switched errors, etc. You can probably see this coming - you can't use the same byte as an ID byte and as a byte of flags. For example, the built-in drive in the IIc Plus has characteritics that make its subtype be $00. That's the same as the documented subtype of the Unidisk, but the IIc Plus drive does not support the Unidisk device-specific calls. Central Point deliberately chose to return subtype $C0 for Apple 3.5 drives attached to the UDC so copy-protected programs looking for the $C0 subtype byte would run correctly. Unfortunately, their interface doesn't support the Extended SmartPort protocol one of those bits says is present. When GS/OS tries to use it, the system crashes. The UniDisk driver adds more disk-switched detection to what's in the drive and as such will only work when attached to the internal port (GS/OS slot number $0005). As the generated drivers are created (which one would be for something attached to a UDC, as it can't be in internal slot 5), the Device Dispatcher tries to kick out generated drivers for Apple peripherals that it knows need loaded drivers. The UniDisk is one of these - without a loaded driver you will eventually confuse the drive, miss disk switches and probably write cached information (like directories) to the wrong disk. What Central Point needs to do is write a generic 3.5" driver that claims all the 3.5" drives attached to the UDC and handles them appropriately. -- ============================================================================ Matt Deatherage, Apple Computer, Inc. | "The opinions represented here are Developer Technical Support, Apple II | not necessarily those of Apple Group. Personal mail only, please. | Computer, Inc. Remember that." ============================================================================
AG0514@ALBNYVMS.BITNET (AppleEnthusiast) (09/17/90)
Is your RAM card DMA compatible? I tried using my HD with the new SCSI card and non-DMA ram card and had no problem with P8 or P16, but GS/OS would not recognize the drive properly. It would not boot from the HD, and when booting from a 3.5" the system would mount the HD but then when trying to copy anyting to it would say 0K available (on an empty HD). I tried using a friends GS-Ram+ and then it worked. So I sent my GS-Ram to get upgraded to DMA compatible. Andrew Goldstein aka AppleEnthusiast Internet: ag0514@rachel.albany.edu
danny@gnh-starport.cts.com (Daniel Manchester) (11/05/90)
Hello all! I have two, quick, unrelated questions, which I would GREATLY
appreciate answers to.
1. Are there any good Pascal compilers (commercial / shareware / public
domain) available for an unexpanded, 65C02 Apple //c? I do most of my
programming work on a Macintosh with THINK's Lightspeed Pascal, which allows
you to create independent applications from your source code. I have never (to
my recollection) seen a similar product advertised for a regular Apple //. Are
there any such packages?
2. Is there a way to get around the limitations of AppleSoft BASIC's "READ"
command? Specifically, is there a way I can read ALL characters without
problems (certain ones, such as a regular colon--":"--trip it up) from a data
file? It also considers commas to be analogous to carriage returns (which, for
my purposes, is undesireable). If there is a way around this, I assume it is a
machine language patch, an entirely separate machine language routine, etc.--do
you know of something like this?
If you have an answer to either question, PLEASE reply, via electronic
mail (I am unable to keep up with the high rate of posting on this conference,
so I am often forced to skip messages).
Danny Manchester
Silver Spring, Maryland
InterNet: danny@gnh-starport.cts.com ProLine: danny@gnh-starport
UUCP: crash!gnh-starport!danny ARPA: crash!gnh-starport!danny@nosc.milunknown@ucscb.UCSC.EDU (The Unknown User) (11/05/90)
In article <m0iVm8Q-0001erC@jartel.info.com> danny@gnh-starport.cts.com (Daniel Manchester) writes: >1. Are there any good Pascal compilers (commercial / shareware / public >domain) available for an unexpanded, 65C02 Apple //c? I do most of my >programming work on a Macintosh with THINK's Lightspeed Pascal, which allows >you to create independent applications from your source code. I have never (to >my recollection) seen a similar product advertised for a regular Apple //. Are >there any such packages? I used Apple Pascal back in high school, and it seemed pretty good. It uses its own operating system so it's not like you can write an application and then move it to a ProDOS disk and run it. (Hell, maybe you can somehow, because I know that Chameleon reads ProDOS/DOS3.3/Pascal disks.. I doubt Pascal makes a "SYSTEM"-ish file though) Jeez, that seems to be a major problem of 8 bit compilers.. they use their own O/S... HyperC and Apple Pascal seem to have this problem. But anyway, as my first experience with a high level language, it seemed pretty good. I also remember that Apple Pascal dealt with 5.25" disks AS FAST AS PHYSICALLY POSSIBLE. (Someone told me this). It probably has to due at least partially with the fact that Apple Pascal makes you keep your files sequentially on disk (there's a better term for what I mean but I can't think of it).. there's a function for doing just that in the OS itself. (You K)runch a disk) Also, Apple Pascal deals quite fine with 3.5" disks and RAM disks (at least on the GS).. And this was before the GS came out, as far as I can remember. Apple Pascal is still for sale according to what someone else posted a few days ago... If you buy it then you'll show Apple that there are still people interested in high level languages for the 8 bit Apple IIs! -- /Apple II(GS) Forever! unknown@ucscb.ucsc.edu MAIL ME FOR INFO ABOUT CHEAP CDs\ \"If cartoons were meant for adults, they'd be on in prime time."-Lisa Simpson/
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (11/05/90)
unknown@ucscb.UCSC.EDU (The Unknown User) writes: >I doubt Pascal makes a "SYSTEM"-ish file though) Jeez, that seems to be It doesn't. Apple Pascal has no knowledge of Prodos. It might be possible to write a prodos application that acted as a front end to pascal created code. To my knowledge, no one has attempted this yet. > But anyway, as my first experience with a high level language, it >seemed pretty good. My first experiences with Apple Pascal were horrible. I kept overflowing the stack while COMPILING (!!) for no apparent reason (i.e. really small programs). I stuck to BASIC and moved into machine language, and when I got to college, to C. > I also remember that Apple Pascal dealt with 5.25" disks AS FAST >AS PHYSICALLY POSSIBLE. (Someone told me this). It probably has to due >at least partially with the fact that Apple Pascal makes you keep your >files sequentially on disk (there's a better term for what I mean but I >can't think of it).. there's a function for doing just that in the OS itself. >(You K)runch a disk) This was the best thing about Apple Pascal, and it was refined by the Mac O/S which uses the same scheme ('extents' or strips of adjacent blocks on the disk) except the Mac O/S allowed for fragmentation whereas Apple Pascal did not. With the Mac O/S you get a less efficient disk access if there isn't a free strip for the whole file; with pascal you get a insufficient space message and you have to Krunch the disk before attempting to save it there again. > Also, Apple Pascal deals quite fine with 3.5" disks and RAM disks >(at least on the GS).. And this was before the GS came out, as far as I can >remember. Yep... Apple Pascal was very well designed, but it was truly annoying to work with when you wanted to get down and dirty... this trait is embedded into the Mac O/S and it's the main reason I prefer GS/OS. Todd Whitesel toddpw @ tybalt.caltech.edu
dcw@lcs.mit.edu (David C. Whitney) (11/05/90)
In article <1990Nov5.112859.7962@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >unknown@ucscb.UCSC.EDU (The Unknown User) writes: > >>I doubt Pascal makes a "SYSTEM"-ish file though) Jeez, that seems to be > >It doesn't. Apple Pascal has no knowledge of Prodos. It might be possible >to write a prodos application that acted as a front end to pascal created >code. To my knowledge, no one has attempted this yet. EEAACK! There's good reason. Apple Pascal compiled to P-Code (which, by the way, will run on any machine running a P-interpreter). It did not compile to 6502 assembly. Part of the P-system is the P-interpreter. In order to get an Apple Pascal program to run under ProDOS, you'll need to write a P-interpreter running under ProDOS. Oog. Too much work for any one sane mind. -- Dave Whitney Computer Science MIT 1990 | I wrote Z-Link and BinSCII. Send me bug dcw@lcs.mit.edu | reports. I need a job. Send me an offer. Every now and then one makes a mistake. Mine was probably this post.
tribby@hpindwa.cup.hp.com (David Tribby) (11/06/90)
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >unknown@ucscb.UCSC.EDU (The Unknown User) writes: > >>I doubt Pascal makes a "SYSTEM"-ish file though) Jeez, that seems to be > >It doesn't. Apple Pascal has no knowledge of Prodos. It might be possible >to write a prodos application that acted as a front end to pascal created >code. To my knowledge, no one has attempted this yet. 6 or so years ago, Apple sold a software unit to give Apple Pascal programs access to ProDOS disks. I bought it and was able to read and write ProDOS volumes from a Pascal program. I, too, never heard of any p-code interpreter running under ProDOS (but it would be just a simple matter of programming!). >My first experiences with Apple Pascal were horrible. I kept overflowing >the stack while COMPILING (!!) for no apparent reason (i.e. really small >programs). Maybe you had the original version (1.0?) which I understand was pretty bad. You should have gotten the 128K version, which had p-code in aux memory and left a lot more main memory available for stack/heap and assembly code. >Yep... Apple Pascal was very well designed, but it was truly annoying to work >with when you wanted to get down and dirty... this trait is embedded into the >Mac O/S and it's the main reason I prefer GS/OS. I got as dirty as I wanted with Apple Pascal, particularly after I disassembled APPLE.SYSTEM (the BIOS and p-code interpreter). With assembler, you could write relocatable routines that interacted easily with Pascal programs. They provided support for writing your own drivers. Randal Hyde wrote a book showing how to patch the p-code interpreter to speed up performance and implement the TIME intrinsic. That was fun hacking... -- Dave Tribby
taob@pnet91.cts.com (Brian Tao) (11/06/90)
> I also remember that Apple Pascal dealt with 5.25" disks AS FAST > AS PHYSICALLY POSSIBLE. (Someone told me this). It probably has to due > at least partially with the fact that Apple Pascal makes you keep your > files sequentially on disk (there's a better term for what I mean but I > can't think of it).. there's a function for doing just that in the OS > itself. (You K)runch a disk) You mean to say that Apple Pascal keeps all your files CONTIGUOUS (all in one continuous block, not scattered all over the place). Is that feature automatic? Or do you have to specify Krunch Disk to optimize the files? All operating systems today have similar utilities which will do the same task. It's usually called optimization or defragmentation. It speeds up file access because the read/write head doesn't have to jump all over the disk looking for the next piece of the file. \/\/\/\/\/\/\/\/\/ | Brian T. Tao | UUCP: torag!pnet91!taob | / \ | University of Toronto | INET: taob@pnet91.cts.com | \ The Apple II / | Scarberia, ON | taob@pro-micol.cts.com | / Lives On!! \ |:::::::::::::::::::::::::::::::::::::::::::::::::::::::| \ / | "Computer guru? Someone who got their computer a | /\/\/\/\/\/\/\/\/\ | couple of weeks before you did." (Alvin Toffler) |
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (11/06/90)
taob@pnet91.cts.com (Brian Tao) writes: > You mean to say that Apple Pascal keeps all your files CONTIGUOUS (all in >one continuous block, not scattered all over the place). Is that feature >automatic? Or do you have to specify Krunch Disk to optimize the files? All The feature is _required_ in the sense that Apple Pascal will give a disk full error rather than write a fragmented file to disk. It was simply incapable of dealing with fragmented files, and the Krunch facility was necessary because of it. Todd Whitesel toddpw @ tybalt.caltech.edu
dcw@lcs.mit.edu (David C. Whitney) (11/06/90)
In article <104@generic.UUCP> taob@pnet91.cts.com (Brian Tao) writes: >> It probably has to due >> at least partially with the fact that Apple Pascal makes you keep your >> files sequentially on disk > > You mean to say that Apple Pascal keeps all your files CONTIGUOUS (all in >one continuous block, not scattered all over the place). Is that feature >automatic? Or do you have to specify Krunch Disk to optimize the files? Apple Pascal actually won't write your file to disk if there isn't a large enough contiguous block of free space. K)runching just presses the (already) contiguous files into one large used space, thereby making all the freespace contiguous. The directory entry for each file indicated which block the file starts at and how many blocks long it is. This pretty much eliminates the need for index blocks. Has it's plusses and minuses (can you say, "Krunch It!" every ten minutes?). -- Dave Whitney Computer Science MIT 1990 | I wrote Z-Link and BinSCII. Send me bug dcw@lcs.mit.edu | reports. I need a job. Send me an offer. Every now and then one makes a mistake. Mine was probably this post.
knauer@sunc7 (Rob Knauerhase) (11/07/90)
In article <1990Nov6.144524.28199@mintaka.lcs.mit.edu> dcw@lcs.mit.edu (David C. Whitney) writes: [snip, snip] >is. This pretty much eliminates the need for index blocks. Has it's >plusses and minuses (can you say, "Krunch It!" every ten minutes?). Yes, I can, but the other people in the lab would probably get annoyed after the first few times... [Sorry, I couldn't resist! :-) ] Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Robert C. Knauerhase knauer@cs.uiuc.edu U of Illinois @ Urbana-Champaign rck@ces.cwru.edu,knauer@cwru.bitnet Case Western Reserve University knauer@scivax.lerc.nasa.gov NASA Lewis Research Center "<esc> : q ! <return> emacs <return>" -- all the vi you need to know...
jh4o+@andrew.cmu.edu (Jeffrey T. Hutzelman) (11/07/90)
Apple Pascal MUST store files contiguously on disk. The Krunch option
moves all the files on a disk to one end, so all the free space is in
one contiguous block. This is necessary because Apple Pascal can't deal
with fragnmented blocks.
--------------------
Jeffrey Hutzelman America Online: JeffreyH11
Internet: jh4o+@andrew.cmu.edu BITNET: JHUTZ@DRYCAS
>> Apple // Forever!!! <<bill@braille.uwo.ca (Bill Carss) (11/07/90)
In article <1990Nov5.141216.28524@mintaka.lcs.mit.edu> dcw@lcs.mit.edu (David C. Whitney) writes: >In article <1990Nov5.112859.7962@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >>unknown@ucscb.UCSC.EDU (The Unknown User) writes: >> >>>I doubt Pascal makes a "SYSTEM"-ish file though) Jeez, that seems to be >> >>It doesn't. Apple Pascal has no knowledge of Prodos. It might be possible >>to write a prodos application that acted as a front end to pascal created >>code. To my knowledge, no one has attempted this yet. > >EEAACK! There's good reason. Apple Pascal compiled to P-Code (which, >by the way, will run on any machine running a P-interpreter). It did >not compile to 6502 assembly. Part of the P-system is the >P-interpreter. In order to get an Apple Pascal program to run under >ProDOS, you'll need to write a P-interpreter running under ProDOS. >Oog. Too much work for any one sane mind. I don't know how this discussion got started, but it might be a good place to ask a few Pascal - ProDOS related questions and a good forum for displaying my ignorance at the same time!!! I thought or think, that such disks as Apple Presents AppleWorks are Pascal disks. Further, I think that AppleWorks was originally written in Pascal. Considering that there are obviously .system files on the AppleWorks disk it would seem, assuming that my contention that AppleWorks is Pascal, that much of the previous discussion is a bunch of hooey!! Now that I have your attention via raising your dander, I would like to ask a question or two: 1. I have some software called Pascal ProFile Manager (which as of yet I have never used). Can I "mix" Pascal and ProDOS files on my hard drive via this software? 2. The program has a file selection facility and assuming number 1 is true, could I use this selector for activating ProDOS applications? Thanks very much for waht ever help you can offer. Bill Carss bill@braille.uwo.ca (please note the lower case) A - mazing // // ___ P - rovocative // // // \\ P - enetrating // // // \\ L - imitless // // |||||||||| E - ducational // // \\ // // \\ __ // -- Bill Carss bill@braille.uwo.ca (Please Note the Lower case!!)
jb10320@uxa.cso.uiuc.edu (Desdinova) (11/07/90)
In article <85@braille.uwo.ca> bill@braille.uwo.ca (Bill Carss) writes: >I don't know how this discussion got started, but it might be a good >place to ask a few Pascal - ProDOS related questions and a good forum >for displaying my ignorance at the same time!!! > >I thought or think, that such disks as Apple Presents AppleWorks are >Pascal disks. Further, I think that AppleWorks was originally written in >Pascal. Considering that there are obviously .system files on the >AppleWorks disk it would seem, assuming that my contention that AppleWorks >is Pascal, that much of the previous discussion is a bunch of hooey!! AppleWorks started out as the Apple /// program "/// Easy Pieces". // Easy Piece was written in Pascal. The II version of that program which became known as AppleWorks, was and is written entirely in 6502 assembler. The only Apple II Pascal that can produce .SYSTEM files is/was KYAN pascal. Unfortunately, this product is no longer produced or supported. If you can find it it is an excellent investment. It was relatively quick (Even on a //e) and produced good code. I believe there were libraries for graphics, and for a "desktop" metaphor environment (pop-up menus, windows, code could be used as a pop-up from AppleWorks, etc.) >Bill Carss >bill@braille.uwo.ca (please note the lower case) -- Jawaid Bazyar | Blondes in big black cars look better wearing Senior/Computer Engineering | their dark sunglasses at night. (unk. wierdo) jb10320@uxa.cso.uiuc.edu | The gin, the gin, glows in the Dark! Apple II Forever! | (B O'Cult) Comp.Sys.Apple2- Home of the Unofficial Apple II Developer Support Team (DST)
gwyn@smoke.brl.mil (Doug Gwyn) (11/07/90)
In article <85@braille.uwo.ca> bill@braille.uwo.ca (Bill Carss) writes: >Can I "mix" Pascal and ProDOS files on my hard drive via this software? Yes, the Pascal ProFile Manager creates a partition specifically for Apple's version of UCSD Pascal. >could I use this selector for activating ProDOS applications? I don't think so but I'm not 100% sure.
dcw@lcs.mit.edu (David C. Whitney) (11/07/90)
In article <1990Nov6.221751.9629@ux1.cso.uiuc.edu> knauer@cs.uiuc.edu (Rob Knauerhase) writes: >In article <1990Nov6.144524.28199@mintaka.lcs.mit.edu> I write: >>(can you say, "Krunch It!" every ten minutes?) > >Yes, I can, but the other people in the lab would probably get annoyed >after the first few times... > >[Sorry, I couldn't resist! :-) ] > >Rob Aw, a WISE GUY, eh? Well, take THAT (shivers his hand violently in front of Rob's face) and THAT (as he waves his hand back and forth - Rob is captivated) and THAT (finally bringing his down to the floor - Rob falls over). HA! So there. Dave -- Dave Whitney Computer Science MIT 1990 | I wrote Z-Link and BinSCII. Send me bug dcw@lcs.mit.edu | reports. I need a job. Send me an offer. Every now and then one makes a mistake. Mine was probably this post.
bh1e+@andrew.cmu.edu (Brendan Gallagher Hoar) (11/08/90)
Kinda of as a side comment: There was a program released before Appleworks called QuickFile II (I have a feeling thats completely wrong) that basically was the Appleworks Database. It was written in Apple Pascal by Rupert (Robert?) Lissner (Lisner?), the author of Appleworks 1.0 thru ?.?... It was nice...I used it for about 2 months - then I found out about Appleworks and purchased it. God, that was a long time ago. Only 20 and feeling much older at the moment. Never had tha happen before. Brendan G. Hoar bh1e+@andrew.cmu.edu Carnegie Mellon, Inc.
toth@tellabs.com (Joseph G. Toth) (11/27/90)
In article <1990Nov5.141216.28524@mintaka.lcs.mit.edu>, dcw@lcs.mit.edu (David C. Whitney) writes: > In article <1990Nov5.112859.7962@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: > >unknown@ucscb.UCSC.EDU (The Unknown User) writes: > > > >>I doubt Pascal makes a "SYSTEM"-ish file though) Jeez, that seems to be > > > >It doesn't. Apple Pascal has no knowledge of Prodos. It might be possible > > EEAACK! There's good reason. Apple Pascal compiled to P-Code (which, > by the way, will run on any machine running a P-interpreter). It did > not compile to 6502 assembly. Part of the P-system is the > P-interpreter. In order to get an Apple Pascal program to run under > ProDOS, you'll need to write a P-interpreter running under ProDOS. > Oog. Too much work for any one sane mind. P-interpreters tend to be Language context/system dependent. Due to the file structure of Apple Pascal, thers is a special option for the file close operation; close ( file_id, crunch ); where the crunch option causes a file system compression. This is file system dependent, meaning that the code compiled for this option might be handled incorrectly under a ProDOS P-code interpreter, or any P-code interpreter not using the Apple Pascal file format. Has anybody investigated Manx, Apprentice C or HyperC to determine whether either of these is a P-code system?? > -- > Dave Whitney > Every now and then one makes a mistake. Mine was probably this post. Ya know, mine probably was too... ;^) Joe Toth Tellabs, Inc. Lisle, Il.
jeff@pro-avalon.cts.com (Jeff Jungblut) (11/28/90)
In-Reply-To: message from toth@tellabs.com > Due to the file structure of Apple Pascal, thers is a special option > for the file close operation; > > close ( file_id, crunch ); > > where the crunch option causes a file system compression. > > Joe Toth > Tellabs, Inc. > Lisle, Il. I don't remember the crunch option. Was this new in 1.3? On a related note, can anyone post a brief list of feature changes and enhancements made from 1.2 to 1.3? Specifically, just how compatible is it with 3.5" disks and SCSI hard disks? Does it support any kind of ProDOS file access through the F(iler or other utilities? -- jeff@pro-avalon UUCP: crash!pro-avalon!jeff ARPA: crash!pro-avalon!jeff@nosc.mil INET: jeff@pro-avalon.cts.com
jmuller@Stardent.COM (Jim Muller) (12/07/90)
In <4673@tellab5.tellabs.com> toth@tellabs.com (Joseph G. Toth) writes: >In <1990Nov5.141216.28524@mintaka.lcs.mit.edu>, dcw@lcs.mit.edu (David C. Whitney) writes: >...a special option > > close ( file_id, crunch ); > >where the crunch option causes a file system compression. And then in <24019.apple.net@pro-avalon> jeff@pro-avalon.cts.com (Jeff Jungblut) writes: >I don't remember the crunch option. Was this new in 1.3? No, it was not new in 1.3. In fact, it wasn't even new in 1.2. It is (I believe) a "standard" UCSD-Pascal option, and it doesn't cause a file system compression. The crunch option for CLOSE causes the file to be marked EOF immediately after the point of last access rather than the end of that disk block. Normally when a file is extended in place or created, the system grabs the next disk block. If you do a normal close, the file will contain whatever was on the disk through that block. If it is an edited text file, this won't matter, since text files are managed by the system via a 2-block header. For a data file or a text file that is created by a program, it may not matter either as long as subsequent reads attempt to read only what was originally written. But if you were to edit a text file that a program, not the editor, had created, you would pick up a lot of garbage at the end of the file. Thr crunch option prevents that. I suspect that J.G.T. mistook this for the Filer command K(runch), which does do a file-system compression. -- - Jim Muller