Sometimes, a product gets lost on the way to final production. Our QuadPortIEC 4 port IEC bus hub is one such product. After announcing the design here and showing off completed boards here, we focused our attention on the recently introduced ZoomFloppy and then the EasyFlash 3. Finally, we sent the boards off for assembly, but still felt a bare board with wires would simply not work as a product. Finally, about a year or so ago, Commodore enthusiast Jim Peters in Iowa requested some bare PCBs and assembled units for personal use, which we supplied. He took it upon himself to machine finished cases for the units, with fabulous results. Thus, we hired him to supply finished cases for the remaining stock, and now can offer them in the store.
The design has not changed; QuadPortIEC is nothing more than a “dumb” IEC hub. ATN switches on the front for each port allow “silencing” of each bus segment, but that’s the only functionality exposed.
Still, we are glad to finally put the units in the store, where they will sell for USD$30.00. Since the units fill out a small flat rate box, we may need to adjust shipping charges for buyers.
RETRO Innovations will be traveling to Brookfield, WI this weekend for the 2013 Midwest Gaming Classic. We’re simply attending, not manning a store table, but feel free to email us if you’d like to place an order for pickup and skip the shipping costs.
Since we don’t have enough things to keep us busy, we’ve been on an arcade machine buying spree over the last few months, picking up:
a KLAX upright conversion, in great condition
a Pole Position, in good condition, working, but missing a few sound effects
a non working asteroids, in rough condition
a Shoot the Bull game in a Ms. Pac Man cabinet
Some Championship Bowling ROMSTAR game, in a Super Pac Man cabinet (purchased for the cab, monitor and wiring).
a Gyruss, complete and working
a Defender, with monitor issues
a StarFire unit, in a Defender case, with PCB issues (but, partially working)
Since our goal is to see if there are product opportunities in game restoration for RETRO Innovations, buying machines that need help seemed appropriate. KLAX was a fluke, as it’s in great condition, but the others all need some TLC for optimum operation. To start that process, a trip to MGC is required. We know the Ms. Pac Man needs to be converted back, and that requires some parts (we have a known working PCB for the game already). Asteroids might be beyond help, and so might be parted out, while the Pole Position just needs some TLC on the PCB and general cleaning.
It’s an interesting exercise, and they should be fun to play… err test!
The difference between a project and a product often boils down to looks. Along with a professionally designed and manufactured circuit board, a proper enclosure completes the package.
Thought we have long offered a un-machined cartridge case with 64NIC+ Ethernet cartridges, we had resisted the thought of milling cartridge cases. In the case of the 64NIC+, the Ethernet jack machining is tough and prone to error. A proper CNC milling machine is required to efficiently handle such a design. However, the EasyFlash 3 did not require so complex a solution to correctly machine a suitable cartridge enclosure. Some simple jigs on the drill press and creative use of drill bits ably substituted for a CNC mill. As a result, EasyFlash 3 arrives in an optional fully machined enclosure.
The red color choice was somewhat arbitrary, as we have clear enclosures. Still, translucent red and the red LED on the unit seemed to fit well together. I hope you agree.
The wait is almost over for VIC Expansion enthusiasts. After a significant delay, X-Pander 3 VIC units are nearing the end of assembly. As the photo shows, only the IO2/IO3 SWAP jumpers are left to assemble. We hope to add this to the store by the end of the week.
Given the width of VIC-20 cartridges, the finished units will have the switches located underneath the board, but will otherwise look identical.
As the picture suggests, the unit shares the same basic layout and operation as the X-Pander 64, but adds additional switches to control BLK and RAM lines.
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.
Well, C2N Power! v2 is manufactured and the first few units are assembled, Hopefully, this weekend I can verify electrical operation and then I’m hoping to ship a few of them to developers for software creation. The offer is still open for assembly programmers who want a small weekend challenge.
The unit is shown assembled for Real Time Clock operation, with a Maxim DS1307+ installed under the unit, with I2C pullup resistors and the MOTOR line conversion transistor in place. On top, a lone 3V3 Lithium battery powers the RTC when CBM power is absent.
It’s taken a while, but EasyFlash 3 units are nearing completion. All SMT components are installed, and the LED, switches, and jumper pins are all that remain. I am hoping the assembly house can ship this week so I can deliver units starting next week.
I’ve asked that the first 100 units be shipped before the second 100 are completed.
Since many people have ordered cases, it looks like I have some holes to drill before shipping 🙂
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.
For reasons I can only guess, Commodore created it’s IEEE-488 cables in two forms. The first was a standard Centronics 24 to Centronics 24 cable, with each end of the cable offering a passthrough connector (male on the top, female on the bottom). This cable could be used to connect any CBM IEEE-488 peripheral to any other CBM IEEE-488 peripheral, creating a chain of peripherals through a single cable. However, the second, and more important cable was the one that connected the PET or CBM machine to the first peripheral of the chain. And, on one end of this cable, Commodore specified a .156 12/24 female edge connector.
Ordinarily, I’d guess the reason was cost reduction, and that might indeed be the truth, but IEEE-488 cables in general were not cheap, and creating a specific non-standard cable that only Commodore would use seems contrary to a cost reduction move. My next thought was “vendor lock-in”, but if that were the reason, why bother with standard cables anywhere?
There are other theories, of course, and I don’t spend much time considering why these things occur. However, such a design decision makes a real impact today, more than 30 years since the cable debuted. Namely, the non-standard cables are hard to find, and no one produces them anymore (standard IEEE-488 cables are still produced in significant quantities). Since each PET/CBM machine needs exactly one of these cables, they are somewhat important.
One can always cut a standard cable and wire up a 12/24 connector, but I recently saw a neat idea on a classic computer mailing list that concisely solves the problem: An IEEE-488 connector adapter. The adapter is simplistic to an extreme. One end contains a 12/24 .156″ connector, while the other contains a standard Centronics-24 connector. Coupled with a standard cable, the search for this elusive connection option can be over.
The design seems so simplistic, I’m wondering if there is something else that can be added to the design before I send it off for production. Comments are welcome.
Given a need to order more C2NPower cassette port power adapters, RETRO Innovations has revamped and expanded the functionality of this tiny product. In addition to providing a tap for 5VDC for powered peripherals and a layout that includes holes for the Atmel ATTINY24/44/84 AVR microcontrollers, the new design also includes support for the MAXIM DS1307+ (and compatibles) Real Time Clock and the 24CXXXX line of serial EEPROMs.
Before we roll this new design into production, we’re looking for a couple of proficient assembly language developers who could help us develop some functions for reading and writing the time to the RTC and reading/writing data to the EEPROM. The protocol is I2C, using the MOTOR and WRITE lines for SCK and SDA, respectively. The only nuance is that MOTOR line is inverted. We’re hoping some folks would like to compose a bit of code in exchange for a free C2N Power! unit (with EEPROM and RTC supported). Ideally, we’d like to create some common 6502 code for the basic routines that can be used on the PET, 40XX, 80XX, VIC, 64, and C128 machines with only minor variations among platforms.
Thus, if you or someone you know could help, please let us know via our contact page. Feel free to repost as appropriate.