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 4 ... 10
 on: February 22, 2021, 11:45:53 am 
Started by RadRacer203 - Last post by blusnowkitty
I'll second the cleaning and lubrication of the 400k drive. The grease that Sony used on those drives back in the day is no good anymore and it'll keep the mechanism from working properly or at all. The gear Ray linked is for an 800k drive, the Sony 400k drives are all metal linkages so there's no plastic gears to strip out there. I'll again second Ray and say you want to pick up a Floppy Emu, but add you'll want one anyway no matter what you want to do for the physical floppy drive. It's just /so/ much easier to dump your collection of disk images onto a Floppy Emu and boot those than have to worry about getting a compatible Mac and fussing with Disk Copy, or bootstrapping BLU over serial and writing disk images over serial.

For hard drives, an X/ProFile or a Cameo is the way to go. If I didn't already have an X/ProFile I'd probably go with the Cameo myself since Tom has been doing some amazing work with the Cameo that makes it a lot more user-friendly than the X/ProFile is. You will have to get a run of Cameo boards made if you want to go down that route, but I know PCBway can do full assembly of the boards for you for an extra charge. If you do go down the Cameo route, you will have to get a Widget to DB-25 adapter from VintageMicros, or find a dual parallel card.

For my keyboard, I used TexElec's premade foil/foam discs and I've had absolutely no issues since: They're fiddly to install as you have to make sure that the plastic disc that makes up the sandwich gets properly clipped into some very tiny plastic clips, and you want to make sure you either use latex/nitrile gloves or tweezers to install the discs since finger oils could keep the keyboard from working properly.

ETA: If you do end up replacing the drive with an 800k drive, you'll need a new set of drive standoffs to get the 800k drive to align properly with the faceplate opening. You will also have to replace the disk I/O ROM with the Sun Remarketing 800k ROM as the original disk ROM doesn't understand 800k drives at all. The ROM can be found on BitSavers if you have the ability to burn it yourself. Lisa Office System doesn't understand 800k disks by default; you'll still only be able to use 400k disks unless you also load the 800k driver:

 on: February 22, 2021, 11:33:20 am 
Started by RadRacer203 - Last post by rayarachelian
Generally you can clean/lubricate the floppy drive and use isopropyl to clean the drive heads. see:
You can find videos on youtube on how to do this, there are many, here's one from a Mac, which uses the same mechanism:

It's also possible that the eject gear is broken, if so you can use these: - (though not sure if this is the right gear or for an 800k one).

You could also replace the floppy drive entirely with a FloppyEmu:

Keyboard repair is painful, you can find instructions here:
Basically you have to find the right type of foam, and mylar to cut with a leather punch.
There are also various devices that allow you to use the keyboard from a Mac 128/512/512KE or ADB, or even USB instead:

Hard drive wise, X/ProFile from Vintage Micros is the way to go, or you could build your own IDEFile:
Most recently Tom Stepleton has built the Aphid/Cameo which is nearly ready to go, see:

 on: February 22, 2021, 11:32:30 am 
Started by compu_85 - Last post by RadRacer203
I got my Lisa this past Friday from a former Apple software engineer who picked it up when a business was upgrading back in the day. It sat in his basement for years and now that he's moving I got the privilege of picking through all his computers he collected over the years, and taking home some really nice examples of machines I've never seen, not just the Lisa!

 on: February 22, 2021, 11:21:59 am 
Started by RadRacer203 - Last post by RadRacer203
Just got my first Lisa (a 2/10 model) this past Friday and overall it's in nice shape and doesn't need a whole lot. It does turn on, no errors found, but can't boot because the hard drive is completely shot and the floppy drive immediately rejects disks without even seeking. The power supply needs new capacitors and I'm going to have a friend help me with that, and the foam in the keyboard is bad, as is typical.

Right now I want to find a hard drive solution for it, preferably more or less plug and play and not as expensive as the x/profile. I also want to either get the original floppy drive working or find a replacement, maybe an 800k drive?

 on: February 22, 2021, 10:04:44 am 
Started by compu_85 - Last post by rayarachelian
Every LOS 3.x has a Priam specific driver on it, just like it has one for the profile. Actually there's two files, one is for the running OS, and another is for booting. (There is a third driver for the parallel port itself when used with ProFiles/Widgets.) I don't yet know enough about why a different driver is needed during booting, perhaps it's invoked by the loader blocks (BB,BB).

UniPlus has drivers in the kernel for these as well, and there is source for the kernel (and these drivers). The schematics and drive manuals are up on bitsavers for this drive. These are a totally different protocol than the ProFiles.

I know there were several drives compatible with the ProFile protocol, SunRem made a controller also that accepted an MFM/RLL drive. It's possible Corvus had an interface to this or a model that supported this protocol. Perhaps it needed a driver (or not.)

OSCONFIG is a clue for me, thanks for finding that. I did see differences in BLU widget dumps from profile dumps in SYSTEM.CONFIG - the clue there is the boot device failure and moving from say motherboard parallel port to expansion slot parallel port, or profile to widget, etc. I'll have to figure out more info about OSCONFIG and perhaps how to replace it when moving data from a Widget to a ProFile.

 on: February 22, 2021, 09:56:43 am 
Started by stepleton - Last post by rayarachelian
Also wondering, how did one transfer files from Monitor to LOS? Did LOS 1.x understand the Monitor file system or vice versa?

 on: February 22, 2021, 08:07:01 am 
Started by compu_85 - Last post by compu_85
I've seen some tidbits saying that a Corvus hard disk could be connected to the Lisa:

  • The Lisa OS Guide:
  • This post from someone using Unisoft back in the day:
    "...if anyone hears of a RAM disk for the Uniplus System V, I'd love to hear it. 
    (PS: one of our staff has a Lisa with a Corvus disk.  Aside from the fact that the Corvus disk has failed a few times, he loves it.
    The problem is strictly with the slowness of the Profile.)"
  • These notes from the Lisa Handbook, page 27
    "Any additional drive must always be connect via a parallel card, whether its augmenting a profile drive or a 10-megabyte drive.
    Lisa now supports a 70-megabyte drive manufactured by Priam and distributed by Tecmar.
    UNIX and XENIX users have the option of attaching drives from Corvus and Sunol in sizes from 20 to 100 megabytes. "
  • References in the Uniplus (and I think Xenix?) manuals for the procedure to create the device file for a Corvus and format the disk

So here's the question... how was the Corvus disk attached? It also used an 8 bit parallel interface, but looking the the pinouts it seems quite different from the ProFile.

CHM has a prototype Lisa with a Pippin (Profile) / Corvus card:
Al has some pictures of the card here (which looks quite similar to the 1 port Parallel card I got last year..):

Does anyone have more info on this? A friend has some Corvus drives and I'd love to give this a try.



 on: February 21, 2021, 10:51:48 pm 
Started by stepleton - Last post by D.Finni
Here's another little tidbit I came across today:

The Filer will create a volume with a large directory, capable of storing 786 file names, so long as the volume size is greater than 2048 blocks (1 MB).

Also, I have a possible reason why the Monitor did not automatically boot from the ProFile. It's because the Lisa developers also had Lisa OS installed in another partition on the ProFile, and they wanted LOS to boot from it instead of Monitor. And they did not yet have a way to pick which OS to boot from the ProFile.

 on: February 21, 2021, 07:56:37 pm 
Started by stepleton - Last post by rayarachelian
That file browser is nice. Looking through one of the files reminds me of another problem I've had with the Monitor disk images on Bitsavers: not being able to run Editor.obj. The error message mentions something about a font file, if memory serves. It's been a while...

Just ran across it here: page 62:

Code: [Select]
The Pascal Development System Manual THE EDITOR File needed:

And on page: 64

The editor uses whatever font it finds in the file LISA:EDITOR.FONT to display the folder contents. The suggested fonts are:

TITLE12R12S.F  20 lines x 82 chars
SARA8.F             26 lines x 83 chars
TlLEX.F               32 lines x 82 chars (default)
TlLE7R15S.F      32 lines x 94 chars
TlLE5R18S.F      37 lines x 132 chars

 on: February 21, 2021, 12:40:03 pm 
Started by D.Finni - Last post by rayarachelian
Ah, ok now I understand what you're after. The Lisa documentation is awfully tight-lipped about it, from my review of it last evening. I'm not totally sure that LOS uses A-line traps. I should admit that it's just my assumption based on so many similarities between Macintosh and Lisa architecture. On Macintosh, the trap dispatch table is located at $400 in RAM.

Yeah the LOS manual just shows you the pascal procedure names, so I'd need to compile code with the pascal compiler, even though I'm just after the assembly side of things, and then analyze the generated code and actual A-Line calls.

Yeah, they're not the same as in A-Line traps in Classic Mac OS (<10.0). On the Mac, the A-Line traps aren't addresses and they have fixed meanings. When you call a specific one in System 0.9, say A0000, it has the the same function as in System 6.0.8 and even in 7.5 or 9.2. And this is what allows for portable code.

In LOS, the A-Line trap is an address into the kernel code, and you can potentially pass anything there, even things that don't belong at all - hence, it's a supervisor trampoline. So it has the potential of changing between versions, further, it's undocumented.

For example, in Solaris 2.6 on SPARC, the open syscall is exactly the same trap as in Solaris 10 SPARC, so the ABI (Application Binary Interface) makes it 100% portable. (Linux on i386 didn't do this, and so you'd need a bevy of libc binaries to have backwards compatibility with previous releases, not sure about x86_64.)

Back to LOS, as long as you can figure out the address of your code in context 0 (and AFAIK context zero maps all RAM), your process can run in supervisor mode.

I suspect that if you're after this, you can ask the MMU mapping for your running segment by using something like this: (this is just a sample off the top of my head, not an actual tested implementation, probably is very wrong in some ways, but it's a skeleton)

Code: [Select]
      LEA shellcode,A0
      MOVE.L A0,D0
      AND #00ffffff,D0
      MOVE.L D0,(saveaddress); save this address for later
      LSR D0,#17  ; d0 now has the segment number of the shellcode
      ; some call here to get mmu register for physical address
      MOVE.L (saveaddress),D0
      ADD A0,D0 ; assuming A0 contains the physical address offset of the segment, add our saved value to it
      AND.L #$00FFFFFF,D0
      ORI.L #$A00000,D0
      LEA trampoline
      MOVE.L D0,(trampoline)
      NOP ; insert some NOPs since we're doing self modifying code here and don't want whatever
      NOP ; pipeline cache our CPU may have from preventing this from working properly
trampoline: DB.L #$A0000000
shellcode: evil code to "Same thing we do every night Pinky, try and take over the world!"
... and now we're in supervisor mode.

Some shifting, and then a read of the MMU register for your current code by calling the right call to give you back the physical address. (Basically shifting it by 9 would give you the segment number and to this you'd add the physical address, and then the offset you got from LEA PC+X,A0).

Then, since context zero (which runs as supervisor) has a very fixed, predictable memory map, you can calculate which address it would match there for your shellcode, and then invoke the A-Line trap for that address (with some self-modifying code to write that address in the A-Line opcode) and you've got supervisor access to the whole of LOS.

Also, on the Mac the A-Line traps are only 16 bits, where on the Lisa they're 32 bits because they're actually addresses (and the high by of 'A?' is a throwaway, so actually 24 bits of address range, but stored as 32 bits worth of opcodes).

Pages: 1 [2] 3 4 ... 10