panic: No init or sh found (again)

[Vutshi]

Description Hi, I've tried ELKS 0.5 and 0.6 on my 8088 with 256KB of RAM. It is a Soviet clone of the actual 8088 CPU named К1810ВМ88. I observed a problem similar to the one mentioned in https://github.com/jbruchon/elks/issues/288.

Computer description

• The computer is called МК-88.01 where .01 denotes a variant with 256K RAM and FDD
• CPU: КР1810ВМ88 is a clone of Intel 8088 at frequency 4.77MHz
• Video RAM 128K
• Programmable interval timer: КР580ВИ53 equivalent to Intel 8253. Max frequency 2MHz
• Programmable interrupt controller: КР1810ВН59А equivalent to Intel 8259
• Keyboard controller: КР580ВВ55 analog of Intel 8255
• Floppy disk controller: UMC UM8272A analog of Intel 8272
• Controller for cassette recorder: КР580ВВ55А analog of Intel 8255
• There is one floppy drive installed (720K) which is used as 360K There is LPT and Joystick.
• No HDD, no COM port, no Soundcard.

Configuration

• I tried precompiled ELKS 0.5 with xms fix
• Also I compiled the latest master version (75a7cb7) myself (precompiled 0.6 didn't even start booting)

Raw data In both cases I get the same result shown in screenshots:

• 0.6 master:
• 0.5 with xms fix

P.S. 0.6 master boots nicely in qemu. Best

[Vutshi]

Here is what the screen should look like. Make sure you "make clean; make". Attached is also the config file I'm using.

Yes. This is how it looks like for me as well. The screen shot with "kbd poll got 2267" was done on Intel with the first version of the test. I included it just because of the bioshd(0) messages. Sorry, if I cause a confusion.

[ghaerr]

It seems we're getting multiple issues mixed up here. I suggest testing first on your desktop, and seeing if ELKS runs well or not. We know ELKS works well, so lets see whether your compilation of it works on your desktop (remove printk's discussed above). Your desktop has some sector retry issues with ELKS our the floppy you're using.

Then, you can add back in the printk's, and see what proper desktop looks like. As I mentioned, it is proper to display the hex values I described, depending on what you're typing.

Once both the above work, we can get back to debugging other system.

[Vutshi]

It seems we're getting multiple issues mixed up here. I suggest testing first on your desktop, and seeing if ELKS runs well or not. We know ELKS works well, so lets see whether your compilation of it works on your desktop (remove printk's discussed above). Your desktop has some sector retry issues with ELKS our the floppy you're using.

This one I checked already. Without printk on keyboard polling desktop works well with this configuration of ELKS. It is just as good as qemu.

Tomorrow I check that it returns correct hex values.

[Vutshi]

You're probably not holding your finger on the drive hard enough ;)

Btw, I have got now a new floppy drive. No more fingers required to boot ELKS or DOS :)

[Vutshi]

ASM source code.

Nope. No ASM source code for МК-88 BIOS

[Vutshi]

Then, you can add back in the printk's, and see what proper desktop looks like. As I mentioned, it is proper to display the hex values I described, depending on what you're typing.

Here is the Intel desktop reference reaction on typing "qwerty" with my test build of ELKS:

which is identical to the result in qemu:

[Vutshi]

I wonder why the size of printk message (printk("."); vs printk("kbd poll\n");) affects the booting behaviour on my 8088 computer. Is there overfilling of some buffer?

[Vutshi]

Can you tell us more about your system? What is the programmable interrupt controller (PIC)? Is it an 8259? Are there other devices attached to it?

Yes, it is an analog of 8259. There are not so many devices in the computer. LPT and Joystick come to mind, no HDD, no COM port, no nothing. I have updated the opening post with all information about the computer I have collected so far.

EDIT: One peculiar thing is that my МК-88 has a controller for cassette recorder which makes it different from IBM PC XT. There was one in IBM PCjr. "BIOS interrupt call 15[h] routines were documented in the technical reference manual that would turn the cassette motor on and off, and read or write data."

[Vutshi]

Hi @ghaerr and everyone,

I was poking around with some more low-level tests and found one strange thing about my computer. In particular, after seeing random behaviour of ELKS with additional printk() messages we decided to try printing various messages from a test program loaded from the boot sector thus bypassing any OS.

It appears that the computer (BIOS?) doesn't like characters \r \n. I can print them only ~20 times and then computer freezes seemingly when it has to scroll the screen. Without the 'bad' characters printing goes on forever. I found a potentially similar bug described in IBM PC BIOS versions from 1981. Btw, as I mentioned above, MS-DOS doesn't care about this \r \n problem and works alright.

I did the following change to elks/blob/master/elks/kernel/printk.c#L62-L69

void kputchar(int ch)
{
  if (ch == '\r' || ch == '\n')
    return;
  if (kputc)
    (*kputc)(dev_console, ch);
  else early_putchar(ch);
}

It seems like removal of the \r \n characters help to restore the stability of ELKS booting. Now it works well, types dots like a champ until it needs to scroll... and it still refuses to read keyboard :)

https://user-images.githubusercontent.com/4971779/176764671-f2964776-a606-40b8-a9d6-cac9c720a59a.mp4

I noticed also that my computer can tolerate the unlucky characters \r \n while working in a graphical regime. Is there a way to boot ELKS in such a regime?

[ghaerr]

Hello @Vutshi,

It appears then we have two big problems we need to work around for your system - the first is that the PC nearly crashes or becomes unresponsive when having to scroll, and secondly, the ongoing keyboard read problem.

For the first problem, it seems your BIOS has a buggy scroll routine? The ELKS boot block and early kernel setup use the INT 10h AH=0Eh to write to the console. In addition, the BIOS console uses this interrupt for console output.

You will probably have to rewrite this routine to do console output directly yourself (this is the same method that @tyama501 uses for PC-98). This means switching back to using the Direct Console (not BIOS console) for the time being, which will remain problematic because it uses a different method for keyboard I/O. Then, a rewritten console output routine would allow you to bypass using the buggy BIOS routine.

By switching back to Direct Console (CONFIG_CONSOLE_DIRECT=y), this problem may go away. Otherwise, it is possible to rewrite the console output routine and still use the BIOS console, as it may be more suited for fixing the keyboard, when we finally figure that out.

I would advise looking at the PC-98 ASM code for the rewritten console output routine in elks/arch/i86/drivers/char/conio-pc98-asm.S. It is a little complicated explaining exactly how we might get all this working, so I'll defer on that explanation until seeing which way you'd like to go.

This problem did not exist using Direct Console, correct?

Btw, as I mentioned above, MS-DOS doesn't care about this \r \n problem and works alright.

This is likely because MSDOS doesn't use the INT 10h function to display output. ELKS Direct Console doesn't either.

Thank you!

[toncho11]

Hi @Vutshi ,

Did you manage to run ELKS on MK-88? I am interested in these Eastern block PCs. Maybe I will buy MK-88 one day, but it is good to know its compatibility first.

[Vutshi]

Hi @Vutshi ,

Did you manage to run ELKS on MK-88? I am interested in these Eastern block PCs. Maybe I will buy MK-88 one day, but it is good to know its compatibility first.

Hi @toncho11. Not yet, I have postponed this project. We were busy with fixing some hardware problems and now slowly expanding the RAM. I will come back to this ELKS issue later. Regarding compatibility I can say that if you stay within realms of MS-DOS the compatibility is excellent. At least I haven't found any problems so far.

[ActionRetro]

Hi there,

Wanted to drop in my details, because it seems I have the same problem on a Packard Bell VX588 AT clone. I can boot 0.5.0 just fine, but 0.6.0 fails:

[toncho11]

It can be:

• the 360kb image of ELKS was not written correctly (bad sectors, etc)
• you are using ELKS with XMS enabled
• you need at least 512KB of memory for a normal boot (how much memory do you have?)

You can also try the latest ELKS build instead of 0.6.

[ActionRetro]

Thanks @toncho11

I'm using the 720 Minix image from the 0.6.0 releases. I've tried it written to a CF Card in XT IDE, disk image on floppy drive emulator, and real disk. 0.5.0 works on all three methods.

I have 640K RAM.

I'm not sure about XMS, is that within the Elks image?

[toncho11]

The ELKS v0.5.0 boot images were incorrectly configured to assume a machine with XMS capabilities, and when they're missing, the images fail to boot, but then you are having a problem with 0.6, not 0.5.

So this is 8088 with 640 kb memory.

Try the latest image: https://github.com/jbruchon/elks/actions/runs/3004384610 (scroll down to see all .img files and the one for 720 kb).

[toncho11]

What happens sometimes is a misconfigured image where a linux command is missing from /bin and this prevents it from boot.

[ActionRetro]

Hi @toncho11, thanks - I tried that image, and got a similar result:

[toncho11]

Can you try a 360kb image on the same computer?

If you want to try a 1.44 kb image on 8088 I recommend this controller: https://www.ebay.fr/itm/283729440716

[ATroubleshooter]

Hi @toncho11, thanks - I tried that image, and got a similar result:

Hello.

How come, that it reports 8 sectors per track floppy drive? What an image it's gonna be then - 640k? (fd0: 80 tracks 2 heads 8 sectors) I guess, the error is probably here.

Edit: despite that earlier it reports "/dev/fd0: 40 cylinders, 2 heads, 9 sectors".

[ActionRetro]

Tried it with 360 image, and got similar result:

[toncho11]

Interesting. I have a 360kb 8088 computer and the last time I tested it was OK.

So ELKS 0.5 works, but not 0.6 - neither with 720 kb or 360 kb image. It is true that first the FD0 seems to have been detected correctly and until then the kernel has booted correctly. Then it changes to 8 sectors and then it starts with errors. Why is it floppy probing again? Maybe we just need to disable this second check which uses a different method for probing and thus it always fails on your computer in version 0.6.

Now we need to call an expert who knows what changed recently. @ghaerr would you please have a look at this issue or @Mellvik ?

[Mellvik]

It has already been pointed out that the # of sectors per track seems to be wrong, should be 9. This most likely explains the problem.

Please check that the hardware/BIOS/CMOS configuration corresponds to the physical drive and the image. IIRC this is an area that was updated between 0.5 and 0.6.

If this doesn't help, try setting the correct CHS values for the floppy drive in the kernel configuration and recompile. That will help narrow down the possible sources of errors.

-M

4. okt. 2022 kl. 09:24 skrev toncho11 @.***>:

Interesting. I have a 360kb 8088 computer and the last time I tested it was OK.

So ELKS 0.5 works, but not 0.6 - neither with 720 kb or 360 kb image. It is true that first the FD0 seems to have been detected correctly and until then the kernel has booted correctly. Then it changes to 8 sectors and then it starts with errors. Why is it floppy probing again? Maybe we just need to disable this second check again which uses a different method and thus it always fails on your computer in version 0.6.

Now we need to call an expert who knows what changed recently. @ghaerr https://github.com/ghaerr would please have a look at this issue or @Mellvik https://github.com/Mellvik ?

— Reply to this email directly, view it on GitHub https://github.com/jbruchon/elks/issues/1327#issuecomment-1266517940, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3WGOHDYINYREH45HOXNBTWBPLTRANCNFSM5ZBYI6BA. You are receiving this because you were mentioned.

[toncho11]

So the code from 0.5 to 0.6 has been changed here: #1184 It says performance optimizations of the probing.

[Mellvik]

@ActionRetro - can you post a picture of 0.5.0 booting on the same machine?

-M

[ghaerr]

Hi @toncho11, I will look into this but am on vacation until Monday.

Thank you!

Sent from my iPhone

On Oct 4, 2022, at 9:24 AM, toncho11 @.***> wrote:



Interesting. I have a 360kb 8088 computer and the last time I tested it was OK.

So ELKS 0.5 works, but not 0.6 - neither with 720 kb or 360 kb image. It is true that first the FD0 seems to have been detected correctly and until then the kernel has booted correctly. Then it changes to 8 sectors and then it starts with errors. Why is it floppy probing again? Maybe we just need to disable this second check again which uses a different method and thus it always fails on your computer in version 0.6.

Now we need to call an expert who knows what changed recently. @ghaerrhttps://github.com/ghaerr would please have a look at this issue or @Mellvikhttps://github.com/Mellvik ?

— Reply to this email directly, view it on GitHubhttps://github.com/jbruchon/elks/issues/1327#issuecomment-1266517940, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AC3OFZLS7BVJZIMU23QNDQLWBPLTRANCNFSM5ZBYI6BA. You are receiving this because you were mentioned.Message ID: @.***>

[toncho11]

@ATroubleshooter what is your BIOS on your Packard Bell VX588 AT? Is it Phoenix 2.52?

[ATroubleshooter]

@ATroubleshooter what is your BIOS on your Packard Bell VX588 AT? Is it Phoenix 2.52?

it's not mine, indeed, it's his @ActionRetro

🙂

Thank you

[toncho11]

Ah. Yes. @ATroubleshooter thank you for identifying that there was a problem with the floppy probing.

@ActionRetro what is your BIOS on your Packard Bell VX588 AT? Is it Phoenix 2.52?

[ghaerr]

Hello @ActionRetro, @ATroubleshooter, @toncho11, @Mellvik,

If I'm following this conversation correctly, it is being reported that the ELKS v0.5.0 image(s) work fine, whilst v0.6.0 do not, using three different floppy emulation or hardware devices. The disk format and ELKS image that is being used is 720k, is that correct?

If so, the correct CHS for 720k is 80 cylinders, 2 heads and 9 sectors. From @ActionRetro's first boot image above, ELKS is reporting 8 sectors, which is incorrect.

Separately, in the next image, @ActionRetro reports that a disk failed, where the probe reported CHS 40/2/9. In this case, the cylinders is 40 instead of 80 which is incorrect, but the sectors is 9 which is correct. Was the disk image changed here? I am trying to understand whether this is an ELKS probing issue, and need to know exactly the disk format being tried and the probe result.

As @toncho11 posted, yes, in v0.6.0 the ELKS probe routine was "enhanced" in #1184, attempting to probe a bit faster. This could be the culprit, but I am not sure yet. I am not sure it matters what the BIOS is, if v0.5 works and v0.6 doesn't, using the same images. In general, ELKS doesn't use the BIOS configuration, but probes the floppy. However, the floppy is NOT probed when using an ELKS-generated MINIX filesystem floppy image, since the ELKS build process writes the CHS values in the EPB (ELKS parameter block) of the boot sector.

I suppose, if the 360k floppy is failing boot on v0.6.0, we should compare the boot screens using only 360k floppy, trying v0.5 and v0.6 version of the same format MINIX image, and see whether the probe shows the same results. Although the stock v0.5.0 ELKS images were incorrectly generated with XMS configured, it doesn't seem that XMS is the problem here.

Thank you!

[ActionRetro]

Hi there, sorry for the delay! Here are some screenshots showing 0.5.0 booting from the Minix fd720 image.

[ghaerr]

Here are some screenshots showing 0.5.0 booting from the Minix fd720 image.

The screen shows /dev/fd0 as CHS 40,2,9 which is 360k. Are you booting from a 360k floppy? If so, you should be using the ELKS 360k fd360 floppy image, not the fd720 image. That is, even if the 360k floppy is booting a 720k image, there will be files in inaccessible locations (i.e. all tracks > 40) and would run into errors, it seems to me.

[ActionRetro]

For version 0.6.0, I tried both the 360 and 720 images with the same result.

[ghaerr]

If so, you should be using the ELKS 360k fd360 floppy image, not the fd720 image.

Oops... I was getting confused by the boot screen. What is happening is the BIOS is thinking the drive is 360k, but then ELKS is reading the MINIX image with the EPB and correctly identifying it as a 720k drive (CHS 80,2,9). So ELKS DOES think the drive is 720k, and my last statement above would not be a problem.

For version 0.6.0, I tried both the 360 and 720 images with the same result.

Can you post the boot screen using the same floppy and 720k image, for 0.6.0?

[ActionRetro]

Sure thing! Here's 0.6.0 with Minix fd720 image:

[ghaerr]

Sure thing! Here's 0.6.0 with Minix fd720 image:

Thanks - it seems the 0.6.0 boot is NOT finding the ELKS EPB signature and thus is using a regular probe. (Note in the second-to-last picture for 0.5.0, it says "/dev/fd0: found ELKS parm block CHS 80,2,9). For 0.6.0 in the last screenshot, it says "/dev/fd0 probed, probably has 80,2,8). The probe is returning the wrong number of sectors - 8 instead of 9, which is definitely causing the boot failure.

So we have two issues here: first, why the ELKS parm block isn't being found on the v0.6.0 floppy, and 2nd, that the probe is failing. Can you post the 720k 0.6.0 image in .zip format here so I can look at it?

[ActionRetro]

Sure! Here it is - it's the same one from the releases page. fd720-minix.img.zip

[ghaerr]

That image boots properly on QEMU, and produces the following screen:

Note it says "/dev/fd0: ELKS bootable... (CHS 80,2,9)". This is because the first sector read on track 0 sector 1 found the ELKS parm block, and no further probe needed.

Looking at the source for the BIOSHD driver in elks/arch/i86/drivers/block/bioshd.c::probe_floppy(), it appears that the only way we do the full probe is if the first sector read is failing:

        /* Try to look for an ELKS or DOS parameter block in the first sector.
         * If it exists, we can obtain the disk geometry from it.
         */
        if (!read_sector(target, 0, 1)) {
            struct elks_disk_parms __far *parms = _MK_FP(DMASEG, drivep->sector_size -
                2 - sizeof(struct elks_disk_parms));

            /* first check for ELKS parm block */
            if (parms->marker[0] == 'e' && parms->marker[1] == 'L'
                && parms->size >= offsetof(struct elks_disk_parms, size)) {
                drivep->cylinders = parms->track_max;
                drivep->sectors = parms->sect_max;
                drivep->heads = parms->head_max;

                if (drivep->cylinders != 0 && drivep->sectors != 0
                    && drivep->heads != 0) {
                    found_PB = 1;
                    /*printk("fd: found valid ELKS disk parameters on /dev/fd%d "
                           "boot sector\n", target);*/
                    goto got_geom;
                }
            }

I am pretty sure read_sector(target, 0, 1) is failing. This could very well be because of what @toncho11 is talking about, where for some reason the BIOS isn't working with our ELKS disk driver for some reason (since the BIOS thinks the drive is 360k from the screenshot).

It is possible that the subsequent ELKS probe is not allowing the read on sector 9, which causes ELKS to think the disk has 8 sectors and is thus not 720k-compatible. I don't yet know why ELKS v0.6.0 isn't working when v0.5.0 is, there have been other changes made to the bioshd.c driver, which we may have to revert. Can you build the ELKS kernel and images in order to test that?

Does anyone have further thoughts on this?

[toncho11]

Hi,

@ActionRetro how do you write the images to floppy disks? What programs do you use? You do that under DOS?

[ActionRetro]

@toncho11 I'm using a Gotek floppy emulator

[toncho11]

In the best case scenario @ghaerr you will need a Gotek drive to test.

I think we have identified the issue "ELKS 0.6 (and latest) does not recognize correctly floppy drives emulated with Gotek".

[tyama501]

FlashFloppy GOTEK or just original GOTEK?

At least GOTEK with the FlashFloppy firmware and PC-98 works well.

[ghaerr]

In the best case scenario @ghaerr you will need a Gotek drive to test.

I have a GoTek for testing, but since v0.6.0 works on everyone's except @ActionRetro's PC, and v0.5 works on that PC, it seems the problem isn't in the GoTek, but in some code difference between v0.5 and v0.6. We may need to produce a set of versions backing out various changes to the BIOS disk driver, or at least some debug versions, in order to get more information.

@ActionRetro, can you build ELKS from the repo?

[Mellvik]

FWIW - GOTEK and 720k is known to be a difficult combination, but I agree with @ghaerr. We need to find the change between 0.5.0 and 0.6.0 that triggers the problem. If it turns out to be useful, I can install the GOTEK in a machine for testing.

Slightly+++ off topic - I pulled out my GOTEK which hasn't been used for years and took look at the flash drive. The first image is a MSDOS 5 boot floppy and - @ghaerr & @tkchia - it has the 'I am Li' virus!! So apparently the virus has been lurking around on my systems for quite some time … One of the images is a ELKS 0.2.0 boot image - a reliable of not very accurate age indicator.

—M

12. okt. 2022 kl. 21:00 skrev Action Retro @.***>:

@toncho11 https://github.com/toncho11 I'm using a Gotek floppy emulator

— Reply to this email directly, view it on GitHub https://github.com/jbruchon/elks/issues/1327#issuecomment-1276607161, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA3WGODEKIAUDWRLWVUATJ3WC4DERANCNFSM5ZBYI6BA. You are receiving this because you were mentioned.

[ghaerr]

Hello @Mellvik,

GOTEK and 720k is known to be a difficult combination

Can you expand on that? I'm trying to figure out whether this is an ELKS problem, or GoTek floppy emulator issue. I'm looking at #1184, which changed the floppy probe algorithm between v0.5 and v0.6, but as pointed out above, it seems from the screenshot provided that sector 9 isn't being read, and ELKS thinks the floppy is CHS 80,2,8 (=655k??).

I could provide a special build with CONFIG_TRACK_CACHE turned off, but think perhaps a better approach, providing @ActionRetro is interested, is leaving 720k alone and just testing and debugging only on 360k floppy images on GoTek, to eliminate that variable. I don't have the full boot screen on the last test, but ELKS should not be performing a probe in the first place with an ELKS floppy, since the EPB contains the CHS. So something is off.

Thank you!

[ghaerr]

Hello @ActionRetro,

Since v0.5.0 works, I've created a v0.6.0 ELKS image whose probe routine forces 9 sectors regardless. Please try this to see if it boots (in either 360k or 720k image). This should eliminate whether the problem is the probe routine or something else.

fd720-minix.img.zip

Thank you!

[Mellvik]

18. okt. 2022 kl. 18:41 skrev Gregory Haerr @.***>:

Hello @Mellvik https://github.com/Mellvik,

GOTEK and 720k is known to be a difficult combination

Can you expand on that? I'm trying to figure out whether this is an ELKS problem, or GoTek floppy emulator issue. I'm looking at #1184 https://github.com/jbruchon/elks/pull/1184, which changed the floppy probe algorithm between v0.5 and v0.6, but as pointed out above, it seems from the screenshot provided that sector 9 isn't being read, and ELKS thinks the floppy is CHS 80,2,8 (=655k??).

Hi @ghaerr, I actually planned to come back with some hard facts on this but ran into some hardware issues preventing that (or postponing it at least).

The thing with the GOTEK is that the model # says which size it supports (and will appear to the host as). 144, 720, etc. It seems that if you have a 144 model you may be lucky and have it serve 1.2M 5.25 images correctly, but not other sizes. I had some success with this a few years back. Some posts on the net claim that the GOTEK looks at the size of the image on the flash drive and adjust itself accordingly. It does not. The flash drive has no structure whatsoever, just a fixed size 'block' per image (3072 blocks in my case, I have the 144 model) regardless of how much data is in each block. The tools delivered with the product are Windows only, so I've been using dd to populate the flash drive - no problem.

Then the good news as @tyama501 mentioned: FlashFloppy (on github) makes the GOTEK a whole lot more flexible. I haven't tried it (but intend to). Apparently it will make emulation 'true' for all kind of formats. Actually a great testing tool.

As to the problem at hand, it may well be a hardware or BIOS issue (or a combination). I got something similar when booting 0.5.0 off of a 1.2M image this morning (tracks were off, not sectors) and I suspect there is an issue with either the drive or the medium. I'll be back with details once I figure it out. (yes, the problem was with 0.5.0, I didn't have a 0.6.0 1.2M floppy at hand (yet).

—M edit: fix typos

[Vutshi]

Hi @ghaerr and @toncho11,

I have discovered a possibly important difference between my MK-88 and PC XT/AT. My computer uses an analog of Intel 8255 as a keyboard controller. If I understand correctly ELKS assumes keyboard controller Intel 8042 in direct console.

I don't know how big of a difference this makes. Google doesn't really help me here.

[ghaerr]

Hello @Vutshi,

My computer uses an analog of Intel 8255 as a keyboard controller. If I understand correctly ELKS assumes keyboard controller Intel 8042 in direct console.

Good news, that is definitely a problem: ELKS directly accesses the 8042 device using IN/OUT instructions at startup if XMS is enabled, which could cause problems. On the IBM PC, the 8042 is also wired up to enable/disable the A20 address line, which is used when extended memory is enabled.

I suggest building ELKS using BIOS Console (not Direct Console), which uses BIOS INT 16h to poll the keyboard and return a keypress if present. You'll want to check that your PC implements INT 16h for that function. See elks/arch/i86/drivers/char/conio-bios.S for more details.

There may be other sections in ELKS that assume an 8042 keyboard controller, if you are interested in moving forward on this, let me know and I'll look into this further.

Thank you!

[Vutshi]

Dear @ghaerr,

At last I have more time for the computer archeology. Several things have happened.

First, I learned how to disassemble BIOS and found out that it is basically IBM PC XT BIOS from 1981. This explains the scrolling bug caused by INT 10h which destroys BP register. The bug was fixed by IBM in later BIOS versions (e.g. it is absent in 1986) by it was carefully preserved in MK-88 build in 1991. I have fixed it in my BIOS which is nice but still didn't help ELKS to work properly.

By the way, I noticed that the infamous BP bug is taken into account in conio-bios.S, but not in console-bios-asm.S.

Second, it appears that my computer not only uses Intel 8255 as a keyboard controller instead of 8042 but it also does it in a different way. In particular, it doesn't like to talk to its keyboard as much as XT/AT does. Here is INT 9h in MK-88 versus XT BIOS. We tried to change direct console in a similar way, it didn't help. I observe that initialisation BIOS routines are also different form XT in similar way as they do not control keyboard or whatever via 61h.

I suggest building ELKS using BIOS Console (not Direct Console), which uses BIOS INT 16h to poll the keyboard and return a keypress if present. You'll want to check that your PC implements INT 16h for that function. See elks/arch/i86/drivers/char/conio-bios.S for more details.

INT 16h was tested some time ago and it works well in my computer. Although something prevents it from doing the same under ELKS.

There may be other sections in ELKS that assume an 8042 keyboard controller, if you are interested in moving forward on this, let me know and I'll look into this further.

This might be the source of the problem so I would like learn more about 8042 in ELKS.

Finally, there is a bug in determining 9 sectors in my FDD. I had an impression that ELKS looks into INT 1Eh to find number of sectors and my BIOS looks exactly like the XT one in this respect. So I changed 8 to 9 there and nothing happened :). So I am curious which part of the BIOS should I change to make it ELKS compatible.

I don't yet have full BIOS disassembly but I can do it for a piece which might be interesting from ELKS perspective, so just let me know where to dig.

Thank you.