Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Commodore » Commodore Emulation » ANNC: xum1541 beta now available
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
ANNC: xum1541 beta now available [message #147461] Sat, 12 December 2009 15:59 Go to next message
Wolfgang Moser is currently offline  Wolfgang Moser
Messages: 632
Registered: July 2003
Karma: 0
Senior Member
Hello CBM'ers,

this is a message forward from the OpenCBM user mailing list where Nate
Lawson annouced the beta release of his version of a firmware for an USB
based transfer cable as backend for OpenCBM. Read on...

Womo

-------- Original-Nachricht --------
Subject: [opencbm-user] xum1541 beta now available
Date: 12 Dec 09 01:15:19 GMT
From: nate (at) root (dot) org (Nate Lawson)

I'm proud to announce that the beta release of the xum1541 USB floppy
adapter is now available. The firmware and host-side code are now
available in OpenCBM cvs. See the xum1541 home page (below) for
information about building and setting up the first hardware, based on
the Atmel AT90USBKEY development board.

This beta is pretty well-tested on Windows and Mac OS X, including error
handling cases. However, both the device and host-side code is likely to
change between now and the final release, so be sure you're willing to
upgrade if you want to start using it now. Notably, the nibbler support
is still being debugged, so it isn't enabled yet.

I'd like to thank Wolfgang Moser, Spiro Trikaliotis, and Christian
Vogelgsang for testing various code drops, building their own devices,
and providing good advice as things progressed.

http://www.root.org/~nate/c64/xum1541/

--
Nate


------------------------------------------------------------ ------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
opencbm-user mailing list
opencbm-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opencbm-user
Re: ANNC: xum1541 beta now available [message #147462 is a reply to message #147461] Sun, 13 December 2009 04:01 Go to previous messageGo to next message
MagerValp is currently offline  MagerValp
Messages: 847
Registered: April 2012
Karma: 0
Senior Member
On 12 Dec, 21:59, Wolfgang Moser <w...@news.trikaliotis.net> wrote:
> Hello CBM'ers,
>
> this is a message forward from the OpenCBM user mailing list where Nate
> Lawson annouced the beta release of his version of a firmware for an USB
> based transfer cable as backend for OpenCBM.

Great to see that it's coming together. What's the speed like though?
The demo video made it seem like it only supported original C= speed,
but that was an early alpha.
Re: ANNC: xum1541 beta now available [message #147463 is a reply to message #147462] Sun, 13 December 2009 06:22 Go to previous messageGo to next message
Wolfgang Moser is currently offline  Wolfgang Moser
Messages: 632
Registered: July 2003
Karma: 0
Senior Member
Hello MV,

MagerValp schrieb:
> On 12 Dec, 21:59, Wolfgang Moser <w...@news.trikaliotis.net> wrote:
>> Hello CBM'ers,
>>
>> this is a message forward from the OpenCBM user mailing list where Nate
>> Lawson annouced the beta release of his version of a firmware for an USB
>> based transfer cable as backend for OpenCBM.
>
> Great to see that it's coming together. What's the speed like though?
> The demo video made it seem like it only supported original C= speed,
> but that was an early alpha.

once the ParallelBurst protocol is implemented and validated to be
stable through testing, it would be one "track per round" which is
nearly 8000 raw GCR bytes per round, which approximates to 40 kB/s raw
GCR data transfer speed. This estimation neglects the time needed to
move the R/W head and such. It's just the speed you can reach with
BurstNibbler.

I my personal tests I read in a 35 tracks disk within 22 seconds on a
Commodore 1571 disk drive with the (standard) parallel transfer
protocol. The 1541(-II) looks to be a bit slower, here a disk was
transferred in 26 seconds I believe. Maybe both times can be improved
further, when using more features a microcontroller solution can
provide. I'm thinking of using the two handshaking lines of the SpeedDOS
parallel cable, so that handshaking doesn't need to be done with IEC bus
signalling. By using this maybe the automatic raw GCR read sector
interleave reduces from 3 to 2 and shortens time that way.

I hope that if experienced people start building adaptors upon the
AT90USBKey development board, more resilient results from timing tests
would show the true performance of the xum1541 firmware.


Womo

--
------ to obtain more infos about me, look up the page ------
----- http://www.wmsr.de | wn0612 (at) d81 (dot) de -----
Re: ANNC: xum1541 beta now available [message #147464 is a reply to message #147461] Sun, 13 December 2009 07:07 Go to previous messageGo to next message
Joe Forster/STA is currently offline  Joe Forster/STA
Messages: 371
Registered: March 2013
Karma: 0
Senior Member
To (mis)quote Duke Nukem: Daaamn, you're gooood... ;-) I'm eagerly
looking forward to more infos!
Re: ANNC: xum1541 beta now available [message #147597 is a reply to message #147461] Sun, 13 December 2009 20:31 Go to previous messageGo to next message
Jerry Kurtz is currently offline  Jerry Kurtz
Messages: 244
Registered: June 2012
Karma: 0
Senior Member
Cool. It will be a great day once the C64, USB, and nibbler support
become a reality :)

Jerry
Re: ANNC: xum1541 beta now available [message #147598 is a reply to message #147463] Mon, 14 December 2009 02:31 Go to previous messageGo to next message
Groepaz is currently offline  Groepaz
Messages: 640
Registered: December 2011
Karma: 0
Senior Member
Wolfgang Moser wrote:

> I my personal tests I read in a 35 tracks disk within 22 seconds on a
> Commodore 1571 disk drive with the (standard) parallel transfer

mmmh that sounds slowish to me *shrug* you can read a disk in 27 seconds
using IEC only, with parallel it should be more like around 9 seconds (7
without head movement). *shrugs again*

--

http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org

Q: what is the main problem on the web? A: avoiding commercial idiots. Q:
when can you be sure that you are not dealing with commercial idiots? A:
When you actually find a site that delivers something, instead of only
asking for money/karma/patience/bad taste.
<Fravia>
Re: ANNC: xum1541 beta now available [message #147599 is a reply to message #147598] Mon, 14 December 2009 08:13 Go to previous messageGo to next message
Joe Forster/STA is currently offline  Joe Forster/STA
Messages: 371
Registered: March 2013
Karma: 0
Senior Member
>> I my personal tests I read in a 35 tracks disk within 22 seconds on a
>> Commodore 1571 disk drive with the (standard) parallel transfer
>
> mmmh that sounds slowish to me *shrug* you can read a disk in 27 seconds
> using IEC only, with parallel it should be more like around 9 seconds (7
> without head movement). *shrugs again*

I think you may be more than welcome to add another, much tighter,
transfer protocol to the bunch. ;-)
Re: ANNC: xum1541 beta now available [message #147600 is a reply to message #147599] Mon, 14 December 2009 08:43 Go to previous messageGo to next message
Groepaz is currently offline  Groepaz
Messages: 640
Registered: December 2011
Karma: 0
Senior Member
Joe Forster/STA wrote:

>>> I my personal tests I read in a 35 tracks disk within 22 seconds on a
>>> Commodore 1571 disk drive with the (standard) parallel transfer
>>
>> mmmh that sounds slowish to me *shrug* you can read a disk in 27 seconds
>> using IEC only, with parallel it should be more like around 9 seconds (7
>> without head movement). *shrugs again*
>
> I think you may be more than welcome to add another, much tighter,
> transfer protocol to the bunch. ;-)

10 years ago i might have ... today i am using warpcopy (which is quite damn
close to the IEC bus limit) and thats enough for me :) i have all my disks
transfered too, so what the hell... :=)

anyway, is it really the transfer protocoll that limits the speed? i would
think that burstnibbler does a bit more than just read regular sectors as
fast as possible, and all the extra stuff needs the time it needs (probably
an extra disk revolution per track too, to do some more analyzing).

other than that, i'd rip apart the well known 15seconds speeddos copy,
should be easy enough :)

--

http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org

Wenn man ein zweite Chance im Leben bekommt, sollte man immer daran denken
das man seine erste bereits versaut hat.
Re: ANNC: xum1541 beta now available [message #147601 is a reply to message #147600] Mon, 14 December 2009 09:48 Go to previous messageGo to next message
Joe Forster/STA is currently offline  Joe Forster/STA
Messages: 371
Registered: March 2013
Karma: 0
Senior Member
> 10 years ago i might have ... today i am using warpcopy (which is quite damn
> close to the IEC bus limit) and thats enough for me :) i have all my disks
> transfered too, so what the hell... :=)

I haven't had any need for my own software for, at least, the last
half decade either but developing useful stuff is _always_ fun!

> anyway, is it really the transfer protocoll that limits the speed?

Mostly. If I'm not mistaken, xum1541 is using opencbm's transfer
routines which are heavily based on those of Star Commander. Star
Commander was always meant to run on a system where interrupts may
occur any time as well as the system's effective speed is completely
unknown. For these reasons, stability was much preferred over raw
speed.

> other than that, i'd rip apart the well known 15seconds speeddos copy,
> should be easy enough :)

Probably. If I understand it correctly, xum1541 takes over the burden
of communicating with the drive. (You see, the greatest problem of a
USB-only solution was the relatively high overhead of USB transfers.
USB was not meant to be used for peeking and poking individual wires
in the frequency realm of cca. 100 kHz.) _Inside_ the xum1541('s
microcontroller), there are no (unexpected) interrupts and the system
speed is known exactly. So, yes, implementing much a tighter tarnsfer
protocol is absolutely possible.
Re: ANNC: xum1541 beta now available [message #147602 is a reply to message #147601] Mon, 14 December 2009 11:09 Go to previous messageGo to next message
Groepaz is currently offline  Groepaz
Messages: 640
Registered: December 2011
Karma: 0
Senior Member
Joe Forster/STA wrote:

>> anyway, is it really the transfer protocoll that limits the speed?
>
> Mostly. If I'm not mistaken, xum1541 is using opencbm's transfer
> routines which are heavily based on those of Star Commander. Star
> Commander was always meant to run on a system where interrupts may
> occur any time as well as the system's effective speed is completely
> unknown. For these reasons, stability was much preferred over raw
> speed.

ah ok, that makes sense.

--

http://www.hitmen-console.org http://magicdisk.untergrund.net
http://www.pokefinder.org http://ftp.pokefinder.org

Zweck des Disputs oder der Diskussion soll nicht der Sieg, sondern der
Gewinn sein.
<Joseph Joubert>
Re: ANNC: xum1541 beta now available [message #147603 is a reply to message #147602] Tue, 15 December 2009 13:47 Go to previous message
Wolfgang Moser is currently offline  Wolfgang Moser
Messages: 632
Registered: July 2003
Karma: 0
Senior Member
Heya,

Groepaz schrieb:
> Joe Forster/STA wrote:
>
>>> anyway, is it really the transfer protocoll that limits the speed?
>>
>> Mostly. If I'm not mistaken, xum1541 is using opencbm's transfer
>> routines which are heavily based on those of Star Commander. Star
>> Commander was always meant to run on a system where interrupts may
>> occur any time as well as the system's effective speed is completely
>> unknown. For these reasons, stability was much preferred over raw
>> speed.
>
> ah ok, that makes sense.

yep, that's one side: not reinventing the wheel, when most people are
looking for a cheapmost solution that just does work.

Some more drawbacks of the PC-to-1541-transfer based parallel cables
that affect transfer speed are:
* Not using handshaking lines and only 8 parallel lines instead
of the 10 lines SpeedDOS cable.
PC LPTs port were able to detect the 1µs handshake pulse of
incoming events, once I developed some sort of mini hardware
based on a 74LS74 to emulate the SpeedDOS protocol for VC1541
from Torsten Paul, but wasn't able to eliminate remaining
timing bugs.
==> Therefore handshaking has to be done via the relatively
slow IEC bus lines (Open Collector characteristics)
* Only asynchronous protocols could be used, even under plain
old DOS, because a lot of Star Commander beta testers always
wanted Star Commander to run under Win95/Win98 (as Joe said
already)
* "Weak" hardware implementations of some LPT parallel ports,
so that double-reads are desperately needed as a workaround

In general current parallel transfer implementations beside the parallel
burst protocol do not make use of some sort of interleave. That means,
in a first step data is read off the disk into a buffer and then
transferred over to the PC. We never (neither the Star Commander
development team -- Joe Forster --, nor the OpenCBM development team --
Michael Klein, et alii --) started to interleave disk reads with
parallel data sends in a parallel data transfer implementation. Is this
is not needed anymore since Markus Brenner created MNib which then
evolved to the OpenCBM parallel burst protocol.


Future development goals for µC based "cables" could become:
* using the parallel burst protocol for block oriented transfers
to speed up standard parallel transfers even more
* using the original 10 lines SpeedDOS parallel cable with
handshaking lines to free software from doing the handshaking
"by hand" over the IEC bus


As always, for Star Commander and OpenCBM as well, reliability has
precedence over transfer speed. And since compatibility between the
Commodore floppies and different PC LPT port implementations was and is
always an issue, transfer speed dropped more and more.

I can remember to times, where the parallel transfer protocol ran fine
with a sector interleave of 2 at my AMD 486-DX4-133 using two dedicated
BPP parallel port cards (bidirectional, Open Collector, also named PS/2
LTP) for the X1541 and the XP1541. Back then the Star Commander was a
bit too strictly optimised for speed which was reverted later, when the
read interleaved was automatically determined in Warp transfers.


Womo

--
------ to obtain more infos about me, look up the page ------
----- http://www.wmsr.de | wn0612 (at) d81 (dot) de -----
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: New 64Copy v4.43 out
Next Topic: Re: ANNC: xum1541 beta now available
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 11:33:25 EDT 2024

Total time taken to generate the page: 0.09229 seconds