XAP1541 Adapter and Windows XP Problems
hodo
long.
After more than 10 year's absence, my interest in C64 stuff was
renewed when my daughter recently asked if I could convert her Pocket
Writer data files to MS Word. She now teaches the stuff she was
taught and wanted to use her comprehensive notes.
I quickly found out about the magic of X1541 cables so dusted off my 3
SX-64's and extra 1541's which all fired up nicely. All the floppies
also seemed to be in good shape.
I made up a X1541 cable but it only worked in pure DOS on a 486-DX2-66
laptop and not on a P200MMX or a PIII-800 Celeron system. I then made
a XE1541/XM1541 cable which worked in pure DOS on the P200MMX but not
on the laptop or PIII-800.
Using the XE1541 on a P200MMX in pure DOS, I sucessfully converted
many of the Pocket Writer files by first using Pocket Writer to
re-save them as sequential ASCII files and then using Star Commander
to transfer them individually to the PC. Transfered files worked
perfectly in MS Word.
Since I don't have room for 2 PC's, I wanted a cable that worked on my
PIII-800 Celeron. So last week I purchased an XAP1541 adapter from
http://sta.c64.org. I understood most compatabilty issues with newer
mainboards and Windows XP were resolved with the XA1541, as long as
the tweak package was installed and the latest beta release of SC was
used.
I installed the XAP1541 only to find it also did not work in a Windows
environment on the PIII-800 Celeron system.
Under Windows XP SP1 safe boot into XP DOS, both Star Commander 8.314
beta and 8.2 immediately freeze up when started. SCSetup also freezes
immediately upon execution, even without an sc.ini file. Powering the
1541 down, disconnecting/reconnecting, and re-powering doesn't unlock
the freeze up. There is nothing I can do to unfreeze the DOS window,
except to kill it.
I am only using the XA1541 portion of the XAP1541 adapter as I don't
have any drives wired for the XP1541 parallel connection.
SC will start up if I execute "sc.exe /nolpt" but SC freezes
immediately with any of the /noems, /noxms, or /novesa switches. Of
course, starting up with the /nolpt switch is useless since the LPT
port and attached XAP1541 is completely ignored.
If I boot into pure DOS from an MSDOS 6.22 floppy, SC works just fine.
SC reads directories off floppies in my 1541 or 1541-II drives without
trouble. The problem is only with SC in an XP environment.
My primary concern about pure DOS boots is that my NTFS drives can't
be accessed. I presume I could create FAT partitions in my HD's that
could be accessed by DOS and SC, but I would prefer not to do that. I
tried DOSNTFS OS's such as DR. DOS 7.5 but they were not suitable for
this task.
In my Windows XP SP1 system, I installed the tweak package files
giveio.sys and userport.sys correctly as they both appear as active
devices in the hidden devices manager list. Executing userport.exe
and trying different settings made no difference.
The I/O addresses in userport.sys matches the I/O of LPT1 both in BIOS
and Device Manager. I have manually changed the LPT port I/O
addresses in BIOS to no avail. I have tried all permutations and
combinations of addresses and LPT's for SPP, EPP, & ECP in BIOS. I
also tried EPP 1.7 & 1.9 to no avail.
I have also tried different memory configurations for accessing the
shell DOS command prompt before executing sc.exe.
Before giving up on the XE1541/XM1541 on my PIII 800 Celeron system,
and after having gone through the complete SC's instructions and
troubleshooting guide many times, I purchased a Lava PCI Parallel Port
card. Unfortunately I couldn't use the card since userport.exe would
not accept the assigned I/O address of 07XX-07YY and since BIOS does
not see PCI parallel cards. Also, SC failed to recognize the Lava
port.
With the XE1541 or XM1541 on my PIII 800 XP SP1 system, SC never
locked up on start up from pure DOS or from XP SP1 safe-boot DOS. I
just could never access drive 8 or 9.
My system information is:
Intel PIII 800 Celeron, 512 MB SDRAM
MainBoard - Tyan S1854 Trinity 400
Award Bios 4.51
VIA VT82C694X Apollo Pro 133A Chipset
Onboard Parallel Port has no other printers or devices attached
Windows XP Professional Build 2600.xpsp2.03042201633 (Service Pack
1)
Here is XCDetect's output from within Windows with BIOS in SPP.
C:\SC>xcdetect -d
PC-CBM transfercable autodetection design study, (C) 1998 -
Wolfgang Moser
uses basic routines of The Star Commander, (C) 1994-1998 -
Joe Forster
Version: 0.17 -- Debug messages mode (-d) switched to on.
Prechecking port addresses ...
LPT1 at 0x3BC, PS/2
LPT2 at 0x378, N/A
LPT3 at 0x278, N/A
Searching for cables (DelayOffset: 22)...
(can only be found, if IEC devices are connected and switched on)
no cable connected to port address 0x3BC
no cable connected to port address 0x378
no cable connected to port address 0x278
Searching for IEC floppy devices ...
Searching for parallel cables on all floppy devices ...
C:\SC>
I'm not interested in any kind of retribution for my purchase of the
XAP1541 adapter. I still think it was a good buy, even if I can only
use it with floppy drive access and storage. However, I am very
interested in finding out how to make it work under Windows so that I
can use my NTFS drives for direct access to and storage of Commodore
floppy data.
I Googled the web and groups extensively for answers. The best
resource was Star Commander http://sta.c64.org . Perhaps someone else
can help STA provide possible answers or a fix.
Hodo
Nicolas Welte
hodo wrote:
> This is my first post to comp.sys.cbm and I apologize if it's too
> long.
no problem. the more information, the better ;)
> Under Windows XP SP1 safe boot into XP DOS, both Star Commander 8.314
> beta and 8.2 immediately freeze up when started.
XP DOS isn't DOS, it's a 32bit command line. SC doesn't work any better here
than in the full XP environment, in a command line window. It doesn't make
any sense to use this option.
> If I boot into pure DOS from an MSDOS 6.22 floppy, SC works just fine.
> SC reads directories off floppies in my 1541 or 1541-II drives without
> trouble. The problem is only with SC in an XP environment.
Okay, this information is important. So your hardware setup works fine, at least.
> In my Windows XP SP1 system, I installed the tweak package files
> giveio.sys and userport.sys correctly as they both appear as active
> devices in the hidden devices manager list. Executing userport.exe
> and trying different settings made no difference.
First: Why do you have installed both packages? Usually only one of them is
enough, and who knows, there might be problems if you install both? For me, I
have only experience with userport.sys, but you have to follow the
instructions closely, and use the tweak package and the docs that are offered
on the SC beta page.
> The I/O addresses in userport.sys matches the I/O of LPT1 both in BIOS
> and Device Manager. I have manually changed the LPT port I/O
> addresses in BIOS to no avail. I have tried all permutations and
> combinations of addresses and LPT's for SPP, EPP, & ECP in BIOS. I
> also tried EPP 1.7 & 1.9 to no avail.
No need to do this. Just use the configuration that proved to work on this
machine when you boot with the DOS 6.22 disk.
> I have also tried different memory configurations for accessing the
> shell DOS command prompt before executing sc.exe.
>
> Before giving up on the XE1541/XM1541 on my PIII 800 Celeron system,
> and after having gone through the complete SC's instructions and
> troubleshooting guide many times, I purchased a Lava PCI Parallel Port
> card. Unfortunately I couldn't use the card since userport.exe would
> not accept the assigned I/O address of 07XX-07YY and since BIOS does
> not see PCI parallel cards. Also, SC failed to recognize the Lava
> port.
Have you tested this card with the giveio.sys driver? The docs say that this
driver opens all port addresses for DOS access.
> Here is XCDetect's output from within Windows with BIOS in SPP.
>
> C:\SC>xcdetect -d
> PC-CBM transfercable autodetection design study, (C) 1998 -
> Wolfgang Moser
> uses basic routines of The Star Commander, (C) 1994-1998 -
> Joe Forster
>
> Version: 0.17 -- Debug messages mode (-d) switched to on.
>
> Prechecking port addresses ...
>
> LPT1 at 0x3BC, PS/2
> LPT2 at 0x378, N/A
> LPT3 at 0x278, N/A
Is your LPT port really configured at 0x3bc? If not, this might be because
xcdetect is not able to enable the userport.sys driver. In this case, try
again with the manual enable method from the tweak package docs.
There's also one trap when configuring SC to use the port. Make double sure
that the LPT address inside SC matches the one in your Windows device
manager, because SC can't read the BIOS translation table under XP. Try all
the hints from the tweak package (e.g. disable the LPT port in Windows, or at
least the PnP detection), and make sure you have SC configured to the correct
cable type. You can also disable SC's port mode detection.
> I Googled the web and groups extensively for answers. The best
> resource was Star Commander http://sta.c64.org . Perhaps someone else
> can help STA provide possible answers or a fix.
I hope Joe shows up here and can provide some more help. I'm really out of
ideas here!
Nicolas
--
--> Email address is valid for replies (requires Re: in the subject) <--
- See my Commodore hardware projects at http://people.freenet.de/x1541 -
- Visit the German X1541 Shop at http://sta.c64.org/x1541shop_ger.html -
Wolfgang Moser
Nicolas, thanks for jumping in here. I also recognized this thread,
but didn't feel able to help altogether, because I didn't find a
Win XP solution myself until now. So I'll provide only some
additional hints that _may_ be helpful.
Nicolas Welte wrote:
>>
>> Before giving up on the XE1541/XM1541 on my PIII 800 Celeron system,
>> and after having gone through the complete SC's instructions and
>> troubleshooting guide many times, I purchased a Lava PCI Parallel Port
>> card. Unfortunately I couldn't use the card since userport.exe would
>> not accept the assigned I/O address of 07XX-07YY and since BIOS does
>> not see PCI parallel cards. Also, SC failed to recognize the Lava
>> port.
>
> Have you tested this card with the giveio.sys driver? The docs say that
> this driver opens all port addresses for DOS access.
I am also using an additional PCI LPT port card from SIIG for my
Star Commander transfer configuration. And I couldn't get it to run
under Windows XP until now. The card itself works fine, but because
the driver assigns the LPT port addresses to some wierd values:
LPT 2: EPP+ECP, B000-B007 & A800-A803, IRQ 17
LPT 3: EPP+ECP, B800-B807 & B400-B403, IRQ 17
the giveio.sys package as well as the userport.sys driver have
difficulties. I cannot configure them to open up read/write access
to these port addresses. GiveIO _should_ be able to support high
IO addresses, but it doesn't work with The Star Commander. That's
my personal experience and definetly not a proofed result.
Until now I didn't test the builtin LPT port, which should be a
working configuration as I know from Nicolas. He's using the
motherboard integrated parallel port with the userport.sys driver.
>> Here is XCDetect's output from within Windows with BIOS in SPP.
>> [...]
>> C:\SC>xcdetect -d
>> PC-CBM transfercable autodetection design study, (C) 1998 -
>> Wolfgang Moser
>
> Is your LPT port really configured at 0x3bc? If not, this might be
> because xcdetect is not able to enable the userport.sys driver. In this
> case, try again with the manual enable method from the tweak package docs.
Oughhh, XCDetect was definetly not developed for Windows XP. All
the results reported are "undefined", if this tool is not used
under a plain DOS environment.
It's use is to help debugging general hardware (cable) problems,
when The Star Commander is not able to work under DOS also (which
it does in your case).
And definetly yes, XCDetect doesn't support the userport.sys
and giveio.sys packages as I wrote this tool long before all
the users changed their OSes to Win XP. It also lacks support
for the XA1541 cable. I never found the time to write an updated
version with additional autodetection routines (this is a very
sophisticated algorithm).
> I hope Joe shows up here and can provide some more help. I'm really out
> of ideas here!
Some more detailed informations could perhaps help, so I
propose to do:
1. Start with the plain DOS configuration, that is known
to work with The Star Commander and note all the settings
and configurations (port address, port configuration,
cable). Preferrably use the builtin LPT port.
2. Start Windows XP, look into the device manager and report
the configuration of the LPT port as repoted by Windows
XP. This _could_ be different to DOS.
3. As mentioned in the SC docs, disable that LPT port in the
current hardware profile.
4. Configure The Star Commander, you have to manually insert
the correct (Windows XP) LPT port address into the transfer
options dialog since the port is not visible anymore after
it has been disabled in the XP device manager.
5. Good luck.
Womo
--
------ to obtain more infos about me, look up the page ------
---- http://www.wmsr.de pwnah (at) d81 (dot) de ----
hodo
<wn...@d81.de.invalid> wrote:
>Hello Hodo, hello Nicolas,
>
>Some more detailed informations could perhaps help, so I
>propose to do:
>
> 1. Start with the plain DOS configuration, that is known
> to work with The Star Commander and note all the settings
> and configurations (port address, port configuration,
> cable). Preferrably use the builtin LPT port.
>
> 2. Start Windows XP, look into the device manager and report
> the configuration of the LPT port as repoted by Windows
> XP. This _could_ be different to DOS.
>
> 3. As mentioned in the SC docs, disable that LPT port in the
> current hardware profile.
>
> 4. Configure The Star Commander, you have to manually insert
> the correct (Windows XP) LPT port address into the transfer
> options dialog since the port is not visible anymore after
> it has been disabled in the XP device manager.
>
> 5. Good luck.
>
>
>Womo
Thanks Joe, Womo, and Nocolas,
Joe has also been looking into my problem. I had reported to him that
I was now able access Star Commander with XP in Safe Mode, without
freezing on start-up. However, I still can't see the 1541. I always
get the "Drive 9: not present" error. The 1541-II is configured as
Drive 9. SC still freezes on start-up in normal XP.
So the first problem is to get SC to see the 1541 in XP Safe Mode,
then to figure out how to prevent the freeze-up in normal XP.
At Joe's suggestion I ran XCTest and sent him the results. Joe felt
the results meant that "either the outgoing signals never reach the
adaptor or the incoming signals don't arrive from the adaptor. (Even
though XCTest also activates both "giveio" and "userport"
automatically upon every access!)"
I decided to try Womo's suggestions.
I set BIOS to each of SPP, EPP, ECP & ECP+EPP and then logged SC's
available LPT modes in both pure DOS and in XP Safe Boot. Before
taking LPT readings off SC for each of the changed BIOS settings, I
pressed the SC "Set Default Configuration" button, then set Transfer
Mode to Warp, Serial Cable to XA1541, and Sync Transfer to Always; all
other settings were left at default values. I tried setting "Detect
Modes" on or off as well.
BIOS SC in Pure DOS SC in XP Safe
SPP 03BC/IRQ7 LPT1 ($03BC,PS/2) LPT1 ($03BC,EPP)
LPT2 LPT2 ($0378,EPP)
LPT3 LPT3 ($0278,EPP)
EPP 03BC/IRQ7 LPT1 ($03BC,PS/2) LPT1 ($03BC,EPP)
LPT2 LPT2 ($0378,EPP)
LPT3 LPT3 ($0278,EPP)
ECP 03BC/IRQ7 LPT1 ($03BC,ECP) LPT1 ($03BC,EPP)
LPT2 LPT2 ($0378,EPP)
LPT3 LPT3 ($0278,EPP)
ECP+EPP 03BC/IRQ7 LPT1 ($03BC,ECP) LPT1 ($03BC,EPP)
LPT2 LPT2 ($0378,EPP)
LPT3 LPT3 ($0278,EPP)
For each of the above BIOS settings, running XP in Safe mode, I also
ran SC with all permutations and combinations of giveio/userport
on/off.
For every BIOS setting, SC in pure DOS successfully read the 1541 but
was still unable to access the 1541 in XP Safe mode.
Wolfgang Moser
> Womo wrote:
>>
>>Some more detailed informations could perhaps help, so I
>>propose to do:
>>
>> 1. Start with the plain DOS configuration, that is known
>> to work with The Star Commander and note all the settings
>> and configurations (port address, port configuration,
>> cable). Preferrably use the builtin LPT port.
>>
>> 2. Start Windows XP, look into the device manager and report
>> the configuration of the LPT port as repoted by Windows
>> XP. This _could_ be different to DOS.
> [...]
> I decided to try Womo's suggestions.
>
>
> SPP 03BC/IRQ7 LPT1 ($03BC,PS/2) LPT1 ($03BC,EPP)
> LPT2 LPT2 ($0378,EPP)
> LPT3 LPT3 ($0278,EPP)
> EPP 03BC/IRQ7 LPT1 ($03BC,PS/2) LPT1 ($03BC,EPP)
> LPT2 LPT2 ($0378,EPP)
> LPT3 LPT3 ($0278,EPP)
> ECP 03BC/IRQ7 LPT1 ($03BC,ECP) LPT1 ($03BC,EPP)
> LPT2 LPT2 ($0378,EPP)
> LPT3 LPT3 ($0278,EPP)
> ECP+EPP 03BC/IRQ7 LPT1 ($03BC,ECP) LPT1 ($03BC,EPP)
> LPT2 LPT2 ($0378,EPP)
> LPT3 LPT3 ($0278,EPP)
>
please repeat step 2 and report, what the device manager of
Windows XP tells, where it configured the LPT ports to. Since
XP got it's own Plug'n'Play kernel, it may configure the ports
to completely different settings than the BIOS.
* Start: Start -> Settings -> Control Panel -> System
* then select the "Hardware" tab
* Press the "Device Manager" button
* Open the "COM and LPT" ports subtree and double click
you LPT port(s) item
* Select the resources tab (for each of your ports) and
tell me all the configured resources (I/O area, IRQ, DMA)
Then we will hopefully know the correct adresses, that have to
be configured into The Star Commander by manual selection.
hodo
Joe thought there was something suspicious about the 37B address for
the parallel port, so I was already exploring settings in device
manager when I read your response above.
Through a combination of changing the parallel port address in BIOS to
0378, 0278, and back to 037B, temporarily disabling LPT1 in device
manager, forcing IRQ's in device manager, preventing IRQ's, and
manually changing addresses to match BIOS, and returning to automatic
addresses, I've managed to get SC to start-up in a normal XP window
without freezing up.
Now, no matter what I settings I try, to duplicate those present when
I was getting freeze-ups, I can't get freeze-ups.
Seems I previously to got SC to start without freezing in XP Safe mode
by disabling LP1 in device manager and trying various settings. I
couldn't restore conditions that were causing freeze-up in XP Safe
then either.
I prepared the below table after testing various addresses and IRQ's
in BIOS, XP's Device Manager, and SC's Detected Ports. BIOS was set to
SPP. The SC Error Messages come up when trying to access a 1541-II
whose device switch is set to 9.
BIOS Device Manager SC Detected Port SC Error Message
037B/IRQ7 LPT1 037B/IRQ7 LPT1 (037B,PS/2) Timeout detected
037B/IRQ7 LPT1 037B/noIRQ LPT1 (037B,PS/2) Timeout detected
037B/IRQ7 LPT1 0378/IRQ7 LPT2 (0378,PS/2) Drive 9: not present
037B/IRQ7 LPT1 0378/noIRQ LPT2 (0378,PS/2) Drive 9: not present
037B/IRQ7 LPT1 0278/IRQ7 LPT3 (0278,PS/2) Drive 9: not present
037B/IRQ7 LPT1 0278/noIRQ LPT3 (0278,PS/2) Drive 9: not present
0378/IRQ7 LPT1 0378/IRQ7 LPT2 (0378,PS/2) Timeout detected
0378/IRQ7 LPT1 0378/noIRQ LPT2 (0378,PS/2) Timeout detected
0378/IRQ7 LPT1 037B/IRQ7 LPT1 (0378,PS/2) Drive 9: not present
0378/IRQ7 LPT1 037B/noIRQ LPT1 (0378,PS/2) Drive 9: not present
0378/IRQ7 LPT1 0278/IRQ7 LPT3 (0278,PS/2) Drive 9: not present
0378/IRQ7 LPT1 0278/noIRQ LPT3 (0278,PS/2) Drive 9: not present
0278/IRQ5 LPT1 0278/IRQ5 LPT3 (0278,PS/2) Timeout detected
0278/IRQ5 LPT1 0278/noIRQ LPT3 (0278,PS/2) Timeout detected
0278/IRQ5 LPT1 037B/IRQ5 LPT1 (0378,PS/2) Drive 9: not present
0278/IRQ5 LPT1 037B/noIRQ LPT1 (0378,PS/2) Drive 9: not present
0278/IRQ5 LPT1 0278/IRQ5 LPT2 (0378,PS/2) Drive 9: not present
0278/IRQ5 LPT1 0278/noIRQ LPT2 (0378,PS/2) Drive 9: not present
It is apparent the only way to prevent the "Drive 9: not present"
error is to ensure there is a match between the port addresses of
BIOS, Device Manager, and SC Detected Port.
It would appear the only thing I need to resolve now is how to prevent
the "Timeout detected" message for reading the 1541. I have gone
through SC 8.314 instructions over and over to find clues and found
little. I guess I need further suggestions as to what to try next.
Womo, just in case you need answers to your specific questions, here
is the information.
My last and current Device Manager properties for Printer Port (LPT1)
with BIOS set to SPP 0278/IRQ5 were as follows.
Port Settings: Never use an interrupt - ON
Enable legacy Plug & Play detection - ON
Resources: I/O Range - 0278-027f
Setting based on: Current configuration
Use Automatic settings - OFF
Conlicting device list - No conflicts
hodo
wrote:
>_Now_ try to test the connection with XCTest! Perhaps, this is only
>a timing problem now...?
>
>Joe
Joe,
I've run all six tests in XCTest and my results appear to have met all
expectations and passed. I don't completely understand what is
expected in the DRIVE-DETECT-JITTER test, but I think I saw what was
expected.
How does one know if there is a timing problem and what is the
procedure for changing the timing?
I still get the Timeout detected error message when trying to read the
1541.
Vic
Wolfgang Moser
hodo wrote:
> I prepared the below table after testing various addresses and IRQ's
> in BIOS, XP's Device Manager, and SC's Detected Ports. BIOS was set to
> SPP. The SC Error Messages come up when trying to access a 1541-II
> whose device switch is set to 9.
>
> BIOS Device Manager SC Detected Port SC Error Message
>
> 037B/IRQ7 LPT1 037B/IRQ7 LPT1 (037B,PS/2) Timeout detected
> 037B/IRQ7 LPT1 037B/noIRQ LPT1 (037B,PS/2) Timeout detected
> 037B/IRQ7 LPT1 0378/IRQ7 LPT2 (0378,PS/2) Drive 9: not present
> 037B/IRQ7 LPT1 0378/noIRQ LPT2 (0378,PS/2) Drive 9: not present
> 037B/IRQ7 LPT1 0278/IRQ7 LPT3 (0278,PS/2) Drive 9: not present
> 037B/IRQ7 LPT1 0278/noIRQ LPT3 (0278,PS/2) Drive 9: not present
>
> 0378/IRQ7 LPT1 0378/IRQ7 LPT2 (0378,PS/2) Timeout detected
> 0378/IRQ7 LPT1 0378/noIRQ LPT2 (0378,PS/2) Timeout detected
> 0378/IRQ7 LPT1 037B/IRQ7 LPT1 (0378,PS/2) Drive 9: not present
> 0378/IRQ7 LPT1 037B/noIRQ LPT1 (0378,PS/2) Drive 9: not present
> 0378/IRQ7 LPT1 0278/IRQ7 LPT3 (0278,PS/2) Drive 9: not present
> 0378/IRQ7 LPT1 0278/noIRQ LPT3 (0278,PS/2) Drive 9: not present
>
> 0278/IRQ5 LPT1 0278/IRQ5 LPT3 (0278,PS/2) Timeout detected
> 0278/IRQ5 LPT1 0278/noIRQ LPT3 (0278,PS/2) Timeout detected
> 0278/IRQ5 LPT1 037B/IRQ5 LPT1 (0378,PS/2) Drive 9: not present
> 0278/IRQ5 LPT1 037B/noIRQ LPT1 (0378,PS/2) Drive 9: not present
> 0278/IRQ5 LPT1 0278/IRQ5 LPT2 (0378,PS/2) Drive 9: not present
> 0278/IRQ5 LPT1 0278/noIRQ LPT2 (0378,PS/2) Drive 9: not present
Looks almost fine, especially the settings were all three
report/are configured to the very same port address.
And yes, Joe is right, when he complains about the 37B
address. As I can remember, normally the third standard
port address (or the first one, depends on the PC era you
look from) should be 3BC instead.
> It is apparent the only way to prevent the "Drive 9: not present"
> error is to ensure there is a match between the port addresses of
> BIOS, Device Manager, and SC Detected Port.
True. And a 'Timeout detected' message is much "better"
than a '... not present' one.
> It would appear the only thing I need to resolve now is how to prevent
> the "Timeout detected" message for reading the 1541. I have gone
> through SC 8.314 instructions over and over to find clues and found
> little. I guess I need further suggestions as to what to try next.
Manually adjusting the "Delay value" setting may help. But
first you should do an autocalibration. It may result in
a different value in comparison the a plain DOS
configuration.
> My last and current Device Manager properties for Printer Port (LPT1)
> with BIOS set to SPP 0278/IRQ5 were as follows.
>
> Port Settings: Never use an interrupt - ON
> Enable legacy Plug & Play detection - ON
> Resources: I/O Range - 0278-027f
> Setting based on: Current configuration
> Use Automatic settings - OFF
> Conlicting device list - No conflicts
Looks good, except for one thing:
You configured the BIOS to SPP. Are you using a X1541 cable
(the oldest "standard" of the Xcables)? Otherwise this setting
isn't much helpful.
Somewhere I read, that you are using a XA1541 cable, therefore
you should configure your port to ECP+EPP or to ECP (EPP 1.9
should also work).
When you do this, the Windows XP device manager should show you
some more occupied resources, that you could and should report
here. (I could tell you, what I expect to see, but to find
possible errors, it's more helpful the other way around).
hodo
Womo, Joe, Nicolas,
I've just discovered that it is giveio.sys that causes my SC to freeze
on start-up. When giveio.sys is disabled, SC starts up without
freezing but is unable to read the 1541 due to the "Timeout detected"
error message.
When I start giveio.sys when a SC session has been started, SC reads
the 1541, but then freezes. Disabling giveio.sys and restarting SC
does not stop SC from freezing on start-up. However, if I disable
giveio.sys and warm-boot Windows, SC starts without freezing.
I will run some tests with and without userport.sys started or turned
off to see what impact it has on SC freezes, and post those results.
Vic
hodo
>Womo, Joe, Nicolas,
>
>I've just discovered that it is giveio.sys that causes my SC to freeze
>on start-up. When giveio.sys is disabled, SC starts up without
>freezing but is unable to read the 1541 due to the "Timeout detected"
>error message.
>
>When I start giveio.sys when a SC session has been started, SC reads
>the 1541, but then freezes. Disabling giveio.sys and restarting SC
>does not stop SC from freezing on start-up. However, if I disable
>giveio.sys and warm-boot Windows, SC starts without freezing.
>
>I will run some tests with and without userport.sys started or turned
>off to see what impact it has on SC freezes, and post those results.
>
>Vic
It seems giveio.sys holds the secret to SC freezes and 1541 access, on
my system anyway.
Here's the results with BIOS in EPP 1.9 at 0278. For every start or
stop of either GiveIO or UserPort, the system was re-booted before
running SC. Without system re-boots, results are not reliable and may
not match this table.
SC's initial response to activating GiveIO from an inactive state is
to successfully read the 1541 (if SC is in the 1541 read screen),
before SC freezes-up.
GiveIO UserPort StarCommander 1541
off on runs timeout detected
off off runs Drive 9: not present
on on freezes
on off freezes
hodo
I've spent about 8 more hours trying to figure out what's going on.
I definitely can't use GiveIO on my system, either in XP Safe Mode or
XP Normal Mode, without SC freezing on start-up.
I noticed the following reactions to LoadDrv commands in XP Safe vs
Normal Modes, with commands being given in the noted sequence. In all
casses giveio.sys is located in
c:\windows\system32\drivers\giveio.sys.
XP Safe Mode:
1. Remove - Service doesn't exist
2. Install - Operation was successful
3. Install - Service already exists
4. Start - An unexpected error occured
5. Stop - Service hasn't been started
6. Remove - Operation was successful
XP Normal Mode
1. Remove - Service doesn't exist
2. Install - Operation was successful
3. Install - Service already exists
4. Start - Operation was successful
5. Start - Service already exists
6. Stop - operation was successful
7. Stop - Service hasn't been started
8. Remove - Operation was successful
Although giveio.sys installed successully in Safe Mode, it could not
be started. If Device Manager is used to try to start GiveIO, XP
reports it can't be started in Safe Mode.
Using XP Safe Mode without GiveIO but with or without UperPort
started, SC gives the Drive 9:not present error. This tells me it's
not possible to get SC to successfully read 1541's when XP is in Safe
Mode.
Using XP Normal Mode without GiveIO but with Userport started, SC
gives the Timeout Detected error. Changing the Delay Time from 0 to
50 seconds in 1 second intervals does not remove the Timeout Detected
error. Hitting recalibrate always gives a time delay value of 22
seconds.
I tried all the above with LPT port set to 0278 and 0378, both in BIOS
and Device Manager, and ensured the same address was used in BIOS,
Device Manager and SCSetup.
Joe's instructions for installing GiveIO only includes a need to
install, but nothing about starting GiveIO as a necessary step. A
couple of days ago I had noticed in XP Safe Mode that hitting the
start button resulted in "An unexpected error occured", but thought
nothing of it since Joe's instructions didn't address any need to also
hit start to confirm that operation was also successful. Joe needs to
address what users should do when the start operation fails.
Now I just need help to get rid of the Timeout Detected errors in SC
when just UserPort is started and when I'm running in normal XP. When
that is fixed, I should be able to read 1541's.
I think I read somewhere that UserPort can't be used in XP Home
Edition. I'm using XP Professional SP1.
hodo
I used loaddrv.exe to install a newer giveio.sys with 2.12KB dated
2002-05-13 (other giveio.sys is 5.12KB dated 1996-04-03), but Star
Commander still freezes on start-up. If the last active SC screen is
the Drive 9 screen, the 1541 lights momentarily and SC displays floppy
contents before freezing. This is the same reaction as I got from a
started 5.12KB giveio.sys.
It seems that giveio allows access to drive 9 but doesn't allow SC to
proceed any further.
The next observation may provide an answer as to where the freeze
originates.
With giveio.sys installed and started, if I open a DOS window and
execute "debug \\.\giveio", the DOS window freezes!
Perhaps experts out there can figure out reasons for the freezes by
evaluating these observations.
It appears giveio is required for SC to read the 1541, but how can I
get it to run without SC freezing up.
On the other hand, can I get SC to read the 1541 without giveio and
with just userport started, by making adjustments to prevent the
"Timeout detected" error message? Per my previous post, I have tried
all Timeout delay settings from 0 to 50 seconds, in 1 second
increments.
vic20owner
>>>I've just discovered that it is giveio.sys that causes my SC to freeze
>>>on start-up. When giveio.sys is disabled, SC starts up without
>>>freezing but is unable to read the 1541 due to the "Timeout detected"
>>>error message.
>>>
>>>When I start giveio.sys when a SC session has been started, SC reads
>>>the 1541, but then freezes. Disabling giveio.sys and restarting SC
>>>does not stop SC from freezing on start-up. However, if I disable
>>>giveio.sys and warm-boot Windows, SC starts without freezing.
You may want to try using DOS 7. It supposedly will mount NTFS drives
and supports long filenames. In in the process of creating a boot cd
now which will boot DOS, run SC and allow me to access my XP drive. Not
a great solution, but better than a DOS partition.
hodo
wrote:
>
>You may want to try using DOS 7. It supposedly will mount NTFS drives
>and supports long filenames. In in the process of creating a boot cd
>now which will boot DOS, run SC and allow me to access my XP drive. Not
>a great solution, but better than a DOS partition.
In my original post I indicated I looked for and tried DOS boots that
supposedly supported access to NTFS drives, but none worked. I tried
DOSNTFS and Dr.Dos 7.05. I think I'm close to getting SC to work in
XP and hope someone will provide a clue how to do it, taking into
account all my symptoms, tests, and observations.
vic20owner
> In my original post I indicated I looked for and tried DOS boots that
> supposedly supported access to NTFS drives, but none worked. I tried
> DOSNTFS and Dr.Dos 7.05. I think I'm close to getting SC to work in
> XP and hope someone will provide a clue how to do it, taking into
> account all my symptoms, tests, and observations.
Whoops sorry about that. I missed the start of the thread. It's funny
you mention that because I'm having trouble getting DOS7 to see my NTFS
drive too. Hmph. I thought Iread in the documentation for SC that even
tuned and working under XP it is still prone to freezing. I'm still
amazed that today's multitasking operating systems are not able to do a
simple thing like communicate synchronously through a parallel port.
-tom
vic20owner
> In my original post I indicated I looked for and tried DOS boots that
> supposedly supported access to NTFS drives, but none worked. I tried
> DOSNTFS and Dr.Dos 7.05. I think I'm close to getting SC to work in
> XP and hope someone will provide a clue how to do it, taking into
> account all my symptoms, tests, and observations.
Wait a minute. Don't the SC instruction say to install the "userport"
driver for XP, and the "giveio" driver for NT/2000?
I could be wrong but I'm getting ready to try the same thing, and the
way I'm interpreting the intruction is that I need to install the
userport driver, and not the giveio driver.
Tom
hodo
wrote:
>
>Wait a minute. Don't the SC instruction say to install the "userport"
>driver for XP, and the "giveio" driver for NT/2000?
>
>I could be wrong but I'm getting ready to try the same thing, and the
>way I'm interpreting the intruction is that I need to install the
>userport driver, and not the giveio driver.
>
>Tom
Tom,
SC instructions for running under XP is to install either giveio or
userport or both, whichever gets SC to read 1541's through a X1541
series cable.
Per my thread follow-ups, I have tried and logged many combinations,
without success.
I'm hoping the gurus here will be able to figure out how to get SC to
work properly. It may not be a direct problem with SC, but a problem
with giveio compatiblity.
Vic
vic20owner
> Per my thread follow-ups, I have tried and logged many combinations,
> without success.
>
> I'm hoping the gurus here will be able to figure out how to get SC to
> work properly. It may not be a direct problem with SC, but a problem
> with giveio compatiblity.
Me too :(
I've been trying for 2 hours now (much lass than you, but I'm getting
ready to give up on it)
-tom
Sam Gillett
"vic20owner" <vic20...@yahoo.com> wrote ...
> Whoops sorry about that. I missed the start of the thread. It's funny
> you mention that because I'm having trouble getting DOS7 to see my NTFS
> drive too. Hmph. I thought Iread in the documentation for SC that even
> tuned and working under XP it is still prone to freezing.
Seems I remember something about DOS 7 being limited to drives under a
specific size. Maybe your drive is simply too large?
--
Best regards,
Sam Gillett
Change is inevitable,
except from vending machines!
bud
'Lo all:
Group: comp.sys.cbm Date: Sun, May 23, 2004, 12:28am (CDT+5) From:
vic20...@yahoo.com (vic20owner)
script:
>… I'm having trouble getting DOS7 to
>see my NTFS drive too.…
>
>-tom
FWIW: I haven't had an NTFS partition to try WinME (DOS 8) on, however,
I have read (or been told) that if one SYSes a floppy under XP, the flop
will have the SYS files for DOS 8 (WinME) on it.
You might want to try that to see if it helps. (I.e., boot from the
flop to see if you can work with SC that way.)
salaam,
dowcom
--
To e-mail me, add the character zero to "dowcom". i.e.:
dowcom(zero)(at)webtv(dot)net.
http://community.webtv.net/dowcom/DOWCOMSAMSTRADGUIDE
MSWindows is television,… Linux is radar.
vic20owner
> work properly. It may not be a direct problem with SC, but a problem
> with giveio compatiblity.
Well, Vic, I was up until 3:30 am last night messing with this thing. I
did finally manage to get it to work under XP. I set the UserPort
driver to 378-37f (my LPT) and opened a dos window. I typed debug
\\.\UserPort, q, then ran SC. I selected the port and turned on manual
timeouts, warp, EX1541 (for my cable), and Async.
Then... magically it worked! I copied about 5 disks and some files. I
still got timeouts after copying each file, but the files copied ok as
far as I can tell.
I managed to make an image of one of the Infoquick disks sent to me by
Gary (Thanks Gary!) but the other disks had R/W errors.
Now here's the bad news.....
This morning I started it up and all I get is TIMEOUT!! It won't work at
all. I've been messing with it for over an hour. My conclusion is that
even if you get it working it may not keep working. I think I'll find
an old dos machine and commit it to the cause....
hodo
wrote:
>Well, Vic, I was up until 3:30 am last night messing with this thing. I
>did finally manage to get it to work under XP. I set the UserPort
>driver to 378-37f (my LPT) and opened a dos window. I typed debug
>\\.\UserPort, q, then ran SC. I selected the port and turned on manual
>timeouts, warp, EX1541 (for my cable), and Async.
>
>Then... magically it worked! I copied about 5 disks and some files. I
>still got timeouts after copying each file, but the files copied ok as
>far as I can tell.
>
>I managed to make an image of one of the Infoquick disks sent to me by
>Gary (Thanks Gary!) but the other disks had R/W errors.
>
>Now here's the bad news.....
>
>This morning I started it up and all I get is TIMEOUT!! It won't work at
>all. I've been messing with it for over an hour. My conclusion is that
>even if you get it working it may not keep working. I think I'll find
>an old dos machine and commit it to the cause....
Tom,
Starting either or both giveio or userport by executing the debug
command doesn't make any difference on my system. Whenever giveio is
started, SC still freezes on start-up. If userport is already
started, the "Timeout Detected" message pops up and SC freezes. If
userport is not started, SC displays the "Drive 9: not present"
message and freezes.
I suspect the freeze-ups are only keyboard/gui freezes within the DOS
window and that SC is actually still active.
I spent a good amount of time last night looking for an alternative
program to giveio for direct port I/O stuff. I found and tried
DriveIO and ParaPort to no avail. Maybe someone knows of other good
alternatives to try in place of giveio.
I don't have a problem running SC on my system with with XAP1541
adapter if I boot DOS from a floppy. The problem is I can only save
C64 images on the PC's 3 1/4" drive. I could create a FAT partition on
my HD in order to save images to the HD, but would prefer not to do
that.
Vic
vic20owner
> I don't have a problem running SC on my system with with XAP1541
> adapter if I boot DOS from a floppy. The problem is I can only save
> C64 images on the PC's 3 1/4" drive. I could create a FAT partition on
> my HD in order to save images to the HD, but would prefer not to do
> that.
Same here. One more note: I disabled my LPT port in windows... no, that
didn't help, it made things worse. When I re-enabled it, SC started
working. ?!??! I tried this process again, no luck.
My machine is already dual booted, so I'm afraid creating a dos
partition at this point will leave me fighting with boot managers, etc.
tom
Nicolas Welte
>> I'm hoping the gurus here will be able to figure out how to get SC to
>> work properly. It may not be a direct problem with SC, but a problem
>> with giveio compatiblity.
>
>
> Well, Vic, I was up until 3:30 am last night messing with this thing. I
> did finally manage to get it to work under XP. I set the UserPort
> driver to 378-37f (my LPT) and opened a dos window. I typed debug
> \\.\UserPort, q, then ran SC. I selected the port and turned on manual
> timeouts, warp, EX1541 (for my cable), and Async.
I usually turn off manual timeout. IIRC, the added keyboard query can mess up
the timing in some cases. Also, it may help to stop and restart userport.sys
via the userport.exe program manually. Don't ask me why, but sometimes this
helped for me.
> Then... magically it worked! I copied about 5 disks and some files. I
> still got timeouts after copying each file, but the files copied ok as
> far as I can tell.
I don't recommend using file copy in Windows. It's possible that SC falls
back to the standard IEC protocol after each file, and this isn't very
Windows friendly. I don't tempt my luck and use disk copy in Windows only. If
there are still timeouts during a disk copy, I disable the LPT port in
Windows device manager completely. For me this got rid of all timeouts!
vic20owner
> the LPT port in Windows device manager completely. For me this got rid
> of all timeouts!
Whenever I disable LPT1 in the device manager, SC fails to see the port
even if I specify the range! Any ideas?
-tom
Wolfgang Moser
Nicolas Welte wrote:
>
> I usually turn off manual timeout. IIRC, the added keyboard query can
> mess up the timing in some cases. Also, it may help to stop and restart
this is also intersting to me, since I had 'manual timeouts'
enabled all the time. Maybe this is one of the reasons that
I couldn't get SC to run with my XP tests some months ago.
Perhaps this information should be included in the SC docs?
Since I didn't redo my Star-Commander-on-Windows-XP tests
since then I'll be quiet again in this news thread.
I hopefully find some time the next days to help Hodo by
doing some own tests again.
hodo
<welte...@freenet.de> wrote:
>I don't recommend using file copy in Windows. It's possible that SC falls
>back to the standard IEC protocol after each file, and this isn't very
>Windows friendly. I don't tempt my luck and use disk copy in Windows only. If
>there are still timeouts during a disk copy, I disable the LPT port in
>Windows device manager completely. For me this got rid of all timeouts!
Nicolas,
My XP's reaction to disabling LPT port in device manager is the same
as Tom's; that is SC reports "Drive 9:not present". No combination of
giveio and userport gives "Timeout detected". Of course, with giveio
started, SC always freezes.
Your precaustion about not trying file copy within Windows give me
some concern. From what I've seen about D64 images, all file data is
layed out as it is on a 1541 floppy, with BAM and link information
intact.
If I wanted to take a Pocket Writer data file from the D64 disk image
file, I would never get a file that's clean of the link points. That
would mean a lot of clean-up would be required in Word before I could
use the data.
When I did my Pocket Writer data file conversions from .prg PETSCII to
.seq ASCII, I initially did full disk copy .D64 copies using SC in
pure DOS. In order to use the individual data files, I had to find
the data files within the D64 image. Then I was stuck with data which
included 1541 pointers and BAM link points. That was not acceptable,
so I used SC to copy each and every .seq file, which worked perfectly
for the purpose of importing the data into Word.
My primary motivation for getting the X541 series cables to work under
Windows was to make it easier to transfer Pocket Writer data files
directly to my NTFS HD's, hopefully within XP.
If what you're saying about file copying within XP is true, I may be
SOL, even when and if I somehow succeed in getting SC to work under
XP!
Vic
hodo
>My primary motivation for getting the X541 series cables to work under
>Windows was to make it easier to transfer Pocket Writer data files
>directly to my NTFS HD's, hopefully within XP.
>
>If what you're saying about file copying within XP is true, I may be
>SOL, even when and if I somehow succeed in getting SC to work under
>XP!
I realize D64 files are just 1541 floppy images and therefore only
useable for transfer between a C= floppy and a PC, or by a C64
Emulator in the PC. Such D64 image files are not usefull for the
purpose of transfering and using data files for use in PC app's.
My family must have been amongst the few C64 users that actually used
their C64's for productivity applications. Pocket Writer was truly a
great word processor. PW had features and simplicity that Word has
yet to duplicate. I created PW charts and tables in the mid 80's that
were only duplicated by using high end non-PC word processors.
I have yet to install and run a C64 emulator. I don't see the need to
run an emulator since I have 3 SX-64's if the urge and need arises to
play games. But it would be nice to use the HD or CDR's to store
images of my C64 software collection.
Joe Forster/STA
- There's no need to, actually, _start_ either giveio or userport
(with the "debug \\.\XXX" command) as the Commander starts (more
precisely: initializes) both before each access of the Commodore
drive. This is not very clear in the tweak package docs, right?
- Vic, please, gimme the download URL of the newer giveio.sys!
- The fact that "debug \\.\giveio" freezes the DOS shell shows that
the freeze is not the Commander's fault. There's something wrong
with giveio instead (probably, some configuration or compatibility
problem)...
- Multitasking systems _are_ able to do synchronous communication, as
cbm4linux's example shows. Unfortunately, the Commander is a DOS
program and it can't make use of parallel port interrupts as part
of the handshake, as cbm4linux does.
- No, you do _not_ install both giveio and userport on the same system!
(This _might_ be the cause for the lockup...?!) giveio is fine for
Windows NT but you might be better off with userport under Windows
2000 and XP. Again, the tweak package docs are not very clear about
this, right?
- Disable "Manual timeouts" all the time! While it _may_ help under
real DOS, it will, for sure, give you problems under multitasking
systems. This is mentioned twice in the docs.
- Do _not_ copy files under a multitasking system! Yes, the Commander
uses the C64 KERNAL protocol at the beginning (uploading small disk
turbo) and at the end (querying command channel) of every transfer,
and this protocol is not designed for multitasking. This is also in
the docs.
I'm sorry that I cannot give more specific ideas on solving the initial
problem... :-/ Bye,
Joe
--
KOVÁCS Balázs alias Joe Forster/STA s...@c64.org; http://sta.c64.org
Orsolya u. 5. IV/12., 1204 Budapest, Hungary; +36-1-285-3881, 6-10PM CET
(SpamAssassin protection! No HTML E-mails! No uncompressed attachments!)
hodo
>Hi guys, some all-in-one answers...
>
>- There's no need to, actually, _start_ either giveio or userport
> (with the "debug \\.\XXX" command) as the Commander starts (more
> precisely: initializes) both before each access of the Commodore
> drive. This is not very clear in the tweak package docs, right?
Tweak instructions suggest using the debug command "if the program
you're running is unable to use the "giveio" driver manually". In my
case I assumed it was possible that giveio was not useable since SC
would always freeze when it was started using loaddrv.
>- Vic, please, gimme the download URL of the newer giveio.sys!
http://www.cobbleware.com/gp32/gp32jtag.html and the dowanload URL is
http://www.cobbleware.com/files/giveio.zip
>- The fact that "debug \\.\giveio" freezes the DOS shell shows that
> the freeze is not the Commander's fault. There's something wrong
> with giveio instead (probably, some configuration or compatibility
> problem)...
"debug \\.\giveio" only freezes the DOS shell if giveio is already
started either by loaddrv or by automatic startup in device manager.
If I execute "debug \\.\userport" when giveio is already started by
"debug \\.\giveio" in the same DOS window, or previously started by
loaddrv or automatic startup in device manager, the DOS window does
not freeze.
Is it possible the freeze by SC is the result of the way "Commander
starts (more precisely: initializes) both before each access of the
Commodore drive", whenever giveio has previously been started, in my
system? Is this a possible code bug in SC?
>- Multitasking systems _are_ able to do synchronous communication, as
> cbm4linux's example shows. Unfortunately, the Commander is a DOS
> program and it can't make use of parallel port interrupts as part
> of the handshake, as cbm4linux does.
>- No, you do _not_ install both giveio and userport on the same system!
> (This _might_ be the cause for the lockup...?!) giveio is fine for
> Windows NT but you might be better off with userport under Windows
> 2000 and XP. Again, the tweak package docs are not very clear about
> this, right?
I get SC lockups only when giveio is started. I doesn't make any
difference if userport is started or not.
When userport is started with or without giveio started, the SC
startup screen always gives the "Timeout detected" error message, if
the SC ini startup window is the Drive 9 window. With giveio started,
SC also immediately freezes. However, with userport started without
giveio also being started, I get an active SC screen with just the
"Timeout detected" message of the Drive 9 window.
Depending on the sequence of starting giveio, userport, and starting
SC with drive 9 as the SC startup screen, the 1541 drive activity
light comes on and SC displays the content before freezing.
Please note I am very meticulous about re-booting XP before running SC
with different giveio and userport start configurations. On every
boot-up, I use device manager to check whether or not giveio or
userport are started, and also run loadddrv.exe and userport.exe to
confirm the same. I unload the giveio driver by first using loaddrv
to stop and remove it, then using device manager to unload it. I
unload userport by first stopping it with userport.exe, then unloading
it in device manager. All such unloadings are followed by re-boots
before trying anything further.
>- Disable "Manual timeouts" all the time! While it _may_ help under
> real DOS, it will, for sure, give you problems under multitasking
> systems. This is mentioned twice in the docs.
Docs initially say "turn 'Manual timeouts' on or off......" I have
done all my tests with it off, as per one of your earlier suggestions.
>- Do _not_ copy files under a multitasking system! Yes, the Commander
> uses the C64 KERNAL protocol at the beginning (uploading small disk
> turbo) and at the end (querying command channel) of every transfer,
> and this protocol is not designed for multitasking. This is also in
> the docs.
I presume this means attempts to transfer single sequential data files
using SC in XP will likely be unsuccessful. I we can get SC to start
in my XP, I'd want to try it first before going back to using SC in
pure DOS and in a floppy drive environment.
>I'm sorry that I cannot give more specific ideas on solving the initial
>problem... :-/ Bye,
What about preventing the "Timeout detected" error in SC when userport
is started without giveio? SC starts without freeze-ups in this mode.
I was under the impression this error was more easily resolved
compared to the "Drive 9:not present" error which is what I get when
userport is not started.
Joe, I really appreciate your efforts in this endeavour. I have tried
to be as complete and comprehensive as possible in presenting my
problems. I don't sit back and wait for responses. I am always
trying things and try to ensure everything is completely repeatable. I
have spent the best part of the last 2 weeks doing this.
Good thing I'm retired!
Thanks,
Vic
Joe Forster/STA
> Tweak instructions suggest using the debug command "if the program
> you're running is unable to use the "giveio" driver manually". In my
> case I assumed it was possible that giveio was not useable since SC
> would always freeze when it was started using loaddrv.
Okay, gonna make a note in the tweak docs about the Commander doing it
automatically.
>>- Vic, please, gimme the download URL of the newer giveio.sys!
Thanks. It's an _installable_ version of giveio.sys, nice! I'll test
it and add it to the tweak package if's easier to use...
> "debug \\.\giveio" only freezes the DOS shell if giveio is already
> started either by loaddrv or by automatic startup in device manager.
Yes, of course. If the driver is not active (read: is not running in
the background, listening to such calls) then calls to it won't do
anything (well, perhaps, you might get some kind of an error message,
e.g. that the "\\.\giveio" file doesn't exist?)...
> If I execute "debug \\.\userport" when giveio is already started by
> "debug \\.\giveio" in the same DOS window, or previously started by
> loaddrv or automatic startup in device manager, the DOS window does
> not freeze.
This suggests that userport is working fine, while there's some
problem with giveio. That is, calling userport is okay but calling
giveio results in a freeze of the DOS window. Conclusion: try userport
_only_, that is, stop/disable gievio in the device manager.
The Commander tries to initialize _both_ drivers as it has no way of
finding out which of them is installed/active. If it manages to send
a call to giveio, the DOS shell will freeze; so, giveio mustn't be
there, to be called. But the Commander can also initialize userport
which is supposed to do the same thing!
> Is it possible the freeze by SC is the result of the way "Commander
> starts (more precisely: initializes) both before each access of the
> Commodore drive", whenever giveio has previously been started, in my
> system?
Yes, I described the same above, I guess...
> Is this a possible code bug in SC?
As it occurs with the Commander not even having been started (just a
"debug \\.\XXX" command), I don't think so. Such freezes/lockups
_have_ been reported but they're, actually, only delays for which
the "Usage" section suggests turning "Detect port modes" off; see
the list of possible strange behaviors in that section.
> However, with userport started without
> giveio also being started, I get an active SC screen with just the
> "Timeout detected" message of the Drive 9 window.
Good; as I said, this means that the Commander didn't mess up anything
when it tried to access the parallel port, with giveio's/userport's
help. _Now_ is the time to do some low level testing with XCTest!
> Docs initially say "turn 'Manual timeouts' on or off......"
That's in the "Troubleshooting" section and it explains the problems
when it is turned on. ;-)
>>- Do _not_ copy files under a multitasking system! Yes, the Commander
>> uses the C64 KERNAL protocol at the beginning (uploading small disk
>> turbo) and at the end (querying command channel) of every transfer,
>> and this protocol is not designed for multitasking. This is also in
>> the docs.
>
> I presume this means attempts to transfer single sequential data files
> using SC in XP will likely be unsuccessful.
Nope. It means that the chances of getting timeouts and crashes at the
beginning or end of _file_ transfers is higher than at the beginning or
at the end of _disk_ transfers. In other words, in a multitasking
system, copy disks rather than individual files with the Commander.
> What about preventing the "Timeout detected" error in SC when userport
> is started without giveio?
This error message is not to be prevented. It tells you that the
Commander was unable to get _any_ reply from the Commodore drive
so there's nothing it can do to access it.
> I was under the impression this error was more easily resolved
> compared to the "Drive 9:not present" error which is what I get when
> userport is not started.
I don't really remember this part of the code so I don't know which
error message means better results, that is, having gotten further
with trying to access the drive... Bye,
hodo
wrote:
>> However, with userport started without
>> giveio also being started, I get an active SC screen with just the
>> "Timeout detected" message of the Drive 9 window.
>
>Good; as I said, this means that the Commander didn't mess up anything
>when it tried to access the parallel port, with giveio's/userport's
>help. _Now_ is the time to do some low level testing with XCTest!
>
This brings me back to my earlier response to your suggestion of
running XCTest. I had mentioned XCTest will not report anything
unless userport is started. I reported the following XCTest results
with userport started.
"I've run all six tests in XCTest and my results appear to have met
all expectations and passed. I don't completely understand what is
expected in the DRIVE-DETECT-JITTER test, but I think I saw what was
expected."
"How does one know if there is a timing problem and what is the
procedure for changing the timing?"
"I still get the Timeout detected error message when trying to read
the 1541."
There is nothing in XCTest instructions about running low level
testing, unless the suggested tests are "low level" tests.
>> I was under the impression this error was more easily resolved
>> compared to the "Drive 9:not present" error which is what I get when
>> userport is not started.
>
>I don't really remember this part of the code so I don't know which
>error message means better results, that is, having gotten further
>with trying to access the drive... Bye,
My impression that "Timeout detected" was a better error report than
"Drive 9;not present" and something that could be resolved because you
said that getting XCTest to respond (as is the case with userport
started) was better than not getting XCTest to respond (as is the case
without userport started).
Vic
Nicolas Welte
With specifying the range, you mean you enter the port range manually into
the Commander (thus creating a user defined port)? When I did this, it worked
for me without problems. But I have an older motherboard (Asus P2B) which
does not allow PnP configuration of the LPT port, it always is at the address
I specify in the BIOS setup. It's possible that newer LPT implementations do
not have an address at all if they're disabled in Windows. In this case,
you're pretty much out of luck.
Nicolas Welte
> Your precaustion about not trying file copy within Windows give me
> some concern. From what I've seen about D64 images, all file data is
> layed out as it is on a 1541 floppy, with BAM and link information
> intact.
No problem with this. It's only one extra step of work: First copy the disk
to a .d64 image, then open this image with Star Commander, and use it to copy
one or more files from this image onto your NTFS drive. (For an expert SC
user this is just a few key presses: ENTER, +, ENTER, F5, ENTER).
> If what you're saying about file copying within XP is true, I may be
> SOL, even when and if I somehow succeed in getting SC to work under
> XP!
Don't worry. A .d64 is just a virtual disk, and SC can work with it the same
way as it can with a real disk. Only faster, and without timeout errors ;)
hodo
<welte...@freenet.de> wrote:
>> Your precaustion about not trying file copy within Windows give me
>> some concern. From what I've seen about D64 images, all file data is
>> layed out as it is on a 1541 floppy, with BAM and link information
>> intact.
>
>No problem with this. It's only one extra step of work: First copy the disk
>to a .d64 image, then open this image with Star Commander, and use it to copy
>one or more files from this image onto your NTFS drive. (For an expert SC
>user this is just a few key presses: ENTER, +, ENTER, F5, ENTER).
>
>> If what you're saying about file copying within XP is true, I may be
>> SOL, even when and if I somehow succeed in getting SC to work under
>> XP!
>
>Don't worry. A .d64 is just a virtual disk, and SC can work with it the same
>way as it can with a real disk. Only faster, and without timeout errors ;)
>
Nicolas,
Thanks for clarifying that.
Vic
Nicolas Welte
stuff running! I ran some tests with XP-SP1, XAP1541 adaptor and a 1541-II
(only serial cable, SC set to serial=XA1541, parallel=none).
0. One important diagnostic hint: If SC has LPT access, even if the timing is
completely messed up, you can ALWAYS reset your drive with pressing the keys
CTRL-ALT-BACKSPACE simultaneously! If this doesn't work, you have a
configuration problem in giveio, userport, or SC itself!
1. I repeat my earlier comment on restarting the userport driver. When I
start up my Windows, and try to access the drive (also method 0.), there is
no success. I have to start userport.exe, press STOP, and then START again.
Then I start SC, and then I have access!
2. I also repeat my hint about disabling/deactivating the LPT port in Windows
device manager. If it's enabled (and the drive switched on), the drive resets
several times during booting Windows, and also some time afterwards. There is
no change if the "legacy PnP" option is enabled! With the LPT port enabled, I
can't get a full disk copy finish without a crash or timeout with the serial
cable. With the parallel cable, sometimes it finishes, sometimes it doesn't.
PS to Joe: maybe there's some (Windows) way to lock the LPT port so it's not
accessed by the PnP stuff anymore, and then SC has exclusive access. It seems
(see reports in this thread) that disabling the port completely doesn't work
on all machines.
Nicolas
hodo
<welte...@freenet.de> wrote:
>One follow-up to my own mail, with IMPORTANT info that might help to get this
>stuff running! I ran some tests with XP-SP1, XAP1541 adaptor and a 1541-II
>(only serial cable, SC set to serial=XA1541, parallel=none).
>
>0. One important diagnostic hint: If SC has LPT access, even if the timing is
>completely messed up, you can ALWAYS reset your drive with pressing the keys
>CTRL-ALT-BACKSPACE simultaneously! If this doesn't work, you have a
>configuration problem in giveio, userport, or SC itself!
>
>1. I repeat my earlier comment on restarting the userport driver. When I
>start up my Windows, and try to access the drive (also method 0.), there is
>no success. I have to start userport.exe, press STOP, and then START again.
>Then I start SC, and then I have access!
>
>2. I also repeat my hint about disabling/deactivating the LPT port in Windows
>device manager. If it's enabled (and the drive switched on), the drive resets
>several times during booting Windows, and also some time afterwards. There is
>no change if the "legacy PnP" option is enabled! With the LPT port enabled, I
>can't get a full disk copy finish without a crash or timeout with the serial
>cable. With the parallel cable, sometimes it finishes, sometimes it doesn't.
>
>PS to Joe: maybe there's some (Windows) way to lock the LPT port so it's not
>accessed by the PnP stuff anymore, and then SC has exclusive access. It seems
>(see reports in this thread) that disabling the port completely doesn't work
>on all machines.
>
Nicolas,
Following your suggestions explicitly on my system which has XP-SP1,
XAP1541 adaptor and a 1541-II (only serial cable, SC set to
serial=XA1541, parallel=none), I still get the "Drive 9: not present"
error, no matter how many times I stop and start userport.
To be sure no latent LPT1 activity exists after disabling LPT1 in
device manager, I re-booted before runing tests with SC and userport
stop/start.
When LPT1 is disabled in device manager, available Parallel Ports in
SCSetup Serial Interface show addresses for LPT1 (03bc, EPP) and LPT3
(0278, EPP), but none for LPT2 which normally picks up LPT2 (0378,
EPP) when LPT1 is enabled in device manager. My current BIOS setting
for LPT is 0378, EPP 1.9.
With LPT1 disabled by device manager, XCTest fails all 6 tests for
XA1541 and 0378. Trying the test with 03BC & 0278 also fails. The
drive LED does not come on during the Drive-Reset test.
When LPT1 is enabled in device manager, SCSetup shows 0378, EPP as
LPT2. Selecting LPT2 results in the "Timeout detected" error in SC.
Selecting either LPT1 (03BC, EPP) or LPT3 (0278, EPP) results in
"Drive 9: Not present".
With LPT1 enabled by device manager, XCTest passes all 6 tests for
XA1541 and 0378.
Vic
Wolfgang Moser
I'm back with some own tests made on the following system
(with no/bad success to say it first):
Hardware (basic configuration):
Mainboard: Asus P2B-DS, rev 1.04
CPU: 1x Pentium III 850 MHz (via Powerleap CPU converter)
(my system is currently unstable with the
second CPU inserted)
RAM: 768 MB PC-133 (3x 256 MB)
LPT-Port: integrated to mainboard, EPP+ECP, 0x378, IRQ 7, DMA 3
Additional LPT: SIIG CyberParallel Dual, Dual PCI-LPT port card
LPT 2: EPP+ECP, 0xA800..0xA803, 0xB000..0xB007, IRQ 17
LPT 3: EPP+ECP, 0xB400..0xB403, 0xB800..0xB807, IRQ 17
Operating System:
OS: Microsaft Windows XP Professional, SP 1, all available
hotfixes through Windows-Update
LPT-Configuration:
LPT 1: I/O: 0x0378..0x037B (basic port address)
I/O: 0x0778..0x077B (ECP additional addresses)
IRQ: 07
DMA: 03
Possibly problematic software installations:
MBM Motherboard-Monitor 5.3.0
Sygate Personal Firewall 5.5
Daemon Tools 3.44, Virutal Daemon Manager
McAfee Antivirus 4.5 (Service normally disabled, when offline)
Hardware access drive:
UserPort.sys (since I already had bad experiences with GiveIO
under WIndows XP. With Windows NT 4.0 GiveIO
worked flawlessly for years)
Nicolas Welte wrote:
> One follow-up to my own mail, with IMPORTANT info that might help to get
> this stuff running! I ran some tests with XP-SP1, XAP1541 adaptor and a
> 1541-II (only serial cable, SC set to serial=XA1541, parallel=none).
Oh, yes, forgot to mention the SC configuration:
Cable: XAP1541
Drive: 1541-II with parallel cable connection
Transfer mode: Warp, parallel
Drive Exec mode: Warp
Manual Timeout: Disabled
> 0. One important diagnostic hint: If SC has LPT access, even if the
> timing is completely messed up, you can ALWAYS reset your drive with
> pressing the keys CTRL-ALT-BACKSPACE simultaneously! If this doesn't
> work, you have a configuration problem in giveio, userport, or SC itself!
True. With all my tests, this criteria was a reliable detection,
if the connection works in general.
One observation from my tests:
Whenever I disabled the integrated LPT port at address 0x378 in
the current hardware profile, SC wasn't able to reset the drive
with CTRL-ALT-BACKSPACE. Stopping, (Updating,) Starting
UserPort.sys in between didn't solve anything, the drive couldn't
be reset. Only when I enabled (activated) the LPT port again
within the device manager, SC was able to access the drive.
> 1. I repeat my earlier comment on restarting the userport driver. When I
> start up my Windows, and try to access the drive (also method 0.), there
> is no success. I have to start userport.exe, press STOP, and then START
> again. Then I start SC, and then I have access!
At me, this had no effect in several cases. Ohhh, something about
the problems here:
If the drive is accessible in general (via the CTRL-ALT-BACKSPACE
test check) and if I try to read a directory of some disk, I
always get an error message like "READ ERROR 18;00".
When I don't use the feature "[Detect] Extended 1541 disks", I
mainly get the message "Timeout detected".
Result: In general, the connection does work and the drive can
be accessed somehow. But because of timing issues (my
personal assumptions), the transfer is not reliable and
aborts with several error symptoms.
Since it seems, that I cannot disable my LPT port in the
device manager without losing it all the way, the chance
to get a reeliable connection seems to be very low.
> 2. I also repeat my hint about disabling/deactivating the LPT port in
> Windows device manager. If it's enabled (and the drive switched on), the
> drive resets several times during booting Windows, and also some time
> afterwards. There is no change if the "legacy PnP" option is enabled!
Hmmm, I saw that check box and it was not enabled. But I'll have
a look onto it again. Maybe this was/is the reason, why I cannot
disble the port without losing it all over the system (and SC
also).
> With the LPT port enabled, I can't get a full disk copy finish without a
> crash or timeout with the serial cable. With the parallel cable,
> sometimes it finishes, sometimes it doesn't.
Since I didn't get any sucess with my parallel cable setup I
didn't test the serial-only connection.
> PS to Joe: maybe there's some (Windows) way to lock the LPT port so it's
> not accessed by the PnP stuff anymore, and then SC has exclusive access.
> It seems (see reports in this thread) that disabling the port completely
> doesn't work on all machines.
Seems to be so. But if I remember correctly, we both have got
nearly the same motherboard type (Asus P2B-DS). And since we
surely installed the same Windows XP version, I cannot see any
reason, why disabling the port doesn't seem to work at me.
So far, Womo
PS: Are there any volunteers with Visual Studio .NET experiences,
that may want to experiment with logix4u's direct-IO DLL:
http://www.logix4u.net/inpout32.htm
Maybe someone is able to write some sort of reliable software
adaptor for The Star Commander and Windows XP???
Wolfgang Moser
Wolfgang Moser wrote:
> [...]
>> 2. I also repeat my hint about disabling/deactivating the LPT port in
>> Windows device manager. If it's enabled (and the drive switched on),
>> the drive resets several times during booting Windows, and also some
>> time afterwards. There is no change if the "legacy PnP" option is
>> enabled!
>
>
> Hmmm, I saw that check box and it was not enabled. But I'll have
> a look onto it again. Maybe this was/is the reason, why I cannot
> disble the port without losing it all over the system (and SC
> also).
I double checked the "legacy PnP" item now. It's disabled (not
checked) here, but disabling (deactivating) the LPT port (the
mainboard integrated LPT port at 0x378) also disables any access
from The Star Commander also. There seems to be no way to get
access to it, even manually setting the port address of 0x378
within the Transfer options dialog doesn't help (CTRL-ALT-BKSP
test used to check for it).
> [...]
Nicolas, do you use some specialised PIF file to call SC at
your XP box? Maybe you set some other things there? I can
remember, that I set the "compatible hardware timer emulation"
checkbox with my previous NT 4 installation.
Oh and another thing: Which LPT device driver do you use? When I
looked for my version I saw these signatures:
Microsoft, 01.07.2001, 5.1.2600.0, Microsoft Windows Publisher
Some driver details:
...\system32\drivers\parport.sys
5.1.2600.1106 (xpsp 1.020828-1920)
Maybe there's another parport.sys kernelmode driver available???
Womo
Nicolas Welte
> I double checked the "legacy PnP" item now. It's disabled (not
> checked) here, but disabling (deactivating) the LPT port (the
this legacy PnP option is disabled by default. The new tweak package docs say
you should enable it if you have problems. I tried this, but it helped
nothing for the timeout/lockup problems I have if the LPT device is enabled.
> Nicolas, do you use some specialised PIF file to call SC at
> your XP box? Maybe you set some other things there? I can
> remember, that I set the "compatible hardware timer emulation"
> checkbox with my previous NT 4 installation.
I don't think I change anything. I use the standard PIF file that comes with
XP (SP1). There is one thing that is special about my XP installation, but I
don't remember if I changed it before or after my initial tests with the
Commander: I disabled ACPI support (But I think I changed to ACPI-less XP
later than testing SC)! I had to do this because ACPI occupies IRQ9, and my
soundcard needs it for hardware MIDI support.
> Oh and another thing: Which LPT device driver do you use? When I
> looked for my version I saw these signatures:
> ...\system32\drivers\parport.sys
> 5.1.2600.1106 (xpsp 1.020828-1920)
I have the same version.
Wolfgang Moser
Nicolas Welte wrote:
>> I double checked the "legacy PnP" item now. It's disabled (not
>> checked) here, but disabling (deactivating) the LPT port (the
>
> this legacy PnP option is disabled by default. The new tweak package
> docs say
> you should enable it if you have problems. I tried this, but it helped
> nothing for the timeout/lockup problems I have if the LPT device is
> enabled.
I also tried both variants, but I'll have a deeper look again
when I get time for some new tests.
>> Nicolas, do you use some specialised PIF file to call SC at
>
> I don't think I change anything. I use the standard PIF file that comes
> with XP (SP1).
Ok.
> There is one thing that is special about my XP installation,
> but I
> don't remember if I changed it before or after my initial tests with the
> Commander: I disabled ACPI support (But I think I changed to ACPI-less XP
Hmmm, this sounds interesting. With my P2B-DS board I had to
resolder a resistor to get the board correctly working with
dual CPU board. This was needed, so that I could install XP
with the ACPI-HAL (hardware abstraction layer of Windows NT
systems).
It seems that I need to do some tests with an alternative
HAL, that I'll integrate into the boot.ini options. OK, I'll
lose some functions like programmed Power-Off then, but it's
probably worth the try to test the APM-HAL.
>> Oh and another thing: Which LPT device driver do you use? When I
>> 5.1.2600.1106 (xpsp 1.020828-1920)
>
> I have the same version.
Ok.
Spiro Trikaliotis
some late reply:
Nicolas Welte <welte...@freenet.de> schrieb:
> PS to Joe: maybe there's some (Windows) way to lock the LPT port so
> it's not accessed by the PnP stuff anymore, and then SC has exclusive
> access. It seems (see reports in this thread) that disabling the port
> completely doesn't work on all machines.
Yes, there is a way to get exclusive access to the parallel port in all
Windows version (except Win95, I don't know about that one). This is
even mandatory for using the port as a device. Unfortunately, since that
requires issueing an IOCTL_INTERNAL_PARALLEL_PORT_ALLOCATE, which is an
internal (=kernel-mode only) IOCTL (IRP_MJ_INTERNAL_DEVICE_CONTROL),
this is only possible from a device driver in Windows.
Regards,
Spiro.
--
Spiro R. Trikaliotis
http://www.trikaliotis.net/
Nicolas Welte
> Yes, there is a way to get exclusive access to the parallel port in all
> Windows version (except Win95, I don't know about that one). This is
> even mandatory for using the port as a device. Unfortunately, since that
> requires issueing an IOCTL_INTERNAL_PARALLEL_PORT_ALLOCATE, which is an
> internal (=kernel-mode only) IOCTL (IRP_MJ_INTERNAL_DEVICE_CONTROL),
> this is only possible from a device driver in Windows.
Can this code be added to e.g. the userport.sys driver? Would make things a
lot easier for the user if there was only one extra program to work with, to
open both the I/O area and lock the LPT port for exclusive use by SC. (Each
time SC calls the userport driver, the LPT port is also locked).
Spiro Trikaliotis
Nicolas Welte <welte...@freenet.de> schrieb:
> Spiro Trikaliotis wrote:
> Can this code be added to e.g. the userport.sys driver? Would make things a
> lot easier for the user if there was only one extra program to work with, to
> open both the I/O area and lock the LPT port for exclusive use by SC. (Each
> time SC calls the userport driver, the LPT port is also locked).
yes, this can be added. I just had a quick look into userport.sys (same
applies to directio.sys): Unfortunately, it does not try to enumerate
and use the parallel port drivers, which would be the biggest
"challenge" for this tiny project. It's not that much, but it has to be
done.
As time permits, I'll have a look into this.
Nicolas Welte
> yes, this can be added. I just had a quick look into userport.sys (same
> applies to directio.sys): Unfortunately, it does not try to enumerate
> and use the parallel port drivers, which would be the biggest
> "challenge" for this tiny project. It's not that much, but it has to be
> done.
>
> As time permits, I'll have a look into this.
Great, Spiro! I volunteer for testing :)
Wolfgang Moser
after several weeks of trying different setups, several
Windows XP HALs (hardware abstraction layer) and many
more really sophisticated configuration options, I
discovered two things today:
1. I did use a too old beta version of SC,
version 0.83.08 beta. With this version, the
diskcopy support seems to be broken under certain
circumstances
2. I played with the BIOS LPT port configurations and
found out, that under Windows XP with Userport.SYS,
the EPP setting works much better than the other
extended port settings namely: ECP and ECP+EPP
This was my last setup, changes are noted:
>
> Hardware (basic configuration):
>
> Mainboard: Asus P2B-DS, rev 1.04
> CPU: 1x Pentium III 850 MHz (via Powerleap CPU converter)
> (my system is currently unstable with the
> second CPU inserted)
> RAM: 768 MB PC-133 (3x 256 MB)
>
> LPT-Port: integrated to mainboard, EPP+ECP, 0x378, IRQ 7, DMA 3
now: LPT-Port: integrated to mainboard, EPP, 0x378, IRQ 7
> Additional LPT: SIIG CyberParallel Dual, Dual PCI-LPT port card
> LPT 2: EPP+ECP, 0xA800..0xA803, 0xB000..0xB007, IRQ 17
> LPT 3: EPP+ECP, 0xB400..0xB403, 0xB800..0xB807, IRQ 17
>
>
> Operating System:
> OS: Microsaft Windows XP Professional, SP 1, all available
> hotfixes through Windows-Update
>
> LPT-Configuration:
> LPT 1: I/O: 0x0378..0x037B (basic port address)
> I/O: 0x0778..0x077B (ECP additional addresses)
> IRQ: 07
> DMA: 03
now:
LPT 1: I/O: 0x0378..0x037F (basic port address)
IRQ: 07
> Possibly problematic software installations:
> MBM Motherboard-Monitor 5.3.0
now: MBM5 has been uninstalled due to some oddities with
Userport.SYS
> Sygate Personal Firewall 5.5
> Daemon Tools 3.44, Virutal Daemon Manager
>
> McAfee Antivirus 4.5 (Service normally disabled, when offline)
>
> Hardware access drive:
>
> UserPort.sys (since I already had bad experiences with GiveIO
> under WIndows XP. With Windows NT 4.0 GiveIO
> worked flawlessly for years)
>
> SC configuration:
>
> SC version: 0.83.13 beta
> (yep, the current one is 0.83.14b, I couldn't
> download it, because sta.c64.org seems to be
> down this weekend)
>
> Cable: XAP1541
> Drive: 1541-II with parallel cable connection
>
> Transfer mode: Warp, parallel
> Drive Exec mode: Warp
> Manual Timeout: Disabled
Within the following step-by-step configuration guide, I'll tell
you some more words about my SC configuration.
How to configure The Star Commander, your hardware and operting
system to let it run under Windows XP and access external
Commdore disk drives:
1. Only the UserPort.SYS variant out of the SC_WINNT.ZIP
package from the beta page of The Star Commander site
does work under Windows XP.
Read the included documentation about how to install and
configure that driver correctly.
Don't enable UserPort.SYS before the next reboot, you
should enable (start) it only just before you want to
use The Star Commander and disable (stop) it again, after
you closed SC.
2. Reboot your system and go into the BIOS setup. Configure
your LPT port to "EPP".
Don't set it to "ECP" nor "ECP+EPP". Other options like
BPP, PS/2 _may_ work also, but weren't tested by me.
Also avoid the "SPP" setting or something like "EPP 1.7",
you may lose support for the parallel cable extension and
the latter one would lead into much more trouble (instead
of "EPP 1.9" or simply "EPP").
The reason for choosing "EPP" (only) support instead of
"ECP" or "ECP+EPP" is, that the ECP port contains
additional extended register at higher port addresses
(usually 0x778..0x77B), that cannot be configured into
UserPort.SYS. Therefore The Star Commander is unable to
do some initializations, that are needed _sometimes_
(switching into ECP byte mode).
3. After the next reboot, check out the (new) LPT port
configuration within the device manager of Windows XP.
Please note the exact port addresses in the resources
tab of the LPT port you want to use. For "EPP" it should
be something like: 0x0378 - 0x37F
4. Compare the address with the one configured via the
UserPort.SYS configuration applet, in this case it
should be set to: 0x0378 - 0x037B
(it doesn't matter much, if the range goes up to 0x037F
here or not. SC really does not use the 32 bit
extension registers of the EPP ports).
5. Now start UserPort.SYS with the applet and open a new
DOS prompt.
6. Change into the right directory and start up SC, change
into the configuration and go to the transfer options:
<CTRL>-<F9> , then <F5>
Check for these settings:
Transfer mode: Warp
Serial cable: XA1541 (depends on you type)
Parallel cable: none (only try out parallel
extensions, when the
serial only option does
work correctly)
Async transfer: Auto (perhaps better "Always")
Manual timeouts: No (recommended in the docs)
Detect port modes: No (less NT/2k/XP problems)
Serial interface:
Please configure the start address of the port you
want to use as noted in step 3. You should configure
that address manually by selecting the fourth or
fifth option out of the selection box.
Parallel interface:
Same as above, only needed, when a parallel extension
cable should be used.
The following options should better be disabled:
Extended 1541 disks: Never/Always (but not Auto)
Detect disk changes: No
[The reason is, that these options need additional
drive custom code uploads within the very unreliable
initialisation phase of each drive operation. By
disabling these options you decrease the possibility
for hangups and other wierd behaviours.]
7. Check you settings by pressing: <CTRL>-<ALT>-<BCKSPC>
you should see, that your drive does a reset.
8. When using The Star Commander, please *don't* use:
- single file transfers
- the disk editor (on external disks)
- all other operations except disk copy and
listing the directory
For single files, please operate on images only, but not
on external drives directly. Single file transfers do
need much much more transfer initialization steps and are
vulnerable to timing differencies and hangups in general.
9. After having used SC, you should disable UserPort.SYS
again, don't let it run over the next reboot.
Some more general hints:
* If working as normal user (without administration rights),
you have to start the UserPort.SYS configuration applet
with administration rights (<SHIFT> and right mouse click,
Run As ...). Otherwise you are not allowed to start and/or
stop the UserPort.SYS driver.
* Don't use The Star Commander under Windows XP for more than
one disk transfer per week. For mass import/export sessions,
direct disk operations (disk editor) and such, please reboot
to DOS. You will _never_ get stable and reliable support of
SC under Windows XP, since it's all more a dirty hack than
anything else with these GiveIO and UserPort.SYS helpers.
* If The Star Commander does hang up and this may happen from
time to time, even when using disk copy transfers only, then
your only option is to cancel the whole DOS box.
1. Cancel the DOS box
2. Stop the UserPort.SYS driver
3. Start the UserPort.SYS driver
4. Open a new DOS box
5. Start SC again.
Additional notes:
* Disabling the LPT port via the device manager did definetly
not work with my computer / OS / BIOS. When I did this, SC
was also unable to access the port and I always got
"Device not present" messages
* Importing external (reading) disks is much more reliable
than exporting to (writing) external disks. Be prepared for
a higher hangup probability.
* With my setup, the serial only transfer (XA1541) seemed to
be somewhat more reliable than the parallel extended one
(XAP1541). So be sure to configure the serial only option,
when doing the first steps.
You can view a screenshot of my basic configuration settings at:
http://d81.de/shared/Success-Report-WinXP-SC-EPP.png
(yeah, this is a german version of Windows XP)
I hope, this helps a bit. Are there any questions remaining?
Womo
Jonathan Herr
news:40CCB98E...@d81.de.invalid...
SC version: 0.83.13 beta
(yep, the current one is 0.83.14b, I couldn't
download it, because sta.c64.org seems to be
down this weekend)
1 6 ms 7 ms 7 ms 10.48.224.1
2 7 ms 7 ms 10 ms 10.48.224.1
3 8 ms 6 ms 8 ms srp1-0.ungvwiykvl-rtr1.wi.rr.com
[24.160.224.97]
4 8 ms 9 ms 7 ms srp14-0.milwwirtco-rtr1.wi.rr.com
[24.160.225.1]
5 27 ms 26 ms 26 ms so0-1-0.kscymoL3-rtr1.kc.rr.com
[24.94.160.17]
6 31 ms 32 ms 35 ms so-4-0.hsa1.StLouis1.Level3.net
[63.208.56.5]
7 34 ms 32 ms 31 ms so-6-1-0.mp2.StLouis1.Level3.net
[64.159.4.141]
8 * 22 ms 24 ms so-6-1-0.bbr2.Chicago1.Level3.net
[64.159.0.58]
9 23 ms 24 ms 24 ms so-6-0-0.edge1.Chicago1.Level3.net
[209.244.8.10]
10 26 ms 23 ms 37 ms atm3-0-182-20M.cr1.SJC.gblx.net
[208.50.13.113]
11 23 ms 23 ms 26 ms pos8-0-2488M.cr1.CHI1.gblx.net
[67.17.67.125]
Seems that here is a problematic server link... 23-26ms to 135-138...
Sounds like a slow link (possibly a reroute to get round a bad server...)
12 136 ms 138 ms 135 ms pos9-0-2488M.cr1.CDG2.gblx.net [67.17.92.34]
13 139 ms 135 ms 135 ms so3-0-0-2488M.ar2.CDG2.gblx.net
[67.17.65.114]
14 142 ms 143 ms 143 ms geant-ch1-ch.so-6-0-0.ar2.CDG2.gblx.net
[208.48.23.162]
15 159 ms 160 ms 161 ms ch.at1.at.geant.net [62.40.96.1]
16 168 ms 168 ms 179 ms at.hu1.hu.geant.net [62.40.96.178]
17 168 ms 166 ms 167 ms hungarnet-gw.hu1.hu.geant.net [62.40.103.26]
18 167 ms 167 ms 173 ms c6513-tengbeth5-1.vh.hbone.hu
[195.111.97.242]
19 167 ms 169 ms 167 ms sup720-tengbeth2-1.bme.hbone.hu
[195.111.97.102]
20 169 ms 168 ms 169 ms tge8-1.taz.bme.hu [152.66.0.125]
21 170 ms 168 ms 167 ms vlan11.photon.bme.hu [152.66.0.90]
22 * * * Request timed out.
It timed out after that...
--
Visit my website located at: http://earth.prohosting.com/dsilver/
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.703 / Virus Database: 459 - Release Date: 6/10/04
Tom Lake
> (yep, the current one is 0.83.14b, I couldn't
> download it, because sta.c64.org seems to be
> down this weekend)
Can you send me a copy of 0.83.13 or post it to your Website? I can't get
to the SC Homepage either and I only have 0.82.55 beta which doesn't work
with XP at all.
Tom Lake
hodo
Sorry, but it's still a no go on my system. I followed your
instructions explicitly and still get Drive 9: not present error using
userport.sys.
My system information is:
Intel PIII 800 Celeron, 512 MB SDRAM
MainBoard - Tyan S1854 Trinity 400
Award Bios 4.51
VIA VT82C694X Apollo Pro 133A Chipset
BIOS parallel port mode: EPP
BIOS EPP mode select: EPP1.7 (or EPP1.9) (only 2 choices)
BIOS parallel port address: 0378 IRQ7
Onboard Parallel Port has no printers or devices attached
Device manager LPT port: LPT1 0378 IRQ7
Windows XP Professional Build 2600.xpsp2.03042201633 (Service Pack 1)
AntiVirus uninstalled (I prefer to use on-line virus scans)
Star Commander 8.3.14
Cable XAP1541
1541-II (Drive 9) not wired for XAP1541 parallel
5 1/4" Floppies - read OK when drive connected to SX-64
Transfer mode: Warp
Serial cable: XA1541
Parallel cable: none
Async transfer: Always
Manual timeouts: No
Detect port modes: No
Womo, you mention your BIOS allows you to ignore EPP1.7 and EPP1.9
when in EPP mode. My BIOS automatically activates "EPP mode select"
when EPP is selected as the "parallel port mode". I must choose
either EPP1.7 or EPP1.9.
When comparing your screen dump of SC configuration to mine, I notice
your parallet port setting displays 0378, whereas my setting displays
LPT2 which setup shows as the port at 0378, EPP. Perhap BIOS
differences affect userport's ability to access LPT ports with Windows
XP and that's why I can't get it working on my system.
A screen dump of my SC setup screen is at ftp://sc:s...@69.192.151.174
I have also put a copy of Start Commander 08.3.14 beta at this ftp
site in case anyone needs to download it while sta.c64.org is down.
hodo
Wolfgang Moser
> Sorry, but it's still a no go on my system. I followed your
> instructions explicitly and still get Drive 9: not present error using
> userport.sys.
Although I don't believe, that this could be an issue,
you may want to configure your drive to No. 8.
That is my configuration right here:
One single 1541-II disk drive, configured as drive 8,
connected to the PC LPT port via a XA(P)1541 cable.
No other peripherals are daisy chained behind that
drive.
> My system information is:
>
> Intel PIII 800 Celeron, 512 MB SDRAM
> MainBoard - Tyan S1854 Trinity 400
> Award Bios 4.51
> VIA VT82C694X Apollo Pro 133A Chipset
> BIOS parallel port mode: EPP
> BIOS EPP mode select: EPP1.7 (or EPP1.9) (only 2 choices)
Then please select "EPP 1.9". When I remember right,
I got several problems with EPP 1.7, when I did much
of the LPT port experiments for Joe in 1999 and 2000.
> BIOS parallel port address: 0378 IRQ7
> Onboard Parallel Port has no printers or devices attached
> Device manager LPT port: LPT1 0378 IRQ7
> Windows XP Professional Build 2600.xpsp2.03042201633 (Service Pack 1)
> AntiVirus uninstalled (I prefer to use on-line virus scans)
Me too, but only when I'm online...
> Star Commander 8.3.14
I just got it and remade some tests, successfully.
> Cable XAP1541
> 1541-II (Drive 9) not wired for XAP1541 parallel
> 5 1/4" Floppies - read OK when drive connected to SX-64
> Transfer mode: Warp
> Serial cable: XA1541
> Parallel cable: none
> Async transfer: Always
> Manual timeouts: No
> Detect port modes: No
>
> Womo, you mention your BIOS allows you to ignore EPP1.7 and EPP1.9
No, it doesn't. My BIOS knows only the EPP setting,
which is "EPP 1.9". It cannot be set to EPP 1.7.
But I _know_ of the different standards, since I had
a deep view into LPT ports and LPT port programming
five years ago (see LPT-Detect from one of my web
pages).
> when in EPP mode. My BIOS automatically activates "EPP mode select"
> when EPP is selected as the "parallel port mode". I must choose
> either EPP1.7 or EPP1.9.
As said above, please select EPP 1.9.
> When comparing your screen dump of SC configuration to mine, I notice
> your parallet port setting displays 0378, whereas my setting displays
> LPT2 which setup shows as the port at 0378, EPP. Perhap BIOS
As I said in my setp-by-step description, I recommend to
select the fourth or fifth entry from the selection box.
This one is set to "0000" for the first time, whereas you
have to manually enter the correct port address after.
That way, interpretation errors with the readout of the
BIOS data area can be excluded. Just simply enter exactly
the same start address, that is read out from the device
manager of Windows XP and configured to UserPort.SYS.
> differences affect userport's ability to access LPT ports with Windows
> XP and that's why I can't get it working on my system.
Maybe, I don't know.
> A screen dump of my SC setup screen is at ftp://sc:s...@69.192.151.174
The "Delay value" of 22 says to me, that SC doesn't have
direct access to your LPT port. You should again check,
if the right addresses are configured to UserPort.SYS.
> I have also put a copy of Start Commander 08.3.14 beta at this ftp
> site in case anyone needs to download it while sta.c64.org is down.
Ahem, thanks, but you know, that Joe doesn't allow any
redistribution of his beta packages. You should remove
it as soon as sta.c64.org is up again.
Back to your introductionary sentence:
> ... still get Drive 9: not present error using ...
The "not present" error says, that your drive is not
connected, not switched to on, or under Windows XP, that
SC is unable to access the LPT port directly.
I assume the latter one, because your autodetected delay
value got 22 instead of 2, 3 or 4 normally (for >= 100MHz
systems).
First you need to get to your old state, where you get
the "Timeout" messages or something like "Read Error 18,
00". I could observe the latter one very often with my
experiments.
A very sure indication of a generally working connection
is the "Drive reset" keyboard combination,
<CTRL>-<ALT>-<BKSPC>. If the drive does a reset, SC is
able to access the LPT port directly. After that we have
to look onto timing issues.
Apropos timing issues: You aren't overclocking your
system by increasing the main board clock (PCI clock)?
Anything, that alters the base clock of the sytem timer
(14,31818 MHz) makes it impossible for SC to get a stable
timing. But that's the same for all OSes, SC shouldn't
work under DOS then, too.
When you do some more tests, could you please make some
screen shots of your UserPort.SYS applet as well as
from the device manager LPT configuration.
hodo
<wn...@d81.de.invalid> wrote:
>Hello Hodo,
>
>> Sorry, but it's still a no go on my system. I followed your
>> instructions explicitly and still get Drive 9: not present error using
>> userport.sys.
>
>Although I don't believe, that this could be an issue,
>you may want to configure your drive to No. 8.
>That is my configuration right here:
> One single 1541-II disk drive, configured as drive 8,
> connected to the PC LPT port via a XA(P)1541 cable.
> No other peripherals are daisy chained behind that
> drive.
>
Changing to Drive 8 makes no difference. Now the I get Drive 8: not
present
>> My system information is:
>>
>> Intel PIII 800 Celeron, 512 MB SDRAM
>> MainBoard - Tyan S1854 Trinity 400
>> Award Bios 4.51
>> VIA VT82C694X Apollo Pro 133A Chipset
>> BIOS parallel port mode: EPP
>> BIOS EPP mode select: EPP1.7 (or EPP1.9) (only 2 choices)
>
>Then please select "EPP 1.9". When I remember right,
>I got several problems with EPP 1.7, when I did much
>of the LPT port experiments for Joe in 1999 and 2000.
>
Same results Drive 8: not present with either EPP 1.7 or EPP 1.9
Done, set to EPP 1.9
>
>> When comparing your screen dump of SC configuration to mine, I notice
>> your parallet port setting displays 0378, whereas my setting displays
>> LPT2 which setup shows as the port at 0378, EPP. Perhap BIOS
>
>As I said in my setp-by-step description, I recommend to
>select the fourth or fifth entry from the selection box.
>This one is set to "0000" for the first time, whereas you
>have to manually enter the correct port address after.
>
>That way, interpretation errors with the readout of the
>BIOS data area can be excluded. Just simply enter exactly
>the same start address, that is read out from the device
>manager of Windows XP and configured to UserPort.SYS.
>
This was new to me, excuse me if I missed it. I thought I must select
the port that reflected the correct I/O address of 0378, which in my
case was LPT2 ($0378, EPP). I have now manually set both serial and
parallel to 0378.
>> differences affect userport's ability to access LPT ports with Windows
>> XP and that's why I can't get it working on my system.
>
>Maybe, I don't know.
>
>> A screen dump of my SC setup screen is at ftp://sc:s...@69.192.151.174
>
>The "Delay value" of 22 says to me, that SC doesn't have
>direct access to your LPT port. You should again check,
>if the right addresses are configured to UserPort.SYS.
>
>> I have also put a copy of Start Commander 08.3.14 beta at this ftp
>> site in case anyone needs to download it while sta.c64.org is down.
>
>Ahem, thanks, but you know, that Joe doesn't allow any
>redistribution of his beta packages. You should remove
>it as soon as sta.c64.org is up again.
>
That's why I said I was doing it while Joe's site was down.
>
>Back to your introductionary sentence:
> > ... still get Drive 9: not present error using ...
>
>The "not present" error says, that your drive is not
>connected, not switched to on, or under Windows XP, that
>SC is unable to access the LPT port directly.
>I assume the latter one, because your autodetected delay
>value got 22 instead of 2, 3 or 4 normally (for >= 100MHz
>systems).
>
The delay value of 22 was automatically set after hitting the
recalibrate button. I my previous posts, I indicated I had manually
set the delay time from 1 to 50 seconds, to no avail.
With the serial port manually set to 0378, the recalibrate button now
gives a delay time of 7 seconds.
>First you need to get to your old state, where you get
>the "Timeout" messages or something like "Read Error 18,
>00". I could observe the latter one very often with my
>experiments.
>
With your suggested setup, I don't get timeout messages or Read Error
18,00. I just get Drive 8: not present.
>A very sure indication of a generally working connection
>is the "Drive reset" keyboard combination,
><CTRL>-<ALT>-<BKSPC>. If the drive does a reset, SC is
>able to access the LPT port directly. After that we have
>to look onto timing issues.
Hitting ctrl-alt-bkspc does nothing to the 1541
>
>Apropos timing issues: You aren't overclocking your
> system by increasing the main board clock (PCI clock)?
>Anything, that alters the base clock of the sytem timer
>(14,31818 MHz) makes it impossible for SC to get a stable
>timing. But that's the same for all OSes, SC shouldn't
>work under DOS then, too.
>
I have never overclocked this system. Everything is stock.
>
>When you do some more tests, could you please make some
>screen shots of your UserPort.SYS applet as well as
>from the device manager LPT configuration.
>
A new screen dump is at ftp://sc:s...@69.192.151.174
>
>Womo
If you wish we could use ICQ to try stuff. ICQ# 68-901-467
Hodo
hodo
Womo,
Hold off investigating further for the momement. It seems I commited
the cardinal sin of not making sure the 1541-II was turned on while
using your last set of instructions.
Seems by using setting (4) 0000 and manually changing the serial port
address in SC to 0378 has resulted in seeing the 1541.
I'll report further when I do some consistency and repeatability
tests.
Hodo
hodo
1. With your configuration, Star Commander 8.3.14 is very unstable on
my system. It's next to impossible to consistently get SC.exe or
SCSetup.exe to start up without freezing, with or without userport
started. I was only able to get SC to read the 1541-II once and even
then it locked up shortly afterwards
2. Star Commander 8.2 is stable and reads the 1541-II consistently,
even when userport is started during system start-ups in device
manager. It does not appear to be necessary to only start userport
just before running SC, and then stoping it after finishing with SC to
ensure it doesn't start with a system start.
The problem on my side was the set up of the serial port in SC
configuration. No where in the SC.txt instructions does it say to
manually configure the parallel port serial interface using option 4,
which initially shows address 0000, to the I/O address of BIOS and
device manager. I was always selecting the LPT port which displayed
the I/O address of BIOS and LPT1 in device manager. The LPT port that
SC parallel port serial interface showed with the BIOS address of 0378
was LPT2, even though BIOS and device manager both showed LPT1.
Womo, your instruction below was the solution to my problems.
Serial interface:
Please configure the start address of the port you
want to use as noted in step 3. You should configure
that address manually by selecting the fourth or
fifth option out of the selection box.
I wouldn't be surprised other people will have similar problems as me
trying to get 8.3.14 running with any kind of consistency and
reliability under PIII or higher systems and under XP.
If you or Joe need me to do testing to figure out the probs with
8.3.14, I'll be glad to help. Again my ICQ is 68-901-467.
It was very interesting to find out, earlier on, that XP will not
allow userport to be started in Safe mode. Running in Safe mode
seemed to be the natural way of ensuring the minumum number of
multitasked programs are concurrently running with SC.
I've removed the copy of Star Commander 8.3.14 from my ftp server. It
was only there for you to DL because Joe's site was down.
Hodo
hodo
I've spent the last 6 hours trying to figure out why SC 8.3.14 was so
unstable on my system. The way 8.3.14 was acting was exactly the same
as when I first contacted Joe.
You solved my major problem of not seeing the 1541 floppy by giving
the hint of selecting option 4 and manually entering the parallel port
address of 0378.
I was able to overcome the 8.3.14 stablity problem and virtually all
other problems by adhering to the following steps. Most of these
steps are the same as those you proposed, but I've tweaked others.
1. In BIOS, set parallel port LPT1 to EPP at address 0378 & IRQ7, and
set mode to EPP 1.9
2. Confirm device manager LPT1 Port resources are set to 0378-037F &
IRQ7
3. Open a DOS window and change directory to the folder containing
Star Commander sc.exe
4. At the command prompt delete sc.ini by entering "del sc.ini"
5. At the command prompt access Star Commander by entering "sc.exe
/nolpt"
6. Access SC setup with F9/Options/Configuration/Transfer Options and
make the following settings
Warp Transfer mode
XA1541 Serial Cable
None Parallel cable (XP1541 if wired for it)
Auto Async transfer (can also use "always")
Off Manual timeouts
0 Delay value (to be set again later in this process)
0378 Serial interface (select option 4 0000 and manually enter
0378) - Ignore Setup message that says this port doesn't exist
0378 Parallel interface (select option 4 0000 and manually enter
0378) - Ignore Setup message that says this port doesn't exist
Off Detect port modes
7. Exit the setup utility and save the settings
8. Ensure userport.sys is located in the \Windows\System32 folder
9. Run Userport.exe
10. Add the following addresses on the right half of the Userport
screen, if they are not there
40-43
61-61
378-37F
11. The left half of the userport screen does not need any addresses
12. Hit the Userport Stop button, then hit the update button
13. Exit Userport
14. Shutdown XP (a full shutdown is recommended as restart retains
residual settings)
15. Power up XP from shutdown state
16. Before running Star Commander, run Userport and hit the Start
button
17. If Userport says "driver is already started", hit Stop, Exit
Userport, restart Userport and press Start again.
18. In Userport, hit Exit.
19. Run Star Commander sc.exe
20. Access the 1541 floppy by selecting the Drive number (make sure
the 1541 is powered up)
21. If a timeout error occurs reading the 1541, access SC setup with
F9/Options/Configuration/Transfer Options and hit the recalibrate
button
22. Exit SC setup and save the settings
23. Access the 1541 floppy by selecting the Drive Number
24. For subsequent Star Commander sessions, repeat steps 16-23.
25. If 24 doesn't work, repeat steps 1-23.
These steps are the ones that work for me. Hopefully they'll work for
most XP systems.
Hodo
Wolfgang Moser
hodo wrote:
> 1. With your configuration, Star Commander 8.3.14 is very unstable on
> my system. It's next to impossible to consistently get SC.exe or
> SCSetup.exe to start up without freezing, with or without userport
> started. I was only able to get SC to read the 1541-II once and even
> then it locked up shortly afterwards
As I said more than once, this whole SC_WINNT.ZIP is
nothing more than a big hack. None here around should
wonder about reliability problems when using SC under
NT/2k/XP.
> 2. Star Commander 8.2 is stable and reads the 1541-II consistently,
> even when userport is started during system start-ups in device
> manager. It does not appear to be necessary to only start userport
Aha, so I'll have to do some additional tests again?
> The problem on my side was the set up of the serial port in SC
> configuration. No where in the SC.txt instructions does it say to
> manually configure the parallel port serial interface using option 4,
> which initially shows address 0000, to the I/O address of BIOS and
When I saw your screen dump with the three LPT settings
"autodetected" port addresses, my first thought was:
'BIOS data area data read out corruption'
So it's generally a good idea to overcome any PnP issues
in wierd environments. Thanks to Joe, that he once added
the possibility to set up the port addresses manually.
> device manager. I was always selecting the LPT port which displayed
> the I/O address of BIOS and LPT1 in device manager. The LPT port that
> SC parallel port serial interface showed with the BIOS address of 0378
> was LPT2, even though BIOS and device manager both showed LPT1.
One more question:
Your screen dump show the SC transfer settings setup
screen with three LPT ports at the addresses 0x3BC,
0x378 and 0x278. I assume, that the first and third
parallel port are from your Lava PCI Parallel Port
card.
How were you able to configure your card onto these
low port addresses?
With my SIIG dual PCI LPT port card the port
addresses are automatically set up to the addresses
0xA400 and 0xB000, much too high for UserPort.SYS.
Under NT 4.0 there was a simple configuration applet
for the driver, which is missing in Windows XP.
It seems, that I should buy a Lava card and test it.
> If you or Joe need me to do testing to figure out the probs with
> 8.3.14, I'll be glad to help. Again my ICQ is 68-901-467.
ICQ is definetly no option for me, because of missing
time. And for me, it's much more effective to analyse a
user's report, doing some own tests, developing a
problem hypothesis that leads to a detailed test
procedure. That may rise another view of the very same
problem and mostly helps to find a solution.
Now that you got a running configuration, you should
probably do some sort of a backup.
After that you may want to do some more experiments with
your addon PCI LPT port card again. I'll do the same,
when I see a way to overcome the high port address issue
of my SIIG card.
hodo
wrote:
>One more question:
> Your screen dump show the SC transfer settings setup
> screen with three LPT ports at the addresses 0x3BC,
> 0x378 and 0x278. I assume, that the first and third
> parallel port are from your Lava PCI Parallel Port
> card.
> How were you able to configure your card onto these
> low port addresses?
> With my SIIG dual PCI LPT port card the port
> addresses are automatically set up to the addresses
> 0xA400 and 0xB000, much too high for UserPort.SYS.
> Under NT 4.0 there was a simple configuration applet
> for the driver, which is missing in Windows XP.
> It seems, that I should buy a Lava card and test it.
Womo,
I presume you have seen my other post where I got XP working with SC
82.14 and outlined steps I must take to ensure SC starts up without
Device not present or timeout errosrs.
Those 3 LPT ports, LPT1 at 3BC, LPT2 at 378, & 278 at LPT3 are brought
into view by SC setup. I don't have any accessory LPT ports cards
installed. I only have the single on-board LPT1 port.
During the early stages of my efforts to get SC running, I purchased a
Lava PCI parallel card to see if that would work. It didn't work
since the Lava port is not picked up by BIOS and since it works with
I/O addresses above 0770. Userport won't accept I/O addresses in the
high range. I called Lava to see if there was anything that could be
done and the answer was no. I got a refund on the card.
Hodo
Joe Forster/STA
On a short note, I _am_ reading this thread... I'm gonna add the infos
you provided into the tweak package docs and send it to both of you for
review. Later, the new docs will be published in a new release of the
tweak package.
In the meantime, Spiro is hacking the UserPort driver so that it can be
kept open, thus exclusive port usage established, during parallel port
access. I just finished the additional code in SC 0.83.15 alpha so that
Spiro can test his hack.
Joe
--
KOVÁCS Balázs alias Joe Forster/STA s...@c64.org; http://sta.c64.org
Orsolya u. 5. IV/12., 1204 Budapest, Hungary; +36-1-285-3881, 6-10PM CET
(SpamAssassin protection! No HTML E-mails! No uncompressed attachments!)
Wolfgang Moser
> On a short note, I _am_ reading this thread... I'm gonna add the infos
I hoped so, therefore I did the time to investigate this problem
more deeply and did the setp-by-step guide. It was my intention
to do half the work of writing a dedicated Windows XP guide for
the SC_WINNT.ZIP package.
> you provided into the tweak package docs and send it to both of you for
> review. Later, the new docs will be published in a new release of the
> tweak package.
Hmmmm, I don't know, if the tips and hints from Nicolas, Hodo,
others and me may be useful to other Windows XP users. I expect
much more problem reports since the whole package (SC, XP and
Userport.SYS) is anything but a rock solid solution.
> In the meantime, Spiro is hacking the UserPort driver so that it can be
> kept open, thus exclusive port usage established, during parallel port
> access. I just finished the additional code in SC 0.83.15 alpha so that
> Spiro can test his hack.
Cool, and it seems, that the original writer of Userport.SYS
is also extending the 'driver' a little bit. Hopefully I can
use my SIIG card then (high port addresses). But this would
solve _all_ problems since with one of the ports, the ECP
extended register is 0x800 bytes away from the main port
register. But that's completely another story.
joh...@web.fr
problems with sc and win xp - and still have.
my problem is that every time i start userport.exe and press start it
says "already running", i then click stop, exit userport.exe, restart
it and when i then hit start again my system just gets rebooted every
time. when i first installed userport i entered sc, and got time outs
of 16, 17 and then 4. i saved it and by selecting drive 9 (in my case)
the green light lit but the drive never stopped spinning. timeouts of
16 and 17 just gave me a blinking green led. as stated before now when
i boot up my xp, do the userport-stuff the computer gets suddenly
rebooted, restarts with checking the drive sc is on for errors. there
is something wrong when i fiddle around with userport.exe.
last i wanna say that i have the xE-cable (i included that instead of
the xa from hodos tweak-list).
any help?
On Tue, 15 Jun 2004 22:01:54 +0200, Wolfgang Moser <pw...@d81.de>
wrote:
>Hello Hodo,
hodo
>People, I was lurking here for quite some time as i also have the same
>problems with sc and win xp - and still have.
>
>my problem is that every time i start userport.exe and press start it
>says "already running", i then click stop, exit userport.exe, restart
>it and when i then hit start again my system just gets rebooted every
>time. when i first installed userport i entered sc, and got time outs
>of 16, 17 and then 4. i saved it and by selecting drive 9 (in my case)
>the green light lit but the drive never stopped spinning. timeouts of
>16 and 17 just gave me a blinking green led. as stated before now when
>i boot up my xp, do the userport-stuff the computer gets suddenly
>rebooted, restarts with checking the drive sc is on for errors. there
>is something wrong when i fiddle around with userport.exe.
>
>last i wanna say that i have the xE-cable (i included that instead of
>the xa from hodos tweak-list).
>any help?
johndoe,
If you didn't see my other post, you might want to try steps 1-23.
Let us know if it works or not.
joh...@web.fr
yes, tried steps 1-23 (i mentioned that i have the xe-cable and choose
that in Star Commander, all other tweaks are exactly the same).
funny thing is, Star Commander stopped working on my last computer
from one day to another (other beta of SC?) and i haven`t been able to
get it to work on my new one.
Wolfgang Moser
joh...@web.fr wrote:
> yes, tried steps 1-23 (i mentioned that i have the xe-cable and choose
> that in Star Commander, all other tweaks are exactly the same).
>
> funny thing is, Star Commander stopped working on my last computer
> from one day to another (other beta of SC?) and i haven`t been able to
> get it to work on my new one.
So for the first, please check out the latest release version,
Star Commander 0.82.
Did you check out, if Star Commander runs under plain DOS on
your machine (via a DOS bootdisk)? This is the most important
step to ensure, that your (mainboard) hardware (configuration)
is not the problem.
And maybe some screenshots may be helpful, it/they should show
1. your LPT port configuration (resource tab) from the
device manager
2. the UserPort.SYS applet with the preconfigured addresses
3. the Star Commander transfer options configuration menu,
which shows some values autodetected by SC (delay value,
number of LPT ports detected, LPT port start addresses)
What about the <CTRL>-<ALT>-<BCKSP> check? Did you follow
Nicolas' recommendation to test, if the drive can be reset
after each configuration step? You really shouldn't try to
make any transfers even not listing the directory until the
manual reset with <CTRL>-<ALT>-<BCKSP> does work.
joh...@web.fr
my main problem is the giveio.exe/sys as i described in a previous
posting - at the moment i can`t experiment with SC because the giveio
reboots my computer every time i try to update and start it.
will make a dos-disk now and try the functionality there.
keep you posted.
grüße
Spiro Trikaliotis
Wolfgang Moser wrote:
>> In the meantime, Spiro is hacking the UserPort driver so that it can
>> be kept open, thus exclusive port usage established, during parallel
>> port access. I just finished the additional code in SC 0.83.15 alpha
>> so that Spiro can test his hack.
>
> Cool, and it seems, that the original writer of Userport.SYS is also
> extending the 'driver' a little bit. Hopefully I can use my SIIG card
> then (high port addresses). But this would solve _all_ problems since
> with one of the ports, the ECP extended register is 0x800 bytes away
> from the main port register. But that's completely another story.
Well, currently, it's mostly Tomas Franzon, the userport.sys author, not
me who does most of the work. I only added a very small fraction, which
does not seem to be as effective as I hoped it would be. Anyway, I still
find it a good idea to allocate the parallel port while SC is working.
Furthermore, Tomas Franzon and I, We are in contact and speaking about
some issues.
I'll keep you informed about progress. :-)
Anyway, as Wolfgang stated, this whole
userport.sys/DirectIO.sys/GiveIO.sys it's just a hack, and a really big
mess.
Wolfgang Moser
joh...@web.fr wrote:
> my main problem is the giveio.exe/sys as i described in a previous
> posting - at the moment i can`t experiment with SC because the giveio
> reboots my computer every time i try to update and start it.
what? why? Several posting authors of this thread including me
mentioned, that there is / might be some problem with GiveIO
and Windows XP. Therefore only the UserPort.SYS driver can be
used.
In your other posting you said, that you were using UserPort.EXE.
You don't try to start/stop the GiveIO.SYS driver with the
UserPort.EXE applet, do you?
You shouldn't install both driver packages at the same time,
this could indeed result in a crashed system. You will
hopefully be able to start into Safe Mode, so that you can
uninstall at least one (GiveIO) or both of the drivers to
get a running system again.
You should go on with only installing/testing the UserPort.SYS
driver along with accompaying UserPort.EXE applet for the
driver configuration.
> will make a dos-disk now and try the functionality there.
And yes, before testing SC under Windows XP, please be sure
that it definetly does work under DOS with your current
hardware configuration (LPT port BIOS config, cable settings
and so on).
joh...@web.fr
;) - i don`t have giveio installed.
will attach a floppy drive tomorrow as i dont have one in my config
now.
thanks for your time - i keep you posted.
Spiro Trikaliotis
joh...@web.fr <joh...@web.fr> schrieb:
> my problem is that every time i start userport.exe and press start it
> says "already running", i then click stop, exit userport.exe, restart
> it and when i then hit start again my system just gets rebooted every
> time.
This is very interesting. Are you sure it is immediately restarting, and
there is no blue screen in between?
If this is reproducible, and there is a blue screen in between (what
does System settings/System/Start and stop tell you? Should the machine
reboot immediately, or is this disabled?), then I would like to have a
memory dump from you. If possible, a full dump would be good, but a
"kernel memory dump" should be enough in most cases.
If you have a possibility to generate it and put it online on a web
page, please do this and send me the URL in a PM.
DO NOT SEND IT AS ATTACHMENT, PLEASE!
joh...@web.fr
yes, immediate reboot is DISABLED but it doesnt matter much to my
machine. there is NO blue screen. this is the log entry i get
"Der Computer ist nach einem schwerwiegenden Fehler neu gestartet. Der
Fehlercode war: 0x0000000a (0x0000437a, 0x000000ff, 0x00000000,
0x8053482f). Ein volles Abbild wurde gespeichert in:
C:\WINDOWS\Minidump\Mini061704-01.dmp."
I have more time on the weekend - then i will reproduce it and will
pass you the url of the minidump.
thanks
On 17 Jun 2004 20:03:13 GMT, Spiro Trikaliotis
Spiro Trikaliotis
posted & mailed, as I don't know if this mail box is spam protected. I
think the rest should go via PM.
joh...@web.fr <joh...@web.fr> wrote:
> yes, immediate reboot is DISABLED but it doesnt matter much to my
> machine. there is NO blue screen.
This is very bad news, it seems you're getting a triple fault or
anything similar.
> this is the log entry i get
>
> "Der Computer ist nach einem schwerwiegenden Fehler neu gestartet. Der
> Fehlercode war: 0x0000000a (0x0000437a, 0x000000ff, 0x00000000,
> 0x8053482f). Ein volles Abbild wurde gespeichert in:
> C:\WINDOWS\Minidump\Mini061704-01.dmp."
You're using a german version of Win? Well, so I believe you are a
native german speaker, aren't you? Then we can proceed in german.
> I have more time on the weekend - then i will reproduce it and will
> pass you the url of the minidump.
Good. A minidump is not the best possible solution, but it might help
anyway.
TraunStaa
i changed my nick from the fake email address ;)
i installed the floppy today - sc starts under dos and reads the
directory from the disks but then freezes. i also tried the "normal"
and "turbo" modes but to no effect. i fiddled around in scsetup quite
some time but i cant even get sc working under dos.
greets, traunstaa
On 18 Jun 2004 09:00:00 GMT, Spiro Trikaliotis
TraunStaa
SC is running smooth now under DOS - I transfered already at about
22 disk sides.
On 18 Jun 2004 09:00:00 GMT, Spiro Trikaliotis
Wolfgang Moser
> UPDATE:
> SC is running smooth now under DOS - I transfered
> already at about 22 disk sides.
So what do you want to do now? Are you satisfied with the
current solution by transferring your CBM content under
plain DOS? I can only recommend that since it is the most
reliable environment (DOS) best suited for longer sessions
with The Star Commander.
If you want to get SC running under Windows XP nevertheless,
well I'm waiting for informations about your configuration:
1 Mainboard type, chipset manufacturer and number, CPU and
CPU speed setting, number of CPUs installed in the
mainboard, overclocking settings, additional LPT port cards,
X-cable type, BIOS configuration of the LPT port cards
(current type as well as all alternative settings, IRQ, DMA)
2 Current SC configuration of the one, that does work under
plain DOS, most important are all the settings from the
"Transfer options" and the "Drive options" menu.
- In the "transfer options" menu, hit <Space> on the
"Serial interface" port address selection box and write
down all the information, that is given by SC (mainly
the autodetected values and port types)
3 Windows XP configuration of the LPT ports. Check out the
device manager and look for the parallel printer port
section. For each installed (or detected) parallel port
(LPT port), note the common properties of that port and
especially tell me the resources that are configured to
that port.
4 Try to reinstall the UserPort.SYS driver and applet and
configure it according to the Readme in SC_WINNT.ZIP.
Please tell me your configuration after.
Try to start UserPort.SYS .
5 Try to start the Star Commander, but DON'T select any
external drive yet. Repeat the second topic for this SC
instance (running under NT now) and again especially tell
me the autodetected values of the "serial interface" port
address selection box.
6 Please additionally read:
http://sta.c64.org/scdoc.html#section11
and send me informations about the items asked there
(if not already mentioned above).
Maybe you want to make a batch of screenshots instead of
writing all these informations down. Please find a web
storage location of your choice, don't post these picture
into this group, which is text-only.
TraunStaa
the DOS-only solution works fine for me. if you want to find the
problem on my xp configuration i`ll be happy to provide you with the
needed information.
Wolfgang Moser
> the DOS-only solution works fine for me. if you want to find the
Good, that's the most important thing.
> problem on my xp configuration i`ll be happy to provide you with the
> needed information.
Hmmmm, I don't want to confuse anyone here now. I'll always
try to help out people with their configuration, if they
_desperately_need_ to use The Star Commander under Windows
XP and I'm working with some other people on (slightly)
better solutions in the background.
But no, it doesn't make me happy to solve other people's
problem. Well, there's always some positive feeling, if
I was able to help out. But there's mostly no fun with
doing all the work before (interpreting the messages from
the person requesting help, analysing and creating an
error hypothesis, giving advices to do next and so on).
If you accidently collect all the informations I request
and post them here, I'll have a look. Maybe I see a problem
and could help you getting a running SC+XP plattform, which
is nice to have for transferring a disk in between.
TraunStaa
the boring part when using SC under DOS is that there is nothing else
to do while waiting for the disks to be transfered. heck, for what do
we have a multitasking operating system ;)
i will collect the needed information and come back to you.
traunstaa
Ruud Baltissen
> heck, for what do we have a multitasking operating system ;)
Heck, for what do we have more then one computer? :)
(I also use to read a good book during multiple transfers)
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: Ruud.C64.org
Rikidozan
cleaned up the room a bit ;)
On 24 Jun 2004 02:53:52 -0700, Ruud.Ba...@abp.nl (Ruud Baltissen)
wrote: