While replenishing stock of uIEC/SD daughtercards, I decided to improve the design a bit. Hopefully, this version will eliminate the need to offer the original daughtercard option.
- Buttons now on side of unit, for easier access. Buttons can now be used on C128D/C128DCR when installed.
- Operational Mini-USB connector. If desired, power with a small Mini-USB phone charger
- Complete 7805-based linear regulator section available for hobbyists. Parts are not present on the board, but should be trivial to source (2 caps and an LM7805)
- Oversized holes at front of board to allow PCB standoff usage. When powered via MiniUSB, standoffs can be used to level the PCB.
The new daughtercard works with all uIEC/SD versions (3.0,3.1, and 3.2). Stock will be arriving soon. Production boards will have sorter switch posts, for some reason, I accidentally ordered taller ones for the prototype.
It’s arguably a dubious distinction, and entirely academic, but it’s a record nonetheless.
For years, systems like IDE64 (and uIEC/IDE) have been able to marry large hard drives up to the Commodore platform. While I don’t personally know of such an installation, I would be surprised if someone doesn’t have a 500GB or 1TB PATA HDD attached to their C64.
This ignores the real question: Would all of the Commodore 8-bit software ever produced fill even a fraction of that space? I highly doubt it, though there is more than one would think. GameBase64 v7 was 5.3GB compressed, so I think one could fill 10-20GB with every version of every software package written for any Commodore 8-bit machine (PET to C65). In any case, nearly every contemporary storage solution for the Commodore line can handle that amount. Even the lowly Secure Digital drives, like uIEC/SD, support 32GB SDHC cards.
Cautious buyers will often inquire about the maximum drive size support for uIEC/SD. I often tell them that the uIEC/SD will support SDHC cards up to 32GB in size. That limit is a specification maximum, listed in the SDHC documents as the absolute maximum size allowed. That satisfies most people, but I do get followups on occasion about support for larger media.
Until recently, there were no larger media options, but 2009 saw the introduction of SDXC, which eliminated the 32GB limit. The SDXC cards were intended for cameras and camcorders, which had moved away from tape media to flash media like SD and demanded ever more storage space. As prospective buyers became more aware of SDXC, I received inquiries on whether uIEC/SD supported these larger media options. With no card to test, I countered that 32GB should satisfy any need, and one could always buy 2 of them as insurance against lack of space.
The topic of SDXC support came up recently, and I decided to update my knowledge. I knew about the format, and I knew that SDXC cards came factory formatted in Microsoft’s proprietary exFAT format. But, research uncovered many people who simply reformatted their cards to FAT32 and happily used them without any issues. I had previously assumed the SDXC protocol differed in significant ways from the SDHC protocol.
So, I decided to pick up a card and try it out. The prudent choice would have been to snag a less expensive 64GB card, but I decided to go all out and pick up a Lexar Professional 128GB SDXC (the largest I could find). At $160.00, it’s not a cheap chip of plastic, but I decided I could always use it as a second HDD in my laptop.
Upon delivery, I immediately imaged the entire raw card using Roadkil’s Disk Image utility. After 3 hours, a 128GB image was available, which I immediately compressed to 4MB and archived. It’s unclear if dumping the expanded image back to the card will put the data back in the original location in the FLASH memory, but it seemed prudent to save off the image in case it was later needed.
I then used a third party utility to format the entire card in FAT32 with 32768 byte sectors. I suspect contemporary operating systems will allow this as well, but I was in a hurry and the utility was handy.
I then copied 48GB of files to the card, to ensure new files would be forced into the area above 32GB. After 2 more hours of copying, I was finally ready to test. I popped the card into the uIEC/SD, powered on the SX64, and watched. The activity light blinked very fast (possibly the bootloader does not recognize the card size), and then the activity light came on for 6 seconds and then went off (system and card initialization)
I created a small BASIC program and saved it to disk. The activity light came on and lingered, forcing me to wonder if the unit had locked up with the light on. However, after 2:21 (2 minutes and 21 seconds), the light went off and the BASIC prompt returned. A disk directory showed the new file, and loading it was very fast. Subsequent saves were very quick, even after resetting the machine, power cycling, and re-installing the card. Files were correctly saved, and a nominal test of directory commands and disk operations showed nothing extraordinary.
Honestly, the entire event was anticlimactic. Ignoring the fact that there can’t possibly by 128gB of Commodore 8-bit files, I think it’s just too large a card for storage. I’ll continue to recommend 8GB cards: they deliver the best price per GB, one needs only a few to hold everything, and files can be easily segrated by platform among a few cards. Still, if you feel the need for maximum drive size, rest assured that any product offering based on a recent build of Ingo Korb’s sd2iec appears to support FAT32 formatted SDXC cards. However, I can say with certainty that the native SDXC exFAT disk format will never be supported in sd2iec, because it requires a license from Microsoft to use. Such an implementation would never be allowed to use the GPLv2 license, which sd2iec utilizes.
Sean Ober sends us this nice YouTube clip showing off his uIEC C64C internal installation. Thanks to Sean, and others who record their installations and uses. We welcome links to multimedia via our contact form. Please let us know who created the content so we attribute correctly!
Werner Weicht has released uIEC_Man, a GEOS utility that supports mounting and unmounting different disk images while in GEOS. The utility works with GEOS, Wheels, and Megapatch V3. As Werner notes, users are highly encouraged to read the included manual before starting the utility.
Ingo Korb has recently released version 0.10.2 of sd2iec, which is the firmware that powers devices like the uIEC. A list of enhancements is noted below. Because the uIEC can auto-update itself, users need only download the ZIP archive, unpack the contents onto a partition 1 of their SD card, IDE HDD, or CF card, and reboot.
Changes in sd2iec 0.10.2:
- Correct end of generated raw directory information
- compiling with all fastloaders disabled should now work
- ULoad M3 auto-exits when ATN becomes active
- Improve code size (to free enough space for…)
- Support new fastloader: ELoad Version 1 (the one used by EasyProg)
Rik Magers managed to stuff a uIEC into a tiny little enclosure that looks like a miniature CBM 1541 case. More details are available at his blog.
Even though there’s not much to tell, some folks asked about the differences in the new v3.2 uIEC/SD design. A picture is worth its weight in gold here, but I’ll also point out some less apparent details.
- Due to the new SD socket footprint, I was able to push the edge of the socket further from the edge of the board. This should help with implementations sitting behind thick plastic cases.
- Two small half moons (on the top left and bottom right) should allow the unit to be mounted in a Hammond 1551RBK enclosure.
- Although not populated on the PCB, there are pads for a Dallas DS1307 (or compatible) RTC with battery backup. The battery pins are shown on the right of the new PCB, while you can make out the watch crystal footprint below them on the right side.
- The LEDs have been pushed further outside the PCB. Truly, the assembly house went overboard on the first batch, but they should stick out to the edge of the SD socket.
Nothing else, I am afraid. I tried to add device jumpers to the design, but ran out of space and time to route the pads. The rest remains the sames, including:
- Pinout. v3.2 shares the same pinout as v3.1 and v3.0
- Mounting location. The mounting holes are in exactly the same place. Though the SD socket has mover 1/8″ further out, the PCB will fit in exactly the same place as previous designs.
- Same uC. The Atmel ATMEGA1281 is still in use, as is the 74LVC06 serial bus driver
As of tonight, the last of the uIEC/SD pre-orders have finally shipped. In fact, for the first time since early May, we are caught up on order fulfillment. Now, I can relate some features of the new uIEC/SD daughtercard option:
- Two (2) IEC connectors. No need to ensure the uIEC is the last item on the bus
- 3 uIEC/SD connectors (one populated by default). One is designed to point backwards from the daughtercard (for a horizontal setup), while the other two are vertical. (This means users can reposition the unit for ease of use, or can utilize more than 1 uIEC on the same daughtercard)
- Integrated power plug. No more pigtail wire to break.
- RESET button on board.
- Selectable uIEC/SD RESET operation. Removing the on-board jumper will prevent computer resets from affecting uIEC/SD unit.
Of course, the original Daughtercard remains available for those who prefer a minimal approach. The original daughtercard works best for C128D/DCR users, while the new unit works best for other machines.
The new unit will be available as an option in the store shortly.
After what seems like an eternity, the first 50 uIEC/SD units have been shipped from the assembly house. Exhibiting the longest design/manufacturing cycle I’ve ever witnessed, they’ve been unavailable since late April, 2011.
For those new to the saga, the normal stock re-order process in early May ran aground when the specified SD socket was unavailable for purchase. Though the socket had been discontinued (and the manufacturer did send me an email), the sales distributor showed (and allowed me to order) a last batch of units. I had no idea the distributor would be overcommitted and call notifying me they could not fulfill the order. That call set off a multi-week effort to find alternate stock, which then morphed into finding another option that fit the footprint, and finally resulted in redesigning the board to accommodate a new SD socket option. That delay ate up the entire month of May and part of June.
Things started getting interesting in late June, as I awaited new stock. First, the date slipped, which was not altogether surprising (it was but an estimate at best). Then, the assembly house sent word the DIN6 IEC connectors would not fit in the daughtercard footprint. This was not a showstopper, as I had sourced connectors for another project that would work. A while later, the assembly house IMed on a Thursday night that the new SD connector would not fit the design. I double-checked the PCB design and measured the sample units. Everything looked correct. I asked for a picture to view the issue. They promised one later that day. But, they are a half day ahead. I received it the end of their day, Friday morning here in the US. By that time, they had gone home for the weekend. Looking at the picture, I immediately solved the problem. They were trying to solder the old SD socket onto the new PCB design. Still, that wasted time.
Luckily, after nearly suffering heart stoppage over the SD socket issue, the rest of assembly went relatively smoothly. Complicating the shipment: most pre-orders specified a daughtercard option. Thus, both items required assembly before any orders could be filled. As well, I produced the new daughtercard design in this order.
Now, to see if my design skills are good enough to overcome the lack of prototype assembly and testing.
My plan to ship uIEC/SD units by end of June was evidently overly optimistic. It took longer than expected to modify the uIEC/SD PCB design, and the design had to be checked more thoroughly since I will not have time to assemble and test a sample before ordering the SMT stencil (a metal “mask” laid over the PCB that is used to force solder paste to only deposit on the exposed PCB pads) and a production PCB run. Thus, I am crossing my fingers that the redesign is correct. The new design looks very similar to the older, though I have designed the PCB to fit a small Hammond 1551 enclosure (the 2 half-present holes on the corners of the board).
At this point, I’ve moved the expected ship date to July 12, and alerted customers about the delay.