I'm trying to layout the design for all of the devices of my emulator...
It uses external plugins for devices, but the way my messaging system works, I need to have #defines for about every device that has interaction
If you could, add any devices I missed, and anything that might "hook" into it...
here is a bit of a list
keyboard
-KeyPress --usually sent from gui, tells that a key was pressed
-KeyRelease
com(1)
-hook_into --this is a function call or something for communication between com host and com client
lpt
-hook_into --same as above
USB
-hook_into(port_num) -- same as above...
Mouse
-MouseMoved --has a packet of mouse info..(usually sent from GUI)
Floppy
-LoadImage --loads a floppy image, or possibly mounts a floppy drive
DMA(in the core, I guess?)
PCI
-hook_into(card_num) --a function for communication between host and device
Firewire
-hook_into(num) ?no idea on Firewire..
Network_Card
-hook_into... (or should this be considered generic and be put under PCI or whatever?)
ISA
-hook_into(card_num)..hook into for communication
IDE
-hook_into(number) ...I guess, no idea..
CD-Drive
-LoadImage --loads a CD image(.iso) or mounts a CD
HDD
-LoadImahe --same as above
graphics_card
--get_rendering_resolution --this ones already implemented actually..
PIT
?
PIC
-CallIRQ --Calls an IRQ
that's all I can think of right now...
a list of most devices...
-
Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
Are those absolute essentials?~ wrote:What about:
TV/Radio Card
Audio Card
Multimedia device (camera, ...)
Game device (joystick, ...)
Anyway.. I would emulate the bare minimal.. considering your targeting the 8086 initially.. Emulate a bare bones ISA-only system?
(PCI/USB/Firewire etc should probably wait a bit..)
Re: a list of most devices...
Hi,
In this case the interface between the emulator and it's plugins would emulate reads/writes to physical addresses (for memory mapped devices), reads/writes to I/O ports, read/writes to PCI configuration space and IRQs; but wouldn't emulate any specific devices.
In addition, the plugins would need to be hierarchical. For e.g. you could have the main CPU module (the emulator itself) with a chipset plugin attached to it. Then the chipset plugin could have a USB controller plugin, and the USB controller plugin could have a USB mouse and flash memory plugin.
Basically, you could treat the OS's IPC like the CPUs front side bus for the interface between the emulator and the chipset plugin; treat the OS's IPC like a PCI bus for the interface between the chipset plugin and PCI device plugins; and treat the OS's IPC like a USB bus for the interface between a USB controller and a USB device plugin; etc.
That way anyone could make a plugin for any hardware (without the emulator knowing much about the hardware), and the host OS's device drivers could support the same interface/s and act like plugins (to allow real devices to be used from within the emulator).
You could also have several different emulators (e.g. one that interprets instructions like Bochs, one that uses dynamic translation, one that uses VMX/SVM hardware virtualization, etc). You could even emulate different CPUs using the same interfaces - for e.g. a SPARC emulator and/or Itanium emulator that uses the same "PCI device" plugins.
It'd be "mix & match emulation heaven", and you won't need to have #defines for every device...
Cheers,
Brendan
It would be nice to be able to assign a real device to the emulator. For example, open some list of devices (e.g. "Device Manager" in Windows), right click on a second video card and select "make available for emulators", then tell the emulator to use the real video card instead of an emulated video card.hckr83 wrote:I'm trying to layout the design for all of the devices of my emulator...
It uses external plugins for devices, but the way my messaging system works, I need to have #defines for about every device that has interaction
In this case the interface between the emulator and it's plugins would emulate reads/writes to physical addresses (for memory mapped devices), reads/writes to I/O ports, read/writes to PCI configuration space and IRQs; but wouldn't emulate any specific devices.
In addition, the plugins would need to be hierarchical. For e.g. you could have the main CPU module (the emulator itself) with a chipset plugin attached to it. Then the chipset plugin could have a USB controller plugin, and the USB controller plugin could have a USB mouse and flash memory plugin.
Basically, you could treat the OS's IPC like the CPUs front side bus for the interface between the emulator and the chipset plugin; treat the OS's IPC like a PCI bus for the interface between the chipset plugin and PCI device plugins; and treat the OS's IPC like a USB bus for the interface between a USB controller and a USB device plugin; etc.
That way anyone could make a plugin for any hardware (without the emulator knowing much about the hardware), and the host OS's device drivers could support the same interface/s and act like plugins (to allow real devices to be used from within the emulator).
You could also have several different emulators (e.g. one that interprets instructions like Bochs, one that uses dynamic translation, one that uses VMX/SVM hardware virtualization, etc). You could even emulate different CPUs using the same interfaces - for e.g. a SPARC emulator and/or Itanium emulator that uses the same "PCI device" plugins.
It'd be "mix & match emulation heaven", and you won't need to have #defines for every device...
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
Brynet-Inc
- Member
- Posts: 2426
- Joined: Tue Oct 17, 2006 9:29 pm
- Libera.chat IRC: brynet
- Location: Canada
- Contact:
Hi,
For example, (from hckr83's original post) consider the words "but the way my messaging system works".
From what I remember hckr83's messaging system is an asynchronous event driving thing, much like mine. I've tried to implement asynchronous messaging on Linux before (a "portability layer" for C, so applications designed for my OS could be ported to "legacy OSs"). I got the IPC to work using sockets and datagrams on Linux, but by the time I got it to work (and solved some of the other problems) it was far too ugly to consider. It's like making water run uphill - technically possible, but not necessarily good for the environment.
For the ideas above I'd restrict it severely for other OSs (e.g. one portable emulator core and bare minimum hardware emulation). Then I'd tell people to use my OS instead if they want the full singing dancing version of the emulator. This makes good marketting sense too (if you want people to shift from other OSs to your OS, and your "stuff" is good enough).
Cheers,
Brendan
Portability is a major pain in the neck, but it's a pain in the neck that won't really go away regardless of how the emulator actually works.Brynet-Inc wrote:Well if he's trying to make a portable emulator.. That wouldn't be really realistic.. It would be full of "ifdefs/defines" to make that available to people using the Windows "port"
For example, (from hckr83's original post) consider the words "but the way my messaging system works".
From what I remember hckr83's messaging system is an asynchronous event driving thing, much like mine. I've tried to implement asynchronous messaging on Linux before (a "portability layer" for C, so applications designed for my OS could be ported to "legacy OSs"). I got the IPC to work using sockets and datagrams on Linux, but by the time I got it to work (and solved some of the other problems) it was far too ugly to consider. It's like making water run uphill - technically possible, but not necessarily good for the environment.
For the ideas above I'd restrict it severely for other OSs (e.g. one portable emulator core and bare minimum hardware emulation). Then I'd tell people to use my OS instead if they want the full singing dancing version of the emulator. This makes good marketting sense too (if you want people to shift from other OSs to your OS, and your "stuff" is good enough).
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
lol...my Device IPC(if I can call it that) is much different from my OS design's
This one I think is quite good, it's a mix between Events and Messages...
Basically once an message is sent, A "EventCalled" type function is called with the message stuff...
it has some weird features like CallBack_when_done() is set by the sender to tell that the message was received
and then it goes even weirder with the CallBack_when_CallBack_called() which is called after the CallBack_whendone() is called, and is set by the device that got the message
This one I think is quite good, it's a mix between Events and Messages...
Basically once an message is sent, A "EventCalled" type function is called with the message stuff...
it has some weird features like CallBack_when_done() is set by the sender to tell that the message was received
and then it goes even weirder with the CallBack_when_CallBack_called() which is called after the CallBack_whendone() is called, and is set by the device that got the message