Hi group,

I would like to transfer my old disks to the images. Since I would like 
to preserve as much as possible, I would like to go for the GCR based 
image format. What would you suggest as the most comfortable way of 
creating/managing such images... preferrably within a microsoft-free 
environment.

Thanks in advance.

Wolfgang Moser wrote:
> Hey Patryk,
>=20
> Patryk 'Silver Dream !' ?ogiewa wrote:
>=20
>> Hi group,
>>
>> I would like to transfer my old disks to the images. Since I would=20
>> like to preserve as much as possible, I would like to go for the GCR=20
>> based image format. What would you suggest as the most comfortable way=
=20
>> of creating/managing such images... preferrably within a=20
>> microsoft-free environment.
>=20
>=20
> I known also two readily available solutions, both
> written by Markus Brenner.
>=20
>   1. Create SixPack-ZIPCode images
>        * With the ZipCode Collection V2.0
>        * With Joe's Star Commander
>      then use Markus' tool S2G to convert the SixPacks
>      to the G64 image file format.
>=20
>   2. Use Markus' tool MNIB to directly create G64 files
>      from a parallel connected 1541 disk drive (XA1541
>      or XE1541 combined with a XP1541 cable).

I think I would like the second one better. But... I have the XM/XP=20
cable pair only. This, probably, won't do?

>=20
> Get both tools from:  http://markus.brenner.de/
>=20

OK.

>=20
> There's another more "ultimative" solution, that
> currently lacks appropriate software. Jens Sch=F6nfeld
> Catweasel MK3 adds _the_ ultimative floppy controller
> hardware to your Amiga/PC/Mac/(unix computer with PCI)
> that is able to read nearly any rotating magnetic
> media.

I have this controller. Didn't find anything _that_ ultimative in it=20
(except the SID socket :-) In this case, however, I believe the Amiga=20
built-in controller should be enough, if programmed properly. Have to=20
verify this though. Ah yes, _the ultimate_ for the pc machine, that is.

> But there's no software available, that is able to
> import G64 image files directly. At least I don't know
> any for at least PC based computers. I would expect
> such sort of software for Amiga systems, but actually
> I don't know anything about that.

I am currently a bit aside the Amiga's development, but I can't recall=20
anything too. Also the aminet doesn't show much about it.

> If such software does exist for the Amiga, then you
> might have the chance to use it on your PC, if you get
> WinUAE, an Amiga emulator, that natively supports the
> Catweasel MK3, that is plugged into your PC!

I would still use the Amiga, rather than UAE, espesially the LoseUAE=20
version ;-) but I am afraid no software for this purpose has been=20
written yet.

>=20
> Maybe I myself perhaps want to start developing a
> native Win32 command line tool for importing G64 disks
> for the Catweasel MK3, that I bought last years. But I'm
> not going to start a new project for at least the next
> six months, too much from other private projects...
>=20

Heh, the same here. First I need to finish the IDE64 filesystem support, =

then I have at least two more private projects in the queue.

SD!

Wolfgang Moser wrote:

> Hey Patryk,
> 
> Patryk 'Silver Dream !' ?ogiewa wrote:
> 
>> Hi group,
>>
>> I would like to transfer my old disks to the images. Since I would 
>> like to preserve as much as possible, I would like to go for the GCR 
>> based image format. What would you suggest as the most comfortable way 
>> of creating/managing such images... preferrably within a 
>> microsoft-free environment.
> 
> 
> I known also two readily available solutions, both
> written by Markus Brenner.
> 
>   1. Create SixPack-ZIPCode images
>        * With the ZipCode Collection V2.0
>        * With Joe's Star Commander
>      then use Markus' tool S2G to convert the SixPacks
>      to the G64 image file format.
> 
>   2. Use Markus' tool MNIB to directly create G64 files
>      from a parallel connected 1541 disk drive (XA1541
>      or XE1541 combined with a XP1541 cable).
> 
> Get both tools from:  http://markus.brenner.de/

Ooops! MNIB is also a msdos thingy... :-(

Even if I had a spare partition, msdos doesn't recognise even my 
hsrddrive properly and the dumb pc crap won't boot off the zip disk, eh...

Looks like one of the projects will have to be to extend the cbm4linux 
appropriately. This should be quite easily doable since AFAIR cbm4linux 
has one of the transfer modes, which does exactly raw GCR transfer.

Or has anyone worked on this already?!

Hi Patryk,

Patryk 'Silver Dream !' ?ogiewa wrote:
> Wolfgang Moser wrote:
>>   2. Use Markus' tool MNIB to directly create G64 files
>>      from a parallel connected 1541 disk drive (XA1541
>>      or XE1541 combined with a XP1541 cable).
>>
>> Get both tools from:  http://markus.brenner.de/
> 
> I think I would like the second one better. But... I have the XM/XP 
> cable pair only. This, probably, won't do?

As it looks to me, the XM1541 is currently not supported
by mnib. You should have a little (private) talk with
Markus. Maybe he wants to create a special version for
you where the XA1541 support is replaced by XM1541
support. This should be easily doable, since only the
outputs bits need to be inverted by a simple:

    outportb(baseport + ctrl,  value ^ 0x0F);

[It may not be that easy, if timing issues come accross]

> Ooops! MNIB is also a msdos thingy... :-(

That's true. Absolutely _full_ control over the whole
machine is needed for the very timing critical part of
the parallel burst transfers. To my knowledge, Markus
doesn't use any sort of synchronization for the burst
transfer parts. When this occurs, absolutely no other
task or interrupt must run, that would disturb the
burst mode byte receiver.

> Even if I had a spare partition, msdos doesn't recognise even my 
> hsrddrive properly and the dumb pc crap won't boot off the zip disk, eh...

Hmmmmm, but _that_ shouldn't be an unsolvable problem.
Maybe you shoudl try out, the MSDOS variant of
Win95/Win98 and make a little bootable CD out of it.
This OS is also able to recognize FAT32 formatted
partitions.

FreeDOS at   http://www.freedos.org   is also able to
directly support FAT32 partitions, see:

    http://www.freedos.org/freedos/news/technote/146.html

(don't be afraid about the discussed drfat32 driver, but
  only read the side note about freedos fat32 support).

> Looks like one of the projects will have to be to extend the cbm4linux 
> appropriately. This should be quite easily doable since AFAIR cbm4linux 
> has one of the transfer modes, which does exactly raw GCR transfer.
> 
> Or has anyone worked on this already?!

First: I don't expect cbm4linux to be able to grab as
   much information from the disk as mnib or Burstnibbler.
   I would compare it with Star Commander or SixPack
   ZipCode. There's no such software available, this is
   an assumption because of the architecture of cbm4linux.

But Michael Klein describes on his pages a 8K RAM
expansion for the 1541:
    http://www.lb.shuttle.de/puffin/8k1541/8k1541.html
I _think_ that he constructed it with one idea in his
mind:
  Constructing a RAMboard copier for cbm4linux.

Such a RAMboard copier would be very close to the
capabilities of a Burstnibbler, if not better. Maybe you
want to ask Michael directly, if he has plans to expand
his software by such a copier.

The dificulties may be, that every user (you) would have
to add such a RAM expansion to your floppy drive. Maybe
you want to buy Nicolas Welte's 6502-RAMROM expansion as
PCB-only, kit or assembled unit, which does this job by
simply plugging it into the 1541's processor socket:

     http://x1541.de/  --> Hardware_projects
     http://d81.de/6502RamRom   (my test report about it)


Womo

Hi Maciej, you wrote:
> Wolfgang Moser wrote:
> 
>>First: I don't expect cbm4linux to be able to grab as
>>   much information from the disk as mnib or Burstnibbler.
> 
> That's a false one IMO. With parallel connection cbm4linux should be able to
> grab all the data directly from the head - just like nibblers do, with
> handshakes over IEC connection. Even at the cost of bringing PC to a halt,
> but hey - it's a kernel driver and it is able to do it.

Please check out the sources of cbm4linux to be sure
about your opinion. I had a deep look into the sources
of Star Commander and I know, how most of the protocols
implemented by Joe do work (from an architectural point
of view). All his parallel protocols do need some
handshaking over the serial connection part (X/XE/XM/XA
cable).
Since cbm4linux runs under a multitasking OS and
especially because Michael Klein implemented the turbo
protocols very similar if not compatible to Joe ones, I
expect them to also use handshaking over the serial
connection part, if parallel transfers are used.

Consider the facts, what it means to implement a real
Burstnibbler style transfer protocol:

   - you need to read every GCR byte (one and a fraction
     of GCR nibbles) of a _whole_track_ of the disk in
     _one_consecutive_ run.
     This results in a block transfer size of at least
     7928 bytes (bad case, lower drive rotation speeds
     into account liek with the VMAX protection).

   - The transfer mustn't pause inbetween such a run,
     otherwise you would loose some bytes.

   - At the fastest speed zone of a CBM 1541 formatted
     disk, there arrives approximately every 26 cycles
     a new GCR byte from the controller register, that
     you have to read and transfer to the parallel cable's
     data port, e.g.:

       BVC .      ; waiting, 2 cycles at least
       CLV        ; 2 cycles
       LDA $1C01  ; reading GCR byte, 4 cycles
       STA $1801  ; parallel port, 4 cycles
       ;...
       ; calc or store or something 14 cycles
       ; could be used for calculating checksums
       ; or incorporating serial line signalling
       ;...

As you can see, you have some room (14 cycles) for e.g.
additionally signalling byte changes at the parallel cable
(via the serial cable part), but to implement a real
asynchronous protocol with perhaps incorporating a GCR
byte queue there's definetly not enough time.
Well, I know some tricks from speeders like Dolphin-DOS
or Prologic-DOS, that left out every second CLV/BVC-loop,
which may bring some more cycles, but I don't believe,
that this would be enough to let one create a _robust_
asynchronous Burstnibbler protocol with a fully
implemented GCR byte queue.
Consider the multitasking scheduling timing windows of the
PC's operating system, the 1541 drive would have to buffer
data for at least some milliseconds until the PC's receiver
routine is able to handle transferred bytes again.
40 Bytes would need to be queued (and dequeued) for each
millisecond.


Womo

Wolfgang Moser wrote:
> of view). All his parallel protocols do need some
> handshaking over the serial connection part (X/XE/XM/XA
> cable).

This is true because parallel extension simply lacks handshake lines (it
should have 10 wires, not 8; burst cables for C64 have 10 wires).
Unfortunately PC LPT port plainly sucks. If it only was full 8255-like
without ECP/EPP crap.

> Since cbm4linux runs under a multitasking OS and
> especially because Michael Klein implemented the turbo
> protocols very similar if not compatible to Joe ones, I
> expect them to also use handshaking over the serial
> connection part, if parallel transfers are used.

True, but the reason is in cable hardware itself, not a multitasking host OS.

>    - you need to read every GCR byte (one and a fraction
>      of GCR nibbles) of a _whole_track_ of the disk in
>      _one_consecutive_ run.
>      This results in a block transfer size of at least
>      7928 bytes (bad case, lower drive rotation speeds
>      into account liek with the VMAX protection).

~8000 byte buffer on host side is nothing.

>    - The transfer mustn't pause inbetween such a run,
>      otherwise you would loose some bytes.

Like above - ~8000 bytes buffer is nothing and there's time to pause between
changing tracks and time to resync when head waits for the first sector to
arrive.

>        BVC .      ; waiting, 2 cycles at least
>        CLV        ; 2 cycles
>        LDA $1C01  ; reading GCR byte, 4 cycles
>        STA $1801  ; parallel port, 4 cycles
          LDA $1800
		  EOR #something   ; toggle line so PC knows that new data is ready
		  STA $1800
		  ...              ; continue
>        ;...
>        ; calc or store or something 14 cycles
>        ; could be used for calculating checksums
There's no time to calculate checksum. Your hardware either works or not :)

>        ; or incorporating serial line signalling
Toggling a line to give PC hint that new data is there is enough. PC doesn't
need to confirm that it has received it because there's nothing you can do
with such information in the drive. You can only repeat transmission of a
whole track.

> Consider the multitasking scheduling timing windows of the
> PC's operating system, the 1541 drive would have to buffer

It's a kernel driver. It can halt other tasks. It can wait in busy loop for
incoming ~8000 bytes, then call schedule(). When control returns to the driver
- head in the drive will be in the new position and the driver can resynchronize
with the drive.

> I forgot to point this out in a conclusion. To my
> knowledge, the Burstnibbler series of copy programs
> do _no_ real handshaking, only some sort of
> signalling.

I think I should explain exactly what kind of programs I'm talking about.
There are two kinds of parallel cables - one with 8 wires that has only data
lines and another one with 10 wires where two extra are connected to /FLAG2
and /PC2 on user port and CA1/2 (? whatever those inputs are called) on VIA.
With 8 wires you have to synchronize/handshake using IEC.
With 10 wires you have hardware handshake - there's an impulse from VIA on
each store to $1801 that can be detected in $dd0d, bit 4. And it works in a
very similar way in the other direction. Like:

1541:                               C64:
-   bvc -                               lda #$10
    lda $1c01                       -   bit $dd0d
	sta $1801                           beq -
	                                    lda $dd01

> Okay, this would work somehow (blocking the Linux kernel
> as a whole), but that would be something nobody can
> really want, since I expect thousands of bad side
> effects to the Linux kernel then (timers, IDE timout
> counters, LAN driver effects)...

True, but it would block only for time of a single track transfer - one disk
revolution.
It is simply my intuition that it should work as I don't really see anything
that could prevent it. Ok, there is one thing - interrupts from other PC
hardware.

> If you want to do such things, do it under an
> operating system, that was built for such things,

Yuck! :)

ytm

-- 
Najlepsza sygnatura to brak sygnatury.

Hi Maciej,

although we both hardly defend our positions
without that I see, that we would come together,
here are some more aspects:

Maciej Witkowiak wrote:
> Wolfgang Moser wrote:
> 
>>of view). All his parallel protocols do need some
>>handshaking over the serial connection part (X/XE/XM/XA
>>cable).
> 
> This is true because parallel extension simply lacks handshake lines (it
> should have 10 wires, not 8; burst cables for C64 have 10 wires).
> Unfortunately PC LPT port plainly sucks. If it only was full 8255-like
> without ECP/EPP crap.

Well, the EPP and ECP already incorporate hardware
handshaking. A more universable variant with 4
handshake lines for true bidirectional transfers.
This cannot easily support by the VIA/CIA chips
without further software control.
Additionally the ECP implementation carries a 16
byte FIFO byte queue (hardware) with it, a big
improvement in my opinion.

But... true hardwware handshaking or not, that
doesn't change anything to the real questions, where
the multitasking aspects come into account.

>>Since cbm4linux runs under a multitasking OS and
>>especially because Michael Klein implemented the turbo
> 
> True, but the reason is in cable hardware itself, not a multitasking host OS.

That seems to be the point, where our both opinions
(I woulnd't call it "facts" yet) differ at most.

>>   - you need to read every GCR byte (one and a fraction
>>     of GCR nibbles) of a _whole_track_ of the disk in
>>     _one_consecutive_ run.
> 
> ~8000 byte buffer on host side is nothing.

But! Just imagine that you don't want to hardly
break the multitasking by halting the Linux kernal
with the driver. Then you don't get the chance to
fill that host side buffer.

>>Consider the multitasking scheduling timing windows of the
>>PC's operating system, the 1541 drive would have to buffer
> 
> It's a kernel driver. It can halt other tasks. It can wait in busy loop for
> incoming ~8000 bytes, then call schedule(). When control returns to the driver
> - head in the drive will be in the new position and the driver can resynchronize
> with the drive.

Waiting for all these 8000 bytes with 26 cycles each
would block the kernal for at least 200ms!
Don't you think, that such a long block, would
conflict with running LAN communication, other timing
applications, USB transfers (interrupted transfers)
and especially Audio/Video???

A block of 200ms is absolutely undiscussible for
any multitasking system that needs to do something
else.


> True, but it would block only for time of a single track transfer - one disk
> revolution.

"Only" means 200ms here as shown above, please
consider that.


> It is simply my intuition that it should work as I don't really see anything
> that could prevent it. Ok, there is one thing - interrupts from other PC
> hardware.

That means nearly any hardware card and communication
devices.

>>If you want to do such things, do it under an
>>operating system, that was built for such things,
> 
> 
> Yuck! :)

Why not? Get the tool/hardware/software, that is best
designed for the things you want to do.

If it comes to plain (sometimes stupid) hardcore
applications, DOS is the OS of choice. Maybe QNX or
microcontroller based applications.


Womo

Wolfgang Moser wrote:

[...]

> 
>> Ooops! MNIB is also a msdos thingy... :-(
>  
[...]
> 
>> Even if I had a spare partition, msdos doesn't recognise even my 
>> hsrddrive properly and the dumb pc crap won't boot off the zip disk, 
>> eh...
> 
> 
> Hmmmmm, but _that_ shouldn't be an unsolvable problem.

You are absolutely right. The only problem that seems to be unsolvable 
is that even thinking of fiddling with the pc/msdos combinations, moods 
and peculiarities makes me feel sick ;-)

> Maybe you shoudl try out, the MSDOS variant of
> Win95/Win98 and make a little bootable CD out of it.

That might be an option. But since I have never tried it, I am afraid I 
would lose some enormous amounts of time and energy before it would 
start to work. Of course I have nothing against doing and learning some 
new things, but since I have no plans of becoming MSCSE and it would be 
for _this, one, particular case only_, I don't feel like starting there.

I think, I would rather get a SCSI controler, which allows SCSI booting 
and plug in the Jaz, MO or SyQuest drive to it. This should do the 
trick, I suppose. I would still prefer getting around it with my current 
setup though.

>> Looks like one of the projects will have to be to extend the cbm4linux 
>> appropriately. This should be quite easily doable since AFAIR 
>> cbm4linux has one of the transfer modes, which does exactly raw GCR 
>> transfer.
>>
>> Or has anyone worked on this already?!
> 
> 
> First: I don't expect cbm4linux to be able to grab as
>   much information from the disk as mnib or Burstnibbler.
>   I would compare it with Star Commander or SixPack
>   ZipCode. There's no such software available, this is
>   an assumption because of the architecture of cbm4linux.

There were some comments from ytm on that and I also don't think it is a 
valid assumption. Anyway, doing it might not be as straightforward as I 
initially thought.

> But Michael Klein describes on his pages a 8K RAM
> expansion for the 1541:
>    http://www.lb.shuttle.de/puffin/8k1541/8k1541.html
> I _think_ that he constructed it with one idea in his
> mind:
>  Constructing a RAMboard copier for cbm4linux.

Would be _the_ thing I am looking for! There is a sentence:

"I hope that there will be a .g64 ripper for cbm4linux soon." on those 
pages.

> 
> Such a RAMboard copier would be very close to the
> capabilities of a Burstnibbler, if not better. Maybe you
> want to ask Michael directly, if he has plans to expand
> his software by such a copier.
> 
> The dificulties may be, that every user (you) would have
> to add such a RAM expansion to your floppy drive. Maybe
> you want to buy Nicolas Welte's 6502-RAMROM expansion as
> PCB-only, kit or assembled unit, which does this job by
> simply plugging it into the 1541's processor socket:

That's not a problem. I have already a RAM expansion in my drive. I also 
recreated the DolphinDOS V2 and (partially) V3 hardware from scratch.

http://blacha.srebrnysen.com/~silverdr/DD2.png

Have even some proto PCBs left.

Even if reconfiguring the mapping of the extension would be (for some 
reason) required, it can be done easily. And I prefer spending time on 
this, rather than fighting with mswhatever... ;-)

Wolfgang Moser wrote:
I know that we won't come to a common opinion, but the exchange of arguments
is too tempting :)

> Waiting for all these 8000 bytes with 26 cycles each
> would block the kernal for at least 200ms!
> Don't you think, that such a long block, would
> conflict with running LAN communication, other timing
> applications, USB transfers (interrupted transfers)
> and especially Audio/Video???

They must be interrupt driven one way or another. On SMP the other CPU will
handle them. On single-CPU system there is a potential danger, but I wouldn't
exaggerate it. With taskswitching disabled only 'upper halves' of the
interrupt routines will be called. These do whatever it is required to handle
situation when interrupts are coming too fast (like when 'bottom half' wasn't
calledi yet) by halting transfer if possible.

Old NVidia drivers halted Linux during X11 startup for more than 2secs (for
unknown reason). Completely halted - no interrupts no nothing, no harm (except
my anger) done.

> A block of 200ms is absolutely undiscussible for
> any multitasking system that needs to do something
> else.

A quick google search showed me that standard Linux timeslice for a process is
just about 200ms which is quite appropriate for our task.
http://www.theinquirer.net/?article=5104
According to Linux-Kernel mailing list in the newest 2.6.0 a nice 0 task gets
102ms.

>> It is simply my intuition that it should work as I don't really see anything
>> that could prevent it. Ok, there is one thing - interrupts from other PC
>> hardware.
> That means nearly any hardware card and communication
> devices.

.... which often have own hardware buffers/FIFOs and a way to halt transfer.
Apart from old 1-byte buffer RS-232 stuff I don't think anything would be
lost. (again only my intuition).
Anyway, high-speed GCR 1541 transfer shouldn't be done on a server that is
streaming audio/video to LAN and burning a CD at the same time.
They can put a warning message about it :).

>> Yuck! :)
> 
> Why not? Get the tool/hardware/software, that is best
> designed for the things you want to do.

Because I need additional box with monitor and keyboard then and I need time
to boot it.
A dedicated uC or card would be better. (always, for most tasks :)

> If it comes to plain (sometimes stupid) hardcore
> applications, DOS is the OS of choice. Maybe QNX or

It is - when it is too complicated for uC and it just has to run without human
control.

ytm

-- 
Najlepsza sygnatura to brak sygnatury.

Patryk 'Silver Dream !' �ogiewa wrote:
> Would be _the_ thing I am looking for! There is a sentence:
> 
> "I hope that there will be a .g64 ripper for cbm4linux soon." on those 
> pages.

If someone is looking, there is a ready for use, GPLed code for drive and C64:
ftp://ftp.elysium.pl/gnu-generation/YTM/ddbb.src.gz

It is a complete solution. AFAIR you just send 'M-E',<addr>,#tracknum to the
drive and after a simple synchronization fetch the bytes. Similar with
writing.

ytm

-- 
Najlepsza sygnatura to brak sygnatury.

On 30 Aug 2003 15:12:42 GMT, Maciej Witkowiak
<ytm@elysium.pl.andremowe.me> wrote:
>> Why not? Get the tool/hardware/software, that is best
>> designed for the things you want to do.
>Because I need additional box with monitor and keyboard then and I need time
>to boot it.
>A dedicated uC or card would be better. (always, for most tasks :)

You guys are getting back to a discussion we already had. Look at the
above threads in this newsgroup:

1) Commodore serial bus from Windows/Linux?
2) Commodore serial bus access from Multitasking OS's

You will see that "Kroko" has already created a device to do this:

http://www.bitcity.de/1541%20Serial%20Interface.htm

I am sure he would love some help with debugging and fleshing out the
user interface. My AVR programming skills are not up to par yet, but I
hope to be able to contribute to this project one of these days.

/*Raj*/

Hello,

Patryk 'Silver Dream !' ?ogiewa wrote:
>> The dificulties may be, that every user (you) would have
>> to add such a RAM expansion to your floppy drive. Maybe
>> you want to buy Nicolas Welte's 6502-RAMROM expansion as
>> PCB-only, kit or assembled unit, which does this job by
>> simply plugging it into the 1541's processor socket:
> 
> 
> That's not a problem. I have already a RAM expansion in my drive. I also 
> recreated the DolphinDOS V2 and (partially) V3 hardware from scratch.

A very useful extension as all the different speeders
showed. And probably part of the most portable and
'ultimative' GCR transfer solution, since the transfer
can even be done over serial lines.

> http://blacha.srebrnysen.com/~silverdr/DD2.png

Oh, well done. Nicolas already did something similar with
his 6502-RamRom. I myself created a new hardware the last
13 months, mainly emulating the Professional-DOS speeder.
Although most of the first developing phase is done and
beta test board reached my tester I'm currently lacking
with documentation and website updates.

An disadvantage of Nicolas and my board is and/or will
be, that we don't support parallel cable chips directly
at our PCBs. Therefore Dolphin-DOS 3.0 and other speeder
incorporating extra parallel cable chips (6821 or other)
aren't supported directly.

> Even if reconfiguring the mapping of the extension would be (for some 
> reason) required, it can be done easily. And I prefer spending time on 
> this, rather than fighting with mswhatever... ;-)

Hmmm, if you used reprogrammable logic like GALs or
CPLDs (no, I don't mean FGPAs here), that would have
been a little bit simpler. Nicolas and I did it that
way.


Womo

Hi,

Maciej Witkowiak wrote:
> Patryk 'Silver Dream !' �ogiewa wrote:
> 
>>Would be _the_ thing I am looking for! There is a sentence:
>>
>>"I hope that there will be a .g64 ripper for cbm4linux soon." on those 
>>pages.
> 
> 
> If someone is looking, there is a ready for use, GPLed code for drive and C64:
> ftp://ftp.elysium.pl/gnu-generation/YTM/ddbb.src.gz
> 
> It is a complete solution. AFAIR you just send 'M-E',<addr>,#tracknum to the
> drive and after a simple synchronization fetch the bytes. Similar with
> writing.

But his is a burst copier again, isn't it. Patryk wished
Michael would implement a RAMboard copier. Maybe other
code snippets with GPL copyrights can be found.


Womo

Hello,

Maciej Witkowiak wrote:
> Wolfgang Moser wrote:
> I know that we won't come to a common opinion, but the exchange of arguments
> is too tempting :)

:-)) If it doesn't take too much time. Because
nothing is less productive than discussing all
the time withoug actually doing something.

>>Waiting for all these 8000 bytes with 26 cycles each
>>would block the kernal for at least 200ms!
> 
> They must be interrupt driven one way or another. On SMP the other CPU will

On typical PC design, there are some other side
effects you would have to care about. E.g. port
accesses (inportb/outportb): Every port access
to old derived hardware interfaces (ISA based)
like the parallel port takes at least one 1�s
because of waitstates.

Now take an example of such a IRQ driven Burstnibbler
receiver routine. Let's assume, that the interrupt
is externally driven by a signalling line over the
serial bus:

The drive stores a value to the parallel cable and
signals a high/low/high sequence to the right line
of the IEC cable.

The PC has to acnowledge the IRQ, he needs to read
the Status register of the LPT port and two accesses
to the IRQ controller (I believe). Another access to
the LPT data port is needed to get the value. Then
the EOI has to be programmed by another access to
the IRQ controller.
I count at least 5 IO port accesses here (5�s, if
I remembered right into PC IRQ programming). This all
happens every 26 1541 CPU cycles, mroe or less every
26�s.

> Old NVidia drivers halted Linux during X11 startup for more than 2secs (for
> unknown reason). Completely halted - no interrupts no nothing, no harm (except
> my anger) done.

Ouch! They did? And nothing critical happened? Wow.

>>A block of 200ms is absolutely undiscussible for
>>any multitasking system that needs to do something
>>else.
> 
> A quick google search showed me that standard Linux timeslice for a process is
> just about 200ms which is quite appropriate for our task.
> http://www.theinquirer.net/?article=5104
> According to Linux-Kernel mailing list in the newest 2.6.0 a nice 0 task gets
> 102ms.

Uuupps... it seems, that I was wrong. If this is
really correct, then a 200ms block seems to be not
as critical as I thought always...


Now there's only one open issue, that I think, we
cannot clarify out by discussing only. If such a
Burstnibbler copier is possible and if it really is
possible under multitasking OS, then how does it feel?

Knowing, that it definetly can be done is one thing.
Reliability and uncommon sideeffects (bucking or
short hangups), conclusively the user feeling is
another story.



Womo

Hi Raj,

> You guys are getting back to a discussion we already had. Look at the
> above threads in this newsgroup:
> 1) Commodore serial bus from Windows/Linux?
> 2) Commodore serial bus access from Multitasking OS's

you know, that I know these threads very good.
Because I made the experience, that many users
don't want to Google all the time and because
they especially don't read common C64 FAQs I
started repeating basic theories about transfer
solutions and their possibilities...

Always searching for people that might have some
wierd ideas about better solutions. Hardwareless,
reliable, able to transfer copy protections...


Womo

Wolfgang Moser wrote:
>> If someone is looking, there is a ready for use, GPLed code for drive and C64:
>> ftp://ftp.elysium.pl/gnu-generation/YTM/ddbb.src.gz
>> 
>> It is a complete solution. AFAIR you just send 'M-E',<addr>,#tracknum to the
>> drive and after a simple synchronization fetch the bytes. Similar with
>> writing.
> 
> But his is a burst copier again, isn't it. Patryk wished
> Michael would implement a RAMboard copier. Maybe other
> code snippets with GPL copyrights can be found.

What's the difference? Instead of pushing track data to $1c01 you store it to
RAM. The missing thing here is a transfer routine that will work over IEC when
whole track has been read - these pieces are already there in cbm4linux.

ytm

-- 
Najlepsza sygnatura to brak sygnatury.

Hi Kroko!

On Sun, 31 Aug 2003 00:46:59 +0200, Kroko <Kroko@nil.com> wrote:
>My device is now transfering raw gcr data to the interface which is
>then forwarded to any serial receiver at 128kbps. The transfer time
>for a GCR disk image with 35 Tracks is currently 61 seconds.

So you are alive out there! :)

Wow! That IS impressive and GREAT news! What modifications have you
made? Is the source code on your web site current? 

When you get a chance, would you please post your source code for the
Windows client? Maybe we can get some more people involved with this.
I have had to but my AVR projects on hold... to busy patching security
holes in Microsoft operating systems. haha!

Hopefully one of these days we will all have your device instead of
the DOS based X1541 series cables. Have you thought of a name for it
yet?

/*Raj*/

>So you are alive out there! :)

Sure i am :-)

>Wow! That IS impressive and GREAT news! What modifications have you
>made? Is the source code on your web site current? 

I have implemented a new fastloader. It is working, but the code on my
site is still the old version. I need to work on this stuff a bit more
before i can put it on the site. Especially error checking is not yet
implemented in a proper way. Same for retry etc ...I couldnt believe
that a controller based solution should be slower than the cable
transfers. So i spent some time in making things faster. But I don't
think I will be able to make it faster than about 60 seconds, without
modifying the drive or using custom cables. I guess 1 minute per disk
will be acceptable for most people.

>When you get a chance, would you please post your source code for the
>Windows client? Maybe we can get some more people involved with this.
>I have had to but my AVR projects on hold... to busy patching security
>holes in Microsoft operating systems. haha!

At the moment the client doesn't do a lot more than send the
fastloader to the drive, send "read disk" to the interface
and receive GCR data. The client is not a real problem. Its more that
I have to think about a good way to communicate with the interface.
Its more or less experimental at the moment. And its difficult to let
people develop a frontend for something that is still changing. I
would suggest, the frontend is the very last thing we should
concentrate on. I am also still thinking about changing the interfaces
controller and clock speed etc.

>Hopefully one of these days we will all have your device instead of
>the DOS based X1541 series cables. Have you thought of a name for it
>yet?

I don't want to replace these cables. Lots of things can never be done
with a microcontroller device. What i really want it to be is:

- a fast and reliable way to transfer disks to the pc
- a virtual 1541 
- cheap 

Kroko.

Wolfgang Moser wrote:

[...]

> Now there's only one open issue, that I think, we
> cannot clarify out by discussing only. If such a
> Burstnibbler copier is possible and if it really is
> possible under multitasking OS, then how does it feel?
> 
> Knowing, that it definetly can be done is one thing.
> Reliability and uncommon sideeffects (bucking or
> short hangups),

Now, I guess, you hit the right string... ;-)

Maciej Witkowiak wrote:

> Wolfgang Moser wrote:
> 
>>>If someone is looking, there is a ready for use, GPLed code for drive and C64:
>>>ftp://ftp.elysium.pl/gnu-generation/YTM/ddbb.src.gz
>>>
>>>It is a complete solution. AFAIR you just send 'M-E',<addr>,#tracknum to the
>>>drive and after a simple synchronization fetch the bytes. Similar with
>>>writing.
>>
>>But his is a burst copier again, isn't it. Patryk wished
>>Michael would implement a RAMboard copier. Maybe other
>>code snippets with GPL copyrights can be found.
> 
> 
> What's the difference? Instead of pushing track data to $1c01 you store it to
> RAM. The missing thing here is a transfer routine that will work over IEC when
> whole track has been read - these pieces are already there in cbm4linux.
> 
Hm. I don't think I can take another project on currently, but it would 
be really GREAT if someone could make a good use of it!

Wolfgang Moser wrote:

> 
> Oh, well done. Nicolas already did something similar with
> his 6502-RamRom. I myself created a new hardware the last
> 13 months, mainly emulating the Professional-DOS speeder.
> Although most of the first developing phase is done and
> beta test board reached my tester I'm currently lacking
> with documentation and website updates.
> 
> An disadvantage of Nicolas and my board is and/or will
> be, that we don't support parallel cable chips directly
> at our PCBs. Therefore Dolphin-DOS 3.0 and other speeder
> incorporating extra parallel cable chips (6821 or other)
> aren't supported directly.

I know. I had an e-mail exchange with Nicolas about that some time ago. 
That was one of the major reasons why I started recreating the DD3 hardware.

> 
>> Even if reconfiguring the mapping of the extension would be (for some 
>> reason) required, it can be done easily. And I prefer spending time on 
>> this, rather than fighting with mswhatever... ;-)
> 
> 
> Hmmm, if you used reprogrammable logic like GALs or
> CPLDs (no, I don't mean FGPAs here), that would have
> been a little bit simpler. Nicolas and I did it that
> way.

Sure. I also think of similar approach in the DD3 recreation project 
(currently on hold though).

Anyway, RAM expansion is not a problem here. Just we have to make a good 
use of it ;-)

Patryk 'Silver Dream !' ?ogiewa wrote:

>> Maybe you shoudl try out, the MSDOS variant of
>> Win95/Win98 and make a little bootable CD out of it.
> 
> 
> That might be an option. But since I have never tried it, I am afraid I
> would lose some enormous amounts of time and energy before it would
> start to work. Of course I have nothing against doing and learning some
> new things, but since I have no plans of becoming MSCSE and it would be
> for _this, one, particular case only_, I don't feel like starting there.

You can boot Win98-DOS from a f*cking floppy. Go to anybody who has a
Win98 computer, start it in DOS mode (press F8 as soon as boot starts,
then select option no. 5 "MS-DOS prompt only".) or open a DOS prompt
Window from inside Windows 98.

Then insert a floppy disk into the drive, type FORMAT A: into DOS
followed by SYS A: after FORMAT finishes.

lo and behold, you got a bootable floppy now.

Copy cwsdpmi.exe (it's all over the net) and mnib.exe to the floppy.

Boot your computer from that floppy and run mnib from there, and if you
find that can't access your hard drive(s) just store the result onto the
floppy. You'll have to reboot when the floppy gets full, but it will
work just fine.

If your computer won't boot from the floppy (most will), you need to
change exactly one setting in the BIOS setup to enable trying to boot
from A first, then C after that.

(I haven't tried it but I see no reason why it shouldn't work.)

-- 

Linards Ticmanis

 The Master said, "The business of laying on the colors follows the
preparation of the plain ground."

Linards,

On Mon, 01 Sep 2003 00:53:44 +0200, Linards Ticmanis
<ticmanis@coli.uni-sb.de> wrote:
>You can boot Win98-DOS from a f*cking floppy.

Keep in mind that many PC's and laptops manufactured today do *not*
have floppy drives.

/*Raj*/

RajW wrote:

> Keep in mind that many PC's and laptops manufactured today do *not*
> have floppy drives.

On a laptop, fine, space is very limited. But a desktop or tower should
have a floppy drive IMHO. They're really cheap by now, and still often
useful, if you don't want to bother with burning a CD.

-- 

Linards Ticmanis

 The Master said, "The business of laying on the colors follows the
preparation of the plain ground."

Linards Ticmanis wrote:
> Patryk 'Silver Dream !' ?ogiewa wrote:
> 
> 
>>>Maybe you shoudl try out, the MSDOS variant of
>>>Win95/Win98 and make a little bootable CD out of it.
>>
>>
>>That might be an option. But since I have never tried it, I am afraid I
>>would lose some enormous amounts of time and energy before it would
>>start to work. Of course I have nothing against doing and learning some
>>new things, but since I have no plans of becoming MSCSE and it would be
>>for _this, one, particular case only_, I don't feel like starting there.
> 
> 
> You can boot Win98-DOS from a f*cking floppy.

I have one f*cking 3.5" floppy drive, it gets connected via USB... 
Bought it to share between the laptop and the pc. Until now, I never 
used it yet after checking that it actually works. I am afraid this 
won't do the trick as the pc won't boot off it. And (as I wrote earlier) 
if I have to extend the hardware, then its all fine. I can plug in the 
floppy or a bootable SCSI controller. Still the matter is not only to 
get it done. I wouldn't mind getting whatever to boot the msdos then. 
Could even buy another (small enough) harddrive for msdos. The matter, 
however is:

a) to get this done
b) to get this done preferably without hardware changes
c) to get this done even more preferrably without resorting to msdos
d) to extend the abilities of the current solutions and the freedom of 
our choice.

I don't know how the others, but I don't like to shutdown the modern 
unixalike and boot some legacy to get one (1) thing done. Not to mention 
the fact that I currently have no way of booting the legacy. Of course 
if there would be no other way, then it is a different story. I wouldn't 
complain that much then ;-)

But I think that (partially) out of this discussion, a very good 
extension to cbm4linux might get eventually born. I can afford waiting 
some time if it brings progress to this. If not, I will boot msdos some 
day. One way or another.

> Go to anybody who has a
> Win98 computer, start it in DOS mode (press F8 as soon as boot starts,
> then select option no. 5 "MS-DOS prompt only".) or open a DOS prompt
> Window from inside Windows 98.
> 
> Then insert a floppy disk into the drive, type FORMAT A: into DOS
> followed by SYS A: after FORMAT finishes.
> 
> lo and behold, you got a bootable floppy now.
> 
> Copy cwsdpmi.exe (it's all over the net) and mnib.exe to the floppy.
> 
> Boot your computer from that floppy and run mnib from there, and if you
> find that can't access your hard drive(s) just store the result onto the
> floppy. You'll have to reboot when the floppy gets full, but it will
> work just fine.
> 
> If your computer won't boot from the floppy (most will), you need to
> change exactly one setting in the BIOS setup to enable trying to boot
> from A first, then C after that.
> 
> (I haven't tried it but I see no reason why it shouldn't work.)
> 

Because the pc doesn't like my floppy on boot, it doesn't like the ZIP 
floppy on boot, it can boot off the CD (yes, the pc makers made 
eventually that breakthrough some years ago!) bu if I boot the windows 
installer off CD, it doesn't like my harddrive and says it is some 8G 
(while it is 160G capacity), and happily wants to format it. I can boot 
the VirtualPC off the USB floppy (or floppy image) on the MacOSX laptop, 
and have a working DOS environment, but I don't have the LPT there, and 
of course, even if I had, it wouldn't work under multitasking. The same 
goes for dosemu on the pc.

Creating a bootable DOS CD with e.g. USB floppy support to store the 
data, would be an option but I wrote about this earlier.

There is one alternative, that I find "geeky" enough to be interesting 
(regardless of the msdos legacy). It would be to boot msdos diskless via 
network. I have set a couple of diskless unixalike clients up to boot 
this way but never tried it with msdos. Who knows...

Anyway, thank you for your remarks.

Wolfgang Moser schrieb:

>   2. Use Markus' tool MNIB to directly create G64 files
>      from a parallel connected 1541 disk drive (XA1541
>      or XE1541 combined with a XP1541 cable).

Does that work with my XA/XP1571 too?

Does it mean the original California Games and Winter Games (with the
really fast fastloader) would work as G64 with an Emulater, or even if I
transfer it back to the 1571?

Hi Womo !

>PS: I myself am running around this perfect GCR-copier task
>for 6 years now. Many things improved, but I didn't see the
>big wonder since then.

Is there any place, where I can read about what the problem is with
GCR copy progs. I would be very interested in reading more about it.
Or can you briefly explain it to me, please.

Kroko.

Hi Kroko,

Kroko wrote:
>>PS: I myself am running around this perfect GCR-copier task
>>for 6 years now. Many things improved, but I didn't see the
>>big wonder since then.
> 
> Is there any place, where I can read about what the problem is with

I don't have all of the handy, here're some:
   http://members.tripod.com/whdloadrules/rob_northen_interview.html
and from Markus page:
   http://markus.brenner.de/mnib/vmaxtech.txt
   http://markus.brenner.de/mnib/burstn19.txt
   http://markus.brenner.de/mnib/rapidlok.txt
   http://markus.brenner.de/binary/vcf3.pdf

> GCR copy progs. I would be very interested in reading more about it.
> Or can you briefly explain it to me, please.

When I discuss "the worst scenario" with myself, I think
of a theoretical copy protection, that can definetly not
be created with a (unmodified) CBM 1541 floppy drive
mechanic. I'm unable to tell you exactly, how it would
work,
   * if it changes the speed zone within a known position
     inmid of a sector or track
   * if it seeks from one track to another at a known
     position, while following this coil track and reading
     bits from it all the time
   * if it tries to write a known physical position of the
     disk, that doesn't contain magnetisable material, so
     that if read back, nothing happened to this physical
     location but neighbored parts only
it's only a brain construction to think about.

I can't explain, waht exactly the problem is, because I
don't know exactly what the problem is. I would have to
known all existing 1541 floppy disks or at least one
piece of each 1541 copy protection ever created.
But I want more, I want to create (not actually writing
a software, but finding a theoretical way to go) a copier,
that is able to copy 1541 disks with protections, that may
probably invented in the future, because the 1541 would be
able to read such future protected disks.

To understand my sentence above somewhat better, you could
read the page:  http://d81.de/R.I.P/Xcables.shtml
and especially the quoted mail from me to Joe Forster.
It was Aug/1997, when I asked for GCR support for The Star
Commander. On 2002-07-07, this became true with SC 0.83.03
beta. That was the "improvement", I was talking from. Well,
Markus Brenner created s2g before and many may know the
COM1541 utility from Miha Peternel's C64S emulator
package, which already was able to transfer GCR data
(serial nibbler concept like with Turbo Nibbler 4.0) into
the so named NewD64 format (similar to G64, but
proprietary).

But the wonder would be a real oldschool magnetic
recording expert, who creates a very capable and cheap
hardware (analogous high speed sampling, USB interface)
and a pretty portable Java application, that makes it
possible to transfer each known and unknown rotating
magnetic media into a virtual representation (this would
require a high level of understanding of mathematical
statistics).

The Catweasel MK3 was and is a very huge step into this
direction ("only" digital), but it still lacks some
HyperDuper-Software. Maybe, within the next 5 years I
could find the time to write such a software for the
Catweasel (Java GUI app), like I did with 1581-Copy for
the last 5 years (DOS only, no GUI, no copy protection,
MFM, directly at the hardware registers).


Womo

"Martin Brunner" <mbrunner@mcnon.com> wrote in message
news:bj04o7$e08c3$1@ID-819.news.uni-berlin.de...
> Wolfgang Moser schrieb:
>
> >   2. Use Markus' tool MNIB to directly create G64 files
> >      from a parallel connected 1541 disk drive (XA1541
> >      or XE1541 combined with a XP1541 cable).
>
> Does that work with my XA/XP1571 too?
>
> Does it mean the original California Games and Winter Games (with the
> really fast fastloader) would work as G64 with an Emulater, or even if I
> transfer it back to the 1571?

Yes

Actually, this does work with SG2 and WG, as I did it a while ago.

"Christian Link" <C.LinkSPAMBLOCK@GMX.NET> wrote in message
news:pu67lvckeqfcn7ccgd363d87dv23h4fufp@4ax.com...
> On Mon, 01 Sep 2003 20:56:07 +0200, Martin Brunner
> <mbrunner@mcnon.com> wrote:
>
> >Does it mean the original California Games and Winter Games (with the
> >really fast fastloader) would work as G64 with an Emulater, or even if I
>
> Haven't tried California Games (only have the tape original, not the
> disk), but my two Vorpal originals of Winter Games do work from MNIBed
> G64s indeed. I figure it won't be different with California Games,
> which ought to use that Vorpal version as wel.
>
> >transfer it back to the 1571?
>
> No chance, unless you find a way to copy them back in the first place.
> The only way of doing so, as for the moment, would be sixpacking them
> and transferring them back. Then again, _if_ sixpacking would be
> suitable for reproducing that particular copy-protection, you could
> have transferred the whole game eons ago already, without MNIB, but by
> using sixpacks for the C64=>PC transfer as well. And this is exactly
> what did _not_ work in these cases, as far as I remember.
>
> Chris

Cool, now I have something new to think about :-)

Kroko.

Christian Link wrote:

> Haven't tried California Games (only have the tape original, not the
> disk), but my two Vorpal originals of Winter Games do work from MNIBed
> G64s indeed. I figure it won't be different with California Games,
> which ought to use that Vorpal version as wel.

By the way... is there a site or archive devoted to MNIBed originals?

(xpost2 csc, cec; fup2 csc)
-- 

Linards Ticmanis

 The Master said, "The business of laying on the colors follows the
preparation of the plain ground."

Hi, Peter,

On Mon, 1 Sep 2003 17:40:55 -0400, "Peter Rittwage"
<peterng@rittwage.com> wrote:

>Actually, this does work with SG2 and WG, as I did it a while ago.

But you're American, aren't you? It's not absolutely clear if your
versions used the same loading systems as our European ones, of which
there sometimes were several _per game_ even: e. g. the Rushware
version of SG2 uses a simple read error protection, while the US Gold
version did use Vorpal. Sure, in this case both would work (the first
one even from D64s + error info), but this is rather the exception
than the rule ;-) .

Greetings,
                       Chris.

Hi, Linards,

On Mon, 01 Sep 2003 23:50:36 +0200, Linards Ticmanis
<ticmanis@coli.uni-sb.de> wrote:

>> Haven't tried California Games (only have the tape original, not the
>> disk), but my two Vorpal originals of Winter Games do work from MNIBed
>> G64s indeed. I figure it won't be different with California Games,
>> which ought to use that Vorpal version as wel.
>
>By the way... is there a site or archive devoted to MNIBed originals?

Not that I knew of. But as you probably know, Arnold has an
"Originals" directory supposedly containing quite a lot of them
(already converted to G64, though - just in case your emphasis would
be on *.NIB files).

Greetings,
                     Chris.