Add RetroShell as a serial port device

[dirkwhoffmann]

Add RetroShell as a serial port device

[dirkwhoffmann]

With the latest code changes, RetroShell can be used inside a Terminal program such as A-Talk III (unlike the type ser: solution, there are no buffering issues, and communication is possible with high baud rates).

Important:

• Set handshake to none.
• Select half-duplex mode.
• Press Ctrl+Return to send a command to RetroShell.

There are some caveats, though:

• Some commands, such as amiga power off will crash the emulator. That is because RetroShell commands are expected to be executed within the GUI thread. The RetroShell commander executes the commands within the emulator thread which causes issues with several commands such as all commands that trigger a state change. The emulator will run into an assertion checking the thread type. This will not change until vAmiga 3.0, which will utilize the new code architecture currently being developed for VirtualC64.

• Terminal emulation is not perfect. For example, typing a backspace in A-Talk III will not result in a backspace inside RetroShell. As a result, correcting typos when entering commands is impossible. Furthermore, RetroShell's clear command does not clear the terminal.

Summing up:

• The main goal has already been achieved: Providing the means to turn warp mode on and off from within the emulator.
• Everything else is more of a fun project we can work on later during some dull, rainy days.

[dirkwhoffmann]

Another possibility would be to merge the RetroShell viewer and the RetroShell commander into a single device and to use a unique character to enter command mode.

As this is all about retro, we could use the ASCII character 16 (DLE, Data Link Escape). Once this character is detected, transmitted bytes are no longer just displayed in RetroShell but typed in. Command mode will be reset to text mode on the following line.

[wepl]

dle.zip
attached a dle command which prints the argument prepended with a DLE

[dirkwhoffmann]

Unfortunately, I didn't find a way to echo the DLE character in Amiga DOS. There seems to be no way to specify an ASCII character by number inside a string, which would make the special character approach tedious to use.

If some Amiga DOS expert knows a solution, please let me know.

[wepl]

I think there is no way to create a DLE char with the standard tools.
But it would be easy to create a command which outputs it or prepend the output with a DLE.
On 1.3 you anyway need the Echo command to print something.

[dirkwhoffmann]

Thinking more deeply about the available options, I think the dual-device approach is superior. That is because I want to let the Commander send back the RetroShell output to the Amiga eventually, which the viewer (sniffer) should never do. In particular, the two devices will behave as follows:

• Sniffer
  Listens to the serial port and displays all incoming and outgoing bytes in RetroShell. This is the same as the Port inspector panel does in the Mac app, just inside RetroShell.

• Commander
  The commander types all outgoing bytes into RetroShell and executes the command when \n is received. Eventually, it will send the RetroShell output back to the Amiga through the serial port (I will have to expand the UART class accordingly).

The important part of the Commander is already implemented (but still needs to be ported over to vAmigaWeb).

In the Mac app, plug in the Commander into the serial port:

In Kick 3.0 (which allows ser: to be addressed directly), send a RetroShell command simply via echo (no special characters needed):

With the Commander plugged in, the command is executed inside RetroShell:

With the Commander plugged in, you have complete control over the emulator. You can enable or disable warp mode as you like or anything else.

[dirkwhoffmann]

Sending RetroShell output to the Amiga also works (in the lower window, I've typed in type ser:) :

There are two issues left:

• The known buffering problem. The Amiga buffers incoming data. We need to find out if a flush signal can be sent. Currently, I am not aware of anything like that.
• More severely, I've experienced two Gurus while testing. My current code might be able to bring the UART to an inconsistent state. More investigation is needed.