• Please review our updated Terms and Rules here

Any way to bypass a password login in CompuPro Concurrent DOS?

retrogear said:
>Interesting... I wonder if the disk then is trying to set a baud rate my machine can't even handle?

It's possible although I think the TTYS file doesn't come into play until after CCPM.SYS is launched. Try pressing ctrl-c when it hangs. Sometimes that takes it back to a cold boot routine.
Or blindly type 40FH then return. Can you change the baud in your terminal to 9600 ?
Click to expand...

I've tried every baud rate, 19.2K is the only one that displays anything at all (and it stops displaying when the floppy loader executes). Blindly typing does nothing, and neither does ctrl-c.

EDIT: Well, anything coherent anyway. I sometimes get garbage at some of the other baud rates, but it's just a corrupted version of the text I've already seen. No prompt.
 
Last edited:
jmetal88 said:
I've tried every baud rate, 19.2K is the only one that displays anything at all (and it stops displaying when the floppy loader executes). Blindly typing does nothing, and neither does ctrl-c.

EDIT: Well, anything coherent anyway. I sometimes get garbage at some of the other baud rates, but it's just a corrupted version of the text I've already seen. No prompt.
Click to expand...
The fact that the loader sends a readable prompt to your terminal at 19.2K indicates the problem is not with the serial communications settings. The Loader is a very simple program that only serves to load the CCPM.SYS file from the boot drive; the Loader does not make use of a TTYS file.

If the Loader does not see a file named CCPM.SYS on the boot drive, what is *supposed* to happen is that the loader sends a prompt to the terminal for the user to enter the name of the SYS file that should be loaded. What you have described happening is that the loader sends part of a message to the terminal, but I understand it never gets far enough into the process to send you a prompt for entry of the SYS file name. Instead, it seems the loader "disappears" likely trying to execute some code that doesn't work on your 10+. It seems, to me, that your boot disk does not have the correct Loader for your specific 10+ hardware configuration. The CompuPro boot Loader is to some extent specific to the hardware configuration of the system it is being used with.
 
Last edited:
hmb said:
The fact that the loader sends a readable prompt to your terminal at 19.2K indicates the problem is not with the serial communications settings. The Loader is a very simple program that only serves to load the CCPM.SYS file from the boot drive; the Loader does not make use of a TTYS file.

If the Loader does not see a file named CCPM.SYS on the boot drive, what is *supposed* to happen is that the loader sends a prompt to the terminal for the user to enter the name of the SYS file that should be loaded. What you have described happening is that the loader sends part of a message to the terminal, but I understand it never gets far enough into the process to send you a prompt for entry of the SYS file name. Instead, it seems the loader "disappears" likely trying to execute some code that doesn't work on your 10+. It seems, to me, that your boot disk does not have the correct Loader for your specific 10+ hardware configuration. The CompuPro loader is to some extent specific to the hardware configuration of the system it is being used with.
Click to expand...

Right; I am wondering if I do rename one of the SYS files to CCPM.SYS if it will behave any differently, though. That may at least tell me if it's crashing while looking for the file or while trying to generate the prompt.
 
jmetal88 said:
Right; I am wondering if I do rename one of the SYS files to CCPM.SYS if it will behave any differently, though. That may at least tell me if it's crashing while looking for the file or while trying to generate the prompt.
Click to expand...

If you can figure out how to do that then yes, it might provide some information as to where the boot process goes astray. My guess is that the boot process still won't get past the Loader stage. I expect that if the Loader can send part of a message to the terminal but not the entire prompt for user entry of the name of SYS file, the Loader version may not be correct for your 10+.
 
Last edited:
I wonder if it could be as simple as the loader pointing to the wrong address for my floppy controller? I may have to take it back out and look at the circuitry again to see if I can determine where they're placing the controller chip on the address bus. There is a jumper that looks like it might possibly set that up, but I hadn't made any headway messing with it blindly.
 
jmetal88 said:
I wonder if it could be as simple as the loader pointing to the wrong address for my floppy controller? I may have to take it back out and look at the circuitry again to see if I can determine where they're placing the controller chip on the address bus. There is a jumper that looks like it might possibly set that up, but I hadn't made any headway messing with it blindly.
Click to expand...

Eh, I'm not going to be able to determine how the floppy drive is addressed very easily. They are doing the address decoding with a PAL. I could potentially set up a logic analyzer on it to try and figure it out, but I'm not sure I want to go to that much effort.

By the way, renaming one of the SYS files to CCPM.SYS did not help. It is either getting stuck during or before it tries to read the disk directory.
 
My cables I need to connect my 8" drive to my PC are supposed to be in on Saturday, so I should be able to read in my CDOS 4.1E disks soon. I am hoping something on one of those disks will provide some insight, but at this point I have my doubts about that.
 
jmetal88 said:
My cables I need to connect my 8" drive to my PC are supposed to be in on Saturday, so I should be able to read in my CDOS 4.1E disks soon. I am hoping something on one of those disks will provide some insight, but at this point I have my doubts about that.
Click to expand...

Even if you can't use them directly, the images would be useful to other people. There doesn't seem to be a copy of any versions of 4.x anywhere.
 
Well, I am an idiot and ordered the wrong gender of connector so now it'll be at least another week.
 
Actually it looks like that wrong gender connector won't be a waste after all. I'm trying to read a disk now on my dedicated 'floppy imaging' machine and it seems like the controller is having trouble with single-density tracks. It works well enough for Teledisk to be able to determine that they are single-density, but not well enough to actually read the data on them. I do know my XT clone can properly read/write single-density, so I can use that wrong connector to build an adapter cable for its own floppy controller (which does not have the external 37-pin like the controller on my main floppy imaging machine does).
 
Oh... Well, I tested out the connection by reading one of the 'homemade' boot disks that also came in the box I picked up and it read the whole thing perfectly, but I'm getting a lot of data errors on the first of the actual system master disk set.

Eh, I've sometimes had luck by trying to read the same disk repeatedly and cleaning my drive heads between attempts so that's probably worth a shot here, but it doesn't look promising so far.
 
Yeah, I don't know how much use these 4.1 disks will be. I was hoping 1 and 2 would both be bootable, but it looks like only 1 is and one of the bad sectors (there are a dozen or so) is in the boot track.
 
I finally managed to read in a copy of disk 1 with the boot track intact and have been messing around with copying it to a 5.25" disk some.

Interestingly, when I try to boot off of it, the read head seems to stay down a fraction of a second longer than it did with the CCPM image from the Maslin archive. Unfortunately in spite of this, the code seems to crash even before displaying the version info. Looking at the files on the disk, I don't think they would be able to set up my system anyway as they are still named in ways that indicate they are obviously expecting a Disk 3 for a hard drive interface instead of whatever hardware is in the 10 Plus. But it's at least nice to know for sure that they won't work with my MP4.

The disk images are here for anyone interested: CompuPro Concurrent DOS 4.1E System Master Set (Bad Sectors)

Disk 3 is the only one that copied without any bad sectors. I think I had 10 bad sectors on Disk 1, 5 bad sectors on Disk 2, and 13 bad sectors on Disk 4. I didn't take the time to figure out how many or which files are affected by the bad sectors.

Oh, and I used the following diskdef to extract the files in CPMTOOLS:

Code: 
diskdef comf
  seclen 1024
  tracks 154
  sectrk 8
  blocksize 2048
  maxdir 256
  skew 3
  offset 23040
  boottrk 0
  os 3
end
 
I couldn't get your IMD's to transfer back on disk or read with the cpmtools def. It's weird they can be viewed with IMDV but Imagedisk refuses to write them.
When you imaged did you remember to turn double step off?
If nothing else, can you share the files? I have a DISK3 CompuPro system they will work on. If I see anything for the model 10 I'll let you know.

Larry G
 
retrogear said:
I couldn't get your IMD's to transfer back on disk or read with the cpmtools def. It's weird they can be viewed with IMDV but Imagedisk refuses to write them.
When you imaged did you remember to turn double step off?
If nothing else, can you share the files? I have a DISK3 CompuPro system they will work on. If I see anything for the model 10 I'll let you know.

Larry G
Click to expand...

Hmm, I sent them to Larry K and he was able to get them to write. Yes, double step was off. Larry K and I were both able to get files off the disks (he also was not able to get CPMTOOLS to work even though I somehow was -- he wound up writing the files to real floppies and reading them back with 22DISK to get the files off).

Incidentally, I hadn't been aware of 22DISK so I tried it on my original disks and was able to tell which files on the images are damaged. On Disk 1, CCPMF85.SYS and MEM.CON are damaged, and on Disk 2 HELP.HLP is damaged and FM.CMD is possibly damaged (22DISK reported a read error when extracting it, but the file came out identical from three different methods whereas the other files had differences).

Oh, Larry K did say he used 22DISK to format the physical floppy before writing to it with IMD, so maybe that made a difference? This is the 22DISK definition he sent:
Code: 
BEGIN COM9  Compupro (Viasyn) 8/16 - DSDD 8" - 1024 x 8
DENSITY MFM ,HIGH
CYLINDERS 77 
SIDES 2 
SECTORS 8 ,1024
SIDE1 0 1,4,7,2,5,8,3,6
SIDE2 1 1,4,7,2,5,8,3,6
ORDER SIDES
BSH 4 BLM 15 EXM 0 DSM 599 DRM 255 AL0 0F0H AL1 0 OFS 4
END

EDIT: Also be aware that the first track on these images is single density, so it won't write back properly unless your controller supports single-density. Not really an obstacle if you just want the files off them, but if you actually want to boot you'll be missing the boot track (actually present on disks 1 and 4 after I had a closer look).
 
Last edited:
Yes I have an Adaptec AHA-1542 SCSI card that writes the mixed density off it's floppy controller.
I cobbled together a 34 to 50 pin cable so it can control the 8" drive as well. Hmmm I was using
floppies formatted by the CompuPro. I don't have that many DSDD 8" disks, most are SSDD.
I'll give it another go. I might contact Larry K. We have worked together in the past.

Larry G
 
Since I don't have much DSDD 8" floppies that are free to use, I put in a 1.2M HD 5.25 drive as a substitute and got those IMD's to write to those.
Boy there are a crap ton of files on those disks. If the MEM.CON is corrupt that is the one that will hurt. Without it I can't do a genccpm but the
stock CCPM340.SYS will probably work for me. I see support for SPU-Z which I have as well as a CPU-286. Thanks for sharing those and to Larry K for the def which worked great.
I have alot more tinkering to do now. Hope you find files for your model 10. I don't see any in these.

Larry G
 
If it helps, it looks like there is only one byte that is different between my attempts to extract MEM.CON. At offset 0x911 my read straight off the disk is 0x2E but my read off the disk image is 0x26. There's only one bit of difference there, so if you run it and it crashes you might try flipping that bit so it's a 2E instead of a 26 and see if that makes a difference.
 
0x911 is 26 in my file and I compared to the CDOS V3.1D MEM.CON file and got a match for 26 in the same sequence at 0x8D3 so 26 it is, the MEM.CON looks like it's intact compared to the other version - yes !!!

Larry G
 
You must log in or register to reply here.
Back
Top