1050 ROMs

[tregare]

Ok, so far most of the 1050's i have that aren't DD have K rev roms, is L a better rom to have for the 1050's?

[+bob1200xl]

I haven't heard that the ROM version is of much concern. Never seen it documented...

 

Bob

 

 

 

 

Ok, so far most of the 1050's i have that aren't DD have K rev roms, is L a better rom to have for the 1050's?

[+Larry]

I'd never heard there was more than one version -- is it stenciled on the rom or is there a "magic location" in the rom that gives the version?

-Larry

[+bf2k+]

I'd never heard there was more than one version -- is it stenciled on the rom or is there a "magic location" in the rom that gives the version?

-Larry

 

Mine have a paper stamp on them... I am sure I have both here (somewhere). I've certainly removed quite a few from 1050's.

[ijor]

IIRC, the only difference is that rev L added support for the WD2797 FDC. Revision K supported the 2793 only.

[+Larry]

Interesting, and that is quite a significant difference!

-Larry

 

IIRC, the only difference is that rev L added support for the WD2797 FDC. Revision K supported the 2793 only.

[carmel_andrews]

I am guessing that there must have been different revisions of the 1050, like rom's, disk mechs etc

 

I recall that in the US doubler manual, it said that with certain 1050's you needed additional moddying of the 1050 for the US doubler to function properly

[1050]

There were a least a couple of 1050 roms used and they were (still are) buggy. I've never heard of a best one to use - ever.

 

The extra modding of the 1050 when converting to US Doubler was all about setting the proper jumpers for the two different styles of (P)ROM or EPROM in use versus the ones to be used. The US Doubler came on both styles. But I've never seen a stock 1050 with anything other than a 2732 EPROM or one using the famous double sided 2797 controller. So the need to be able to use one seems like vapor ware somehow.

 

In the Holmes collection one can find the 1050 rom disassembled by Michael Pascher and W. Derks of Abbuc-Buch. They did a tremendous job of it and fixed the bugs I mentioned earlier. Deep within that we can see that the 1050 never did return a bad sector list or map as was rumored in the early days when formatting. It's clear that there was potential to do so, but no one at Atari followed thru nor fixed the bugs. IIRC, the bugs were mostly to do with the internal test code that could be invoked with a stress testing cartridge or program, and the buggy results from the same must not have mattered enough to go back and fix a bug or two. I don't think anybody at Atari ever really knew or cared about the bugs. The bugs don't affect normal use at all. I only found the fixed code after I assembled their work and double checked that code against real EPROM data.

 

IIRC, only some EPROMS carry a letter version code on the paper tab that covers the UV window. I don't recall noticing a section within the disassembled code where it dealt with a version letter or number at all, I was in there pretty deep at one time.

[re-atari]

But I've never seen a stock 1050 with anything other than a 2732 EPROM or one using the famous double sided 2797 controller.

So far I have seen only one 1050 that actually had a 2797 installed. It happened back in the 80's when a friend of mine tried to get a diskspeeder he had just got hold of to operate in his 1050. Turned out his drive had a 2797 installed, and after some IC swapping we found out that this prevented the speeder from functioning properly.

Can't remember how the 1050 acted up, though. IIRC the drive just wouldn't start up, but I might be wrong after all these years. I do remember the only way to get the speeder to function properly in his 1050 was by swapping the 2797 with a 2793 from my stock 1050.

Remarkable fact is that the 2797 came with its pin 25 snipped off. I still have the IC in my collection to this very day.

 

re-atari

[tregare]

But I've never seen a stock 1050 with anything other than a 2732 EPROM or one using the famous double sided 2797 controller. So the need to be able to use one seems like vapor ware somehow.

 

 

I have a couple 'stock' 1050's that have the mask rom in them, BTW: if anyone is interested, they can be read from by telling your eprom programmer that it is a 2532 eprom then reading the rpeom to the buffer and saving it.

[tregare]

There were a least a couple of 1050 roms used and they were (still are) buggy. I've never heard of a best one to use - ever.

 

The extra modding of the 1050 when converting to US Doubler was all about setting the proper jumpers for the two different styles of (P)ROM or EPROM in use versus the ones to be used. The US Doubler came on both styles. But I've never seen a stock 1050 with anything other than a 2732 EPROM or one using the famous double sided 2797 controller. So the need to be able to use one seems like vapor ware somehow.

 

In the Holmes collection one can find the 1050 rom disassembled by Michael Pascher and W. Derks of Abbuc-Buch. They did a tremendous job of it and fixed the bugs I mentioned earlier. Deep within that we can see that the 1050 never did return a bad sector list or map as was rumored in the early days when formatting. It's clear that there was potential to do so, but no one at Atari followed thru nor fixed the bugs. IIRC, the bugs were mostly to do with the internal test code that could be invoked with a stress testing cartridge or program, and the buggy results from the same must not have mattered enough to go back and fix a bug or two. I don't think anybody at Atari ever really knew or cared about the bugs. The bugs don't affect normal use at all. I only found the fixed code after I assembled their work and double checked that code against real EPROM data.

 

IIRC, only some EPROMS carry a letter version code on the paper tab that covers the UV window. I don't recall noticing a section within the disassembled code where it dealt with a version letter or number at all, I was in there pretty deep at one time.

 

so it assembles cleanly? that might be worth doing and burning to a rom

[Rybags]

I just wonder - could one ROM difference be the powerup sequence.

 

Normally the 1050 will seek by about 20 tracks or so forward, then back to Track zero.

 

In most cases this is a non-event, but if you happen to have powered off your drive and the head is beyond Track 20 or so, the drive will hit the bump stop and make a clicking sound.

 

The logical fix would be to instead have the drive seek backwards until it hits Track zero, then do the forward/back sequence.

[+kheller2]

ROMS...

The World Storage Technology (Copal?) ROM identifies itself as K but it is very different binary wise.

 

I'm not sure if anyone has confirmed that only L supports the 2797. And I'm curious about the masked Tandon ROMs and what version of code they have. I'm too lazy to make a 2532 to 2732 adapter for my TL866. Actually, a universal ROM reader adapter for the TL866 would be sweet.

 

 

MD5 (1050-revJ.rom) = dd296b6e2aacfd89cc94cc7e6dcebfd3

MD5 (1050-revK.rom) = 5acf59fff75d36a079771b34d7c7d349

MD5 (1050-revL.rom) = 2575d0514c5fe2dd6f5bd3f0ec434eb7

MD5 (WSTR5.BIN) = 5754ab8bef5c93e0caf17425d96bd80e

1050-revJ.rom

1050-revK.rom

1050-revL.rom

WSTR5.BIN

Edited August 27, 2016 by kheller2

[ijor]

The World Storage Technology (Copal?) ROM identifies itself as K but it is very different binary wise.

...

I'm not sure if anyone has confirmed that only L supports the 2797.

 

 

Did a quick look on the WST ROM. Interesting and even a bit intriguing ...

It is rev K modified. Main modification seems to be around stepping. Would need to study the code a bit more, but sounds like you couldn't use a Tandom ROM with that mechanism. If so, it would also mean you couldn't use any of the enhacement ROMs (happy,USD)!

 

It does NOT support the 2797.

 

The strange part is that the ROM checksum is disabled. It performs the checksum comparison, but then the branch to failure was replaced with a couple of NOPs. Exactly as if the ROM would have been hacked, but ... OTOH, and because of the modification of the stepping code, most of the ROM code was displaced a few bytes. So they had to re assemble everything, it wasn't just a hack. So why they didn't update the checksum then ???

[+kheller2]

Even more interesting is that my WST is running a real USD. Go figure. Because I can't at the moment.

[ijor]

Even more interesting is that my WST is running a real USD. Go figure. Because I can't at the moment.

 

I see. Checked the stepping code a bit more. It is possible that the mechanism is backwards compatible. The code sends slightly different values to the stepper motor, but I can't say if the "TANDON" values, or the USD ones, won't work, neither the other way around. Seems it does.

 

But the stepping rate is much faster! If I'm correct, it's about 50% faster in the WST rom. Never tried if you can't increase the step rate on TANDON mechanisms, assumed always you can't too much. That would mean that WST mechanisms are better, at least in that regard! ... but you are missing the faster step rate currently when using the USD rom. You might want to try patching the USD with the faster rate

[+kheller2]

I just checked an old picture of my original drive -- WST mech with the USD REV L EPROM. Maybe someday I'll get around to patching the faster step rate. Interesting that Atari went with the WST mechs and then came out with the Tandon REV-L for 2797 Speaking of "L", were there ever any different USD ROMs other than the one that bumps the drive numbers to 5-8?

[ijor]

I found why they moved most of the code a few bytes, which is why seems the binary is almost completely different to rev K, while the code is virtually the same.

The 1050 stepper (or should I say, the TANDON mechanism stepper) steps in two half, but unequal steps, for each track. One long and one short for every track. For this reason (at least that's what I always assumed), the final step for a seek operation must always be outwards.

When you seek inwards, say, from track 0 to track 20, the firmware performs 40 half steps, then one extra half step inwards, and finally one half step backwards.

These two extra half steps were removed from the WST version. It always seeks directly to the destination track. This saved a few bytes on the seek routine, and the rest of the code moved.

In theory, that ROM should not work with a TANDON mechanism. And If it does happen to work, then it means ALL the other 1050 ROMs (I know) perform, unnecessarily, a too slow stepping.

Speaking of "L", were there ever any different USD ROMs other than the one that bumps the drive numbers to 5-8?

IIRC, the USD ROM is already 2797 compatible. Don't know if that was since the beginning or if there was an older version that was not. IIRC, the earlier Happy and Duplicator versions, were not 2797 compatible.

Edited August 28, 2016 by ijor

[ebiguy]

IIRC, the USD ROM is already 2797 compatible. Don't know if that was since the beginning or if there was an older version that was not. IIRC, the earlier Happy and Duplicator versions, were not 2797 compatible.

 

What is the difference between a 2793 and a 2797 which has an impact in the source code ? the stepping rate ?

[+kheller2]

What is the difference between a 2793 and a 2797 which has an impact in the source code ? the stepping rate ?

http://atariage.com/forums/topic/159652-wdc-fdc-2797-pin-25/?do=findComment&comment=1963880

[ijor]

What is the difference between a 2793 and a 2797 which has an impact in the source code ? the stepping rate ?

 

The stepping rate is the same, and even if it wasn't, the 1050 doesn't use the FDC stepping and seeking interface. The step motor is not connected to the FDC.

 

The difference is that the 2797 supports an alternate sector length encoding, as the FD1771 (the FDC used in the 810) also does. So some bits in the read and write sector commands have different meaning. The command bytes used in rev K would select that alternate sector length encoding in the 2797.

 

http://atariage.com/forums/topic/159652-wdc-fdc-2797-pin-25/?do=findComment&comment=1963880

That thread actually describes an issue at the board hardware level, not the source level incompatibility. I think.

[+kheller2]

 

These two extra half steps were removed from the WST version. It always seeks directly to the destination track. This saved a few bytes on the seek routine, and the rest of the code moved.

 

In theory, that ROM should not work with a TANDON mechanism. And If it does happen to work, then it means ALL the other 1050 ROMs (I know) perform, unnecessarily, a too slow stepping.

 

 

Would stepper motor specifications help clarify any of this? It seems strange to have those extra steps and the only reasons that come to my mind, if the Tandon stepper is not the reason, are: compensating for an alignment issue, compensating for a bug elsewhere in the code, or on purpose to slow it down.

 

I do not own a REV L 1050 and it makes me wonder if they were not released in the US. I only mention this because supposedly the WST drives were shipped late in the 1050 life cycle ('85) and someone looked at and modified the K code for a reason. I'm assuming L doesn't have the faster step rate.

 

You could always burn the code and try it on one of your Tandons. Hint hint.

 

We should also publish the src code for each version highlighting the differences. I know there is a user documented version of the src floating around and I think Candle documented one as well.

[ijor]

Would stepper motor specifications help clarify any of this?

 

Probably yes.

 

It seems strange to have those extra steps and the only reasons that come to my mind, if the Tandon stepper is not the reason ...

 

Can't say for sure, but it is probably related to the stepper asymmetry. I recall somebody here mentioned he could actually see the short vs long half steps.

 

 

I only mention this because supposedly the WST drives were shipped late in the 1050 life cycle ('85)... I'm assuming L doesn't have the faster step rate.

 

Rev L is identical to rev K except for the 2797 support (see below). Why they didn't implement the faster stepping in rate L? I can speculate three possible reasons.

 

- They didn't have time, bother. And made just a quick hack on rev K.

- The stepper in Tandon mechs is really slower and can't (reliably) use the faster stepping.

- It depends on the exact stepper motor. Newer steppers, even in Tandon mechs could use WST step code. But they didn't want to burn a new ROM that wasn't compatible with older mechs.

 

Note that there are two improvements. One is the actual step rate, that is the delay between each half step. They reduced the 20ms step rate, to about 13ms. The other is that they removed those two extra half steps.

 

We should also publish the src code for each version highlighting the differences. I know there is a user documented version ...

 

And it is a shame that we still don't get the original Atari commented source code. This is exactly where the original comments might bring information that you won't get disassembling the code.

 

Rev K vs rev L:

0004: 57 38
0553: 82 88
0603: A2 A8
0671: 82 88
0F80: 82 88
0FA6: 82 88
0FF9: 4B 4C

The $A8 is the modified write sector command for 2797 compatibility. The four $88 occurrences are the modified read sector command. The $4C is the rev L designation. And the $38 (vs $57) is the checksum byte. That's all.

 

[+kheller2]

That's good to know that the 2797 changed some commands, besides the FDC support for half clock rates being removed and side select added and whatever other internal improvements WD made.

 

I do recall seeing a thread here about the half steps as well.

 

I'll dig out a Tandon and WST mech later and get the stepper information and then try to track down some documents. Any thoughts as to why they didn't use the FDC for stepping? I wish we had some engineering notes or even prototypes. The next drive units (1053...) went right to the SA400 interface.

 

I'd also be interested in any slight improvements gained with the faster step times and a device doing full track buffering. Of course then, wouldn't shorter seek times break some copy protection? Hmm maybe not.

 

It's always fun to discover something new here.

 

So at the moment, K for Tandon mechs unless it's a 2797 then use L. WST, use WST. Ooh that means one can hack the WST to support 2797 boards. No practical purpose but neat. As long as one is rewriting and hacking, hook up that SSO line and add some DS code. LOL. I have some bare Epson mechs that I was going to hack into a 1050 someday anyway. They are very similar to the Tandon with all connectors and no electronics but are DS.

[ijor]

Any thoughts as to why they didn't use the FDC for stepping?

 

The FDC can't control directly a 4 four phases stepper. It has a simplified DIR/STEP interface that requires a small logic at the mechanism, as PC drives do.

 

Of course then, wouldn't shorter seek times break some copy protection? Hmm maybe not.

 

Protections usually don't care about that. And seek times are different at the 810 anyway. May be some will break, can't say for sure, but should be very few.

 

So at the moment, K for Tandon mechs unless it's a 2797 then use L.

 

Note that rev L is backwards compatible with 2793. The command word sent by rev L firmware works on both. So you can use rev L in every drive.