Zalt virtual devices over USB

I still don’t have any IO hardware in the Zalt system. I am working on a general high-speed bus design with Ron, but that is far from usable at this stage.

Virtual Devices

So the idea came to tunnel all the smart IO devices I would like to build virtually over USB to and from the PC. The PSoC (kit) System Controller has a (device) USB port on it and dropping in the USB design component in the PSoC design service and configuring that to two-way USB bulk transfer basically is all you need to get that working.

The Virtual Devices app on the PC is a C++ application in Visual Studio using Qt as an application framework and libusb as a USB library.

I had some trouble getting the event system working on a Qt Console application, so I turned it into a Gui application. I guess the eventing system is tied to the (Windows) event loop. The application installs an application-level event filter that catches all the key strokes – when the keyboard button on the Gui is active. These keyboard events are put in a USB protocol message of my own design and send to the PSoC. That is about all the app does at this moment. Future plans include having a virtual file system. Not sure about video yet – perhaps start with character based.

The PSoC has a new UsbProcessor component that (for now only) receives the protocol messages sent from the PC app and dispatches them to the correct device handler. I changed the Keyboard device to now handle the protocol messages and signal availability to the Z80 using the interrupt and vector that was already in place. The Z80 will then use IO to come and get the key code.

virtual-devices

Smart IO Devices

The whole idea of making the virtual devices PC app is to develop the stream-based smart-devices Z80 API. The bus I mentioned earlier uses a high-level protocol to communicate with each smart-IO-device. The idea being that the Z80 programs does not want to know or care about file sectors or tracks – it only care about files, directory structure and content.

So now I can write the API that will be used to access remote data of the smart-devices over the bus. I can even start to code the bus protocol I had in mind to see if it covers all the bases. But first things first – small steps.

Published in: on January 25, 2017 at 10:40 am  Leave a Comment  

Zalt Debugging Support

I have been busy on the Zim80 Z80 simulator software a lot lately. But recently I have been switching back to writing the Zalt bios (kernel/os – whatever you want to call it) and setting up basic facilities for further development.

One of these basic facilities is some kind of way to implement a debugger in the PSoC System Controller. As I have mentioned before I have chosen to use the Z80 Halt instruction as a signal from the Z80 to the System Controller it wishes to break into the debugger. The System Controller responds and an exchange of data follows.

  • Z80: Executes the Halt instruction and the HALT signal goes low (active).
  • PSoC: Has an interrupt on the HALT signal activation and executes its ISR:
    • Activates the NMI signal to the Z80
    • Wait for the HALT signal to become inactive – this means the Z80 has detected the NMI and is executing its NMI handler at address 66h.
    • Deactivate the NMI signal.
    • The Debugger starts the state-machine to indicate we have a debugger session.
  • Z80: The NMI handler calls a routine to save all registers into memory variables and calls the PSoC to ask if we’re in a debug session – executes an In (io) instruction on the debug-port (currently 00h – but that may change).
  • PSoC: detects the IO-In instruction and calls the Debugger (because the address is on the Debug-Port) and advances the state machine to the next state. Note that the PSoC will insert wait-states for all IO-operations to/from the Z80 – it just isn’t fast enough because software is involved.
  • Z80: It checks the result of the In-instruction and continues. For now I have hard -coded to dump all register values  (we previously saved) to the PSoC. At a later time a whole debug-monitor can be implemented here.
  • PSoC: all register values are intercepted and stored in memory. When done the statemachine engages its last state that signals the main-loop in the PSoC to print all the register values – remember we’re executing inside the Halt-ISR here (actually it’s the IO-ISR).
  • Z80: With all register values sent, the NMI handler returns (retn) and continues normal execution of the program.

Because I am currently writing most code in C I have made some debug marco’s that encapsulate this ‘breakpoint’ halt statement and make it easy to use.

As I go, I will add more functionality to the debug-monitor implementation to support more commands and interaction with the developer at the debug console.

You can follow along with the progress at the Zalt github repository.

Published in: on January 6, 2017 at 1:23 pm  Leave a Comment