Print

[kgraaf]

I think a bug fix/feature request list is a great idea

I think Y2K support would be an excellent candidate. I'm pretty good with Object Pascal, I'd be more than happy to contribute

[compu_85]

Here's the start of a bug / feature list. If you want write access to the sheet just ask me.

https://docs.google.com/spreadsheets/d/1bP4ad3zF4Vy0UQ_-CiGT5f5SDYZy13ba3xez9iaGvi0/edit?usp=sharing

-J

[blusnowkitty]

Can we list "OS has copy protection features" as a bug?

More seriously, a good feature to put on the list I think would be to put Twiggy support back in. Maybe look at the Sony driver to see what it'd take to add back in external drive support, that'd be convenient. Maybe add 800k and 1.44MB drive support while we're at it? Though I don't think the original IWM can do HD.

Looking through the Lisa 1.75 docs, there's a reference to someone prototyping a disk drive card that could run Apple II, 871/Twiggy, and Sony drives.

[sigma7]

Here's the start of a bug / feature list.

Thanks for putting XLerator support on the list of potential features... I've been pondering whether that's of interest for a long while.

Also -- SCSI hard disk driver?

[kgraaf]

On the subject of hard drives, I will echo what I believe others have said, that VirtualBox-style shared folders would be immensely helpful. Obviously, that would require LisaEm support as well.

[D.Finni]

You guys have a lot of exciting ideas, but have any of you started to actually study the source to understand its structure and design?

[blusnowkitty]

You guys have a lot of exciting ideas, but have any of you started to actually study the source to understand its structure and design?

I think right now we're in the wish list phase...

[stepleton]

You guys have a lot of exciting ideas, but have any of you started to actually study the source to understand its structure and design?

Eh, there are plenty of things I've dreamed about doing with a computer or with programming that I filed away for years until I decided to mess around with it one day, or until I knew enough about the topic to actually accomplish what I wanted to do. The Lisa isn't going anywhere. So there's plenty of time to dream. (Of course Apple can terminate the license at any point with 30 days' notice, but let's hope they don't  ).

Once we have a good set of ideas, it may be possible to treat them like a curriculum --- we can do what we guess are the easy ones first and learn as we go to build up to harder and harder ones. For example, maybe Twiggy support isn't so tough and is a good place to start: perhaps it's an artificial limitation where the OS just detects a Lisa 1 and throws up an error, and this check can be defeated.

[sigma7]

have any of you started to actually study the source to understand its structure and design?

I have spent some time looking at the code for the Priam drivers; partially to help troubleshoot the DataTower I have that no longer works, and partially with the hope that tape drive support can be added to BLU someday (which entails sub-projects of troubleshooting tape drives and drive bands).

Having done so (and having worked on low-level SCSI code before), I'm thinking that writing the code for a SCSI driver is not a huge project. However a big unknown (to me) is how one gets the driver from source code to a binary installed in the OS.

So I agree with the others that have suggested:

• task 1 is being able to compile and install the code as-is, and documenting how to do that;
• task 0 is brainstorming what might be done with this fantastic opportunity -- thanks Al !!

As Al has pointed out, it is crucially important that Apple not regret releasing the code, so an overriding consideration is how Apple may be affected... eg. would they see a SCSI driver as a good thing, bad thing, or neutral/don't care? To me, this isn't a simple question; hopefully Al's upcoming post will help frame this objective.

[Al Kossow]

You guys have a lot of exciting ideas, but have any of you started to actually study the source to understand its structure and design?

Pretty sure we're all in agreement the first order of business is to figure out how to get the OS built in the first place, preferably through a more modern environment.

I don't think there is any agreement about that at all AFA doing it in a modern enviroment beyond having it emulated with a decent debugger.

[blusnowkitty]

You're right, sorry; corrected my post!

[compu_85]

A while ago I made somewhat of a joke thread about the Lisa "Pepsi" system, and we weren't quite sure what Pepsi actually was.

From APIN-OFFICE.TEXT:

Code: [Select]

{constants used to check the value returned by the Mach_Info call
(the I/O board part of the record)}

IOlisa       = 0;    { Old I/O board (lisa) w/Twiggys }
IOpepsi      = 1;    { New I/O board (pepsi) w/Sonys and Widget }
IOlisaLite   = 2;    { Old I/O board (lisa) w/Sonys }
IOpepsiLite  = 3;    { New I/O board (pepsi) w/Sonys, no Widget }

And there we have it. I didn't know a Widgetless 2/10 was called a PespiLite. Better than Diet Pepsi I suppose?

-J

[Al Kossow]

Reconnected with Ron this weekend.
Here is a talk where he talks about AppleNet
https://www.youtube.com/watch?v=pFxNwUhL3Wg

[stepleton]

AppleNet is between 27:15 to 29:35 if anyone's in a hurry, but he goes on to talk about LocalTalk and continues from there through the G5 and beyond. Thanks for the link!

[compu_85]

Here's another tidbit I saw in source-PROFILE.TEXT

(*Drive types*)
T_Profile = 0;
T_Seagate = 1;
T_Widget  = 2;

if (discsize <= 9728) or (discsize > 30000)
then drivetype:= T_Profile (* set drivetype to profile *)
else
if drivetype <> 0 then
begin (*widget*)
  remap_interleave := false;
  drivetype:=T_Widget;
  rvrs_hdr:=20; (*headers are at end of sector*)
end
else
begin (*Seagate*)
  drivetype:=T_Seagate;(*10mb seagate*)

(I cut some lines out of this code). So if the disk is exactly 5mb, or over 15mb use the Profile driver. If it's a Widget use that driver, otherwise use the 10MB Seagate (10mb profile??) driver.

-J