Re: countdownEvent in BOCHS

On Tue, Oct 2, 2012 at 2:36 PM, Stanislav <[email protected]> wrote:
> Think real hardware CPU, it communicates with outer world with pins and
> interrupts.
>
> The CPU won't be aware of keyboard button pressed until keyboard controller
> send interrupt to it through PIC, right ?
>
> The fact that timers code is also handled from CPU code is atavism and
> should be fixed at some time.
>
> The countdownEvent function is called not from handleAsyncEvent function of
> CPU but from BX_TICKN which is called from CPU when it likes to do so.
> The BX_TICKN calls for countdownEvent function if it sees that next event
> has to come already in terms of emulated time.
> This is one this way only because emulated time is ***defined*** using CPU
> instructions executed.
> The IPS variable says how many executed instruction would be 1 emulated
> second.
> So if IPS=100M and timer for example should be called 10 times a second it
> would be called every 10M instructions. How ? CPU calls BX_TICKN.
> In another implementation the timer could seat in another thread and ping
> periodically Bochs about instructions executed.

Make sure i understand you correctly here. the emulated time is
defined by the number of CPU instructions emulated. the input from the
device could be ready before that. but the CPU only checks for it when
CPU believes to be neccessary. i.e. the number of instructions
executed exceed some number.

Xin

> When is sees 10M instructions passed it would raise interrupt to CPU though
> PIC - this is the way I like more and promise you that someday things would
> work like this.
> Especially because it allows to do SMP emulation by several HW threads in
> more robust way.
>
> Stanislav
>
> -----Original Message-----
> From: Xin Tong [mailto:[email protected]]
> Sent: Tuesday, October 02, 2012 9:03 PM
> To: Stanislav
> Cc: Volker Ruppert; [email protected]
> Subject: Re: [Bochs-developers] countdownEvent in BOCHS
>
> On Tue, Oct 2, 2012 at 2:57 PM, Stanislav <[email protected]> wrote:
>> The async_event is nothing more than just an indication that CPU
>> should check for external events.
>> The events themselves are not necessary have to be pending at this
>> time,
>
> not too sure about what you mean by events here. can you please give an
> example ?
>
> Xin
>
>> moreover setting the bit alone as is won't cause any side effect.
>> The interrupts delivered to CPU through PIC, I/O APIC or APIC or by
>> raising external pins like SMI/NMI
>>
>> Stanislav
>>
>> -----Original Message-----
>> From: Xin Tong [mailto:[email protected]]
>> Sent: Tuesday, October 02, 2012 7:46 PM
>> To: Volker Ruppert
>> Cc: [email protected]
>> Subject: Re: [Bochs-developers] countdownEvent in BOCHS
>>
>> On Tue, Oct 2, 2012 at 1:23 PM, Volker Ruppert
>> <[email protected]>
>> wrote:
>>> Hi!
>>>
>>>
>>>> so no immediate interrupt is generated when the keystroke is
>>>> received from the keyboard ? rather, the interrupt is only generated
>>>> when the timer fires and the input buffer of keyboard is checkd ?
>>>
>>>
>>> That's right. The keyboard controller should not generate interrupts
>>> faster than it happens on real hardware. Note that the keyboard and
>>> mouse interrupts are only generated if enabled in the controller (and
>>> of course in the PIC). The timer handler also manages the paste
>>> feature. When pressing the paste button in the Bochs header bar, text
>>> data can be sent to the keyboard controller. A delay is required
>>> between each character to avoid a buffer overflow. The keyboard does
>>> not
>> yet emulate the typematic feature.
>>> The delay and characters per second depend on the host settings. When
>>> implementing this feature, most of the job must be done by the timer
>>> handler.
>>
>> so lets say i press a key on my computer keyboard. it will raise an
>> interrupt on my physical machine. the character is read and stored in
>> a BUFFER A. this BUFFER A is then later copied to a BUFFER B (in bochs
>> emulated keyboard) in bochs and bochs checks for what is in BUFFER B
>> when a timer fires.
>>
>> 2 questions.
>>
>> 1. when and how is the copying done from BUFFER A to BUFFER B ?
>> 2. why can not the same thread set a bit in the BX_CPU_C async_event
>> bit to force the checking of BUFFER B ?
>>
>> Xin
>>
>>>
>>>
>>>>> The timer for the gui event handler is located in the devices.cc
>>>>> code. It calls bx_gui->handle_events() every 1 millisecond.
>>>>
>>>>
>>>>> This method sends the
>>>>> keyboard / mouse data to the buffer of the emulated device.
>>>>>
>>>> can you explain this a bit more ?
>>>
>>>
>>> The gui event handler is always called from the simulation thread
>>> (timer handler in devices.cc). If there is only one thread, the code
>>> polls outstanding events from the library used (e.g. X11, SDL). Mouse
>>> events can be sent directly to the hardware emulation (PS/2 , USB).
>>> Keyboard events must be translated to BX_KEY_* constants. If
>>> necessary (and enabled) a remap of the localized keyboard layout to
>>> the U.S. one is handled. In a multi-threaded environment (rfb, win32,
>>> wx) the gui thread detects events and stores them in a queue. The gui
>>> method
>>> handle_events() only has to read from this queue and continues
>>> processing
>> events as described above.
>>>
>>> Our development docs still have some empty sections. Some parts of
>>> this text might be useful there.
>>>
>>> --
>>> Thanks
>>>
>>> Volker
>>>
>>
>> ----------------------------------------------------------------------
>> ------
>> --
>> Don't let slow site performance ruin your business. Deploy New Relic
>> APM Deploy New Relic app performance management and know exactly what
>> is happening inside your Ruby, Python, PHP, Java, and .NET app Try New
>> Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> bochs-developers mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/bochs-developers
>>
>

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev