New SD2IEC from NKCElectronics

[Unseen]

For me, the most exciting thing is the ability to print to a modern USB printer (Laser too) and to use a USB Pen-drive like a CF or a SD, do you think it will be possible ?

That depends if you want to do it standalone or with a PC as the "interface" between the printer/pen drive and uIEC. Doing it standalone requires an USB host interface(*) for uIEC which isn't really feasible with the current harwdare - you'd have to build an addon that would probably have more computing resources than uIEC itself.

With a PC as the interface access to its drives and printer should be possible.

(*) USB is designed to move most of the complexity to the host side so devices can be cheaper. This has the side-effect that for small embedded projects it's easy to add USB device support, for example by using a USB-to-serial converter chip (which is what's planned for uIEC), but there are very few options to add USB host support. One of the few I know would be to use a controller that includes USB-on-the-go support (simplified host plus client in one device), but the chip uIEC is based on is not one of those.

[brain]

For me, the most exciting thing is the ability to print to a modern USB printer (Laser too) and to use a USB Pen-drive like a CF or a SD, do you think it will be possible ?

USB printer from uIEC directly, no. It would be impossible to develop the correct drivers for all the printers on the market.

Pendrive, it depends. I got a VNC1L, which is a USB host controller on a chip, but I am just not convinced that it's worth it. You can buy SD cards and USB-SD adapters that are the same size as a flash drive for about the same as a regular flash drive, so why add the complexity?

And just because we are speaking of future planning, why not a single interface with CF+SD+USB(PenDrive) support ?

uIEC/IDE+CF will soon offer SD support (it's in the sd2iec main codebase now, just no HW built as yet. That's probably as close as I'll come.

But, the code is GPL, so anyone can do as they please.

Jim

[PaulQ]

For me, the most exciting thing is the ability to print to a modern USB printer (Laser too) and to use a USB Pen-drive like a CF or a SD, do you think it will be possible ?

USB printer from uIEC directly, no. It would be impossible to develop the correct drivers for all the printers on the market.

I take it that the days of intelligent printers which can be used with a generic driver have long been over.

[brain]

In a word, yes.

Jim

[eslapion]

USB printer from uIEC directly, no. It would be impossible to develop the correct drivers for all the printers on the market.

The vast majority of printers on the market are compatible with PCL or Postscript or both.

Would it be possible to simply support one of these 2 protocols or both?

[brain]

USB printer from uIEC directly, no. It would be impossible to develop the correct drivers for all the printers on the market.

The vast majority of printers on the market are compatible with PCL or Postscript or both.

Would it be possible to simply support one of these 2 protocols or both?

Do you have some information to back up those statements? My experience with most of the cheaper HP,LexMark,Canon,Brother,and others are that the printer doesn;t support any high level language. It handles only low level commands, expecting the printer driver to render the page into a set of printing primitives, to minimize the processor and memory demands of the printer engine.

In any event, I'd rather spend my time attaching the uIEC to a PC/Mac, and let the normal printer drivers be used.

Jim

Jim

[nbla000]

Pendrive, it depends. I got a VNC1L, which is a USB host controller on a chip, but I am just not convinced that it's worth it. You can buy SD cards and USB-SD adapters that are the same size as a flash drive for about the same as a regular flash drive, so why add the complexity?

Yes, you are right.

uIEC/IDE+CF will soon offer SD support (it's in the sd2iec main codebase now, just no HW built as yet. That's probably as close as I'll come.

So another feature for your big baby


PS: Schema sent me some positive tests with EasyLoad+ and his Modded Vic with embed uIEC/CF on drive 10, i may easily change DIR by typing this command:
@"CD:DIRNAME" or @"CD:FILE.D64"
Very nice, and by disabling Turbo (using F5) you may load any file from uIEC, if you report me asked tests i may change EasyLoad so to load a file even if turbo is ON but using standard Kernal routines of course.

[Unseen]

Very nice, and by disabling Turbo (using F5) you may load any file from uIEC, if you report me asked tests i may change EasyLoad so to load a file even if turbo is ON but using standard Kernal routines of course.

Are you trying to ask how you can detect a uIEC? Don't rely on M-R, its results are unstable except for a few addresses that were specifically hardcoded to convince certain C64 software fastloaders to use the kernal code (Action Replay 6) or to tell it to upload its 1541 code (Dreamload, used by quite a few demos).

The way I recommend to detect the type of an attached drive (and which I think was recommended by Commodore) is to send the UI command and read the error channel. Everything that works properly should return a 73 error with an identification string in the text part. Many speeder roms for a 1541 change the text, but I haven't seen one yet that doesn't say 1541 somewhere. If you really want to test specifically for uIEC, look for UIEC or SD2IEC in the string, although I can't gurantee that it will catch all future hardware based on the same code (probably yes, at least if I convince potential troublemakers that this string should identify not just the hardware but also the software =) ).

[nbla000]

Are you trying to ask how you can detect a uIEC?

Yes.

Don't rely on M-R

Yes, based on read docs it reports randoms values, right ?

its results are unstable except for a few addresses that were specifically hardcoded to convince certain C64 software fastloaders to use the kernal code (Action Replay 6)

Is exactly what i wish to check, AR6 ask for FFFE and FFFF values right ? uIEC for these specific addresses reports 0 and 0 while 154X/157X drives report 103 - 254 ($FE67) and 1581 drive report 3 - 255 ($FF03) so the basic code for a drive 8 is:

Code: Select all

10 OPEN15,8,15,"M-R"+CHR$(254)+CHR$(255)+CHR$(2)
20 GET#15,A$,B$
30 PRINT ASC(A$)"-"ASC(B$)
40 CLOSE15

And the logic is:
If the result is 103 - 254 ($FE67) i assume 1540/1541/1541-II/1541C/1570/1571 drives

If the result is 3 - 255 ($FF03) i assume 1581 drive

For any other result (0-0 too) i may use standard CBM routines.

By using the uIEC the result is always 0 - 0 or i may get random values ?

I'm wrong ?

[Unseen]

By using the uIEC the result is always 0 - 0 or i may get random values ?

Although you will always get 0-0 from there for now this will change as soon as someone reimplements the AR6 speeder for sd2iec because it's just a hack to convince AR6 to not use its speeder.

Don't rely on any M-R results, even if the address is currently hard-coded to return a specific value. We don't gurantee those results and might even make all of it user-configurable if we have to for increased compatibility (e.g. at least one of the currently-hardcoded addresses needs to change to convince CMDs FCOPY that we're a CMD drive with subdirectory and partition support).

[nbla000]

Although you will always get 0-0 from there for now this will change as soon as someone reimplements the AR6 speeder for sd2iec because it's just a hack to convince AR6 to not use its speeder.

I need an easy way to detect the drive model, AR6 uses this extraordinary easy mode while if i'm not wrong the 73 error reports the drive model just the first time...

Another way ? do you think that the AR6 routines implementations are imminent ? why not implement EasyLoad fastload routines too ? they are based on the Marko Mäkelä IRQ loader and slightly modified to load file name with 16 chars:
http://www.ffd2.com/fridge/io/irqloader.s

Are you the firmware developer ?
If you want i may supply you the full drive fastload code in ASM and i explain you how EasyLoad interface itself with the drive.

[Unseen]

do you think that the AR6 routines implementations are imminent ?

No idea, that depends on the free time and motivation of any possible contributors.

why not implement EasyLoad fastload routines too ? they are based on the Marko Mäkelä IRQ loader and slightly modified to load file name with 16 chars:
http://www.ffd2.com/fridge/io/irqloader.s

Oooh, commented code - what a luxury. =) It's certainly possible to implement it, although I'd be hesitant to do it myself if I can't test the result.

Are you the firmware developer ?

I started the sd2iec "project", Jim came in later and contributed lots of code, some other people added bits and pieces (e.g. some of the fastloader reimplementations).

If you want i may supply you the full drive fastload code in ASM and i explain you how EasyLoad interface itself with the drive.

That would probably be helpful, although I can't say when I'll get around to do anything with it because I'm currently busy with university exams.

[nbla000]

Oooh, commented code - what a luxury. =) It's certainly possible to implement it, although I'd be hesitant to do it myself if I can't test the result.

so you haven't a vic...

But using sd2iec or uIEC/SD or uIEC/CF may I update the firmware in someway ? in this case I may do tests... but you need to update the firmware and maybe I update EasyLoad too.

Are you the firmware developer ?

I started the sd2iec "project"...

The firmware or the hardware project ?

If you want i may supply you the full drive fastload code in ASM and i explain you how EasyLoad interface itself with the drive.

That would probably be helpful, although I can't say when I'll get around to do anything with it because I'm currently busy with university exams.

So you are a "young boy", this is the reason because you haven't a Vic...

My EasyLoad fastload code version is just for the Vic-20 (both PAL and NTSC) and uses 2 different codes for 154x/157x drives (originally made by Marko Mäkelä) and for 1581 drives a little bit efficient (originally made by Pasi Ojala).

Currently to check the drive, I use this code but in ASM of course:

Code: Select all

10 OPEN15,8,15,"M-R"+CHR$(84)+CHR$(255)+CHR$(1)
20 INPUT#15,A$
25 PRINT ASC(A$)

Thus i read the $FF54 byte in ROM and if the result is 76 ($4C) or 108 ($6C) EasyLoad assumes a 1581 drive else a 154X/157X, this is based on VIMM fastload code.

I wish at least change this behaviour because i need to turn OFF the turbo to use unsupported drives.
The AR6 logic is perfect for me and if I implement it, now it works with uIEC/sd2iec but do you think that in the future if you implement the EasyLoad emulation on the sd2iec firmware you may leave the AR6 hardcoded code too ?

Current EasyLoad turbo logic is:
Detect if turbo is OFF in case skip and use kernal routines (this work with sd2iec firmware)
Detect drive 1581 or other (i wish to change this part)
Move drive code with "M-W" command (sd2iec firmware simply ignore this command right ?)
execute code on drive (Send "U3" command, so code reside on $0500 to the drive, i think this is the start point for the sd2iec EasyLoad emulation)

[Unseen]

so you haven't a vic... :oops: :wink:

I think I still have one, but I have no idea where it is.

But using sd2iec or uIEC/SD or uIEC/CF may I update the firmware in someway ?

The source code is available (http://www.sd2iec.de/cgi-bin/gitweb.cgi ... ;a=summary is a browser for the repository, if you click on "tree" you can browse the current revision and download a tgz file of it with the "snapshot" link on that page), patches can be sent to the mail address in the README.

I started the sd2iec "project"...

The firmware or the hardware project ?

It's a bit complicated, so I'll better tell the long version of the story: In 2007 someone (Shadowolf) on the german forum64.de created a very small PCB for LarsP's MMC2IEC, suitable for integration into a C64DTV. After a few revisions he offered ~100 all-parts-included kits to people on the forum, I got two of those. It was obvious after a few tests that the MMC2IEC firmware was quite "lacking" in features and compatibility and improving those points would mean large-scale restructuring of its source code.

So I just went ahead and dropped almost all of it (except for low-level SD card access which was changed so much to improve card compatibility that it doesn't look very similiar to the original today), grabbed a FAT library that offered a reasonable compromise between features and space requirements and started to write new IEC code based on a 1571 rom listing. That software was called sd2iec and originally ran only on MMC2IEC hardware.

Some time later it was obvious that the demand for the hardware kits was still high but instead of just doing another run of the same PCB Shadowolf decided to address a few issues of the original MMC2IEC design - the drive strength on the IEC bus was quite low which limited the number of Commodore drives connected in parallel, there was no crystal[1] and you could already tell that sd2iec would outgrow the 32K rom/2K ram controller used by MMC2IEC soon. The redesigned boards were called SD2IEC because they wouldn't run the MMC2IEC code anymore. The boards offered by NKC are based on those and as far as I know Shadowolf had some input into their layout (he's very pedantic about circuit layout best practices...).

Jim Brain joined the software side in January 2008 and contributed (among lots of other things) patches to run sd2iec on his uIEC design as well as long file name support for the FAT library. Without him the code probably wouldn't support multiple partitions (nobody ever partitions their SD cards, but it seems to be popular for IDE drives) and other things I can't remember right now.

Other people that were involved are M. Kiesel who offered an AVR implementation of the JiffyDos byte/block transmission code when I couldn't figure out the 1541 rom disassembly (although I rewrote his version to save space...) and Thomas Giesel who did the Final Cartridge III fastloader/-saver and Dreamload reimplementations.

[1] The internal oscillator of the controller is good enough for standard IEC and some turbo protocols, but the first speeder I selected almost at random requires a clock precision so high that we've had someone complain about corrupted files with it because he had used the wrong loading capacitors for the crystal on his perfboard version of the circuit.

My EasyLoad fastload code version is just for the Vic-20 (both PAL and NTSC) and uses 2 different codes for 154x/157x drives (originally made by Marko Mäkelä) and for 1581 drives a little bit efficient (originally made by Pasi Ojala).

Does it use the same drive-side code for both PAL and NTSC?

I wish at least change this behaviour because i need to turn OFF the turbo to use unsupported drives.

I still recommend UI, that is implemented by more "alternative drives" than M-R and even if it isn't you'll get something from the error channel that won't match any known drive signatures.

The AR6 logic is perfect for me and if I implement it, now it works with uIEC/sd2iec but do you think that in the future if you implement the EasyLoad emulation on the sd2iec firmware you may leave the AR6 hardcoded code too ?

As said before, everything returned by M-R can change in future firmware revisions. If you rely on it and your code breaks the best you can expect from me is a "I told you so" because I see it only as a way to increase compatibility with legacy programs but not current projects that could implement more reliable detection methods.

Move drive code with "M-W" command (sd2iec firmware simply ignore this command right ?)

Almost - if you try to use M-W to write to address 119 (decimal) it is interpreted as an attempt to change the device address as 119/120 are the two bytes you need to write to on a 1541 to temporarily change the address.

All other writes are checksummed and discarded, this way we know which speeder code was uploaded when a M-E is received and can call the reimplementation if the checksum matches a known one. Nothing that is reimplemented has used U[2-6] yet, but that could be handled the same way as M-E.

[brain]

I'll add my portion of the history here as well, just so it is captured somewhere as useless trivia:

I started uIEC in early 2005 out of frustration with an earlier project that tried to bridge IEC to a PC. I theorized that my IEC routines and PC routines were messing up timing, so I thought designing an HD-only interface would simplify the design and would allow me to get IEC code running. By mid-2005, I had a design that supported CBM serial and JiffyDOS, but the JiffyDOS routines were corrupting a byte every so often, and that was difficult to debug. I put the project on the shelf, admitting my grasp of JiffyDOS was not complete enough to make the solution work. As well, though I had implemented a home grown FAT library, it was read-only.

In late 2007, I started to clear out some of my old projects, and decided to try finishing up uIEC again. After I managed to add write functionality to my FAT library, I found out that, in the intervening years, a very robust FAT library had been created, so I decided to switch my code to use it. Since it did not support long filenames, I went to work adding my LFN code from my library to the new one. As well, I had designed my library because I could not find a FAT library in 2005 that would allow multiple files open without requiring significant RAM, something the small controllers tend to lack. This new library handled that with some restrictions, so I went about removing those restrictions.

After I modified uIEC DOS to support the new library, I turned my thoughts to MMC2IEC. I had downloaded it when it came out, and also had dloaded sd2iec as well, thinking that one day I would peek at the code and see if there was anything of interest. Well, as I opened sd2iec, I noticed it used the same FAT library I had just modified to support LFNs, so I offered the code to Ingo. Then, I thought I'd just pull the IEC routines from sd2iec into my uIEC DOS and use them, since JiffyDOS was working. But, as I started to rework the code, I decided it would be much more useful to just port the useful pieces of my codebase over to sd2iec and modify sd2iec to work with the already produced uIEC boards. Besides the LFN support, probably my main contribution was work on CMD partition and subdirectory support.

I mention this all because I did resist the notion of using sd2iec in uIEC initially (it's so much harder to learn someone else's code than to write it yourself, and it will always be Ingo's code, with my meager mods). But, after a few days of consideration (and a few hours of trying to push sd2iec code into the uIEC DOS codebase), I decided there was no value in the approach. While I could still claim uIEC DOS as my own, it would have to acknowledge sd2iec contributions as well, I would be forced to retrofit new sd2iec functionality into uIEC all the time, and it would generally be re-inventing the wheel. So, I cleaned up the final uIEC codebase, checked it into source control, and deleted all the files, replacing them with sd2iec and working to get it running on uIEC. As a testament to the portability of the code, it did not take long.

Since a whole year has passed, I'm very impressed about the value of the decision. sd2iec is a much more robust codebase than mine ever was (C is not my strong suit, as I last used it in college, and that was a while ago), it's been very helpful to bounce ideas off of someone who is actually in a position to provide useful input, and I think some very good ideas on how to interface the new with the old have come of the collaboration.

Jim