Although parts were delayed due to a Blizzard in the Midwest this past weekend, I was able to construct ZoomFloppy #1 Monday night. Though one hopes for first attempt success, that is not often the case. It was indeed not the case for this construction.
When I designed the board, I knew the 0402-sized surface mount components were small, 1/4 the size of the 0804-sized components I normally utilize for SMT designs. Still, it’s a bit academic until one actually tries to solder the parts. At a size that is seems near my eye’s minimum ability to resolve details, the components truly tested my soldering abilities. For comparison, my finest iron tip is 1/32″, and the parts were about the same size as the tip. Still, I was able to place each component on the board.
When first powering up the unit, it did register as a USB device, and I was quickly able to load the required firmware. However, upon re-insertion, the unit registered as “xum1541 (ZOOMFLOPPY)” and demanded USB drivers I did not have. Since it was late, I left the project at that point and solicited help from Nate (the project designer) and others.
Tuesday night, I had learned what version of OpenCBM to load on the PC, the correct USB drivers had been sent to me in a ZIP file, and progress was made. The correct drivers were loaded, and OpenCBM commands were issues to the device.
Sadly, initial tests failed. Before assuming the worst, I checked all solder joints, and measured impedences, on the assumption I had soldered a component incorrectly. During the inspection, I noticed two resistors attached to the IEC lines were shorted to each other, thus effectively shorting the IEC lines together. After resolving that issue, the unit successfully passed the tests by transferring data from the drive ROM to the PC.
With no need to spin a new PCB, I released the 98 first batch units to production and ordered the required parts for assembly. The plan is to quickly assemble 25 units and potentially ship before end of year, with the rest coming quickly in January. Since the 2×8 header X3 was nominal in cost, I ordered it for inclusion in assembly.
Sale price target is $35.00, and I will add a pre-order option in the store shortly. Given the ease of installation and configuration, I predict significant sales. This device eliminates the need to fiddle with parallel port settings, trying to remember a myriad of differently lettered adapters, and a need to maintain older systems with legacy ports for disk access purposes.
One of the most often requested features for uIEC is GEOS support. Given that uIEC emulates a Commodore Disk Drive at the protocol level, not at the hardware level, such support is harder than it sounds. Like many applications of the day, GEOS uses a custom disk drive transfer routine (commonly called a “speeder” or “fastloader”) called diskTurbo to make drive access times more manageable. Since the normal protocol is discarded in favor of a faster variant, successful emulation requires emulating the custom protocol. uIEC uses the sd2iec firmware, which has supported a handful of custom protocols for some time (including JiffyDOS), but does not currently support the GEOS custom protocol.
That may soon change, though. RedumLOA has created a site called “Commodore Bounty” that will allow interested individuals to fund project activities. The first bounty is for sd2iec GEOS support, which has been funded to over $750.00 at the time of this posting. If you are interested in seeing GEOS support on sd2iec and uIEC, please consider a donation.
Many apologies for the lack of postings, but I was preparing for the Cincinnati Commodore Computer Club EXPO (C4 EXPO), which happened over Memorial Day weekend, and I am just now getting caught up on postings.
Two weeks prior to the show, I shifted all focus to ensuring newly produced products would be available at the show. X-Pander3 expansion boards and 64NIC+ network cards were in production, but delivery had been delayed a week or so. This seems to always happen prior to a show, without fail. I spent evenings obtaining manufacturing and shipment statuses, making last minute parts purchases, and packing for the show.
The week prior to the show was spent traveling to Ohio, taking in some sights (Kings Island, for example), and spending time with the family. Since we were already on the road, I rescheduled last minute product shipments from China to arrive at the hotel before the show.
Though not the only reason, it is true I offer products for sale to finance these trips. I can enjoy catching up with old and online friends and relaxing and enjoying the hobby. This year was no different. I arrived mid afternoon on Friday, with the show room already open and a few folks setting up systems. Over the years, I’ve learned how to pack lighter, so my tables didn’t take too long to setup. Then, I spent time finishing some products for the show and chatting with the early arrivals.
I called it quits early Saturday morning (1AM or so Central), getting back to the room before 9:30AM. Traffic was lighter than usual, and seemed light all day. Sales were nominal, but steady. JiffyDOS sales were hampered by issues with my Willem programmer (after I returned home, I determined the configuration switches were faulty), preventing me from flashing some of the JiffyDOS versions.
Traffic stayed light all day, which is a bit disappointing because this is the second year traffic has been light. By afternoon, sales dissipated and I spent time fighting with the programmer. Oliver VieBrooks (Six of Style) came over late afternoon and we brainstormed on project ideas. Thus began the prototyping portion of the show. Given that sales had stopped, I decided to start on a project right then, and continued through the normal annual Saturday “C4 EXPO Golden Corral” dinner period (to be fair, I probably would have went, but we’d already enjoyed GC as a family earlier in the week).
Later in the evening, I worked on a project for Leif Bloomquist. Since the Fall ECCC ’09 show, Leif and I have been working to bring his VIC-20 MIDI cartridge to fruition. The main issue with the original design is the UART utilized, a MC6850 that is hard to source and pricey. I suggested rewriting the drivers to use the much more common 16X50-style PC UART ICs. I’d source a batch of them, but still needed to wire up one to Leif’s board so he could test.
By Sunday, I was out of energy, having worked on two prototypes the previous night. Thus, I packed up and left without much fanfare.
Seeing friends and talking hobby is always nice, but I feel the Memorial Day slot for this show hurts it quite a bit. Traffic was light, as previously noted, and sales were likewise light. Surprisingly, the Louisville crowd didn’t show, which hurt attendance more.
Powering CBM products can prove harder than initially thought. Many manufacturers choose the safe (and professional) route of including a power jack on the product and a plug-in power supply (wall wart). It’s a safe choice, but it carries a double cost. Power supplies tend to be $5.00 or so, and are often bulky and heavy, adding to shipping costs. On the consumer side, there’s a cost in finding another open outlet for the power supply and cable management.
For larger or more power hungry products, it’s a worthwhile tradeoff, but for smaller products, it is more efficient to power the product from the actual machine. Even today, USB devices can obtain power from the host computer, as long as they do not consume more than 100mA of power. Above that, and they require an external power source. Thus, for smaller CBM projects, it’s tempting to draw power from the console itself. On the Commodore VIC-20, C64, C64C, and C128, power can be sipped from the user port, cassette port, and/or expansion port, as well as from the joystick ports.
Over time, the cassette port has become the preferred port for power draw. Mainly, it’s rarely used. The joystick ports are smallest and probably cheapest to interface, but they are heavily used and can be prone to accidental disconnection. Still, the cassette port can prove challenging for interfacing in 2010. Most importantly, the .156″ 6 position connector is hard to source nowadays.
When I started offering products, I chose the cassette port because it offered a way to reduce prices for consumers, and the products used minimal power, making the port an ideal power source. With that decided, I simply needed to source the cassette port connectors and start selling products.
Oh, how I wish it were that easy! To understand the challenge, let me relate a bit of technical information. The standard PET/CBM cassette connector is a male 6/12 .156″ edge connector. For obvious reasons, Commodore created the male portion on the compute rmotherboard, as it was cheap (it requires no connector, just etching the connector conductive “fingers” onto the motherboard). To interface, one needs the female portion, which comes in 2 basic styles. One is designed for chassis (enclosure) mounting and contains 2 tabs on each end, each with a hole in them. They are called “mounting tabs”. The idea is to cut a hole in the case, mount the connector using the “tabs” and the holes, and then use the connector. The other foregoes the “tabs”. Since the “tabless” version is less useful (most use cases require a mounting option), it’s harder to source. Therefore, I initially obtained the more plentiful “tabbed” version of the cassette port connector for my power needs.
After I’d sold a number of units with the cassette port power connector, I noticed two things:
The installed connector was very hard to remove from the C64 or C128, as the cassette port on all CBM units is recessed into the case. Although I’d already know about the issue of removing the connector in general, that issue and this one didn’t concern me greatly because I surmised the connector would not often be removed.
The tabs prevented C128DCR usage. Commodore evidently reduced the width of the cassette port opening in the C128DCR case, making the tabbed connector too wide for entry. Although this was not a major issue (removing the tabs addresses the concern), it caught some folks off-guard and provided fodder for reviews and such.
Still, I had 150 of the tabbed connectors and no source for the non-tabbed connectors, so I pushed forward. Along the way, though, I both used up my stock of connectors and also managed to find a source for the more elusive non-tabbed connector.
With experience in hand, I decided to rework the power connection option for the product line. In addition to the previous issues, a few folks has lamented the lack of a cassette port “pass through”. Thus, I decided to fix all of the issues at once. The removal issues and the passthrough request could easily be solved by adding a small PCB to the connector (something to grab onto), and etching a cassette port male connector on the opposite end of the PCB. The C128DCR concerns required sourcing a non-tabbed connector. The resulting board would like similar to printer interface cassette port power adapters of the era. But it seemed a waste to create a PCB just to bring the signals out for passthrough usage.
Never one to ignore an opportunity, I decided to add some value to the power connector. In contemporary PCB design, it’s a fact that you’re paying for the area of PCB, rarely anything else. By creatively laying out the PCB, I managed to find space for a DIP-14 socket and a single pole switch. TO use the DIP socket, I mapped out the pin configuration for a small Atmel AVR microcontroller, the ATMEGA24/44/84. The cassette port signals all route to the AVR, as does the switch.
Mind you, I have no immediate plans to create a product using the uC onboard the connector. Thus, the uC is unpopulated, but one can easily add the socket and the controller. Nonetheless, I’m interested in idea for usage, and eager to see if hobbyists come up with independent ideas for usage.
In my continuing effort to sell more products for your Commodore computer, I determined users would buy more cartridge-based solutions if they could plug more into their machine at one time 🙂 Thus, given the lack of cartridge expansion options on the market at present, I am producing the X-Pander. Modeled off the CMD EX-3, CMD EX2+1, and the FB-3XP, X-Pander offers the following features and design aspects:
3 upright expansion slots
1 rear-facing slot for larger cartridge options (REU, etc.)
Each slot can be controlled via 8 DIP switches (GAME,EXROM,IO1,IO2,ROML,ROMH,POWER are selectable)
Slots #2 and #3 can swap IO lines (IO1->IO2, IO2->IO1)
Power LED indicators for each slot
Switches are located on right side for easy access
IO1/IO2 swap option located on right side for easy access
Long throw “piano” lever switches used for ease of configuration
Slot #3 can be accessed via top or rear port.
The prototype units have arrived and have been tested, production units are currently in manufacturing and should be in the store in a month. Current pricing estimates are $30.00.
The USB interface has become the ubiquitous interface for all kinds of peripherals, from file storage to cameras, wireless adapters to input devices. I wonder if there would be interest in a USB interface for Commodore machines, and how “intelligent” it would need to be. For example, I could easily design a “dumb” interface that simply maps the USB electrical interface into the C64/C128/VIC address space, but then each developer would be required to implement all USB protocol functionality. On the other hand, a more intelligent interface would help developers, but would cost more and some development would still be necessary, as many less common USB devices would require custom drivers to implement high level functionality.
Still, the idea seems a sound one. If the right balance is chosen, only software development would be required to use newer USB devices on the C64/C128. Software is much easier to develop and share, and if there are enough owners, it would be worth it to add support for USB devices in programs like GEOS, etc.
I’d appreciate any thoughts readers might have. Is this something you would find useful?
When people order a uIEC unit, some ask if an IEC (disk serial) cable is included or available. After looking in my stash, I did find a batch of Commodore cables, but two things concerned me. First, I have a number of actual drive units with no cables, and I wanted to ensure that each drive in my possession sported a cable in case it is later sold or traded. Second, when my stock is depleted, I will have nothing to offer.
While searching for other items, I came across a few suppliers who offer newly manufactured cables and could do custom lengths. At that point, I contacted Joseph Palumbo of JP PBM (Products by Mail), as he had expressed a need for additional IEC cables months before. As well, I recalled that Gideon Zweijtzer (of 1541 Ultimate fame) was looking for short (12″) IEC cables for the 1541U-II currently in production. I contacted Gideon and asked if he was interested in a purchase. Both Joe and Gideon were interested in moving forward, so I recently ordered 1300 cables of each size (standard 4 foot length and 1541U/uIEC preferred 12″ length). I can only imagine the number of boxes it will take to ship them here, but we will soon be offering black molded IEC cables in both lengths in the store, and Gideon will be receiving a large order to supply 1541U-II buyers.
I’ve received samples of the cable, and tested them. The cable is shielded, offers molded connectors on both ends, and offers 28 AWG stranded wire with an Aluminum Foil shield in addition to the bare shielding wire spiraling around the signal wires. The cabling is reasonably flexible (not quite a flexible as the original OEM cables, but not stiff) and 5.5mm in diameter. They should look right at home in a Commodore 8-bit setup.
When the Cincinnati Commodore Computer Club approached me in late 2008 to design a low-cost ethernet cartridge for the C64/C128, I underestimated the interest. Not only has C4 sold out of their stock, but mine is gone as well.
I’m happy to report another order has been made, and should be available in a month or so. No changes, though I may take the lead time to see if I can source some cheap EPROMs for the ROM slot on the cartridge and see what I might be able to bundle in the ROM.
At some point, I’d prefer to improve on the design, but it may very well be that this design is “good enough” for what people want to do.
Based on a customer request, I’ve designed a small adapter card that will allow C64 cartridges to be used in the Commodore VIC-20. The design is not finished, and suggestions are appreciated. Switches allow the IO and BLK select lines to be configured per cartridge. Barring any major changes to the design, I hope to have units available early 2010.