Atari 8-bit Software Preservation Initiative

[luckybuck]

Yes, very true. The atx files in an emulator are no problem, when used with SIO2SD or SIO2USB or maybe TheCart! etc. it even can run on normal hardware. So, the need to write back is very limited to my point of view. Further, if the remaining atx are brought to atr, then all problems regarding this are over.

[+DrVenkman]

Yes, very true. The atx files in an emulator are no problem, when used with SIO2SD or SIO2USB or maybe TheCart! etc. it even can run on normal hardware. So, the need to write back is very limited to my point of view. Further, if the remaining atx are brought to atr, then all problems regarding this are over.

Thats the part I dont understand. That specific hardware is far from common among the wider Atari 8-bit retrocommunity, especially outside of Europe. Much more common are other flashcarts like the UNO, Ultimate and Atarimax carts, and generic FTDI-based SIO2PC devices connected to boxes running APE, RespeQt or AspeQt. None of that hardware allows use of these archived ATX files, which is a frankly a bit of a tragedy in our scene.

Edited June 28, 2018 by DrVenkman

[+remowilliams]

The Kryoflux writes back. You just have to convert the ATX back to the Kryoflux's raw flux files first.

 

Would the conversion/write chain look like this?

 

 

a8rawconv.exe -of scp "title.atx" .\_scpconvert\title.scp
hxcfe -finput:_scpconvert\title.scp -foutput_scpconvert\title -conv:KRYOFLUXSTREAM
dtc -f.\_scpconvert\title_scp00.0.raw -w -ks2 -wb1 -we2

[luckybuck]

@DrVenkman: sure, if they support atx files, then everything is fine, too. No problem.

 

@remowilliams: Have made a recipe:

https://atariwiki.org/wiki/Wiki.jsp?page=Create%20an%20atx%20image%20from%20KryoFlux%20raw%20files

Edited June 28, 2018 by luckybuck

[GlowingGhoul]

Yes, very true. The atx files in an emulator are no problem, when used with SIO2SD or SIO2USB or maybe TheCart! etc. it even can run on normal hardware. So, the need to write back is very limited to my point of view. Further, if the remaining atx are brought to atr, then all problems regarding this are over.

 

None of those devices support protected images. The point is to be able to use the original program, without relying on cracked versions.

[+remowilliams]

@remowilliams: Have made a recipe:

https://atariwiki.org/wiki/Wiki.jsp?page=Create%20an%20atx%20image%20from%20KryoFlux%20raw%20files

 

Thanks, but I know how to create an .atx from Kryo raw images. The question is how to take an .atx image and convert back to Kryo raw for write purposes.

[Pheonix]

 

 

Would the conversion/write chain look like this?

 

 

a8rawconv.exe -of scp "title.atx" .\_scpconvert\title.scp
hxcfe -finput:_scpconvert\title.scp -foutput_scpconvert\title -conv:KRYOFLUXSTREAM
dtc -f.\_scpconvert\title_scp00.0.raw -w -ks2 -wb1 -we2

 

 

I'm not completely sure. I use HxC in GUI form to convert to the Kryoflux raw flux files. The DTC line is "mostly" right... You would also need to set the device number (-d1 or -d0 depending on which is your 5.25" drive.) If your are going to use the disk with a real Atari floppy drive, you'll probably also want to use a DD floppy drive to write with. So, the -ks2 may not be necessary, and you might need to convert to file to a true 40 track set (00-39 i/o 00-78 even numbers.) Don't know, been wanting to get a true DD drive for writing with, but haven't gotten a working one yet.

[Farb]

In the meantime, although I continue to host a seed I mostly can't actually use on my real hardware, DjayBee is doing the Lord's work for us mere mortals.

 

Where does this perception come from that the only way to make use of ATX files on real hardware is to write them back to physical media? There are two solutions you can use today to do this:

 

1. APE with the VAPI.dll (should run almost everything)

2. SDrive Max (this already supports many ATX files today and we are actively working on getting more advanced timing-based protections working).

 

Don't get me wrong, I think the idea of writing back to real floppy disks is fun for the "full retro Atari experience". But it relies on disk drives that are getting pretty long in the tooth and media that we're already seeing has a finite shelf life and will become harder and harder to get (and more expensive) over time. To echo luckybuck's sentiment, if we are going to put effort into developing solutions to get ATX files running on real hardware, we should focus our efforts on sustainable solutions for the long term that don't rely on fragile hardware and media.

Edited June 28, 2018 by Farb

[Farb]

...I recently was given a stash of original Avalon Hill games, all seem complete, one doesn't even have any of the cardboard fiddly bits punched out... some are even on tape! So, getting my KryoFlux up and running will be a weekend project sometime. In the meantime, I know some people have offered to image some of my other masters for games etc. If that offer is still open, I can easily (now that is) dig them out and get them ready for imaging either by myself or members.

 

The offer to trade games for disk loaning is no longer an option since I've sold off most of my collection to continue funding the preservation project. But if you would prefer someone else to dump the software and are still willing to loan your disks out, I can connect you with some US-based colleagues that can assist.

Edited June 28, 2018 by Farb

[avanze]

I have some disks not yet in the collection. When I get the funds and time to get a SuperCard Pro, I will back them up and upload them here.

The Disks I have are

Atari Smash Hits 1 - 7.

I see the list is currently missing 2,3,4.

 

Please do, it would be a great service to have these disks saved.

[+DrVenkman]

 

Where does this perception come from that the only way to make use of ATX files on real hardware is to write them back to physical media? There are two solutions you can use today to do this:

 

1. APE with the VAPI.dll (should run almost everything)

2. SDrive Max (this already supports many ATX files today and we are actively working on getting more advanced timing-based protections working).

 

1. Well, as those who haunt the RespeQt threads have picked up on over the last couple years, that software - currently running on a $10 RPiZeroW is my “SIO2PC” solution these days. I don’t need nor want to tether a full-on Windows PC to my vintage gear and pay $50 to use APE. That’s just a non-starter for me and - I think - quite a lot of others.

 

2. And we I replied to Luckybuck, that specific hardware is just not very common or widespread in the community from what I’ve seen, at least compared to other file loading devices.

 

Don’t get me wrong - preserving these files in original format is fantastic from the standpoint of history and archival purposes, and those who have the hardware and time to devote to the cause are appreciated. It’s just a shame that it’s damn near impossible for the wider community to appreciate the fruits of the team’s labor.

[Farb]

2. And we I replied to Luckybuck, that specific hardware is just not very common or widespread in the community from what I’ve seen, at least compared to other file loading devices.

 

I saw those replies and I have a difficult time understanding that reasoning. It's not very common device because it is fairly new. And the only way it will become more common is for people to start using it. The firmware is free, open source and you can build the hardware for around $20 if you already have an SIO cable lying around. If a barrier to adoption is lack of skill to build/program one, then we should focus efforts to address that.

 

The more people there are using SDrive Max, the more motivation there is to improve it and the more likely others will get involved. And if we can achieve good ATX support on this low-memory device, it will give others access to a working implementation that they can use to implement support in their more "popular" file loading device projects. I've been waiting years to see this happen and it simply hasn't which is why I got involved with SDrive Max because it was open and easy to jump into.

 

The point of my previous post was to highlight the questionable practicality of continuing to rely on magnetic media. I'd hate to see our small community's efforts diluted spending time on efforts like developing new write-back hardware when it doesn't really solve the problem long-term. IMHO, an aspect of preservation is making sure people can use this software long after its original hardware is no longer practical to use either due to cost or availability. I believe projects like EclaireXL and SDrive Max (and others obviously) that are are open from both a hardware and software perspective are well worth supporting because they work to accomplish that.

 

It’s just a shame that it’s damn near impossible for the wider community to appreciate the fruits of the team’s labor.

We clearly have very different definitions of "near impossible". We've already discussed no less than 4 possible ways to consume the results of this project:

 

1. Altirra

2. APE/VAPI

3. SDrive Max

4. SuperCard Pro write-back

 

It may sound like I'm being pedantic but I want to make sure misinformation is not being spread. Various people's statements such as "can't actually use on my real hardware", "near impossible to appreciate[use]" and "exclusive focus on emulation" are simply not accurate and will hurt perception of the value of the project. If people start to believe that the output of this project is only for a certain elite that have exclusive access to unobtainable hardware or software, it will die. It's part of my job to make sure that doesn't happen and I've been doing everything I can to prevent that :-)

Edited June 28, 2018 by Farb

[ijor]

Thats the part I dont understand. That specific hardware is far from common among the wider Atari 8-bit retrocommunity, especially outside of Europe. Much more common are other flashcarts like the UNO, Ultimate and Atarimax carts, and generic FTDI-based SIO2PC devices connected to boxes running APE, RespeQt or AspeQt. None of that hardware allows use of these archived ATX files, which is a frankly a bit of a tragedy in our scene.

...

currently running on a $10 RPiZeroW is my “SIO2PC” solution these days ...

 

I'm afraid those cartridge loaders are not suitable for running copy protected disk images as ATX. You need something attached to the SIO bus, or may be to the PBI, not a cartridge.

 

Regarding RespeQT/AspeQT. I'm not very familiar with the software, and I can't tell for sure how easy or difficult would be to implement support for ATX images. Copy protected images require strict and accurate timing. It won't be able to run reliably on every single platform and hardware solution. But may be this is not the right place to push for support. I suspect that the RespeQt team doesn't follow this thread. May be better to post at their own dedicated threads. We'll gladly provide any help if it is needed.

[lemiel]

Sorry, didn't see here earlier that Kris built new version of SDrive-NG called SDrive-MAX with that capabilities.

It could be very nice device.

But how many users use it and know about it?

 

(To be honest I have not yet finished translation job for Kris...)

Edited June 28, 2018 by lemiel

[Farb]

But how many users use it and know about it?

 

Not sure, that's what I'm attempting to help with here

 

I forget that there is only a German page for it. Can I assist with the English translation?

[toddtmw]

 

Not sure, that's what I'm attempting to help with here

 

I forget that there is only a German page for it. Can I assist with the English translation?

Yes, please!

 

Is this something we build using standard components? Or is this being sold?

 

Thank you.

[lemiel]

I think you have to translate it. That's beyond my capabilities.

Maybe in new topic here.

[80s_Atari_Guy]

Is SDrive Max, much better than sio2sd ?

Or, could sio2sd make use of these files ?

[+remowilliams]

I'm not completely sure. I use HxC in GUI form to convert to the Kryoflux raw flux files. The DTC line is "mostly" right... You would also need to set the device number (-d1 or -d0 depending on which is your 5.25" drive.) If your are going to use the disk with a real Atari floppy drive, you'll probably also want to use a DD floppy drive to write with. So, the -ks2 may not be necessary, and you might need to convert to file to a true 40 track set (00-39 i/o 00-78 even numbers.) Don't know, been wanting to get a true DD drive for writing with, but haven't gotten a working one yet.

 

I'm using an 80 track drive for reading/writing. So I tested that command set with the Kennedy Approach .atx and it wrote out the disk, but the protection failed with 'HARDWARE FAILURE !' during loading.

 

I then went back to my own original Kryoflux .raw set of data and did the write back again, and it loaded properly.

 

.atx > .scp > .raw conversion worked for MULE

 

.atx > .scp > .raw did not work for Archon II. However .scp > .raw did work. So the .atx > .scp > .raw conversion may process have issues there.

 

This probably isn't of use to anyone, but I posted it anyway

[Pheonix]

Great Though, from what I've read you got lucky with the disks. An 80 track drive uses a narrower write head than a 40 track drive. This leads to the read head on the 40 track drive possibly picking up flux patterns from the edges that the 80 track drive's write left behind. This can cause data corruption on the read. I'm told that the severity can vary greatly depending on the 2 drives in question (as well as the media itself.) So, get a good combination of drives and you'll rarely have an issue. Get a bad combination and you'll almost always have an issue.

 

So, doing the .atx > .scp > .raw could (theoretically,) work if you did it again. Not saying that was the problem. There very well could be an issue with the conversion process. It's just a thought.

[ijor]

I'm using an 80 track drive for reading/writing. So I tested that command set with the Kennedy Approach .atx and it wrote out the disk, but the protection failed with 'HARDWARE FAILURE !' during loading.

I then went back to my own original Kryoflux .raw set of data and did the write back again, and it loaded properly.

.atx > .scp > .raw conversion worked for MULE

.atx > .scp > .raw did not work for Archon II. However .scp > .raw did work. So the .atx > .scp > .raw conversion may process have issues there.

 

This kind of conversion process is affected by several factors. First the whole thing depends on the write splice location. If it is not aligned to the index location then it will probably fail. The 3 titles you converted usually do are aligned to the index hole. arawconv doesn't properly convert the protection on Archon II.

 

Though, from what I've read you got lucky with the disks. An 80 track drive uses a narrower write head than a 40 track drive. This leads to the read head on the 40 track drive possibly picking up flux patterns from the edges that the 80 track drive's write left behind.

 

The problem only happens when the same disk is written either by a 40 track drive, or by an 80 tracks drive but not in double step mode. If the disk is virgin as it comes from factory, or it is degaussed (bulk erased), and you write only on the 80 track drives and only using double step, then it should read without problems on the 40 tracks drive.

 

[Pheonix]

Yes, a virgin disk is unlikely to have this problem. Or a degaussed disk. But the edge trash is not the only issue, just the main issue. Signal strength can also have an impact. Some 40 track drives will not recognize the transitions on the disk because the narrower track produces a signal strength below that drives threshold. Not near as common, and usually only with older 40 track drives. It's just best, whenever possible, to use a 40 track drive to write a disk your going to use in a 40 track drive. As an example, I have yet to get a disk written back on my 80 track flippy drive to be successfully read on my 1541 drive. Though, the 1571 drive will read it, usually. I plan to get a 40 track drive to attach to my Kryoflux in the future.

[+remowilliams]

This kind of conversion process is affected by several factors. First the whole thing depends on the write splice location. If it is not aligned to the index location then it will probably fail. The 3 titles you converted usually do are aligned to the index hole. arawconv doesn't properly convert the protection on Archon II.

 

Ah that explains the full chain conversion issue (.atx > .scp > .raw) with Archon II. I'll probably try some more to see how it goes.

 

Yeah the write splice thing leaves this as sort of luck with the Kryo, however a good amount of things (.scp > .raw anyway) seem to be working when tested. Including Zinderneuf which I just wrote out

 

 

As an example, I have yet to get a disk written back on my 80 track flippy drive to be successfully read on my 1541 drive. Though, the 1571 drive will read it, usually. I plan to get a 40 track drive to attach to my Kryoflux in the future.

 

Interesting. I know I've written Commodore images out with this same 80 track drive though it likely was one of the 1571s hooked up for read, but I'm fairly sure I've read them in the 1541-II as well.

[Pheonix]

You have a good 80 track drive Maybe it writes with a slightly stronger EM field than mine. If your writes are consistently read by 40 track drives (especially those from 8-bit systems,) then hang onto it and keep it in good shape. Or better yet, sell it to me OK, that last bit was a joke. Besides, no money right now.

[ijor]

Yeah the write splice thing leaves this as sort of luck, however a good amount of things (.scp > .raw anyway) seem to be working when tested. Including Zinderneuf which I just wrote out

 

The write splice issue is not specific to the conversion. It would happen also if you use raw files directly that were not converted and produced directly with the Kryoflux.

 

Murder on the Zinerneuf should be ok. Almost all ECA US releases are index hole aligned.