3 ms·

The UCSD p-System was amazing. I used it on a Heathkit-branded PDP-11, the Apple II, and an HP-9000 workstation; and though the author doesn't mention it, the

The UCSD p-System was amazing. I used it on a Heathkit-branded PDP-11, the Apple II, and an HP-9000 workstation; and though the author doesn't mention it, the first version of Borland's Turbo Pascal for CP/M and DOS had a UI that was clearly influenced by the p-System's UI. The coolest thing about UCSD Pascal when I first encountered it was it supported "full screen" programs, notably the system's text editor, via the `gotoxy(x, y)` intrinsic. This procedure moved the cursor to the specified character cell on the terminal. Prior to this I'd only used line-oriented editors.

mbessey 2y ago
I did mention the Turbo Pascal connection briefly, and I'll probably make a more in-depth comparison in a later post on just the IDE. I used a fairly early version of Turbo Pascal for DOS for several years after High School. I can still remember the absolute terror of realizing you'd pressed "R" without saving first.
- sitkack 2y ago
  I never used it, are you saying you could Run the current program and it might accidentally bring your entire system down without having saved the program? Seems like at least a two file circular buffer with autosave wouldn't take up too much space, or maybe streaming diffs into a compressed buffer (even on a 286, this shouldn't be too much trouble).
  - kragen 2y ago
    I think that is what he is saying, though I can't remember the TP command set well enough. Turbo Pascal wasn't written on a 286; it was written for CP/M, where I think it required 48KiB of RAM. A "fairly early version of Turbo Pascal for DOS" might have required 64KiB? You can't really stream things onto a floppy disk (remember that early home computers and the IBM PC didn't have hard disks; they didn't become standard equipment until the late 80s). You have to write a whole sector at a time, which can take a second or two to seek the disk to the appropriate track; rotating the disk to the right sector takes a significant fraction of a second. Journaling your edits to a journal file was a feature that EDT on VAX/VMS had around that time, but there wasn't really a practical way to do that on a home computer.
    - sitkack 2y ago
      Yeah, I see that. I had an Amiga and mostly used the HD, so I don't really remember how slow the floppy drives were. Maybe for systems with tape drives we could live code and stream a journal to audio tape? A log of all the edit commands should be doable, maybe even as DTMF tones. That would be funny if early OSes had an 8track (endless loop) as the circular journal. I think that is how the Voyager probes work. The 8 track DTR on the Voyager probes did not have an endless loop. https://hackaday.com/2018/11/29/interstellar-8-track-the-low-tech-data-recorders-of-voyager/ https://hackaday.com/2018/11/29/interstellar-8-track-the-low... Did you see this Show HN: Torque – A lightweight meta-assembler for any processor (benbridle.com) https://news.ycombinator.com/item?id=43698801 https://news.ycombinator.com/item?id=43698801 It is a Forth inspired programmable assembler. based off of https://wiki.xxiivv.com/site/uxn.html https://wiki.xxiivv.com/site/uxn.html
      - kragen 2y ago
        It's definitely an entertaining idea! And you probably could have made it work. RAM would have been a cheaper and probably more reliable edit journaling device than an 8-track tape. It would survive warm boots unscathed where you had to reboot the computer after hanging it, failing only if your edits were lost to a power outage, and you would test it all the time, not just when the computer crashed. A battery-backed CMOS shift register memory chip, maybe about 2048 bits in size, would have solved the power loss problem, but keep in mind that a lot of these early microcomputers were so bare-bones they didn't even include a real-time clock, which is the other thing you want the battery for. In 01996, Chen et al. at UMich proposed just such a (non-battery-backed) RAM journal to avoid losing written data in kernel crashes in https://web.eecs.umich.edu/virtual/papers/chen96.pdf https://web.eecs.umich.edu/virtual/papers/chen96.pdf, "The Rio File Cache: Surviving Operating System Crashes". They reported that it worked surprisingly well, and it enabled them to increase the durable transaction rate of their spinning rust filesystem by about three orders of magnitude, if I recall. And of course NetApp have been shipping FAServers using that approach (with battery-backed RAM) since day one, also about 01996. Tim Paterson's blog I linked elsewhere in the thread has some comments about quantitatively exactly how fast different floppy systems used on 8-bit computers were.
      - 2y ago
  - mbessey 2y ago
    Yes, that exactly. Part of what made Turbo Pascal so fast was that it kept your entire program, and the compiler, in memory. You had an option from the main menu to "compile" or "run", which included compiling, but NOT saving your edits first. You could save first, but on a floppy-based system, that could take a while. I want to say that behavior changed in Turbo Pascal version 2, or 3?
    - dumdedum123 2y ago
      At least until 3 which is what I used.
  - cardiffspaceman 2y ago
    But control-Kdsr saves your work to the device it came from and runs the program. Approximately the WordStar command set with additions for the task at hand.
- dumdedum123 2y ago
  Oh the memories! You are exactly right. I remember this as well.
- dumdedum123 2y ago
  For a blast from the past https://www.pcjs.org/software/pcx86/lang/borland/pascal/3.02a/ https://www.pcjs.org/software/pcx86/lang/borland/pascal/3.02...
- wduquette 2y ago
  My bad; I missed the Turbo Pascal reference. I first heard of Turbo Pascal in a magazine called Profiles, published by Kaypro for owners of their computers; I'd recently gotten a Kaypro 4, which ran CP/M-80, my first computer of my very own, and I was pining for Apple Pascal/UCSD Pascal. I read the ad (and maybe a review?); it was $49.95, and I ordered it immediately. Nor was I disappointed.
musicale 2y ago
> Heathkit-branded PDP-11 The idea that you could save money by soldering together your own PDP-11 system from parts, and that there was a company that actually sold the kits (as well as assembled versions), is terrific. And today (assuming you can find a vintage DCJ11 CPU or equivalent) you still can build your own hardware PDP-11 via PDP-11/Hack and other designs! (Though personally I'll probably go for an FPGA version.)
- wduquette 2y ago
  I watched my dad build the PDP-11, terminal, and paper tape reader/punch. Eventually we got a dual-8” floppy drive; he might have built that, too, I don’t remember.

mbessey 2y ago

I did mention the Turbo Pascal connection briefly, and I'll probably make a more in-depth comparison in a later post on just the IDE. I used a fairly early version of Turbo Pascal for DOS for several years after High School. I can still remember the absolute terror of realizing you'd pressed "R" without saving first.

sitkack 2y ago
I never used it, are you saying you could Run the current program and it might accidentally bring your entire system down without having saved the program? Seems like at least a two file circular buffer with autosave wouldn't take up too much space, or maybe streaming diffs into a compressed buffer (even on a 286, this shouldn't be too much trouble).
- kragen 2y ago
  I think that is what he is saying, though I can't remember the TP command set well enough. Turbo Pascal wasn't written on a 286; it was written for CP/M, where I think it required 48KiB of RAM. A "fairly early version of Turbo Pascal for DOS" might have required 64KiB? You can't really stream things onto a floppy disk (remember that early home computers and the IBM PC didn't have hard disks; they didn't become standard equipment until the late 80s). You have to write a whole sector at a time, which can take a second or two to seek the disk to the appropriate track; rotating the disk to the right sector takes a significant fraction of a second. Journaling your edits to a journal file was a feature that EDT on VAX/VMS had around that time, but there wasn't really a practical way to do that on a home computer.
  - sitkack 2y ago
    Yeah, I see that. I had an Amiga and mostly used the HD, so I don't really remember how slow the floppy drives were. Maybe for systems with tape drives we could live code and stream a journal to audio tape? A log of all the edit commands should be doable, maybe even as DTMF tones. That would be funny if early OSes had an 8track (endless loop) as the circular journal. I think that is how the Voyager probes work. The 8 track DTR on the Voyager probes did not have an endless loop. https://hackaday.com/2018/11/29/interstellar-8-track-the-low-tech-data-recorders-of-voyager/ https://hackaday.com/2018/11/29/interstellar-8-track-the-low... Did you see this Show HN: Torque – A lightweight meta-assembler for any processor (benbridle.com) https://news.ycombinator.com/item?id=43698801 https://news.ycombinator.com/item?id=43698801 It is a Forth inspired programmable assembler. based off of https://wiki.xxiivv.com/site/uxn.html https://wiki.xxiivv.com/site/uxn.html
    - kragen 2y ago
      It's definitely an entertaining idea! And you probably could have made it work. RAM would have been a cheaper and probably more reliable edit journaling device than an 8-track tape. It would survive warm boots unscathed where you had to reboot the computer after hanging it, failing only if your edits were lost to a power outage, and you would test it all the time, not just when the computer crashed. A battery-backed CMOS shift register memory chip, maybe about 2048 bits in size, would have solved the power loss problem, but keep in mind that a lot of these early microcomputers were so bare-bones they didn't even include a real-time clock, which is the other thing you want the battery for. In 01996, Chen et al. at UMich proposed just such a (non-battery-backed) RAM journal to avoid losing written data in kernel crashes in https://web.eecs.umich.edu/virtual/papers/chen96.pdf https://web.eecs.umich.edu/virtual/papers/chen96.pdf, "The Rio File Cache: Surviving Operating System Crashes". They reported that it worked surprisingly well, and it enabled them to increase the durable transaction rate of their spinning rust filesystem by about three orders of magnitude, if I recall. And of course NetApp have been shipping FAServers using that approach (with battery-backed RAM) since day one, also about 01996. Tim Paterson's blog I linked elsewhere in the thread has some comments about quantitatively exactly how fast different floppy systems used on 8-bit computers were.
    - 2y ago
- mbessey 2y ago
  Yes, that exactly. Part of what made Turbo Pascal so fast was that it kept your entire program, and the compiler, in memory. You had an option from the main menu to "compile" or "run", which included compiling, but NOT saving your edits first. You could save first, but on a floppy-based system, that could take a while. I want to say that behavior changed in Turbo Pascal version 2, or 3?
  - dumdedum123 2y ago
    At least until 3 which is what I used.
- cardiffspaceman 2y ago
  But control-Kdsr saves your work to the device it came from and runs the program. Approximately the WordStar command set with additions for the task at hand.
dumdedum123 2y ago
Oh the memories! You are exactly right. I remember this as well.
dumdedum123 2y ago
For a blast from the past https://www.pcjs.org/software/pcx86/lang/borland/pascal/3.02a/ https://www.pcjs.org/software/pcx86/lang/borland/pascal/3.02...
wduquette 2y ago
My bad; I missed the Turbo Pascal reference. I first heard of Turbo Pascal in a magazine called Profiles, published by Kaypro for owners of their computers; I'd recently gotten a Kaypro 4, which ran CP/M-80, my first computer of my very own, and I was pining for Apple Pascal/UCSD Pascal. I read the ad (and maybe a review?); it was $49.95, and I ordered it immediately. Nor was I disappointed.

musicale 2y ago

> Heathkit-branded PDP-11 The idea that you could save money by soldering together your own PDP-11 system from parts, and that there was a company that actually sold the kits (as well as assembled versions), is terrific. And today (assuming you can find a vintage DCJ11 CPU or equivalent) you still can build your own hardware PDP-11 via PDP-11/Hack and other designs! (Though personally I'll probably go for an FPGA version.)

wduquette 2y ago
I watched my dad build the PDP-11, terminal, and paper tape reader/punch. Eventually we got a dual-8” floppy drive; he might have built that, too, I don’t remember.