U1541

[Suudy]

I don't know how many of you frequent comp.sys.cbm, but I've posted a few times about my U1541 project.  I thought I had the great idea of PC<-->15x1 (and PC<-->C64/C128) using USB, but others beat me to it (e.g. XU1541).

You can read my blog to see more detail.  The advantage to this design over the XU1541 is that the USB is in hardware, so the overall performance and throughput will be greater.  The XU1541 did USB in software, not only consuming AVR resources, but also limiting the potential throughput.  Since the design takes advantage of the FT232 part the burden of the USB interface is lifted from the AVR, allowing it to concentrate on the IEC side of things.  And since it is USB, it works on modern operating systems using standard drivers, such as Windows and Linux (even OSX possibly).

There are 2 phases to the project.  Phase 1, the current phase, is to get PC<-->15x1 working.  I've already been discussing with Jim Brain to use his IEC code to support both standard 15x1 communications, as well as JiffyDOS.  On the PC side, I plan to support OpenCBM for such work, and when hardware is ready coordinate with Spiros on this front. 

Phase 2 is PC<-->C64/C128 support.  Unlike the 1541 Ultimate, uIEC, sd2iec, etc, the PC is the server.  This opens a huge variety of options, including emulation of 15x1 drives (with or without JiffyDOS), CMD et al harddrives, even printers and tape drives.  The initial step here is to develop a framework to support "plugins" for a variety of peripherals.  Initially the focus will be on 15x1 drives.

The total board cost is variable.  But in small quantities, it runs about $50 in parts, and another $50 in board cost.  These prices drop dramatically as quantities increase.  In 100 part quantities, the total board cost is close to probably $50.  And in even larger quantities, the cost can drop even more.

So far on this project, I have worked with Jim Brain and a board designer to develop the board.  We have the schematic complete, but need to work forward to the board layout.  So far I have contributed $600 of the $1100 total for the board design.  I'm asking for donations to complete the work so that I can make some prototype boards.  For those that contribute, I'm willing to send you a board without parts (edit:  within reason of course, no free board for a $1 donation!).  You can then order the parts from Digikey or Mouser.

If you are interested, please feel free to contact me, either via PM or my blog.

[Golan Klinger]

Why not just pre-sell units to raise the cash necessary for the development and when you've got 100 pre-orders (or whatever you determine is necessary) go ahead and make a run of them? This is sort of what was done with the 1541 Ultimate and that worked out brilliantly for all involved.

[Suudy]

Why not just pre-sell units to raise the cash necessary for the development and when you've got 100 pre-orders (or whatever you determine is necessary) go ahead and make a run of them? This is sort of what was done with the 1541 Ultimate and that worked out brilliantly for all involved.

There are a couple of reasons:  1)  I don't want to sell the results.  The results will be made available for anyone who wants to make their own, hack it, etc.  Consider it an "open-source" kind of project.  The donations to offset the cost of the development will become available to everyone.  2)  Pre-orders require collecting cash up-front.  I'm not comfortable giving money up front for something that "may" exist.  Why would I expect anyone else to do the same?

Selling the U1541 isn't something I want to do.  I want to do it so that I can replace the heap that is my DOS box, and expand upon things.  A full blow PC side server isn't something that exists.  And it is something I think others would find very useful.

[Golan Klinger]

There are a couple of reasons:  1)  I don't want to sell the results.  The results will be made available for anyone who wants to make their own, hack it, etc.  Consider it an "open-source" kind of project.

This is the case with most current C= projects, the 1541U included. Many people aren't capable of making their own devices, even with readily available plans, and they're usually willing to pay to have someone else do it even if they must pay long in advance which in part helps fund the project. It helps if you don't think of it as a commercial venture per se. There's no getting around things if you don't want to sell the results and I can respect that. I only made the suggestion because the scheme has worked in the past for other projects.

2)  Pre-orders require collecting cash up-front.  I'm not comfortable giving money up front for something that "may" exist.  Why would I expect anyone else to do the same?

Fair enough. Understand though that many of us are. (There's a tacit understanding that if the developer abandons the project that they'll return the money.) Personally, I don't need a U1541 but I would prepay for one to help the device come to fruition whereas making a purely altruistic donation is something I reserve for projects that are up and running and require on-going funding (like the GameBase64).

Anyway, best of luck with your project and welcome to 128 Alive!

[Golan Klinger]

(Continued from here)

It really is PC<-->15x1 via USB.

Please correct me if I'm wrong but I understood that the U1541 is (or will be) a USB version of an X-cable. I think I get your drift though even if I think the analogy is stretching it a bit. (By your interpretation one could compare the 1541U and 64HDD.) The 1541U is a 1541 simulator with an REU and some utility cartridges although it may evolve into more some day. Were your device to include a connection to both the IEC and expansion ports, you'd be in a better position to debate the similarity. I suppose something could be done with the GPIO connectors to facilitate that.

That reminds me of something I wanted to ask. Are you developing PC-side software or is it your intention that people will use existing software (with or without modification) that currently works with X-cables?

[Suudy]

Please correct me if I'm wrong but I understood that the U1541 is (or will be) a USB version of an X-cable. I think I get your drift though even if I think the analogy is stretching it a bit. (By your interpretation one could compare the 1541U and 64HDD.) The 1541U is a 1541 simulator with an REU and some utility cartridges although it may evolve into more some day. Were your device to include a connection to both the IEC and expansion ports, you'd be in a better position to debate the similarity. I suppose something could be done with the GPIO connectors to facilitate that.

It is more than a USB version of an X-cable.  However, I now see your point.

You are right.  It isn't exactly what 1541Ultimate achieves.  The U1541 (I really should probably come up with a better name), only supports connections via IEC.  Thus, there is no REU expansion included.  In my response, I was considering only the PC<-->C64/C128 side of things in terms of drives, not the REU.  I apologize for the confusion.

So to be clear, there are 2 main goals to the U1541:  an IEC-only connection for 1)  PC<-->15x1 and 2) PC<-->C64/C128.  While the possibility does exist for other expansions (such as the cartridge port), they are unlikely to support anything like a large REU.  However, such expandability beyond the IEC interface is outside the scope of my project.

That reminds me of something I wanted to ask. Are you developing PC-side software or is it your intention that people will use existing software (with or without modification) that currently works with X-cables?

My intention, initially, is to support PC<-->15x1, and to support changes (even if it means writing code myself) to OpenCBM.  So yes, I plan for people to use both existing software and to develop PC-side software.

For phase 2, the PC<-->C64/C128, I plan to develop this software, hopefully with the help of the community.  The "plugin" approach allows a variety of options to be developed.  I have some ideas on how to approach this, and intially it will be on the framework for such an approach.  Later, I plan to elicit community support for the development of such "plugins" to support a variety of IEC options.

[gsteemso]

Back around 1999 or 2000 I began work on a RS232/422 to IEC protocol converter, which I called the SQUID-1 (for "Steemson's Quite Useful Interface Device, mark 1"). As I was both immature and mentally ill at the time, I was very excited and bragged about it to anyone who would listen, even going so far as to fax a letter to CMD asking how to make it JiffyDOS compatible (they said "show us the hardware first"). You may recall Jim Brain's resource list briefly mentioning a project to interface Macs to Commodores? That was me.

I failed to complete development in time for my computer-hardware class's project submission deadline, and development stopped cold until this past month, when I finally obtained a replacement means of downloading code to my microcontroller. Unfortunately, the microcontroller I was using (the PIC16F84) has just few enough I/O pins that it turns out I will have to redesign the beast with more support chips if I want to support JiffyDOS, or even burst mode. What the hell, at least I'm still working on it.

I considered the Mac side of the equation to include allowing 15x1 drives or D64 images to be mounted by the Mac OS Finder, which added a great deal of complexity and effectively made the development time approach infinity. It does mean I've laid a lot of the groundwork for supporting SQUID or U1541 devices on Mac OS classic though. (OS X is harder because it shares almost nothing in common with the previous device-handling arrangements, and I am crippled in learning the new techniques by lack of software -- I'm still running OS 10.3.9, which Apple hasn't supported for development work in years.)

I had intended that the SQUID-2, when I got that far, would replace the RS-422 interface with USB, but it sounds like you've beaten me to it with the U1541. Is there any chance we could coordinate our system architectures so stuff I make for my project on the Mac will also work with your device, and stuff people make for your project on the PC will also work with the SQUID?

The more devices of this nature get made the better, in my opinion. Good luck with your project!

G.

[Suudy]

I had intended that the SQUID-2, when I got that far, would replace the RS-422 interface with USB, but it sounds like you've beaten me to it with the U1541. Is there any chance we could coordinate our system architectures so stuff I make for my project on the Mac will also work with your device, and stuff people make for your project on the PC will also work with the SQUID?

I'd be glad to work with you on this.  In fact, your work on an RS-232/422 to IEC would fit in well.  The current implementation uses the FT232, which is a USB<-->RS232 converter.  The trick is to integrate all of this into OpenCBM.  I haven't yet looked into the guts of OpenCBM to see how it would support an RS232 interface, but perhaps your work on SQUID could help on this front.

As for the Mac side of things, it sounds like you are the ideal candidate.  I don't have a Mac (well, not a modern one anways--my nostalgic Mac Classic doesn't count) to do any testing on.  As boards come available, I'll let you know.

[Diddl]

Any progress in this adapter since June?


In the meantime I started a similar kind of interface: The XS-1541 - universal serial adapter for Commodore Floppy


The XS-1541 support all kind of Commodore Floppy. All serial IEC (15x1 type) and old IEEE-488 Floppy drives (2030,4040,8050,8250, SFD1001) also.

The PC is connected by RS232 (serial COM Port) or USB (by a USB - VCOM bridge).

The firmware is nearly finished. On PC side you don't need a program (only a terminal emulation lke Hyperterm or such). So it is independent from PC, it is working also on a MAC or any other Computer which supports a RS232 and a Terminal emulation.

The Firmware is able to communicate with IEC and/or IEEE drives same time. You can list a directory ($, dir[ectory], ca[talog]), send disk commands (@xxx) or read the disk status (@). You can download (dl) or dump (df) single files or whole disks (ba[ckup]) as a P00 (single file) or an image file in D64, D71, D80, D81 and D82 format (whole disk). Image files can be read as all blocks (- all) or allocated (- bam). The file transfer to the PC works as a X-Modem File Transfer. In near future it will work with Y-Modem protocoll, so you don't have to enter a filename again.

All this is already working! Currently I improve the communication speed. The 1571 and 1581 burst mode will be supported now (nearly finished). The parallel interface (SpeedDos cable) will work for 1541 drives (not finished).

The costs of a XS-1541 are very small. It is based on a Atmel AVR Atmega644. You only need a prototype board and a Floppy cable. Cut the floppy cable and solder the wires on the ports of the Atmega. Nothing more ...

[Suudy]

Any progress in this adapter since June?

No.  My wife and I have been trying to buy a house over the last few months, and thought we finally found one.  Turns out it was a short sale, and the bank took 2 months to decide to reject our offer.  During that time I got withering looks from my wife whenever I suggesting spending money to have PCB's made.  We finally found a place and close next week, but there is a lot of money to spend on updates.  I'm hoping that once we are in the house (scheduled for the weekend of Sep 20), I'll be able to get back on the wagon.

The PC is connected by RS232 (serial COM Port) or USB (by a USB - VCOM bridge).

The link is to a German site, and unfortunately I'm clueless.  Post it in Latin, and I'd stand a chance!

But seriously, I presume it has to be powered externally, such as by a battery or DC adapter.  That is one of the limitations I wanted to remove.  So my board is powered from the USB bus.

The firmware is nearly finished. On PC side you don't need a program (only a terminal emulation lke Hyperterm or such). So it is independent from PC, it is working also on a MAC or any other Computer which supports a RS232 and a Terminal emulation.

The Firmware is able to communicate with IEC and/or IEEE drives same time. You can list a directory ($, dir[ectory], ca[talog]), send disk commands (@xxx) or read the disk status (@). You can download (dl) or dump (df) single files or whole disks (ba[ckup]) as a P00 (single file) or an image file in D64, D71, D80, D81 and D82 format (whole disk). Image files can be read as all blocks (- all) or allocated (- bam). The file transfer to the PC works as a X-Modem File Transfer. In near future it will work with Y-Modem protocoll, so you don't have to enter a filename again.[/quote]
This kind of setup can work well for PC<-->15x1.  Did you do the IEC code yourself?  I planned to grab Jim Brain's IEC code and incorporate it to work with OpenCBM.  I do like the X/Y-Modem transfers and the text interface.  Makes it easy to use without software, and possible to use through a translation layer to OpenCBM.

All this is already working! Currently I improve the communication speed. The 1571 and 1581 burst mode will be supported now (nearly finished). The parallel interface (SpeedDos cable) will work for 1541 drives (not finished).

As for the parallel interface, I'm not familiar with the SpeedDos cable.  Is this one soldered to the 1541 board?  If so, how do you handle full tracks?  Does your board have enough memory?  That is one thing I provisioned for on my board was external memory (up to 128K) to support nibblers and for buffering.

The costs of a XS-1541 are very small. It is based on a Atmel AVR Atmega644. You only need a prototype board and a Floppy cable. Cut the floppy cable and solder the wires on the ports of the Atmega. Nothing more ...

That's the nice thing about through-hole only, low-speed designs.  Very easy to breadboard up.  Unfortunately with the USB side of things that I had to go the PCB route.  And since I was already going to have PCB, I figured why not get a more powerful processor that can support plenty of external memory, even if they are surface mount.

I am very interested in what you have done.  Whenever I get hardware (when the wife gives permission to order PCB's), I will certainly keep you in mind.