-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Anyone have a DC42 image of Lisa COBOL
- Thread starter Corey986
- Start date
maybe this one ?
ftp://bitsavers.informatik.uni-stuttgart.de/../../bits/Apple/Lisa/cobol_2.0/
[edit]
seems good
ftp://bitsavers.informatik.uni-stuttgart.de/../../bits/Apple/Lisa/cobol_2.0/
[edit]
seems good
Last edited by a moderator:
I can second that! I had no idea there was Lisa Cobol. I wonder how many man-hours went into that port vs. the number of copies of the software actually sold...
The cost was probably not too high. This cobol seems to be a third party cobol ported to the workshop. You just have to port some api and probably adapt a runtime library but since there is already an os and a c and pascal compiler you do not start from scratch. Anyway a cobol compiler was mandatory for a business oriented computer (at least until around 2000)
I don't think I'd go that far. While it's true that COBOL development systems existed for most larger 8 and 16 bit Microcomputers I don't think Cobol applications were ever particularly widespread outside of a few specialized areas. (For instance, Tandy sold a line of accounting/business management software written in RS-COBOL for the TRS-80 Model 2/12/16/6000 series that were shovelware ports of older Minicomputer software.) So far as I can tell the Macintosh got along fine without one. Casually searching Google/Macintosh Garden for a Cobol compiler turns up zero hits.
Really, what makes it just so bizarre on the Lisa is literally the whole point of the Lisa was to showcase the GUI environment. I would likewise be curious if any numbers exist as to how many buyers actually used software limited to running inside the Workshop environment. I suppose in theory the Lisa wasn't *that* much more expensive than roughly-comparable business-centric computers like the Radio Shack Model 16 (another 68000 machine) after Apple slashed prices in 1984, but it only lasted a year before it was effectively discontinued. (They sold rebadged Lisas as MacXL's until mid-1985, but can a Lisa with the "Square Pixel" mod run Workshop software anymore?) It just seems like it would make scads more sense for a small business that relies on Cobol for some vertical-market thing to buy something like a Tandy Xenix box (or maybe something like an Alpha Micro S100 machine) to keep in the back room. They could always use the Lisa as a terminal, the Office System environment came with the software for that.
I think the ambition to make the Lisa a "business supermicro" really reflects an important original goal of Apple's Personal Office Systems division---note that the Lisa project was well underway before the decision was made to give it a GUI.[1][2]
Apple certainly seems to have hired toward that goal, poaching programmers and engineers from the big minicomputer firms.[3] As such, it might not be so surprising to find minicomputer-like features on the Lisa, including an MMU (granted, you are going to need virtual memory to run all that software) and an operating system with multiprocessing, four types of inter-process communication, user-defined exceptions, and all kinds of other elaborate bells and whistles.
The Lisa was meant as a personal computer, but I don't think it was ever expected to be a home computer. Virtually all of the marketing materials I've ever seen talk about business and show the machine in an office context. Apple sold (expensive!) systems for having your Lisa talk to IBM mainframes[4] over 327x links, and AppleNet networking was going to tie your branch office together.
In this context, I think Cobol matches the overall goals of the POS group. It wasn't well-integrated with the GUI, but virtually no third-party applications were, at the beginning---I gather that the Office System was initially a lot like iOS before they let you have third-party apps. If you wanted to write Lisa programs, you got a black-on-white console, and you weren't happy with plain text, it was basically up to you to put bits on the screen. At least Apple gave you QuickDraw!
(Later on they released QuickPort, and later still the ToolKit for writing "fully fledged" Office System apps.)
Check out the Lisa brochures on Bitsavers.[5] The ones about programming resources take care to point out compatibility with "serious" language standards. The BASIC-Plus brochure brags about "Large-System Capabilities" and compatibility with the offering from DEC, for example.
references
[1] https://www.cs.oberlin.edu/~jwalker/lisa-legacy/
[2] http://lowendmac.com/2005/history-of-apples-lisa/
[3] https://guidebookgallery.org/articles/applesbidtostayinthebigtime
[4] https://books.google.co.uk/books?id=fC4EAAAAMBAJ&lpg=PA71&ots=6QL4ghIByL&dq=apple cluster controller&pg=PA71#v=onepage&q=apple cluster controller&f=false
[5] http://bitsavers.informatik.uni-stuttgart.de/pdf/apple/brochures/Lisa/
Apple certainly seems to have hired toward that goal, poaching programmers and engineers from the big minicomputer firms.[3] As such, it might not be so surprising to find minicomputer-like features on the Lisa, including an MMU (granted, you are going to need virtual memory to run all that software) and an operating system with multiprocessing, four types of inter-process communication, user-defined exceptions, and all kinds of other elaborate bells and whistles.
The Lisa was meant as a personal computer, but I don't think it was ever expected to be a home computer. Virtually all of the marketing materials I've ever seen talk about business and show the machine in an office context. Apple sold (expensive!) systems for having your Lisa talk to IBM mainframes[4] over 327x links, and AppleNet networking was going to tie your branch office together.
In this context, I think Cobol matches the overall goals of the POS group. It wasn't well-integrated with the GUI, but virtually no third-party applications were, at the beginning---I gather that the Office System was initially a lot like iOS before they let you have third-party apps. If you wanted to write Lisa programs, you got a black-on-white console, and you weren't happy with plain text, it was basically up to you to put bits on the screen. At least Apple gave you QuickDraw!
(Later on they released QuickPort, and later still the ToolKit for writing "fully fledged" Office System apps.)
Check out the Lisa brochures on Bitsavers.[5] The ones about programming resources take care to point out compatibility with "serious" language standards. The BASIC-Plus brochure brags about "Large-System Capabilities" and compatibility with the offering from DEC, for example.
references
[1] https://www.cs.oberlin.edu/~jwalker/lisa-legacy/
[2] http://lowendmac.com/2005/history-of-apples-lisa/
[3] https://guidebookgallery.org/articles/applesbidtostayinthebigtime
[4] https://books.google.co.uk/books?id=fC4EAAAAMBAJ&lpg=PA71&ots=6QL4ghIByL&dq=apple cluster controller&pg=PA71#v=onepage&q=apple cluster controller&f=false
[5] http://bitsavers.informatik.uni-stuttgart.de/pdf/apple/brochures/Lisa/
Last edited by a moderator:
Of course, in retrospect it starts to become obvious that Apple's "Personal Office System" ambitions lead them down a lot of dead ends that didn't make a ton of sense. The Lisa failed in part because Apple wasn't able to communicate a clear vision for why it was worth spending $10,000 (wasn't it more like $13,000 with the hard disk?) for their office computer verses any number of competitors that sold for less than half that. Given that its main selling point was the UI I can't help but think putting out brochures for COBOL and "Basic Plus" that don't actually use it could be considered, well, "muddying the waters".
(It kind of cracks me up that the brochures for those languages describe the purgatory environment they're stuck running inside as having "facilities similar to the Apple II and Apple /// Pascal environments". Way to go, reminding potential customers about the Apple ///. Which, incidentally, also had a COBOL compiler and was a lot cheaper... assuming you'd be foolish enough to buy one in 1983.)
Can't argue with that. But why limit it to just one flaw:
- Too expensive
- Far too slow
- Incompatible with everything
- Rectangular pixels
- Unreliable floppy media
- Built-in nuisance DRM
- No satisfying way to program third-party apps (until too late)
- Office apps were largely middle-of-the-pack, features-wise
- Disastrous timing with the Macintosh nipping at its heels
I love the Lisa---they tried so hard; they built their (largely prophetic) vision the future of computing, and... it just didn't work out. It's hard not to imagine the disappointment! Look at page 23 of the Dialog Building Block chapter in the ToolKit documentation:
But at least they got to build a complicated, innovative, and fascinating system all the way from the ground up, and deep down what engineer or designer doesn't want to do that?
I can't wait to see the source code...
- Too expensive
- Far too slow
- Incompatible with everything
- Rectangular pixels
- Unreliable floppy media
- Built-in nuisance DRM
- No satisfying way to program third-party apps (until too late)
- Office apps were largely middle-of-the-pack, features-wise
- Disastrous timing with the Macintosh nipping at its heels
I love the Lisa---they tried so hard; they built their (largely prophetic) vision the future of computing, and... it just didn't work out. It's hard not to imagine the disappointment! Look at page 23 of the Dialog Building Block chapter in the ToolKit documentation:
But at least they got to build a complicated, innovative, and fascinating system all the way from the ground up, and deep down what engineer or designer doesn't want to do that?
I can't wait to see the source code...
Lisa is not that slow, it’s 5mhz versus 8mhz for mac but with plenty of ram and a harddrive. Lisa OS is slow but macworks is not and for its time the workshop was a fast dev environment. But does not change the fact it was a failure 
my point of view is that the hardcoded mmu is the major flaw of lisa because 68000 is not restartable processor
my point of view is that the hardcoded mmu is the major flaw of lisa because 68000 is not restartable processor
That is terribly sad yet hilarious at the same time.
(Having been through the slow, flaming death of a company during the "Dot com" bust I can completely sympathize. Every engineer working there believed with all their heart that they had some great technology, and unlike a lot of dot-coms I'd say that they legitimately did have something worthwhile, but sometimes the world just isn't ready, or... whatever.)
In part at least I think where Apple really went wrong with the Lisa is instead of building an "open system" they decided to go all-in on trying to own the whole widget. (Your comparison with iOS was indeed very apt there.) The Macintosh gets a lot of flack for being a closed *hardware* box, but unlike with the Lisa the Mac team made a genuine effort to get third party developers onboard from day one. I can't help but think the Lisa might have faired better if they'd had at least preliminary Toolkit documentation and a reasonable build system available on release; I kind of have to wonder if there might have been some overarching confusion on the part of the entire team about whether the Lisa Office System was in fact going to be the "Operating System" of the computer or if it was always intended to be a self-contained "Integrated Software Suite" (ala something like AppleWorks/Framework/Lotus Symphony/etc) that Apple controlled the horizontal and vertical of exclusively. (Again you can make iffy comparison to iOS'es original intention that "third party development" be limited to optimized web apps.)
Maybe in the end you can just attribute it all to hubris. Sure, Apple hired plenty of brilliant people, but you've got to be careful about letting people like that get sucked into believing that they're "smarter than everyone else" and being blinded as a result. The utter failure of Apple's Disk Storage division (around the same time as the Lisa, non-coincidentally enough) seems to have been largely the result of the engineers stubbornly sticking to ideas they thought were brilliant and world-shattering when really, no, they just weren't that great. I hate to say it, but maybe Steve Jobs was onto something by regularly subjecting his employees to humiliating abuse. That's one way to keep them from getting too comfortable. Granted it might not be the optimal one.
Yesterday I randomly looked up details on the MMU (because "virtual memory" was mentioned above and, so far as I was aware, the Lisa didn't actually support virtual memory in the "transparent demand paging" sense) and frankly the patent description and the documentation in the Lisa hardware manual left me scratching my head. As you note the 68000 doesn't support restarting from a page fault... but beyond that, it doesn't seem like even the prospect of demand paging is brought up. (By comparison, the documentation for the MMU in the roughly contemporaneous SUN-1 makes a big point of talking about how the MMU *will* support it when the CPU does and, indeed, the Sun-2 uses almost exactly the same design with the substitution of a 68010.) It's... weird, frankly. The Lisa isn't a multi-user machine, and if you *just* want hardware protection for supervisor-verses-user code anyway you can still manage that with a significantly simpler design. Do the Lisa OS/applications actually leverage the multiple virtual address space context feature in any meaningful way, or does the MMU just get set up once when loading LOS and is mostly left alone at that point?
The 68000 is good at handling relative addressing (IE, it's not hard to make code mostly-arbitrarily relocatable) so you don't really *need* a flat virtual memory space per task. (Machines like the Amiga and the Mac got by mostly fine without it.) I have this vague recollection (I can't find a reference quickly so I'll stick to the vagueness, maybe I'm mistaken) that the Apple III included a simple MMU that allowed the location of the stack (and maybe the zero page?) to be changed using a simple register, which can be really useful if you're trying to multi-task on the 6502 because normally the locations of those are fixed. My jaded theory is that *maybe* by analogy with the 6502 the Lisa team decided that the speed improvement you can get on the 68000 from using the "short" 16 bit addressing mode was significant enough that it was worth implementing an MMU that would let each task have its own mapping for the first 32k of RAM.
Last edited by a moderator:
I have to admit that I'm mostly taking it on faith that the Lisa is using demand paging (for pete's sake, what on earth could the thing be doing as you stare for seconds at a blank LisaWrite window with the ProFile blinking away furiously :lisa2: ).
But the Operating System manual does describe it in section 4.6, starting on page 89 of this PDF. There's only a paragraph, basically.
Folks may know this already, but if I understand correctly, while the Lisa engineers understood that the 68000 was not restartable in general, they determined that some instructions were restartable. For that reason, if your program intended to access an area of memory that you didn't know was already prepared for you, you had to try to provoke a page fault first by touching it with one of the "safe" instructions (TST.W was recommended specifically). Procedure calls in particular needed to do this to make sure that the stack would be big enough for the procedure's arguments and variables. If your program didn't test the ice before it tried to stand on it, then it deserved to fall into the lake, I guess.
For more details, check out section 6.6.1 of the Workshop Users Guide, or page 110 of this PDF.
In light of what other manufacturers were doing to get virtual memory on a 68000 system, having this combined hardware/software approach seems like an elegant kludge, if there is such a thing.
(for those who don't click on the last link: let's just have two 68000s---one of them "goes first" and triggers a page fault, then the second one cleans up the mess and puts the first processor back on its feet. I assume without knowing that the second processor was ordinarily running the same program as the first, allowing it to know what the register contents were just prior to the page fault. Well, that's one way to do it.)
But the Operating System manual does describe it in section 4.6, starting on page 89 of this PDF. There's only a paragraph, basically.
Folks may know this already, but if I understand correctly, while the Lisa engineers understood that the 68000 was not restartable in general, they determined that some instructions were restartable. For that reason, if your program intended to access an area of memory that you didn't know was already prepared for you, you had to try to provoke a page fault first by touching it with one of the "safe" instructions (TST.W was recommended specifically). Procedure calls in particular needed to do this to make sure that the stack would be big enough for the procedure's arguments and variables. If your program didn't test the ice before it tried to stand on it, then it deserved to fall into the lake, I guess.
For more details, check out section 6.6.1 of the Workshop Users Guide, or page 110 of this PDF.
In light of what other manufacturers were doing to get virtual memory on a 68000 system, having this combined hardware/software approach seems like an elegant kludge, if there is such a thing.
(for those who don't click on the last link: let's just have two 68000s---one of them "goes first" and triggers a page fault, then the second one cleans up the mess and puts the first processor back on its feet. I assume without knowing that the second processor was ordinarily running the same program as the first, allowing it to know what the register contents were just prior to the page fault. Well, that's one way to do it.)
Last edited by a moderator:
The thing I guess I'd point out about that is that swapping chunks of code and data back and forth to disk by no means relies on having an MMU if you're willing to live with the limitation of having to rely on making a system call to make sure that what you actually want is there before you touch it. (Which it sounds like the Lisa *kinda* does.)
Oldest example I can think of off the top of my head (because once upon a time I was really familiar with it) is TRS-DOS on the TRS-80 Model I and III; TRS-DOS only occupied about 5K of RAM "permanently", but some commands and more rarely used functions were implemented in the form of blobs of code called overlays that shuffled in and out of a transient area, and the OS handled it all transparently. Mostly you wouldn't notice it but, for instance, if you called a DOS command from inside BASIC there'd actually be a semi-significant overhead in doing so because parts of the Disk Basic extensions resided in the overlay area and would be overwritten in the process. (And then subsequently automatically reloaded before execution resumed.) It also had repercussions for software designers because while you could *technically* have a user program use RAM all the way down to the start of the overlay area you'd have to design your program to recover gracefully is you made any system calls that would clobber the overlay area. Note this wasn't *exactly* "swapping" because TRS-DOS would *not* automatically write out whatever already resided in the area when it loaded an overlay; it would just hand the reins back to whatever was running before and say "hey, you might want to reload a fresh copy that thing you had there". Storing user data in the overlay area was thus a very bad idea.) But it could still nonetheless be classified as a *really* rudimentary form of disk-based virtual memory extension.
And, of course, there are infinite examples of application-level "swapping" to be found (IE, word processors capable of working on documents far too large to fit in memory all at once, for instance). It would be odd for that to be happening right after starting the program, though so, sure I'd certainly grant that in the case you describe there's a strong possibility the Lisa is indeed chucking some unrelated things to disk to clear up space in anticipation of you starting to type. I suppose it just comes down to hair-splitting about the exact mechanism whether that counts as "Demand paging". (Did Lisawrite just rudely malloc a heap of RAM for its buffer and start zeroing it, thus causing a series of page faults that spurred the OS into action to swap out a bunch of pages, or did Lisawrite say to the OS "I think I'm going to need at least {this} much space now, pretty please gimmie pages" and the OS is clearing some space without a fault recovery.)
One thing the Lisa's MMU *would* make a lot easier is dealing with the problem of memory fragmentation. There *are* ways you can deal with that without one (tracking data and code segments in the form of linked lists that allow dynamic updates, etc) but none of it's very pretty.
As soon as we get to see the source, we'll know for sure what's going on!
I think it's pretty likely that there is some actual kind of fault recovery underway in some cases, like the stack---as in, the precautionary TST.W causes a real life page fault, the OS handles it, and then the program resumes. (Maybe this could be a kind of one-instruction malloc-me-maybe system call, I guess.) In many other cases, meanwhile, I expect it is the other way---there's no page fault per se, the OS is shuffling segments in and out of RAM on demand.
The manual says things like "If the program calls a procedure in a segment not in memory, a segment swap-in request is initiated." It's not really shedding too much light on what's going on, but since a BSR will definitely affect your register state, I can't imagine that they're handling that with a page fault.
Anyway... as far as the motive for all this goes, I guess even the source code can't explain that---we'll have to summon John Couch to the forum somehow! But if I had to guess, I would expect that in no small part it goes back to the minicomputer-alumni design culture I was talking about earlier:
"Look, see, a serious business computer has an MMU and virtual addressing and paging (and at least a megabyte of RAM, and a modular no-tool-disassembly component design, and baroque infrastructure for software licensing, and COBOL, and...). We were hired away from serious business computer companies, and by golly we are going to make ourselves a serious business computer!"
Perhaps if you have this mindset, it becomes easy to add on additional supporting justifications---like, who knows how complicated this GUI stuff is going to be, we'd better design the hardware defensively so we don't let the software folks down...
I think it's pretty likely that there is some actual kind of fault recovery underway in some cases, like the stack---as in, the precautionary TST.W causes a real life page fault, the OS handles it, and then the program resumes. (Maybe this could be a kind of one-instruction malloc-me-maybe system call, I guess.) In many other cases, meanwhile, I expect it is the other way---there's no page fault per se, the OS is shuffling segments in and out of RAM on demand.
The manual says things like "If the program calls a procedure in a segment not in memory, a segment swap-in request is initiated." It's not really shedding too much light on what's going on, but since a BSR will definitely affect your register state, I can't imagine that they're handling that with a page fault.
Anyway... as far as the motive for all this goes, I guess even the source code can't explain that---we'll have to summon John Couch to the forum somehow! But if I had to guess, I would expect that in no small part it goes back to the minicomputer-alumni design culture I was talking about earlier:
"Look, see, a serious business computer has an MMU and virtual addressing and paging (and at least a megabyte of RAM, and a modular no-tool-disassembly component design, and baroque infrastructure for software licensing, and COBOL, and...). We were hired away from serious business computer companies, and by golly we are going to make ourselves a serious business computer!"
Perhaps if you have this mindset, it becomes easy to add on additional supporting justifications---like, who knows how complicated this GUI stuff is going to be, we'd better design the hardware defensively so we don't let the software folks down...
For sure there is a bus error handler in all versions of los and workshop. The code is complex and rely on identification of the last opcode in the instruction register. I needed to debug the behaviour of the emulator for this. The 68000 core I use is still buggy for some points. I will read the code but probably it will not change much for emulators
What's really tragic, of course, is in the end the last gasp for the Lisa hardware involved being dumbed down to emulate a Macintosh, a machine missing all the "real computer" bells and whistles they worked so hard to build.
Don't get me wrong here, btw, I think the Lisa's a pretty cool machine. It's mostly Apple's business plan for it I don't really get. It's like they genuinely couldn't decide if they were building a COBOL-crunching "Business Computer" in the IBM sense, a Fisher-Price "My First Xerox Star" general-purpose GUI workstation, or some revolutionary new kind of sealed-box "Office Appliance". So they tried to be all of those things to some degree; of them the Lisa was only really well equipped out of the gate to be the last thing, and $14,000 for that was always going to be one heck of a hard sell. Neither of the other two things makes a ton of sense because you could buy better command prompt-based business computers for significantly less; the Lisa also wasn't initially priced *that* much less than a Xerox Star and in a direct comparison it suffers pretty badly. (It's more friendly but is otherwise far less capable.) The Lisa has been described before as a prototype that escaped the lab too early, and unfortunately that's a pretty fair criticism. It definitely feels like Apple should have gone through at least one more round of defining what the thing was supposed to be *for* and optimizing the hardware configuration and price (and building up the necessary developer support) to best fulfill the mission.
(Also, the crazy politics inside Apple undoubtedly didn't help. Having the Mac and the Lisa as two mutually incompatible product lines would never have worked in the long run. Figuring out some way to merge the two into a "family" of upwardly compatible systems might have helped both, considering how the Mac itself almost failed because many of the potential business customers couldn't take a 128k floppy-only computer seriously.)
That was the point of MacWorks.
In my opinion the Mac's #1 problem in 1984 that could have caused it to fail wasn't the RAM size or disk drive, it was the lack of software. A drought. Same as with Lisa, you could argue. Read any Mac magazine or newsletter of the time and you will see this plea in every one of them: where is the software?
Last edited by a moderator:
Of course, the Lisa could not have emulated a Mac so easily...
...if it couldn't place a copy of the Mac ROM at the exact memory address where the software expected to find it. Luckily, it had an MMU to do the address translation :lisa2:
A prior effort to present Lisa and Mac as happy and totally intentional siblings, really, was the marketing term "Lisa technology" (e.g. links below). Either that or it was a subtle hint that the most compelling bits of Lisa had a life---that is, any future at all---outside of the machine itself.
http://www.storiesofapple.net/meet-the-apple-32-supermicros.html
http://www.computerhistory.org/collections/catalog/102630893
...if it couldn't place a copy of the Mac ROM at the exact memory address where the software expected to find it. Luckily, it had an MMU to do the address translation :lisa2:
A prior effort to present Lisa and Mac as happy and totally intentional siblings, really, was the marketing term "Lisa technology" (e.g. links below). Either that or it was a subtle hint that the most compelling bits of Lisa had a life---that is, any future at all---outside of the machine itself.
http://www.storiesofapple.net/meet-the-apple-32-supermicros.html
http://www.computerhistory.org/collections/catalog/102630893
Similar threads
