Atari 400/800 - The Chip Disk Backup/Developmet System by Spartan

[ijor]

Then the bitwriter software might be wrong. But I don't know for sure if that's what is making the copy to fail in your case, because the bitwriter copy bits and not sectors. The only problem is that the even when copying bits, the software must detect a reasonable write splice. And if it misses some sectors it might select a wrong write splice location. But again, check the skew align issue.

 

I just checked and there are multiple versions. But all the ones I checked have at least a few tracks with 34 sectors. Conceivable, you might have a very different version with none. Yes, it looks like the 130XE version.

[tep392]

It could be that the bitwriter s/w misidentified the number of sectors on the long tracks. As you said, it doesn't matter though since it's still going to copy all the bits.

 

I just re-copied track 4, making sure the fuzzy sector feature was enabled and that fixed it. The copy works now! Skew didn't seem to be a factor because I used 3.02, not 3.12 which is the skew version of the archiver/editor. So copying took multiple steps.

 

1) copy entire disk with 3.02 making sure phantom sectors are enabled with P+ option. If you know which tracks are long ahead of time you can set it to not copy them. I would sometimes get logic read-write errors as it tried to write the long tracks, so it may actually be necessary to identify the long tracks first and exclude them.

2) copy long tracks with bitwriter program. If you are copying an original disk, make sure "write splice" is enabled. If it's a 2nd gen copy, the option is not required. When using the long track copy option, it will ask how many sectors per track for the tracks you want to copy. I just entered 18 and let it do it's scan so I could identify the number of sectors for each long track, which was 21 for this disk. Then I aborted the copy and restarted using 21 as the parameter. It then only copied the tracks with 21 sectors.

 

Perhaps it would have been better to reverse the order I used and identify/copy the long tracks first, then use the 3.02 program to copy the remaining tracks to avoid the write errors that slowed it down.

 

It was fun using the Bitwriter to do what is was intended for!

[+DjayBee]

This seems to be a different version of Syncalc than the ones currently available as ATX. As ijor wrote, these all have several tracks with 34 sectors and IIRC most of these sectors are read during load of the program. If yours only has 21 sector tracks it must be different.

 

Please let somebody dump it with Kryoflux or SCP.

At least post a plain sector copy here to compare your version to what we have.

[tep392]

I'll post some pics later of the disks, and manual pages with publication dates. If someone in the Peoria IL area has a Kryoflux, I'll let them copy it, but I don't want to mail the original and risk loss/damage. These are the sector counts identified by the bitwriter.

 

sector count - track

0 - track 15

17 - track 04

18 - tracks 0-3, 8-10, 18-20, 26-28, 39

21 - tracks 5-7, 11-14, 16-17, 21-25, 29-38

[tep392]

The template book is dated 1985 and the main manual is dated 1983, 1985. I don't think these are unique. I see them on Ebay all the time. I re-checked using the 3.02 editor program and it confirmed the sector counts from the bitwriter program.

 

An interesting observation of this disk is that it loads from different tracks if I boot on my 800 with Axlon RAM (tracks 5-14) than it does on my 800XL with U1MB (tracks 29-38). Also, it only supports 64K extra RAM on the 800XL (84k free) while supporting 256K Axlon on the 800 (245k free). So the 800 is the superior machine for SynCalc.

 

[ijor]

The template book is dated 1985 and the main manual is dated 1983, 1985. I don't think these are unique. I see them on Ebay all the time. I re-checked using the 3.02 editor program and it confirmed the sector counts from the bitwriter program.

 

I'm afraid the pictures are not very useful for distinguishing the (minor) version. And certainly not the manual. Many titles were recorded in multiple versions that I used to call "types". The actual software might be exactly the same. But the loader or the protection might be different.

 

I understand you are reluctant to ship the disk, but as DjayBee suggested, making a plain sector copy will probably let us know if it is a different version than the ones we have or not.

 

I wouldn't be surprised that the SA software is missing some sectors on those tracks. The layout is very, very tricky. Just that as we said, the wrong sector level analysis is not fatal for the bitwriter.

 

[tep392]

 

I'm afraid the pictures are not very useful for distinguishing the (minor) version. And certainly not the manual. Many titles were recorded in multiple versions that I used to call "types". The actual software might be exactly the same. But the loader or the protection might be different.

 

I understand you are reluctant to ship the disk, but as DjayBee suggested, making a plain sector copy will probably let us know if it is a different version than the ones we have or not.

 

I wouldn't be surprised that the SA software is missing some sectors on those tracks. The layout is very, very tricky. Just that as we said, the wrong sector level analysis is not fatal for the bitwriter.

 

Is there a program I can use to make an image file that I could then upload for you to inspect?

[tep392]

I did a few track and sector traces that might be helpful. The track trace counts how many sectors have been read from each track. It is the sum of booting syncalc and booting the SA trace progam, which is necessary to download the data from the drive. Tracks 16,17,20 are the tracer program. Tracks 5-14 are the main program for Syncalc, (Axlon version). You can see that some tracks have 34 sectors read, but when you look at the sector trace I did, it appears some sectors are read multiple times, or they could be duplicate sectors numbers. There is limited space to store the sectors, so I didn't quite get the entire track 7 traced.

 

[ijor]

Is there a program I can use to make an image file that I could then upload for you to inspect?

 

Just a simple sector copier that ignores read errors should be fine for this specific purpose. Probably DjayBee can suggest the most suitable ones.

[ijor]

I wouldn't be surprised that the SA software is missing some sectors on those tracks. The layout is very, very tricky. Just that as we said, the wrong sector level analysis is not fatal for the bitwriter.

 

This is partial hex dump of the track 7 at the FM byte level, headers are highlighted with read, data marks with green:

 

 

You can see that one header is right after the other. It is very difficult to read the second one. Programs like the Archiver or the Happy issue read address commands to the FDC to get all the headers on the track. There are only 4 bytes between both headers. But the FDC is very slow, it takes several cycles between the end of the header until actually ending the command and being ready for receiving a new command. Plus it also takes several cycles between receiving the next command and actually starting looking for a sector header. And the software side at the CPU also has some overhead.

 

So chances that after reading the first header, waiting for the command completion, looping to issue another read address command, the FDC overhead to actually looking for a sync mark ... too late, the sync mark for the second header is already over.

[+DjayBee]

Use Disk Wizard II to create the sector copy. The link points to a post of mine where I recently uploaded an image of it.

 

If you want to know more about the protection of SynCalc then look here. Post #40 of this thread contains an ATR with some tools (README inside).

In case you want to run SYNLIST.XEX from this toolbox against your copy of SynCalc:
The starting sectors for the currently available dump of the 1985 version are: 93, 291 and 525

[tep392]

Are those two sectors with the same sector number? I'm not familar with the FDC. If two sectors with duplicate sector numbers were spaced so closely, it would not be reliable to read the second sector unless it was done at just the right time. If duplicate sectors can be read by the application, then I don't know why it would be difficult for the archiver program to use an algorithm that would find the duplicates. Seems like that would be a very fundamental requirement of any sector copier.

 

edit: thinking about this more, I guess I don't understand how that second header can be read reliably.

 

2nd edit: I found some documentation on the FDC so now understand it is scanning every byte in a track until it finds the header with matching track#, sector# and crc. So I'm back to thinking it should not be difficult to find all the sectors by sequentially requesting the same sector number. Looking at the sector scan I posted yesterday, it appears that is how they are actually read as the program is loaded.

[ijor]

Are those two sectors with the same sector number? I'm not familar with the FDC. If two sectors with duplicate sector numbers were spaced so closely, it would not be reliable to read the second sector unless it was done at just the right time. If duplicate sectors can be read by the application, then I don't know why it would be difficult for the archiver program to use an algorithm that would find the duplicates. Seems like that would be a very fundamental requirement of any sector copier.

 

edit: thinking about this more, I guess I don't understand how that second header can be read reliably.

 

2nd edit: I found some documentation on the FDC so now understand it is scanning every byte in a track until it finds the header with matching track#, sector# and crc. So I'm back to thinking it should not be difficult to find all the sectors by sequentially requesting the same sector number. Looking at the sector scan I posted yesterday, it appears that is how they are actually read as the program is loaded.

 

Those headers have different sector numbers. The first is sector 10, the second is sector 11.

 

The task is always much easier for the software that is checking the protection than for the copier. The copier must work (mostly) blindly, it doesn't know what or where to look. It can't try all the conceivable possibilities, neither retry too much, because otherwise it would be awfully slow and the program won't fit in the available memory. The protection check OTOH, it knows exactly what it is looking. It knows on which track, which sector, and can afford to performs several retries because it would do it only on specific sectors.

 

Hardware copiers like The Archiver or The Happy don't work like that. They don't request the same sector multiple times blindly. That would be too slow. And still it wouldn't be too reliably, sectors might still be overlapped and hidden (not like this one that the actual headers are almost overlapped).

 

So these copiers first perform a so called track scan by reading all the headers present in the track. Only later they try to read the corresponding sectors.

 

Also note that The Chip/Archiver is not a very powerful hardware in comparison to enhancements like the Happy. In doesn't have much extra RAM. Some things that would be possibly with the Happy are very difficult, if possible at all, here.

[+DjayBee]

The protection check OTOH, it knows exactly what it is looking. It knows on which track, which sector, and can afford to performs several retries because it would do it only on specific sectors.

 

IIRC this is partially correct. Synapse's protection knows exactly what it is looking for but it reads each sector only once. If the drive does not return the expected one then the load will fail.

 

All sectors of a "file" are chained in a loosely similar way to Atari DOS. The chaining information is EORed with the current sector's number and is located in varying offsets from the start of each sector.

[ijor]

IIRC this is partially correct. Synapse's protection knows exactly what it is looking for but it reads each sector only once. If the drive does not return the expected one then the load will fail.

 

Hi DjayBee. I wasn't talking specifically about this protection. But in general about how different conceptually is to detect which protection was used, than to confirm if a specific protection is present or not.

[tep392]

This has been very educational. I can see that backing up the more sophisticated copy protection schemes requires knowledge, analysis and some trial and error. Happy was smart to do the up front work and provide files to their customers to make it user friendly. I feel like CSS kind of left people out to dry with the Archiver products by making them figure out the details needed to make a backup on their own. While the SA and Bitwriter are a powerful hardware and software, it is far from user friendly.

[ijor]

Happy was smart to do the up front work and provide files to their customers to make it user friendly. I feel like CSS kind of left people out to dry with the Archiver products by making them figure out the details needed to make a backup on their own. While the SA and Bitwriter are a powerful hardware and software, it is far from user friendly.

 

I always liked Happy products more. But to be honest, not sure it is fair comparison in this case. In first place the Happy doesn't really copy this disk, the BitWriter does. Also I think they have different targets. The Happy was more a product to the general public, specially with the track buffer that makes it so fast. SA products, and the original The Chip, IMHO, really targeted the hacker.

Edited April 11, 2018 by ijor

[tep392]

 

I always liked Happy products more. But to be honest, not sure it is fair comparison in this case. In first place the Happy doesn't really copy this disk, the BitWriter does. Also I think they have different targets. The Happy was more a product to the general public, specially with the track buffer that makes it so fast. SA products, and the original The Chip, IMHO, really targeted the hacker.

Although the Happy doesn't produce a true copy, it's a good option for someone who is just looking for a way to run off a backup to keep the original safe. The speed boost is of course very welcome. If I had a second 1050, I would put a happy in it just so I could have both. I have two 810's, one Chip and one Happy.

 

Now I'm wondering what's actually on the Happy backup. I created one on my 810 Happy drive. What do the long tracks look like on the Happy backup? Looks like I have something to do tonight.

[Zarxx]

Here's a dump of mine from A8 and the SCP GUI. It's the only title that I've had trouble making a 100% reliable backup either with the BitWriter or SCP write.

 

I will often see CRC errors on the long tracks, where the original has none. 50/50 chance of loading successfully.

 

SynCalc Dump.zip

 

SynCalc (1983)(Synapse Software)(US) - T4 (17s) - Weak s16, T5-6, 16-17 (21s) - Duplicate s7, 9, 12 x2, T7, 11-14, 21-25 (34s) - Duplicate s2-5, 7-8, 10, 13-14, 18 x2, T15, 27 - Unformatted

 

[+DjayBee]

I will often see CRC errors on the long tracks, where the original has none. 50/50 chance of loading successfully.

 

Yes, it is somehow fascinating that these tracks must have overlapping sectors but all these sectors read with a correct CRC.

 

Can you please convert the dumps to ATX format?

[ijor]

Here's a dump of mine from A8 and the SCP GUI. It's the only title that I've had trouble making a 100% reliable backup either with the BitWriter or SCP write.

 

I will often see CRC errors on the long tracks, where the original has none. 50/50 chance of loading successfully.

 

This is the old version, without 130XE, support. The protection is very similar but not the same.

 

The CRC errors on the copy are one per track and always at the same sector and position? If so, probably the issue is not locating a correct write splice location.

[Zarxx]

 

Yes, it is somehow fascinating that these tracks must have overlapping sectors but all these sectors read with a correct CRC.

 

Can you please convert the dumps to ATX format?

 

Sure.

 

SynCalc-ATX.zip

 

 

 

This is the old version, without 130XE, support. The protection is very similar but not the same.

 

The CRC errors on the copy are one per track and always at the same sector and position? If so, probably the issue is not locating a correct write splice location.

 

Yep, saw that. Wasn't sure if you had a dump of this one and if it was any use/interest. Yep WS, my bane. Same track/sector each time, not all the the long tracks tho'.

[Binarygeek]

It could be that the bitwriter s/w misidentified the number of sectors on the long tracks. As you said, it doesn't matter though since it's still going to copy all the bits.

 

I just re-copied track 4, making sure the fuzzy sector feature was enabled and that fixed it. The copy works now! Skew didn't seem to be a factor because I used 3.02, not 3.12 which is the skew version of the archiver/editor. So copying took multiple steps.

 

1) copy entire disk with 3.02 making sure phantom sectors are enabled with P+ option. If you know which tracks are long ahead of time you can set it to not copy them. I would sometimes get logic read-write errors as it tried to write the long tracks, so it may actually be necessary to identify the long tracks first and exclude them.

2) copy long tracks with bitwriter program. If you are copying an original disk, make sure "write splice" is enabled. If it's a 2nd gen copy, the option is not required. When using the long track copy option, it will ask how many sectors per track for the tracks you want to copy. I just entered 18 and let it do it's scan so I could identify the number of sectors for each long track, which was 21 for this disk. Then I aborted the copy and restarted using 21 as the parameter. It then only copied the tracks with 21 sectors.

 

Perhaps it would have been better to reverse the order I used and identify/copy the long tracks first, then use the 3.02 program to copy the remaining tracks to avoid the write errors that slowed it down.

 

It was fun using the Bitwriter to do what is was intended for!

Hey folks

 

IIRC (and I absolutely do), I could always duplicate a fuzzy sector disk (specifically the first Alternate Reality) using the 1050 Happy Archiver and it's custom formatting/write option. The key was to always write the format and data to a disk that had NEVER been formatted. Since it's never been formatted, it will always read random data. I forgot the EXACT steps I used to do this (I'm working on this again for fun), but it wasn't difficult and didn't take long. The end result would be, say reading sector 720, the sector would only have 55 bytes written to it. When reading the sector, the first 55 bytes would always be constant, while the remainder of the bytes would always be changing. This was how I copied Alternate Reality, and actually sent a copy to Richard Adams. Told him I only used the Happy Archiver. Probably took him all of 6 minutes to figure out the rest. Oh, my were those days great!

[ijor]

Yes, it is somehow fascinating that these tracks must have overlapping sectors but all these sectors read with a correct CRC.

 

This is the very definition of a super track. The sectors are overlapped one inside the other in such a way to have a correct CRC. The idea is that you must write this track in a single pass, and not format and then write the sectors. But the FDC has some limitations on what it can write at format time. Some bytes, like $F7 or $F5 are escape codes and can't be written at format time. So these tracks can't be written by the FDC and then defeat the Happy. You need something that can write without the FDC to copy these tracks.

 

[ijor]

IIRC (and I absolutely do), I could always duplicate a fuzzy sector disk (specifically the first Alternate Reality) using the 1050 Happy Archiver and it's custom formatting/write option. The key was to always write the format and data to a disk that had NEVER been formatted. Since it's never been formatted, it will always read random data. I forgot the EXACT steps I used to do this (I'm working on this again for fun), but it wasn't difficult and didn't take long. The end result would be, say reading sector 720, the sector would only have 55 bytes written to it. When reading the sector, the first 55 bytes would always be constant, while the remainder of the bytes would always be changing. This was how I copied Alternate Reality, and actually sent a copy to Richard Adams. Told him I only used the Happy Archiver. Probably took him all of 6 minutes to figure out the rest. Oh, my were those days great!

 

That's how many original disks with weak bits were actually duplicated. Of course not with the Happy Archiver, but yes using a virgin unformatted disk and not writing over the area that wanted to have weak bits.

 

I'm not quite sure how you could do that with the Happy Archiver. Yes, you can control how many bytes are written when writing the sector. But that's not enough. You must also somehow use a partial format, and you have multiple sectors with weak bits in this specific case. Otherwise the track is not virgin anymore after being formatted.