AspeQt: Yet another SIO2PC/APE clone

[sloopy]

hope to be able to test a new version soon... looks very nice...

 

sloopy.

[a8isa1]

@HiassofT and sloopy:

As I said before the high CPU usage is currently intentional, but shouldn't freeze anything. But see below...

 

@HiassofT:

Okay, I was fiddling with the atari file system stuff but I must admit it's way more interresting I did some quick tests with atarisio, and it works very well. The API is clean and simple and the source code and readme is very informative. Truly impressive package! Only if someone had written a similar open source driver for Windows!

 

So I decided to change my priorities. Currently I'm refactoring the code to make different backends possible. So the next release will hopefully support atarisio. I'm also rewriting the Windows serial port in the process to use WaitCommEvent, so the CPU load won't be a problem in the next release. I'll probably leave the Linux code as it is for now, except the atarisio support. So, back to work

 

Thanks everybody for feedback!

wow!

 

New revisions are coming faster than I can test the old ones!

 

3X SIO speed is now quite good though slows some with system load. (My being only able to use an antiquated Athlon 950mhz system doesn't help).

 

oh! I just realized that drag and drop works! Love it! Executables, ATRs, and folder images all work. Terrific!

 

drag and drop for disk swapping as well

 

Thanks cyco130!

Edited December 19, 2009 by a8isa1

[HiassofT]

@HiassofT and sloopy:

As I said before the high CPU usage is currently intentional, but shouldn't freeze anything. But see below...

Yes, I know, but I was wondering why the USB adapter didn't show the high load. I straced both versions and I guess I found the answer:

 

strace with serial port:

[pid 28766] 1261224384.915012 ioctl(12, TIOCMGET, [TIOCM_DTR|TIOCM_RTS|0x4000]) = 0
[pid 28766] 1261224384.915030 sched_yield() = 0
[pid 28766] 1261224384.915047 ioctl(12, TIOCMGET, [TIOCM_DTR|TIOCM_RTS|0x4000]) = 0
[pid 28766] 1261224384.915066 sched_yield() = 0
[pid 28766] 1261224384.915083 ioctl(12, TIOCMGET, [TIOCM_DTR|TIOCM_RTS|0x4000]) = 0
[pid 28766] 1261224384.915102 sched_yield() = 0
[pid 28766] 1261224384.915118 ioctl(12, TIOCMGET, [TIOCM_DTR|TIOCM_RTS|0x4000]) = 0
[pid 28766] 1261224384.915137 sched_yield() = 0

 

strace with USB adapter:

[pid 28799] 1261224431.381250 ioctl(12, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
[pid 28799] 1261224431.382218 sched_yield() = 0
[pid 28799] 1261224431.382249 ioctl(12, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
[pid 28799] 1261224431.383225 sched_yield() = 0
[pid 28799] 1261224431.383257 ioctl(12, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
[pid 28799] 1261224431.384216 sched_yield() = 0
[pid 28799] 1261224431.384285 ioctl(12, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
[pid 28799] 1261224431.385226 sched_yield() = 0

 

The ioctl takes less than 20 usec with the serial card but almost 1 msec with the USB adapter. I guess during the USB code must be putting the process to sleep while waiting for some event (or something similar), therefore the larger delay and lower load. OTOH the serial code returns immediately and one CPU core is busy-polling the status lines.

 

BTW: I compiled my kernel with HZ=1000, so the ioctl every 1ms could also have something to do with the kernel timer tick frequency. I'll re-check this with another kernel compiled with HZ=250, this could also have an impact on USB adapter performance/reliability.

 

Okay, I was fiddling with the atari file system stuff but I must admit it's way more interresting I did some quick tests with atarisio, and it works very well. The API is clean and simple and the source code and readme is very informative. Truly impressive package! Only if someone had written a similar open source driver for Windows!

Thanks a lot!

 

so long,

 

Hias

[HiassofT]

BTW: I compiled my kernel with HZ=1000, so the ioctl every 1ms could also have something to do with the kernel timer tick frequency. I'll re-check this with another kernel compiled with HZ=250, this could also have an impact on USB adapter performance/reliability.

Just tried my old 2.6.31 kernel with HZ=250, performance was identical to 2.6.32 with HZ=1000 and the ioctls also occurred every 1ms.

 

So forget about this, it was just me being curious again :-)

 

so long,

 

Hias

[cyco130]

@HiassofT:

Hmm, it must be the USB driver having to communicate with the device to get the line status.

 

@all:

I just rewrote the Windows serial I/O backend. It's much faster now, much faster than Atari 810 and almost as fast as APE, and it doesn't hog the CPU anymore: 0% load when iddle . I didn't commit the changes because the current code wouldn't compile under Linux. Now I should rewrite the Linux one too but unfortunately my day job got in the way so it will be a little later than I originally thought

[cyco130]

Hi,

 

AspeQt 0.2 is just released. You can download it here.

 

Admittedly, it's a bit rushed because I won't be available for a while. So don't expect anything more than beta quality. I would have liked to add the image explorer feature, a better exe booter and folder images that permit more than loading a file but I didn't have enough time. Coding doesn't take much but testing is a real pain I decided to release it anyway because there are some serious changes:

 

On Windows:

The I/O speed and reliability is now on par with APE and much better than Atari810. The CPU load problem is gone too. I encourage everyone to upgrade because it's now much faster when doing 3x I/O.

 

On Linux:

AspeQt now supports AtariSIO as an optional backend. It's not as good as it can be yet but it's much better than the standard serial I/O backend. Just go to the Tools/Options and change the backend. The maximum speed is fixed at 3x for now. (The kernel driver is not included, please download and install version 091124 from hiassoft's web site).

 

The standart serial I/O is about the same: Still high CPU load and slow when writing, but should be just a bit faster. I tried to do better but no luck this time. Thanks a lot to hiassoft for helping at this.

 

In general:

Now there is a source release too. I encourage everyone to download the source release or revision 9 from the SVN. Later revisions (they don't exist yet) may not even compile so don't complain, it suits my workflow better

 

I did fix some minor bugs but I rewrote some major parts of the software so I may have inadvertedly introduced more. Please report any issues you encounter!

 

Thanks in advance for feedback!

 

PS: I did all my tests with a stock Atari 800XL, a homemade SIO2PC cable with RI handshaking and following software: Dos 2.0s vanilla, Dos 2.5s vanilla (it has slightly different timing because it has its own SIO interrupt routines), Dos 2.0s + hiassoft's hisio.com, Dos 2.0s + APE Warp patch, TurboDos 2.1 happy/speedy version and SpartaDos 3.2g. On the PC side I used Windows XP SP3 and Ubuntu 9.10, both with latest updates on a single core 32-bit only Pentium 4/2000. So I'm very interrested in other configurations!

[ascrnet]

hi cyco130,

 

Thanks for your program aspeqt, I liked the option to run a .xex directly.

 

I have a question, I have a cable with the chip sio2pc but DS1489AN program only runs at 1x me what can be?

 

Greetings

[cyco130]

Hi ascrnet,

 

Thanks for your interest!

 

If you're refering to the executable booter, it has no high speed SIO routine, so 1x operation is normal. It's on

my to do list so future releases will hopefully support this.

 

If the program never switches to 3x then make sure that:

 

* The maximum speed is set to 3x from the Tools/Options dialog.

* You're using a high speed capable DOS or OS patch on the Atari.

* Your cable runs fine with other software (like APE or AtariSio).

 

If all of the above are ok than it is probably a bug on my part. Do you see any error messages when the code tries

to switch to 3x?

 

PS: I'll be releasing a new version before new year, so, everybody, please ignore the GUI disk swap bug and AtariSio

error messages for now. They're mostly harmless.

[candle]

Fatih,

one annoyance i have to report:

when you mount folder, atari dos will always report content as it was when the folder was mounted, disregarding it current state

ie if you add files, you have to "eject" it and then remount to see any changes

[cyco130]

Fatih,

one annoyance i have to report:

when you mount folder, atari dos will always report content as it was when the folder was mounted, disregarding it current state

ie if you add files, you have to "eject" it and then remount to see any changes

 

Will be fixed in the next release (tomorrow, or the day after tomorrow), thanks for the report. The thing is, "folder image" feature is currently very simplistic, intended for just loading a program etc., hopefully the new release will have an image explorer so you can drag and drop files in and out of a disk image (AtariDos/MyDos file system for now, SpartaDos will follow later). In the future I plan to reuse that file system code to provide a better folder image solution, including write access.

[candle]

Another thing, SDX v 4.43 reports 148 - unknown file system when accessing mounted directory

[cyco130]

Another thing, SDX v 4.43 reports 148 - unknown file system when accessing mounted directory

 

Will be fixed in the next release too The reason is that folder images don't emulate the VTOC and boot sectors.

[jdh]

Great work, and thanks for releasing the code!

 

Builds and runs fine on Linux Mint Gloria.

[+Stephen]

Another thing, SDX v 4.43 reports 148 - unknown file system when accessing mounted directory

Is version 4.43 available to the public yet? I checked over at trub and all I saw was version 4.42.

 

Stephen Anderson

[cyco130]

Hi,

 

AspeQt 0.3 is now available here.

 

I was supposed to release it before new year but, well, I couldn't

 

Here is a list of changes, note that most features are poorly tested:

 

* AspeQt is now useful even without an SIO2PC cable, because it has now an image explorer. You can view, extract/insert files and folders using drag and drop with optional text conversion (currently unix style text files only), rename and delete files. Currently it only supports Atari Dos derivatives including Dos 1.0, Dos 2.0s, Dos 2.0d, Dos 2.5 and MyDos. It can detect the proper file system in most cases and but it also lets you override it but I wouldn't count on write support if it can't detect the file system but reading should be fine. I wouldn't count on the error handling either. An issue is that dragging out of an image maybe somewhat slow with deep directory trees.

* SpartaDos images are detected correctly but can't be viewed yet. Future releases will add support for this too.

* Slightly better folder images. Issues reported by candle should be gone. The image explorer feature is actually an experiment that allows me to observe disk usage patterns of some DOSes so I can improve the folder images.

* Support for 512 bytes/sector ATR images. It assumes that the first three sectors are full sized. (Totally untested because I still don't have SpartaDos X)

* AspeQt now rejects most malformed image files instead of interpreting it incorrectly.

* Disk images are now mounted using a temporary file. So you now have the option to save or discard the changes. You can also save with another name or format. The up sides are obvious, the down side is mounting big images may take some time. If anyone objects to this I will add an option to mount ATR and XFD images directly.

* Raw and gzipped image file support is temporarily dropped. I rewrote the image handling back end and I was just too lazy to reimplement it. It will be back with the next release, along with support for SCP, DCM and DI formats. The new "save as" feature will effectively enable you to convert between different formats.

* Lots of small GUI changes and bug fixes. Most features are now accessible by right clicking a disk slot.

 

There are many changes which means that there are litterally a hundred things that could go wrong. I'm very interrested in hearing about any bug reports and feature requests.

 

Thanks to everybody for feedback!

[flashjazzcat]

Brilliant - gonna try it right now. Thanks!

[drac030]

Is version 4.43 available to the public yet? I checked over at trub and all I saw was version 4.42.

 

No, it is not yet finished.

[cyco130]

D'oh!

 

Version 0.3 had a nasty bug in the image explorer that caused crashes under some circumstances. I hope nobody lost any data because of this.

 

Version 0.4 is available here. I urge everyone to upgrade.

 

As an apology, the image explorer now has read-only SpartaDos filesystem support, including 512 bytes/sector ATRs. Write support will follow. Many thanks to drac030 for providing me with some example ATRs.

 

Thanks to everybody for feedback!

Edited January 7, 2010 by cyco130

[flashjazzcat]

Absolutely love the new image explorer. Really handy to drag and drop a freshly compiled XEX file onto a mounted ATR. Aspeqt is the biggest productivity boost since WUDSN.

 

I do find that the latest version always crashes on closing in Win 7, however.

Edited January 7, 2010 by flashjazzcat

[cyco130]

Absolutely love the new image explorer. Really handy to drag and drop a freshly compiled XEX file onto a mounted ATR. Aspeqt is the biggest productivity boost since WUDSN.

 

I do find that the latest version always crashes on closing in Win 7, however.

 

Thanks for the report!

 

I wasn't able to reproduce it in my brothers laptop with Windows 7. Right now I'm doing a major code cleanup and adding a logfile feature so I can see what's going on in case a crash occurs.

 

Meanwhile please try the following:

* Check the process list under Windows task manager if any previous instances of AspeQt is in a deadlock or something.

* Remove any files and folders starting with aspeqt in your temporary folder, there should be plenty if it crashed a couple of times. I suppose under Windows 7 it's named C:\Users\{User name}\AppData\Local\Temp where {User name} is your user name.

* If the above doesn't help, remove the HKEY_CURRENT_USER\Software\TrayGun Software\AspeQt registry key (and its contents). It will cause AspeQt to forget its settings, mounted images and recent images.

* Otherwise, go back to version 0.3 for now but don't use image explorer subdirectories, they are buggy.

 

Sorry for the inconvenience, too much late night coding brings too much bugs and messy, hard to debug code. I will clean up everything before adding any new features.

[cyco130]

Hi,

 

It's been a while since the last update because I was somewhat busy.

 

AspeQt version 0.5 is now available, you can download it here.

 

Apart from the usual bug fixes - one was especially nasty and I believe it was the one causing flashjazzcat's troubles but I'm not sure - here are some of the new features:

 

• 
   
  
• Higher speeds than x3 (57600) can be achieved if the serial port adaptor supports them
  Go to the options menu and check "Use non-standard speeds" and select the Pokey divisor. Lower means faster, 8 is the same as 3x and 0 is approximately 6x. If your serial port adaptor and DOS supports it, you may go up to divisor 0. Only tested with a ft232r based adaptor (see below for details). I'm not sure if it will work with 16C950 based ports.
  
• New EXE booter with optional high speed SIO routines and drag-drop support for files with EXE, COM and XEX extensions
  Just drop an EXE into any slot. Autoboot dialog will appear. The boot code is changed but it's a bit experimental. So expect some compatibility issues. The high speed option can be selected under Options/Emulation. The high speed code is courtesy of hiassoft (see below) but don't blame him if anything goes wrong. I litterally butchered his code
  
• Preliminary printer emulation
  No printing yet. But you can view and save the printer text output to a file. It's under File/View printer text output.
  
• Text conversion for image explorer is now working properly under Windows
  It will use proper CR/LF pairs instead of Unix-style CR only for line endings.
  
• Old temporary files resulting from crashes are now removed when AspeQt starts
  It may slow down your first start if AspeQt crashed a lot before this release.
  
• Log file
  It will create a file named aspeqt.log in your temporary folder. I hope it will help me inspect crashes more deeply.
  

 

I want to thank candle for donating one of his awesome I/O boards. It is now partially supported by AspeQt. I couldn't keep all my promises yet though, synchronous transfer is not yet supported. But I did many tests and results are promising. In the near future I hope that AspeQt will be breaking speed records using synchronous I/O. I'll discuss my tests in another thread but 480000 bps seems very doable.

 

I also want to thank HiassofT, not because of his endless knowledge but because he's kind enough to share it unselfishly. He even got his hands dirty and provided a patch that enabled Linux backend to go up to POKEY divisor 0 with a suitable serial port adaptor

 

One more surprise for the next release: A polish fellow named Krzysztof Pyrkosz offered to translate AspeQt to Polish. I'm not sure if he's a member here but I would be surprised if he isn't. So, hi there

 

And thanks everybody for testing, bug reports, feature requests etc. I'm looking forward for more, let's see what I screwed up this time

 

edit: spelling.

Edited January 29, 2010 by cyco130

[cyco130]

Hi,

 

I've put together a quick and dirty user manual for AspeQt. It's available here.

 

I know it isn't much but it's a start and, hopefully, still useful.

[ascrnet]

Hi,

 

I've put together a quick and dirty user manual for AspeQt. It's available here.

 

I know it isn't much but it's a start and, hopefully, still useful.

 

hi cyco130,

 

Thanks for the manual ASPEQT although it is not difficult to use but never the other.

 

I guess I will soon be able to use the files. Cas?

 

Greetings

Edited January 30, 2010 by ascrnet

[Syfo-Dyas]

QT Based you say? So in theory this could be ported to Haiku (BeOS), provided we had hardware drivers for the various devices as well...?

Edited January 31, 2010 by Syfo-Dyas

[cyco130]

I guess I will soon be able to use the files. Cas?

 

I hope so, please stay tuned

 

 

QT Based you say? So in theory this could be ported to Haiku (BeOS), provided we had hardware drivers for the various devices as well...?

 

In theory yes. In practice that would require:

* Properly functionning Qt 4.6 libraries and build tools for Haiku.

* UART (and maybe FTDI) drivers. I can imagine Haiku lacking FTDI drivers but I would be very surprised if it doesn't have a UART driver.

* A Haiku expert with a decent knowledge of Qt and Haiku serial port APIs and enough interest and free time.

 

I myself know next to nothing about Haiku/BeOS but would do my best to help anyone attempting to make it happen.