ELKS tested

[toncho11]

I have tested ELKS 06503d8 (latest) today 15/07/2022 on an Amstrad 1640 using a 360 kb image and it works.

[ghaerr]

Thanks @toncho11, I appreciate your testing.

Remind me, is this Amstrand the machine that has the very early BIOS in it (which initially didn't work on ELKS but was later fixed)?

BTW, we recently renamed the minix full screen editor to edit - give that a try and tell us what you think. It should run lots faster than kilo.

[toncho11]

It is more about checking if all the recent changes did not break something.

[hscharno]

Hi, I have an IBM 5150 it starts with ELKS ..... and then I get a !4 and "press key". After this the PC restarts. How can I add some debug output?

[toncho11]

Hi,

I just tested on my IBM 5160 and this version from 15/07/2022 works OK.

Do you get just dots "." or also "*" stars. This is an indication of read error. Maybe your floppy disk damaged, @ghaerr there should be a wiki page with the errors 1,2,3,4!.

[ghaerr]

I have an IBM 5150 it starts with ELKS ..... and then I get a !4

Error 4 means "Bad system": the format of /linux is incorrect. This could be the case if the /linux file is copied without being the first file on a freshly formatted or mkfs'd disk (i.e. it must be contiguous).

there should be a wiki page with the errors 1,2,3,4!.

Completely agree @toncho11! I have noted it on my TODO list.

[hscharno]

Thanks for your help! I'm using elks 0.6 hd32mbr-fat.img on a scsi2sd "disk". The screenshot shows the current error.

[ghaerr]

I'm using elks 0.6 hd32mbr-fat.img

Oh, I see. ELKS hard disk images have to be built with specific CHS (cylinder, head, sector) settings, and the default is CHS 63,16,63. I'm pretty sure the problem is that this CHS value doesn't match your hard drive. You'll need to make menuconfig and set the values for the hard drive and build your own system, instead of using a pre-built image, unfortunately. The pre-built floppy images should work, however.

[toncho11]

I have made a wiki page on this subject:

https://github.com/jbruchon/elks/wiki/Installing-HD-image-on-physical-media

What @ghaerr suggests is Method 2.

If this does not work, then you can always boot from floppy and use the ELKS "sys" command to transfer ELKS to a HDD. This is the recommended way of installing ELKS.

[hscharno]

Cool thanks, I will try it. Today I used a boot disk and it worked!

[toncho11]

:) Nice!
Check the documentation on the Installation.

[hscharno]

It is working now using Methode 1. Thanks for the help!

[ghaerr]

Hello @toncho11,

I have made a wiki page on this subject

Thank you, nice work!

[toncho11]

Today 11/12/202 I tested ELKS again on my IBM 5160 and it booted OK. I used one of the latest images from the build Actions.

[tt1542]

Hi people,

today I have succesfully tested ELKS 0.6.0 on my Monotech NuXT 2.0 board (V20)!

Booting from a 1.44 MB floppy requires the most recent BIOS update 0.9.9 from Sergey Kiselev, though. Using an older BIOS version will lead to a cryptic kernel error.

[toncho11]

Please state how many physical drives and of which type you have attached:
drive 1 fd0:
drive 2 fd1:

When you say not reported correctly, please state: the type detected by ELKS verse the expected type.
Please post a log if possible.

Thank you!

[tt1542]

@toncho11 , I was referring to the log posted above (yesterday). fd0 is a 1.44M, fd1 is 360K. BIOS is set correctly for both drives. The screenshot shows that ELKS (or the BIOS) gets something wrong in reporting fd0 as 360K erroneously.

[toncho11]

You mean one time fd0 is reported as 360kb by the BIOS and
one time the fd0 is reported as 2880 (ELKS bootable : 80 x 2 x 18) by the ELKS probing mechanism.
Then ELSK finds CHS info that is at the begging of the floppy image and then it proceeds as if the floppy is 1.44 instead of 2880.
So maybe the probing does not work correctly, but only @ghaerr can say if this can be somehow improved.

[ghaerr]

Hello @tt1542,

The BIOS is now correctly set to 1.44M/360K. However, in the ELKS boot log, two 360K drives are being reported. More precisely, the format of fd0 is still not reported correctly.

I have finally figured out the problem, its a bit complicated to explain: very early BIOSes (such as some that @toncho11 has, original pre-AT machines) do not support the BIOS INT 13h AH=8 Get Drive Parameters call. ELKS is currently using the CPU type to determine whether to make this BIOS call. If the CPU is an 8086, the call is not made, and drives are set to 360k. I can see this is the case because the boot log shows "syscaps 0x0". This was thought to be a good workaround, as the BIOS function was only added on PC/AT machines, which had an 80286 CPU. Obviously, that isn't the case with your machine and BIOS.

When initially coded, I had thought there might be a problem calling an unimplemented BIOS function which could cause a crash. However, I am thinking perhaps we can try calling the function regardless of CPU type (PC vs AT, when the BIOS function was added), and use the Carry bit BIOS return value to indicate the function is missing. Thus, for your system, even though its an 8086, it would call the BIOS Get Drive Parameters function to get the drive types.

I will post a an image with a fix for this for you to test. @toncho11 will have to test on one of his early machines to ensure the image still boots. If those both work, then this should be solved.

However, given the situation above, I don't see ELKS itself recognizing, in the lower part of the log, my fd1 drive with 360K. Does ELKS only display the boot drive at this point?

Yes - in the lower part of the log, ELKS does not display an additional drive type unless there is a floppy inserted AND a program accesses that floppy. So this is normal. I don't think we will have an issue on this, but you can go ahead and test.

Thank you!

[ghaerr]

@tt1542 and @toncho11,

Here's both 1440k and 360k FAT images with the above fix for you to test with.
fdtest.zip

Thanks!

[toncho11]

Here is a list of things to be tested:

• test the floppy detection above with the new BIOS call on XT 8088/8086 system with the original IBM BIOS (still any XT test will be useful)
• test NX tetris - the mouse cursor should become invisible if no serial card is detected
• test the fixed TinyIRC on 8088 using an unencrypted IRC server: ./tinyirc Nickname 193.27.78.5 6667 -dumb (should connect you to quakenet)
• test if all recent changes in memory allocation and other small fixes do not crash the basic usage of the system

Voila. Maybe someone can help :)

[toncho11]

The first two are OK.

[ghaerr]

test NX tetris - the mouse cursor should become invisible if no serial card is detected

I've tested this and am pretty sure it works the way requested.

test the fixed TinyIRC on 8088 using an unencrypted IRC server: ./tinyirc Nickname 193.27.78.5 6667 -dumb (should connect you to quakenet)

This doesn't really need testing on real hardware, but instead using QEMU or any system connected to the net. I tried the above and am not able to get a connection to 193.27.78.5. However, that just indicates a network connectivity issue, not the PING/PING fix just implemented. I think my issue is QEMU setup to allow passthrough of the indicated TCP address and port.

test if all recent changes in memory allocation and other small fixes do not crash the basic usage of the system

There are no changes to memory allocation, only a heap fix in tinyirc, so I don't think a full system test is necessary until we're closer to 0.7.0.

test the floppy detection above with the new BIOS call on XT 8088/8086 system with the original IBM BIOS (still any XT test will be useful)

This is really the only test that needs to occur on real hardware. We'll wait and see what @tt1542 has to say, then it would be nice to test on original IBM BIOS machine as indicated.

[toncho11]

So with qemu you can set an ELKS compatible network card from the command line?

[ghaerr]

So with qemu you can set an ELKS compatible network card from the command line?

Yes - that's how I've debugged almost all the kernel networking code, as I don't actually have a working NIC in any of my real hardware test setups. Setting up QEMU is a little tricky, try qemu.sh which is preset to work. The section on host forwarding will need to be updated for the IRC chat client/server, this is what it looks like for telnet, ftp/ftpd and httpd:

# Simultaneous telnet, http and ftp forwarding
FWD="\
hostfwd=tcp:127.0.0.1:8080-10.0.2.15:80,\
hostfwd=tcp:127.0.0.1:2323-10.0.2.15:23,\
hostfwd=tcp::8020-:20,\
hostfwd=tcp::8021-:21,\
hostfwd=tcp::8041-:49821,\
hostfwd=tcp::8042-:49822,\
hostfwd=tcp::8043-:49823,\
hostfwd=tcp::8044-:49824,\
hostfwd=tcp::8045-:49825,\
hostfwd=tcp::8046-:49826,\
hostfwd=tcp::8047-:49827,\
hostfwd=tcp::8048-:49828,\
hostfwd=tcp::8049-:49829"

[tt1542]

Sooo... now for some more hardware testing results! With the version @ghaerr provided, floppy detection works on my NuXT (V20, 1.44M/360K)!

I decided to push ELKS some more, trying to mount a FAT12 360K disk and display a test file I created under DOS. The disk was thoroughly checked before, including bad sectors.

So, mounting the floppy FS succeeded, but displaying the file contents did not work. Seems like the system is treating the text file as special file?...

[toncho11]

Try "edit" to be sure. In general I am able to access my fat partitions from ELKS without problems. But I think it is fat16 and not fat12. There is some detail like this that could be the source of the problem.
I also use "mount -t vfat".

[tt1542]

I tried both your ideas, mounting using the "-t vfat" option (though I didn't use any LFN features) and opening the file with "edit". The result is basically the same, edit claims the file has zero bytes.

[toncho11]

Check again in DOS/Windows if the file is OK.

[tt1542]

It is fine.

[toncho11]

OK. @ghaerr the issue here counts as a potential bug.

[ghaerr]

Hello @tt1542,

With the version @ghaerr provided, floppy detection works on my NuXT (V20, 1.44M/360K)!

Great! That version added back the BIOS call for drive checking even when the CPU is 8086/8088. I will produce a PR for this, which I am pretty sure will work on IBM XT systems with older BIOSes. Should hardware testing on IBM XT show that doesn't work, we will come up with another method if required for this solution.

BTW, this "syscaps" issue using the CPU to determine other system capabilities is also used to determine whether to remap IRQ 2 to IRQ 9, IRQ 8-15 allowed, keyboard, LEDs, and more, as evidenced from the following table. This means that these features will not currently be operational on the NuXT:

#define CAP_PC_AT       (CAP_IRQ8TO15|CAP_IRQ2MAP9)      /* PC/AT capabilities */
#define CAP_DRIVE_PARMS 0x02      /* has INT 13h fn 8 drive parms */
#define CAP_KBD_LEDS    0x04      /* has keyboard LEDs */
#define CAP_HD_IDE      0x08      /* can do hard drive IDE probes */
#define CAP_IRQ8TO15    0x10      /* has IRQ 8 through 15 */
#define CAP_IRQ2MAP9    0x20      /* map IRQ 2 to 9 */

I decided to push ELKS some more, trying to mount a FAT12 360K disk and display a test file I created under DOS.

We need to do some careful testing to eliminate variables before going too deep down a rabbit hole for this. That is, I would first rather test the NuXT system just running on the booted floppy, before mounting another. That means we should first try booting a 360k ELKS image on drive A to see whether the system runs on 360k. Would that be possible?

I would also like you to throughly test the booted system on a 1.44M floppy only to make sure everything seems to work well there before adding another drive. Then we know that ELKS is actually working properly on NuXT with one drive.

I'm not sure whether the 2nd problem you're seeing is a result of your BIOS or ELKS at this point.
As far as the problem itself, look at the screenshot, after mounting and ls -l, it plainly shows that test.txt is a block device:

brw-r--r-- 1 root ... test.txt

So vi thinks its not a regular file, and cat thinks its a block device and returns nothing, which is correct. Thus the problem is that for some reason ELKS is reading the root directory of the floppy image and thinking that the test.txt directory entry is a block device - which shouldn't be possible on ELKS since the device entries are faked. More on that later. Would it be possible for you to upload a copy of that DOS 360k image so I can test on QEMU?

Thank you!

[ghaerr]

We need an image from the real floppy drive, right? This dskimage is supposed to read byte per byte the floppy and make a file from it.

We can either use the image that was used to copy to the floppy, or a copy from the floppy. It doesn't matter that it comes from the floppy, the issue is the FAT format used to create the floppy. That FAT format is not the same as other FAT formats we have seen created by mformat and could be the issue here.

[tt1542]

I found the good ol' DOS raread program, we used them to make disk images ages ago. @ghaerr , would you check if you can use this?

360KB.zip

[tt1542]

And, as @ghaerr suggested, I tried to mount the floppy disk as fat explicitly. Unfortunately, the result remains the same.

[ghaerr]

I tried to mount the floppy disk as fat explicitly. Unfortunately, the result remains the same.
I found the good ol' DOS raread program, we used them to make disk images ages ago. @ghaerr , would you check if you can use this?

Got it, and guess what? I get the same buggy results on QEMU over here. Congratulations, you've just identified a new FAT filesystem bug in ELKS :) I'll look into it and figure out what's wrong. Thank you!

[tt1542]

That is ... wonderful? ;-) Thank you for looking into this!

[ghaerr]

Hello @tt1542,

I've fixed both the above problems in #1572. Here's two boot images you can test with:
fdtest2.zip

The problem with the FAT mount is a bit complicated, but has to do with the fact that ELKS emulates the /dev directory on FAT volumes, ONLY if /dev exists - which it won't on any DOS disk created in the wild. This fixes that. There remain some issues with emulating /dev properly on FAT volumes created with only 2 sectors allocated to the FAT table, which is the way your 360k floppy happens to be formatted. In ELKS, the mformat command forces 3 sectors to be allocated on 360k disks. But none of that should pose a problem for you, as long as a /dev entry is not present on your DOS floppy. That said, you'll need to use an ELKS-formatted FAT floppy in order to boot from.

Thank you!

[tyama501]

Hello @ghaerr ,

Is this affect to my system too?
I thought I have been mount and writing/reading dos disk without dev before, but they may not be done correctly?

[tt1542]

Looks fine to me! :-)

[ghaerr]

Hello @tt1542,

Super! Thank you for your reports and testing. It looks like we've got ELKS running well on NuXT machines now :) If other problems arise, go ahead and open separate issues for them.

[ghaerr]

Hello @tyama501,

Is this affect to my system too?
I thought I have been mount and writing/reading dos disk without dev before, but they may not be done correctly?

Yes, this issue was likely present on PC-98 too, but only when FAT disks without a /DEV entry were used. The directory entries would show correctly, but the file attributes could be incorrect depending on their location in the root directory, which may not have been noticed unless a long directory listing were shown.

[tt1542]

Hello ELKS people,

quite recently, I got my hands on a Book 8088, one of those crazy new-old chinese retro laptop builds from Aliexpress. Obviously enough, I tried to boot ELKS 0.6.0 on the machine (most recent build, #2595).

The amount of boot options available is rather limited for the device. While it should be possible to use the external ISA adapter board for an 8 bit FDC and then connecting a FDD to it, this seemed a rather lengthy way for me and I did not try that. The only other way for booting the laptop is pulling out the CF card and writing one of the ELKS images to it.

I did not succeed using the current 32 M FAT MBR image. This gave me a 4! boot error. I succeeded in writing the new 64 M minix image to disk and booting from it, however.

Here is a screenshot, sorry for the bad image quality (display gives a lot of reflections and is rather dark). Maybe this could become another supported device for 0.7.0?

Edit, hardware specs: There's a V20 inside (I exchanged the original one for a V20HL low energy cpu), a CGA card and 640k of RAM. That's about it.

Edit 2: I completely missed the posts regarding the Book 8088 within this issue. Please ignore this post if you feel it is no longer relevant.

[tt1542]

No, I did not change anything. I used Rufus 4.2 to write the fresh 64M image directly to a 2G CF disk.

[toncho11]

I see. For example: hd64-minix.img

[tt1542]

Yes, that's the image.

[ghaerr]

Nice @tt1542, good to know the Book 8088 can boot ELKS with at least one image! :)

Are you using an updated version of Sergey's (stolen) BIOS for that, or the stock version that came with it? What version are you running, I'll indicate it in the soon-to-be-released v0.7.0 release notes.

[tt1542]

@ghaerr , I am still using the "stock" BIOS. There seem to be two different versions, the first one with the bogus copyright notices and the second one without these, mine being the later one. I plan to switch to Sergeys version, though.

[toncho11]

Awesome! You can make a PR request to add your screenshot to the Screenshot folder in this GIT repository.
@ghaerr can add your success to the 0.7 release notes.

[ghaerr]

I'll add the above screenshot, no need for a PR. I'll update the 0.7 release notes once I know what version BIOS is required.