AspeQt: Yet another SIO2PC/APE clone

[timofonic]

So...

 

Are there some volunteer to help with AspeQt development? It seems there is need of some help and form a small team at least.

[Irgendwer]

And now the annoyance, or a bug, don't know...

 

When copying real disks from a Speedy-1050 disk drive (D2:) to an ATR (D1:) AspeQt shows very annoying behavior. While reading the source disk AspeQt shows a "Cannot read command frame" and "Emulation stopped" somewhere halfway the read process. This results in a write error to the destination ATR as emulation has stopped. Restarting the emulation by clicking the icon on the bottom solves it and it continues like it never happened and formats and writes to the ATR at 3X speed without problems.

 

This is with all disks and different sector copiers and I think it's odd it errors out while not even reading from an ATR but from a real 1050 in stead.

 

I have the same problem here too. So I don't think it's Atari/copy-software related.

[atari8warez]

Is Fatih or anybody else still working on AspeQt? I did implement a few minor changes to revision 42 and I am wondering whether I should check that in as revision 43.

• Added SEND TO PRINTER option to Atari printer output dialog
  
• Added DISPLAY DOCUMENTATION option to Help
  
• Added Turkish translation (75% done)
  

By the way does anybody know how to develop a Windows HELP system, anyone willing to tackle that?

Also, I currently only know how to compile it for Windows, how do I do it for Linux distro?

 

It's a learning process for me, planning to do more as I gain more experience in QT IDE...

 

Ray

Edited January 26, 2012 by atari8warez

[+JAC!]

Hi Ray,

 

See my post :"Meanwhile, if other Atari enthusiasts want to takeover the project leadership (it's open source after all), I would be more than willing to help as a contributor. Regards, Fatih."

 

Hias has done many updates on AspectQT locally, too. It would be really great if you could become a contributor on sourceforge and merge your changes and Hias's changes into a new public version!

Edited January 27, 2012 by JAC!

[Gunstar]

What is the latest version of AspeQT and how do you tell which version you have? Also, where can the latest version be downloaded if I have an older version?

[Fox-1 / mnx]

download: http://sourceforge.net/projects/aspeqt/

[atari8warez]

What is the latest version of AspeQT and how do you tell which version you have? Also, where can the latest version be downloaded if I have an older version?

 

I've checked revision 42 in (in trunk\) from sourceforge.net and am working with Turtoise SVN client. I noticed that there is a tagged (i.e 0.x) version under tags\ but I haven't diff'ed them so I am not sure what is different (if anything), tags\ version is at revision 46. My understanding is trunk\ is the main source to check software out for mods. Unfortunately source code lacks in documentation (very few comments). I will try to compare sources in trunk\ and tags\ and see what the story is.

[atari8warez]

What is the latest version of AspeQT and how do you tell which version you have? Also, where can the latest version be downloaded if I have an older version?

 

I've checked revision 42 in (in trunk\) from sourceforge.net and am working with Turtoise SVN client. I noticed that there is a tagged (i.e 0.x) version under tags\ but I haven't diff'ed them so I am not sure what is different (if anything), tags\ version is at revision 46. My understanding is trunk\ is the main source to check software out for mods. Unfortunately source code lacks in documentation (very few comments). I will try to compare sources in trunk\ and tags\ and see what the story is.

 

As far as downloading the new version, I believe Fatih once said that sourgeforge.net provides a download link for the latest version in the SVN section. In fact that's where I dl'ed it the first time.

[atari8warez]

Hi Ray,

 

See my post :"Meanwhile, if other Atari enthusiasts want to takeover the project leadership (it's open source after all), I would be more than willing to help as a contributor. Regards, Fatih."

 

Hias has done many updates on AspectQT locally, too. It would be really great if you could become a contributor on sourceforge and merge your changes and Hias's changes into a new public version!

 

If Hias would be kind enough to provide us with that info we could definitely do that. I've done a few minor changes as follows:

 

1. Added a print dialog to send the Atari text printer output to the PC printer.

 

2. Added a "Display documentation" option to the HELP menu to display the doc file supplied by Fatih. I hope that will help AspeQt newcomers to gain some insight about the software instead of hunting for the documentation around the net. It would be great if we could add a comprehensive HELP section with search capabilities....(anybody ???)

 

3. Fixed a problem with some .atr files not loading (when the .atr file is larger than the SIZE value in the header). This was actually not a bug (in fact it shows how Fatih's code is failsafe) but prevented some otherwise usable .atr files from loading. I was conservative in the way I modified the code as such it will still not load an .atr if the header size information is greater than the actual file size. See my post here for more details.http://www.atariage....__fromsearch__1

 

4. Added Turkish translation (still working on it), and yes I am of Turkish origin (and I believe Fatih also is) and can still speak the language after being away from the native country for 30 years now

 

Ray

Edited January 28, 2012 by atari8warez

[HiassofT]

Hias has done many updates on AspectQT locally, too. It would be really great if you could become a contributor on sourceforge and merge your changes and Hias's changes into a new public version!

I wouldn't call it "many updates", actually it's just very few (minor) changes.

 

I worked with the latest release, version 0.6, as I wasn't too sure about the changes in trunk (and most people use 0.6, so this was a good basis to start, IMO). I've attached the diffs, splitted up in 2 files.

 

The first patch fixes problems with Pokey divisors 0 and 1 I was experiencing on my PAL 800XL. I set the baudrates to values actually supported by the FTDI chip to avoid possible rounding errors (resulting in too high speeds).

 

The second patch incorporates 3 changes:

- first a small backslash-escape issue in the project file and I also bumped the version number (so you can see in the About dialog that this is a patched version)

- then a (cosmetic) fix for the image size calculation in the "create image" dialog.

- plus add support for ATRs with 8192 byte sectors (both in the base "diskimage" code and also when creating new images).

 

ATRs with 8192 byte sectors isn't something people will need too often (putting a filesystem on top of it and using this on the Atari 8bits would be quite insane), but it was very handy for my flasher software, which accesses the flash cart in 8k blocks so one block could be read with a single SIO call (which is somewhat faster than 32 256-byte SIO transfers, especially on Windows machines).

 

I also tried to investigate why the performance (overall throughput) on Win32 was significantly lower than on Linux - on Win32 you have really huge delays between ACK and Complete (some 7ms) and between Complete and data frame (some 15ms). Especially at high transfer speed this was quite annoying. At divisor 0 a 256 byte data frame takes some 20ms to transfer, the delays add another 22ms so performance drops to almost 50% of what it should be.

 

It turned out this has to do with how the Win32 sleep function and scheduler work. There seems to be no easy way to get finer granularity than a standard Win32 timeslice in user-space. At least I haven't found a solution, but this doesn't mean too much as I'm no expert in Win32 systems. I tried to do busy-waiting using the performance counters instead of using Qthread::usleep(), but this didn't help much and also opens another can of worms on multiprocessor/core systems (where each core has it's own counters, and you need to take care of that). Maybe the multimedia timers (in single-shot mode) could help, but I haven't found the time yet to test this.

 

so long,

 

Hias

aspeqt-0.6-patches.zip

[flashjazzcat]

Does folder mounting still return a small, circular quantity of sector numbers (thus preventing it from working with SDX's AtariDOS driver)?

[atari8warez]

Hias has done many updates on AspectQT locally, too. It would be really great if you could become a contributor on sourceforge and merge your changes and Hias's changes into a new public version!

I wouldn't call it "many updates", actually it's just very few (minor) changes.

 

.........

 

Hias

 

Great, thank you for the explanation, I will incorporate your changes into my copy, I am still working on the translation (tedious and long work) and implementing smaller, mostly convenience related changes. I don't yet have enough Qt/ Serial Comm knowledge to dive deep into the nitty gritty details of timings etc., so my changes will evolve around adding more UI related enhancements.

 

Take care.

Ray

Edited February 5, 2012 by atari8warez

[phaeron]

I also tried to investigate why the performance (overall throughput) on Win32 was significantly lower than on Linux - on Win32 you have really huge delays between ACK and Complete (some 7ms) and between Complete and data frame (some 15ms). Especially at high transfer speed this was quite annoying. At divisor 0 a 256 byte data frame takes some 20ms to transfer, the delays add another 22ms so performance drops to almost 50% of what it should be. It turned out this has to do with how the Win32 sleep function and scheduler work. There seems to be no easy way to get finer granularity than a standard Win32 timeslice in user-space.

 

The usual solution for this is to jack up the system timer rate using timeBeginPeriod(1). A goofy thing you can try is to check AspeQt's timing when Altirra is running in the background (actually running, not paused) -- it raises the system timer precision to 1ms when running so this would also affect AspeQt's thread scheduling. The delay will still be longer than needed, 1.5ms on average, but it'd be significantly better.

 

Also, I wonder whether the delay between Complete to data frame is actually necessary. There isn't a timing requirement for this in the SIO spec and so presumably the computer would have to handle back-to-back transfers. The 810 has a long complete-to-data delay due to its checksum routine, while the XF551 has a 1.2ms delay and it looks like the 1050 just sends the data immediately.

[HiassofT]

The usual solution for this is to jack up the system timer rate using timeBeginPeriod(1). A goofy thing you can try is to check AspeQt's timing when Altirra is running in the background (actually running, not paused) -- it raises the system timer precision to 1ms when running so this would also affect AspeQt's thread scheduling. The delay will still be longer than needed, 1.5ms on average, but it'd be significantly better.

Thanks a lot for the info, I guess this should help quite a bit!

 

Now that you mentioned timeBeginPeriod() I also saw a reference to it in the docs of the Sleep() function - must have missed this back then :-)

 

Also, I wonder whether the delay between Complete to data frame is actually necessary. There isn't a timing requirement for this in the SIO spec and so presumably the computer would have to handle back-to-back transfers. The 810 has a long complete-to-data delay due to its checksum routine, while the XF551 has a 1.2ms delay and it looks like the 1050 just sends the data immediately.

At standard SIO speed this is no big problem, as each byte takes ages to transfer. But at higher speeds some SIO codes fail if there's no delay between complete and data. I found the following comment in my AtariSIO code:

/* QMEG OS 3 needs a delay of max. 150usec between complete and data */

I can't remember which other SIO implementations also need a delay, and how long it would need to be, I have the 150µs delay in my code for some time now, without any troubles.

 

so long,

 

Hias

[+Larry]

I'm not sure if this is related to Hias' comments or not. (?) On my NTSC system with the FTDI converter, I find that AspeQt does not produce a smooth SIO sound. I don't get hard errors, but it sounds as if it is making quite a few retries at anything above 1X SIO, and the faster I go, the worse it sounds. I don't get this at all with APE -- it is smooth and steady. Does anyone else find this behavior? BTW, my PC is a Core 2 Duo 6300, (still) running 32-bit XP.

-Larry

[Rybags]

Yep. It's as if multiple command frames are sometimes having to being sent instead of just one.

 

Probably some sort of timing issue.

 

But I don't use it much anymore, thanks to the problem with folder mounts + SDX.

[atari8warez]

I'm not sure if this is related to Hias' comments or not. (?) On my NTSC system with the FTDI converter, I find that AspeQt does not produce a smooth SIO sound. I don't get hard errors, but it sounds as if it is making quite a few retries at anything above 1X SIO, and the faster I go, the worse it sounds. I don't get this at all with APE -- it is smooth and steady. Does anyone else find this behavior? BTW, my PC is a Core 2 Duo 6300, (still) running 32-bit XP.

-Larry

 

I don't have an FTDI based cable so I can't compare my results to yours, but just FYI, I run AspeQt with a Prolific based virtual comm port on my laptop (Intel Dual core T5200 @ 1.6Ghz, 64 bit Win7) and the operation is pretty smooth at 1 and 2x SIO speeds. With 3x, I run into problems especialy when writing to a drive (reads are mostly OK).

 

On my configuration APE does not run at all cause it does not have 64 bit serial I/O drivers.

[atari8warez]

But I don't use it much anymore, thanks to the problem with folder mounts + SDX.

 

What are the problems with folder mounts? could you please expand on that (or is there a thread i can read about it here @ atariage)

[flashjazzcat]

I asked about the SDX folder issue further up the thread but the question wasn't addressed at the time. Aspeqt returns sector numbers in a loop and this upsets SDX's AtariDOS driver, which evidently expects each sector of a file to have a unique ID. It may have something to do with sector caching... not exactly sure, but this bit of Aspeqt needs fixed.

[HiassofT]

Hi Larry!

 

I'm not sure if this is related to Hias' comments or not. (?) On my NTSC system with the FTDI converter, I find that AspeQt does not produce a smooth SIO sound. I don't get hard errors, but it sounds as if it is making quite a few retries at anything above 1X SIO, and the faster I go, the worse it sounds. I don't get this at all with APE -- it is smooth and steady. Does anyone else find this behavior? BTW, my PC is a Core 2 Duo 6300, (still) running 32-bit XP.

I tested AspeQt on an old 1.8GHz P4 running WinXP and on a XP VM running on my Core2Duo 6750 Linux box, using a FTDI converter, and didn't experience any strange non-smooth sounds. I suspect something in the background (either a program or some driver) might be blocking your system for too long (too long here means some 20-40ms, so it's not something you'd usually notice).

 

Anyways, here's the link to my patched version, compiled for Win32:

http://www.horus.com...Hias-111113.zip

 

so long,

 

Hias

[HiassofT]

Hi Jon!

 

I asked about the SDX folder issue further up the thread but the question wasn't addressed at the time. Aspeqt returns sector numbers in a loop and this upsets SDX's AtariDOS driver, which evidently expects each sector of a file to have a unique ID. It may have something to do with sector caching... not exactly sure, but this bit of Aspeqt needs fixed.

I haven't had a look at this particular bit of code in AspeQt (and also don't have the time to do this), but I'd like to also blame the SDX ataridos driver and/or the SDX caching/buffering scheme. Not sure how well it works with APE (IIRC APE returned links to the same sector number, at least at some time), but I had problems when writing to a "virtual drive" on AtariSIO. Any cache which "optimizes" sector accesses or re-arranges the order in which sectors are accessed are likely to cause problems with virtual / emulated / PC-mirror drives.

 

So, an option in SDX to disable the cache for particular drive(s) would be needed (not sure if such an option already exists or not).

 

so long,

 

Hias

[+Larry]

Hi Hias!

 

Thanks very much -- I'll definitely give it a try.

 

Now I just have to find what I did with that converter!

 

-Larry

[+Larry]

Hi Hias-

 

I downloaded your Win32 patched version of AspeQt, and it runs much smoother. I'm using your HISION driver with it, and it sounds just as smooth as APE.

 

Congrats, and thanks, again!

 

-Larry

[+Larry]

FWIW: Some small suggestions for AspeQt. I'm very impressed with AspeQt, especially considering that it is a relatively recent release. But I do have a few "user friendly" suggestions.

 

1) Have the GUI "remember" it's size and location if toggled. This is useful if one uses it with several other windows at the same time. (My "Atari windows" are always in the same places and mostly the same sizes for each run.)

 

2) A nice little icon for the desktop would be nice.

 

3) The GUI is a bit hard to read (especially for older eyes). Some better color choices and type face selections would likely improve it.

 

4) I had trouble before getting the printer window to open up, but now it seems fine. (?) But looks like you can't print directly to the Win printer. Printing to a text file certainly works, but would be a little more convenient going directly to the printer.

 

-Larry

[Fox-1 / mnx]

I'll like to add:

 

1a) Have the GUI store the settings (all settings actually) in a CFG file in stead of the registry.

 

I often run 2 instances of it on the same system under the same user account, and while this works perfectly, the fact each instance always starts up in the state where it was closed the last time is at least very annoying. This way all instances will default to the same COM port, same ATR's, etc...

 

 

5) Make the SIO transmissions compatible with real disk drives.

 

Using a real Speedy 1050 drive causes AspeQt to stop even when just loading from the real drive, like, no ATR's involved.