embryo wrote:
Does it mean that you have implemented emulation of a processor (x86?), IO space, devices and so on?
DOSBox already emulates a 32 bit CPU with some simple I/O for devices like the video, sound, serial and network. The IDE/ATA interface doesn't exist, all read and write operations need to go through a BIOS service call. This may apply to other devices that I haven't looked into yet. I have not added or removed any of this functionally with BoxOn. Have a look at
this to see it's capabilities.
embryo wrote:
It seems like I need to call your API. ... And where is the border between API and emulation? What I need to work with HDD, for example? Can I use IO ports or I should call your API?
This is the part where the API sits, there is no access to files without BIOS calls and this includes when you mount an image file. I plan to create a simple firmware where you can use system functions after the boot process. This could be something like BIOS32, DPMI or something totally new. The API does not need to support anything more than disk access but it would not be difficult to add support for other hardware if it's a clean usable interface.
embryo wrote:
I suppose something like another device which I can write driver for. Then my code can communicate with the host system using a standard device driver.
The way BoxOn (and DOSBox) supports the BIOS services is different to a regular emulator. With Bochs the machine boots and then a BIOS is loaded and runs inside the emulator memory but with BoxOn the BIOS is outside of the emulators memory. The services are handled by a custom opcode call to the service area and then the function is performed by a BoxOn library not emulated BIOS x86 code.
The interface I'm designing is more about how to pass parameters to a service. This is currently where I'm heading along with using the custom opcode call that BoxOn already supports.
Code:
mov eax, 0x00000003 ; Service number - Read device
mov ebx, 0x00001380 ; Device ID - first hard drive
mov ecx, diskControl ; Pointer to a control structure similar to BIOS extended read
mov edx, memPtr ; Memory pointer to read data buffer
CALL 0x0010 ; The call to the firmware. The actual opcode is 0xfe 0x38 0x10 0x00
This part at the very minimum will be required in some form to access the filesystem or disk image. If it works well it could be expanded to support video or sound without using regular hardware I/O.
Code:
mov eax, 0x00000000 ; Service number - Set/Reset device
mov ebx, 0x00001000 ; Device ID - video card
mov ecx, 0x00000008 ; Mode flags - 8 bit color
mov edx, 0x03200258 ; 800 x 600 resolution
CALL 0x0010 ; The call to the firmware
Or you could have done the same thing by searching for the VBE info block and setting the mode with a vm86 BIOS call.
embryo wrote:
Also there should be some means to tell the emulator from hardware. But it will work only in case of a complete emulation with all processor instructions and many devices supported.
This could be done by searching for an info block somewhere in low memory. Search for something like an 8 byte firmware name ('BIOS32BX') and a checksum and inside the info block will be the configuration to use. If the info block is missing it's not running on the the BoxOn/firmware combination.
embryo wrote:
I still do not see if your system fits the "complete" case or is it something simpler with mandatory API usage just to be able being hosted under your OS/emulator.
BoxOn is not a full emulator, it will not be used to test your OS it will be used to integrate your OS with the host OS.