Re: countdownEvent in BOCHS

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.
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