Is this for real? (aka Drive Tech Chat)

[Bryan]

How do you suppose the bad sector trick works?

 

-Bry

[Rybags]

The tape trick works by causing the disk to move slightly - so that a sector will be written but deviate from the track. So, I suppose that the sync marks or some of the data will go missing - but in any case the sector should come up unreadable.

 

The speed trick would probably cause the data to be spread out too thinly and not read back properly.

 

The problem with both is that only very early games, and few later ones used a simple I/O fail as a test for a bad sector - probably partly because the Atari drives give very little information relating to I/O errors.

 

Things like fuzzy and duplicate sectors and long tracks were much better schemes, and harder to reproduce.

 

I can remember copying American Road Race (Activision) - by simply formatting a disk and ejecting it after about track 50 - then writing the data to it.

[Rybags]

I've just tried sending some SIO blocks with COMMAND = $23.

 

I'm sending a block of 128 bytes, experimenting with the first 2 bytes of the block. They seem to alter what happens:

Byte 1 is command? Byte2 is parameter?

 

byte 1=04 seems to do a format operation?

 

byte 1=03 steps the head (by half a track)

in this case, byte 2 controls the direction (0=positive, $80=negative)

 

You can step to track = -1 then do a read of sector 1, it doesn't step the head in this case (as previously stated)

 

Next thing is to do a format and see if the whole scheme really works.

 

A datasheet for the floppy controller would be handy. Might be able to work out commands a bit easier.

[Bryan]

A datasheet for the floppy controller would be handy. Might be able to work out commands a bit easier.

fdc.zip

[Rybags]

Thanks, Bryan. Similar to one I already located.

 

It seems the bytes I'm sending don't correspond to controller commands, so some pre-processing must be done by the drive software.

 

In any case, I've successfully written to the "hidden track" and have a program in progress which I'll upload shortly.

[ijor]

How do you suppose the bad sector trick works?

 

I don’t know for sure, but I guess it is also related to this unconditional step command.

 

Those half steps, aren’t exactly half steps. I don’t know the exact mechanical internals of the four phases stepper (may be somebody here does). But the steps are not symmetric. It would be more correct to say that you need two steps for a track distance, than saying that each step is a half track step. They also behave different inwards than outwards.

 

So it’s possible that you could manage to locate the head slightly off track. Close enough for the sector header to be read correctly (otherwise the FDC won’t start the write command) and not to damage contiguous tracks. But far enough so that the sector written will produce an error when reading back at the nominal position. This is what I mentioned above, it would operate under the same principle that writing a sector with the spin motor slowed down. It would probably require some amount of retries, but that shouldn’t be a big problem.

 

Hard to be sure and give specifics without actual tests. Looks like Rybags is more in the mood for tests, so he might find out and tell us

 

Yes, of course, this won’t be very useful for copying commercial disks. Very few protections are based on simple bad sectors. I think it is more interesting from the theory than for any practical purposes. Just the fact that this was not widely known is amazing.

 

You could imagine another IMPOSSIBLE C.S.S. product. Hey, it should really match the advertising they did for the Impossible “They said it was impossible…”

[ijor]

It seems the bytes I'm sending don't correspond to controller commands,

 

Of course not. And the half step command has certainly no relation at all with the FDC. The stepper is handled completely by the CPU.

[Rybags]

HIDDEN.zip

 

Here's a BASIC program which will create a hidden track, and leave a message on Sector 1. It's SAVEd, so LOAD it, with DOS loaded in Atari BASIC, since it uses the XIO command to get DOS to do the formatting.

 

It can also display the real and "hidden" sector 1.

 

It's a bit of a rush-job, but works. I used an SIO interface routine that I wrote decades ago.

It prompts you to power off/on the drive at times, but it should work without powering off. It does a sector read (of sector 200) to get the head off track 0.

 

Problems can arise using this program, since the drive can get confused if stepped backwards, but powering off the drive always fixes it.

 

As was posted initially, the trick works by stepping back the head, doing a format, then resetting to the real Track 0 (which would be track 1 now), then formatting again, which doesn't affect track -1.

 

I had my drive open while developing this, to see what was going on.

 

The step command does half-tracks, and it seems you can get the drive to go beyond it's logical limits, although I doubt we could do writes to tracks above 39.

Edited March 15, 2006 by Rybags

[Rybags]

The controller does recognize step commands (look at the datasheet). I've written programs on the ST which did all sorts of stuff, although it has a different controller.

 

It's just that, like the Commodore 1541, the Atari 1050 drive is capable of half-track stepping.

[ijor]

The controller does recognize step commands (look at the datasheet).

 

Of course it does, nobody said it doesn’t. But the stepper motor in the 1050 is not connected at all to the FDC. So you can issue step or seek commands and the head won't move.

 

Why you don’t look at the 1050 schematics? Is the “STEP” pin of the FDC connected at all? No, it is not.

 

I've written programs on the ST which did all sorts of stuff, although it has a different controller.

 

The ST is completely different. It uses standard industry drives which have a minicontroller integrated. The FDC in that case send the step pulses, and the minicontroller in the drive actually handles the stepper.

[Rybags]

hidden2.zip

 

Slightly enhanced version. It does a seek of sector 200 before read and format operations, which should make it unnecessary to power down the drive to get it to recognise the proper position of track 0.

 

The program does r/w to sectors 1 and 2.

 

The USR routine is of the following format. All parameters are required:

<var> = USR (1536, [status buffer],[aux1&2],[# ops],[data buffer],[command],[device],[dstat],[dbyte],[buffer length],[dunuse],[retries] )


[status buffer] - an area where the status returned from SIO is put (1 byte per operation) - just point it at 45000 so it's harmlessly written over the BASIC ROM

[aux1&2] = AUX1 and AUX2 (*256) of the SIOCB.  The program will increment these if multiple operations are performed

[#ops] - number of operations to perform.  AUX1/2m and the SIO buffer address will be incremented accordingly for each operation

[data buffer] - your data buffer to send or receive into

[command] - the SIO command to issue

[device] - the device ID

[dstat] - DSTAT flag. $40 for a read operation or $80 for a write operation

[buffer length] - length of buffer for each operation (usually 128).  The buffer pointer is incremented by this amount for each operation

[dunuse] - SIO DUNUSE flag (not sure if it's needed, but has to be supplied)

[retries] - number of times the program will retry if a SIO call fails)

[Rybags]

The controller does recognize step commands (look at the datasheet).

 

Of course it does, nobody said it doesn’t. But the stepper motor in the 1050 is not connected at all to the FDC. So you can issue step or seek commands and the head won't move.

 

Why you don’t look at the 1050 schematics? Is the “STEP” pin of the FDC connected at all? No, it is not.

 

I've written programs on the ST which did all sorts of stuff, although it has a different controller.

 

The ST is completely different. It uses standard industry drives which have a minicontroller integrated. The FDC in that case send the step pulses, and the minicontroller in the drive actually handles the stepper.

 

 

Fair enough. Anyway, we've proven the initial "hidden sector" theory true anyway.

 

It would be nice to have some source code for the 1050, or a ROM dump. I have a file here, but it's probably for a Happy drive.

[drac030]

It would be nice to have some source code for the 1050, or a ROM dump.

 

Could you please take a look at the link I gave above? It will direct you to the FTP site which contains both the source code and the ROM dump.

Edited March 15, 2006 by drac030

[Rybags]

Got it. 1050 source here

 

http://ftp.pigwa.net/stuff/collections/ata...0Source%20Code/

 

Command $23 has subcommands as follows:

 

02 test step rate on all tracks

03 half-step, as I already found out before

04 diagnostic (involves format, write and readback tests)

05 seek to track (illegal tracks will not work)

 

Command $24 is for testing rotation speed, subcommands:

 

00,01 send time of 1 revolution

00,01 send RPM of drive

 

It would appear that out of the extra commands for a 1050, the half-step is probably the only one of use for accessing the area outside the normal Track 0-39 bounds.

 

It was fun to play around and learn something new. But with the fact that other drives (810 as well?) probably don't use these commands, plus the fact that most of us are running APE and have gigs of free space on emu'd drives kinda makes the whole thing useless in a practical sense.

 

If anything, the speed sense command ($24) is probably more useful to most people.

 

As for generating "bad" sectors, I guess that half-stepping might work.

 

I've put my 1050 away for now, but with the program I uploaded it would be easy for someone else to play around with it.

 

I think that if writing to a half-track did work, it would be a fair chance that the entire adjacent track would become useless, since one or two sectors (of which we couldn't be sure which ones) might be overwritten or "weakened".

[ijor]

Got it. 1050 source here

 

Let’s call things by its name. I’m sure Rybags and Drac030 already know that, but just in case somebody doesn’t, that isn’t the source code. It is a disassembly with comments and labels added by reverse engineering.

 

It is still of course extremely useful, sometimes those might have more info than the source. But it is not yet the original source code. If somebody ever seen or heard about it, I’d love to know.

 

Furthermore, it seems to be a hacked release. It’s not a real 1050 ROM. The checksum is wrong and then will not run if you burn an EPROM with it.

 

As for generating "bad" sectors, I guess that half-stepping might work.

 

I've put my 1050 away for now, but with the program I uploaded it would be easy for someone else to play around with it.

 

I think that if writing to a half-track did work, it would be a fair chance that the entire adjacent track would become useless, since one or two sectors (of which we couldn't be sure which ones) might be overwritten or "weakened".

 

Again, they aren’t exactly half-tracks. As I said, I can’t be sure without actual tests. But at this point I suppose TUB is not joking or bluffing. And I don’t see any other way you could create the bad sectors, do you?

[Bryan]

I did some poking around in the 810 ROM and so far I've discovered that the RIOT is at $380 (regs) and $180 (RAM), the ROM starts at $800, the 1771 is at $00 and the 6810 RAM is at $80. The address decoding is very crude, so hitting some addresses will enable more than one device and cause bus conflicts.

 

The ROM is only 2K, BTW.

 

-Bry

[Rybags]

I might try the bad sector creation later.

 

In any case, it's fairly pointless and redundant, and only the really old software used "bad" sectors. More sophisticated software used sectors with CRC errors (data still good though), or duplicate sectors, both of which are impossible to recreate on a standard 1050.

 

As for the stepping not being exactly half track, I did notice that some steps seemed a little smaller than others (I had my drive opened up when playing around with the software yesterday).

[Rybags]

OK. I tried writing individual sectors, groups of sectors and entire tracks, after stepping in or out by half.

 

It's a hit/miss affair at times, sometimes the drive will seek back to 0 and retrack before writing them, other times it will happily write them straight away.

 

ijor was right about the differences in the steps, there is a definite visible and audible difference in the stepping of the head when going by "half" - it seems to be a pattern of one small followed by a larger step, and going back follows the same.

 

As for "bad" sectors, at best I think I was able to make "weak" sectors, which made the drive either read a little slower, or at worst, reseek track 0 then go back to where it was and read the sector again successfully. Normal status was returned by SIO, but a "copy protection" scheme could possibly use timing to detect the anomoly.

 

I modified my program a little further - this time adding the option for "bad" track writes.

 

Note that it's still fairly simplistic and assumes "tracks" as per 810 Single Density, ie 18 sectors / track. All it does is read in the sectors, then write them back after optionally half-stepping.

 

The stepping options available are In (-ve), Out (+ve) and none.

 

hidden4.zip

Edited March 16, 2006 by Rybags

[ijor]

I did some poking around in the 810 ROM and so far I've discovered that the RIOT is at $380 (regs) and $180 (RAM), the ROM starts at $800, the 1771 is at $00 and the 6810 RAM is at $80. The address decoding is very crude, so hitting some addresses will enable more than one device and cause bus conflicts.

 

That shouldn’t be a big problem, should be? No user software can run in the drive without a hardware mod (or at very least a custom ROM). It’s then not so important to protect the hardware against dangerous software, as you need to do in the actual computer.

 

I don’t recall seeing it, but it’s possible that the original source code for the 810 ROM was published. If you read Rick’s post in the newsgroup again, it seems that he had it (and not a 1050 ROM one).

[Bryan]

That shouldn’t be a big problem, should be? No user software can run in the drive without a hardware mod (or at very least a custom ROM). It’s then not so important to protect the hardware against dangerous software, as you need to do in the actual computer.

 

No, but if there is a failure (such as bad ROM) or a power fluctuation it could cause extra stress on the components.

 

I don’t recall seeing it, but it’s possible that the original source code for the 810 ROM was published. If you read Rick’s post in the newsgroup again, it seems that he had it (and not a 1050 ROM one).

 

The code is so short that it wouldn't take long to figure it out. The funny thing about the 1050 is that it has enough RAM to hold a DD sector, but I guess a little more scratchpad space was needed since the 6507 has so few registers. The solution of making ED mode wasn't a very good one, though. I wonder if with some extreme coding someone could get DD working in a stock 1050. You'd have access to X,Y,A,SP,and any RIOT/FDC register space you could put flags in.

 

-Bry

[ijor]

The funny thing about the 1050 is that it has enough RAM to hold a DD sector, but I guess a little more scratchpad space was needed since the 6507 has so few registers. The solution of making ED mode wasn't a very good one, though. I wonder if with some extreme coding someone could get DD working in a stock 1050. You'd have access to X,Y,A,SP,and any RIOT/FDC register space you could put flags in.

 

At the very least it would cost a considerable increase in ROM size. Without RAM for the stack you can’t use subroutines. You might simulate some subroutine mechanism without stack, but for that you would need more precious scratchpad space. Either way you would need to inline several subroutines.

 

And even then, I’m not sure that would be possible. You can use the FDC registers as scratchpad at some points, for example when receiving the data frame. But you can’t use FDC registers when reading/writing a sector. Yes, you can save a few bits on the RIOT ports.

 

It would have certainly been great if a 1050 would come with DD support from factory. But then we would have lost ED. Sure was a lot of fun all the densities, all the DOS variations, etc. Don’t you agree?

[Jeffrey Worley]

On 3/12/2006 at 7:58 PM, Bryan said:

 

You mean I can't believe everything I find on the Internet?

 

Oh well.. I didn't think anything like this was possible.

 

-Bry

Like the dihydrogen monoxife posts.  They use in Baby Food!...

 

Jeff

[Kyle22]

On 9/28/2019 at 9:36 PM, Technoid Mutant said:

Like the dihydrogen monoxife posts.  They use in Baby Food!...

 

Jeff

I just drank a beer that is ~95% dihydrogen monoxide.

Make fun of (their) buzzwords and shove it in the face of [stupid people].

Good stuff.

 

Fact, BTW: Vegetation (trees, plants) process both CO and CO2, removing it from the air and producing both FOOD and OXYGEN.

 

:)

 

[Stormtrooper of Death]

Hi, i think that the Unknown Base is John Beerens (from Eindhoven). He and I started the Atari Club Eindhoven in the early 90s.

 

We spoke several times about programming the standard 1050 diskdrive. And indeed he did make a program to put a markerword/code on a disk, that could be read with a special program. That could be handy to protect your disks so, that if a copy started circulating in the Atari scene, that we could see who the person was who spread the program.

 

I also did some trickery on the standard 1050 diskdrive. Reading MS-DOS files with the MS-DOS <-> Atari emulator program.

 

John tried to explain me his own creations about how to program the 1050 diskdrive, but it was very lowlevel. And I sadly didnt understand much, what he tried to explain to me.

 

I lost contact with him after the Atari Club Eindhoven ceased to exist. Last thing I heard from him, was that he sold all his Atari hardware (8bit and ST(e) ) and went on to work with MS-DOS computers.

 

[Jeffrey Worley]

On 3/14/2006 at 4:28 PM, Rybags said:

The tape trick works by causing the disk to move slightly - so that a sector will be written but deviate from the track. So, I suppose that the sync marks or some of the data will go missing - but in any case the sector should come up unreadable.

 

The speed trick would probably cause the data to be spread out too thinly and not read back properly.

 

The problem with both is that only very early games, and few later ones used a simple I/O fail as a test for a bad sector - probably partly because the Atari drives give very little information relating to I/O errors.

 

Things like fuzzy and duplicate sectors and long tracks were much better schemes, and harder to reproduce.

 

I can remember copying American Road Race (Activision) - by simply formatting a disk and ejecting it after about track 50 - then writing the data to it.

Nah, the tape trick works by causing drag, causing the disk to rotate slower than the 288rpm standard.  I forget the range, but there's an optimum range of rotation for writing a bad sector, like 240rpm-ish?  Some drives have electronics on them that will adjust the RPM to do just this, all automatically.  The tape trick is the poor man's approach and works on any drive but the 810's with the barn door closure.  No way to tug on the tape there.  In the old days, if someone was working with a whole lotta disks, he might open the drive, slow the motor down by adjusting the control for that, and have it ready just to write the bad sectors out on the media.  Copy using one drive, pop the disk into the other, write some bad sectors, check the thing reads the way it should (quality control), package and ship to your customer.

 

Best,

 

Jeff