cbm4linux-users — Any cbm4linux related discussions

Re: [cbm4linux-users] a few questions

[Andreas <co...@c6...>]

Yo Joe,

> > I, personally, still suffer from my XMP1541 cable not working fine.
> >
> > Whenever trying parallel transfer a disk is read at quite ok parallel
> > speed, but on 2-3 places at different places (on same disks, several
> > re-tries) the transfer hangs, gives errors, and most likely continues. I
> > have experienced hangings aswell though.
>
> Try the same disks using only the serial half of your XMP1541 cable, i.e.
> configure cbm4linux to _not_ use the parallel cable. Does that help? Also,
> try the same disks with The Star Commander, with the same settings, under
> real DOS and Windows (if you have one on your machine! ;-) ). Does that
> help?
>
> You see, it might be the disks; the drive; the (parallel half of the)
> cable; the transfer software; the transfer settings; the operating
> system... ;-)
>
> > All serial transfers with and without warp are just fine.
>
> Okay, so disabling the parallel cable does help... (?) Bye,

Yes, using -s1   -s2 and warpmodes works just fine. Reads the very same disk 
perfectly. Reading the disk with parallel transfer several times shows the 
errors on different places ....

I am using one of these adapters which Protovision is selling. One end 
connects directly into the PC parallel port. Attached to it is a platine 
(board) which has a serial port and a port for the parallel cable. You surely 
know it.
That way the 1541 can be connected to the PC using the standard IEC cables and 
the parallel cable soldered to the drive.

This also allows me to test the parallel cable on the c64. Using several 
parallel copiers and nibblers has shown me that the parallel cables attached 
to (two different) drives are working fine. 

Also, if one of the wires would be broken on the cable, it should error all 
the way or just pass even unnoticed. Dunno how the routines there are 
programmed.

I will try to catch you on IRC and ask for a test procedure you like me to go 
through or sumthing. :)

l8r
-- 
Count Zero/CyberpunX/SCS*TRC
http://rr.c64.org - Retro Replay home

Re: [cbm4linux-users] a few questions

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

Hi Count Zero,

> I, personally, still suffer from my XMP1541 cable not working fine.
>
> Whenever trying parallel transfer a disk is read at quite ok parallel
> speed, but on 2-3 places at different places (on same disks, several
> re-tries) the transfer hangs, gives errors, and most likely continues. I
> have experienced hangings aswell though.

Try the same disks using only the serial half of your XMP1541 cable, i.e.
configure cbm4linux to _not_ use the parallel cable. Does that help? Also,
try the same disks with The Star Commander, with the same settings, under
real DOS and Windows (if you have one on your machine! ;-) ). Does that
help?

You see, it might be the disks; the drive; the (parallel half of the)
cable; the transfer software; the transfer settings; the operating
system... ;-)

> All serial transfers with and without warp are just fine.

Okay, so disabling the parallel cable does help... (?) Bye,

Joe

Re: [cbm4linux-users] a few questions

[Andreas <co...@c6...>]

Regarding Martin's and Ryan's Mails:

> > > 3) Is there, or would it be possible to construct, a program to do head
> > > alignment of a commodore drive using a x*1541 cable and a PC?
> >
> > Absolutely possible. Anything you can do from a C64 should be also
> > doable from a Linux PC (except highly timing-sensitive drive/host
> > communication stuff).
> > For inspiration, here's a small GTK+-based tool to measure the drives
> > rotation speed:
> >
> > http://a98.shuttle.de/~michael/rpm1541/
> > (Use scratch disk!)

> Nice to read such a thing.
> I have a 1541 i knew was working fine until i carried it to a friend.
> Now it can't read any more disks, it just returns errors. Unfortunately
> i have no program to re-align the head, is there something available on
> the net? I found no one so far who has any original disks with such
> programs and i was told it was a vendor-only thing.
>
> Can anyone help me?

This is basically all you need, no ?
Simply run Michael's program and align your drivespeed to 300 rounds per 
minute. "Kwik Copy" on C64 allows you to display the drivespeed aswell, but 
will display 312 r/min on a PAL system. :)
Other measures are the usual head cleaning with alcohol and using "proper" 
disks as far as possible.
The actual head alignment sometimes works (there are various programs redoing 
all kind of operations on "good" disks until it gives halfway good values), 
but I would try anything before going for that.
Whenever you need such a program more often, there is something else seriously 
wrong, I guess.


I, personally, still suffer from my XMP1541 cable not working fine.

Whenever trying parallel transfer a disk is read at quite ok parallel speed, 
but on 2-3 places at different places (on same disks, several re-tries) the 
transfer hangs, gives errors, and most likely continues. I have experienced 
hangings aswell though.
Using Suse 9.0 on AMD XP 2000 with a K7S5A Elitegroup Mainboard. Experienced 
similar problems eversince I switched to 2.4.x Kernel. Didn't help much to 
try 2.6.x Kernels either and I didn't manage to get 2.2.x going again.

Anyone else experienced this ? All serial transfers with and without warp are 
just fine.

(Yes, I asked and described this before ... :) )

l8r

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

Re: [cbm4linux-users] a few questions

[Ryan U. <nem...@ic...>]

On Fri, Jan 09, 2004 at 04:14:57PM +0100, Martin Brotzeller wrote:
> Nice to read such a thing.
> I have a 1541 i knew was working fine until i carried it to a friend.
> Now it can't read any more disks, it just returns errors. Unfortunately
> i have no program to re-align the head, is there something available on
> the net? I found no one so far who has any original disks with such
> programs and i was told it was a vendor-only thing.

I think the problem is that you need an alignment diskette to go along
with any alignment software.  This alignment diskette probably shouldn't
be copied because any copies will have generational loss and might not
be good for using as an alignment reference.  You could probably pick up
an alignment diskette on Ebay, and copy an actual alignment program to
another disk by use of a X1541 cable.  There are lots of 1541 alignment
programs out there.  Or you could wait for someone to write an alignment
program that runs on PC with X1541 setup... ;)  (but don't hold your
breath on that)

--=20
Ryan Underwood, <ne...@ic...>

Re: [cbm4linux-users] a few questions

[Michael K. <mic...@pu...>]

On Fri, 9 Jan 2004, Ryan Underwood wrote:

> On Fri, Jan 09, 2004 at 02:15:58PM +0100, Michael Klein wrote:

[Warp mode description]
> > This means also that warp is generally safer than turbo, because turbo
> > doesn't catch transfer errors (data sent by 1541 != data received by PC)!
>
> Interesting!  In warp mode, does the PC retry in case of errors?  Along
> the lines of my original question, is there a particular reason _not_ to
> use warp mode under any set of circumstances?

No, at least I cannot think of one right now ;-)

> After copying some disks, I'm also wondering if d64copy tries to do
> anything about the most common forms of copy protection (1/2 track,
> missing blocks, etc).

No, the copy protection could not be stored in a .d64 anyway.
If you want to archive your originals you'll have to sixpack them on a
C64. (Some day there might be a dedicated nibbler for cbm4linux, though)

> For example, I dumped Winter Games by Epyx, which
> I was almost certain had some sort of copy protection on it.  The copy
> process completed without error on both sides, however.  (I haven't
> tested the resulting images.)

I'm pretty sure the image will not work. AFAICS, most advanced copy
protected disks can be copied without a single error message, but the
actual protection is lost of course.

> > > 3) Is there, or would it be possible to construct, a program to do head
> > > alignment of a commodore drive using a x*1541 cable and a PC?
> >
> > Absolutely possible. Anything you can do from a C64 should be also
> > doable from a Linux PC (except highly timing-sensitive drive/host
> > communication stuff).
> > For inspiration, here's a small GTK+-based tool to measure the drives
> > rotation speed:
> >
> > http://a98.shuttle.de/~michael/rpm1541/
> > (Use scratch disk!)
>
> Very cool.  Thanks for your informative reply!

You're welcome!

-- 
Michael

Public key : http://www.lb.shuttle.de/puffin/identity.pub
Fingerprint: 48BD 7D3D A23E FF5B 50ED  D917 DF9D 8488 321C 0487

Re: [cbm4linux-users] a few questions

[Martin B. <bro...@in...>]

On Fri, 2004-01-09 at 14:15, Michael Klein wrote:

> > 3) Is there, or would it be possible to construct, a program to do head
> > alignment of a commodore drive using a x*1541 cable and a PC?
> 
> Absolutely possible. Anything you can do from a C64 should be also
> doable from a Linux PC (except highly timing-sensitive drive/host
> communication stuff).
> For inspiration, here's a small GTK+-based tool to measure the drives
> rotation speed:
> 
> http://a98.shuttle.de/~michael/rpm1541/
> (Use scratch disk!)

Nice to read such a thing.
I have a 1541 i knew was working fine until i carried it to a friend.
Now it can't read any more disks, it just returns errors. Unfortunately
i have no program to re-align the head, is there something available on
the net? I found no one so far who has any original disks with such
programs and i was told it was a vendor-only thing.

Can anyone help me?

regards,
Martin

Re: [cbm4linux-users] a few questions

[Ryan U. <nem...@ic...>]

On Fri, Jan 09, 2004 at 02:15:58PM +0100, Michael Klein wrote:
>=20
> Warp mode sends raw (unchecked) GCR data over the bus, leaving decoding
> and checksumming to the Linux side. This is normally significantly
> faster despite the fact that more data is transferred (325(?) bytes
> instead of 256). Thus, the Linux host catches in fact more block
> checksum errors (23) than in non-warp (turbo/original) mode, where the
> 1541 automatically retries and eventually succeeds.
>=20
> This means also that warp is generally safer than turbo, because turbo
> doesn't catch transfer errors (data sent by 1541 !=3D data received by PC=
)!

Interesting!  In warp mode, does the PC retry in case of errors?  Along
the lines of my original question, is there a particular reason _not_ to
use warp mode under any set of circumstances?  It seems that extra speed
doesn't very often come without a price of some sort....

After copying some disks, I'm also wondering if d64copy tries to do
anything about the most common forms of copy protection (1/2 track,
missing blocks, etc).  For example, I dumped Winter Games by Epyx, which
I was almost certain had some sort of copy protection on it.  The copy
process completed without error on both sides, however.  (I haven't
tested the resulting images.)

> > 3) Is there, or would it be possible to construct, a program to do head
> > alignment of a commodore drive using a x*1541 cable and a PC?
>=20
> Absolutely possible. Anything you can do from a C64 should be also
> doable from a Linux PC (except highly timing-sensitive drive/host
> communication stuff).
> For inspiration, here's a small GTK+-based tool to measure the drives
> rotation speed:
>=20
> http://a98.shuttle.de/~michael/rpm1541/
> (Use scratch disk!)

Very cool.  Thanks for your informative reply!

--=20
Ryan Underwood, <ne...@ic...>

Re: [cbm4linux-users] a few questions

[Michael K. <mic...@pu...>]

Hi Ryan,

> I set up a little copying rig with d64copy, a 1541, and a XM1541 cable
> (orignally a XE1541).
>
> 1) What are the differences in operation when using warp mode?  I seem
> to get many more errors using warp mode transfers than non-warp.

Warp mode sends raw (unchecked) GCR data over the bus, leaving decoding
and checksumming to the Linux side. This is normally significantly
faster despite the fact that more data is transferred (325(?) bytes
instead of 256). Thus, the Linux host catches in fact more block
checksum errors (23) than in non-warp (turbo/original) mode, where the
1541 automatically retries and eventually succeeds.

This means also that warp is generally safer than turbo, because turbo
doesn't catch transfer errors (data sent by 1541 != data received by PC)!

> 2) Occasionally in the middle of a copy, the 1541 will bang its head
> like it encountered a read error, but d64copy doesn't report any error.
> In that case, can I be confident that a re-read succeeded?

Is that in warp or turbo? Either way, I'd say yes, the data should be
fine. If not, it's a bug ;-)

> Actually, the bigger question is, can I always trust d64copy output to
> tell me if there were any errors at all with the transfer?

Yes, see above. (Of course it doesn't hurt to repeat the copy operation
and do a binary diff, if in doubt)

> 3) Is there, or would it be possible to construct, a program to do head
> alignment of a commodore drive using a x*1541 cable and a PC?

Absolutely possible. Anything you can do from a C64 should be also
doable from a Linux PC (except highly timing-sensitive drive/host
communication stuff).
For inspiration, here's a small GTK+-based tool to measure the drives
rotation speed:

http://a98.shuttle.de/~michael/rpm1541/
(Use scratch disk!)

Cheers!

-- 
Michael

Public key : http://www.lb.shuttle.de/puffin/identity.pub
Fingerprint: 48BD 7D3D A23E FF5B 50ED  D917 DF9D 8488 321C 0487

[cbm4linux-users] a few questions

[Ryan U. <nem...@ic...>]

Hi,

I set up a little copying rig with d64copy, a 1541, and a XM1541 cable
(orignally a XE1541).

1) What are the differences in operation when using warp mode?  I seem
to get many more errors using warp mode transfers than non-warp.

2) Occasionally in the middle of a copy, the 1541 will bang its head
like it encountered a read error, but d64copy doesn't report any error.
In that case, can I be confident that a re-read succeeded?

Actually, the bigger question is, can I always trust d64copy output to
tell me if there were any errors at all with the transfer?

3) Is there, or would it be possible to construct, a program to do head
alignment of a commodore drive using a x*1541 cable and a PC?

thanks,

--=20
Ryan Underwood, <ne...@ic...>

Re: [cbm4linux-users] Yay, Korean spam, I feel so HONORED

[Michael K. <mic...@pu...>]

On Tue, 22 Jul 2003, -=[o.b.iNSiDERZ]=- wrote:

> > On Sun, Jul 20, 2003 at 10:33:12PM -0400, sun...@fr... wrote
> > something in HTML and mostly in Korean, but starting with the English
> > >Mail for potential customers
> >
> > which makes it sound suspiciously like spam to me.  The list should
> > probably be set to reject messages from non-subscribed addresses if
> > possible.
>
> Whaaat? It isnt set so????

No, it wasn't. Sorry for that. Maybe Sourceforge should change the
default setting ;-)

-- 
Michael

message composed with
VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Apr 14 2002 20:41:29)

Re: [cbm4linux-users] Yay, Korean spam, I feel so HONORED

[-=[o.b.iNSiDERZ]=- <ob...@gm...>]

"Matthew W. Miller" schrieb:
> 
> On Sun, Jul 20, 2003 at 10:33:12PM -0400, sun...@fr... wrote
> something in HTML and mostly in Korean, but starting with the English
> >Mail for potential customers
> 
> which makes it sound suspiciously like spam to me.  The list should
> probably be set to reject messages from non-subscribed addresses if
> possible.

Whaaat? It isnt set so????

-- 
   *º¤.,___,.¤º*¨¨¨*¤         =Oliver@home=         *º¤.,¸¸¸,.¤º*¨¨*¤
   I   / __|__   http://www.bmw-roadster.de/Friends/Olli/olli.html  I
   I  / /  |_/   http://www.bmw-roadster.de/Friends/friends.html    I
   I  \ \__|_\   http://groups.yahoo.com/group/VGAP-93              I
   I   \___|     mailto:VGA...@ya...           I
   >>>  Linux is a wigwam: no windows, no gates, apache inside!   <<<

[cbm4linux-users] Yay, Korean spam, I feel so HONORED

[Matthew W. M. <mwm...@co...>]

On Sun, Jul 20, 2003 at 10:33:12PM -0400, sun...@fr... wrote 
something in HTML and mostly in Korean, but starting with the English
>Mail for potential customers

which makes it sound suspiciously like spam to me.  The list should 
probably be set to reject messages from non-subscribed addresses if 
possible.
-- 
Matthew W. Miller <mwm...@co...>

[cbm4linux-users] µ·¹ö´Â¹æ¹ý-ÃÖ¼ÒÈ°µ¿À¸·Î º»¾÷À» ´É°¡ÇÏ´Â ÃÖ°íÀÇÅõÀ⽺

[<sun...@fr...>]

<html>
<head>
<title>Mail for potential customers</title>
<body> 
넷마블아지트-인터넷1위 게임포털 넷마블의 2000만회원들이 단골<br>
이 되어 이용하게 되는 곳으로, 넷마블 아지트로 선정된 점주께서는<br>
찾아온 넷마블 회원에게 사용금액의 일부를 마음대로 할인해 주시<br>
면 됩니다.<br>
<br>
넷마블쿠폰배송 및 아지트를 관리해 주실분을 모십니다.(10-100만<br>
원투자)-고소득가능<br>
<br>
돈되는 파란 동그라미-<br>
파란동그라미를 붙이시면:2000만명(동네마다 수백-수천명)의 넷마<br>
블회원이 파란동그라미 곁으로 모여듭니다.<br>
파란동그라미가게(아지트)는 사이버캐쉬를 준다는 소문 때문이죠.<br>
소문은 넷마블이 퍼뜨립니다.<br>
사장님은 바글거리는 손님들 속에서 신바람 나는 장사만 하세요<br>
계약조건:손님에게 5-10%dc(개설비,가맹비무료)<br>
<br>
파란동그라미(넷마블아지트)란? 전국의 모든 가게들은 신청을 통해 가맹비 전혀 없이 넷마블아지트가 될 수 있습니다.<br>
넷마블아지트가 되면 입구에 파란동그라미를 붙여드리는데 국내 인터넷1위 포탈 넷마블의 2000만 회원들은 쿠폰을 받기위해 이동그라미를 찾아오게 됩니다<br>
아지트에서는 오는 회원들에게 할인금액을 쿠폰으로 주고, 회원들은 쿠폰을 사이버캐쉬로 전환하여 넷마블 내 다양한 컨텐츠를 이용할 수 있습니다.<br>
<br>
아지트쿠폰:아지트를 찾아온 고객들에게 할인금액만큼 제공하는 쿠폰으로 넷마블에서 인증번호를 입력하고 넷마블 캐쉬로 전환합니다.<br>
                     이 캐쉬는 게임,아반타구입,쇼핑,영화,만화,문자메세지등 다양한 용도로 마음껏 사용하실 수 있습니다.<br>
<br>
넷마블 아지트가 되면 왜 장사가 잘될까요? 현재 전 인터넷 이용자들은 사이버캐쉬에 굶주려 있습니다.그런데 아지트를 방문하면 쿠폰으로 사이버캐쉬를 듬뿍 받을 수 있는 겁니다.<br>
특히 넷마블의 2000만 회원들에게 항시 아지트를 방문하도록 온라인 상에서 뿐만 아니라 전단, 포스터, 책갈피 등 오프라인 상에서의 홍보활동도 병행하기 때문에<br>
2000만회운들이 단골이되어 여러분의 가게를 방문하게 되기 때문입니다.<br>
<br>
지역별 아지트를 관리하고 쿠폰을 배급할 분을 모집합니다.(본사보다 부담이 덜가는조건 10만원-100만원투자<br>
홍보물구입비로 평생직장이 보장되며 2000만회원을 담보로 하는 기막힌 사업입니다. 부업으로 시작하여 본업으로 돌아가는<br>
확실한 사업인데다 게임포털1위 넷마블이 함께하는 안정적 사업입니다.<br>
<br>
문의:넷마블아지트사업지사장- 011-707-7825<br>
               sun...@fr...<br>
<br>

</body></html>

Re: [cbm4linux-users] Device not found?

[Michael K. <mic...@pu...>]

On Sun, 8 Jun 2003, Mick Reed wrote:

> Can anyone please help with this problem?  I am using the direct port
> access setup.  I can reset the drive, but apparently nothing else. I am
> using an XA1541 cable and an Athlon XP 2200+ with gentoo linux.

Hm, your box is quite a bit faster than my Duron 700, so a timing
problem can't be ruled out (but that's IMHO unlikely).
Perhaps somebody else can comment on this?

Anyway, are you sure the drive and cable are ok? (i.e. does it work with
Star Commander)

Here's a _very_ basic cable tester (should be run without any connected
devices):

http://a98.shuttle.de/~michael/xtest/

HTH,

-- 
Michael

"I may have invented Ctrl-Alt-Del, but Microsoft made it popular."
  - David Bradley, one of the designers of the original IBM PC

[cbm4linux-users] Device not found?

[Mick R. <mic...@fr...>]

Can anyone please help with this problem?  I am using the direct port
access setup.  I can reset the drive, but apparently nothing else. I am
using an XA1541 cable and an Athlon XP 2200+ with gentoo linux.

I have the module install at boot, giving the proper options:
modprobe cbm port=0x378 irq=7 cable=-1 reset=-1
seems to work.  When I try to use it: see below.

# cbmctrl reset        <--This works
# cbmctrl detect       <--Nothing appears to happen
# cbmctrl command 8 I0:
cbmctrl: command: No such device

I have tried using modprobe -v to check what it is doing when it uses
insmod, as well as
/proc/interrupts and /proc/ioports.  Also lsmod to see if it is really
installed.  I have used 'regular' and EPP modes on the port.  I can't
find any problems (yet!)  Any help is really appreciated!

Mick

 mic...@sd...
SDF Public Access UNIX System - http://sdf.lonestar.org
mick_makes_em on ebay.com

Re: [cbm4linux-users] XMP1541 parallel Problems

[Michael K. <mic...@pu...>]

On Wed, 28 May 2003, Andreas wrote:

> > How about parallel turbo?
>
> What would that mean ? my docs here say: original, serial 1/2 and parallel
> along with warp ... hm ?

That would be '-t parallel' without '-w'. The drive routine consists of
two distinct modules: bus protocol (s1/s2/parallel) and disk access
(turbo/warp). Turbo is implicitly used if '-w' isn't used.

'-t original' is quite different because it doesn't use any custom
routines at all.

(I think that's quite similar to the Commander, BTW)

> > Ok, wild guess: Is your drive speed ok? I hacked up a small drivemeter a
> > while ago (hey, even with GUI!):
> >
> > http://a98.shuttle.de/~michael/rpm1541
> >
> > (both binary + source, needs GTK+-1.2)
> >
> > It will trash track 41, so be sure to use a scratch disk.
>
> The program doesnt work at all with the 1541II here.

Huh? There must be sth wrong with the drive then. I'm not sure if I
tested rpm1541 with a 1541-II, but I can't see why it shouldn't work
there...

> On the 1571 though it
> gave me nice 300.30 RPM ... will re-try with the 41 whenever the EPROM is
> replaced.
> rpm1541 is really nice

thx!

> .. wish someone would make MC or something else behave
> a little like starcommander with "the hard" stuff being already supplied (or
> port SC over ... hehe)

Any takers? ;-)

-- 
Michael

registered linux user #189917  --  http://counter.li.org/

Re: [cbm4linux-users] XMP1541 parallel Problems

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

Hi Count Zero,

> regarding my previous posts, is there anything else I could try, or
> have you heard of similar problems before ?

Ehm, dunno about specific test, but, no, no such problems were reported
before. Perhaps, people, who have Jiffy DOS-equipped drives, disable Jiffy
DOS when using "non-standard" programs (i.e. disk turbos etc.) by reflex?

> All this connected with the adaptor from your cable shop I assume. (got it
> from Protovision ppl) --- just hardwire - hacked to become XM instead of XE.

Yeah, probably. Also, there were no reports about such weird problems,
caused by damaged products coming from my shop.

Sorry, apparently, I can't help you. _You_ can help me with finding
something...? :-)

Joe

Re: [cbm4linux-users] XMP1541 parallel Problems

[Andreas <co...@c6...>]

Montag, 26. Mai 2003 21:49 wrote Michael Klein:

Hi Michael,

> Uhm, dumb question: does a SJD-equipped drive work with a stock 64
> kernel?

Well, when I just tried it again, it failed ... Since I had the 41II on the 64 
I also tried all kind of other different drive programs and found that there
must be something completely wrong.

I currently suspect the ROMs burned into that drive. Will read the current 
eprom out and compare against some sane ROMs.

Will have to report progress next week though since I am away for some days.
A different ROM may explain a few things. The 2.6 ROM I compared already looks 
VERY suspicious.

> How about parallel turbo?

What would that mean ? my docs here say: original, serial 1/2 and parallel 
along with warp ... hm ?

> Ok, wild guess: Is your drive speed ok? I hacked up a small drivemeter a
> while ago (hey, even with GUI!):
>
> http://a98.shuttle.de/~michael/rpm1541
>
> (both binary + source, needs GTK+-1.2)
>
> It will trash track 41, so be sure to use a scratch disk.

The program doesnt work at all with the 1541II here. On the 1571 though it 
gave me nice 300.30 RPM ... will re-try with the 41 whenever the EPROM is 
replaced.
rpm1541 is really nice .. wish someone would make MC or something else behave 
a little like starcommander with "the hard" stuff being already supplied (or 
port SC over ... hehe)

l8r

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

Re: [cbm4linux-users] XMP1541 parallel Problems

[Michael K. <mic...@pu...>]

Andreas,

> Infact with SJD I have noticed several problems that are all on the behal=
f of
> SJD though. E.g.
>
> # cbmctrl status 8
> ............................................
> # cbmctrl dir 8
> cbmctrl: dir: No such device

Uhm, dumb question: does a SJD-equipped drive work with a stock 64
kernel?

> Since here it doesn't even respond to standard IO commands correctly I wo=
nder
> how at all it works out :) ... will check closer whenever I get my JD128
> back.
>
> Plain JD works rather well, just doesn't seem reliable. Actually, as I no=
ted
> on a previous mail, JD+XMP-Cable seems slightly faster than plain
> ROM+XMP-Cable on SERIAL (1 and2) transfers.

That's probably just because of the higher stepper frequency.
No idea why it should be less reliable, though.

> Trying JD+XMP with parallel modes caused the same type of error behaviour=
 I
> used to have. Enabling -w warp mode completely bugs out. error 23 all ove=
r
> the place and no sector is transferred ok.
>
> Didn't take the time to check with all other serial modes yet.
> Whenever I feel happy and my ordinary (Warp&Parallel) transfers works, I =
may
> start to dig around why the stuff doesn't work with SJD especially.
>
> Joe, regarding my previous posts, is there anything else I could try, or =
have
> you heard of similar problems before ?

> I am pretty sure I tried about anything possible, without even disturbing=
 the
> errors or influencing the transfer at all :(

How about parallel turbo?

> Even under heavy system load the transfer goes smooth for quite a few tra=
cks,
> bugs out, continues for some tracks, bugs out ... etc.
> It does the whole process slower though.

That's normal, since all user-space protocols rely on busy-loops.

> The errors come up on the same disk
> on completely random locations, cables are tripple checked and everything=
=2E
> All this connected with the adaptor from your cable shop I assume. (got i=
t
> from Protovision ppl) --- just hardwire - hacked to become XM instead of =
XE.
>
> ANY guess ??? I'll try anything --- still regarding myself as someone kno=
wing
> a little about drives... :)

Ok, wild guess: Is your drive speed ok? I hacked up a small drivemeter a
while ago (hey, even with GUI!):

http://a98.shuttle.de/~michael/rpm1541

(both binary + source, needs GTK+-1.2)

It will trash track 41, so be sure to use a scratch disk.

Good luck,

--=20
Michael

"Nicht alle Steuerelementpfade geben einen Wert zur=FCck"
               -- Microsoft C/C++ Version 12.00.8186

Re: [cbm4linux-users] XMP1541 parallel Problems

[Andreas <co...@c6...>]

Yo Joe !

> Hi Count Zero,
>
> > WARNING: I CAN NOT recommend using JD or SuperJD along with
> > StarCommander or cbm4linux for that matter. Especially SuperJD contains
> > too many ROM changes and all modes seem to bug or fail.
>
> Any _concrete_ problems?

Unless the parallel transfer with the drive doesn't work reliable, I don't 
want to blame JD or SJD for special behaviour and therefore sticked to 
standard ROM for my tests.

Infact with SJD I have noticed several problems that are all on the behalf of 
SJD though. E.g.

# cbmctrl status 8
............................................
# cbmctrl dir 8
cbmctrl: dir: No such device


Since here it doesn't even respond to standard IO commands correctly I wonder 
how at all it works out :) ... will check closer whenever I get my JD128 
back.

Plain JD works rather well, just doesn't seem reliable. Actually, as I noted 
on a previous mail, JD+XMP-Cable seems slightly faster than plain 
ROM+XMP-Cable on SERIAL (1 and2) transfers.
Trying JD+XMP with parallel modes caused the same type of error behaviour I 
used to have. Enabling -w warp mode completely bugs out. error 23 all over 
the place and no sector is transferred ok.

Didn't take the time to check with all other serial modes yet.
Whenever I feel happy and my ordinary (Warp&Parallel) transfers works, I may 
start to dig around why the stuff doesn't work with SJD especially.

Joe, regarding my previous posts, is there anything else I could try, or have 
you heard of similar problems before ?
I am pretty sure I tried about anything possible, without even disturbing the 
errors or influencing the transfer at all :(
Even under heavy system load the transfer goes smooth for quite a few tracks, 
bugs out, continues for some tracks, bugs out ... etc.
It does the whole process slower though. The errors come up on the same disk 
on completely random locations, cables are tripple checked and everything.
All this connected with the adaptor from your cable shop I assume. (got it 
from Protovision ppl) --- just hardwire - hacked to become XM instead of XE.

ANY guess ??? I'll try anything --- still regarding myself as someone knowing 
a little about drives... :)

l8r

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

Re: [cbm4linux-users] XMP1541 parallel Problems

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

Hi Count Zero,

> WARNING: I CAN NOT recommend using JD or SuperJD along with
> StarCommander or cbm4linux for that matter. Especially SuperJD contains
> too many ROM changes and all modes seem to bug or fail.

Any _concrete_ problems?

Yes, the Commander _definitely_ copies several ROM routines into the RAM
and puts an RTS to their end, thus creating a (sometimes patched)
subroutine version of some useful routine...

However, until now, I haven't heard of confirmed problems whose reason was
a hardware/software incompatibility... Bye,

Joe Forster/STA
st...@c6...

Re: [cbm4linux-users] XMP1541 parallel Problems

[Andreas <co...@c6...>]

Freitag, 23. Mai 2003 08:12 wrote Michael Klein:

RE all,

> > - 1541 model II with 2.6 ROM, but has JD ROM aswell.
>
> Hm, does JD increase the stepper frequency?

Yes, I am almost sure it does, though not 101% :)
All my tests are done using the normal 2.6 ROM though.
The attached archive contains a short log of a few tried transfers.

> > d64copy -d 0 -t p -w 8 pw.d64
> >
> > it reads a few tracks fine, then bugs around and drops dead or skips
> > with an
> > error. Whenever it skips with the error message, it reads a few tracks
> > with
> > perfect speed again and bugs off again then.
>
> When does it start to bug: At the start of a track or in the middle?
> In the first case it might be because the head is moving too fast.

As said, I only used the normal ROM. The log has a JD try aswell, which
was 'feeling' faster on the OK-Tracks. It bugged out the same way as the 
normal ROM though.

The actual errors occur during or towards the end of reading a track. Rarely 
at the beginning. Seems to me during reads of the 10th to 20th sector.
Also the speed zones of the disk don't seem to matter much.
I am open for any other options ! :)
Will get my other 1541II back in a few days or so. Will try with that one 
aswell ofcourse.


WARNING: I CAN NOT recommend using JD or SuperJD along with StarCommander or 
cbm4linux for that matter. Especially SuperJD contains too many ROM changes 
and all modes seem to bug or fail. Normal JD Serial1 and Serial2 Transfers 
work with latest JiffyDos ROMs. SJD doesn't even respond to cbmctrl dir 8  
... :)

> Here's a script to adjust the head movement speed:
>
> #!/bin/sh
> cbmctrl listen 8 15
> echo -ne "M-W\005\034\003\064\000\064" > /dev/cbm
> cbmctrl unlisten

Ah, interesting way of telling the drive here stuff. :)
Didn't think of cbmctrl usage that way. The log shows though, that
there is no difference. Tried several values. :(

l8r
-- 
Count Zero/CyberpunX/SCS*TRC
http://rr.c64.org - Retro Replay home

Re: [cbm4linux-users] XMP1541 parallel Problems

[Michael K. <mic...@pu...>]

Hi Andreas et al,

> - 1541 model II with 2.6 ROM, but has JD ROM aswell.

Hm, does JD increase the stepper frequency?

> d64copy -d 0 -t p -w 8 pw.d64
>
> it reads a few tracks fine, then bugs around and drops dead or skips 
> with an
> error. Whenever it skips with the error message, it reads a few tracks 
> with
> perfect speed again and bugs off again then.

When does it start to bug: At the start of a track or in the middle?
In the first case it might be because the head is moving too fast.

Here's a script to adjust the head movement speed:

#!/bin/sh
cbmctrl listen 8 15
echo -ne "M-W\005\034\003\064\000\064" > /dev/cbm
cbmctrl unlisten

Higher values instead of (both) 064's slow down, lower values speed up.
My 1571 gets unreliable below 024. The original ROM uses 064.
All values are octal.

HTH,

-- 
Michael

Darwin 6.5 Power Macintosh powerpc

[cbm4linux-users] XMP1541 parallel Problems

[Andreas <co...@c6...>]

Hello partypeople,

I have problems transfering diskimages (parallel) using the following setup:

- Suse Linux 8.2 running KDE 3.1 (but also in runlevel 3)
- self-compiled kernel
- 900MHz AMD Athlon
- cbm module loaded 
- SPP, EPP aswell as ECP modes all tried.
- 1541 model II with 2.6 ROM, but has JD ROM aswell.

As for the drive, it reads the disks perfectly on plain serial transfer in any 
mode (s1 and s2, warp on or off), but whenever I issue:

d64copy -d 0 -t p -w 8 pw.d64

it reads a few tracks fine, then bugs around and drops dead or skips with an 
error. Whenever it skips with the error message, it reads a few tracks with 
perfect speed again and bugs off again then.
The disk itself is ofcourse fine. Issuing the same command again right away 
will bug off on different tracks than on the first try.

Of the 30-40 tries to read or write (same thing happens) a d64 image ONCE it 
got through fine.

I already got the parallel cable in that drive replaced, since it was a flat 
cable without shielding, but the new heavily shielded and properly grounded 
cable didnt make a difference.

On real 64 the drive is fine I may also add.

The XMP Adaptor I use is the one Joe "Sta" Foster is selling (I think he 
produced them) and we applied the "change those lines" patch to it, since its 
originally originally is a XEP1541 adapter/interface.

(Without the patch nothing worked. With the patch all is fine on the serial 
end. If just the parallel would work ... sniff ... :( )

I wasnt able to test this under dos with SC, since there is no windows/dos on 
this machine anymore. Has anyone experienced a similar problem ?

Could this be a timing issue somehow ?


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

Re: [cbm4linux-users] cbm4linux on Suse 8.2 & GCC 3.3

[Andreas <co...@c6...>]

Dienstag, 15. April 2003 16:54 wrote Michael Klein:

> > On the other hand, Andreas' solutions as far from that good since it
> > uses a new call to printf() for every line.
>
> That's right. Wouldn't hurt /that/ much here, though ;-)

As said I am a moron to C --- :)

The patch howto I found from some diff-file on another project where it was 
fixed the same way. :)
Was fileutils or sumthing alike. :)

l8r

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