• Please review our updated Terms and Rules here

PDOS/386 using CHS

kerravon said:
I don't want any instruction to include "go to your local landfill and hope", followed by "and watch out for the exploding capacitors - ha ha!".
Click to expand...

I’ll admit to having enough problems trying to make sense of this response that it’s probably in the best interests of my sanity to just smile and nod while backing slowly away from this thread, but… gotta say, if you’ve under the impression that a used Compaq Deskpro that might possibly have a bad capacitor in it somewhere is more likely to burn down your house than one of those Hand386’s, well… all I gotta say is maybe you should Google “Lithium battery fire” with the facts that the Hand386 is A: completely made out of plastic and B: completely unapproved by *any* government approved safety organization in mind.
 
Eudimorphodon said:
I’ll admit to having enough problems trying to make sense of this response that it’s probably in the best interests of my sanity to just smile and nod while backing slowly away from this thread, but… gotta say, if you’ve under the impression that a used Compaq Deskpro that might possibly have a bad capacitor in it somewhere is more likely to burn down your house than one of those Hand386’s, well… all I gotta say is maybe you should Google “Lithium battery fire” with the facts that the Hand386 is A: completely made out of plastic and B: completely unapproved by *any* government approved safety organization in mind.
Click to expand...

To me this is a different issue. If the manufacturer isn't following safety standards (or they don't exist), then I want to be able to complain to the company and/or the government (and potentially sanction - or better, invade - them if they're doing something wrong).

With landfill there is no-one nominally responsible.

The first thing to do is get a name. Of someone who has more than one available. Sometimes vendors offer me a discount or specially source something, but I generally say no - I want to buy something on the free market with nothing behind the scenes so that it is reproducible as a strategy. Just hop on to Lazada (Philippines) and click it "just like I did".

It's the same deal with this "free" software. I don't consider it to be sustainable. I want to see commercial software. The "free" software is distorting the market (same as foreign food aid), and I want to replace the "free but copyrighted" software with public domain software to lower the costs to commercial operations, with no strings attached. That's what I have been doing for more than 30 years.

I do make exceptions and I would indeed buy a Compaq from landfill if there was no commercial alternative. But that's of limited interest. I'm interested in what I can get commercially. That's why I bought ArcaOS recently too. As a commercially-supported vehicle for running Win32 executables. I bought the commercial license too, even though I don't have a company. The license agreement was pretty amazing - they retain the right to kick down my door to see what I'm up to, and I'm supposed to be keeping adequate records, whatever that is supposed to mean.

Take a lot of this with a grain of salt - I only have a vague idea of what I am trying to achieve, and it is unlikely the target is even fixed (e.g. recently I was interested in the 8080, but now I may be switching to pure x64 because we now have a public domain C compiler that is good enough as far as I can tell (unlike 32-bit)).

But maybe tomorrow I will be asking which country has the best landfill as I want to move there as an illegal immigrant.
 
I read your site but can't determine if PDOS is multi-tasking or not? Can it address more RAM directly in a sort of "flat mode" when running on 386?
 
MrImprovement said:
I read your site but can't determine if PDOS is multi-tasking or not? Can it address more RAM directly in a sort of "flat mode" when running on 386?
Click to expand...

No, it isn't multi-tasking. Well - not officially/supported, anyway. Someone else added that and then disappeared and it took me a lot of effort to mask out the code so that I could actually debug unrelated problems. Theoretically you can just rebuild it with the appropriate defines (ie drop NOVM, and undefine NOHARD) and it may work - but you would need to write a program that uses the MSDOS 4.0 multitasking capability function - there is no visible user interface that I know of. I'm not familiar with MSDOS 4.0 either.

And yes, PDOS/386 can address the full 4 GiB or whatever RAM your system makes available (it will query the BIOS to find out).

BTW - I ordered a 386SX laptop from 1990 or something to test PDOS on real hardware since I no longer have access to a 386.

But I have had great success with the x64 version of PDOS so will probably be switching to that from now on.

Although there's not a lot left to do on that either (that I'm interested in), so I'm not sure what I'll be doing when that is proven to my satisfaction. I might switch to mainframe emulation on UCX64.
 
After experimenting with the hand386, I don't recommend it at all for development, I think the BIOS is completely broken. I don't know if this is "normal" for BIOS of that era to have these many bugs, but this one sure does have a few. I found these issues by testing a disk dumping utility that I developed some time ago (https://github.com/ImanolBarba/diskdump)
- LBA addressing seems to be broken: The LBA extensions are present in the BIOS, it even says in the disk configuration utility that it's enabled, but when you try to actually use it (int13h ah=42h or anything in that family of functions), it returns error code 01, which is "Invalid command sent to disk controller".
- CHS addressing is also weird: I found this while trying to boot FreeDOS. In short, it won't. Whether or not I disable LBA, the disk is shows as C=whatever H=16 S=63, if I then read disk geometry it's reported as C=another_amount H=64 S=63. Basically, whatever I specified in the BIOS as disk geometry is completely ignored, even if I disable LBA. After setting heads to 64 in the BIOS I was even able to *almost* make FreeDOS boot.

In short, LBA extensions are shot, and CHS is buggy, so I think you're much better off with another platform.
 
ImanolBarba said:
After experimenting with the hand386, I don't recommend it at all for development, I think the BIOS is completely broken. I don't know if this is "normal" for BIOS of that era to have these many bugs, but this one sure does have a few. I found these issues by testing a disk dumping utility that I developed some time ago (https://github.com/ImanolBarba/diskdump)
- LBA addressing seems to be broken: The LBA extensions are present in the BIOS, it even says in the disk configuration utility that it's enabled, but when you try to actually use it (int13h ah=42h or anything in that family of functions), it returns error code 01, which is "Invalid command sent to disk controller".
- CHS addressing is also weird: I found this while trying to boot FreeDOS. In short, it won't. Whether or not I disable LBA, the disk is shows as C=whatever H=16 S=63, if I then read disk geometry it's reported as C=another_amount H=64 S=63. Basically, whatever I specified in the BIOS as disk geometry is completely ignored, even if I disable LBA. After setting heads to 64 in the BIOS I was even able to *almost* make FreeDOS boot.

In short, LBA extensions are shot, and CHS is buggy, so I think you're much better off with another platform.
Click to expand...

Both of those things are what caused PDOS/386 to both not boot, and required me to operate the Hand 386 for longer than I expected - too long that it died by the time I have resolved both things.

I documented the whole saga in the pdos Discord channel.

First the LBA thing:

kerravon@kerravon-pc:~/devel/pdos/src$ git show b03f2fe9980ced99293fb06c15e52de0b0f7cb4a
commit b03f2fe9980ced99293fb06c15e52de0b0f7cb4a
Author: Paul Edwards <mutazilah@gmail.com>
Date: Sun Aug 27 00:19:01 2023 +0800

check specifically whether AH=42H is supported

diff --git a/src/mbr.asm b/src/mbr.asm
index cdffda78..16bdb8c5 100644
--- a/src/mbr.asm
+++ b/src/mbr.asm
@@ -103,6 +103,9 @@ mov bp,offset no_lba_extensions
jc fatal_error
cmp bx,0aa55h
jnz fatal_error
+; Bit 1 says whether AH=42H is supported or not
+and cx, 1
+jz fatal_error

; Load volume boot record
mov ax,[si+8] ; put sector number into LBA packet
kerravon@kerravon-pc:~/devel/pdos/src$


My problem. Not the (AMI from memory) BIOS.

And that code was in fact exercised and I got past that problem (in my code).

Then I hit a different problem in my code (kernel, not mbr) which is that I was using LBA when I shouldn't have been. And that's what never got tested on the Hand 386.

And since I couldn't get a Hand 386 anymore, I resorted to buying a laptop from 1990 from Australia (I'm Australian, but now live in the Philippines). That saga has been documented on my vlog (bottom of pdos.org) 2023-09-26 and 2023-09-27 so far (I haven't exhausted all possibilities yet, but I'm half stuck).


Ok, so second problem with using the Hand 386 which I discovered before I even started. I knew I needed to enable LBA extensions (my mbr required it at the time), but I think whenever I did an auto-detect of the hard disk, it would switch LBA off. After a lot of experimentation, I found out that it was when it had inspected the cylinder number (from memory) in either the start CHS or end CHS and determined that it had exceeded 1023 - or maybe it had exceeded 1023 if it recalculated based on LBA address and fixing the number of heads at 16 to keep within the IDE limit - something like that (it's documented, I can presumably find it in Discord if required). So if it was outside reasonable geometry, it switched on its definition of LBA, which isn't enabling the OS to use LBA addressing but instead to force a fake geometry.

I'm pretty sure I got that bit of the story right - LBA for that particular BIOS means "fake geometry". And I can remember zapping the MBR for sure. But I'm hazy about the details after that.

Since you have a Hand 386 yourself, would you be willing to try out PDOS/386 on it yourself to see if it works?
 
kerravon said:
Both of those things are what caused PDOS/386 to both not boot, and required me to operate the Hand 386 for longer than I expected - too long that it died by the time I have resolved both things.

I documented the whole saga in the pdos Discord channel.

First the LBA thing:

kerravon@kerravon-pc:~/devel/pdos/src$ git show b03f2fe9980ced99293fb06c15e52de0b0f7cb4a
commit b03f2fe9980ced99293fb06c15e52de0b0f7cb4a
Author: Paul Edwards <mutazilah@gmail.com>
Date: Sun Aug 27 00:19:01 2023 +0800

check specifically whether AH=42H is supported

diff --git a/src/mbr.asm b/src/mbr.asm
index cdffda78..16bdb8c5 100644
--- a/src/mbr.asm
+++ b/src/mbr.asm
@@ -103,6 +103,9 @@ mov bp,offset no_lba_extensions
jc fatal_error
cmp bx,0aa55h
jnz fatal_error
+; Bit 1 says whether AH=42H is supported or not
+and cx, 1
+jz fatal_error

; Load volume boot record
mov ax,[si+8] ; put sector number into LBA packet
kerravon@kerravon-pc:~/devel/pdos/src$


My problem. Not the (AMI from memory) BIOS.

And that code was in fact exercised and I got past that problem (in my code).

Then I hit a different problem in my code (kernel, not mbr) which is that I was using LBA when I shouldn't have been. And that's what never got tested on the Hand 386.

And since I couldn't get a Hand 386 anymore, I resorted to buying a laptop from 1990 from Australia (I'm Australian, but now live in the Philippines). That saga has been documented on my vlog (bottom of pdos.org) 2023-09-26 and 2023-09-27 so far (I haven't exhausted all possibilities yet, but I'm half stuck).


Ok, so second problem with using the Hand 386 which I discovered before I even started. I knew I needed to enable LBA extensions (my mbr required it at the time), but I think whenever I did an auto-detect of the hard disk, it would switch LBA off. After a lot of experimentation, I found out that it was when it had inspected the cylinder number (from memory) in either the start CHS or end CHS and determined that it had exceeded 1023 - or maybe it had exceeded 1023 if it recalculated based on LBA address and fixing the number of heads at 16 to keep within the IDE limit - something like that (it's documented, I can presumably find it in Discord if required). So if it was outside reasonable geometry, it switched on its definition of LBA, which isn't enabling the OS to use LBA addressing but instead to force a fake geometry.

I'm pretty sure I got that bit of the story right - LBA for that particular BIOS means "fake geometry". And I can remember zapping the MBR for sure. But I'm hazy about the details after that.

Since you have a Hand 386 yourself, would you be willing to try out PDOS/386 on it yourself to see if it works?
Click to expand...
Sure, happy to if you provide an image or something
 
ImanolBarba said:
Sure, happy to if you provide an image or something
Click to expand...
Thanks!

The image is available as the first link under "PDOS/386 hard drive image" at http://pdos.org .

Here is the direct link:


The .vhd is effectively a .img so if your disk burning software requires that extension, you can rename it.

Let me know of any issues. Thanks.


P.S. Can you provide a photo after it powers up so that I can see the detected memory and disks, and then do "dir" and "hexdump" (just to display usage) so that I can see a program executing and take a photo of that too please.
 
Just attempted to boot it, but unfortunately I can't go past the bootloader message (Welcome to PDOS/386), I tried LBA, no LBA, and somehow making the fake CHS match the configured device (which did make FreeDOS kernel boot, but fail to locate FreeCOM afterwards) to no avail.

I am starting to accept that MS-DOS 6.22 is about the only thing that will boot here, at least until I get my FDC ISA card set up and I can try booting floppies

Let me know if you want anything in particular tried out

Cheers
 
ImanolBarba said:
Just attempted to boot it, but unfortunately I can't go past the bootloader message (Welcome to PDOS/386), I tried LBA, no LBA, and somehow making the fake CHS match the configured device (which did make FreeDOS kernel boot, but fail to locate FreeCOM afterwards) to no avail.

I am starting to accept that MS-DOS 6.22 is about the only thing that will boot here, at least until I get my FDC ISA card set up and I can try booting floppies

Let me know if you want anything in particular tried out

Cheers
Click to expand...

Thanks a lot for doing that test!

As usual, programmers are over-confident that it should work now. It's working under Bochs and under Virtualbox and on a modern computer with legacy BIOS - it should work!

Having said that - in order to display that message it has at least loaded the kernel, and also it means that printf is operational, which means I can try to debug the issue.

However, that is an iterative process (putting in new debug versions) and it may take 10 attempts at replacing pdos.sys on the disk (similar to msdos.sys), which is more than I expected anyone to do.

If you are happy to do that, let me know and we can communicate privately during the debug process.

The other option is that I can see if it works on my real 386SX, and if I get the same problem I can fix it there before asking you to try again on the Hand 386. The problem is that my 386SX isn't working properly, and only works for about 15 minutes and then I need to wait 2 days for it to reset, so I haven't even got the computer running MSDOS from hard disk yet (in fact - the hard disk isn't even recognized yet, because I wasn't informed what parameters to use, so I'm using an alternative way of guessing that information). So it could be months before I ask for another test.

One more thing I forgot to mention - some of the procedures PDOS/386 does are slow. Under emulation I don't notice that. On real hardware those procedures are slow.

So can you let the Hand 386 run for 10 minutes after the "welcome to pdos" message to ensure that it really has hung and isn't merely slow?

I thought PDOS/86 didn't work on my Book 8088, but I was wrong - it came up after about 5 minutes. Other people have similarly reported hangs and it turned out that their emulator was more faithfully reproducing real hardware and it was in fact working, just slowly. The process of making PDOS faster hasn't really begun yet, except that I have an algorithm in mind. At the moment the focus is just getting it to work at all (which it does - everywhere I have the ability to test).

Thanks.
 
kerravon said:
Thanks a lot for doing that test!

As usual, programmers are over-confident that it should work now. It's working under Bochs and under Virtualbox and on a modern computer with legacy BIOS - it should work!

Having said that - in order to display that message it has at least loaded the kernel, and also it means that printf is operational, which means I can try to debug the issue.

However, that is an iterative process (putting in new debug versions) and it may take 10 attempts at replacing pdos.sys on the disk (similar to msdos.sys), which is more than I expected anyone to do.

If you are happy to do that, let me know and we can communicate privately during the debug process.

The other option is that I can see if it works on my real 386SX, and if I get the same problem I can fix it there before asking you to try again on the Hand 386. The problem is that my 386SX isn't working properly, and only works for about 15 minutes and then I need to wait 2 days for it to reset, so I haven't even got the computer running MSDOS from hard disk yet (in fact - the hard disk isn't even recognized yet, because I wasn't informed what parameters to use, so I'm using an alternative way of guessing that information). So it could be months before I ask for another test.

One more thing I forgot to mention - some of the procedures PDOS/386 does are slow. Under emulation I don't notice that. On real hardware those procedures are slow.

So can you let the Hand 386 run for 10 minutes after the "welcome to pdos" message to ensure that it really has hung and isn't merely slow?

I thought PDOS/86 didn't work on my Book 8088, but I was wrong - it came up after about 5 minutes. Other people have similarly reported hangs and it turned out that their emulator was more faithfully reproducing real hardware and it was in fact working, just slowly. The process of making PDOS faster hasn't really begun yet, except that I have an algorithm in mind. At the moment the focus is just getting it to work at all (which it does - everywhere I have the ability to test).

Thanks.
Click to expand...
To be honest, I am not blaming the developers here, this BIOS is a mess and even some software I wrote which was tested working with an XT running pc-dos 2.0 does not run well on the hand (LBA calls fail)

Happy to run more tests, will leave it booting until battery runs out, but I'm semi confident it just froze.

I think though, the best chance here if you absolutely need to test on the hand386 without having it is to dump the BIOS (I can provide it) and integrate it into 86box/pcem (needs some coding, I am interested in making it work but I have not started on that yet). This way you can quickly iterate on a virtualised environment without swapping CFs in and out.

Cheers
 
ImanolBarba said:
To be honest, I am not blaming the developers here, this BIOS is a mess and even some software I wrote which was tested working with an XT running pc-dos 2.0 does not run well on the hand (LBA calls fail)

Happy to run more tests, will leave it booting until battery runs out, but I'm semi confident it just froze.

I think though, the best chance here if you absolutely need to test on the hand386 without having it is to dump the BIOS (I can provide it) and integrate it into 86box/pcem (needs some coding, I am interested in making it work but I have not started on that yet). This way you can quickly iterate on a virtualised environment without swapping CFs in and out.

Cheers
Click to expand...
Thanks for agreeing to assist with further PDOS tests.

I am not in a rush to fix the problem, so that bit is not an issue. Even a 2 day turnaround is likely to have the problem resolved in a month with 10 tests. The project has gone on for 30 years.

With regard to your own software - why do you expect LBA to work? Early BIOSes did not support that. For it to have worked on the XT you must have used a non-period BIOS.

Since the Hand 386 appears to be using a genuine period BIOS, if you refer to this:


after checking BX:

BX = AA55h if installed

you then check bit 0:

0 extended disk access functions (AH=42h-44h,47h,48h) supported

you will find that it is NOT set. I suspect that you are attempting to use AH=42H, as I was.

I will send you a PM when I have a new pdos.sys to overlay.

Thanks!
 
> With regard to your own software - why do you expect LBA to work? Early BIOSes did not support that. For it to have worked on the XT you must have used a non-period BIOS.

The software detects if the BIOS supports LBA, and if not, falls back to CHS

The problem is, this BIOS reports LBA extensions are supported (which I am checking exactly as you describe, I know what I'm doing :) ), but are not working properly as shown
 
ImanolBarba said:
> With regard to your own software - why do you expect LBA to work? Early BIOSes did not support that. For it to have worked on the XT you must have used a non-period BIOS.

The software detects if the BIOS supports LBA, and if not, falls back to CHS

The problem is, this BIOS reports LBA extensions are supported (which I am checking exactly as you describe, I know what I'm doing :) ), but are not working properly as shown
Click to expand...

Before my (second - I owned two - both died a short time after use) Hand 386 died, I got to the point where I had found that bx was being set as I mentioned, but found that cx bit 0 was NOT set.

Are you saying you have a (presumably identical) Hand 386 to me, and cx bit 0 (ZERO) is SET, indicating that AH=42H is available?

Sounds like one of us has done something wrong in our code.

Here's my code:

mov bp,offset no_lba_extensions
jc fatal_error
cmp bx,0aa55h
jnz fatal_error
; Bit 0 says whether AH=42H is supported or not
and cx, 1
jz fatal_error


Can I see yours?

Note that my real 386 screen was dead again today so I will be trying that again in 2 days.

So I am expecting to try your Hand 386 again as the only available test machine.

Not sure yet when the new drop will be available due to other priorities.
 
kerravon said:
Before my (second - I owned two - both died a short time after use) Hand 386 died, I got to the point where I had found that bx was being set as I mentioned, but found that cx bit 0 was NOT set.

Are you saying you have a (presumably identical) Hand 386 to me, and cx bit 0 (ZERO) is SET, indicating that AH=42H is available?

Sounds like one of us has done something wrong in our code.

Here's my code:

mov bp,offset no_lba_extensions
jc fatal_error
cmp bx,0aa55h
jnz fatal_error
; Bit 0 says whether AH=42H is supported or not
and cx, 1
jz fatal_error


Can I see yours?

Note that my real 386 screen was dead again today so I will be trying that again in 2 days.

So I am expecting to try your Hand 386 again as the only available test machine.

Not sure yet when the new drop will be available due to other priorities.
Click to expand...
Ahhhh you're right, I was NOT checking that it supported the packet structure, hence why it fails.

Code is here https://github.com/ImanolBarba/diskdump/blob/main/DISK.C#L25

I cannot check right now but I'm 98% sure it will return the same thing as yours

Turns out I did not know what I was doing :D
 
You must log in or register to reply here.
Back
Top