Print

[AlexTheCat123]

Alex, that is awesome! Nice work 

Thank you! I hope you enjoy the (rather long) presentation!

[bmwcyclist]

Thank you for all of your hard work!

Okay, the video just went up!

https://www.youtube.com/watch?v=X0btMjXEXgc


As I think I mentioned earlier, I won't be back home until late this week, so give me a bit of time to actually get the build scripts and necessary code modifications prepared and uploaded. But I hope to have them ready by mid to late next week!

[sigma7]

Okay, the video just went up!

https://www.youtube.com/watch?v=X0btMjXEXgc

Very good presentation, and quite an achievement!

I suggest we add a new board/area for this topic eg. "LOS Source" or "Building LOS from Source" or something else suitable of your choice.

Thanks for all your hard work and the immense amount of time; I'm looking forward to flagging the bounty challenge as awarded!

[danm]

Alex, that is awesome! Nice work 

Thank you! I hope you enjoy the (rather long) presentation!

Does Al Kossow know about your (amazing, inspiring) work? I know at one point he was complaining that he did a ton of work to get the Lisa OS source released, and then it seemed like no one did anything with it. I think he would be very happy to hear that situation has been rectified!

[stepleton]

Congratulations again --- I wish the video had been twice the length! You really had to figure out puzzle after puzzle to get this thing to build. I'd love to hear more about some of the fixes mentioned in the talk, particularly the Y1.995K problem fix, but this can all come in good time.

[AlexTheCat123]

Thank you all!

I suggest we add a new board/area for this topic eg. "LOS Source" or "Building LOS from Source" or something else suitable of your choice.

Good idea, I like "Building LOS From Source" but anything to that effect would be great!

Does Al Kossow know about your (amazing, inspiring) work? I know at one point he was complaining that he did a ton of work to get the Lisa OS source released, and then it seemed like no one did anything with it. I think he would be very happy to hear that situation has been rectified!

No idea if he does or not, but he is a member on this forum, so he's almost certain to find out eventually. Al, if you're reading this, then I'd love to hear your thoughts!

Congratulations again --- I wish the video had been twice the length! You really had to figure out puzzle after puzzle to get this thing to build. I'd love to hear more about some of the fixes mentioned in the talk, particularly the Y1.995K problem fix, but this can all come in good time.

Yeah, I wish we had more time for the presentation; fitting it all into an hour and a half was a massive challenge. It was indeed puzzle after puzzle, and I omitted many of the finer details and smaller problems I encountered for the sake of time.

The good news is that I was capturing video from the Lisa throughout the entire process using an RGBtoHDMI and narrating things as I went, so I'm hoping to edit down the over 1000 hours of footage into a series of YouTube videos that document the process as it occurred in real time. Hopefully it's not too boring given that it would include every single little thing that I did along the way, but at least everything would be fully and thoroughly documented!

[Al Kossow]

i'm searching for packseg right now.

---

well, after several hours I realized it is a tool in the workshop, and the workshop wasn't included in the binder with the source disks
and I suspect all of the copies of workshop that have been found were from the Mac dev environment which didn't include it :-(

the right version of the workshop pre Mac used for building Lisa is incredibly difficult to find.

[AlexTheCat123]

i'm searching for packseg right now.

---

well, after several hours I realized it is a tool in the workshop, and the workshop wasn't included in the binder with the source disks
and I suspect all of the copies of workshop that have been found were from the Mac dev environment which didn't include it :-(

the right version of the workshop pre Mac used for building Lisa is incredibly difficult to find.

Thanks for searching, hopefully you eventually run across a copy! It's a shame that the pre-Mac version of the Workshop is so hard to find. But I take this to mean that you do actually have the source code to some version of the Workshop at the very least?

[stepleton]

Thanks for searching, hopefully you eventually run across a copy! It's a shame that the pre-Mac version of the Workshop is so hard to find. But I take this to mean that you do actually have the source code to some version of the Workshop at the very least?

I interpreted it as: the binary workshop distribution used to compile the Office System is hard to find or to recreate.

This said, I had a look at LISA_OS/OS/source-UNPACK.TEXT.unix.txt, and while it has a lot of buffer juggling going on (and although I'm not certain that this is the correct file), the algorithm there does not strike me as being very complicated. I think it works something like this:

Code: [Select]

Loop until finished:
   Load a "flag byte" from the compressed input
   For each bit in the flag byte:
      If the bit is empty:
         Copy two bytes from the compressed input to the decompressed output
      If the bit is set:
         Load one byte from the compressed input
         Use that byte as an index into a table of "common" two-byte words
         Copy the word at that index to the decompressed output

There is some accommodation for if the decompressed data is not made of an even number of bytes, plus the buffer juggling I mentioned. I'm probably missing things. Still, I think it might be possible to write a PACKSEG of our own. Note that PACKSEG will probably need to have access to (or will need to create) a file holding the "common word" table; the scripts in the source code appear to call this file packtable.lib.

[AlexTheCat123]

I interpreted it as: the binary workshop distribution used to compile the Office System is hard to find or to recreate.

I think you're right; I just interpreted it wrong.

This said, I had a look at LISA_OS/OS/source-UNPACK.TEXT.unix.txt, and while it has a lot of buffer juggling going on (and although I'm not certain that this is the correct file), the algorithm there does not strike me as being very complicated. I think it works something like this:

Code: [Select]

Loop until finished:
   Load a "flag byte" from the compressed input
   For each bit in the flag byte:
      If the bit is empty:
         Copy two bytes from the compressed input to the decompressed output
      If the bit is set:
         Load one byte from the compressed input
         Use that byte as an index into a table of "common" two-byte words
         Copy the word at that index to the decompressed output

There is some accommodation for if the decompressed data is not made of an even number of bytes, plus the buffer juggling I mentioned. I'm probably missing things. Still, I think it might be possible to write a PACKSEG of our own. Note that PACKSEG will probably need to have access to (or will need to create) a file holding the "common word" table; the scripts in the source code appear to call this file packtable.lib.

I thought about doing this, I just decided against it for the time being since I was already in a massive time crunch to get things done in time for VCF anyway. But you're right, that's a pretty simple algorithm to implement!

[andrew]

Regarding licensing issues... I am definitely not a lawyer, but just looking at those terms:

• redistribute, publish, sublicense, sell, rent or transfer the Apple Software;
• publish benchmarking results about the Apple Software or your use of it;
  
• use the name, trademarks, service marks or logos of Apple to endorse or promote your modifications or other materials derived from the Apple Software.

Obviously, you can't distribute the source itself, but as blusnowkitty mentioned previously, you could publish diff patches of some sort the way ROM hackers do. However, the last two terms seem designed to prevent any human collaboration which could actually be used to further development of the LOS software, let alone optimizing the current version of it.

The term regarding benchmarking results seems like it could be used to broadly prohibit publishing information about how modifications have improved the software, which could cover just about any kind of documentation, release notes, etc.

Apple also doesn't want you using any of their trademarks/logos, etc. to promote the software modifications. That seems like it would prevent someone from even saying a LOS software patch is actually intended to be used for the Lisa in the first place, Lisa being a trademarked term.

It seems like, effectively, people cannot directly refer to the system a LOS patch is for, nor can people explain how an LOS patch improves the software. What are we even left with after that?

[sigma7]

However, the last two terms seem designed to prevent any human collaboration

Interesting take...

If that was indeed the intent, I would expect them to oppose publishing any modifications, which isn't specifically prohibited even though modifications are mentioned as being allowed/expected.

My interpretation of the last phrase is to prevent misrepresenting eg. a modification as coming from Apple, and/or Apple being responsible for it; this topic of not mis-representing your own work as coming from the licensor is common in developer agreements.

I suppose the term "benchmark" may be ambiguous. Although one might lose in court, I think the public would consider publishing a bug fix or new feature, which permits "x" to function in some way that is functionally different from the standard, isn't the same as a benchmark result, which would typically be regarding some kind of 'performance' as a metric. I think this would be worded differently if they meant that one should not discuss the effect of a modification in general.

My impression from the wording is that they don't want 'embarrassing' comparisons of how the code could have been improved in speed or size. I can imagine this coming up in the boardroom where they are discussing the pros and cons of releasing old source code. Is finding an easy fix to a bug the same thing? Maybe, maybe not.

So my current thinking is that I would not be reluctant to publish details of a modification to fix a bug or add a feature, assuming it is done without re-publishing the source code.

Obviously we ought to sort out this issue as best we can, so further thoughts, opinions, and discussion would be helpful.

Ancillary thought: AFAIK, Lisa and the Lisa Logo are not actually trademarks. In general, they aren't accompanied by the informal trademark symbol "TM" or the registered trademark symbol "circle-R", although perhaps they are in some isolated literature.

[andrew]

However, the last two terms seem designed to prevent any human collaboration

I suppose the term "benchmark" may be ambiguous. Although one might lose in court, I think the public would consider publishing a bug fix or new feature, which permits "x" to function in some way that is functionally different from the standard, isn't the same as a benchmark result, which would typically be regarding some kind of 'performance' as a metric. I think this would be worded differently if they meant that one should not discuss the effect of a modification in general.

The term benchmark is what worried me the most - it stuck out to me as an odd thing to be against. A modified version of LOS has the obvious advantage of 40 years of hindsight, to say nothing of the kinds of pressures and deadlines the original developers were faced with. At least in my opinion, it seems like there are a lot of understandable reasons why there's room for optimization. I'm also reminded of Kaze Emanuar's optimizations of Super Mario 64; using the source code, he's made many substantial performance improvements to that game, and I don't think anyone would look at those and have a poorer opinion of the original SM64. Also, that source code was leaked!

Given the more general definition (from my Mac's dictionary, of all things) of the word "benchmark":

a standard or point of reference against which things may be compared or assessed

That to me seems like a way for Apple to prohibit the release of modifications without directly saying so. Perhaps they are less worried about benchmark comparisons and more worried about their own corporate image; perhaps releasing it with an explicit declaration against modification might make them appear user-hostile or re-enforce the perception of Apple as a large conglomerate. Typing that now, it sounds as equally dubious to me as a concern about benchmarking 40 year old software, but I'm sure anyone who's been following Apple's current legal escapades is aware of their tendency to frame themselves as much smaller than their competitors. Certainly now more than ever, they are desperate to avoid the external appearance of being overly controlling - this wasn't as big of a deal a couple years ago of course.

I guess the exact reasoning can only be speculated on without more direct insight.

Naturally, I don't like the thought of any of this; I'd love to see open development of Apple's old OSs as much as anyone else here.

[sigma7]

The term benchmark is what worried me the most...

Given the more general definition (from my Mac's dictionary, of all things) of the word "benchmark":

a standard or point of reference against which things may be compared or assessed

The interpretation "bug fixed" vs the point of reference of "bug not fixed" as being a "benchmark result" seems valid enough in the literal sense.

That to me seems like a way for Apple to prohibit the release of modifications without directly saying so.

Perhaps it is intentionally vague, not so that they can catch someone out, but rather they have the option of suppressing something bad that arises which they hadn't anticipated.

Back to the actual phrase

"publish benchmarking results... "

I think publish involves making it publicly available, so it may be sufficient to put bug fixes, new features, and other items potentially covered by the broadest interpretation of "benchmark results" in a restricted/private area; requiring some kind of agreement/test for admission to establish that it is clearly not public.

Presumably there is a recognized way of ensuring that something accessed via the internet is not considered public... someone know offhand?

[jamesdenton]

Okay, the video just went up!

https://www.youtube.com/watch?v=X0btMjXEXgc


As I think I mentioned earlier, I won't be back home until late this week, so give me a bit of time to actually get the build scripts and necessary code modifications prepared and uploaded. But I hope to have them ready by mid to late next week!

Just finished this video and continue to be super impressed with your efforts and success. You guys should be super proud of what you managed to do here. Looking forward to what's to come!