570 replies to this topic

[cyco130]

Hi,

I'm working on a peripheral emulator based on Qt. It's free and open source.
It will be greatly appreciated if anyone can give it a go and inform me.

It's in beta stage and not all features are throughly tested yet.

Here's the link: Download AspeQt

Windows version is already there and Linux version will be available in about half an hour.
edit: It's now there

Some features:

* Qt based GUI with drag and drop support.
* Cross-platform (currently Windows and x86-Linux, but it should be very easy to port it to MacOsX)
* 8 disk drive emulation
* Folders can be mounted as simulated Dos20s disks. (read-only, at least for now)
* Atari executables can be booted directly.
* Support for gzipped disk images. DCM and SCP support are on the way.
* Support for APE time downloader.
* 1x, 2x, and 3x SIO.

3x speed doesn't work reliably with all OSes/DOSes. But I had great results with SpartaDos 3.2g.
SpartaDosX user feedback will be greatly appreciated. (I don't have one, yet)

To do:

* PseuDos (A virtual DOS that can access PC files, in a controlled manner)
* Support for some Happy and XF551 commands
* Printer emulation
* Cassette emulation
* DCM and SCP support
* Disk image converter
* Disk image explorer
* SpartaDos/MyDos support for folder images
* Write support for folder images

Here's the Windows screenshot for completeness :

Edited by cyco130, Tue Dec 15, 2009 3:09 AM.

[Rybags]

Done - I'll try and give it a go at some stage.

Any prerequisites needed like C++ Libs, .net or any crap like that?

[cyco130]

Rybags, on Tue Dec 15, 2009 3:05 AM, said:

Done - I'll try and give it a go at some stage.

Thanks a lot

Rybags, on Tue Dec 15, 2009 3:05 AM, said:

Any prerequisites needed like C++ Libs, .net or any crap like that?

For Linux, you'll need the latest Qt libraries but you probably already have them.

For Windows, required Qt and mingw DLLs are in the zip file. It should work out of the box.

[HiassofT]

Is the source code available? I could only find executables on the sourceforge site.

I tried it on my Debian Lenny AMD64 box, the configuration dialog came up fine but then aspeqt crashed:

symbol lookup error: ./aspeqt: undefined symbol: _ZN7QThread18yieldCurrentThreadEv

so long,

Hias

[cyco130]

HiassofT, on Tue Dec 15, 2009 9:54 AM, said:

Is the source code available? I could only find executables on the sourceforge site.

I tried it on my Debian Lenny AMD64 box, the configuration dialog came up fine but then aspeqt crashed:

symbol lookup error: ./aspeqt: undefined symbol: _ZN7QThread18yieldCurrentThreadEv

so long,

Hias

It's probably complaining about missing/incompatible Qt libraries.

The source code is available under GPL but I didn't provide a source package yet, sorry for that,
I'll do it for the upcoming versions. Meanwhile you can check out the sources via SVN from
sourceforge. You may need Qt Creator to build.
I wonder how it will do under AMD64.


Thanks for your interest

edit: No need for svn, apparently sourceforge can create a tar.gz archive: aspeqt.tar.gz
just run qmake followed by make. It should do it if you have the necessary tools...

Edited by cyco130, Tue Dec 15, 2009 10:37 AM.

[HiassofT]

cyco130, on Tue Dec 15, 2009 10:23 AM, said:

It's probably complaining about missing/incompatible Qt libraries.

The source code is available under GPL but I didn't provide a source package yet, sorry for that,
I'll do it for the upcoming versions. Meanwhile you can check out the sources via SVN from
sourceforge. You may need Qt Creator to build.
I wonder how it will do under AMD64.

Thanks for the link (I guess I didn't look close enough first).

I grabbed the current svn version, ran qmake and make, and got an error about yieldCurrentThread being not declared:

g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -o sioworker.o sioworker.cpp
sioworker.cpp: In member function 'virtual void SioWorker::run()':
sioworker.cpp:102: error: 'yieldCurrentThread' was not declared in this scope
make: *** [sioworker.o] Error 1

Debian Lenny ships with qt 4.4.3, and according to the qt docs the yieldCurrentThread method is available since qt 4.5. So my libraries are too old...

so long,

Hias

[cyco130]

HiassofT, on Tue Dec 15, 2009 2:54 PM, said:

Thanks for the link (I guess I didn't look close enough first).

I grabbed the current svn version, ran qmake and make, and got an error about yieldCurrentThread being not declared:

g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I. -o sioworker.o sioworker.cpp
sioworker.cpp: In member function 'virtual void SioWorker::run()':
sioworker.cpp:102: error: 'yieldCurrentThread' was not declared in this scope
make: *** [sioworker.o] Error 1

Debian Lenny ships with qt 4.4.3, and according to the qt docs the yieldCurrentThread method is available since qt 4.5. So my libraries are too old...

so long,

Hias

If you're still motivated you can change the offending line to:

msleep(1);

just to see if it works. By the way your hisio.com works with 3x speed to

Edited by cyco130, Tue Dec 15, 2009 3:15 PM.

[Urchlay]

cyco130, on Tue Dec 15, 2009 10:23 AM, said:

I wonder how it will do under AMD64.

First attempt to compile, it's failing with common errors you get with "non-64bit-clean" code:

moc_mainwindow.cpp: In member function 'virtual int MainWindow::qt_metacall(QMetaObject::Call, int, void**)':
moc_mainwindow.cpp:245: error: invalid conversion from 'int' to 'MessageType::UiMessageType'
moc_mainwindow.cpp:245: error:   initializing argument 2 of 'void MainWindow::uiMessage(QString, MessageType::UiMessageType)'

On 32-bit platforms, MessageType::UiMessageType is probably a typedef for int, and on 64-bit it's something else (long, maybe), so this code will compile for 32-bit but not 64-bit. Either that, or my version of g++ is being stricter about type conversions than yours (what version have you got? Mine's 4.3.3)

The fix is, change line 245 of moc_mainwindow.cpp to look like this:

		case 60: uiMessage((*reinterpret_cast< const QString(*)>(_a[1])),(*reinterpret_cast< MessageType::UiMessageType(*)>(_a[2]))); break;

After fixing that, I get similar type mismatch errors in moc_serialport.cpp, and after fixing those, more in moc_sioworker.cpp...

I'll send you a patch, when/if I get it to compile successfully on x86_64.

[cyco130]

Urchlay, on Tue Dec 15, 2009 3:13 PM, said:

cyco130, on Tue Dec 15, 2009 10:23 AM, said:

I wonder how it will do under AMD64.

First attempt to compile, it's failing with common errors you get with "non-64bit-clean" code:

moc_mainwindow.cpp: In member function 'virtual int MainWindow::qt_metacall(QMetaObject::Call, int, void**)':
moc_mainwindow.cpp:245: error: invalid conversion from 'int' to 'MessageType::UiMessageType'
moc_mainwindow.cpp:245: error:   initializing argument 2 of 'void MainWindow::uiMessage(QString, MessageType::UiMessageType)'

On 32-bit platforms, MessageType::UiMessageType is probably a typedef for int, and on 64-bit it's something else (long, maybe), so this code will compile for 32-bit but not 64-bit. Either that, or my version of g++ is being stricter about type conversions than yours (what version have you got? Mine's 4.3.3)

The fix is, change line 245 of moc_mainwindow.cpp to look like this:

		case 60: uiMessage((*reinterpret_cast< const QString(*)>(_a[1])),(*reinterpret_cast< MessageType::UiMessageType(*)>(_a[2]))); break;

After fixing that, I get similar type mismatch errors in moc_serialport.cpp, and after fixing those, more in moc_sioworker.cpp...

I'll send you a patch, when/if I get it to compile successfully on x86_64.

Thanks a lot. I have already fixed them in the local version. I'll commit them now, I just didn't expect any 64-bit feedback yet

[HiassofT]

cyco130, on Tue Dec 15, 2009 3:12 PM, said:

If you're still motivated you can change the offending line to:

msleep(1);

Thanks, I tried it but then got another error in moc_messagetype.cpp that my qt install is too old. So I did a local install of the latest qt sdk (4.6/2009-05) and the build went fine.

I just did a quick test with TurboDos 2.1 HS (highspeed version) for now (it's late and I really should go to bed :-):

- reading/writing/formatting works fine, at least at up to 38400bps
- switching baudrates takes quite some time (but I guess you already know this)
- at 57600bps the TurboDos highspeed SIO driver didn't work reliable and I got occasional errors

So: well done - aspeqt works fine, even on 64bit systems!

If you need some more help/testing/whatever just drop me a line.

so long,

Hias

[cyco130]

HiassofT, on Tue Dec 15, 2009 6:54 PM, said:

aspeqt works fine, even on 64bit systems!

Wow! Qt _is_ cool

HiassofT, on Tue Dec 15, 2009 6:54 PM, said:

I just did a quick test with TurboDos 2.1 HS (highspeed version) for now (it's late and I really should go to bed :-):

- reading/writing/formatting works fine, at least at up to 38400bps
- switching baudrates takes quite some time (but I guess you already know this)
- at 57600bps the TurboDos highspeed SIO driver didn't work reliable and I got occasional errors

If you need some more help/testing/whatever just drop me a line.

Turns out both problems were caused by a bug in the serial port handling. Revision 3 in the svn repository should work fine. Thanks a lot for your help!

I removed the binary linux release, it seems that I was too optimistic about binary compatibility between *nixes Linux people should check out the svn or download the sources from here and do a qmake followed by a make until I come up with a better solution.

Windows version isn't affected by the problem and works fine on my 32-bit XP box.

BTW, does anyone know any other GUI based SIO program for linux or is this the first? I couldn't find one and it was the reason that I started this project...

Anyway, thanks again for helping!

[mellis]

cyco130, on Wed Dec 16, 2009 8:09 AM, said:

BTW, does anyone know any other GUI based SIO program for linux or is this the first? I couldn't find one and it was the reason that I started this project...

Anyway, thanks again for helping!

Yeah - I have one called SIO Server that's in beta testing.  

I haven't updated it as often as I would have liked lately, as I've been very busy these last several weeks.  However, things are starting to settle down so I expect to have a new release pretty soon.  Right now, I am primarily testing the Mac OS X version, but the application has been designed to work on all POSIX systems.  Eventually I will get a Linux version released (free-time permitting).

I think it's great that there are SIO2PC choices for Mac OS X and Linux now, and I would encourage you to continue your good work.

[cyco130]

mellis, on Wed Dec 16, 2009 8:16 AM, said:

Yeah - I have one called SIO Server that's in beta testing.  

I haven't updated it as often as I would have liked lately, as I've been very busy these last several weeks.  However, things are starting to settle down so I expect to have a new release pretty soon.  Right now, I am primarily testing the Mac OS X version, but the application has been designed to work on all POSIX systems.  Eventually I will get a Linux version released (free-time permitting).

I think it's great that there are SIO2PC choices for Mac OS X and Linux now, and I would encourage you to continue your good work.

I'm aware of your program but for whatever reason I thought it was Mac OS X only and I don't have a Mac. I'm waiting for your Linux release now to steal some features

[HiassofT]

cyco130, on Wed Dec 16, 2009 8:09 AM, said:

Turns out both problems were caused by a bug in the serial port handling. Revision 3 in the svn repository should work fine. Thanks a lot for your help!

Thanks, svn r3 works better. Switching is faster (shorter "farts" on the Atari) and 57600bps seems to work fine (only did a short test).

BTW: I suggest you remove the qt-generated files (moc_*, qrc_*, Makefile) from svn, and maybe set the svn ignore property. Currently I have to run a "make distclean" before "svn up", otherwise svn wants to merge the changes (and I got another error in the moc* files because now my Qt is too new :-).

Quote

BTW, does anyone know any other GUI based SIO program for linux or is this the first? I couldn't find one and it was the reason that I started this project...

No (except the already mentioned SIO Server).

My AtariSIO software is console-only and I have no plans to implement a GUI for it.

so long,

Hias

[cyco130]

Done! Thanks for the good news and tips!

Now that I know that it runs in one more machine that mine, I can go on adding features for the next release

[HiassofT]

cyco130, on Wed Dec 16, 2009 9:10 AM, said:

Done! Thanks for the good news and tips!

You are welcome!

I just did another (crazy) test: I started VMware Workstation and booted my Debian Sid AMD64 VM. Everything worked fine, up to 56kbps, altough one could hear that the loading was not as clean as when running the app natively (but that's no wonder, the serial port in the VM is emulated and emulation also skews timing).

I have't tested this with VirtualBox or kvm yet, but maybe some other crazy folks might give it a try :-)

Quote

Now that I know that it runs in one more machine that mine, I can go on adding features for the next release

Good luck and keep up the great work!

so long,

Hias

[phaeron]

Very nice.

One issue, though: I tried the win32-0.1 version, and it consumes a lot of CPU at times. Interestingly, it only does this when idle -- it's around 3-5% when actually transferring data.

[cyco130]

HiassofT, on Wed Dec 16, 2009 10:08 AM, said:

I just did another (crazy) test: I started VMware Workstation and booted my Debian Sid AMD64 VM. Everything worked fine, up to 56kbps, altough one could hear that the loading was not as clean as when running the app natively (but that's no wonder, the serial port in the VM is emulated and emulation also skews timing).

I have't tested this with VirtualBox or kvm yet, but maybe some other crazy folks might give it a try :-)

Cool, I never had any chance with virtualization and Sio2Pc programs, including this one. I gotta get myself a new computer

HiassofT, on Wed Dec 16, 2009 10:08 AM, said:

Good luck and keep up the great work!

Thanks, I whish the same for you!

phaeron, on Thu Dec 17, 2009 12:04 AM, said:

Very nice.

One issue, though: I tried the win32-0.1 version, and it consumes a lot of CPU at times. Interestingly, it only does this when idle -- it's around 3-5% when actually transferring data.

Thanks for testing. Currently it is intentional. Although it looks scary to see >90% CPU usage, it repeatedly returns the control to the OS so everything should be as responsive as if it's spending ~1%. But it does interfere with CPU power saving, so your laptop's battery may last less long.

The reason is that the program polls the serial line repeatedly to catch the Atari's commands. I found that polling was much more reliable than using WaitCommEvent in Windows and TIOCMI_WAIT in Linux. I will add an option to use them in the next release (should be next week or so) and probably make it the default. Thanks for the report.

---

Instead of packing the program with features, I decided to create a test suite so I can fine tune the serial port engine. It looks good: Wohoo! APE Warp (the patch, not the OS upgrade, I don't have it) runs reliably now The changes will be in SVN in a couple of hours.

[flashjazzcat]

Thanks for this: working a treat so far with Win7.

[ivop]

cyco130, on Wed Dec 16, 2009 8:09 AM, said:

I removed the binary linux release, it seems that I was too optimistic about binary compatibility between *nixes Linux people should check out the svn or download the sources from here and do a qmake followed by a make until I come up with a better solution.

A solution might be making a static build (i.e. link everything statically). Opera (the webbrowser) does this too (besides creating several .debs/.rpms for the major distro's, but I'll understand if you do not want to bother with that).

[a8isa1]

cyco130, on Tue Dec 15, 2009 2:51 AM, said:

Hi,

I'm working on a peripheral emulator based on Qt. It's free and open source.
It will be greatly appreciated if anyone can give it a go and inform me.

It's in beta stage and not all features are throughly tested yet.

Here's the link: Download AspeQt

Windows version is already there and Linux version will be available in about half an hour.
edit: It's now there

Some features:

* Qt based GUI with drag and drop support.
* Cross-platform (currently Windows and x86-Linux, but it should be very easy to port it to MacOsX)
* 8 disk drive emulation
* Folders can be mounted as simulated Dos20s disks. (read-only, at least for now)
* Atari executables can be booted directly.
* Support for gzipped disk images. DCM and SCP support are on the way.
* Support for APE time downloader.
* 1x, 2x, and 3x SIO.

3x speed doesn't work reliably with all OSes/DOSes. But I had great results with SpartaDos 3.2g.
SpartaDosX user feedback will be greatly appreciated. (I don't have one, yet)

To do:

* PseuDos (A virtual DOS that can access PC files, in a controlled manner)
* Support for some Happy and XF551 commands
* Printer emulation
* Cassette emulation
* DCM and SCP support
* Disk image converter
* Disk image explorer
* SpartaDos/MyDos support for folder images
* Write support for folder images

Here's the Windows screenshot for completeness :

Thanks cyco130!

I'm enjoying your program a lot but I have one question. Is aspeQt compatible with USB to RS232 adapters?

I don't want to sound like a complainer but I noticed that your 3X SIO seems to transfering data at about the speed of 2X SIO of APE (Win9X) and XF551 emulation (2X) of AtariSIO.

For the record I'm using OpenSuse 11.2 on my PC and MyDOS 4.53/4 on an 800XL with a built-in MAX233 based SIO2PC. For high speed SIO I'm using either QMEG 4.04 OS or other OSes and Hias' HISIORI.COM patcher.

- Steve Sheppard

[cyco130]

@flashjazzcat:
Thanks a lot for testing! I was wondering how vista/7 compatible it was.

@ivop:
You're right, static linking is probably the way to go when things stabilize. Thanks for the tip!

@a8isa1:
I have a cheap USB RS-232 adapter and it works with 1x speed. I don't know how it will do with better adapters but it should work because I use the "official" serial port APIs and I don't do any direct hardware access.

Revision 8 from the svn is now almost as fast as APE when reading in Linux. Writing in Linux and the whole Windows serial port code still needs a lot work though. But both are more reliable then before. In the long run, I will invetigate the possibilities for using a derivative of hiassoft's atarisio as an optional backend and maybe writing a similar driver for Windows. But currently, since the things are stable enough on my system, I wanna concentrate on other features like better working folder images, image explorer and better executable booter.

Thanks all for feedback!

PS: In theory, revision 8 should compile in MacOsX but I have no Mac knowledge at all, so in practice I have no idea

Edited by cyco130, Fri Dec 18, 2009 1:41 AM.

[HiassofT]

Hi!

cyco130, on Fri Dec 18, 2009 1:33 AM, said:

@a8isa1:
I have a cheap USB RS-232 adapter and it works with 1x speed. I don't know how it will do with better adapters but it should work because I use the "official" serial port APIs and I don't do any direct hardware access.

I have some Digitus DA-70146 adapters (using a FT232BM) and they worked fine at 56k with current svn version. But I only did a quick read and write test with TurboDos.

Quote

Revision 8 from the svn is now almost as fast as APE when reading in Linux. Writing in Linux and the whole Windows serial port code still needs a lot work though. But both are more reliable then before.

Thanks, I can confirm this! Really well done!

While testing I noticed 2 small issues:

When I unplugged the USB adapter and started aspeqt, it couldn't open /dev/ttyUSB0 (of course). Then I went to the options menu and set the port to /dev/ttyS4 but aspeqt didn't reopen the port and stayed at "Emulation disabled".

Using a serial card aspeqt uses 100% cpu time when idle, but when using the USB adapter the load is (almost) zero.

I have a Core2Duo 6750, and checked with cpufreq-info: using the serial port one of the cores was running at low frequency (active power saving), the other one at the high(est) frequency. Here's the output of "top":

top - 13:51:35 up 4 days, 18:23,  2 users,  load average: 1.02, 0.68, 0.33
Tasks: 222 total,   1 running, 221 sleeping,   0 stopped,   0 zombie
Cpu(s):  5.3%us, 46.8%sy,  0.0%ni, 47.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4045852k total,  3892752k used,   153100k free,   109636k buffers
Swap:  7807504k total,	71104k used,  7736400k free,  3064804k cached

  PID USER	  PR  NI  VIRT  RES  SHR S %CPU %MEM	TIME+  COMMAND		   
16138 hias	  40   0  180m  11m 9952 S  100  0.3   5:09.21 aspeqt			

With the USB adapter both cores were at maximum power saving (low frequency). Again, the output of top:

top - 13:53:34 up 4 days, 18:25,  2 users,  load average: 1.12, 0.76, 0.40
Tasks: 222 total,   1 running, 221 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2%us,  0.0%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Quote

In the long run, I will invetigate the possibilities for using a derivative of hiassoft's atarisio as an optional backend and maybe writing a similar driver for Windows.

I had the same idea a few days ago :-)

I guess it would be best if you could add support for the AtariSIO kernel driver, so people can easily switch between your and my software and simply select standard serial port access (useful for USB adapters, for example) and AtariSIO access in aspeqt.

The kernel driver handles most of the low-level stuff (like switching baudrates, waiting for a valid command frame etc.) and has a (quite) simple ioctl interface. In the user space app you basically just fetch the command frame, send ACKs/NAKs and transmit/receive data frames. Have a look at SIOWrapper.cpp/h, this is the C++ wrapper around the ioctl interface.

If you'd like to have some extensions in the kernel driver, just drop me a line.

so long,

Hias

[sloopy]

tried it on my windows xp sp3 machine (AMD x2 6000+) and cpu usage is at ~50-54% with both cpu's showing ~50% usage... also in the proccess list shows aspeqt using 33-42%... during idle, goes to 9-11% cpu when active... when aspeqt is quit cpu goes back down to 0-3% usage... also my PF gets large too i didnt rec'd specific numbers but can if need be...

edit: also noticed it doesnt seem to have the pauses ape does (losing sync?) i am using a single chip sio2pc cable...

sloopy.

Edited by sloopy, Fri Dec 18, 2009 11:04 AM.

[cyco130]

@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!