Re: uniplus disks imaged

gilles wrote:
> I could not find another serial number read but it is not a proof,
> serial number may
> be stored in RAM during boot.
>
>
The boot/install disk (a) calls the Lisa boot ROM and asks for the serial # - this is stored in low RAM at 0x240-0x260. It might make copies of this data somewhere else and refer to it later. I didn't see that it does, but there's nothing to stop it later on during the installation to the profile. I can certainly trap for reads to these addresses once I get my 1.3.0 and profile bugs fixed...

It then calls a few internal routines, which rely on the unix crypt function, and compares it to the value it was serialized from. If they don't match, it prints "Sorry, wrong system." then goes into a long DBRA loop and then returns to the ROM... (I patched the comparison loop to jump out and skip over the message, which was enough to get past this point - there could be other checks which prevent the booting of the OS.)

It is possible for future calls to read 0x240-260 and go through this dance again, but in a slightly different way. I wasn't able to locate the same call on other disks, so if it does exist, it exists in a slightly different way - that might be enough to prevent a search from returning positive results.

If the kernel on disk "a" is what's copied to the hard drive - and it might not be, then we can assume that the hard drive will be deserialized permanently. I haven't traced that deeply, so I can't answer this just yet.
However, both pieces, the memory at 0x240-0x260, and whatever the encrypted hash of the serial number was originally stored on the floppy may still be available to the kernel.

> we have a bit more information than this.
> when the emulator gets stuck, we have something that appears to be the
> kernel in context 0
> And a very little data in context 1 with this string "/etc/init"
> The PC is in an endless loop in this context 1 that seems "normal"
> The keyboard is still responsive.
> The shutdown command is correctly handled.
> An interrupt vector handles IRQ6 for serial events.
>
>
What's missing in the above list that worries me: Are there any timers programmed in VIA1 or VIA2? It seems to me that every OS I've dealt with has had some sort of internal clock separate from the COP421 and uses the interrupts for various tasks.

It seems to me that we'd also want to see an interrupt handler for AVNO=1 since this is shared amongst all the vital devices such as the floppy and parallel port VIA - otherwise it means I/O to the profile is polled.
There needs to be an IRQ handler for the keyboard (AVNO=2), if this is polled instead of interrupt driven, then that's probably not the fully loaded kernel, and it's just some sort of pre-loader with its own I/O handlers.

Also, if you look in the photos, it seems that once UniPlus is fully loaded you see a black console with white text. But the installer program shows white text in the small square drawn by the ROM. So is the program that you're referring to the actual kernel or not, is another question that we need an answer for. It might be the kernel and it might be the same console driver just using different parameters, but I can't say for sure.

> I've searched a bit in my CVS repository. In fact the update that made
> Xenix
> work correctly was made on the cpu core, IRQ auto acknoledgment
> support
> was the problem.

I handle this a bit differently - by checking keeping track of the PC and clock in the general exception handler. Since it's impossible for the same exact opcode at an address to call the same interrupt twice with the same cycle clock value, this prevents duplicate entries. All other I/O devices clear their interrupts based on instructions from inside the IRQ handler routines in their OS to do so, so they'll repeat if not handled, that way the interrupt isn't lost and the device is properly handled. Most ISR's I've seen handle AVNO 1 properly - that is they poll all of the devices they've asked for IRQ's. But, incase they don't, you don't want to lose the IRQ.

> Also, Xenix does not install on a profile that
> already have
> a XENIX system partly installed... but it seems a Xenix bug, not an
> emulator bug.
>
I suspect that this is probably an emulation bug - I haven't seen this in real life on a real Lisa. I was able to install Xenix on a profile that previous had MacWorks back in my early Lisa days. You might want to try this with a profile that already has another OS and try to install Xenix on top of it. Since you have a real Lisa, I guess you can try it there and see how it works.

--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "LisaList" group. To post to this group, send email to lisalist_at_email.domain.hidden To unsubscribe from this group, send email to lisalist-unsubscribe_at_email.domain.hidden For more options, visit this group at http://groups.google.com/group/lisalist?hl=en -~----------~----~----~----~------~----~------~--~--- Received on 2008-03-21 09:43:26