path0s
Junior Member
Posts: 52
|
Post by path0s on Sept 9, 2005 2:24:31 GMT -5
Has anyone put QL on a real 1581 disk and used it on a real CBM machine? Do you just do a filecopy and then load QUANTUM from the 1581 on drive 8 as normal?
The reason I'm asking is my QL disk only has about 5 blocks free, so I'd like to move it to a 1581 disk. The deal is that I'm in VICE so I'm trying to find out if QL just doesn't like the 1581 or if it's a VICE bug.
I've used 3 different DSC files (stock, and 2 others). And I've tried those 3, both with and without jiffydos. No joy with any combination I've tried.
Depending on the combination used, during loading before login, it will either tell me "there's a problem with your disk", simply lock up with a red border, or a VICE error box will popup with a CPU jam (I'd like that on honey wheat toast plz). The same errors always happen the same times depending on which combination. So it's not random.
Any idears? Thanks! ;D
-P
|
|
|
Post by RaymondDay on Sept 9, 2005 9:56:33 GMT -5
I have a 1581 partition on my CMD HD. That Booted my Q-Link back in the last days of me being on Q-Link and the turning off of Q-Link. It's the 2400 patch one. That's how I was on Q-Link when it ended.
I all so have a 1581 Q-Link boot disk that I use to get on the new Q-Link at 2400 baud. It was all ready made too but I think that's what I copied to my hard drive and started to use my hard drive.
I can not remember how I put the Q-Link on my 1581. But I think it was with the help of Jim Collete that I got it on a 1581 but I don't remember how.
If I could make a D81 I could send that disk. But after I delete some old Q-Link mail and other files I downloaded to it. Delete my sign-on data too.
|
|
|
Post by Keith Henrickson on Sept 9, 2005 12:26:07 GMT -5
Qlink disks are, sadly, not file copyable.
1. Account info is stored on 18/15. File copying looses this, and this is not a specifically 'safe' location on a 1581 disk either.
2. Fast loader is 1541/1571 specific.
3. Fast loader uses track/sector pointers, not the file names. Copying the files moves them to new locations on the disk, and they will not load.
To move to a new disk type, you must: 1. Change out the fast loader for standard disk commands. CMD did this, as well as me. So, there are a couple of replacement DSCs out there.
2. Write a relinker to change the track/sector pointers to point to the new locations.
3. Redirect the request for 18/15 to a new location.
Three is actually the hardest, as the read routine is compressed. Cute little compression system. So, you'd have to write your own acct info loader and compress it and replace it.
|
|
path0s
Junior Member
Posts: 52
|
Post by path0s on Sept 9, 2005 15:33:47 GMT -5
Hmm yikes Not something I'd wanna tackle.. However, that seems like old hat stuff to the sceners/crackers/packers.. Any takers? I would imagine that eventually it would be really helpful to have everything uncompressed and "cracked" on the QL disk so that maybe a new version of the client could be created on down the line? -P
|
|
path0s
Junior Member
Posts: 52
|
Post by path0s on Sept 10, 2005 5:49:05 GMT -5
Hey Ray.. Before you delete stuff off that disk, be sure to make a backup of it first!! A buddy of mine says he can at least decompress the client so someone in the future might be able to do some official upgrades to the client.. -P
|
|
|
Post by White Flame on Sept 10, 2005 6:08:42 GMT -5
Hey, I can post without registering? Anyway, I'm the reverse engineer guy. Is the compressed code in question drive code or normal C64 code? And is there anything else compressed in the system whose format needs to be figured out?
Basically, I can offer to document the compression format, document the account info loader, and possibly write a small cross-platform compressor for compressing new code in that format. I've got too much on my plate to commit to programming tasks, but I've helped out Jim Brain before on figuring out how a checksumming routine works.
|
|
|
Post by RaymondDay on Sept 10, 2005 8:01:18 GMT -5
That must be it that it's compressed at lest your log in data. I looked for my name on the hole disk and can't find it.
I guess you could just make some 1 block file and tell point it to 18/15 to say it's stored on the dir track. Name is something like usercompinfo maybe some better name. I my all ready have one like that on my 1581 Q-Link boot disk.
|
|
|
Post by Keith Henrickson on Sept 10, 2005 13:45:13 GMT -5
Your login info is encrypted onto TS 18/15. Just an xor with the index of the byte position. It is read with a U1 command during the first load.
DSC holds all the loader code. It's just a normal commie program that holds the computer and drive side fast loader. It is loaded by the autoboot QUANTUM, which then commands it to load ASK. ASK contains, as do all the other three letter filenames, a list of track and sector pointers to load. Each 'fork' is linked together normally as would any other commie file. It has a header on the front. Type 5 are the huffman compressed files, containing first the dictionary, and then the load address, and then the compressed data. Types 1 and 3 appear to be the other used types. I have not analyzed anything about them.
|
|
|
Post by JefferySto on Sept 10, 2005 20:15:04 GMT -5
Keith,
Are you saying that decryption of track 18/sector 15 sector is accomplished by XORing each of the 256 bytes' (0-255) original values with it's corresponding position number?
example:
(first two bytes in sector are 104, 108 in decimal):
orig pos 0 = 104 (decimal)
new pos 0 = XOR 140, 0 (0 being the pos number)
orig pos 1 = 108 (decimal)
new pos 1 = XOR 145, 1 (1 being the pos number)
etc.
That's what I deduced from your post. Is this accurate? I did the above decryption on my disk and I still don't notice anything readable.
Sincerely,
Jeffery S. Stone jefferystone@yahoo.com
|
|
|
Post by Keith Henrickson on Sept 10, 2005 22:24:10 GMT -5
Been longer than I thought since I did this. There's an offset of 0x6E in my description. void decrypt_sector(unsigned char *bSector) { int nCounter; unsigned char nCrypto = 0x6E; for (nCounter = 0; nCounter < 256; nCounter ++) { bSector[nCounter] ^= nCrypto; nCrypto = (nCrypto + 1) % 0x100; } }
|
|
path0s
Junior Member
Posts: 52
|
Post by path0s on Sept 10, 2005 22:36:14 GMT -5
Just a quick topic change, since this thread has evolved a little bit -P
|
|
|
Post by JefferySto on Sept 11, 2005 0:55:44 GMT -5
Thanks Keith I got it. Worked fine.
Just playing with it to learn more. Thanx for the help.
Do you have any of this documented in another form besides your source code (I'm understand C/C++ a little, but not too sharp on it)
Thanx again for your help.
Sincerely,
Jeffery S. Stone jefferystone@yahoo.com
|
|
|
Post by RaymondDay on Sept 11, 2005 1:44:54 GMT -5
I for get how I made the Q-link boot disk on a 1581. But I have a CBM type file on it named "q pass word" it's 40 blocks big. When I look in the dir it shows it's at track 18 sector 0. I go there and it looks like a copy of a dir sector of some disk. I can see file names like this:
"load address uni-copy file copy filecopy.bin zapload 64 compress 128 auto-run 64 auto-boot 128"
I guess it's just a copy of a dir sector when Jim Collette was working on making this fit a 1581 disk. I think Jim Collette did it.
So on that file that start of it in hex numbers is like this:
00 02 00 2A 21 4C 4F 41 44 20 41 44 44 52 25 53 53 A0 A0 A0 A0 00 00 00 00 00 00 00 00 00 0A 00 00 00 82 25 08 55 4E 49 2D 43 4F 50 59 A0 A0 A0 A0 A0 A0 A0 A0 00 00 00 00 00 00 00 00 00 13 00
I guess this must be something that is needed on a 1581 disk.
I am not sure just how a CBM file's are layed out on the disk. If it's like a PRG file or not. I read the next sector 18 1 but it's blank. It seems like a CBM file don't have the numbers to tell it what track sector is next.
|
|
|
Post by Keith Henrickson on Sept 11, 2005 1:58:49 GMT -5
CBM files are subdirectories... From basic:
OPEN 15,8,15 PRINT#15, "/0:PARTITIONAME"
load address may be interesting, the others are standard utils.
|
|
|
Post by Keith Henrickson on Sept 11, 2005 2:06:53 GMT -5
Do you have any of this documented in another form besides your source code (I'm understand C/C++ a little, but not too sharp on it) Byte 0: Fake load address Byte 1: Fake load address Byte 2: Stored to A816 Byte 3: Stored to A817 Byte 4: Stored to A818 Byte 5: Stored to A81A Byte 6: Stored to A81B Byte 7: Ignored Byte 8: Ignored Byte 9: Ignored Byte 10: Ignored Byte 11: Ignored Byte 12: Ignored Byte 13: File type $05 Byte 14 - 15: Load size Byte 16 - 35: Dictionary bit sizes Byte 36 - Total at AA7F: Dictionary output data Byte 0 - 1: Load address Byte 2 - huffman compressed data This is how far I got. DSC is a pain, but it IS straightforward.
|
|