Page 1 of 1
BoxOn Firmware
Posted: Sat Sep 20, 2014 8:25 pm
by b.zaar
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
Code: Select all
EAX = service call number
EBX = device ID
ECX = read or write byte count
EDX = disk packet
The disk packet is then formatted as
Code: Select all
[0x00000000] = Read/write buffer address
[0x00000004] = Disk position (low dword)
[0x00000008] = Disk position (high dword, currently not used so set to 0)
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
Code: Select all
; Read from disk 0 sector 0
mov eax, 0x00000002 ; Read file
mov ebx, 0x00130000 ; Disk 0
mov ecx, 0x00000200 ; 200 bytes
mov edx, diskPkt ; Read packet
mov [edx], dword rdBuf ; Buffer address
mov [edx + 4], dword 0 ; Disk position
call [serCall]
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.
Re: BoxOn Firmware
Posted: Thu Sep 25, 2014 2:55 am
by b.zaar
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:
Code: Select all
mov eax, 0x00100000 ; Set mode
mov ebx, 0x00100000 ; First frame buffer device
mov ecx, 0x00000004 ; Text mode 4 bpp (16 colors)
mov edx, 0x00500019 ; 80 cols x 25 rows
call [serCall]
Setting a graphics mode:
Code: Select all
mov eax, 0x00100000 ; Set mode
mov ebx, 0x00100000 ; First frame buffer device
mov ecx, 0x00000120 ; Gfx mode 32 bpp (16.7m colors)
mov edx, 0x04000300 ; 1024 x 768
call [serCall]
To get the info about the current mode:
Code: Select all
mov eax, 0x00100001 ; Get info
mov ebx, 0x00100000 ; First frame buffer device
mov ecx, 0x00000000 ; Flags &
mev edx, 0x00000000 ; Data = 0 then get current mode
call [serCall]
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.
Re: BoxOn Firmware
Posted: Sat Sep 27, 2014 7:59 pm
by b.zaar
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.
Re: BoxOn Firmware
Posted: Sat Oct 04, 2014 12:34 am
by b.zaar
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.
Re: BoxOn Firmware
Posted: Sat Oct 04, 2014 2:51 am
by seuti
b.zaar wrote: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
Re: BoxOn Firmware
Posted: Sat Oct 04, 2014 4:07 am
by b.zaar
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.
Re: BoxOn Firmware
Posted: Sat Oct 04, 2014 6:37 am
by seuti
b.zaar wrote: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
Re: BoxOn Firmware
Posted: Sat Oct 11, 2014 9:53 pm
by b.zaar
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.