XU1541 and WinVICE

[+OLD CS1]

So I got my XU1541 interface. It works great on my machine with the command line tools and the CBMXfer GUI front-end. Got a couple of 1571s on it (although I may have figured out a problem with JiffyDOS-enabled drives about which I will post if I determine this to be fact and not coincidence,) my MSD-2s, and a CMD HD.

 

I cannot get WinVICE to use the interface. I set "Use IEC device" for the appropriate device number in the "Peripherals" menu, but no go.

 

I tried finding some documentation on it but was not able to turn anything useful up: supposedly it just works.

 

Has anyone run into problems using the XU1541 with WinVICE? If so, how did you get it working?

[landgraf]

I might not work because your version of Winvice is too recent, IIRC the official builds dropped support of real IEC-devices since V2.3 or so. Older versions can still be found at zimmers.net and csdb

Edited May 14, 2016 by landgraf

[+OLD CS1]

I might not work because your version of Winvice is too recent, IIRC the official builds dropped support of real IEC-devices since V2.3 or so. Older versions can still be found at zimmers.net and csdb

 

Great, thanks. I will give an earlier version a try. I cannot imagine that, for my purposes, I would lose anything by back-tracking. In any case, since it is not an installed software I can run multiple versions in parallel.

[+OLD CS1]

Had to go back all the way to 2.1 for the "Real IEC" option to show... but it is way slower than I expected. Mind you, I have been using the 64-bit, for which I might not have to go so far back.

 

Anyway, it is working now, thanks.

[+OLD CS1]

Suspicion confirmed: the x64 build of WinVICE does not provide support for Real IEC Device. I downloaded v2.4-x86 and the option works as expected with my XU1541.

[landgraf]

Cool that you got it working!

 

In any case, since it is not an installed software I can run multiple versions in parallel.

Yep, I typically have about half a dozen versions ready, given the sizes of modern HDs the few extra MBs don't really hurt. It can get a bit messy to associate certain filetypes with a certain version as all of them show up as "vice emulator" in the selection box, though

[+OLD CS1]

Tell you what -- it is slow as dog snot and I have been using something like JiffyDOS and Warp Speed for so long I have forgotten what stock performance is like.

 

Considering how the various IEC lines are manipulated, I suspect many fast-loaders will not work with this setup. I am hoping JiffyDOS will.

 

I will also play with 128 mode as I believe the XU1541 is burst mode-compatible. CP/M+ will be tested, as well. I found I have six 1571s and three 1581s, so this will be kind-of a third system for the convenience of sitting at my desk working or for transfers between floppies and disk images.

[landgraf]

Considering how the various IEC lines are manipulated, I suspect many fast-loaders will not work with this setup. I am hoping JiffyDOS will.

As Vice itself can't communicate with a real drive in realtime it lets the OpenCBM-driver do the actual communication. If OpenCBM benefits from JiffyDOS you might be lucky, otherwise I'm afraid it won't help.

[+OLD CS1]

As Vice itself can't communicate with a real drive in realtime it lets the OpenCBM-driver do the actual communication. If OpenCBM benefits from JiffyDOS you might be lucky, otherwise I'm afraid it won't help.

 

One of the first results from a quick search turns up this message from Spiro back in 2006:

 

 

I just got a report that cbm4linux does not work on a drive with

JiffyDOS. If the poster switches back to the original ROM, it works.

 

Can anyone confirm (or not confirm) this behaviour on his setup (with

Windows and/or Linux)? This might help me in tracking down the problem.

 

Ten years later, I can confirm that OpenCBM with my XU1541 most definitely has problems with JiffyDOS-enabled drives. Formats, D64 creation and writes, pretty much everything except resetting the drive and reading its status, with sporadic failures getting a directory with my JiffyDOS-enabled 1571s.

 

Then, in 2009 from Spiro:

 

 

 

However, as you are restricted to the original IEC protocol - OpenCBM does not even support JiffyDOS -

this might be cumbersome, as it is very slow.

 

I am resigned to using non-JD drives on the VICE rig. Again, not a big deal, just a bummer. I still have one non-JD 1571 and 1581. I have been thinking about throwing in a 1541-II ROM into my Enhancer 2000 to see if that works as I have read elsewhere, and if so I will use that, as well.

[carlsson]

Hm, if you connect a JD drive to a machine that doesn't have JD, doesn't the drive degrade to stock ROM routines? I never owned a JD drive so I can't tell.

 

Does the same problem occur if you attach an emulated speeder cartridge to VICE and use a non-JD drive? That is something I in theory could test, assuming the Real IEC option works on older versions of VICE even with a XM1541 cable.

 

Actually I got the feeling that OpenCBM has its own built-in turbo but perhaps that is a different thing than accessing its routines from within VICE.

Edited May 16, 2016 by carlsson

[7800fan]

The JD drive is supposed to switch to non JD on a non-JD'd host. I think OpenCBM isn't sending the correct command on power on to trigger non JD mode.

[+OLD CS1]

Hm, if you connect a JD drive to a machine that doesn't have JD, doesn't the drive degrade to stock ROM routines? I never owned a JD drive so I can't tell.

 

Does the same problem occur if you attach an emulated speeder cartridge to VICE and use a non-JD drive? That is something I in theory could test, assuming the Real IEC option works on older versions of VICE even with a XM1541 cable.

 

Actually I got the feeling that OpenCBM has its own built-in turbo but perhaps that is a different thing than accessing its routines from within VICE.

 

I have not tried with a real 1541, yet, so I am not certain there are special turbo routines or if it is just using the 1571 in burst mode. D64 to image and vice-versa works very, very fast, but directory reads are un-Godly slow.

 

Since I am running Windows 7 x64 and will not put the system into a non-secure driver mode, I have no way (currently) of using the XM1541 cable to test. I have considered putting together an XP box on an isolated VLAN with access to nothing but the NAS as I have wanted to run an SIO2PC (Atari) and HDX (TI) server, but without being able to run 64HDD and service all of my old machines, the notion and enthusiasm has kind-of fizzled.

 

I tried Epyx FastLoad with the XU1541 and a non-JD drive. Reading the drive status works fine, but doing any program access locks up the system.

 

 

The JD drive is supposed to switch to non JD on a non-JD'd host. I think OpenCBM isn't sending the correct command on power on to trigger non JD mode.

 

I am not sure about this for two reasons: first, the new JD ROMs I just got for the MSD-2 and 1541-II have deactivation switches which bank-in the original ROMs, and secondly because ISTR from reading the JD disassembly a while back that the drive ROM routines are patched to try a test JD transfer first and then fall back to the stock routines. This works similar to the burst mode routines in the Kernal which try a burst command byte first and wait for the drive to respond or not. I am not certain how much the stock routines get shifted in ROM to accommodate any of the JD changes, if at all. I would have to pull that disassembly back out sometime this week when time permits.

[+OLD CS1]

So, after trying out a real 1541 (one of the brown drives with the Newtronics assembly,) I am pretty certain there is no special turbo protocol in use with OpenCBM I think it just leverages burst-mode with the 1571, and mostly the 1581, as well. Given that, I cannot see any reason to have anything other than a 1571 and 1581 in my XU stack.

 

I would be surprised if there is a big call for this, but I would love to see an XU device and OpenCBM iteration which would allow manipulation of the individual IEC lines to support fast-loaders.

[carlsson]

The utilities d64copy (entire disk) and cbmcopy (individual files) have a parameter -t for transfer mode. It can be auto, original, serial1, serial2 or parallel. The turbo modes are based on those in Star Commander, which isn't to say those are compatible with other well-known fastloaders.

 

http://opencbm.trikaliotis.net/opencbm-20.html

[+OLD CS1]

I may play with those, then. I do not see a place to make that setting change in WinVICE, so given the results loading Bruce Lee 2 (took FOR-EV-ER!) it looks like it, at least, it locked to the slowest mode. heheheh Being laid up on the couch can be fun.

[carlsson]

Yes, I think the faster modes only applies to the OpenCBM applications, not when the driver is used by another program unless of course you have a C64/128 executable that corresponds to the same fastloader. I haven't investigated if that is possible, or how those ones differ from other routines. I gather they reprogram the drive just like every software based fastloader does.