cbm4linux-users — Any cbm4linux related discussions

[cbm4linux-users] libopencbm-xa1541.so missing

[Bernhard S. <c6...@be...>]

Hi all,

I hope this is the right place to ask: I'm trying to install openCBM (or
cbm4linux doesn't matter to me if it works). I've got an XM1541-cable, my
computer is a TravelMate 291LCI running Debian Buster (could update to
Bullseye, if that helps, though). I downloaded three deb-files from Suse
and installed them:

libopencbm[...].deb
opencbm[...].deb
opencbm-xa1541[...].deb

That worked fine. When I now type 

cbmctrl reset

I get

/usr/lib/opencbm/plugin/libopencbm-xa1541.so: cannot open shared object file:
No such file or directory
An error occured opening OpenCBM, aborting...

As I couldn't find anything about this shared object file in the internet, I
tried various other approaches. E.g. doing

dpkg-reconfigure opencbm-xa1541

told me to install the source files and compile them, but that didn't work
well. I tried several ways to compile the source, but every time I ended with
a bunch of errors I could not make up anything from. (If it helps, I can send
you the tries, but I wanted to keep this mail small.)

Now I've got no real idea, how to proceed. Can you help me?

Berni

Re: [Cbm4linux-users] [cbm4linux-users] cbm4linux and JiffyDOS: Anyone having success

[Count Z. <co...@c6...>]

> Hello,
>
> I just got a report that cbm4linux does not work on a drive with
> JiffyDOS. If the poster switches back to the original ROM, it works.
>
> Can anyone confirm (or not confirm) this behaviour on his setup? This
> might help me in tracking down the problem.
>
> Thank you in advance,
>    Spiro.

For me it seems to work equally bad on any ROM.
SuperJD, JD or normal rom sometimes gets sort of outta sync, reads a few 
tracks bad, then continues normally ... will re-test for details today (i 
hope to make it :) )

l8r

-- 
Count Zero/SCS*TRC/CyberpunX
http://rr.c64.org

[cbm4linux-users] cbm4linux and JiffyDOS: Anyone having success

[Spiro T. <tri...@gm...>]

Hello,

I just got a report that cbm4linux does not work on a drive with
JiffyDOS. If the poster switches back to the original ROM, it works.

Can anyone confirm (or not confirm) this behaviour on his setup? This
might help me in tracking down the problem.

Thank you in advance,
   Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/

[cbm4linux-users] New release of cbm4linux/cbm4win: opencbm 0.4.0

[Spiro T. <tri...@gm...>]

Hello,

I just released a new version of cbm4linux and cbm4win (together called
"opencbm"). Get a ChangeLog and the release on

   http://cbm4win.sf.net/

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/

[cbm4linux-users] Seeking testers: Release candidate for upcoming cbm4linux 0.4.0

[Spiro T. <tri...@gm...>]

Hello list,

in a joined effort, cbm4win and cbm4linux will have a 0.4.0 release
shortly. The release is planned around next week.

We need some testers, especially for the cbm4linux part to make this
release a success.

What is new?

- cbm4linux and cbm4win compile from the same sources; thus, all bugs
  found while developing cbm4win are fixed.
- Support for mnib (http://www.rittwage.com/c64pp/dp.php?pg=mnib), if an
  XP1541 cable is available;
- shortened "reset" time: Instead of waiting 5 seconds (which is needed
  for a 1581 drive), only wait until the floppy signals that it is
  ready. With a 1541 or 1571, the reset time will be much less than 1
  second.
- cbmcopy and d64copy: fixed many potential "hangups" due to protocol
  races;
- cbmcopy and d64copy: unless specified otherwise, use best protocol
  (-tp, -ts2, -ts1, -w) by checking the cable and what is connected;
- cbmcopy and d64copy: If a floppy with "Rex-DOS" was used, the transfer
  worked as expected. Anyway, after the transfer, the drive behave
  erroneously. Other speeders might be affected, too. Fixed.
  (cf.
  http://sourceforge.net/tracker/index.php?func=detail&aid=1218165&group_id=122047&atid=692219)
- d64copy: If aborted with Ctrl+C, the error information block was not
  written to the disc image. Fixed.
- cbmformat, d64copy, cbmcopy crashed if they are called with unknown
  parameters. Fixed.
- cbmformat (and new cbmforng, "cbmformat next generation") format a
  1541 disc in a way that is better usable across different floppy
  drives with differing rotation speed of the motor (for details, cf.
  http://sourceforge.net/tracker/index.php?func=detail&aid=1066199&group_id=122047&atid=692219).
  For this, both use a probing formatter (which is not much slower than
  the old cbmformat).
- "cbmctrl detect" let a char in the error channel of the drive. Fixed.
- "cbmctrl change": New command, find out when a floppy disc (which must
  already reside inside of a 1541 or 1571 drive; 1581 is NOT SUPPORTED!)
  is removed and replaced by a new one. Very helpful for scripting mass
  archivals.
- "cbmctrl pcommand", "cbmctrl popen": New commands, like "cbmctrl
  command" and "cbmctrl open"; convert the parameters from ASCII to
  PETSCII before sending them to the floppy (unlike the old commands).
- "cbmctrl read", "cbmctrl write": New commands for a compatible way
  (between Linux and Windows) to read from a CBM floppy (cat /dev/cbm)
  or write to it (cat ... > /dev/cbm).
- many more small and bigger error corrections and additions.


The new version can be found at 

  http://www.trikaliotis.net/cbm4win_0_1_0_86

Don't get surprised from the name; although it states "cbm4win", the
release is for both Linux and Windows. Everything on this page is still
some "Windows-like", but this will be changed until the release.

The download itself can be found at

  http://www.trikaliotis.net/cbm4win_0_1_0_86#download

The instructions to install are "almost" identical to the current
cbm4linux 0.3.2 (http://www.lb.shuttle.de/puffin/cbm4linux/,
as given in the README), only some small changes apply:

ALL make commands MUST incldue a "-f LINUX/Makefile" option; i.e.,

  make -f LINUX/Makefile
  make -f LINUX/Makefile dev
  make -f LINUX/Makefile install

A more complete (but not complete ;)) "ChangeLog" is available at

  http://www.trikaliotis.net/cbm4win_0_1_0_86#v0_1_0_86

Don't get fooled by the version number; cbm4linux 0.3.2 is even older
than cbm4win 0.1.0.


A problem you might encounter which is not yet documented is the
following:

After installing, the shared library "opencbm.so" will not be found on
all systems. cbm4linux installs it in /usr/local/lib/, but not all
systems search there. (Why? Is this a recent change in Linux? cbm4linux
0.3.2 already put it there, and I never encountered problems back then).

You can fix it either by changing LIBDIR in LINUX/config.make to let it
point to a path which will be searched, or include /usr/local/lib in
/etc/ld.so.conf execute "ldconfig" as root.

I am thankfull for ANY feedback, positive or negative, success stories
or failure. This is true especially since I have more Windows testers
than Linux testers.

Of course, the documentation will be changed until the release.

Happy testing!

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis                              http://cbm4win.sf.net/
http://www.trikaliotis.net/                     http://www.viceteam.org/

[cbm4linux-users] Problem re-compiling for Fedora Core 3

[BlackBeltJones <so...@op...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
<font size="-1">G'day folks,<br>
<br>
I've been using cbm4linux for some time now, compiling it with the
awesome guide by agemixer. As any other fc3 users would know, with
every new kernel that comes out, cbm4linux has to be recompiled,
dammit, anyways, after the latest kernel release (2.6.12-1.1372_FC3) i
am unable to recompile. Heres a dump of the screen when i try to
initiate the "make" command:<br>
<br>
$ make<br>
make[1]: Entering directory
`/home/blackbeltjones/packages/cbm4linux/cbm4linux-0.3.2/kernel'<br>
make -C /lib/modules/`uname -r`/build&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; here=`pwd`
CBM4LINUX_KERNEL_FLAGS= SUBDIRS=`pwd` modules<br>
make: *** /lib/modules/2.6.12-1.1372_FC3/build: No such file or
directory.&nbsp; Stop.<br>
make: Entering an unknown directorymake: Leaving an unknown
directorymake[1]: *** [cbm.o] Error 2<br>
make[1]: Leaving directory
`/home/blackbeltjones/packages/cbm4linux/cbm4linux-0.3.2/kernel'<br>
make: *** [all] Error 1<br>
<br>
Can anybody offer me the magical solution to this hurdle? Theres a few
new c64 demos out there and I just HAVE to see them :-) I refuse to use
emulators (only the real thing for me, lol) so I must get this working,<br>
<br>
help! Joe.<br>
</font>
<br>
</body>
</html>

Re: [cbm4linux-users] Problems with cbm4linux

[Spiro T. <tri...@gm...>]

Hello Thomas,

* On Mon, Jul 18, 2005 at 10:34:42PM +0000 Thomas Jespersen wrote:

> Allright, I can format now with
> 
>  cbmctrl command 8 N0:TESTFORMAT,01

Good, this means the driver and the protocol work.

> but d64copy gives me this:
> 
> [root@localhost ~]# d64copy 1\ Hour\ \(1987\)\(Triad\).d64 8

You do not give any "-t" parameter? This way, the system uses 
the IEC bus protocol, which is *very* slow. I would suggest using -ts1
or -ts2.

> [Fatal] could not identify devicea
> [Warning] Unknown drive, assuming 1541

What is the output of "cbmctrl detect"?

What kind of drive do you use? Do you have any special ROM inside of
what? What is the output of "cbmctrl reset; cbmctrl status 8"?

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/

Sv:Sv:Re: Sv:Re: [cbm4linux-users] Problems with cbm4linux

[Thomas J. <fro...@ju...>]

Allright, I can format now with

 cbmctrl command 8 N0:TESTFORMAT,01 

but d64copy gives me this:

[root@localhost ~]# d64copy 1\ Hour\ \(1987\)\(Triad\).d64 8
[Fatal] could not identify device
[Warning] Unknown drive, assuming 1541
[Warning] write error: 01/00: 1
 1: ?--------------------     0%     1/683[Warning] write error: 01/11: 1
 1: ?----------------?---     0%     2/683[Warning] write error: 01/0d: 1
 1: ?------------?---?---     0%     3/683[Warning] write error: 01/09: 1
 1: ?--------?---?---?---     0%     4/683[Warning] write error: 01/05: 1
 1: ?----?---?---?---?---     0%     5/683[Warning] write error: 01/01: 1
 1: ??---?---?---?---?---     0%     6/683[Warning] write error: 01/12: 1
 .........
 .........
etc.etc.

Sv:Re: Sv:Re: [cbm4linux-users] Problems with cbm4linux

[Thomas J. <fro...@ju...>]

> But there should be a /etc/udev directory. Tell me the contents of your 
> directory and I might suggest a place to add it.

[thomas@localhost Download]$ ll /etc/udev/
total 40
drwxr-xr-x  2 root root 4096 May 21 05:39 devices
drwxr-xr-x  2 root root 4096 Jul 18 21:36 makedev.d
drwxr-xr-x  2 root root 4096 Jul 18 21:44 rules.d
drwxr-xr-x  2 root root 4096 Jul 18 21:36 scripts
-rw-r--r--  1 root root  384 May 21 05:39 udev.conf

Additionally the scripts folder has the script "udevpermconv.sh" with this description:
# convert old udev permissions.d file to the new rules.d format.
# revision 2

Re: Sv:Re: [cbm4linux-users] Problems with cbm4linux

[Dirk J. <do...@cu...>]

> I think I found out what my problem was, but I have not figured a solution. According to the Fedora Core 3 document:
> http://www.lb.shuttle.de/puffin/cbm4linux/cbm4linux-for-FC3.txt
> 
> I should edit /etc/udev/permissions.d/50-udev.permissions
> 
> But there is no permissions.d directory in Fedora Core 4. I assumed I could just create the directory, but I guess I might be wrong. Does anybody know how to set these permissions in Fedora Core 4?

But there should be a /etc/udev directory. Tell me the contents of your 
directory and I might suggest a place to add it.

-- 
---> doj / cubic
----> http://cubic.org/~doj
-----> http://llg.cubic.org

Sv:Re: [cbm4linux-users] Problems with cbm4linux

[Thomas J. <fro...@ju...>]

> Seems you don't have write permissions. As the stock cbm4linux code 
> contains two different methods for accessing the parallel port we first 
> have to find out which method you currently use. Please tell us the 
> output of "uname -a" on your machine.
>

I think I found out what my problem was, but I have not figured a solution. According to the Fedora Core 3 document:
http://www.lb.shuttle.de/puffin/cbm4linux/cbm4linux-for-FC3.txt

I should edit /etc/udev/permissions.d/50-udev.permissions

But there is no permissions.d directory in Fedora Core 4. I assumed I could just create the directory, but I guess I might be wrong. Does anybody know how to set these permissions in Fedora Core 4?

Re: [cbm4linux-users] Problems with cbm4linux

[Dirk J. <do...@cu...>]

Hello Spiro,

> 1. The compilation bug for 2.6 (1238239): Does this mean that
>    parport_find_number(lp) replaces the loop from before? Doesn't the
>    new loop work at all, or is this just a shortcut?

Linux 2.6 does not have the parport_enumerate() function. It was 
replaced by parport_find_number() which saves you from coding such a 
bogus loop.

>    BTW: Why did you rearrange the for() loop into a while() loop? (just
>    out of curiosity, not that it matters)

Just personal taste. I don't like for() loops with an empty body.

> 2. The reset patch: Your description tells us that < 0 is a "smart
>    reset", while "== 0" performs no reset at all. Anyway, I cannot find
>    a difference between these two. Is this "smart reset" what Joe
>    proposed, thus, something to be added in the future, or what is this
>    for?

I just copied the description from the comments next to the "int reset" 
definition. I haven't checked if the comments make any sense.

>    Anyway, I see you insist on your "no reset" default. Wouldn't it be
>    better to use a "safe" setting, thus, perform a reset, and let it be
>    disabled by knowledgeable people only?

You got that wrong. I changed the semantics of the reset variable from 
beeing a boolean to the actual number of seconds that should be spent 
waiting after reset. My patch does not alter the default of a 5 second 
wait, but now this time is configurable via the reset variable.

-- 
---> doj / cubic
----> http://cubic.org/~doj
-----> http://llg.cubic.org

Re: [cbm4linux-users] Problems with cbm4linux

[Spiro T. <tri...@gm...>]

Hello Dirk,

* On Thu, Jul 14, 2005 at 04:33:36PM +0200 Dirk Jagdmann wrote:

> >One could come to the conclusion that these always changing APIs do
> >no good. It is the Linux' way to force people keeping up.
> 
> You'd better ask this on LKML and be prepared for tons of flames :-)

Yes, I know. I have had this discussion more than once. Nevertheless,
this is something I almost hate about Linux.

 
> You're right at this point. I've now reworked all my changes and came up 
> with 6 patches, which should do only one thing at a time, although some 
> of them patch in the same areas and are therefore slightly dependand on 
> each other.
> I have updated the patches on
> http://sourceforge.net/tracker/?group_id=45917&atid=444478

Ok, it is obvious that they have to depend upon each other.
Nevertheless, with these patches, it is easier to patch by hand if one
wants only one patch and it fails.

I had a look at your patches:

1. The compilation bug for 2.6 (1238239): Does this mean that
   parport_find_number(lp) replaces the loop from before? Doesn't the
   new loop work at all, or is this just a shortcut?
   BTW: Why did you rearrange the for() loop into a while() loop? (just
   out of curiosity, not that it matters)

2. The reset patch: Your description tells us that < 0 is a "smart
   reset", while "== 0" performs no reset at all. Anyway, I cannot find
   a difference between these two. Is this "smart reset" what Joe
   proposed, thus, something to be added in the future, or what is this
   for?
   Anyway, I see you insist on your "no reset" default. Wouldn't it be
   better to use a "safe" setting, thus, perform a reset, and let it be
   disabled by knowledgeable people only?

3. I like the kernel source directory patch (1189489), although I have
   not tested it yet (but what should go wrong with this?).

Please, don't understand me wrong: I do not have anything against people
providing patches, especially if it is not even my own code but
Michael's. ;) Au contraire, I'm very happy other people look into it. I
only want to tell you what my point of view is - and I am hoping to
convince you. It seems it worked, at least partially.


> >As Michael has no means to test the Windows code, this
> >"cross-testing" is mostly my task. As I do own some Linux machines, I
> >want to be able to test the Linux code, too.
> 
> I have a machine which can boot linux 2.6 and XP. And I'm willing to
> help out.

Well, but it is much easier doing development and being able to test it
yourself instead of asking others to do it, isn't it?

 
> I don't insist on dropping support for old kernels if people want to
> keep it. I can live with the code present in the source, as it's
> #ifdef'ed anyway.

Ok, thank you.

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/

Re: [cbm4linux-users] Problems with cbm4linux

[Dirk J. <do...@cu...>]

> One could come to the conclusion that these always changing APIs do no
> good. It is the Linux' way to force people keeping up.

You'd better ask this on LKML and be prepared for tons of flames :-)

> Personally, I'd like it if you could try to keep them more separate. You
> want to remove things with a patch: Then make a patch which only does
> this, nothing more.

You're right at this point. I've now reworked all my changes and came up 
with 6 patches, which should do only one thing at a time, although some 
of them patch in the same areas and are therefore slightly dependand on 
each other.
I have updated the patches on
http://sourceforge.net/tracker/?group_id=45917&atid=444478

> As Michael has no means to test the Windows code, this "cross-testing"
> is mostly my task. As I do own some Linux machines, I want to be able to
> test the Linux code, too.

I have a machine which can boot linux 2.6 and XP. And I'm willing to 
help out.

> If the support for < 2.4 is dropped, it will be hard for me to be able
> to test both variants. Anyway, I would like to be able to do this, as

I don't insist on dropping support for old kernels if people want to 
keep it. I can live with the code present in the source, as it's 
#ifdef'ed anyway.

-- 
---> doj / cubic
----> http://cubic.org/~doj
-----> http://llg.cubic.org

Re: [cbm4linux-users] Problems with cbm4linux

[Spiro T. <tri...@gm...>]

Hello Dirk,

* On Thu, Jul 14, 2005 at 01:00:16PM +0200 Dirk Jagdmann wrote:
 
> My personal view ist, that kernels < 2.2 are now obsolete and I find
> it really cluttering to have the code support them anymore. If you
> really want to use such a kernel you can take any of the released
> cbm4linux version which still support them.

As long as it does not take considerable time and work to keep
compatible with older versions, I do not see any reason to drop support.
WHEN it will become time-consuming to support them, let's drop it, but
not before, please.

I hope Michael has the same point. In fact, I believe so as otherwise,
most probably, he would have dropped it long before.


> As cbm4linux is not the first kernel driver code I looked at/worked on
> I can tell from my experience that's it's no benefit to try to
> maintain different kernel versions/API within the same source code as
> it just messes up and complicates with each new kernel revision. The
> kernel API change and they change for a reason, which is mostly
> enhanced functionality or portability or performance or whatever.

One could come to the conclusion that these always changing APIs do no
good. It is the Linux' way to force people keeping up.

Unfortunately, I will not consider upgrading my small 486DX4-100 server
to a 2.6 kernel as long as my 2.2 kernel runs there.

> I see my patch just as an offer how the code of official releases
> might be changed.

Personally, I'd like it if you could try to keep them more separate. You
want to remove things with a patch: Then make a patch which only does
this, nothing more.

> If the majority want to include support for multiple major kernel
> releases in one sourcecode I'll accept that. But if you seriously ask
> what kernel versions your users nowadays use I'll bet you don't get
> (m)any answers for kernel < 2.4, so you could just drop the code and
> have a leaner codebase for future developments.

Ok, here one side note:

Michael and me, we are currently looking into integrating cbm4linux and
cbm4win back into one source. In fact, we are in a state that both
compile flawlessly out of one source, but we have not release yet. It
might be a good time to do so when we have joined both SF projects into
one, which we are planning.

As Michael has no means to test the Windows code, this "cross-testing"
is mostly my task. As I do own some Linux machines, I want to be able to
test the Linux code, too.

Personally, I do not have any 2.6 kernel machine (other than something
on VMWare), and only have one machine where a 2.4 kernel runs on. Thus,
I am mainly testing on a 2.2 kernel.

If the support for < 2.4 is dropped, it will be hard for me to be able
to test both variants. Anyway, I would like to be able to do this, as
this could help in finding problems. Furthermore, I can test that my
changes do not break Linux.



[RESET FIX]

> I changed this, because with floppy drive doesn't need any reset wait 
> (at least for my simple d64copy actions I do).

You are just lucky that you are not too fast. In fact, this waiting time
*is* necessary. I have "tested" this accidentially more than once. See
also Joe's comment.

In fact, I wanted to remove this 5 sec delay from cbm4win until I found
out that there is a reason for it.

Of course, having it configurable is a good choice. In fact, in cbm4win,
it already is (from the first initernal version in 2001).

> And my patch makes the reset wait configurable. If you want to stay on
> the safe side you could set the default value to 5 again and the
> behaviour would be the same as before. Just that it can now be changed
> by a simple module loading option.

It is not that I dislike this patch. I just wanted to warn about the
implications which you might not know about.

> >Hu? AFAIR, even "stock" cbm4linux uses these modules if the kernel
> >supports them. Fortunately, without your patches, c4l uses the old
> >implementation if these are not supported.
> 
> But this is only true for x86 equiped with standard parallel ports.

Again, you want to break compatibility without a reason (at least, I do
not see any).

This code does not do any harm, so, why remove it?

BTW: The "no-parport-code" is easier to debug than the parport-code.


With all your reasoning, if I would think as you, there would be no
reason to try to support Win 98 (which would be new) or Win NT 4.0
(which is already there) in cbm4win. I think this would be a pita.

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/

Re: [cbm4linux-users] Problems with cbm4linux

[Spiro T. <tri...@gm...>]

Hello Joe,

* On Thu, Jul 14, 2005 at 12:45:33PM +0200 Joe Forster/STA wrote:
 
> Just to clear things up: unless you wait for the drive to finish its
> reset sequence _before_ you (try to) communicate with it, the drive
> will get stuck in an endless loop. You will have to reset it again and
> be more patient this time. ;-)

Thanks for this more detailed explanation. I mentioned the -03 and -01
ROMs as they need more time to start up in certain conditions (when the
Autoboot-Code thinks it should boot something from the drive).

 
> Spiro, contact me if you'd like to embed it into cbm4linux; I'll point
> you to the respective code in the Commander source. Bye,

Yes, I want to include it in cbm4linux/cbm4win. I already spoke with
WoMo about this (*some* time ago). Anyway, until now, I totally forgot
about that.

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/

Re: [cbm4linux-users] driver error?

[simon <si...@pl...>]

Spiro Trikaliotis (tri...@gm...) wrote:
>

> Well... I'm thinking a little bit. Do you use any special type of
> machines (SMP, HT, for example)?

Nup, its a single processor Athlon.

> Could it be that the 99, DRIVER ERROR never occurs with the first
> command, but only after you used d64copy or cbmcopy with -tp? This woul=
d
> indicate that my reasoning might be valid.

hmmmm, not sure - Ill test and let you know. I think its randomish.

>
>
> > > 2. What did you do to make your parallel cable work?
> >
> > umm, realised Id lifted pin 1 from ground instead of pin2 :) misread
> > the instructions <cue embarrassed look>.
>
> Ok, this should be unrelated. Although: You might have a short between
> some lines on your cables (or, at least, small resistors) which result
> in this behaviour.

I bought this cable from Joe himself - although I did notice the cable is=
 very
thin.

I just made one for a friend and Ive already sent it off - Ill make anoth=
er
and see if it helps.

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Simon Scott
si...@pl...
mob: 0409113359
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Re: [cbm4linux-users] Problems with cbm4linux

[Dirk J. <do...@cu...>]

Hello Spiro,

> Speaking of these patches: What benefit do you get dropping support for
> pre-2.6 kernels? To me, it seems large parts of your patches are just
> throwing out the 2.4, 2.2 and 2.0 support.

My personal view ist, that kernels < 2.2 are now obsolete and I find it 
really cluttering to have the code support them anymore. If you really 
want to use such a kernel you can take any of the released cbm4linux 
version which still support them.
As cbm4linux is not the first kernel driver code I looked at/worked on I 
can tell from my experience that's it's no benefit to try to maintain 
different kernel versions/API within the same source code as it just 
messes up and complicates with each new kernel revision. The kernel API 
change and they change for a reason, which is mostly enhanced 
functionality or portability or performance or whatever.
I see my patch just as an offer how the code of official releases might 
be changed. If the majority want to include support for multiple major 
kernel releases in one sourcecode I'll accept that. But if you seriously 
ask what kernel versions your users nowadays use I'll bet you don't get 
(m)any answers for kernel < 2.4, so you could just drop the code and 
have a leaner codebase for future developments.

> For the "RESET FIX": The waiting time has a reason. If you issue a
> reset, but do not wait any time, you can get very annoying results. To
> avoid confusion, reset waits 5 seconds. Thinking about anything but a
> 1541 with -01 or -03 ROMs, this time might be a little bit high. For the
> 1541 with -01 or -03 ROM, this time might be more appropriate.

I changed this, because with floppy drive doesn't need any reset wait 
(at least for my simple d64copy actions I do). And my patch makes the 
reset wait configurable. If you want to stay on the safe side you could 
set the default value to 5 again and the behaviour would be the same as 
before. Just that it can now be changed by a simple module loading option.

> Hu? AFAIR, even "stock" cbm4linux uses these modules if the kernel
> supports them. Fortunately, without your patches, c4l uses the old
> implementation if these are not supported.

But this is only true for x86 equiped with standard parallel ports. The 
kernel parport api exists for a reason and my view is that it should be 
used if you have devices attached to the parallel port. I haven't tested 
it, but when using the parport api the cbm4linux code should be portable 
to every architecture linux supports that features some kind of parallel 
port.

-- 
---> doj / cubic
----> http://cubic.org/~doj
-----> http://llg.cubic.org

Re: [cbm4linux-users] Problems with cbm4linux

[Joe Forster/S. <st...@c6...>]

Hi guys,

> For the "RESET FIX": The waiting time has a reason. If you issue a
> reset, but do not wait any time, you can get very annoying results.

Just to clear things up: unless you wait for the drive to finish its=20
reset sequence _before_ you (try to) communicate with it, the drive will=20
get stuck in an endless loop. You will have to reset it again and be more=
=20
patient this time. ;-)

> To avoid confusion, reset waits 5 seconds.

The Star Commander keeps trying to detect the presence of devices (mostly=
=20
a contribution by WoMo). A nice side effect of this is that the Commander=
=20
can catch the exact moment when the drive finishes the reset sequence so=20
the delay is as short as possible.

Spiro, contact me if you'd like to embed it into cbm4linux; I'll point=20
you to the respective code in the Commander source. Bye,

Joe
--=20
KOV=C1CS Bal=E1zs alias Joe Forster/STA      st...@c6...; http://sta.c64.or=
g
Don't E-mail spam, HTML or uncompressed files! More contacts on homepage

Re: [cbm4linux-users] driver error?

[Spiro T. <tri...@gm...>]

Hello Simon,

* On Wed, Jun 29, 2005 at 11:41:22PM +0000 simon wrote:

> > 1. Does this "driver error" only occur if you use the parallel cable, or
> >    does it happen always?
> 
> Always has.
> 
> Before installing the parallel cable I used XM1541.

Well... I'm thinking a little bit. Do you use any special type of
machines (SMP, HT, for example)?

I believe (!) I found some race condition in the startup of the parallel
transfer working on cbm4win some time before. Such a race might leave
the drive in an erroneous state on exit, thus, your behaviour might be
due to that. I will check for myself.

Could it be that the 99, DRIVER ERROR never occurs with the first
command, but only after you used d64copy or cbmcopy with -tp? This would
indicate that my reasoning might be valid.


> > 2. What did you do to make your parallel cable work?
> 
> umm, realised Id lifted pin 1 from ground instead of pin2 :) misread
> the instructions <cue embarrassed look>.

Ok, this should be unrelated. Although: You might have a short between
some lines on your cables (or, at least, small resistors) which result
in this behaviour.

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/

Re: [cbm4linux-users] Problems with cbm4linux

[Spiro T. <tri...@gm...>]

Hello Dirk,

* On Thu, Jul 14, 2005 at 12:02:26PM +0200 Dirk Jagdmann wrote:
 
> As you're using a 2.6 kernel I suggest you try my patches for
> cbm4linux and linux 2.6. They're available here:
> http://sourceforge.net/tracker/?group_id=45917&atid=444478

Speaking of these patches: What benefit do you get dropping support for
pre-2.6 kernels? To me, it seems large parts of your patches are just
throwing out the 2.4, 2.2 and 2.0 support.

For the "RESET FIX": The waiting time has a reason. If you issue a
reset, but do not wait any time, you can get very annoying results. To
avoid confusion, reset waits 5 seconds. Thinking about anything but a
1541 with -01 or -03 ROMs, this time might be a little bit high. For the
1541 with -01 or -03 ROM, this time might be more appropriate.


> They then use the generic parport modules from linux, so you should
> have parport and parport_pc as kernel modules too.

Hu? AFAIR, even "stock" cbm4linux uses these modules if the kernel
supports them. Fortunately, without your patches, c4l uses the old
implementation if these are not supported.

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/

Re: Sv:Re: [cbm4linux-users] Problems with cbm4linux

[Dirk J. <do...@cu...>]

> [thomas@localhost ~]$ uname -a
> Linux localhost.localdomain 2.6.12-1.1390_FC4 #1 Tue Jul 5 19:58:55 EDT 2005 i686 athlon i386 GNU/Linux

As you're using a 2.6 kernel I suggest you try my patches for cbm4linux 
and linux 2.6. They're available here:
http://sourceforge.net/tracker/?group_id=45917&atid=444478

They then use the generic parport modules from linux, so you should have 
parport and parport_pc as kernel modules too.

-- 
---> doj / cubic
----> http://cubic.org/~doj
-----> http://llg.cubic.org

Sv:Re: [cbm4linux-users] Problems with cbm4linux

[Thomas J. <fro...@ju...>]

> Seems you don't have write permissions. As the stock cbm4linux code 
> contains two different methods for accessing the parallel port we first 
> have to find out which method you currently use. Please tell us the 
> output of "uname -a" on your machine.

[thomas@localhost ~]$ uname -a
Linux localhost.localdomain 2.6.12-1.1390_FC4 #1 Tue Jul 5 19:58:55 EDT 2005 i686 athlon i386 GNU/Linux

Re: [cbm4linux-users] Problems with cbm4linux

[Dirk J. <do...@cu...>]

> Jul 14 10:00:50 localhost kernel: cbm_write: no devices found
> Jul 14 10:00:50 localhost kernel: cbm_write: I/O error
> 
> It seems I have a problem every time I need to write to the disk but not 
> when I read information from the disk. So I figure I need to set a 
> permission somewhere, can anybody help me out?

Seems you don't have write permissions. As the stock cbm4linux code 
contains two different methods for accessing the parallel port we first 
have to find out which method you currently use. Please tell us the 
output of "uname -a" on your machine.

-- 
---> doj / cubic
----> http://cubic.org/~doj
-----> http://llg.cubic.org

[cbm4linux-users] Problems with cbm4linux

[Thomas J. <fro...@ju...>]

<html><head><style type="text/css">body{font:12px Arial;margin:3px;overflow-y:auto;overflow-x:auto}p{margin:0px;}blockquote, ol, ul{margin-top:0px;margin-bottom:0px;}</style></head>

<body><div style="display: block; font-family: Arial; font-size: 12px;">Hi, I am both new to linux and cbm4linux and now I have a problem.<br>
<br>
My system:<br>
-Fedora Core 4<br>
-XM1541 Cable (tested with Star Commander with a MSDOS bootdisk, works fine)<br>
<br>
I can :<br>
get status from 1541 drive<br>
get directory listing from 1541 drive<br>
<br>
I can't: <br>
-format with cbmformat<br>
-copy disk with d64copy<br>
<br>
This is how my /var/log/messages look like:<br>
<br>
Jul 14 10:00:50 localhost kernel: cbm_write: no devices found<br>
Jul 14 10:00:50 localhost kernel: cbm_write: I/O error<br>
Jul 14 10:00:50 localhost kernel: cbm_write: no devices found<br>
Jul 14 10:00:50 localhost kernel: cbm_write: I/O error<br>
Jul 14 10:00:50 localhost kernel: cbm_write: no devices found<br>
Jul 14 10:00:50 localhost kernel: cbm_write: I/O error<br>
<br>
It seems I have a problem every time I need to write to the disk but
not when I read information from the disk. So I figure I need to set a
permission somewhere, can anybody help me out?<br></br><p style="margin-top:11px;padding-top:3px;background-image: url(http://mail.lycos.co.uk/Images/Mail/_content/dot.gif);background-repeat: repeat-x;background-position: 0px 0px;"></div></body></html>