About The Software Federation.

[bxdanny]

Several of the software manuals that eastomj posted to this section were produced by an outfit called The Software Federation, so I thought that I would provide some information on what TSF was. It's an interesting story.

The Software Federation sold a variety of software for OS-65U. They didn't write the software, it was all produced by various other companies, but TSF sold their own editions, with their own documentation, generally for less money than the companies that produced it sold their versions. Legally, and with the cooperation of those companies. How is that possible? The TSF editions were copy-protected, in a unique way.

The licensed users actually could make as many copies as they wanted. But those copies (like the originals) would only run, and in fact could only be read, on the one single computer that they were licensed for. You see, when you joined The Software Federation (TSF software was sold only to members) you told them what kind of CPU board and what kind of hard drive (if any) you had, and they sent you a ROM chip to be installed on your CPU board, replacing the standard OSI monitor ROM. These ROMs contained unique individual serial numbers, but were otherwise the same as the ones they replaced. The serial numbers were located in the two bytes at $FEFE and $FEFF, which normally contained a copy of OSI's much-criticized interrupt vector of $01C0. (The "real" copy at $FFFE and $FFFF was not changed.)

TSF software disks all contained a modified copy of OS-65U v1.2. The floppy disk drivers were modified so that they did something like XORing all data read from or written to disk with the serial number in ROM. The result was that trying to read a TSF disk under standard 65U would result only in disk errors, as would trying to read a standard 65U disk while booted from the TSF-modified OS. Likewise, trying to read a TSF disk with a standard ROM, or a ROM containing any serial number other than the one the disk was intended for, wouldn't work. TSF software could only run from floppy disks, I'm pretty sure, and did not allow hard disk access, since otherwise software and files could be copied to the hard drive, and then copied to normal floppies after rebootong from the HD.

[Mark]

I'm glad you posted this!
eastonj was kind enough to send me a few floppy disks found among the manuals, and it included software from The Software Federation. I've spent all of about 5 minutes looking at the code. Sure enough, after loading the boot track, the first thing it does is XOR data with $FEFA and $FEFB, the unused copy of the interrupt & reset vectors left over in the OSI monitor ROM.
The disks are labeled WP6502 V1, Figforth 1.0, WP2 and some other disks including something named Master Manufacturing Control System V2.0. By comparing this to known data I'm sure we could figure out the XOR bytes.... I'll attach the disk dumps.
Had you not posted this I'd have wondered what was wrong with these disk images, and spent a lot more time trying to fix a "problem".

[Mark]

Since OS65U track format switches from 8E1 to 8N1 after the track header bytes, and since the 65U disk images from TSF do not have the normal track header bytes, the OSIDump software will not know to switch to 8N1, and all the track data will be bit skewed and unreadable. The 65D image disks should be intact since they maintain 8E1 encoding throughout the whole track.

So anyway most of the disk images in the previous post will be garbage. I need to dump the disks with greaseweasle, or modify OSIDump to correctly extract the data. Even if dumped with greaseweasle, the software decoder in OSIHFE will have to be updated to extract the correct data.

I recognized the telltale byte pattern of incorrect word format on the 65U images - you'll see bands of "80 40 20 10 08 04 02 01 00" in the disk dumps which indicate the wrong decoding.

-Mark

[bxdanny]

Mark,

Yes, I noticed the "80 40 20 10 08 04 02 01 00" pattern, but I didn't know what it meant. Thinking about it now, wouldn't it mean that those bytes were all supposed to be zero (or $80)? If so, then maybe the data isn't really XOR'd with the ROM key, but just has it added to the checksum so that the data will be rejected for having an invalid checksum? I'm speculating here. What error code do you get if you try to load or open one of those disks under standard 65U?

Is there anything in the pile of documentation you have that indicates what the membership number (or license number) in the Software Federation of the person or business who ordered these disks may have been? I'm thinking that that number, treated as a 16-bit value, may have been the actual key that was in the ROM, at either $FEFE or $FEFA. Maybe not, but it's worth a try. Where did he get all that stuff, anyway?

[Mark]

Okay, here is a 2nd attempt at dump.
It looks like the OS65U track header on the TSF files have been changed from $80,trkHi,trkLo (effectively $80,00,trknum) to $00,$0A,trknum.
Patching OSIDump to switch from 8E1 to 8N1 after the modified header produces readable OS65U disk dumps including directory contents etc. This may have been the modification that prevented normal copying. Each track in an 8" OSIDump image is $F00 bytes long. Changing the track header from $00,$0A to $80,00 would make the disk readable with standard OS65U. In addition the OS65U track checksum may also need to be corrected to make the track readable without error. The attached files have not been modified from their original format other than to convert from a serial bitstream to a bytestream as are all OSIDump files.

[Also during the reads I discovered my disk drive head was totally clogged making a previous disk image attempt garbage. Fortunately a little isopropyl alcohol and a cotton swab took care of that. (I've read that the disk image creator guys say it's important to clean those heads whenever you're making kyroflux/greaseweazle/supercopy images as it noticeably affects signal quality!) 40 year old spinning rust tends to clog things.]

I believe the "80 40 20 10 08 04 02 01" pattern does indicated zeros when read with the wrong serial word format.
I don't have any documentation for this other than what eastonj has posted. I was told 5 or 6 boxes of stuff were found cleaning out the parents house.

The attached C3Dump.65a can be drag & dropped onto WinOSI to run it under C3 emulation. Since it understands the 65U TSF header it can be used to show directory contents of the dumped images. I haven't looked into the inner workings yet other than to verify the rom contents were accessed right after loading the boot track. Seems 6 bytes from FEFA-FEFF are read.

Code: Select all

2E70 A9 00    LDA #$00
2E72 4D FA FE EOR $FEFA
2E75 EE 73 2E INC $2E73
2E78 D0 F8    BNE $2E72
2E7A 29 7F    AND #$7F
2E7C 8D 00 60 STA $6000
2E7F 8D 9C 28 STA $289C
2E82 38       SEC
2E83 A9 80    LDA #$80
2E85 ED 00 60 SBC $6000
2E88 8D 01 60 STA $6001
2E8B A9 BD    LDA #$BD
2E8D 8D 02 22 STA $2202
2E90 A2 00    LDX #$00
2E92 4C 02 22 JMP $2202

Its an interesting diversion, but I'm not sure how useful the data on these disks are...