How can a bootloader be made without 'int 13h'?

[Sophite]

I'm thinking about forking an old unix-like distro or something and porting it to this, or making a new OS for it: https://en.wikipedia.org/wiki/HP_200LX

The catch is that I can't use interrupts for reading from the 'disk'... https://en.wikipedia.org/wiki/HP_200LX# ... patibility

How can I make a bootloader without disk I/O interrupts?

[BenLunt]

I think the answer is at the second URL you posted. "Drivers have been partially written for this purpose (to boot MINIX 2.0)".

You would have to find out exactly how to communicate with the hardware and read from the media yourself, all doing this within the size of a single sector/block, whatever size the media has, assuming it reads the first sector/block into RAM.

I am not aware of this design, does the POST read from the media and place the first sector/block at 0x07C00? Probably not, it probably has ROM code that it executes. Does this mean you will have to re-flash the ROM to your code? What kind of media would you be reading from?

Sounds like an interesting project.

Ben

[BrightLight]

If your only goal is to support that specific PC, then I think it's relatively easy to write a driver that only works for that PC. I'd guess that it probably has an ATA hard disk, and so a simple ATA PIO C/H/S-based driver would be sufficient to run on that PC.

[Sik]

Er, I don't think that thing has a hard disk... (it seems to store files in battery-backed RAM)

I'm guessing the ROM contains both the OS and the BIOS, and there's no bootloader at all since it's hardcoded to run the OS in the ROM. Also that the ROM is an actual mask ROM and needs to be desoldered and replaced with another chip to run a different OS altogether. At this point you may as well get rid of the BIOS and do whatever you feel like doing in your own OS (I suppose the main reason to include BIOS calls was to allow existing DOS programs to work, as they may rely on BIOS services)

This is definitely not a traditional PC and you should expect all rules to have been thrown off the window. Go wild ('ヮ' )


EDIT for further explanation: since this thing doesn't have actual disks and is guaranteed to be running DOS, it doesn't make sense for the BIOS to include such functionality (and for programs to rely on DOS services). Indeed, even if you somehow reinterpreted the functions for this specific setup, letting programs touch it directly would be a bad idea since they're likely expecting something different and could potentially trash the data stored on the device. In this case it's better to make those programs crash (before they do anything dangerous) and only let those that rely on DOS to run.

[mallard]

As someone who also has a HP 200LX and has run Minix on it (and had an interest in Minix previously), the "driver" that Minix uses works very simply; it calls DOS.

When Minix is loaded (from DOS; AFAIK there is no way to have the 200LX boot from anything other than its internal ROM, which contains DOS, although it can read CONFIG.SYS and AUTOEXEC.BAT from any recognised storage device), the loader simply requests the largest available memory block from DOS and loads into it. DOS itself (and any TSRs, drivers, etc.) is still in memory and can still be called. That's how the driver works (and, incidentally, how it can work with storage devices that the ROM/BIOS/Firmware does not, e.g. large flash cards that need the "ACECARD" driver).

I've looked at the idea of building an OS for the HP-LX palmtops before and this approach seems to be the only viable option really. You can't stop the device from loading DOS during boot, so you may as well consider it part of the device's "Firmware" (it pretty much is) and use it. Kinda similar to how Windows 9x works; it can also fall back to DOS support for storage devices.

[Sophite]

A
I've looked at the idea of building an OS for the HP-LX palmtops before and this approach seems to be the only viable option really. You can't stop the device from loading DOS during boot, so you may as well consider it part of the device's "Firmware" (it pretty much is) and use it. Kinda similar to how Windows 9x works; it can also fall back to DOS support for storage devices.

Oh... Well, I guess I'll be using DOS calls instead of BIOS calls

I'm gonna assume it's the same in the HP 95LX (the one I'm getting).

Thanks for your help!

EDIT: Does MS-DOS restrict the ability for a program to do kernel-level stuff?

EDIT 2: Wait... If DOS has it's own OS interrupts (syscalls)... How did they get MINIX to run on it?

[Brendan]

Hi,

A
I've looked at the idea of building an OS for the HP-LX palmtops before and this approach seems to be the only viable option really. You can't stop the device from loading DOS during boot, so you may as well consider it part of the device's "Firmware" (it pretty much is) and use it. Kinda similar to how Windows 9x works; it can also fall back to DOS support for storage devices.

Oh... Well, I guess I'll be using DOS calls instead of BIOS calls

I'm gonna assume it's the same in the HP 95LX (the one I'm getting).

Thanks for your help!

EDIT: Does MS-DOS restrict the ability for a program to do kernel-level stuff?

MS-DOS is real-mode, so nothing stops any executable code from doing whatever it feels like. The only kind of protection is that the OS is in ROM (until someone puts an OS somewhere else, and has no protection against any malware at all).

EDIT 2: Wait... If DOS has it's own OS interrupts (syscalls)... How did they get MINIX to run on it?

I don't know about MINIX; but after boot you could start your own device drivers (the same as you would have if you used BIOS during early boot). However; for something like this (designed as "OS+hardware as single product", not designed to run any other OS, and not "PC compatible"), I'd expect other pieces of hardware to be non-standard and undocumented, and/or just plain missing.


Cheers,

Brendan

[linguofreak]

EDIT: Does MS-DOS restrict the ability for a program to do kernel-level stuff?

MS-DOS itself does not, because it was written before the x86 line offered the capability of distinguishing between kernelspace and userspace. On hardware that supports it (the HP 200LX doesn't), programs like DPMI hosts could act as kernels and prevent other programs from doing kernel-level stuff, but often didn't do that in an airtight fashion for backwards compatibility reasons (which is part of the reason that Win 3.x and 9x were so notoriously unstable).

So whether you can do "kernel-level" stuff on your HP 200LX depends on what you mean by "kernel level". If you mean "can I write code that will interface directly with the hardware?", yes, because DOS is incapable of stopping you. If you mean "can I keep programs from trashing each other, or my OS?", which is one of the primary jobs of a modern kernel, the answer is no, because your hardware doesn't give you the tools you need to do that.

EDIT 2: Wait... If DOS has it's own OS interrupts (syscalls)... How did they get MINIX to run on it?

Neither DOS nor your hardware provide the facilities that DOS would need to stop MINIX from running.

[Sophite]

EDIT: Does MS-DOS restrict the ability for a program to do kernel-level stuff?

MS-DOS itself does not, because it was written before the x86 line offered the capability of distinguishing between kernelspace and userspace. On hardware that supports it (the HP 200LX doesn't), programs like DPMI hosts could act as kernels and prevent other programs from doing kernel-level stuff, but often didn't do that in an airtight fashion for backwards compatibility reasons (which is part of the reason that Win 3.x and 9x were so notoriously unstable).

So whether you can do "kernel-level" stuff on your HP 200LX depends on what you mean by "kernel level". If you mean "can I write code that will interface directly with the hardware?", yes, because DOS is incapable of stopping you. If you mean "can I keep programs from trashing each other, or my OS?", which is one of the primary jobs of a modern kernel, the answer is no, because your hardware doesn't give you the tools you need to do that.

EDIT 2: Wait... If DOS has it's own OS interrupts (syscalls)... How did they get MINIX to run on it?

Neither DOS nor your hardware provide the facilities that DOS would need to stop MINIX from running.

Oh... I'm new to old hardware.

Thanks, this helps quite a bit.

[Sik]

Silly question: are the vectors stored in RAM or ROM on this hardware? Because if on RAM you can always just change them to install your own interrupts (possibly then making them call whatever was in the vectors before them, much like DOS drivers used to do). If on ROM then they're fixed and you can't do anything about it.

By the way, that Windows 3.0 runs on it should give you an idea of how far you could go.

[mallard]

Silly question: are the vectors stored in RAM or ROM on this hardware?

The IVT is definitely in RAM, it runs MS-DOS and just about every application that's compatible with an XT-class PC with a CGA display. Much DOS software (including all TSRs and the aforementioned Windows 3.0) relies on being able to hook interrupts.

The device's memory map is pretty much that of a standard XT. 640KB RAM, followed by video memory and ROM areas (the built-in ROM is mapped here, using a bank-switching scheme since there is several MBs of ROM-based software). I'm not entirely sure how the RAM-based storage is accessed; it's probably memory-mapped in some sense, since the RAM vs. storage partitioning is configurable (but 640KB vs. the rest is the default and highly recommended). Units with more than 1MB of total memory (unfortunately, I only have a couple of 1MB units, so I can't test this) can have some memory configured as EMS, with an appropriate driver, which implies that the hardware might contain some sort of CPU-external "MMU". It might even be possible to remap parts of the 640KB of ordinary memory...