uIEC (Micro IEC) Update
Jim Brain
IEC-based CBM computer (VIC/64/128/etc.) to utilize a IDE drive
formatted with a FAT filesystem or a CompactFlash (CF) card with such a
filesystem.
uIEC development took some very interesting paths this year (more
details if there is interest), but I am happy to report that the unit is
working and I'm now concentrating my efforts on making it CF-card
agnostic (testing various cards I have here), and trying to increase
compatibility. I have a deadline to have units for sale in time for the
CCCC expo in late June.
I've taken advantage of the long list of features in another project
(sd2iec) to make uIEC even more compatible and useful. So, here is a
combined list of features:
o Supports IDE and CF cards (uIEC supports IDE/IDE, IDE/CF, or CF/CF if
you have an IDE->CF adapter for the second card. uIEC/CF supports
single CF card)
o Supports drives of any size, though support for >137GB drives needs
more testing. :-)
o Supports FAT12/16/32 partitions of any legal size
* Supports partition-less cards/drives, or up to 4 primary partitions or
3 primary and 12 extended partitions. (Email me if you have more than
12 extended partitions on a drive :-)
o Supports FAT Long filenames
* Transparent support for PRG/SEQ/USR file extensions, with REL support
planned.
o Transparent support for P00/S00/U00 files, with R00 support planned.
o Supports read and write of D64 images.
o Block level disk access supported on D64 images
o Most CBM DOS commands (Scratch,Initialize,Rename,etc.) supported.
o CBM general config commands (U0, U+, U-, UI, U9, U:, UJ) supported.
o CBM block level commands (B-R, B-W, UA, U1, U2, UB) supported when in
D64 image.
o CMD-style partition ($=P) support
o CMD-style subdirectory (MD,CD,RD) support.
o CMD DOS Commands (G-P, G-<shift-P>) support.
* Long form CMD directories ($=T:*, $=T:*=L) supported
o 1581-style/CMD-FD/HD-style wildcard matching supported ($:JIM*RAIN)
o JiffyDOS fast loader equipped (PAL and NTSC support). Can be enabled
or disabled via DOS command.
& Firmware can be updated by copying new firmware file to root dir of
first drive, first partition and resetting unit.
(* noted items are in my WIP codebase, & are features in mainline
codebase I need to enable in my variant)
I want to publicly thank Unseen of sd2iec for creating a very impressive
codebase that made my feeble original attempt pale in comparison.
Although I will regret not being the originator of the uIEC firmware, it
simply made no sense to duplicate all of the features and require sd2iec
to re-implement features already in the uIEC project. I think Unseen
also appreciates another developer on his firmware project. My
additions have primarily been to the FAT LFN code, the CMD HD commands,
and multiple drive support.
In process is time-based directory pattern matching (>00:00:00 and
<00:00:00), support for programs that determine drive type via M-R, and
D71/D81 image support.
I'll refrain from listing the ideas in the enhancement bucket, but there
are quite a few. At this point, I am prioritizing features that might
make HW changes necessary, for obvious reasons. Firmware-only additions
can be made after shipping.
I'm happy to answer questions in the thread.
Jim
christianlott1
g64 support?
how difficult is rel support?
selling price?
push button (manual) disk switching?
rber...@value.net
> I have a deadline to have units for sale in time for the
> CCCC expo in late June.
Congratulations, Jim (and Unseen, too)! I look
forward to reading reports of the big "reveal" at the
4C's Expo.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Jim Brain
> how compatible will this be with fast loaders/copy protection?
At present, except for JiffyDOS and TurboDisk, none are supported.
However, Unseen has this idea of checking the CRC of the downloaded
drive code (the code the computer sends to the drive to enable a
fastloader), and then just turning on an emulation of the fastloader in
question. JiffyDOS is coded in, but Turbodisk support (a SW fastloader)
is supported in this way, so the idea is sound. Of course, implementing
a new fastloader requires identifying the speeder download code (easy)
and someone to write a description of how the code works (not so easy)
so it can be implemented in AVR ASM or C.
I'll answer the second question with below:
> g64 support?
Not at present, but I don't see any issue with it, just needs time to
code up. All errors that are supported by G64 images would then be
supported. The "on-deck" work for generalizing image support will make
it easier to write a handler for G64 images and even other images, like
HD and FD images, or D82 (8250, as I recall) images. A tip of the hat
to Unseen's ability to abstract things in the codebase.
> how difficult is rel support?
Not difficult, but we are struggling to identify the value of including
earlier rather than later. It's in the "things that need to be there at
some point" list, but so far I've only found BBS operators that care
about it.
> selling price?
I'm shooting for $50-$75, though I need to get a new bill of materials
list priced, as it's been a while. The uIEC/CF will be cheaper, as it
has fewer components.
> push button (manual) disk switching?
I forgot that feature, as I don't use it. It's in there. And, you can
have one disk change button per physical drive. You can set the
swaplist via open15,x,15,"XS<partition>//cmd/path/to/file/:filename, or
it will use AUTOSWAP.LST in the current directory. the file is simply a
list of directories or image files, and do not need to be in the current
directory, or even the current partition (or drive, for that matter).
Jim
ramswell
Got any pics of it, Jim? Also, what's the cost on it and is based on
"FLASHING?" Just curious as if it's "similar" to the RR-NET or the
MMC64, then we would be able to download the updates and install them
via the sd card/thumb drive.
Charles
Suudy
> > how compatible will this be with fast loaders/copy protection?
>
> Fastloaders:
>
> At present, except for JiffyDOS and TurboDisk, none are supported.
> However, Unseen has this idea of checking the CRC of the downloaded
> drive code (the code the computer sends to the drive to enable a
> fastloader), and then just turning on an emulation of the fastloader in
> question. JiffyDOS is coded in, but Turbodisk support (a SW fastloader)
> is supported in this way, so the idea is sound. Of course, implementing
> a new fastloader requires identifying the speeder download code (easy)
> and someone to write a description of how the code works (not so easy)
> so it can be implemented in AVR ASM or C.
That is a good idea, though I would suggesting something less
vulnerable to collisions such as SHA-1 or MD5. CRC's are great a
detecting errors, not so good at protecting from collisions.
Pete
Joe Forster/STA
> vulnerable to collisions such as SHA-1 or MD5. CRC's are great a
> detecting errors, not so good at protecting from collisions.
CRC is (relatively) easy to compute. Also, we're not talking about
several megabytes of data, only a few hundred bytes.
Jim Brain
> Got any pics of it, Jim?
Also, what's the cost on it and is based on
Um, as I noted in my original message, probably $50-$75.00USD.
> "FLASHING?" Just curious as if it's "similar" to the RR-NET or the
> MMC64, then we would be able to download the updates and install them
> via the sd card/thumb drive.
As previously noted (did you read all of the original post?) the
firmware supports upgrades via placing a new firmware file on the CF
card and rebooting the interface.
JIm
Jim Brain
Since we'll know all of the CRCs ahead of time, we'll continue to use
CRC until we find collisions and have to change course.
Implementing MD5 or SHA-1 in a uController is not a trivial effort.
Jim
Suudy
> Joe Forster/STA wrote:
> Since we'll know all of the CRCs ahead of time, we'll continue to use
> CRC until we find collisions and have to change course.
It was just a suggestion for the future. However, since the hashes
are known ahead of time, and have no external dependencies, you are
right, it can change later.
> Implementing MD5 or SHA-1 in a uController is not a trivial effort.
I wrote SHA-1 for a crappy 16-bit uC. It is in portable C (even
taking into account endian issues) so should be portable to just about
any uC. Plus, there are lots of implementations available, such as
LibTomCrypt, which is public domain.
Now, I'm not saying it would necessarily be fast....
Pete
vxvxc
I'm sure you've posted it elsewhere or it's been posted already, but are
you taking pre-orders for the deadline at the C4 Expo? If so, where do I
sign up?
I've salivated for this device ever since you showed it at the LUCKY Expo
years ago.
Thanks,
CJ
"Jim Brain" <br...@jbrain.com> wrote in message
news:sKRMj.67117$TT4.24486@attbi_s22...
Jim Brain
> Jim,
>
> I'm sure you've posted it elsewhere or it's been posted already, but are
> you taking pre-orders for the deadline at the C4 Expo? If so, where do I
> sign up?
I should, shouldn't I. Hadn't thought about it, but I will try to get a
parts list and price sheet for it this week, so I can figure preorder
prices.
I have the following punch list to complete before I will sell the unit:
o diskchange button needs to work (Code is already there, I just need to
assign a bit for this button to hang off of)
o dual IDE drive support. I have dual code in, but I'm having troubles
with the slave IDE channel at present. Some drives don't like it.
Debugging.
o firmware update provision. The source already supports it, but I need
to load the initial bootloader into the units and test, I've never used
bootloaders before.
The rest of the stuff (16MB partition support et al), is not as
critical, since it can be added later via a firmware update, but the
three above I feel are crucial.
Jim
SbM
> I'm shooting for $50-$75
Such a great project at such a low price? I'll buy one straight away!
Keep up the good work, Jim ;)
--
[SbM]
<http://sebastienmarty.free.fr> - <http://tradintosh.free.fr>
<http://sbm.ordinotheque.free.fr> - <http://palmiciel.free.fr>
"If the French were really intelligent, they'd speak English" (W. Sheed)