Chapter 6 - Socket Interface

This chapter describes the socket interface supported by VirtualT. The Socekt Interface provides the capability of remote control of most of VirtualT's emulation functionality. The interface also adds low-level debug control of the emulation.

Home

Invoking

To enable the socket interface, VirtualT must be invoked with a command-line option to specify the socket port as follows:

This will cause VirtualT to launch a socket listener thread for remote control appliations. To connect to the socket interface using the vt_client application, from a command prompt perform the following:

  1. 'cd' to the VirtualT directory
  2. type './vt_client port_number'

The vt_client application will connect to the socket interface of VirtualT and present a command-line interface for control. The socket interface can be used by any client to remotely control VirtualT, such as a Perl script, C++ test bench, or any other socket capable program. The vt_client application is just a simple command line example application.

Protocol

The socket interface protocol is an ASCII based command / response type protocol. Commands must be sent as independant socket messages. Each command can have one or more arguments formatted appropriately per command. Commands are not terminated with a NEWLINE character. For each command, VirtualT will respond with one or more messages depending on the command. All responses will end with the ASCII text "Ok". Responses that report information will have one or more lines of data each followed with a NEWLINE (\n) character.

Here is an example transaction of the socket interface protocol:

   Client   sends "halt"
   VirtualT sends "Ok"
   Client   sends "pc"
   VirtualT sends "27105\n"
   VirtualT sends "Ok"
   Client   sends "radix 16"
   VirtualT sends "Ok"
   Client   sends "wr pc=0x69e2"
   VirtualT sends "Ok"
   Client   sends "run"
   VirtualT sends "Ok"

Async Events

Occasionally VirtualT needs to send a message to the client to indicate an event has occurred. Reporting of asynchronous events follows a standard format so they can be parsed by the client application and properly separated from the expected response messages. The format for async event reporting is as follows:

   event, event_name, event_data \n

The async events reported by VirtualT 1.0 are:

   event, break, PC=address     Indicates a breakpoint was encountered
   event, lcdwrite, (r,c),data  Reports data written to the LCD at (r,c) 

Debugger

The socket interface works with the integrated debugger to provide remote debug control over the VirtualT emulation. Using this interface, the 8085 CPU can be halted, single stepped and resumed, breakpoints can be set and / or cleared, and all register and memory can be read and written.

The debugger allows breakpoints to be set for any memory address in the CPU's 64K address range. An unlimited number of breakpoints can be defined. Each breakpoint can be defined to cause a break in CPU execution depending on the active ROM and/or RAM bank of the emulation. Bank selection that should be monitored by the debugger is established during the set_break command.

Breakpoints can also be configured to monitor read and/or write access to specific addresses. To monitor an address for read or write operations, send a set_break command specifying the address with "read" and/or "write" parameters.

To perform debug operations, the integrated debugger must interogate the Program Counter (PC) before excution of every instruction to determine if an active breakpoint has been encountered. When a breakpoint is encountered, the debugger will halt the CPU execution and send an Async Event to the socket interface.

LCD Monitor

The socket interface provides a feature to monitor data sent to the LCD. This feature was added to help accomodate automated regression testing of VirtualT features and applications developed using VirtualT as the development platform.

During LCD monitoring, the integrated debugger is used for monitoring program execution to trap function calls made to the "Character Level 6 Plotting" routine. When a call to this routine is detected, VirtualT extracts the plotted character and the curent row and column position. This data is then used to build strings of data representing the data written to the LCD.

The LCD monitoring feature can be turned on or off using the lcd_mon command. Sometimes during LCD monitoring, it is desireable to ignore portions of the LCD to eliminate excessive socket messages for data that is written repetitively, such as time and date updates on the MENU. To accomodate this, the user can define up to 10 "ignore regions" using the lcd_ignore command. During LCD monitoring, the socket interface will discard any write operations when the curent row and column are bounded by one of the ignore regions.

Commands

VirtualT accepts commands on the socket interface to control emulation options, access low-level hardware resources, and interface with the VirtualT debugger. For commands that accept an address argument, addresses can be represented in decimal format or in hex format by pre-pending with the standard C "0x" syntax, such as 0xA31. Addresses can also be specified by one of the 16 bit registers (pc, sp, bc, de, hl). The commands that VirtualT supports are:


clear_break (cb)


cold_boot


debug_isr (isr)


dis

x


flags


halt


help


in


key


lcd_ignore (li)


lcd_mon (lm)


list_break (lb)


load


optrom


out


radix


read_mem (rm)


read_reg (rr)


reset


run


set_break (sb)


speed


status


step (s)


step_over (so)


string


terminate


write_mem (wm)


write_reg (wr)