I have produced two important top level behaviour blocks in this project. The first behaviour, realTime, causes the simulation thread to sleep giving other Windows applications time to run. The virtualIO behaviour is the main behaviour I've produced. This behaviour has two ports screenBufferIn and mouseClicksOut. When the screenBufferIn port is activated the current screen buffer is sent along a Win32 pipe to the Window Dressing application. When there is a mouse event in the internal queue (implemented on the Pipe itself) it is dequed and sent from the mouseClicksOut port. This behaviour 'exists' in VCC and Windows. As such care has been taken not to call any functions which would result in long blocks to the simulation thread. The implementation of the mouse ensures that polling the mouse will not block the simulation. The implementation of the screen will block if there is insufficient space to write to the Pipe, as the client application is continually reading from the screen pipe (and VCC is slow producing new screen buffers) it is virtually guaranteed that significant blocks will not occur. The significance of this is that the flow of simulated time will be relatively uninterrupted i.e. the simulation isn't paused between mouse events. This behaviour is black box C++ and no timing information is provided (or is necessary). This is because there is no processing within this behaviour that would be mapped to the architecture, the dedicated 'video device' would simply refresh the contents of the screen buffer to the screen and mouse events would probably be generated by a dedicated input device. VCC runs under Windows NT, which is a Unicode native platform. The simulation thread itself seems to be Unicode; the strings passed around in the VCC model are ANSI style. This clash is the reason for the TString Class which is written to accept both Unicode and ANSI strings and convert them to whichever format is native to the compilation. A Word about the Screen Buffer The screen buffer has been implemented in VCC as a typed Port. It would be much better to implement it as a block of behavioural memory but there is insufficient time to rework the graphics module. This behavioural memory would be a piece of dedicated memory written to by the main bus and read from by a 'video device'. The changes to the virtualIO behaviour would be minimal and consist of the following
|
||||
|
||||
![]() |
![]() |