Lazer -> Happy -> BitWriter 1050

[E474]

Hi,

 

I have 2 (working) 1050 drives, both with Lazer (clone?) upgrades, and another 1050 with a Happy (clone?) upgrade in it. I can reprogram the Lazer drives so that they emulate The Chip upgrade, so I can use the Archiver/Editor software. I can edit track layouts, etc., and making backups of disks seems to work. I tried programming the drives using the Super Archiver version 3 software (which I think is the software that the BitWriter uses), but this doesn't seem to work. Is it possible to use the BitWriter software with the hardware I have, or is this a non-starter?

 

Any help on clearing this up would be appreciated - I'ld like to get a BitWriter, but wanted to check that it can't be emulated by the upgrades I already have.

[+Nezgar]

The archiver emulator makes it behave as an 810 archiver. Super archiver is a hardware board for the 1050 that adds a bit more functionality compared to the 810 version. (Ie double density and ultraspeed). The bitwriter is a hardware addon to that which adds full track bit level copying. Those can't be emulated by happy.

 

Also, generally the base happy / lazer backup utility is better at just copying stuff. Archiver software is nice for editing / creating custom tracks.

[ndary]

The CHIP can run the Older Super Archiver software (v1.x), which can edit tracks but limited in number of sectors etc..

the Super Archiver v3 software runs on the 1050 Archiver upgrade, it can copy SD, & ED protected disks.. make fussy/phantom sectors etc..

 

the BitWriter is a hardware addon to the 1050 archiver that with its software you can copy the EA SUPER TRACKS, which considered the tracks that no one can copy.

 

the main use of the Chip, 1050 Archiver, BitWriter is to create custom tracks or copy protected tracks and the copy can run on any standard disks drive,

copies of protected software that are done on Happy/Lazer will run on Happy/Lazer drivers only

[+Nezgar]

copies of protected software that are done on Happy/Lazer will run on Happy/Lazer drivers only

 

This is only true for copies of 'complex' protected software copied using a Happy/Lazer PDB function. Most basic protections copied by Happy/Laser will work on any drive. (Extra, missing, duplicate, error sectors)

[E474]

So does the BitWriter slow down the drive RPM, which means it has a better chance of sampling data from the disk (and presumably writing it back)?

 

I remember you used to be able to slow down 810's to write individual bad sectors, but I think the BitWriter is doing a bit more than that.

 

I think that the Happy can backup most disks, but PDB (Pre-Defined Backup(?)) files copy disks in a particular way, and presumably contain code in specially tagged sectors that the Happy 1050 loads and executes when a PDB copied disk is used?

 

Both the Happy and the BitWriter talk to the drive via the FDC, so I'm wondering if the Happy is actually capable of reading a whole track like the BitWriter does, but that this wasn't ever implemented (in 8-bit software, or code loaded into the 1050)?

[+DrVenkman]

Both the Happy and the BitWriter talk to the drive via the FDC, so I'm wondering if the Happy is actually capable of reading a whole track like the BitWriter does, but that this wasn't ever implemented (in 8-bit software, or code loaded into the 1050)?

In the case of the Happy 1050 at least, the board includes a full 6502 CPU (replacing the stock 6507) and additional ram. The additional ram allows track buffering as well as space for custom code.

[ijor]

Both the Happy and the BitWriter talk to the drive via the FDC, so I'm wondering if the Happy is actually capable of reading a whole track like the BitWriter does, but that this wasn't ever implemented (in 8-bit software, or code loaded into the 1050)?

 

No, the BitWriter bypasses the FDC. It works at a lower level by reading and writing directly from and to the drive. This is required for some protections that can't be recreated with the FDC. The most common case is perhaps the mentioned so called Supertracks.

[+Nezgar]

So does the BitWriter slow down the drive RPM, which means it has a better chance of sampling data from the disk (and presumably writing it back)?

 

I remember you used to be able to slow down 810's to write individual bad sectors, but I think the BitWriter is doing a bit more than that.

 

I think that the Happy can backup most disks, but PDB (Pre-Defined Backup(?)) files copy disks in a particular way, and presumably contain code in specially tagged sectors that the Happy 1050 loads and executes when a PDB copied disk is used?

 

Both the Happy and the BitWriter talk to the drive via the FDC, so I'm wondering if the Happy is actually capable of reading a whole track like the BitWriter does, but that this wasn't ever implemented (in 8-bit software, or code loaded into the 1050)?

 

The BitWriter actually can set the RPM to FOUR different speeds! Slower RPM = can write more sectors on the track. Normally at 288RPM you can't write more than 19 sectors without writing over the beginning of the track.

 

Yes, PDB disks load special code into the extra RAM of the Happy drive to make it 'emulate' the responses the program expects when testing the copy protection. These copied disks will not work in other drives.

 

The Happy can read a whole track at a time, and uses this normally for its promoted high-speed track buffer for general use, but still relies on the ability of the controller chip to write the data. 1050's used either a WD2793 or WD2797 controller chip. Some advanced protections use methods that cannot be written by this controller, so the happy cannot reproduce them.

 

BitWriter gets past this by bypassing the controller, and directly reading/writing the magnetic fluxes directly to/from disk.

[ijor]

Yes, PDB disks load special code into the extra RAM of the Happy drive to make it 'emulate' the responses the program expects when testing the copy protection. These copied disks will not work in other drives.

 

Most the PDBs, but not all of them. Some PDBs make a copy that runs on any drive. e.g., there is a common 20 sectors protection that the software can't copy with normal means. But because they aren't really 20 full sectors, they are overlapped, they can be created with the FDC and using the normal RPM. The specific PDB just has the "smartness" to format and write this type of track.

Edited June 18, 2018 by ijor

[E474]

I was skimming the datasheet for the WD2793 and it looks like you can get it to read a whole track (type III commands), but there might be some integrity problems in the data area. I wonder if you could read a whole track, send that data over to the 8-bit, then read individual sectors for the data, and then send that over to the 8-bit as well?

[+Nezgar]

The archiver software and happy backup do something similar, reading all the sector headers first to get the track sector order, transmitting that to the computer, then reading the data of the sectors in the next pass.

 

The happy track buffer works by scanning the sector id's of the first track, and then assumes the rest of the disk will use the same order, so it can simply read the data sectors in one revolution for consecutive tracks.

[ijor]

I was skimming the datasheet for the WD2793 and it looks like you can get it to read a whole track (type III commands), but there might be some integrity problems in the data area. I wonder if you could read a whole track, send that data over to the 8-bit, then read individual sectors for the data, and then send that over to the 8-bit as well?

 

Reading is not the main problem. The main problem is writing. You cannot always write what you read, not with the FDC. Some bytes cannot be written during format time because they have special meaning. In addition weak bits cannot be created with the FDC. There are further FDC limitations but they are not used by Atari 8-bit protections.

[E474]

I hooked up my Raspberry Pi running sio2bsd to snoop on the SIO traffic to see what happened when I tried to backup a protected disk. There's a lot of diagnostic/log information about the traffic between the 8-bit and the Lazer, but it occurred to me that if you captured and processed the same SIO traffic between the 8-bit and (for the sake of argument), the BitWriter, you could preserve disks without using a cryoflux? Also, you could probably generate ATX files with a Happy, but probably not create all the disks, unless you manually slowed down the drive using the drive speed potentiometer (which you could monitor with the happy, but not control)?

[+kheller2]

I hooked up my Raspberry Pi running sio2bsd to snoop on the SIO traffic to see what happened when I tried to backup a protected disk. There's a lot of diagnostic/log information about the traffic between the 8-bit and the Lazer, but it occurred to me that if you captured and processed the same SIO traffic between the 8-bit and (for the sake of argument), the BitWriter, you could preserve disks without using a cryoflux? Also, you could probably generate ATX files with a Happy, but probably not create all the disks, unless you manually slowed down the drive using the drive speed potentiometer (which you could monitor with the happy, but not control)?

 

I'm no SIO/Drive expert but...

No, not really. KryoFlux is much closer to the raw magnetic data (but its not prefect). What you are seeing has already been processed and its not ALL the data that could occur. Example: Take the simple concept of the duplicate sector. You would see that same sector pass by a few times with different data IF the 8bit asked to read that sector multiple times. You certainly could analyze that data and find a way to make a somewhat working image of a disk but no more than any software program on the 8bit could. I would think at most you could emulate the floppy responses that a program wants to see after careful study and repetition.

[ijor]

I but it occurred to me that if you captured and processed the same SIO traffic between the 8-bit and (for the sake of argument), the BitWriter, you could preserve disks without using a cryoflux? ...

Yes, in theory that should be possible. It won't be as good as using a modern flux level device like the SCP or the Kryoflux, but it is feasible, yes.

 

Also, you could probably generate ATX files with a Happy, but probably not create all the disks, unless you manually slowed down the drive using the drive speed potentiometer (which you could monitor with the happy, but not control)?

Slowing drive the drive is a hack, it is not as helpful. Almost no original disk was recorded in such a slow RPM. I believe there are only one or two cases (don't remember the titles right now) that have 20 real physical sectors and require using a slower recording frequency. Most other cases with more than 19 sectors have some kind of track layout with short and or overlapped sectors. When copying the disk using a slower RPM you are not really copying the original track layout. The sectors might be the same as the original ones, but the timing would be very different. So the protection might work or it might now. And of course that slowing down the drive has a limit because otherwise it becomes unreadable later at a regular RPM speed. So it can't be used for the so called supertracks that have more than 30 sectors.

[ijor]

You would see that same sector pass by a few times with different data IF the 8bit asked to read that sector multiple times. You certainly could analyze that data and find a way to make a somewhat working image of a disk but no more than any software program on the 8bit could ...

 

I think he is talking about capturing the SIO traffic when using a copier like the BitWriter, not when the program is actually running.

[E474]

Hi,

 

I meant capturing traffic when the BitWriter was sending data back to the 8-bit (or writing it, as the data should be the same).

 

Looking at the SIO traffic when the Lazer is backing up a disk, you can see that it looks like the Lazer copier is reading from memory, not disk sectors directly, so it's probably transferring sector data, and data about the track organisation. For example, the start of a log of SIO traffic for the Lazer disk copier (track based copier):

 

0 -> 'A': $31, $41, $00ff ($72)

1 -> 'r': $31, $72, $8d80 ($b1)

2 -> 'w': $31, $77, $8c80 ($b5)

3 -> 'B': $31, $42, $00ff ($73) US=0

4 -> 'r': $31, $72, $9580 ($b9) US=0

5 -> 'r': $31, $72, $9500 ($39) US=0

6 -> 'r': $31, $72, $9480 ($b8) US=0

7 -> 'r': $31, $72, $9400 ($38) US=0

8 -> 'r': $31, $72, $9380 ($b7) US=0

9 -> 'r': $31, $72, $9300 ($37) US=0

10 -> 'r': $31, $72, $9280 ($b6) US=0

11 -> 'r': $31, $72, $9200 ($36) US=0

12 -> 'r': $31, $72, $9180 ($b5) US=0

13 -> 'r': $31, $72, $9100 ($35) US=0

14 -> 'r': $31, $72, $9080 ($b4) US=0

15 -> 'r': $31, $72, $9000 ($34) US=0

16 -> 'r': $31, $72, $8f80 ($b3) US=0

17 -> 'r': $31, $72, $8f00 ($33) US=0

18 -> 'r': $31, $72, $8e80 ($b2) US=0

19 -> 'r': $31, $72, $8e00 ($32) US=0

20 -> 'r': $31, $72, $8d80 ($b1) US=0

21 -> 'r': $31, $72, $8d00 ($31) US=0

22 -> 'A': $31, $41, $00fe ($71) US=0

23 -> 'r': $31, $72, $8d80 ($b1) US=0

24 -> 'w': $31, $77, $8c80 ($b5) US=0

25 -> 'B': $31, $42, $00fe ($72)

26 -> 'r': $31, $72, $9580 ($b9)

27 -> 'r': $31, $72, $9500 ($39)

28 -> 'r': $31, $72, $9480 ($b8)

29 -> 'r': $31, $72, $9400 ($38)

30 -> 'r': $31, $72, $9380 ($b7)

31 -> 'r': $31, $72, $9300 ($37)

32 -> 'r': $31, $72, $9280 ($b6)

33 -> 'r': $31, $72, $9200 ($36)

34 -> 'r': $31, $72, $9180 ($b5)

35 -> 'r': $31, $72, $9100 ($35)

36 -> 'r': $31, $72, $9080 ($b4)

37 -> 'r': $31, $72, $9000 ($34)

38 -> 'r': $31, $72, $8f80 ($b3)

39 -> 'r': $31, $72, $8f00 ($33)

40 -> 'r': $31, $72, $8e80 ($b2)

41 -> 'r': $31, $72, $8e00 ($32)

42 -> 'r': $31, $72, $8d80 ($b1)

43 -> 'r': $31, $72, $8d00 ($31)

44 -> 'C': $31, $43, $fefe ($72)

45 -> 'D': $31, $44, $feff ($74)

46 -> 'A': $31, $41, $00fd ($70)

47 -> 'r': $31, $72, $8d80 ($b1)

48 -> 'w': $31, $77, $8c80 ($b5)

49 -> 'B': $31, $42, $00fd ($71) US=0

50 -> 'r': $31, $72, $9580 ($b9) US=0

51 -> 'r': $31, $72, $9500 ($39) US=0

52 -> 'r': $31, $72, $9480 ($b8) US=0

53 -> 'r': $31, $72, $9400 ($38) US=0

54 -> 'r': $31, $72, $9380 ($b7) US=0

55 -> 'r': $31, $72, $9300 ($37) US=0

56 -> 'r': $31, $72, $9280 ($b6) US=0

57 -> 'r': $31, $72, $9200 ($36) US=0

58 -> 'r': $31, $72, $9180 ($b5) US=0

59 -> 'r': $31, $72, $9100 ($35) US=0

60 -> 'r': $31, $72, $9080 ($b4) US=0

61 -> 'r': $31, $72, $9000 ($34) US=0

62 -> 'r': $31, $72, $8f80 ($b3) US=0

63 -> 'r': $31, $72, $8f00 ($33) US=0

64 -> 'r': $31, $72, $8e80 ($b2) US=0

65 -> 'r': $31, $72, $8e00 ($32) US=0

66 -> 'r': $31, $72, $8d80 ($b1) US=0

67 -> 'r': $31, $72, $8d00 ($31) US=0

68 -> 'C': $31, $43, $fefd ($71) US=0

69 -> 'D': $31, $44, $fefe ($73) US=0

70 -> 'A': $31, $41, $00fc ($6f) US=0

71 -> 'r': $31, $72, $8d80 ($b1) US=0

72 -> 'w': $31, $77, $8c80 ($b5) US=0

73 -> 'B': $31, $42, $00fc ($70)

74 -> 'r': $31, $72, $9580 ($b9)

75 -> 'r': $31, $72, $9500 ($39)

76 -> 'r': $31, $72, $9480 ($b8)

77 -> 'r': $31, $72, $9400 ($38)

78 -> 'r': $31, $72, $9380 ($b7)

79 -> 'r': $31, $72, $9300 ($37)

80 -> 'r': $31, $72, $9280 ($b6)

81 -> 'r': $31, $72, $9200 ($36)

82 -> 'r': $31, $72, $9180 ($b5)

83 -> 'r': $31, $72, $9100 ($35)

84 -> 'r': $31, $72, $9080 ($b4)

85 -> 'r': $31, $72, $9000 ($34)

86 -> 'r': $31, $72, $8f80 ($b3)

87 -> 'r': $31, $72, $8f00 ($33)

88 -> 'r': $31, $72, $8e80 ($b2)

89 -> 'r': $31, $72, $8e00 ($32)

90 -> 'r': $31, $72, $8d80 ($b1)

91 -> 'r': $31, $72, $8d00 ($31)

92 -> 'C': $31, $43, $fefc ($70)

93 -> 'D': $31, $44, $fefd ($72)

94 -> 'A': $31, $41, $00fb ($6e)

95 -> 'r': $31, $72, $8d80 ($b1)

96 -> 'w': $31, $77, $8c80 ($b5)

97 -> 'B': $31, $42, $00fb ($6f) US=0

98 -> 'r': $31, $72, $9580 ($b9) US=0

99 -> 'r': $31, $72, $9500 ($39) US=0

100 -> 'r': $31, $72, $9480 ($b8) US=0

101 -> 'r': $31, $72, $9400 ($38) US=0

102 -> 'r': $31, $72, $9380 ($b7) US=0

103 -> 'r': $31, $72, $9300 ($37) US=0

104 -> 'r': $31, $72, $9280 ($b6) US=0

105 -> 'r': $31, $72, $9200 ($36) US=0

106 -> 'r': $31, $72, $9180 ($b5) US=0

107 -> 'r': $31, $72, $9100 ($35) US=0

108 -> 'r': $31, $72, $9080 ($b4) US=0

109 -> 'r': $31, $72, $9000 ($34) US=0

110 -> 'r': $31, $72, $8f80 ($b3) US=0

111 -> 'r': $31, $72, $8f00 ($33) US=0

112 -> 'r': $31, $72, $8e80 ($b2) US=0

113 -> 'r': $31, $72, $8e00 ($32) US=0

114 -> 'r': $31, $72, $8d80 ($b1) US=0

115 -> 'r': $31, $72, $8d00 ($31) US=0

116 -> 'C': $31, $43, $fefb ($6f) US=0

117 -> 'D': $31, $44, $fefc ($71) US=0

118 -> 'A': $31, $41, $00fa ($6d) US=0

119 -> 'r': $31, $72, $8d80 ($b1) US=0

120 -> 'w': $31, $77, $8c80 ($b5) US=0

121 -> 'B': $31, $42, $00fa ($6e)

122 -> 'r': $31, $72, $9580 ($b9)

123 -> 'r': $31, $72, $9500 ($39)

 

I'm not sure what the ABC and D commands do, but they seem to change by 1 each time they are sent (going from the checksum).

 

I'm planning on writing some code to play round with the read track diagnostics on the FDC, though I'm not sure how long this will take.