ebiguy / respeqt Goto Github PK

RespeQt could benefit from a decent emulation of the 850 (accurate) as well as a slightly differently styled R: device which takes advantage of the features of a modern computer to implement a better emulated device than the 850 was.

The 850 emulation objective is very straightforward: develop an emulated SIO device which works as close to the way the original 850 worked as possible.

The other generic R: device, would instead deviate from the 850 styled emulation. It would actually use the SIO protocol, rather than the 850 style 'concurrent mode'. Data would be received and sent by issuing SIO requests. This device could support high speed SIO, thus allowing higher bitrates as well. This would allow actual handshaking changes during transmission without exiting 'concurrent mode' since there would be no 'concurrent mode' in the sense that the 850 has. This would also allow 'simultaneous' disk access. In addition, provided the SIO2PC device used supports it, this could potentially make use of the interrupt and/or proceed lines of the SIO interface in order to notify the SIO host that data is ready to be sent to the host, or that the device is now ready to receive more data from the host.

When clicking and dragging a disk image from one drive slot to another, CPU usage spikes up from ~0% (idle) to nearly 100% and remains spiked until mouse button is released. As this occurs, mouse movement is sluggish and affects cursor precision during drag/drop. This doe not appear to affect basic functionality but does affect ease of use.

The first time it is used, RespeQt tries to import settings from AspeQt if the latter was used before RespeQt is installed. It does however import ALL settings, whether they are relevant to RespeQt or not, causing bloat and confusion in the registry entries.

RespeQt does not delay between command acknowledge response and operation complete response when used with FTDI usb to serial device. The issue is caused by tcdrain which does not wait for the FTDI chips buffer to be empty, only the OS buffer. As a result, the transmit buffer is not empty when when the operation complete response is sent 300 microseconds later. This byte is added to the transmit buffer of the FTDI device. It is sent immediately after the Acknowledge Command response even though the minimum time between the two needs to be at least 250 microseconds or the Atari computer might miss the response and retry the operation after a long delay.

A temporary fix is to increase the delay between the Acknowledge Command response and the Operation Complete response by approximately the time it requires to send one byte (about 500 microseconds at 19200 baud). The same modification should be performed to the Operation Error response delay as well.

It is not clear whether tcdrain should wait for the hardware device's transmit buffer to be empty before returning, or not. The FTDI USB to serial device reportedly does return empty/not-empty status for the transmit buffer. I will attempt to work with the FTDI driver maintainer(s) to have tcdrain wait until the hardware buffer is empty as well within the FTDI device driver.

I initially only installed the Qt 5.7 toolkit.
The generated UI code, references the wrong headers, for example.
I could build the application, by changing all the culprits. But after changing the UI, I anticipate to do it all over again.
For future proofing, this should be changed.

RespeQt has simple printer emulation which also allows translation from ATASCII to ASCII. This emulation seems to work well. Support for specific printers is possible. There are three distinct types of printers which could be emulated: text, raster-graphics, and plotting printers. In addition, printing to file should be emulated, in both raw and translated output formats. On linux and possible OSX, this alone would allow printing to a real printer, depending on the printer's configuration. On windows, more support will likely be necessary before printing directly to a real printer would be possible.

Atari released a number of text only printers, from the 820, to the 1029, and the XDM121, etc. Some of these printers were direct connect SIO printers which actually 'spoke' SIO and allowed different printing styles specified in the command via, for example, the two auxiliary bytes. Others were generic repackaged printers which were either barely SIO, or not SIO at all (such as the 825). These support certain escape sequences to change the type style.

Atari did not release any raster-graphics printers for the 8 bit computers, to my knowledge. If this is wrong, correct me. However, it was not uncommon for other graphics capable printers to be used on the Atari via a Centronics port adapter. One such printer was the Epson MX-80, and other ESC/P command set printers. These should be possible to emulate. For output format, PDF may work. Otherwise, simple image formats may work.

Lastly, Atari released the 1020 plotter-printer which printed by drawing with a pen. It allowed text to be drawn by a built in font, as well as allowing drawing by various escape sequences. The output format for this printer could be .svg.

'Viewers' for the non-text printers may be more complex. As a start, file output for the raster graphics and plotting printers could be the only option, for the sake of simplicity and for proving the feature.

When an .xex file is loaded with "Use high-speed loader" option selected, and with SOFTWARE Handshaking ON, Write Delay 0, using a wired SIO2PC, the loader performance suffers. In fact the speed is actually much lower compared to when "Use high-speed loader" option is de-selected.

Which Atari OS is used does not matter.
The test has been done on Marcin's BT enhanced AspeQt v0.8.8, but also applies to Respeqt unless the problem has already been found and dealt with.

When I close RespeQt on OSX, I get a crash dialog from the os.
I run it on OS X 10.11 (El Capitan).

RespeQt supports the AspeCl 'server device' which allows the user to change ATRs from their Atari within a DOS, retrieve time from the computer over, etc. The tool to do this, originally from AspeQt, is ASPECL.COM. The source for this tool has not been located, and may not be available. Since the protocol is documented within the AspeQt source, it is possible to make an open source replacement rather easily for someone experienced in writing programs for the Atari which access the SIO. This is one possible solution. The other solution is for someone to locate the AspeCl source, and this can be included with RespeQt.

to change the language in the options is not changed. automatic option works only.

Sadly I never used the feature in years of mounting a folder. But better late than never I just played around this helpful feature, but can't change the folder boot options... I right-click at folder's image, select one of the presented DOSes, click ok, boot up my XE - and see lots of boot errors. When I re-check this setting it is still sitting at AtariDOS 2.x and neither this or other DOSes gets copyied to the mounted folder.

The defaults for RespeQt result in an application binary build that places the application menus inside the RespeQt window itself. The OS X user interface guidelines generally place the application menus at the top left of the screen in the system Menu Bar when that application is the foreground program. RespeQt can be built for OS X such that its menus integrate "properly" with OS X in this way by clicking a single button in Qt Creator during the build process:

The log text box, textEdit, does not resize when the main program window resizes. Other widgets resize properly.

I was getting "Cannot set DTR and RTS lines in serial port" error opening the serial port.
Those don't normally need to be set, but commenting that out resulted in a "Cannot set serial port speed to 19200" error.
I dug around port init on the net (I'm not experienced on Linux) and found that CLOCAL and CREAD need to be set using tcsetattr().
In StandardSerialPortBackend::open() after the port is opened I added code to set those as well as turning HW flow control off.
It works now.
I can copy/paste if you wish.
Bill

RespeQt currently supports DOS 2 folder imaging. SDFS is not supported. This feature should be possible, it has been done in the Altirra emulator.

VAPI ATX format is a format for Atari disks which allows protection mechanisms to be recorded and emulated. RespeQt currently has no built in ATX support.

Some users are experiencing issues loading certain ATRs.

First user:

• using a non-stock OS, Omniview 256.
• provided one example of a problem ATR
• expressed that the issue has been present since AspeQt versions.
• has been asked which platform (windows/linux/osx)

Second user

• has been asked to provide a problematic ATR
• has been asked if there are ATRs which work without issue
• user is using OSX