OSDev.org

I've created the first 2 system calls for BoxOn's built in firmware. These are read and write for a disk image. I've attached a small multiboot asm kernel so you can see the way to use these calls to firmware services and I plan to follow this format for other services.

The first thing to do is to get the firmware service call entry address by scanning memory starting from the address in ESI for a 'BoxOnIO' signature. The information block format (BoxOnInfoBlock) can be seen in src/firmware/boxonio/boxonio.h in the source code.

The parameters are passed to the service as



The disk packet is then formatted as



These calls are for disk images mounted as a BIOS disk (IMGMOUNT) not directories mounted as a DOS disk (MOUNT).

An example read from the tiny.s kernel



I'm interested in any feedback about the structure of the service call handling and if you have any ideas about design or changes of how these calls could/should be improved please let me know.

For those interested I've started work on the frame buffer, the current services are set mode and get info.

Set mode takes the device ID, the bits per pixel for colors, a text or graphics mode and the resolution. The low 8 bits of the flags (ecx) set the bits per pixel and the 9th bit specifies whether it's a text or graphics mode. The top 16 bits of the data (edx) sets the X resolution and the low 16 bits set the Y resolution.

Setting a text mode:


Setting a graphics mode:


To get the info about the current mode:

This will return the flags and data in the same format as for set mode.

The get info service will be able to accept different flags to specify what kind of information about the device you are requesting. The data will point to memory allocated for a structure ready to accept the type of info block. This could be the frame buffer device details similar to the VBE information block or it could be the detailed info about a mode similar to the VBE mode info block.

I've set up a wiki site to document BoxOn and it's firmware. The pages are here for BoxOn and the current work on the frame buffer.

You can see the device information block for a frame buffer provides the minimum to detect the type of device installed. The list of modes will be fetched with another information block service that lists more details about each mode in one single table.

This is the support for the internal frame buffer for displaying to the BoxOn window. What this is leading to is a VNC/RFB device so you can host an OS in BoxOn and use it with a VNC viewer at localhost or over a network.

The first development release of BoxOn for Windows is available to test out. A small kernel is included to demonstrate how to use the firmware and devices. See the README.1st file for more details.

https://github.com/b-zaar/boxon/releases

You will need to install DOSBox first as it uses the same libraries.

Hi,

I downloaded BoxOn from the GitHub download page, but after running it I get the error This program can't start because libpdcurses.dll is missing from your computer. Try reinstalling the program to fix this problem.

I'm running Windows 7 64 bit and I already have DOSBox installed.

Thanks

Ok, sorry about that. I forgot it needed the extra library for the debug window. I've updated the release package and found a blank machine to try it on. It now looks like a stand alone program so DOSBox might not need to be installed first.

I've also played with the bxnkernel configuration and Makefile and made it easier to built and run. Unzip the package to a directory and run the bootsys.bat file to load the included kernel. To build the kernel run the makefile with a i686-elf cross compiler.

It's starting now, thanks for the quick fix

So with all the positive feedback BoxOn has received I'm thinking of developing ReBoxOn.

Just an idea that's been planted...

BoxOn will act more like an external firmware/debugger to either Bochs or Qemu (this is currently the preferred choice) and hook the xchg bx, bx or qemu equivalent to perform a service call. The firmware interface will be simplified to act more like a stripped back *nix with only the simplest of file operations for system call support. This should be enough to provide access to the host OS's filesystem, protected by the specified mount point and the host OS's own file security. Some devices to be supported will be nfs (to use the mounted filesystem), VNC/RFB, and maybe some RPC. All other devices will need to be supported by the OS itself using the VM hardware I/O.