38

Apple's UCSD Pascal for the Apple II used its own file system rather than the existing DOS 3.3 of the day. I'm not sure if it overlapped SOS at all, but regardless of timelines it seems that the Pascal file system was separate and incompatible from SOS and the later derived ProDOS.

What was the point of Apple Pascal having its own file system? Why couldn't it have just used DOS 3.3 or at least ended up serving as a compatible base for SOS / ProDOS?

Leo B.
  • 19,082
  • 5
  • 49
  • 141
bjb
  • 16,259
  • 46
  • 141
  • The focus of the question is on why UCSD Pascal for Apple used its own file system, but I wanted to point out that Microsoft DOS in particular was not an available file system of the day. Apple computers never used DOS, and, moreover, UCSD Pascal for Apple ][ was released before the the original IBM PC (and DOS 1.0). – John Bollinger Sep 02 '17 at 05:22
  • I learned on an Apple //e running UCSD Pascal! It has a fond place in my heart. What bugged me was that the floppy only held 140K or something like that. It was also difficult to ship an app for endusers when the file system requires contiguous blocks! – JDługosz Sep 02 '17 at 06:37
  • 13
    @JohnBollinger, DOS 3.3 is an early Apple II file system that was popular from introduction in 1978 until the mid-1980s when ProDOS presumably took over. I was not referring to Microsoft MS-DOS. – bjb Sep 05 '17 at 16:46

3 Answers3

39

UCSD Pascal was a product of UCSD - The University of California at San Diego. It was not a product of Apple.

UCSD Pascal was available on a number of machines, including the PDP-11, TI99/4, the BBC Micro and the IBM PC. It was a noble attempt to produce a fully cross-platform language.

UCSD Pascal used a disk filing system that was intended to be implemented across all hardware platforms. Thus enabling software written and compiled to P-code on one machine to be used on another. The filing system did away with proprietary restrictions on the lengths and formats of filenames, which were seen as a bar to interoperability.

In my experience transfer wasn't as seamless as was planned but it did greatly assist cross-platform development.

Chenmunka
  • 8,141
  • 3
  • 39
  • 65
  • Presumably the Apple ][ implementation doesn't go so far as to produce floppies that e.g. a BBC could read? They're logically compatible, but not physically? I have no idea whether you can tell the Disk ][ to use a fixed rotation speed close to 360RPM and/or take charge of the encoding, but it feels worth asking since that's exactly the sort of stuff you might leave the CPU to do if producing a compact interface. – Tommy Aug 31 '17 at 15:40
  • 4
    Not realy. ApplePASCAL was an Apple Product, based on UCSD Pascal. The initial revision was bases on the P-Code System 2.1, but with an independant development from there on (AFAIR there where 4 or 5 Releases Apple did). In todays tems it might be called a fork. – Raffzahn Aug 31 '17 at 16:45
  • 1
    Many from the problems of transfering P-Code programms came from the fact that the P-Code was changed several times in incompatible manner. To transfer binary (P-Code) proframms, the receiving machine must implement the same P-Code version. Thanks to that quirk UCSD-Pascal was only real cross platform on a source code base. It was a bit like Linux/Unix. You need to recompile when changing the machine, but you had a great chance of doing so without any need for changes. – Raffzahn Aug 31 '17 at 16:49
  • @Tommy: No, you can't tell Apple II drives to change RPM, or to use MFM instead of GCR: It's impossible to overcome the physical restrictons of floppy disk controller hardware by software. All UCSP-p implementations had to use the underlying hardware, which meant incompatible physical floppy disk formats. No way around that. – dirkt Sep 01 '17 at 05:33
  • @dirkt so you're saying that unlike, say, the C1540, it wasn't up to the CPU (the second one on a 1540, but whatever) to set rotation speed as a function of track, or to perform the GCR encoding? I don't know the Disk ][ but since the hardware is famously minimal, that surprises me a little. – Tommy Sep 01 '17 at 11:02
  • @Tommy: Comment is too short to explain the Apple II disk in full, but: (1) you can't set the motor speed at all. (2) You can simulate "rotation speed" by timing, but there's little wiggle room. The CPU isn't fast enough, or you have to get very lucky in your cycle counting. (3) The Apple format relies heavily on having a "1" transition every 8-th bit (or every 10-th bit for sync, that's how syncing works, in contrast to every other format). You just can't read other formats with that. If you are curious, read up on details how the all of this works. – dirkt Sep 01 '17 at 12:12
  • 3
    @Chenmunk I'd have thought the intent was that programs would be interchangeable, without having to worry about filename conventions (e.g. C:\usr\file.txt vs. /usr/file.txt). – TripeHound Sep 01 '17 at 13:02
  • @dirkt yeah, I've implemented only the very-locked-down i8272, mostly-locked-down WD177x/179x, and the do-whatever-you-feel-like C1540/1541. I grabbed the Disk ][ firmware, meaning to figure it out, but haven't yet. I guess it's somewhere at the Intel/Western Digital end of the spectrum then, rather than the Commodore end. – Tommy Sep 01 '17 at 13:07
  • @Tommy: There isn't really Disk II "firmware", it's all software run on the main CPU. The ROM contents (which you probably have) are just for booting. Google for an annotated assembly listing of the RWTS routine if you want details. It's similar to the Commodore 1541, but different, and without the additional hardware. The IBM formats used in the WD controllers are totally different. – dirkt Sep 01 '17 at 15:21
  • 1
    @dirkt I'm referring to the small ROM — maybe 256 bytes, or around that, but I'm at work now so not minded to start searching Google for "Apple ROM"-type phrases — that Woz used to implement his state machine. Probably not used by garden variety emulators, as it was mildly difficult to find, but likely used by the good ones. Never visible within any CPU's address space. EDIT: from my phone, I'm referring to: http://www.retro.co.za/ccc/apple2/christer/Apple/p6.romdump.html . – Tommy Sep 01 '17 at 15:36
  • @dirkt Perhaps in addition to the 256-byte ROM used as a PLA, the other 256-byte boot ROM at 6502 $C600 contains enough of a subset of RWTS to work out how to build an original RWTS. – Damian Yerrick Sep 01 '17 at 18:21
  • +1 for referencing pcode. Actually pcode pascal was also available for the ibm pc but never had any great audience – Rui F Ribeiro Sep 02 '17 at 12:23
  • @DamianYerrick: While I understand that some programs made use of the $Cx00 ROM after it had loaded and launched code at $0800, that design seems dodgy. It makes the RAM code very dependent upon extremely fine details of how the ROM is set up, and the only benefit it offers is saving at most 100 or so bytes of RAM. If the Disk II card had a bigger ROM with a general-purpose RWTS routine at $C800 code that used that might avoid hardware dependencies, but there's no way anything that isn't essentially identical to the Disk II hardware would have a RWTS entry point in the right place in ROM. – supercat Apr 22 '18 at 19:22
  • 2
    @RuiFRibeiro: The game "Wizardry" had been previously published on the Apple II using the UCSD P-system was ported to the IBM PC, also using the UCSD P-system. While there are some slight changes to the graphics, I wouldn't be surprised if the game code is essentially untouched. – supercat May 24 '18 at 22:16
25

UCSD Pascal was developed prior to the Apple II, during the 70's in San Diego, using PDP-11 class machines with a 512-byte block disk structure. In the process of porting it to microcomputers, often (not always) the file system also got ported.

UCSD Pascal was seen as a closed environment offering everything in one place. Today we might call this an IDE and see it as an application on top of an existing OS. But back in the very early microcomputer days most machines didn't have a DOS of their own. And even if some OSes were available, they were usually rather frugal and mostly just a bunch of hacks to attach floppies one way or another (let's be serious, the Apple DOS was one of them). Thus just only adapting the very basic hardware drivers while keeping everything above in transportable P-code, was a rather clever solution.

Keep in mind, the goal of the P-System was to offer students a standardized programming environment, where they could work on every machine, the university could afford, like on a PDP and have create exactly the same replicable results a course requies. It was never ment to be a language kit for software development for microcomputer systems.

To some extent it was quite similar to early mainframe applications — what we nowadays see as an OS was an integral part of the application, thus forming a world of its own. It wasn't until much later that the P-code system changed from a standalone application to a runtime package running on top of a 'regular' OS (like PC-DOS).

Adopting Pascal for the Apple II can be seen as the first major step of Apple into the educational market. In the course of history, SOS and later ProDOS did inherit the 512 byte block size from the UCSD P-code system, as Pascal was the main implementation language for the Apple III — and later all Mac software. In fact, for some time the Pascal development did also drive Apple II development in general. For example, release 1.1 introduced the 'Firmware Protocol' that required add-on cards to show certain signatures at $Cn05/07/0B and $Cn0C to help identify a card and its functions. Due to the importance of Apple Pascal, hardware manufacturers added them soon. ProDOS (and GS/OS) rely on these markers to identify and handle cards they know.

Nick Westgate
  • 7,688
  • 1
  • 27
  • 61
Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • 2
    So if I am to interpret your answer inline with the spirit of my question, it is simply because UCSD Pascal was ported as a whole for the Apple II which included the filesystem to simplify many of the layers of the universal P-code system? i.e. it was for simplicity of the P-code system rather than the practicality of what was in place for the Apple II at the time? – bjb Sep 05 '17 at 16:50
  • @bjb Exactly. "What was in place at the time" is in fact a nice point,as that was 13 sector DOS. It was the use of 512 byte blocks by Pascal that made Woz create the 16 sector format. He reason was that with uneven sectors per track each track contained only 6 1/2 blocks, spreading every 13th block across two tracks, slowing access to that block down. So Woz wanted to create a format with an even number of sectors and managed to get it up to 16. This being adapted to create DOS 3.3 wasn't exactly welcome with the the Apple III group :) – Raffzahn Feb 08 '24 at 18:59
4

Pascal for the Apple /// actually used the SOS file format and was compatible with files written by Business Basic. SOS was adapted into ProDOS for the Apple II-series machines, but Pascal /// was never ported to it to my knowledge. And, yes, it's a darn shame Pascal and the other UCSD languages FORTRAN, BASIC, and MODULA/2 couldn't run together.

Larry Smith
  • 41
  • 1
  • Welcome to Retrocomputing Stack Exchange. Please read the [tour]. This isn't quite an answer, but it's close enough to be useful. – wizzwizz4 May 09 '18 at 15:38