gilles wrote:
> Many unix servers do not need a console. For example AIX servers can
> start with
> or without serial console attached (true for older ones, newer
> generally have a
> GFX card). To activate serial console(s) lines are included in /etc/
> inittab
> (maybe stty, can't remember...).
> maybe such process exists for uniplus and is simply missing,
> corrupted, or not
> called in the disk B. Remember that on photos, this disk B was
> labelled C and
> handwritten modified... so maybe is it simply not the correct disk...
> This may explain that both real and emulator acts the same...
>
I think we're all just making random guesses here without knowing what's going on. I think the best approach is to do a trace of the execution of the kernel during and after load to see what it is actually doing.
Yes, there are plenty of Unixen out there that don't initialize serial ports when they start up. I'm using one of those right now. It's called OS X. :-)
From the docs that I've read, the installation first takes the serialization diskette and converts it into the first boot disk. We don't have the virgin serialization diskette, we have a serialized one, whose serial number check I BRAnched out of.
There's a second one, also called the root disk that must be copied to the hard drive after the installer disk copies the boot code to the profile. But we don't know exactly what's supposed to happen with that disk or after that. We do know the disks after the first two are all in tar format, so if there's some missing file, copying those files will probably help. But that's all we know so far.
The fact that this doesn't install on a real Lisa is a problem, as it means there's some corruption or damage on the file system level that needs to be found and fixed -- unless of course there are further serial number checks, or some sort of checksum test that fails against the piece of code I've modified.
I'm a bit stuck in LisaEm 1.3.0 with a new CPU issue that I've caused and haven't been able to resolve for the last couple of weeks.
1.2.6 doesn't run UniPlus's installer too well, but the various backups I have of older 1.3.0's without this bug, are able boot the installer disk just fine but fail to install the profile. I do have delays in the profile code, so I don't think it's failing because it's too fast. I think that the order of certain events is slightly off enough to cause it to fail in UniPlus - either that or there's a problem with the VIA code... But first things first...
The 1.3.0 version I'm trying to debug gets stuck with booting LOS - it goes into the Environments window and stays there despite any attempts to tell it to start LOS. So fixing this is my current priority. Fixing this will leave me with the next task of getting the Profile code to work with UniPlus. After that, I can see exactly what's going on in the kernel/boot since 1.3.0 has some more advanced debugging features.
It doesn't seem to be a stuck key or anything like that forcing the entry into Environments, but a bug I introduced into the CPU code when I tried to optimize it a bit overzelously... Swapping code from the 1.3.0's where this bug doesn't exist with the later versions where it does doesn't seem to help - at least so far I haven't found the right combination of swaps to isolate that code.
Yes, yes, I know, early optimization is the root of all evil. :-)
--~--~---------~--~----~------------~-------~--~----~ 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 06:43:52
This archive was generated by hypermail 2.4.0 : 2020-01-13 12:15:21 EST