AspeQt: Yet another SIO2PC/APE clone

[+Eyvind Bernhardsen]

Hey, cool, 0.8 is pretty stable, while 0.6 was stopping emulation suddenly (but only the Linux version, windows version worked seamlessly in Linux).

 

In Mac OS X, I cannot compile the project, it tells me that these files are missing: stropts.h, termio.h, linux/serial.h (v0.6)

 

and the v0.8 sources complain, that AspeQt.rc is missing (which totally confuses me :/ )

I usually deal with missing header files by commenting them out, building, and then searching through the system include files for the symbols the compiler complains are missing. Usually they're just in a different include file, but occasionally you'll have to install an extra library. Worst case, at least you'll have something to Google for to find what you need.

 

[cyco130]

Many thanks to atari8warez and others for the updates. I wanted to comment on some recently raised issues.

 

Porting to Mac: AspeQt won't compile on a Mac yet. Someone needs to write a serial port backend for it. The Unix one should be a good start and most things except header file names and setSpeed ought to work. But setSpeed uses a Linux specific method to use non-standard serial port speeds. I would really like to see AspeQt run on a Mac natively.

 

Folder images: Coming up with a folder imaging scheme that is both efficient and compatible with a wide range of DOSes is not an easy task. One needs to analyze sector access patterns of different DOSes, or rebuild everything from scratch when a write occurs. I gave up at the time because I didn't have SpartaDos X. But on the PC side one can use Qt's QFileSystemWatcher to update the imaged folder automatically. That would solve most problems as long is folder images are readonly. Just rebuild the image when the file system reports change. But I really can't comment on write support.

[flashjazzcat]

Folder images: Coming up with a folder imaging scheme that is both efficient and compatible with a wide range of DOSes is not an easy task. One needs to analyze sector access patterns of different DOSes, or rebuild everything from scratch when a write occurs. I gave up at the time because I didn't have SpartaDos X. But on the PC side one can use Qt's QFileSystemWatcher to update the imaged folder automatically. That would solve most problems as long is folder images are readonly. Just rebuild the image when the file system reports change. But I really can't comment on write support.

 

QFileSystemWatcher is exactly what's needed to implement the read-only system I was considering having a go at. It shouldn't take long to scan the target folder (and - indeed - all its sub-folders) and build up a SpartaDOS disk image (up to 32MB) which exactly represents the folder content (albeit with shortened names). If a change occured on the host file system, perhaps the best way to get around SDX's sector caching is to issue a media change to SDX itself, simply by changing the random and sequence ID bytes in the emulated boot sector. This would then make SDX's cache invalid. Meanwhile Aspqeqt can build a whole new disk image before satisfying subsequent read requests.

 

Write capability: a whole different matter indeed. We're basically trying to intuit file operations from the contents of changed sectors. I believe that this could - long windedly - be accomplished by comparing the amended sectors with the originals and thereby discerning changes to the PC file system (i.e. finding files which have vanished, changed or been newly created). Changes could then be applied to the mounted folder... but we seem to be a kick in the teeth from a mounted ATR by this point.

[atarixle]

Another stupid question - if already answered - ...

 

How do I grant access to my serial device, if Linux declines it? (Ubuntu 12.04 ... in 10.10 it worked out-of-the-box)

Edited April 6, 2012 by atarixle

[kurtm]

Another stupid question - if already answered - ...

 

How do I grant access to my serial device, if Linux declines it? (Ubuntu 12.04 ... in 10.10 it worked out-of-the-box)

 

(Putting on my sysadmin hat)

 

Check the permissions on the serial device. Your user may not belong to the group that can open it. Looks like your user may need to be in the dialout group to use it.

[atari8warez]

AspeQt version 0.8.1

• Added auto-commit (auto-save) function for disk images
  Changes made to disk images can now be saved automatically without user intervention (Ray Ataergin)
  
• Added preliminary .ATX image support (does not seem to be fully functional) (Krzysztof Pyrkosz)
  
• Updated Polish translation (Krzysztof Pyrkosz)
  
• Updated Turkish translation (Ray Ataergin)
  
• Added Russian translation (Nikita Zimin)
  
• Updated high speed exe loader (Matthias Reichl)
  

Binaries and source here

[sharkcz]

The 0.8.1 source doesn't build, at least diskimageatx.h and i18n/aspeqt_ru.ts are missing in the source archive. Do you plan to release the sources in the SourceForge project page too?

 

And I'm providing AspeQt packages for Fedora and RHEL (and clones) in my add-on repository

Edited April 8, 2012 by sharkcz

[atari8warez]

Ok the source is updated, I don't know why I am missing files everytime, I guess Turtoise SVN does not mark some files as changed/new, but in any case the source is also in the SourceForge repo.

[Charlie_]

Hello. This 8.01 doesn't run XEX files for me. I'm trying the pacmanv8.xex and with 8.01 it loads faster but eventually gets to the blue ready screen and the computer is locked up.

 

Going back to 8.0 loads and runs fine, just slow as normal.

 

 

**edit: I went in options of 8.01 and enable high speed loader (it was previously unchecked) and now it loads said XEX VERY fast and properly.

with that option unchecked it fails as described above.

 

My options have a speed set of pokey divisor 1 if that means anything..... still same setting worked in 8.0

 

Another edit, high speed XEX loading works but seems unreliable. bad loads, lock ups, where these fast setting are stable under normal use.

Edited April 9, 2012 by Official Ninja

[atari8warez]

Hello. This 8.01 doesn't run XEX files for me. I'm trying the pacmanv8.xex and with 8.01 it loads faster but eventually gets to the blue ready screen and the computer is locked up.

 

Going back to 8.0 loads and runs fine, just slow as normal.

 

 

**edit: I went in options of 8.01 and enable high speed loader (it was previously unchecked) and now it loads said XEX VERY fast and properly.

with that option unchecked it fails as described above.

 

My options have a speed set of pokey divisor 1 if that means anything..... still same setting worked in 8.0

 

Another edit, high speed XEX loading works but seems unreliable. bad loads, lock ups, where these fast setting are stable under normal use.

 

You're not alone... there seemed to be a build problem for win32 binaries, I have rebuilt the project and uploaded the latest binaries and source to SourceForge as of 15 mins ago. Low speed exe load now works as well as the high speed.

 

Sorry for the confusion.

Ray

[atari8warez]

Krzys made some enhancements to the ATX (VAPI) loader and as of today according to him the following games load and run properly:

• Zorro
  
• Wayout
  
• Bruce Lee
  
• Beach-Head
  
• Archon
  
• Boulder Dash Construction Kit
  

Above enhancement is included on the latest 0.8.1 binaries and source.

Download it from Here or here

 

Ray

 

Edit: Other titles that I myself can confirm as working are:

• Acey-Deucy
  
• Reader Rabbit (Learning Company)
  
• Seawolf II and Gun Fight
  

(Will check for more as my time permits, your feedback is also greatly appreciated folks)

Edited April 10, 2012 by atari8warez

[Charlie_]

You're not alone... there seemed to be a build problem for win32 binaries, I have rebuilt the project and uploaded the latest binaries and source to SourceForge as of 15 mins ago. Low speed exe load now works as well as the high speed.

 

Sorry for the confusion.

Ray

Nice. Great to hear its fixed already. :)I'll be trying it out after work. Edited April 10, 2012 by Official Ninja

[Roydea6]

Ok the source is updated, I don't know why I am missing files everytime, I guess Turtoise SVN does not mark some files as changed/new, but in any case the source is also in the SourceForge repo.

I can't seem to get the little green dot with a '+' sign to work.

 

 

Maybe I just need more information on it's use.

[optixx]

I created a version that compiles on OSX. I changed linux specific serial ioctl to the osx variants via #ifdef's. Compiles with qt4.8. Didn't test it with real hardware, yet.

 

https://github.com/optixx/aspeqt

[atarixle]

it compiles, I will test it later, if it works with my USB/Serial-converter ...

 

for now, it runs (giving me the error message "Cannot retrieve serial port status: Inappropriate ioctl for device." ... think it's cuz I don't have any serial port connected at the moment) and it looks great.

 

Btw., AspeQt for Windows seems to work in Wine for OSX aswell ... amazing considering almost nothing works in wine/OSX

Edited April 10, 2012 by atarixle

[Charlie_]

got the fixed 8.01. The standard speed XEX loading is fixed. Works well.

The high speed is unreliable. Some times it works but mostly fails.

Here is the pacmanv8 remake I've been testing with. (hold option)

At high speed it mostly fails with a bunch of colored bars across the screen.

 

Edit: Not sure if its aspeqt but some times even at normal speed when the first splash screen loads the colors are all wrong and flashing.

Not sure if its a bug or problem with Aspeqt loading...

pacmanV8.xex

Edited April 10, 2012 by Official Ninja

[atari8warez]

I didn't have any issues with either speed (hi or low) when I tested some versions of PacMan last night, but I will try your upload and see.

[Charlie_]

I didn't have any issues with either speed (hi or low) when I tested some versions of PacMan last night, but I will try your upload and see.

 

I just tested some more. High speed XEX loading is reliable only when using 3x standard pokey speed.

 

It is unreliable when using non-standard divisiors. I tried from 0-5 as a divisor and it was just random if it would load properly or not.

 

So 3x, works great. Any divisor speed is no good.

 

Again, I can reliably run mypicodos with the Kheffington's 4, 64mb files of games at a divisor of 0. Large games like Crossbow load super fast with no pauses or errors.

[atari8warez]

I didn't have any issues with either speed (hi or low) when I tested some versions of PacMan last night, but I will try your upload and see.

 

I just tested some more. High speed XEX loading is reliable only when using 3x standard pokey speed.

 

It is unreliable when using non-standard divisiors. I tried from 0-5 as a divisor and it was just random if it would load properly or not.

 

So 3x, works great. Any divisor speed is no good.

 

Again, I can reliably run mypicodos with the Kheffington's 4, 64mb files of games at a divisor of 0. Large games like Crossbow load super fast with no pauses or errors.

 

What kind of SIO2PC/cable combination are you using? and what version of OS on PC?

By the way I tried pacmanv8 and I am having issues at 2xSIO speeds, but only with your file, other files I tried seem to be working ok.

Edited April 11, 2012 by atari8warez

[Charlie_]

I didn't have any issues with either speed (hi or low) when I tested some versions of PacMan last night, but I will try your upload and see.

 

I just tested some more. High speed XEX loading is reliable only when using 3x standard pokey speed.

 

It is unreliable when using non-standard divisiors. I tried from 0-5 as a divisor and it was just random if it would load properly or not.

 

So 3x, works great. Any divisor speed is no good.

 

Again, I can reliably run mypicodos with the Kheffington's 4, 64mb files of games at a divisor of 0. Large games like Crossbow load super fast with no pauses or errors.

 

What kind of SIO2PC/cable combination are you using? and what version of OS on PC?

By the way I tried pacmanv8 and I am having issues at 2xSIO speeds, but only with your file.

 

I'm using a sio2pcusb small dongle type made by Sloopy, running Windows XP.

The XEX of pacmanv8 is taken right from this section of the forums yesterday.

[atari8warez]

I didn't have any issues with either speed (hi or low) when I tested some versions of PacMan last night, but I will try your upload and see.

 

I just tested some more. High speed XEX loading is reliable only when using 3x standard pokey speed.

 

It is unreliable when using non-standard divisiors. I tried from 0-5 as a divisor and it was just random if it would load properly or not.

 

So 3x, works great. Any divisor speed is no good.

 

Again, I can reliably run mypicodos with the Kheffington's 4, 64mb files of games at a divisor of 0. Large games like Crossbow load super fast with no pauses or errors.

 

What kind of SIO2PC/cable combination are you using? and what version of OS on PC?

By the way I tried pacmanv8 and I am having issues at 2xSIO speeds, but only with your file.

 

I'm using a sio2pcusb small dongle type made by Sloopy, running Windows XP.

The XEX of pacmanv8 is taken right from this section of the forums yesterday.

 

This to me, seems like a cable/VCP driver issue, I can load and run your pacmanv8 no problem at normal speed (19200bps), at 38400 (2xSIO) it mostly fails and at 57600 (3xSIO) it fails as soon as the first few sectors are loaded. This, with a Prolific based USB to COM cable. If yours is FTDI based (which I believe it is if it's from sloopy) than it explains why you can successfully load it at 3x. But even with FTDI based VCPs other non-standard pokey divisors - speeds - are highly experimental and not guaranteed to work in all cases.

Edited April 11, 2012 by atari8warez

[Charlie_]

I didn't have any issues with either speed (hi or low) when I tested some versions of PacMan last night, but I will try your upload and see.

 

I just tested some more. High speed XEX loading is reliable only when using 3x standard pokey speed.

 

It is unreliable when using non-standard divisiors. I tried from 0-5 as a divisor and it was just random if it would load properly or not.

 

So 3x, works great. Any divisor speed is no good.

 

Again, I can reliably run mypicodos with the Kheffington's 4, 64mb files of games at a divisor of 0. Large games like Crossbow load super fast with no pauses or errors.

 

What kind of SIO2PC/cable combination are you using? and what version of OS on PC?

By the way I tried pacmanv8 and I am having issues at 2xSIO speeds, but only with your file.

 

I'm using a sio2pcusb small dongle type made by Sloopy, running Windows XP.

The XEX of pacmanv8 is taken right from this section of the forums yesterday.

 

This to me, seems like a cable/VCP driver issue, I can load and run your pacmanv8 no problem at normal speed (19200bps), at 38400 (2xSIO) it mostly fails and at 57600 (3xSIO) it fails as soon as the first few sectors are loaded. This, with a Prolific based USB to COM cable. If yours is FTDI based (which I believe it is if it's from sloopy) than it explains why you can successfully load it at 3x. But even with FTDI based VCPs other non-standard pokey divisors - speeds - are highly experimental and not guaranteed to work in all cases.

 

Ok. Well, I hope it gets better with more updates. For now I'm sticking to standard XEX loading speed. After using the system with divisor 1 or even 0 there is no way you want to go back to 3x. Maybe a separate option for XEX loading speed?

 

As always, Thanks for all the work on Aspeqt. It is fantastic and much appreciated!

[atari8warez]

Ok the source is updated, I don't know why I am missing files everytime, I guess Turtoise SVN does not mark some files as changed/new, but in any case the source is also in the SourceForge repo.

I can't seem to get the little green dot with a '+' sign to work.

 

 

Maybe I just need more information on it's use.

 

That green dot with a + sign is supposed to add a file to the explored disk image (similar to dragging and dropping a file into the explorer window), but image explorer was never fully implemented before Fatih (the original developer of AspeQt) had to take a break from coding. It's one of my objectives to bring image explorer to full functionality but I am not quite there yet. Currently image explorer only allows dragging and dropping from, but not to the explorer window. Also folder images have more limitations than the disk images, that's another area that needs to be tackled.

[atari8warez]

Ok. Well, I hope it gets better with more updates.......As always, Thanks for all the work on Aspeqt. It is fantastic and much appreciated!

 

That's our hope too, we are doing what we can to have our small contibutions help improve an already great piece of software...

[cyco130]

Write capability: a whole different matter indeed. We're basically trying to intuit file operations from the contents of changed sectors. I believe that this could - long windedly - be accomplished by comparing the amended sectors with the originals and thereby discerning changes to the PC file system (i.e. finding files which have vanished, changed or been newly created). Changes could then be applied to the mounted folder... but we seem to be a kick in the teeth from a mounted ATR by this point.

 

A very cool idea to make folder images came from drac030 last year. He e-mailed me about his Dos2Dos protocol, which is an Atari side driver for folder images that he uses for his Sio2Bsd program. Currently only a SDX driver is implemented but writing a Atari Dos/MyDos version seems straight forward. Check this info with Google Translate: http://atariki.krap....dex.php/DOS2DOS

 

I created a version that compiles on OSX. I changed linux specific serial ioctl to the osx variants via #ifdef's. Compiles with qt4.8. Didn't test it with real hardware, yet.

 

Wow! Cool I always wanted to see AspeQt run on Mac OS X. I expect some screen shots after the testing is done. All the major platforms are covered now and AspeQt is the most portable Sio2Pc clone. If someone adds BSD and BeOS support, it'll be unbeatable

 

Maybe a separate option for XEX loading speed?

 

I think it's a good idea. Many XEX loading screens don't like high speed SIO. Current loader, if no one has changed it yet, uses big transfer chunks (around 1K IIRC) which makes it work very fast when it does work but I can see that it can be a problem with some hardware/software combinations.