Ethernet version

[Mike Paull]

Hi Group,

This is more directed at Jim however I wonder what others think of this idea. 

The uIEC has been (I think) a landmark device for our Commodore computers, a device which has finally provided the masses with cheap high capacity storage, something that Jack T surely would have approved of :)

Anyway, for some time I have wondered if the next phase of such a device might be to take advantage of NAS drives. I don't know about the rest of you but thanks to torrents and various web and ftp sites I now have quite a collection of software which I keep on one of my NAS drives so I can readily access it from Vice when I need to. 

As I still have my original Commodore 64 and like using it I wonder if there will ever be a uIEC-Ethernet that would allow access to such drives for real Commodore equipment?

Mike

[RETRO Innovations]

I have considered and would like to pursue the idea. Since there has
been some time to think about the design, I have went through some
iterations:

The first was a device attached to a serial port. Some people saw this
in 2005 SWRAP as VIP (Virtual IEC Peripheral)
Next, since serial was out, I switched to a USB controller.
Then, I realized tethering to a PC seemed a bit limiting, and required
PC code to be constructed, so I swapped out the USB option for a WizNET
controller
Then, I decided to migrate the design to ARM, since many ARM controllers
have the MAC portion of Ethernet built in, reducing cost.
Then, I realized that many may no longer want a wired option, so I
started looking into Wifi solutions to add to the ARM.

So, my current design includes an ARM and a Wifi module, but retains a
footprint for the Ethernet port and PHY items. Both require a TCP/IP
stack, so there's little code difference.

I felt the Ethernet/Wifi design should eventually support certain
protocols natively (CIFS, NFS), which is why I thought the HP of a ARM
might come in handy. Still, the first iteration would use a helper app
on a PC to mediate the protocols and be configured so that the protocols
could be developed and tweaked on a PC, and then the resulting C code
could simply be dropped into the firmware build and would then provide
the protocol natively. A "raw" protocol would always be supported, to
handle esoteric access methods, ones too niche to support in the main
codebase.

Jim

--
RETRO Innovations, Contemporary Gear for Classic Systems
www.go4retro.com
store.go4retro.com

[Mike Paull]

Hi Jim,

>
>So, my current design includes an ARM and a Wifi module, but retains a
>footprint for the Ethernet port and PHY items. Both require a TCP/IP
>stack, so there's little code difference.
>
>I felt the Ethernet/Wifi design should eventually support certain
>protocols natively (CIFS, NFS), which is why I thought the HP of a ARM
>might come in handy. Still, the first iteration would use a helper app
>on a PC to mediate the protocols and be configured so that the protocols
>could be developed and tweaked on a PC, and then the resulting C code
>could simply be dropped into the firmware build and would then provide
>the protocol natively. A "raw" protocol would always be supported, to
>handle esoteric access methods, ones too niche to support in the main
>codebase.
>
>Jim

Sounds like the way to go. Your comments about Wifi are true, I think most
people (including me) would find that a much more convenient way to go.

Raw support would be the ideal solution however a helper app is no problem
for me as I have a linux based server that runs 24/7 for other duties so
it could easily run any helper app required.

Mike

[Terry Raymond]

Hi Jim,

Can you explain Arm a little more Im not sure what that is.

Thanks,

Terry Raymond

--
You received this message because you are subscribed to the Google Groups "µIEC Users Discussion Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uIEC-users+...@googlegroups.com.
To post to this group, send email to uIEC-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/uIEC-users/CDE36C8B.93F4%25mikey351%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Mike Paull]

Hi Jim,

Have you given any more thought to this project?

Regards,

Mike

[RETRO Innovations]

I tried to hire someone to write the code, but no such luck. I am
trying to free time, as I see a gap for such a device. The problem is,
it needs to be an ARM device, in my opinion, to keep costs manageable
and handle the TCP/IP stack (and offer some of the advanced things that
might be needed). I have only created sample apps in ARM, so I would
prefer someone who is comfortable get the first version of the code
going, along with the requisite bootloader, which is a requirement
implementation.

I guess, if anyone knows an embedded programmer comfy with Embedded ARM
and looking to freelance a bit, hook me up.

[Mike Paull]

On Friday, 26 July 2013 15:30:48 UTC+10, Jim Brain wrote:

On 7/25/2013 7:16 PM, Mike Paull wrote:
> Hi Jim,
>
> Have you given any more thought to this project?
>
> Regards,
>
> Mike
>
I tried to hire someone to write the code, but no such luck.  I am
trying to free time, as I see a gap for such a device.  The problem is,
it needs to be an ARM device, in my opinion, to keep costs manageable
and handle the TCP/IP stack (and offer some of the advanced things that
might be needed).  I have only created sample apps in ARM, so I would
prefer someone who is comfortable get the first version of the code
going, along with the requisite bootloader, which is a requirement
implementation.

Hi Jim,

All sounds very logical. Hopefully you'll find someone that can program for ARM as it would be a fantastic device, like you said, there is a gap in the market for such a device. I have had a look at The Commet and Flyer and neither of them appeal to me, although Flyer now supports a type of network access although it seems very awkward and inflexible.

To my way of thinking the best way to do it is have a defined nas drive as the root device and then use standard JiffyDOS/CMD style commands to navigate the folders and images contained on the drive. Perhaps this would be achieved with command like:

@8=192.168.1.67/C64

Where C64 is the folder containing all the D64 images and subdirectories which could be navigated or mounted using the typical @CD commands.

 

I guess, if anyone knows an embedded programmer comfy with Embedded ARM
and looking to freelance a bit, hook me up.

Unfortunately I don't :(

Mike

[Raymond]

Wile your add it maybe add a battery for the Real Time Clock in it.

-Raymond Day