XUM -- parallel cable support -- Jiffy Support

[Thomas Winkler]

HI 

Currently the parallel cable support is limited to a few OpenCBM Tools:

• D64COPY
• CBMCOPY

All things in CBMCTRL.EXE are done with slow serial IEC functions.

===========

Many 1541 drives has a Speed-DOS kernal. And many have a Dolphin DOS inside.

It would nice to see support for for this DOS variants.

I think it is only a "problem" of the Software, since parallel cable is supported from hardware.

Since OpenCBM does only send a TALK, LISTEN, UNTALK/UNLISTEN, IEC-IN, IEC-OUT it should be a way to implement it in ZOOMFLOPPY firmware??

A Speed DOS Kernal in the C64 can handle Speed DOS 1541 and normal 1541 in the same manner. The Kernal Code detect itself if it is a parallel or serial Communication.

Same should be possible in the Zoomfloppy firmware I think.

After OpenCBM want to do a TALK command, Zoomfloppy could detect the kind of communication (parallel/serial) and do further IEC-IN / IEC-OUT with the detected mode until a UNTALK / UNLISTEN is to do.

What do you think about this?

===========

Same thing should be possible for Jiffy drives.

A C64 JIFFY Kernal can automatically detect a 1541 with Jiffy Kernal. A Jiffy drive is automatically supported in fast mode and normal 1541 is working also fine in slow standard mode.

The SD2IEC shows this in the other side. The ATMEGA of an SD2IEC device automatically communicates fast with a C64 Jiffy Kernal and also it speaks in slow mode with a standard C64.

What do you think about Jiffy Support in Zoomfloppy Boards?

I know, Jiffy is not so easy cause this cycle exact timing.

But parallel cable should be relatively easy to support in Zoomfloppy firmware ...

Best regards
Tommy

[Nate Lawson]

It’s an interesting idea. Yes, the ZF could implement the host side of JiffyDOS protocol. It looks like typical delays are 13 or 6 microseconds, which is plenty of time for the AVR.

https://github.com/rkrajnc/sd2iec/blob/master/src/avr/fastloader-ll.S

Is Speed DOS common enough to add support for it? I’d like each supported feature to have enough ongoing testing so that future changes don’t break it. I wouldn’t want to support something few people use these days.

-Nate

> --
> You received this message because you are subscribed to the Google Groups "ZoomFloppy Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to zoomfloppy-use...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/zoomfloppy-users/c1fbb39d-12ae-40ef-8c73-cfaec50d0cfbn%40googlegroups.com.

[Thomas Winkler]

Hi Nate

I think Jiffy is most common in Germany and Austria.

The parallel speeder are not so widly around, but if parallel, most of the user has Speed DOS (cause it was first parallel speeder and it is so cheap) and second is Dolphin DOS, many C64 have Dolphin DOS.  On eBay you very often see 1541 with parallel cable and most of them are simple Speed DOS. Other parallel speeder are very rare at ebay.

I can test it.

I have nearly all kind of parallel Speeder, and surely Jiffy 1541 and I have original Zoomfloppy from Jim and also other XUM devices here.

best regards

Tommy

[mthi...@gmail.com]

It’s an interesting idea. Yes, the ZF could implement the host side of JiffyDOS protocol. It looks like typical delays are 13 or 6 microseconds, which is plenty of time for the AVR.

I gave Jiffy-DOS support a try: https://github.com/thierer/OpenCBM/tree/jiffy_support

So far implemented for the PROMICRO_7406 and ZOOMFLOPPY variants (but I can't test the ZF, let me know if it doesn't work).

Unfortunately there doesn't seem to be much gain outside of niche cases. Not very surprising, with JD support cbmcopy "original" mode transfers are in the same ballpark as the "serial1/2" modes without.

I see benefits in the following cases:

1. Transfers from/to drive memory (as I understand Tommy's intended use case): "cbmctrl download 8 0xc000 0x4000" is 7.6 vs. 28s.

2. VICE's "real device" mode (as the speedup is transparent to the host): Loading a random 175 block file takes 45 vs. 92s.

3. Devices with JD support which are not supported by opencbm's accelerated transfer routines, like the sd2iec (are there others? Maybe CMD-HD?): The same 175 block file takes 6.2 vs. 85s with "cbmcopy -t original".

Martin

[Thomas Winkler]

Wow, wonderful, very good!

> Unfortunately there doesn't seem to be much gain outside of niche cases. Not very surprising, with JD support cbmcopy "original" mode transfers are in the same ballpark as the "serial1/2" modes without.

Yes this is not a surprise.

But this would be a chance for a new protocoll.

The code to handle Filecopy and Blockcopy is always at drive address 0x500 and the "transfer code" always at 0x700.

The transfer code is always the same for filecopy, blockcopy and warpcopy. 

There are many protocol types: S1, S2, S3, PAR

So it would be nice to have a new one: S4  (Jiiffy protocol)

Unfortunatly this would make changes in many parts of OpenCBM ...

Is Jiffy much faster than S2?

--

You received this message because you are subscribed to the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zoomfloppy-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/zoomfloppy-users/6463a687-47ac-43b7-af68-2036e060cddcn%40googlegroups.com.

[Nate Lawson]

> On Sep 1, 2021, at 11:15 AM, mthi...@gmail.com <mthi...@gmail.com> wrote:
>
> It’s an interesting idea. Yes, the ZF could implement the host side of JiffyDOS protocol. It looks like typical delays are 13 or 6 microseconds, which is plenty of time for the AVR.
>
> I gave Jiffy-DOS support a try: https://github.com/thierer/OpenCBM/tree/jiffy_support
>
> So far implemented for the PROMICRO_7406 and ZOOMFLOPPY variants (but I can't test the ZF, let me know if it doesn't work).

Neat, thank you for this work! I love seeing people make new features instead of just tiny ports to niche dev boards.

> Unfortunately there doesn't seem to be much gain outside of niche cases. Not very surprising, with JD support cbmcopy "original" mode transfers are in the same ballpark as the "serial1/2" modes without.
>
> I see benefits in the following cases:
>
> 1. Transfers from/to drive memory (as I understand Tommy's intended use case): "cbmctrl download 8 0xc000 0x4000" is 7.6 vs. 28s.
> 2. VICE's "real device" mode (as the speedup is transparent to the host): Loading a random 175 block file takes 45 vs. 92s.
> 3. Devices with JD support which are not supported by opencbm's accelerated transfer routines, like the sd2iec (are there others? Maybe CMD-HD?): The same 175 block file takes 6.2 vs. 85s with "cbmcopy -t original”.

It certainly would save the time of transferring the S1/S2 code to drive memory during startup, as well as regular DOS routines like listing a directory.

Thomas: what would be the advantage of making this an “S4” transport?

-Nate

[Martin Thierer]

On Wed, Sep 1, 2021 at 8:35 PM Thomas Winkler <oe7...@gmail.com> wrote:
> There are many protocol types: S1, S2, S3, PAR
>
> So it would be nice to have a new one: S4 (Jiiffy protocol)
>
> Unfortunatly this would make changes in many parts of OpenCBM ...
>
> Is Jiffy much faster than S2?

Not at all, that was my point. With JD, the host and the drive
negotiate and transparently use the JD protocol instead of the
standard IEC protocol, if both support it. So what you get when you
select opencbm's "original" protocol *is* the JD protocol. And from
what I measured it's exactly as fast as both the "serial1" and
"serial2" protocols (what you refer to as "S1" and "S2"). So there's
no need for a new protocol for JD, you get it for free when using
"original" mode. But it's not faster than "serial1/2".

1. One exception is d64copy, where "original" also de-selects "warp"
mode and therefore is slower than "serial1/2". It could probably
benefit from enabling "warp" mode if Jiffy-DOS is detected. But I
don't see the point, because the drives which support "warp" mode
should also support "serial1/2", so you could use that instead.
2. There is a faster "load" mode in the JD protocol, that I didn't
implement. It's only useful for reading complete files and a bit of a
hack and would require support in the opencbm tools, while what I
implemented so far is totally transparent to the host.
3. What would be the point of a new protocol anyway? What's the use case?

Martin

[Thomas Winkler]

I'm not sure if S2 is faster or slower than Jiffy?

If Jiffy is faster than S2, it would be nice to have an S4 option.

- so we could make a very fast D64COPY for example

- and currently S2 doesn't work with more than 1 drive, Jiffy does work fine with 2 or more drives

- S4 also would nice for normal drives without JIFFY ROM 

-Tommy

--
You received this message because you are subscribed to the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zoomfloppy-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/zoomfloppy-users/4AFC1B31-02EF-4E39-8881-8224DE981908%40root.org.

[Martin Thierer]

> It certainly would save the time of transferring the S1/S2 code to drive memory during startup, as well as regular DOS routines like listing a directory.

I would have expected that to make a noticeable difference, but it
doesn't over all. I would have to check how much difference it
actually makes, but apparently it's negligible when transferring more
data.

[Martin Thierer]

> I'm not sure if S2 is faster or slower than Jiffy?
>
>
> If Jiffy is faster than S2, it would be nice to have an S4 option.

As I wrote in my other mail (but you probably prepared yours while I
sent it?), they are about the same.

>
> - so we could make a very fast D64COPY for example
> - and currently S2 doesn't work with more than 1 drive, Jiffy does work fine with 2 or more drives

I found no big difference between S1 and S2 either, so I don't think it matters.

> - S4 also would nice for normal drives without JIFFY ROM

In scenarios where it's possible / acceptable to download drive code
you could as well use the existing transfer modes.

[Martin Thierer]

FYI, these are the transfer times I measured for various
configurations with the same 175 block file referenced in my first
email:

# 1541-II with JD rom, xum1541 master

cbmcopy -w -t serial2 => 47s
cbmcopy -w -t serial1 => 49s
cbmcopy -w -t original => 84s
cbmcopy -r -t serial2 => 46s
cbmcopy -r -t serial1 => 47s
cbmcopy -r -t original => 88s

# 1541-II with JD rom, xum1541 with JD support

cbmcopy -w -t serial2 => 47s
cbmcopy -w -t serial1 => 49s
cbmcopy -w -t original => 49s
cbmcopy -r -t serial2 => 46s
cbmcopy -r -t serial1 => 46s
cbmcopy -r -t original => 46s

# 1541-II with stock rom, xum1541 with JD support (didn't measure serial1)

cbmcopy -w -t serial2 => 53s
cbmcopy -w -t original => 115s
cbmcopy -r -t serial2 8 => 52s
cbmcopy -r -t original 8 => 110s

So:
1. The JD rom alone already speeds up all transfer modes, even without
dedicated support in the xum1541 firmware.
2. The only real difference between xum1541 firmware with/without
dedicated JD support in combination with the JD rom is with the
"original" (= standard serial IEC) transfer mode.

Martin

[RETRO Innovations]

--
You received this message because you are subscribed to the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zoomfloppy-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/zoomfloppy-users/6463a687-47ac-43b7-af68-2036e060cddcn%40googlegroups.com.

If possible, I'd like this to be rolled into the mainline, as there are quite a number of non-1541 drives that don't offer anything but the original speeds (MSD would be one).  Supporting JD would help on these (CMD HDD is another).

Jim

-- 
RETRO Innovations, Contemporary Gear for Classic Systems
www.go4retro.com
store.go4retro.com

[Nate Lawson]

On Sep 1, 2021, at 8:42 PM, RETRO Innovations <go4r...@go4retro.com> wrote:



How compatible is it to leave this handshake detection enabled all the time? I know JD comes with a physical switch to disable if needed but we don’t have that on the ZF. 

-Nate

[RETRO Innovations]

On 9/1/2021 10:57 PM, Nate Lawson wrote:
>
>
> How compatible is it to leave this handshake detection enabled all the
> time? I know JD comes with a physical switch to disable if needed but
> we don’t have that on the ZF.

I'm OK, if needed, to make JD S4 or something and force folks to specify it.

Jim

[Nate Lawson]

> On Sep 1, 2021, at 9:06 PM, RETRO Innovations <go4r...@go4retro.com> wrote:

>
> On 9/1/2021 10:57 PM, Nate Lawson wrote:
>>
>> How compatible is it to leave this handshake detection enabled all the time? I know JD comes with a physical switch to disable if needed but we don’t have that on the ZF.
>
> I'm OK, if needed, to make JD S4 or something and force folks to specify it.

I’d prefer auto detect, but I don’t know how safe it is.

-Nate

[RETRO Innovations]

I vote with you, and share your concern.  Maybe there's a way to do a default that auto detects, but allow a way to override if there are issues.

[Thomas Winkler]

okay, very nice, thank you very much for your work.

So Jiffy works "seemless" now, only on  a drive with Jiffy Kernal and without any changes, like it does in the C64 Kernal.

This is fine, cause Code Upload should now very fast.

This waiting periode while using D64COPY (code upload) should now very short on a Jiffy Drive.

best regards

Tommy

--

You received this message because you are subscribed to the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zoomfloppy-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/zoomfloppy-users/9939474e-9a69-9b42-5892-b6439dface75%40go4retro.com.

[Martin Thierer]

On Thu, Sep 2, 2021 at 5:42 AM RETRO Innovations <go4r...@go4retro.com> wrote:
> If possible, I'd like this to be rolled into the mainline, as there are quite a number of non-1541 drives that don't offer anything but the original speeds (MSD would be one). Supporting JD would help on these (CMD HDD is another).

Could you compile the firmware and test if it works, especially with
these other JD-enabled drives? Does it work at all with the
Zoomfloppy?

Also, lack of success stories isn't the only thing why I don't think
it's ready to be merged yet. I'm not sure I'm happy with some aspects
of the implementation. Also, support for all the other boards should
be added first and I still hope to find a way to convince the compiler
to produce usable code without hand-crafting a version for every
single board.

On 9/1/2021 10:57 PM, Nate Lawson wrote:
> How compatible is it to leave this handshake detection enabled all the
> time? I know JD comes with a physical switch to disable if needed but
> we don’t have that on the ZF.

What possible problems are we talking about here? The xum1541 handles
the host side, that's imho not necessarily comparable to the need for
a switch on the drive. Even that is probably 1. there for mostly
psychological reasons and 2. intended for problems with other
fastloaders and copy protections. Both things that won't work with a
xum1541 board anyway. We can control rather well what we send to the
drive.

For the xum1541 firmware, I can think of 3 possible causes of problems:

1. The drive doesn't support JD, but gets confused by the clock
stretching and therefore doesn't correctly receive the byte. Possible,
but I guess it would have to be a fairly exotic drive because I expect
JD to be tested at least with the stock roms of the CBM drives. A
possible fix that comes to mind would be to restart the ATN phase with
disabled JD detection if the drive doesn't acknowledge the command
byte and keep JD detection disabled for the rest of the session if
that actually helps (Cycling ATN should reset the drive's
communication well enough for that to work, but if it's a really
exotic device, who knows).

2. The drive doesn't support JD, *but still*, for whatever reason,
sets DATA during the detection phase so that the host will use the JD
protocol but the drive doesn't understand it. Theoretically possible,
but I consider that so unlikely that I don't think it's useful to even
think about solutions before an actual case is confirmed.

3. The drive *does* support JD, but the communication fails, because
of bugs or quirks in either the xum1541 implementation or the drive. I
consider this the most likely case and the best solution would be to
fix or adapt the xum1541 implementation. This might prove futile
without access to the actual drive, though. In that case a way to
disable the JD detection would make sense.

But: Enabling JD support will require flashing an updated xum1541
firmware anyway. Judging from the many reports I see from folks still
on a v07 firmware, this seems to be a big (and/or unnecessary) step
for most people. So I guess the uptake would be slow. And the users
most likely to flash such a new firmware will be the ones that have JD
capable drives so they should be aware of the topic. (@Jim: Which
firmware do you usually ship your ZF devices with? The latest,
compiled from git master, or a known good earlier version?).

Imho the worst case would be if a known good setup would suddenly stop
working without the user having an indication why. That won't happen
here, because the users just flashed a new firmware, so they will know
exactly what they did (and can just fix it by reverting to the old
firmware).

So right now I wouldn't think too much about or even implement fixes
for problems where we don't even know if they exist.

1. I wouldn't recommend disabling the JD detection by default and only
enable it when explicitly selected. I think the biggest benefit of JD
compared to the other opencbm transfer modes is that it should "just
work" if it detects a supported drive.

2. If it turns out there are problems with certain configurations, the
top priority should be to fix or work around them in the xum1541
firmware. If that isn't possible, it will not be hard to add some form
of selection mechanism (be it a dedicated protocol or something else)
to opencbm that disables JD detection (or disable it by default and
add a way to enable it).


Martin

[RETRO Innovations]

On 9/2/2021 4:25 PM, Martin Thierer wrote:
> On Thu, Sep 2, 2021 at 5:42 AM RETRO Innovations <go4r...@go4retro.com> wrote:
>> If possible, I'd like this to be rolled into the mainline, as there are quite a number of non-1541 drives that don't offer anything but the original speeds (MSD would be one). Supporting JD would help on these (CMD HDD is another).
> Could you compile the firmware and test if it works, especially with
> these other JD-enabled drives? Does it work at all with the
> Zoomfloppy?

I can, but I don't normally compile the firmware here, so I'll need to
work on setting the env up.  If someone else could help and send me a
HEX file I could try, that would speed things up.

[Martin Thierer]

On Thu, Sep 2, 2021 at 11:53 PM RETRO Innovations <go4r...@go4retro.com> wrote:
> I can, but I don't normally compile the firmware here, so I'll need to
> work on setting the env up. If someone else could help and send me a
> HEX file I could try, that would speed things up.

Sure, I'll send it to you via private mail.

[RETRO Innovations]

Origin firmware, JD equipped 1541-II:

C:\temp>echo 18:41:40.34
18:41:40.34

C:\temp>d64copy 8 jim.d64

...

35: *****************       100%   683/683
683 blocks copied.

C:\temp>echo 18:42:56.28
18:42:56.28

JD firmware:

C:\temp>echo 18:45:19.20
18:45:19.20

C:\temp>d64copy 8 jim.d64

35: *****************       100%   683/683
683 blocks copied.

C:\temp>echo 18:46:39.38
18:46:39.38

MSD JD equipped drives are sadly giving me blinking codes right now, so have to get one working before I can test, but the above is your code on ZF.

[mthi...@gmail.com]

Thanks, that's encouraging! For a quick test you can also just use "cbmctrl status" or "cbmctrl dir". Both use the JD protocol if available and will hang or display garbage if it doesn't work. d64copy with "-t auto" (the default) uses its own routines for most of the transfer, that's why you don't see much difference (don't know why your first try was even 3s faster, I get around 70s regardless of JD support). 

go4r...@go4retro.com schrieb am Freitag, 3. September 2021 um 02:24:49 UTC+2:

MSD JD equipped drives are sadly giving me blinking codes right now, so have to get one working before I can test, but the above is your code on ZF.

So is that just after you plug them in or after you issued any commands? If the latter it might indicate a problem with the xum1541 firmware? If so, with both old and new firmware?

Martin 

[mthi...@gmail.com]

I just checked. With the stock rom it takes 580ms to transfer and start the custom drive code for "cbmcopy -r". So there's not much to gain on that front...

[RETRO Innovations]

On 9/3/2021 10:53 AM, mthi...@gmail.com wrote:

Thanks, that's encouraging! For a quick test you can also just use "cbmctrl status" or "cbmctrl dir". Both use the JD protocol if available and will hang or display garbage if it doesn't work. d64copy with "-t auto" (the default) uses its own routines for most of the transfer, that's why you don't see much difference (don't know why your first try was even 3s faster, I get around 70s regardless of JD support).

I'll keep that in mind. 

go4r...@go4retro.com schrieb am Freitag, 3. September 2021 um 02:24:49 UTC+2:

MSD JD equipped drives are sadly giving me blinking codes right now, so have to get one working before I can test, but the above is your code on ZF.

So is that just after you plug them in or after you issued any commands? If the latter it might indicate a problem with the xum1541 firmware? If so, with both old and new firmware?

Sorry, the drives themselves are giving me blinking lights (3 flashing lights on the MSD2), so I need to find the manual and figure out the code.  Not a ZF issue.

JIm

[mthi...@gmail.com]

I gave Jiffy-DOS support a try: https://github.com/thierer/OpenCBM/tree/jiffy_support

I just pushed a new version. Mostly cosmetic changes, except:

- Should now work with all supported boards. That's why I also replaced the firmware files in the repository with versions compiled from this revision. I can only test the pro micro versions, but I'm not aware of any reason why the others might not work.

- As suggested by Nate and Jim, I added a XUM_DISABLE_JIFFY flag which could be used by the opencbm tools to disable the detection dance for Jiffy-DOS support and in extension the use of the protocol. Right now there's no code in opencbm to make use of it, though.

- The xum1541 plugin now prints a message to the XUM1541_DEBUG log, if Jiffy-DOS protocol support was detected by the firmware:

[XUM1541] firmware version 8, library version 8

[XUM1541] device capabilities 03 status 00

[XUM1541] [xum1541_init] No tape support.

[XUM1541] write 16 2 bytes from address 0x7ffe5e53a4de flags 3

[XUM1541] wrote 2 bytes (48 6f)

[XUM1541] xum1541_wait_status checking for status

[XUM1541] return val = 102

[XUM1541] wait done, extended status 258

[XUM1541] Jiffy-DOS protocol support detected

It needs a recompiled version of opencbm to work, but with some imagination (and XUM1541_DEBUG >= 2) it's also useful with the release version, as it will still print "258" for "extended status" (instead of "2" without JD support).

@Nate: I tried to follow what I perceived as your coding style, please let me know if you disagree on something. (I'm personally not totally happy about the "useJiffyDosProtocol" global variable. Alternatives that I can think of: 1. Adding a variable to ProtocolFunctions{} for storing protocol-specific state -> Then it's not really "Functions" any more or 2. adding a flag parameter to iec_raw_read() -> Changes the cbm_raw_read() signature for all protocols).

Martin