[cyco130]

ascrnet, on Sun Jan 31, 2010 12:17 AM, said:

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

Done

Revision 18 from the SVN supports .cas images with an option to override the image's baud rate setting for higher transfer speeds.

I'll make a new release when I got more time.

[candle]

Fatih, You might want to read this
try with google translate, if still no go, i'll translate parts that would intrest You the most

[ascrnet]

cyco130, on Sun Jan 31, 2010 11:01 PM, said:

Done

Revision 18 from the SVN supports .cas images with an option to override the image's baud rate setting for higher transfer speeds.

I'll make a new release when I got more time.

perfect

So to expect the new version and thanks.

[Urchlay]

cyco130, on Sun Jan 31, 2010 10:05 AM, said:

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

Aspeqt + Qt 4.5.1 works fine on Linux, if that's any help to anyone doing a Haiku port...

[cyco130]

candle, on Mon Feb 1, 2010 9:06 AM, said:

Fatih, You might want to read this
try with google translate, if still no go, i'll translate parts that would intrest You the most

Thanks. I had a quick look, it seems like some extension proposal for the .cas format. I'll read it more deeply and check back with you if I need help.

Urchlay, on Tue Feb 2, 2010 12:31 AM, said:

Aspeqt + Qt 4.5.1 works fine on Linux, if that's any help to anyone doing a Haiku port...

Yes, Qt 4.5 should be enough, I use 4.5.2 under Linux. Sorry for the misinformation.

ascrnet, on Mon Feb 1, 2010 3:48 PM, said:

perfect
So to expect the new version and thanks.

Sorry, no luck today It's 2 o'clock here and I just got home. Let's see what tomorrow brings

[cyco130]

AspeQt 0.5.1 is now available. You can download it here.

This release adds simple cassette image playback and fixes small cosmetic issues in the log display (debug messages that shouldn't be shown are gone now and the colors are the same as the older versions). I didn't bump the version number to 0.6 because I felt it would be cheating since the changes were trivial You don't need it if you're not interested in .cas images and the log display verbosity doesn't bug you.

The documentation is updated accordingly. Please check if you want to use the custom baud rates for .cas images.

I've tested the new feature with a few cassette images I've found on the Internet. Most of them worked, including the ones with custom block sizes. The ones that didn't work were marked as "doesn't work with APE, only works with cas2sio". I didn't investigate it more deeply since there were fixed versions that worked. I'll do it some other time.

There is no seek, rewind and similar advanced features yet.

---

I'll study the .cas image extensions pointed by candle later, I want to do some other things first

[Kr0tki]

cyco130, on Tue Feb 2, 2010 8:19 PM, said:

I'll study the .cas image extensions pointed by candle later, I want to do some other things first

You may want to check out the A8CAS project homepage, where the aforementioned .cas extension is originating from. It's described here.

[cyco130]

Kr0tki, on Wed Feb 3, 2010 2:30 AM, said:

You may want to check out the A8CAS project homepage, where the aforementioned .cas extension is originating from. It's described here.

Thanks a lot! I can't immediately think of a way to support the "fsk " chunk using RS-232, but it's definitely doable with FTDI chips. I'll give it more thought.

---

Reading about the cassette things reminds of the time that I didn't have an Sio2Pc cable. I was transferring data to Atari using one of these. And I had a small Turbo Basic program for the other way around that painted the disk sectors (I did have a 1050) to a Gr.3 screen and a decoder on the PC side that took snapshots via a TV-card and saved to a file, it was faster than the cassette output. This was realy painful What was more painful was the time that I didn't have a PC and I didn't have a disk drive back in the old days. >5 minutes for the simplest game, ouch!

[Kr0tki]

Check out Hias' AtariSIO - the development snapshot from Jan 13 supports "fsk " chunks. Hias made it work by using the kernel's high-resolution timers to measure signal lengths. In his own words

This post has been edited by Kr0tki: Wed Feb 3, 2010 3:27 PM

[cyco130]

Kr0tki, on Wed Feb 3, 2010 11:26 PM, said:

Check out Hias' AtariSIO - the development snapshot from Jan 13 supports "fsk " chunks. Hias made it work by using the kernel's high-resolution timers to measure signal lengths. In his own words

Oh boy, this is some idea to send arbitrary bit streams via RS-232! I'll have a look at it and will try to steal some code (viva GPL ) when I got more time. I'm not sure if that precise timing would work in a user space program though. Well, this stuff is certainly on the edge of my abilities (if not beyond) and I'm already strugling with another challenge (synchronous I/O). So, that will certainly take quite some time (don't get me wrong, I'll do my best to support this in the near future).

[HiassofT]

cyco130, on Wed Feb 3, 2010 10:58 PM, said:

Oh boy, this is some idea to send arbitrary bit streams via RS-232! I'll have a look at it and will try to steal some code (viva GPL ) when I got more time. I'm not sure if that precise timing would work in a user space program though.

Yes, it was some crazy idea and it turned out to work really fine (at least for the quite low tape bitrates).

It should also be doable in userspace and I'm thinking of replacing the kernel code with some userspace code. In fact, it's not too complicated, and should also work with standard serial cards (without the AtariSIO kernel driver) under Linux. I'm not familiar with the Windows API, but maybe it supports similar functions:

You can simply use the TIOCSBRK TIOCCBRK ioctls to bit-bang the TxD line (just be sure the UART isn't transmitting anything).

If you are running a current Linux distribution (not older than approx. 2 years) the linux kernel and glibc should support the high resolution timers out of the box (of course you also need some hardware with HPET or similar support). The nice thing about this is that's it's completely transparent to userspace programs: you just use the standard functions (for example clock_nanosleep) and if your system supports high resolution timers you automatically get the high precision.

I'll do some tests when I have time and then I should be able to give some information about the achievable timing accuracy.

so long,

Hias

[Kr0tki]

To be frank, you do not need extremely high accuracy to support "fsk " chunks. Despite their accuracy being specified as tenths of milliseconds, in real life situations you won't encounter such short signals - you can get away with accuracy around 0.5 s.

The "fsk " chunk supports 1/10 ms accuracy in order to ease debugging of low-quality tapes. If a faulty tape cannot be converted into a "data" chunk without errors, it gets converted into "fsk " instead. Then the user can manually adjust lengths of signals stored in the "fsk " chunk, and perform conversion to CAS again, thus hopefully producing an error-free "data" chunk.

[Syfo-Dyas]

Urchlay, on Mon Feb 1, 2010 5:31 PM, said:

cyco130, on Sun Jan 31, 2010 10:05 AM, said:

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

Aspeqt + Qt 4.5.1 works fine on Linux, if that's any help to anyone doing a Haiku port...

Sadly, I am not aware of anyone besides my self who uses both Atari 8-bit and Haiku, and sadly my strength is not in coding. But yes Haiku does in fact have a port of Qt.

http://dev.osdrawer....rojects/qt-beos

This post has been edited by Syfo-Dyas: Thu Feb 4, 2010 12:32 PM

[HiassofT]

Kr0tki, on Thu Feb 4, 2010 7:15 PM, said:

To be frank, you do not need extremely high accuracy to support "fsk " chunks. Despite their accuracy being specified as tenths of milliseconds, in real life situations you won't encounter such short signals - you can get away with accuracy around 0.5 s.

Half a second precision shouldn't be a problem on most systems, even if other programs are running in the background.

I just did some quick tests on my system (Core2Duo 2.67GHz, Debian Lenny AMD64, vanilla Kernel 2.6.32.6 with HZ=1000 and dynamic ticks) using clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &end_time, 0):

When running as a normal userspace program clock_nanosleep() usually returned some 50µs too late. With realtime scheduling enabled (highest SCHED_RR priority) the accuracy was some +/-5µs.

so long,

Hias

[cyco130]

@HiassofT and Kr0tki: Thanks for the info! Now it sounds a lot easier. I'll give it a try when I got time and 1/2 seconds accuracy is definitely doable.

@Syfo-Dyas: Well, at least one of the prerequisites seems to be satisfied

[ascrnet]

cyco130, on Tue Feb 2, 2010 1:19 PM, said:

AspeQt 0.5.1 is now available. You can download it here.

This release adds simple cassette image playback and fixes small cosmetic issues in the log display (debug messages that shouldn't be shown are gone now and the colors are the same as the older versions). I didn't bump the version number to 0.6 because I felt it would be cheating since the changes were trivial You don't need it if you're not interested in .cas images and the log display verbosity doesn't bug you.

The documentation is updated accordingly. Please check if you want to use the custom baud rates for .cas images.

I've tested the new feature with a few cassette images I've found on the Internet. Most of them worked, including the ones with custom block sizes. The ones that didn't work were marked as "doesn't work with APE, only works with cas2sio". I didn't investigate it more deeply since there were fixed versions that worked. I'll do it some other time.

There is no seek, rewind and similar advanced features yet.

---

I'll study the .cas image extensions pointed by candle later, I want to do some other things first

hi cyco130,

I got bad news

I tested this version with the panther game cas format, which falls to the second baud ASPE load. But CAS2SIO or APE loads without problems. I am attaching pictures to show you.


 PANTHER.zip (15.34K)
Number of downloads: 3

Greetings

[cyco130]

Hi ascrnet,

Thanks for the report! Will take a look right away, doesn't seem like a big problem.

[cyco130]

Hi,

The attached file contains a (confirmed) fix for the issue reported by ascrnet. It also fixes the broken .cas drag & drop. It's not an official release (whatever that means), just a Windows .exe replacement. ascrnet's issue shoudn't concern Linux users but you can checkout rev. 21 from svn to fix .cas drag & drop.

Attached File(s)

•  aspeqt-rev21-windows.zip (209.34K)
  Number of downloads: 20

[w1k]

it will be support aspeQt a modem connection?
(ice-t, etc)

[cyco130]

w1k, on Sun Feb 7, 2010 10:21 AM, said:

it will be support aspeQt a modem connection?
(ice-t, etc)

I want to do that. But my knowledge about Atari modems is pretty shallow. Can anyone point me to some in depth docs?

[zaxon]

Amazing software, i was tested with IO-Board, results:

Under sparta i can't use full speed but:

Dos writing 2116.33 B/sek
Dos Reading 3117.96 B/sek
Dos Average 2617.15 B/sek

http://picasaweb.goo...co.uk/zaxoniec/ … 1899616034

Under mydos

Dos writing 3461.46 B/sek
Dos Reading 6084.96 B/sek
Dos Average 4773.21 B/sek

http://picasaweb.goo...co.uk/zaxoniec/ … 1159050370


video's :
http://www.youtube.c...h?v=Vn6HaT5-H_0 , colony 2106 loaded in 15 second's

http://www.youtube.c...h?v=7PbJBK8tWjU numen ,

[cyco130]

zaxon, on Sun Feb 7, 2010 7:58 PM, said:

Amazing software, i was tested with IO-Board, results:
...

Thanks!

Impressive performance, way better than what I can achieve on my (admittedly outdated) PC, I'm a bit jealous .

Would you mind giving your PC's specs and the OS you use at the Atari side to boot in high-speed?

[zaxon]

Pc performance is nothing,for this you can use any pc, including 486, any problems ?

[cyco130]

zaxon, on Mon Feb 8, 2010 12:19 AM, said:

Pc performance is nothing,for this you can use any pc, including 486, any problems ?

Unfortunately, it is something. I would be very surprised if it would run on a 486.

The SIO protocol has pretty tight timing requirements and it's not easy to meet them under a multitasking OS. In addition to that, Qt itself is a pretty heavy library (though nowhere near Java or .NET of course). So, if your PC is not fast enough or it's under heavy load you will experience some problems. If it's a bit faster, no problems will occur but the communication will be slower even when using the same baud rate, due to missed commands and delays in completion of SIO operations. If your PC is even faster, the speed will increase until it hits Atari's limit.

On Windows, I tried to solve this by giving the communication thread a high priority so that it can run in near realtime. On Linux, that's not an option. That's why AtariSIO backend is the recommended way of using AspeQt under Linux. AtariSIO, being a kernel module (a system driver), runs in near realtime and handles some of the time critical portions of the protocol. That's also why it runs faster than everything else.

PS: I'm still curious about the Atari OS you used to boot Kolony in high-speed I could only test divisor 0 with hisio, I wonder if it runs with other OSes too.

[cyco130]

Hi,

Just a quick update:

Thanks to Krzysztof Pyrkosz's efforts, AspeQt is now multilingual (well, bilingual for now). Here's AspeQt in Polish



Volunteers for making AspeQt available in other languages are welcome!