Advanced search  


2019.06.07 fixed NChat for the "Curve" theme, will eventually move it to its own page and add it to the default theme as well. Other plugins are next. see post in the Meta board for details

Pages: [1] 2 3 ... 10
 on: August 04, 2020, 08:01:56 pm 
Started by rayarachelian - Last post by rayarachelian
I've pushed the RC2 source code up at github, I couldn't yet push the macos x binaries.

 on: August 03, 2020, 08:57:08 pm 
Started by rayarachelian - Last post by rayarachelian
So I was curious to see if fixing "The Bug" would help MacWorks, and it did, somewhat.

It Macworks started to work for a bit, I tried 3.0 and 4.5, they now both format the hard drive and install on it, *however* trying to boot from the hard drive causes a sad mac with f0004 or something like that, so there is some improvement, but not enough to get it working again. I'll revisit this later.

Booting from the boot disk after the hard drive is installed also causes the same sadmac.

Also trying to format a disk larger than 10MB causes it to run a very long time and estimate 0mins and 0 seconds so perhaps earlier versions of MacWorks don't work too well with larger drives, but that's less of a concern.

 on: August 03, 2020, 03:37:12 pm 
Started by rayarachelian - Last post by D.Finni
Really fantastic news! And this opens up a lot of opportunities for the future, as you well know.  ;D

 on: August 03, 2020, 02:38:39 pm 
Started by rayarachelian - Last post by rayarachelian
Thanks guys. I'll clean up the source after work and start rolling back the 32 bit to 24 bit tonight, if it still works fine in 24 bit mode, I won't pursue fixing the high byte of PC anymore, though it might turn out that uniplus or xenix might be using that, I think macworks should be since it's not 32 bit clean, but the unix ones don't work due to profile/floppy emulation anyway, so I won't mess with that until after 1.2.7 production is released (likely mid-end of this month the way things are going.)

After that, going to take a break before starting on 2.0 as I've got a huge backlog of physical Lisa projects such as power supply recapping and fixing NiCAD damaged boards, etc.

But yeah, will see about picking up things to make it easier to automate using LPW without directly interacting with it as one of the early features. Some of those will likely make it into a 1.2.8 before I start bringing back the libGen core from 1.3.0 and rerunning the CPU tests against it.

Took a month to get through this batch of CPU tests, but I'm glad it worked out, and now I can reuse them on the 1.3.0 core which will add a lot more features for debugging as well, which might be useful in reversing LOS - unless ofc, AEK releases the sources before I finish that off, etc. :) But yeah, I think the odds are that AEK will be able to use 1.2.7 for his efforts before 2.0 gets shipped since there are a lot of features there, like splitting up the emulator proper from the GUI.
This should also open up other fun avenues like a maybe a QT or native macos versions or a wasm version of lisaem eventually.

Did you guys see these - they're desktop emus made from emscripten recompiles of Basillisk II (not sure about the windows one), but talk about coming full circle, from desktop emu in C to web emu and back to desktop app. :)


 on: August 03, 2020, 02:22:12 pm 
Started by rayarachelian - Last post by stepleton
Congratulations!! This will be huge for people who want to try making Lisa software. It's going to be a lot easier to experiment with the ToolKit now.

 on: August 03, 2020, 07:37:31 am 
Started by rayarachelian - Last post by jamesdenton
Fantastic work! Congrats!

 on: August 02, 2020, 11:32:16 pm 
Started by rayarachelian - Last post by rayarachelian
bug has been fixed, linker works now, scrollbars and desktop menu are good.
Will take me a few days to rollback the pc24->pc32 changes and test if it breaks anything, the will push to github + push another RC, etc.

 on: August 02, 2020, 05:53:54 pm 
Started by blusnowkitty - Last post by rayarachelian
Yes, you're right in that "it's not that bad," and also that this was the state of the art at the time, and that they were used to it and so they accepted it, but that's also playing apologist for the bad decisions made.

It could have been a lot better compared to how well designed and polished the LOS desktop and tools are, and certainly when compared to the smalltalk env in the Alto, i.e.: back in 1976. Comparatively, MPW did it better, but that rewrite should have been to LPW instead. Maybe it was just a matter of time, but the Lisa's ran out, as more focus went to the Mac.

 on: August 02, 2020, 01:02:15 pm 
Started by blusnowkitty - Last post by stepleton
Eh, I don't think it's that bad. To each their own.

Some points: the FILE-MGR being a separate manager is at least a callback to the Monitor, where it was a separate program, and also the p-System before that, which had the "Filer". (It might be a separate program in the Workshop, too---that is, a separate .OBJ file, the same way the compiler and the linker are, among others. Not sure.) It makes sense for there to be some consistency between the Monitor and the Workshop, I think: the Lisa team had probably got pretty used to their toolchain by then, and why switch horses midstream.

Perhaps more importantly: in 1982-'83, I expect things that look like the p-System would have been familiar to large parts of Apple's developer userbase and others. Apple had been shipping the extremely similar Apple Pascal on the ][ since 1979 (it was one of the reasons for the Language Card), and the real pSystem was one of the OS options for the IBM PC (alongside CP/M 86 and one other that I can't remember right now). So going with something that looks like a major market offering isn't a bad idea if you've just gotta ship.

Tesler could have asked for a fancier IDE, but I'm guessing the dev support team was also busy building the ToolKit once they got the Workshop out the door, and I wouldn't be surprised if their attention couldn't be divided. The ToolKit is a rather elaborate system and maybe would have seemed a higher priority for people trying to rebuild what they did or saw at PARC. This is all just a guess though. Certainly there is a lot of new design in the ToolKit, and you can tell when comparing it to something like the Unix GUI offerings around the same time, which are much more rudimentary.

You can eject a floppy from the file manager using the U{nmount :)} option. I actually didn't know you could do it from the Editor...

You can have variables and parameters in EXEC files that have more interesting names than %n. PDF page 167 has the details.

The $ prefix is the main thing I think is "wonky", but the good news is that you can choose whether to use it to prefix internal language lines or the menu-system commands --- either way is acceptable :)

I think EXEC was (literally) more than adequate for the intended purpose. Could it have been better? Sure, but I think it gets the job done, and it doesn't really take much wrestling for it to do that, especially if you are already comfortable with Pascal syntax. The entire Workshop 1.0 installer is in EXEC; so is the utility that publishes your QuickPort app to the Office System. Neither are trivial programs. I guess I don't see the Workshop or EXEC as missed opportunities from a product success perspective---there are probably other things I'll tackle first if I ever get the chance to play Larry Tesler Simulator '82. (You win if Lisa survives as a product until 1996, in which case the I/O board COPS year date limit is the boss level.)

 on: August 02, 2020, 11:49:31 am 
Started by blusnowkitty - Last post by rayarachelian
I mean it's lame in the "Those who do not understand Unix are condemned to reinvent it, poorly." sense.

I fully understand that the shell is the first thing the kernel runs and about init. It's not lame because of that.

It's lame because it's not a proper scripting language, and has no interactive repl. It's a menu system on to which a hack of an exec language has been bolted on to. Basically, stapling extra legs on a dog to make an octopus.

And while the rest of the Lisa has a GUI, this isn't a graphical IDE, so it's basically the worst of all worlds, and it isn't self consistent. Some of its commands are hidden from the menu but documented in the exec  documentation.

The ones that are part of the menu, like "p" for pascal, "a" for assemble, "g" for generate code are single letter commands, typically with curly braces after to write a comment. So pretty much everyone used P{ascal}file where the P was the thing that actually invoked the compiler, but the {ascal} was a comment - so people had to write comments around to make it prettier as a workaround.

For the commands that aren't part of the menu you have prefix with a $ - sure you have have flow logic like if else, and you can call other exec files, but it's really ugly.

And sure, it does have variables like %1 to %9. I mean... ok they're called "parameters" and sure you can do some operations on them like UPPERCASE, but it's very limited.

I mean, DOS batch scripts are more self consistent and more capable than this thing. And I'll refrain from comparing how bad it is compared to sh or ksh, or even perl - and yes, it's possible to write clean well structured, readable perl, just as it's easy to write line noise perl.

And even the menu system is inconsistent. To copy files, compile, link, or power off, or reboot you use this menu system, but to eject a floppy you have to use the GUI text editor. wtf? And that system manager vs file manager in the top level menu? what manager? it's all part of the same binary, there's no separate executable on disk for those. There's no actual "manager" there.
And speaking of the editor, when you launch it it asks you for a file name, which you have to type in. But if you create a new one and save it, it gives you a model dialog file browser or something like that. It's also inconistant.

I can't speak to the rest of LPW, I'd guess it's a proper compiler/linker toolset, though it does use intermediate code generation which isn't ideal, but that's ok.

The rest of LOS is far better designed and self-consistent. This thing is not properly designed, it's been slapped together from multiple schools of thought, and then more features have been accreted on to it with no thought to redesign/refactor it to make it consistent.

MPW at least was a lot better designed and is a lot more consistent.

This could have been a lot better. These guys saw Smalltalk at Xerox, and Tesler should have asked them to build a full IDE here rather than borrowing piece meal from uscd pascal. I don't think Turbo Pascal existed before LPW was built, but something like that would have been 100x better.

Sure the end user was free to write their own shell, hopefully do a better job, but the point is that it should have shipped with a better shell to begin with and a better scripting language.

Pages: [1] 2 3 ... 10