Jump to content
Nezgar

"Weak bits floppy disc protection"

Recommended Posts

So I came across this blog post today: https://scarybeastsecurity.blogspot.com/2020/06/weak-bits-floppy-disc-protection.html

Additional commentary on hacker news: https://news.ycombinator.com/item?id=23664689

 

The article describes creating a 'blank track' with a 8271 controller by writing a track with a single 4096 byte sector, which wraps around the beginning of the track (which is 3125 bytes long), erasing the sector header, effectively resulting in a track with no sector headers at all. The 1771 in the 810, and 2793/2797 used in the 1050 maximum sector size is 1024 bytes long, so that one is not quite viable. :)

 

Anyhow - The article does a good job of explaining how flaky/fuzzy/weak bits can be induced from floppy disk controllers like Intel 8271 and the Western Digital 1770/1772.

 

The article ends with a description of a software method to create a sector with flaky/fuzzy/weak bits by switching the controllers density control (1050 PIA PORTA bit5 / WDC 177x/279x pin 37) from FM to MFM while the write is still in progress. Even though it doesn't result in a 'no-flux area' - testing shows repeated reads of the sector result in different data returned each time.

 

Have any existing Atari drive enhancements made use of such a technique to recreate flaky/fuzzy/weak bits? Seems novel to me, since the bitwriter adds quite a bit of extra hardware to do fuzzy bits, albeit with a lot more precision. Would be interesting to see a proof of concept done with a customized ROM in an Atari drive, potentially used to successfully duplicate a title using such protection.

 

Could one merely install a physical switch to arbitrarily set pin 37 low to set the controller to MFM while writing a sector to achieve a flaky/fuzzy/weak sector?

  • Like 5

Share this post


Link to post
Share on other sites

I can recall reading somewhere about fuzzy sectors on our machine, not sure about bits.

I think fuzzy sectors in that sense were ones that have proper sync/header and some payload but nothing following.

 

Share this post


Link to post
Share on other sites

Hi,

 

    You could try the "MAKE_BAD.COM" program on the realdos.net webpage - that says it can make fuzzy sectors on a Super Archiver "with bit board". I mailed > a year ago asking if I could have a copy of the sources to realdos, but no luck so far!

 

    I guess you could just dissassemble MAKE_BAD.COM, I think Super Archivers do everything via SIO commands rather than programming the drive by uploading code.

 

    Hope this helps!

Share this post


Link to post
Share on other sites
Posted (edited)
3 hours ago, Nezgar said:

(1050 PIA PORTA bit5 / WDC 177x/279x pin 37)

Just a point of clarification here - the 1050 doesn’t have a PIA (6520), it has a RIOT (6532). 

 

Unless I’m missing something in the terminology being used? I admit, I’m no 1050 expert, even though I’ve had my drives open planet of times. 

Edited by DrVenkman
typos

Share this post


Link to post
Share on other sites

Part of the same chip family so probably functionally very close with the ports.

 

Though bit transition behaviour might be one way or the other (ref PORTA vs PORTB in thread elsewhere relating to PIA behaviours).

The transition problem comes down to a few 1.79 MHz machine cycles though, so in the context of a disk at ~ 300 RPM probably wouldn't make much difference.

Share this post


Link to post
Share on other sites
Posted (edited)
7 hours ago, Nezgar said:

The article describes creating a 'blank track' with a 8271 controller by writing a track with a single 4096 byte sector, which wraps around the beginning of the track (which is 3125 bytes long), erasing the sector header, effectively resulting in a track with no sector headers at all. The 1771 in the 810, and 2793/2797 used in the 1050 maximum sector size is 1024 bytes long, so that one is not quite viable. :)

 

Actually the FD1771 supports a maximum sector size of 4K. But there is no need to restore to that trick. The WD FDC format command works in a very different way than the PC FDC. You can easily format a track without sectors if you want. Obviously copiers like the Happy must create blank tracks and it's not a problem at all.

 

Quote

Anyhow - The article does a good job of explaining how flaky/fuzzy/weak bits can be induced from floppy disk controllers like Intel 8271 and the Western Digital 1770/1772.

 

The article ends with a description of a software method to create a sector with flaky/fuzzy/weak bits by switching the controllers density control (1050 PIA PORTA bit5 / WDC 177x/279x pin 37) from FM to MFM while the write is still in progress. Even though it doesn't result in a 'no-flux area' - testing shows repeated reads of the sector result in different data returned each time.

...

Could one merely install a physical switch to arbitrarily set pin 37 low to set the controller to MFM while writing a sector to achieve a flaky/fuzzy/weak sector?

 

No. The article is wrong. You can't create reliably weak bits with such a method. It might work in some cases, but even then if won't be very reliable and might produce weak bits when read in some drives, but not when read on others.

 

IMHO the article is not very accurate at all. His distinction about the different meaning for the flaky/fuzzy/weak terms is his own pure interpretation/speculation.

 

Quote

Have any existing Atari drive enhancements made use of such a technique to recreate flaky/fuzzy/weak bits? Seems novel to me, since the bitwriter adds quite a bit of extra hardware to do fuzzy bits, albeit with a lot more precision. Would be interesting to see a proof of concept done with a customized ROM in an Atari drive, potentially used to successfully duplicate a title using such protection.

The BitWriter is not designed to create weak bits. For this purpose the SuperArchiver has the fuzzy sector maker that is a very simple piece of hardware.

Edited by ijor

Share this post


Link to post
Share on other sites
Posted (edited)

Hi,

 

   This has been on my to-do list of things I was curious about, but the SIO code for writing fuzzy/weak sectors is $62 and/or $71, for the CHIP/Archiver, according to @ebiguy's RespeQt code, at https://github.com/RespeQt/RespeQt/blob/develop/diskimage.cpp (search for "case 0x62" or "case 0x71" to get to the code that emulates/handles this SIO code). As a reference for what the SIO codes are for the Happy and Archiver are, this is a good source!

 

    Hope this helps!

Edited by E474
Missed out 0x71

Share this post


Link to post
Share on other sites
20 hours ago, Rybags said:

I can recall reading somewhere about fuzzy sectors on our machine, not sure about bits.

I think fuzzy sectors in that sense were ones that have proper sync/header and some payload but nothing following.

Yeah, the demonstration in the video at the end of the page uses a BBC Micro with a WDC 1770 controller to write a sector, but change the density signal after sending 6 bytes of the sector. So with creative timing, you can preserve the beginning bytes of the sector and 'fuzz' data after an arbitrary byte.

 

18 hours ago, E474 said:

You could try the "MAKE_BAD.COM" program on the realdos.net webpage - that says it can make fuzzy sectors on a Super Archiver "with bit board".

Yes there are certain hardware upgrades that specifically had a provision for fuzzy sectors. I'm curious if they worked by inhibiting the write signal going to the head (resulting in a true "no flux area"), or this method by telling the controller to switch to MFM creating a flux pattern on the disk that is decoded unpredictably in FM mode. The method dempnstrated suggests a workalike could be done with only a ROM change.

 

17 hours ago, DrVenkman said:

Just a point of clarification here - the 1050 doesn’t have a PIA (6520), it has a RIOT (6532). 

Yep you're entirely right. It was late, and I was reading the Atari 810 Disk Peripheral Device Description, which referred to them as PIA ports. :) Which I guess they are, just as one of multiple functions of the RIOT.

 

14 hours ago, ijor said:

Actually the FD1771 supports a maximum sector size of 4K. But there is no need to restore to that trick. The WD FDC format command works in a very different way than the PC FDC. You can easily format a track without sectors if you want. Obviously copiers like the Happy must create blank tracks and it's not a problem at all.

Ah yes, I see now that the "Type II" commands has a block length flag... Set to 1 for IBM 3470 compatibility the max sector length is 1024 bytes. But I missed that setting the block length flag to 0 can set the sector size in 256 increments of 16 bytes up to 4096 bytes. The author is not using a PC controller in this case, but directly controlling (through BBC micro memory mapped registers) a 1770 controller, so maybe he was just unaware of a specific function for format blank track. :)

 

14 hours ago, ijor said:

You can't create reliably weak bits with such a method. It might work in some cases, but even then if won't be very reliable and might produce weak bits when read in some drives, but not when read on others.

I agree it is not as good as a true 'no flux area' that can be easily be done with added (albeit simple) hardware, but flipping the double-density flag part way through a sector write as a potential way to record pulses that are out of phase & random enough when read back in FM mode to produce unpredictable bytes "most of the time" with only a ROM change (or uploaded code) would be an interesting test.

 

I guess the specific difference in definition are that "weak bits" are when flux transitions happen out-of-phase with the clock boundaries, and "fuzzy bits" are from "no flux areas" where the gain is boosted enough for noise to be decoded as random flux transitions. Reading MFM endoded flux transitions in FM mode would probably mostly fit the "weak bits" definition...

Share this post


Link to post
Share on other sites
4 hours ago, Nezgar said:

Ah yes, I see now that the "Type II" commands has a block length flag... Set to 1 for IBM 3470 compatibility the max sector length is 1024 bytes. But I missed that setting the block length flag to 0 can set the sector size in 256 increments of 16 bytes up to 4096 bytes. The author is not using a PC controller in this case, but directly controlling (through BBC micro memory mapped registers) a 1770 controller, so maybe he was just unaware of a specific function for format blank track. :)

 

No. The author was using an Intel 8271 FDC in this case, which belong to the PC FDC family. Later BBC micro changed the FDC and used the WD1770. So you have BBC models with different FDC chips. But the WD1770 is very different than the FD1771, just the number is almost the same.

 

The FD177X is the earliest FDC generation by WD and was used in the 810. The WD177X is the latest generation and was used on the XF-551. Only the FD177X supports that odd sector size scheme.

 

Quote

I guess the specific difference in definition are that "weak bits" are when flux transitions happen out-of-phase with the clock boundaries, and "fuzzy bits" are from "no flux areas" where the gain is boosted enough for noise to be decoded as random flux transitions.

 

Not at all. There is no relation, historically, between the different terms and the different variations. There wasn't any formal terminology. There were no formal bibliography and most of the information on the subject was pretty much secretive. Each one came up with his own terms. Even with double sectors you have the same things. What is the difference between double or dup sectors, even called Phantom in some cases? No difference, just different terms assigned by different people and companies.

 

Back at the day I never heard the term flaky. I used the term weak because that's the first one I heard, I believe from Happy computers. Later I also heard the term Fuzzy, used by CSS of course (Fuzzy sector maker), also used at the Advanced Copy Protection book. Btw, checking the book now, I see it also uses the term "unstable" and "phantom". So you can see, there are even more terms. May be there were even more used in other platforms.

Share this post


Link to post
Share on other sites
Posted (edited)
20 hours ago, E474 said:

according to @ebiguy's RespeQt code

Thanks for looking at my code as a reference.

I am not the best expert in flux or magnetic things but I spent so much time on Happy/SA program or uploaded code disassembly that I think RespeQt is relatively accurate in Happy/SA emulation (as it can be on Windows with timing issues).

 

13 hours ago, Nezgar said:

I'm curious if they worked by inhibiting the write signal going to the head (resulting in a true "no flux area")

The fuzzy sector maker, as stated by @ijor is a feature of SA hardware. As usual with CSS, this is quite clever as you will see.

The pin 31 of the WDC 2793 is an output to write data to the head (both clock and data).

Upon installation of the SA upgrade, you have to bend pin 31 and connect it to the SA upgrade.

You must also connect another wire from the SA upgrade to a test pin that was initially connected to pin 31.

This way, the WDC pin 31 does not directly manage the write signal to the head anymore.

Instead, inside the SA upgrade, there is a logic that can let the signal go from pin 31 to the head unaltered OR force the write data to 0.

The trick is how the firmware manages to force the write data to 0.

There is no available output pin on the RIOT. The only one available was used for the bank switching.

For anybody, this would be a headache because no output is available. But not for CSS!

Spoiler alert - Stop here if you want to spend some time finding a solution for this problem.

 

The solution: The bank switching is ALSO used to disable the head (force data to 0). How?

The code to write data to the WDC is located in both bank 0 and bank 1.

If you want to make a fuzzy sector with the first 100 bytes OK and the remaining 28 bytes fuzzy, it becomes very easy:

You start writing the first 100 bytes from bank 0, then you switch to bank 1 and continue to write the remaining 28 bytes.

The bank select output pin is an input in the logic gates that forces 0 to the head.

Hats off for such a simple and clever way of doing so much with so few resources.

I like that!!!!! That is what makes Atari still fascinating today.

 

I think this trick deserves a larger audience that's why I'm allowing myself to reference some people who will probably like these details: @flashjazzcat, @phaeron, @_The Doctor__, @Marius

EDIT: I forgot @tf_hh who builds BitWriter replicas these days.

Edited by ebiguy
  • Like 7
  • Thanks 2

Share this post


Link to post
Share on other sites

Hi @ebiguy,

 

    Thanks for the detailed explanation, I don't know very much about the Super Archiver - how is the hardware organised. From your description, and the track buffering, I'm guessing it is a 6502 due to the size of the address space (I think I also saw a comment about 6502 code being uploaded in diskimage.cpp, above), but is there explicit bank selection like in the Happy Rom where you read from a specific address (I think $FFF9 or $FFFA ??) to select one rom bank or the other rom bank, with both occupying  the same address space, or is the bank selection actually based on a more normal address range, for example, bank 1 is always $E000 - $FFFF, and bank 0 is always $C000 - $DFFF, so pin 31 would be tied to one of the higher address lines (via some logic, I guess)? 

 

   From your description I am guessing a lot of the read code, etc., would be in bank 1 so it wouldn't have to worry about the state of the Write head (if that's how it works)?

 

    Any info would be appreciated!

Share this post


Link to post
Share on other sites
Posted (edited)
3 hours ago, E474 said:

I'm guessing it is a 6502 due to the size of the address space

No the CPU is still is a 6507 so the address space is very limited.

You're pointing out something which has always seem weird to me.

Super Archiver contains 2KB of RAM

Part of the ROM is encoded so that you can not disassemble it.

The firmware starts by decoding the ROM into RAM, loosing a lot of the available RAM

That's a pity all this RAM was lost just for protecting the ROM code from being disassembled.

 

3 hours ago, E474 said:

From your description, and the track buffering

There is no track buffering with SA.

One could say that the limited 6507 address space is the reason and the 2KB is not enough for a track.

But again, with the ingenuity of CSS, this was not a show stopper as the BitWriter proves it:

You still have a 6507 but have now a enough RAM to store a full track.

Track buffering like the one found in Happy could have been implemented with BitWriter.

 

3 hours ago, E474 said:

I think I also saw a comment about 6502 code being uploaded in diskimage.cpp

For the CHIP 810, SA 1.0 defined a set of SIO commands to create custom formats, read sector headers,...

The SA upgrade for 1050 along with the SA 3.xx uses the same SIO commands and adds a few ones to deal with high speed and fuzzy sectors.

But the majority of the enhancements are not implemented as new SIO commands.

SA 3.x contains embedded 6507 code which is uploaded to the remaining RAM in the SA upgrade and executed.

A clever choice which allows to change the implementation among software versions (no need to change the firmware).

 

3 hours ago, E474 said:

I think $FFF9 or $FFFA ??

No. The bank switching is controlled through a RIOT PORT A pin.

For example to switch to bank 1 when you are in bank 0, you execute this code

            lda RIOTDRA
            ora #BANKSW
            sta RIOTDRA

 

3 hours ago, E474 said:

so pin 31 would be tied to one of the higher address lines

No, the logic is shown in the diagram designed by Nir Dary

sch_1050sa.thumb.jpg.168a136bc37dc56ad844a6f301d57cec.jpg

 

The WDC 2793 sends data through its output pin 31.

Using a NAND gate, this signal is combined with the output of RIOT pin 10 (the bank switching).

And then inverted using a one leg NAND gate and sent to TP11 which is connected to the drive head.

 

3 hours ago, E474 said:

From your description I am guessing a lot of the read code, etc., would be in bank 1 so it wouldn't have to worry about the state of the Write head (if that's how it works)?

You guessed right.

The code in bank 1 can NOT write anything. So this is the bank for reading, stepping, SIO,...

Bank 0 contains all the code to write a track or a sector.

 

3 hours ago, E474 said:

Any info would be appreciated!

I am always Happy (not a joke) to talk about SA which is a great piece of hardware/software.

 

Edited by ebiguy
  • Like 3

Share this post


Link to post
Share on other sites
Posted (edited)
19 hours ago, ebiguy said:

Instead, inside the SA upgrade, there is a logic that can let the signal go from pin 31 to the head unaltered OR force the write data to 0.

The trick is how the firmware manages to force the write data to 0.

There is no available output pin on the RIOT. The only one available was used for the bank switching.

For anybody, this would be a headache because no output is available. But not for CSS!

...

The solution: The bank switching is ALSO used to disable the head (force data to 0). How?

The code to write data to the WDC is located in both bank 0 and bank 1.

...

No the CPU is still is a 6507 so the address space is very limited.

 

Bob Puff (CSS) is extremely talented and he designed great products. Although, IMHO, they were sometimes a bit "cheap", hackish designs, especially when you consider the prices. That solution was very clever, typical of Bob, but there are more elegant and simple solutions that would allow you to control the FDC pin 31 NAND without affecting the bank switching. One possibility is to use a mux decoder to get 4 separate control signals from two RIOT outputs. This might have increased the cost, but by how much? The BitWriter requires the Archiver and the total price was something like U$150. Doesn't look like an extra small gate would be very significant for such a product. Could probably include a full 6502 as well.

Edited by ijor

Share this post


Link to post
Share on other sites
4 hours ago, ijor said:

there are more elegant and simple solutions

...

This might have increased the cost, but by how much?

...

Could probably include a full 6502 as well.

It would have been very cool to get Bob's feedback about all these remarks and ideas to know if he deliberately discarded these ideas back in the old days and why.

Does he come sometimes on AtariAge? Would be great to start a conversation on this topic...

Share this post


Link to post
Share on other sites
51 minutes ago, ebiguy said:

It would have been very cool to get Bob's feedback about all these remarks and ideas to know if he deliberately discarded these ideas back in the old days and why.

Programming with limitations is always more fun - right? Dropping in a 6502 would be "too easy." :D Just like all the people pushing the limits and making our Atari's do new things even in 2020.

  • Like 1

Share this post


Link to post
Share on other sites

Hello Marceau

 

2 hours ago, ebiguy said:

It would have been very cool to get Bob's feedback about all these remarks and ideas to know if he deliberately discarded these ideas back in the old days and why.

Does he come sometimes on AtariAge? Would be great to start a conversation on this topic...

 

Unfortunately, Bob doesn't visit any known forums, he hardly ever answers to mails.  But if you call him during office hours, he'll talk to you until a customer enters his office.

 

Sincerely

 

Mathy

  • Like 2

Share this post


Link to post
Share on other sites
2 hours ago, ebiguy said:

It would have been very cool to get Bob's feedback about all these remarks and ideas to know if he deliberately discarded these ideas back in the old days and why.

Does he come sometimes on AtariAge? Would be great to start a conversation on this topic...

 

Unfortunately he does not, and he doesn't accept interviews either, I understand. The same as Mike Gustafson (Sparta & ICD), the same as Richard Adams (Happy) ... :(

  • Sad 1

Share this post


Link to post
Share on other sites

I remember the first time that I discovered that custom formats were possible.  It was in the computer lab in high school, and we were trying to copy a friend's Drol disk.  A straight copy, IIRC, would format itself on boot.  We were looking at sectors in a sector editor when we saw something weird happen.  Sometimes, certain sectors seemed to change when we reloaded them!  Weird.  We were able to confirm that this was happening, that somehow certain sectors were "doubled", so we called them "double sectors".  Somehow, in this investigation, we managed to overwrite the doubled sector on his disk so that both sectors read the same thing.  Oh Oh Crap!  I don't recall if maybe his was an Original disk that had a write-enable notch, or if maybe his was a Chip copy.  Also, I don't recall if we ended up with his disk formatting itself, but the end result was the same.  We hosed his game.  So, we were forced to crack it so that he could have his game working again. 😀

 

The track with the double sector also had a bad sector, so we hypothesized that the track still had 18 sectors, but doubled one and skipped another.  We didn't know anything about how soft-sectored disks held sector information, but this made sense to us.

 

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

Hi,

 

   Thanks again @ebiguyfor the even more detailed explanation of the Super Archiver architecture. 

 

   I guess at the time a 6507 based solution would have been very appealing - when compared to a Happy, the only advantage of the Happy would have been a track buffer, something that I'm not convinced makes that much difference anyway, while the Happy would have required a more expensive set of chips. You could argue that a Happy was an example of over-engineering a solution. The only other thing I can think of that a Happy could do, that wasn't available for a Super Archiver was write files to MS-DOS format disks, and I think that was probably just because the utility never got written.

 

   It would be interesting to know what can be done in terms of uploading code to a Super Archiver - is it a matter of defining new SIO commands and adding them to the Command Table, as is the case with a Happy or Speedy, or is it a different mechanism? I remember you can upload code to the original Archiver by putting it in sector 720, but I'm curious what functions are at what ROM addresses, and if they stayed the same with different versions of the Archiver? I'm also wondering if the ROM's included any code "based" on the original 1050 firmware as was the case with the Happy (allegedly).

 

   Edit: Actually, I'm guessing uploaded code can only implement new commands, as otherwise there's no actual way to communicate with the drive over SIO, but it would be nice to know how this works.

Edited by E474
Answering own question

Share this post


Link to post
Share on other sites
1 hour ago, E474 said:

I guess at the time a 6507 based solution would have been very appealing - when compared to a Happy, the only advantage of the Happy would have been a track buffer, something that I'm not convinced makes that much difference anyway, while the Happy would have required a more expensive set of chips.

 

I doubt many would agree that a track buffer is not important, to say the least. The track buffer was the most important feature of the Happy. The much faster loading time thanks to the track buffer was probably the main reason that people bought the Happy in the first place. The track buffer has several other benefits, including the possibility of uploading a completely new OS. The Happy could "emulate" The Chip/Archiver for that reason. But all of these were hacker tools that many people didn't care too much. Use a sector copier with a Happy (or other similar enhancements like the Speedy), and you can never go back to a drive without track buffer.

  • Like 1

Share this post


Link to post
Share on other sites
6 hours ago, E474 said:

is it a matter of defining new SIO commands and adding them to the Command Table, as is the case with a Happy or Speedy, or is it a different mechanism

Yes, there is something similar.

This was already the case with The Chip 810 and Super Archiver 1.0 but it was not documented (I mean I never read anything about it).

In the 810, you could redirect the error routine called when an unknown command has been detected.

This way, you could send code and change the error vector to your code.

When a command is unknown, the Chip jumps to your code through the error vector.

If you don't know the command, then you can call the original error routine or handle the command if it is a good one.

But there was some limitations that I won't explain here.

Anyway, that was already a clever way to support a new command.

With this mechanism, you can not override a standard command.

In the 1050, this 'error vector' has been removed.

Instead, you need to know that the code reading the command table is in RAM.

This is part of the code which is encrypted and decoded to RAM.

So you can overwrite it whenever you want.

It means that you can change all standard command behaviors or add new commands.

 

7 hours ago, E474 said:

I remember you can upload code to the original Archiver by putting it in sector 720

Right. And the code on the original Archiver disk was a list of LDA #$xx, STA $yyyy.

But between the 810 and the 1050, all RAM addresses have changed except for a couple of them.

The only instructions which can work on both drives are: LDA #$80 STA $0195 to open the Chip (810 or 1050)

 

7 hours ago, E474 said:

but I'm curious what functions are at what ROM addresses, and if they stayed the same with different versions of the Archiver?

That's a good question.

And I can not answer it. All versions I have ever seen are 1.6.

I would love to get previous revisions.

So if someone has a different firmware version, please, get in touch!!!

That's really easy to know by launching the diagnostic program in the menu.

 

7 hours ago, E474 said:

I'm also wondering if the ROM's included any code "based" on the original 1050 firmware as was the case with the Happy

No, this is an original creation. It seems to me that everything has been rewritten.

 

5 hours ago, ijor said:

The Happy could "emulate" The Chip/Archiver for that reason.

Emulating the Archiver is very interesting as it lets you use the excellent Super Archiver software.

The reverse is useless because there is not enough RAM on the Archiver upgrade to implement track buffering and you certainly don't want to use the Happy software with your Archiver upgrade until you are forced to (who want a copier where you can not chose source and destination drive???).

The Archiver emulation only supports Archiver 1.0 command set - which is limited.

I made some tests many years ago to copy protected software using an original Archiver upgrade and with the Archiver emulation on a Happy and found that the results are different.

I am not sure but I think I remember that the Archiver emulation was not as good as the real Archiver upgrade.

So, I guess that this is not an emulation (implying accuracy) but an implementation which is compatible at SIO command level.

On this last point, I have no proof as I did not disassemble the emulation code.

 

Share this post


Link to post
Share on other sites
5 hours ago, ebiguy said:

Emulating the Archiver is very interesting as it lets you use the excellent Super Archiver software. The reverse is useless because there is not enough RAM on the Archiver upgrade to implement track buffering ...

 

The SA doesn't have enough RAM to hold the Happy code, let alone the track buffer. It can't even "emulate" a stock 1050 (run the exact original 1050 firmware relocated) as the Happy does.

 

Quote

The Archiver emulation only supports Archiver 1.0 command set - which is limited.

...

I am not sure but I think I remember that the Archiver emulation was not as good as the real Archiver upgrade.

 

The Happy Archiver emulator was written by Bob Puff. It's called "Happy To Chip" and it was released by CSS long before the SA. So obviously it emulates The Chip, not the Super Archiver. But it is perfectly possible to implement an updated version that would emulate the Super Archiver except, of course, for the Fuzzy Sector Maker and the slow speed mods because they are not present at the Happy. Sure Bob could have released an updated version but guess he wasn't interested in creating more competition with his own product.

 

Now, if you mean that the original Chip (and not the Super Archiver) was superior than the emulated Archiver running on the Happy, I'm not sure that would make much sense.

 

Btw, there is also an Archiver for the Happy 810 that was written by Gustafson himself and published by Spartan.

 

  • Like 1

Share this post


Link to post
Share on other sites

Hi @ebiguyand @ijor,

 

   Thanks for the additional information, I hope I get to sit down and have a good hacking session at some point in the future, but my hands are a bit full at the moment.

 

    I'm still not that convinced a track buffer is that much of a benefit. For regular speed I/O, it's a bit quicker, but for high speed I/O, such as if you are running a sector copier, on, for example, a US Doubler, I think you can get the same copy speeds by reading the sectors in a different order (I remember @Nezgar started a thread on copiers that were optimised for reading sectors in a non-sequential order so that the disk didn't have to be formatted with a sector skew to get the highest copy rates).

 

   If you wanted the same effect in a DOS like DOS 2.5, you could also change the sector number that the next sector pointer pointed to (when writing the file), though you would have to squeeze this into the resident FMS part of DOS, somehow. Of course, with file I/O, the reader or writer program might not be transferring data that quickly, e.g. a BASIC program that is working with string data, etc. If you are copying lots of small files in DOS 2.5, I think you might lose the benefits of the track buffer as you would probably be seeking all over the disk as you would keep on needing to access the vtoc each time you wanted to read the disk directory for the next file to copy (I think).

 

   It's quite true that you could use the RAM used by the track buffer for loading an archiver emulator,  but I can't think of any feature in the Happy that the Super Archiver actually lacks/can't do (apart from transfer to IBM PC disks, and I have a feeling that was because the software wasn't written, not couldn't be written), and I think if you are interested in actually making your own custom formats, the best software for this is the Archiver Editor, something that the Happy (as far as I am aware) doesn't have an equivalent for (e.g. there is no track editor program from Happy). On the other hand, I do have some disks made with the Happy Compactor, and also some disks that will only run in a Happy drive, though I'm not sure this is related to the track buffer or not, and if these same disks could have been copied by the Archiver/Super Archiver and would have worked on any drive. I remember reading somewhere that the reason for disk backups that would only run on a Happy drive was more to do with providing a certain amount of legal coverage than any technical reasons, but I don't know if that's actually the case or not.

 

   By the way, does the Super Archiver also slow the disk RPM, or is that something that only the BitWriter does? Also, is there a track editor for the Speedy mods like the Archiver Editor?

Share this post


Link to post
Share on other sites

Yes, there are track editors for the Speedy. In the german Atari Magazin there was a series about copy-protection, originally written by the author for the Happy 1050, but from day one also for the Speedy 1050 (since the publisher requested it) and a little later also for the Turbo 1050. One of the released programs was "ReadTrk.COM", guess what it does... and of course there were several programs to copy various copy-protected disks (without the need for any PDB files) like MS-Copy, MS-Formatter, MS-whatnot, Ultracopy, BackupCopy (several versions), Track Analyzer / Track Editor, Diskmaster (a german program to create and analyze various copy protections) and several other programs.

 

Allthough most americans do not like the 130k format, it was very usefull with a Turbo 1050 enhancement. The Turbo 1050 works with sector interleave, just like USD, Archiver, Super Archiver, etc. One could install the turbo driver manually into page 1 or page 6 and if the disk had the special turbo sector interleave format, it would load and save with 68kBaud. [The built-in utilities of the Turbo 1050 enhancement allowed one to load the turbo driver, create special formats and to backup copy-protected 90k disks; the enhancement was able to slow the drive RPM down to approx. 270 RpM to create bad sectors and maybe other stuff.]

 

There were turbo copy programs that transfered a disk from 90k into 130k (including bootdisks) and furthermore there was a turbo autoload program that a) copied the original bootsectors into the "unused" sectors 1025-1027 (unused by DOS 2.5 and bootdisks that were originally 90k, e.g. most commercial disks) and b) created a driver in the bootsectors, so the disk would load with 68kBaud turbospeed. The created turbo driver used either page 1 or page 6, so programs only worked with turbospeed when they did NOT use page 1 or page 6 themselves. But therefore many commercial (pirated/hacked/cracked) programs could be loaded from such a prepared 130k disk in full turbospeed.

 

Besides, if a disk used the special turbo sector interleave and came with a turbo driver, then reading + writing was faster than a Speedy or Happy 1050. But, thanks to the track buffer, there is a Turbo 1050 emulator available for the Speedy 1050 enhancement...

 

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...