Re: long-term data storage, was Re: [sebhc] Offload of H89 hard and soft sectored disks

[Norberto]

About the Ethernet board I only have a similar board for the H8. I think we talk about this and my request was for someone to provide schematics. Also it was mentioned to buy off the shelf board with such capability and then interface to the H8/H89

Sent from my Verizon Wireless 4G LTE DROID

Gregg Chandler <in...@esx.com> wrote:

I did essentially what I believe you said.  I virtualized my H-8 and its
HDOS file system, including the front panel.  HDOS is probably easier to do
than CP/M in this regard.  I translated HDOS file access into the host (in
my case Windows,) file access.  I was able to mount Windows folders as a
virtual devices--up to eight of them at once.  Individual files sizes grew
to a couple of megabytes apiece as well.  The only thing that needed
patching, which I was too lazy to do, was the files sizes displayed in
directory listings exceeded the buffer space allocated by PIP.  I had wanted
to interface to the network via ethernet, but was unsuccessful in convincing
anyone to create a board.


On 6/4/14 5:24 PM, "Douglas Miller" <durga...@gmail.com> wrote:

> I recall working with a backup device that used video tape (this is
> before VHS and home video) to do backups. Can't recall the name, but it
> might have been from Corvus (who also did hard disk systems). It
> redundantly stored blocks of data in video frames with enough
> checksumming to be able to choose a valid duplicate frame as needed.
>
> But, at the risk of starting a barfight, my own point of view is that
> eventually these glorious old machines (like ourselves) will become
> unmaintainable and die. In my mind, the best way to preserve our
> glorious experiences is through virtualization. To that end we would be
> served to keep safe copies of all our files/programs/data on modern storage.
>
> But one thing I've always wondered about is getting an '89 hooked up to
> a modern computer through one of it's high speed communications links,
> like a SASI (hard disk) port. I would think it's not too big a deal to
> interface a SASI port to a PC parallel port. Then you'd need to write a
> driver on the PC to proxy the disk commands from the '89 to your local
> filesystems. The drive should be able to present anything the '89 needs
> in the area of partition tables, etc.
>
> One step further would be to write a driver for the '89 (I am a CP/Mer
> and so think of CP/Net) to virtualize/network drives over the interface
> to the PC. That might not seem like a big improvement, and maybe it
> won't get us much, but I was thinking it could un-shackle us from the
> SASI protocol and allow more simple function-shipping of file operations
> over the interface - allowing the PC to store our actual files natively
> instead of only raw disk images from the '89 (you could directly access
> '89 files on your PC without running a disk image interpreter). Not sure
> about HDOS, but CP/M was taking steps to get away from direct disk I/O
> and push most things through the file interface, so many CP/M
> applications would work in such a mode. I had played with a virtual
> machine that does just that, pretends to be CP/M on a Z80 but uses the
> native OS filesystem.
>
> anyway, just in case there was nothing left to talk about...
>
> On 06/04/2014 03:39 PM, Lee Hart wrote:
>> Lee Hart wrote:
>>>> Well, *I'm* thinking about ways to have mass storage on old computers.
>>>> (I don't want my backup foundation built on the shifting sands of
>>>> here-today  gone-tomorrow PC technology).
>>
>> Dave McGuire wrote:
>>> Well good!  Let's run with that, then. :-)
>>>
>>> "Floppy tape" systems functioned... barely...once hard drives appeared
>>> those products didn't last very long... The world of tape wasdominated
>>> by huge9-track drives. Some higher-end QIC subsystems appeared, with
>>> ISA-bus  interfaces. Those were solid and fast (except when compared to
>>> 9-track),  but way too expensive for most people... DC-100 was great at
>>> the time, but they sadly didn't stand the test of time.
>>
>> Thanks for the info. I know lots of systems existed; but I don't know
>> how reliable they turned out to be.
>>
>> Of course, the vast majority of people used whatever was the cheapest
>> system at the time. Thus the "bit rot" that so often plagues older
>> systems.
>>
>> So, I'm trying to figure out (with 20/20 hindsight) what kind of
>> reliable backup storage I *should* be using for my classic computers.
>> Of course I can modem all my files to a PC, and depend on its
>> cheapest-is-best technology. But that feels like just kicking the can
>> down the road. When I want that data back, I don't feel like there's
>> any guarantee I can *get* it back!
>>
>>> Thinking about it further, it would be near-trivial to implement a
>>> SCSI host adapter for something like an H8.
>>
>> Didn't Heath's H67 hard drive use the SASI interface, which is very
>> close to SCSI? The software already exists to run that. If a modern
>> SCSI drive can be interfaced in place of the old H67, that could be a
>> viable solution.
>>
>>> DLT drives and media are small, cheap, readily available, and
>>> practically indestructible.  I am willing to bet that a single 40GB tape
>>> cartridge would hold all software ever written for the H-8 and H-89.
>>
>> Tell us more. I've never heard of it!
>>
>>> But the software to drive it would be interesting.  Perhaps something
>>> like tar could be written for CP/M and/or HDOS, with small buffers
>>> etc etc.
>>> That would actually be a viable project, I think.
>>
>> I've only seen "tar" mentioned as the linux alternative to "zip"
>> files. Is that what you're referring to?
>>
>> Is it *necessary* to compress files, when the media you're storing
>> them on is vastly bigger than necessary? I would think that when the
>> purpose is archiving, some format that spreads out the data
>> reduntantly with error correction is what would be used.
>>
>>> Don't buy cheap consumer crap hardware... I recommend WD "Red" series
>>> drives.
>>
>> Thanks! I don't know the difference between brands, and online reviews
>> are certainly no help (the blind advising the blind). EVERYTHING is
>> made in China, and there's often no way to tell the good from the bad
>> at the retail level.
>>
>>> Next...Spinning drives up and down causes a great deal of wear and
>>> tear. Buy them, install them, and LEAVE THEM RUNNING.
>>
>> That assumes you do continuous backups? I'm thinking more in terms of
>> spending days to backup most of my H8/89 software on some kind of
>> media, and then putting that media away in a safe place until I need
>> it. It seems like a hard drive running continuously will be less
>> reliable than one that is off except maybe for a few hours a month for
>> updates.
>>
>>> find a good checksummed filesystem and a comfortable way to use it.
>>> ZFS... was ported to Linux and FreeBSD (accessible) from Solaris
>>> (production-grade). That is the one I recommend...
>>
>> Forgive my ignorance; but you're talking getting a version of linux
>> that uses ZFS to run on a Windows PC, and use that PC for a backup
>> file server? Use a serial port to transfer files between it and the
>> H8/H89? Keep in mind you're talking to someone who has never had
>> networked computers, and not been successful at using linux for anything.
>>
>>> There are "canned" NAS packages, for free of course, that
>>> you download as a disk image and install on most any well-configured PC
>>> that essentially turns it into a NAS.
>>
>> NAS = Networked Attached Storage? I had to google a bit to guess. The
>> NAS wiki seems to say it requires an ethernet or other high-speed
>> network to get data in/out. How would you do this with an H89?
>>
>> Assuming you use an NAS with a network for other PCs: Are you using
>> the NAS *instead of* the PC's own hard drive for storing files and
>> programs? If so, what backs up the NAS when it fails? Or, is there
>> some special program that is saving backup copies of the PC's local
>> hard drive on the NAS, so the PC and the NAS back each other up?
>>


--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CFB6366E.DAD50%25info%40esx.com.
For more options, visit https://groups.google.com/d/optout.

[Gregg Chandler]

It was my understanding that the Ethernet on the one board was more of a replacement for RS-232.. I apologize if I mis-understood.. My code requires an API more like Berkley sockets.. I looked at the ethernet interface of an Arduino, and it wasn’t sufficient to support my code base either—in particular, it did not support the select function.

[Chris Elmquist]

I remember some of this discussion and I believe it fragmented into two
camps, with one wanting what amounts to a terminal server with an async
connection to a UART on the Heath machine and another camp that wants
to run the entire TCP stack on the Heath.

I think I'm in the middle.

I would propose an ethernet interface that is assisted by a modern
microcontroller to do the following things,

1) provide a parallel interface to the Heath system with command, status
and data ports that are byte wide, read/write interfaces.

2) provide a synchronous serial interface to the ethernet controller.
Most of the low-cost ethernet controllers appearing in Arduino and
PIC land use a SPI interface. This would be painfully slow to support
directly on a Heath H8 or H89.

3) Have a soft API where, depending on the firmware loaded, you can
choose to have the entire TCP stack on the microcontroller and have
terminal sessions supported across the host interface, or you can have
half the TCP stack and a sockets-like API to the microcontroller or,
what I want, a MAC layer protocol where I can put and get packets on
the ethernet that are not TCP protocol.

As much as I dislike PICs, they do have a nice interface called the PMP
(parallel master port) which takes care of #1 right out of the box.
There are then a zillion reference designs and example code in PIC-land
for hooking up the ethernet controller and code to make it go.

I'm pretty busy with a startup company these days but I'd sure be happy
to colaborate with folks that want to put something like this together.
It is applicable to lots of platforms and not just the Heath H8 or H89.

Chris

> --
> You received this message because you are subscribed to the Google Groups "SEBHC" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
> To post to this group, send email to se...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/CFB654F2.DAD67%25info%40esx.com.

> For more options, visit https://groups.google.com/d/optout.

--
Chris Elmquist

[Gregg Chandler]

What I really wanted was a separate board capable of running the full TCP/IP
stack, interfaced to the H8/H89 with a shared memory buffer of at least 256
bytes, perhaps better 512 or 1024 bytes.. Ideally, the board would be
programmable with a good/stable C++ compiler.. A status port of some type to
assist in arbitrating the protocol, generating interrupts, etc., would
probably be necessary as well.. Due to the different memory maps of CP/M and
HDOS, the location of the shared memory buffer would need tobe software
configurable..

In any case, I don't now have the time either--at least not now.. I also
realize that I have specified a non-trivial design project for a 1980's era
architecture..

Essentially, my emulator wraps HDOS in such an environment.. I have code
that runs outside of the emulated environment that necessarily co-ordinates
with code that runs within the emulated environment. Outside of the emulated
environment I implement the host file access, network access, etc... Inside
the emulated environment I implemented the necessary hooks to co-ordinate
with external protocols.. In general, it probably is more similar to
something like Vmware rather than a straight emulator.. This is probably
somewhat different than what others on this group have done where they have
emulated bits coming in from the UART on the disk controller.

Although I have not implemented CP/M emulation to date, I believe that most
of the concepts would translate to a similar feature set.. I believe that
trapping the system calls would be possible there as well, although because
some of the data associated with the ECB's(?) lives in the user address
space, things would be a bit more complicated.

[Douglas Miller]

The CP/M part is not hard (depends on your perspective, I guess),
although I'm not sure what you mean by user address space - these
machines have only one address space, and a VM should have access to all
of "memory" (even if "banked"). The CP/M "FCB"s (file control block) can
be tricky if you want to support a wide range of programs, as it was
common practice on older versions of CP/M to directly access bytes in
the FCB / directory entry (and is even required for things like
determining a file's size). It requires building a "DPB" (disk parameter
block) that describes how you will "fake" the data in the FCB for the
given virtualized "disk". Somewhat involved, especially if you didn't
port CP/M in another life... or can't remember what you had for
breakfast... (it took me awhile to work out what I used to do in my
sleep...)

If you want to also support direct BIOS calls, especially for disk, you
have other problems. I would either run a full CP/M BDOS and emulate the
disk in the BIOS (raw disk images only), or else emulate the BDOS file
access (native files only) and only allow console/printer/aux I/O
operations through BIOS (you can't run programs like SYSGEN that access
the boot sectors, for example).

But I suspect no one (else) is going to actually try such a thing, so
I'm sure most have deleted by now... But if not, I have a project I
could share that is basically functional.

On 06/06/2014 08:28 AM, Gregg Chandler wrote:
> ...

[Lee Hart]

Gregg Chandler wrote:
> What I really wanted was a separate board capable of running the full TCP/IP
> stack, interfaced to the H8/H89 with a shared memory buffer of at least 256
> bytes, perhaps better 512 or 1024 bytes.. Ideally, the board would be
> programmable with a good/stable C++ compiler.. A status port of some type to
> assist in arbitrating the protocol, generating interrupts, etc., would
> probably be necessary as well.. Due to the different memory maps of CP/M and
> HDOS, the location of the shared memory buffer would need tobe software
> configurable..

I would guess that one of the modern single-board computers (BeagleBone,
etc.) could do 90% of this. Someone else already designed and programmed
it, so you'd have to work around what they did.

The remaining 10% is the H8/H89 interface. If you want this to be
dual-port RAM, that will be a challenge. The BeagleBone etc. don't
provide any external memory connections, and the timing and sharing for
dual port RAM is always tricky to design. If you could live with a
parallel or fast serial port between the two, the hardware design would
be much easier.

I'm also wondering... why would you want or need TCP/IP on a very old
computer? It can't browse the web, or do email. If it's only for file
transfers, I wouldn't think you need so much overhead.
--
All children are born as engineers. Watch them at play. They're not
just playing; they're building and learning. They are engineering.
Then we get them in school and spend years squashing it out of them.
-- Geoffrey Orsak, Southern Methodist University dean of engineering
--
Lee Hart's EV projects are at http://www.sunrise-ev.com/LeesEVs.htm

[Dave McGuire]

On 06/06/2014 10:37 AM, Lee Hart wrote:
> I'm also wondering... why would you want or need TCP/IP on a very old
> computer? It can't browse the web, or do email. If it's only for file
> transfers, I wouldn't think you need so much overhead.

Please excuse me for butting in, but it could most certainly browse
the web or do email. It's just that nobody has written the code. It's
not like a POP or IMAP client is all that hard to write, and text-mode
browsers don't have to be monstrously elaborate to be functional.

Further, it's not like the only uses for TCP/IP are web and email.

I'd say it's worthwhile.

(and not just because I'm sitting on SEVEN HUNDRED tiny little
Ethernet modules with embedded TCP/IP that I'm looking to sell! ;))

-Dave

--
Dave McGuire, AK4HZ
New Kensington, PA

[Gregg Chandler]

By user address space, I mean that the user can directly manipulate in their
address space data structures that in other OS's are manipulated by the OS
only through a well defined API.. I agree that CP/M is doable, it is just
that HDOS, which I have aleady done, is easier.. I haven't been personally
interested in CP/M.(grin)

In my emulator, I implemented both of the strategies you listed.. I support
device image files of all possible sizes, including custom sizes not found
on floppies or physical devices of the era. I also support virtualized host
access to the underlying OS.. For fun, I also created a graphic version of
the H8 front panel which I suppoert--althugh I did't do multi-touch for the
front panel as as windows didn't support it then.. I also turned serial and
parallel ports into TCP/IP access like rlogin, etc.

The next time I find the code, I'll send you a screen shot of my HDOS box
with other DOS boxes.. I thought that it was pretty cool.

[Gregg Chandler]

I agree that TCP/IP is a lot of overhead for just file transfers, but a
networked file system is about more than file transfers.. I want to give my
H8 transparent network file access--access to any file in my office.. There
really is a profound difference.. The more serious limitation would be file
sizes versus what an H8 can process.

I can remotely use my H8 emulator over rlogin, like I remoely access windows
or *nix computers.. The output of serial drivers goes over the network,.....
I can assemble programs stored remotely on other computers.. I am not trying
to browse the web from an H8, just modernize it by connecting it to the rest
of my computers.

Networked file systems are much more powerful than transferring files back
and forth.. I suspect most on this group use networked file systems.. If you
haven't ever networked your computers, I can understand the question and
concern.

[Gregg Chandler]

A BeagleBone would probably be ideal for me, if I could get the shared
memory buffer and some other simple hardware. I have considered the Bone,
or a Raspberry Pi, as ideal candidates. I ruled out the Arduino because the
Ethernet implementation didn't support all of Berkley sockets--in particular
the select function call. When you need to manage a flexible number of
incoming/outgoing connections, it is pretty useful. I wouldn't want to work
around what the Beagle engineers had done, but rather, leverage what they
had done and use it. I am not really interested in re-implementing the
TCP/IP stack--although somebody else might be.

On 6/6/14 10:37 AM, "Lee Hart" <leea...@earthlink.net> wrote:

[Norberto Collado]

I can remotely use my H8 emulator over rlogin, like I remoely access windows
or *nix computers.. The output of serial drivers goes over the network,.....
I can assemble programs stored remotely on other computers.. I am not trying
to browse the web from an H8, just modernize it by connecting it to the rest
of my computers.

>> That means that you can modify your emulator to talk over the serial port of
the PC to an actual H8 computer. More like having two H8's exchanging data via
the serial port; one logical and the other physical.

>> Is this a viable solution?

>> Also we can add an Intel 8/16-bit ISA Ethernet Network Interface Card RJ-45
($99.00) to the H8 bus in 8 bit mode. You will need to write the H8 driver to
initialize the card to connect to the outside world. Can you do that????

>> link:
http://www.memory4less.com/m4l_itemdetail.aspx?itemid=1439638394&partno=306451-0
11&rid=90&origin=pla&gclid=CLfutIuC574CFUlqfgodxKMAOA


>> Norberto

[Chris Elmquist]

I changed the subject of this thread since we're going slightly off track
if we want to continue discussing an ethernet interface for H8 and H89...

Norberto, were you looking for me to create a schematic for such
an interface? If so, I can do that but I want to discuss a few more
aspects to see if that's really where people want to go.

Beaglebone's and Raspberry Pi's were brought up too and so here is what
I know about that direction,

I develop commercial and industrial products with the same processor
that is on the Beaglebone-- the TI OMAP AM335x series. I have been doing
that for more than five years. They are a fabulous platform for high-end
embedded systems and the development ecosystem around them is unmatched.
However, they are extremely complicated to interface to something like
the H8 or H89, where you would like to have an 8-bit parallel interface
to that legacy system and perhaps even a shared memory sort of interface
between the two. You will need a lot of external logic to get from the
OMAP's memory interface (GPMC) in a byte-wide fashion and you will need
to convert from the 3.3V domain on the OMAP to the 5V domain on the
Heath system.

I think all of that is overkill for the task at hand.

However, we already have a USB interface to the Heath systems and the
Beaglebone, Raspberry Pi and lots of other SOC based platforms have a
USB host interface right on the board.

If you want to develop a network interconnect, file server, just about
anything to gateway the H8 or H89 to the modern world, what would
be wrong with going in and out of the H8/H89 with the USB interface
we already have?? using a Beaglebone, RaspPi or equiv as a "server"
which then performs your network operations, filesystem operations,
etc. to whatever media you wish to connect to that SOC platform?

And you don't really even need a Beaglebone or Rasp Pi because any old
PC with a USB jack that can run Linux can also be this server.

The USB interface to the H8/H89 is already WAY faster than its 8080 or
Z80 can saturate, it takes care of the voltage domain conversions and
it's already a solved hardware problem.

So, if you put the USB interface into the Heath machine, connect it to
a Beaglebone or an old PC, then the rest is a software exercise in app
development for Linux on that server platform. There's also some support
required on the Heath side but the interface to the FT245 device is
brain dead simple-- a bi-directional data port and status read port.
My original design drops into an 8250 UART socket on any of the Heath
serial port cards.

If you put a USB hub ahead of the "server", now you can connect multiple
H8/H89 to this server at the same time and share files between all
the Heath machines and the modern world over the ethernet all at once.

We may need to revisit some of the sofware on the Linux side as Dan had
some trouble with libraries and protocol but I continue to maintain that
the hardware solution here is sound and there is a lot more we can do
with it before I think we need a new or different host interface.

Chris

> To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/kexauucbnxpcpbpo9u96ffun.1401996614872%40email.android.com.

> For more options, visit https://groups.google.com/d/optout.

--
Chris Elmquist

[Gregg Chandler]

As some one has previously noted, when we discussed this a few years ago, I
doubt if the H8 or H89 has enough address space to implement the full TCP/IP
stack. If it does, there wouldn't much user address space left. This is
why I proposed a board with a separate processor and a shared memory buffer
to trade data packets. This design would minimize the impact within the
limited 8080 address space. (Yes, I could overlay it, but that would be too
slow given the interrupting nature of networks.)

I COULD modify my emulator to talk serially. I've got quite a bit of
experience with 8250's and 8251's--especially in H8's and H89's.(wink,wink)

I've already written RPC (remote procedure call) code through serial ports
some thirty years ago--albeit it for CP/M, although that was a bank-switched
CP/M system so the address space was four times larger. It was written in
C.

I virtualized all of the file system calls so that either end of a serial
connection could remotely access all of the facilities in the remote or
local file system. (This was code I delivered to a large commercial
customer in Chicago nearly thirty years ago.) I had also written all of the
code to take in all of the data from a large stock exchange in New
York--collecting all of the real time data received in Chicago for display
on an exchange floor wall for thousands to see. (Same customer.) I guess I
knew at least a little about serial data in a PC as well.(wink,wink)

I've also implemented multiple processor systems that talked to one another
through registers, although again over thirty years ago. Going through
registers, much like going through a serial port, consumed quite a bit of
system resources--even though it was interrupt driven. Not the ideal
situation for what I wanted to do here.

As for whether or not I can initialize a peripheral or write a driver, all I
can say is that if I am given the proper documentation, I think that I might
be able to. I've written a driver or two in my time.(wink,wink)

As for the network card that you indicated, neither it, nor the ten or
twenty others similar to it in my office would work in this case. As
someone else has correctly suggested, what I am looking for is more of a
Raspberry Pi or BeagleBone on a board in my H8 with a shared buffer and some
shared register bits.

I purchased an Arduino and determined that it will not work for my purposes.
I also purchased a Texas Instruments version of a board that was very
similar to these (BeagleBone and Pi)--but was disappointed in the compiler
tools available. The free versions were very limited, and the licensed
versions very expensive.

My intent was not to reopen this discussion again. I think that you
(Norberto) and the group (others) have done admirable work with the boards
you have laid out, purchased and written software for. I don't intend to
take anything away from that.

I thought that I was initially responding to someone asking about strategies
for archiving H8/H89 data. My initial contact with this group was in
seeking out a device to archive some of my many floppies. I had contacted
someone regarding hardware that would let me do that, but when I received no
response, created my own system for doing so--all based upon software.

I created software for the H89 that would upload arbitrary drive images, an
emulator on a Windows host that would boot and execute those images, and
drivers to virtualize access to the underlying host file system, so that I
could easily access individual files either from HDOS, or the host operating
system. I spent two or three weeks and had a lot of fun doing it. It
brought back many fond memories. To my surprise, I still even remember many
of the octal instruction values.

As I explained earlier, I don't have much time now. I am managing my
father's health. He has alzheimer's, and it is a full time job.
Additionally, I am struggling to keep my business alive. There are few
folks still in Benton Harbor/St. Joseph that want the type of custom
programming services that I provide--at least in the way that I can provide
them and still care for my father.

I would participate in more of your board buy and builds, but building
boards is not my strong suit. If I have a strong suit, (and that is a big
if,) it is writing software. I vicariously appreciate your (Noberto's) joy
in bringing up a new board. In the past, I've brought up new software
systems. I wrote the archiving software I described above when my mother
had gotten sick a number of years ago. It brought me joy at a time when the
fragility of life was intruding. Her state also reminded me that some of
the data that I have demands preserving.

[Gregg Chandler]

See my other post on the original thread.

My intent wasn't to revisit this discussion--just respond to someone's
thoughts regarding archiving data. It was previously clear a couple of
years ago that the group doesn't have interest in this kind of Ethernet
project.

However, I do believe that there is a BIG difference between file transfer
and network file support. I implemented file transfer in 1978. I have now
also implemented network file access--at least virtually--for HDOS. It
appears most on this group are satisfied with file transfer. I never have
been.

[Dave McGuire]

On 06/07/2014 05:33 PM, Gregg Chandler wrote:
> As some one has previously noted, when we discussed this a few years ago, I
> doubt if the H8 or H89 has enough address space to implement the full TCP/IP
> stack.

There are two existing, widely-used IP stacks that should fit on those
machines: uIP and lwIP. They are targeted at the embedded world, but
the similarities are fun to think about. ;)

> If it does, there wouldn't much user address space left. This is
> why I proposed a board with a separate processor and a shared memory buffer
> to trade data packets. This design would minimize the impact within the
> limited 8080 address space.

That sounds like a nice idea.

[dsem...@verizon.net]

I've been following this discussion with some interest.  I've had to stop "hobbying" for a while and take a part-time paying gig for the past several months so haven't worked much with my HDOS to Linux  USB interface.  I'll try to carve out some time to get back to it.

One of my plans before having to stop and earn some money, was moving the Linux utility(ies) to a Raspberry Pi.  The idea was originally to have all the HDOS images I could ever want on the Pi memory card sitting right on top the H89 connected via USB.  I then realized that it should not take a great deal of work to extend that combination to my local network via the Pi and it's ethernet port.  Alternatively, I could also use a USB wireless dongle and have the Pi handle the ethernet work in both cases.  It's on the TODO list, but, you know . . .

In any case, the USB interface, either the Elmquist/Emrick manifestation or the Collado manifestation, works great to: (1) transfer individual files between systems, (2) create disk images (track-by-track) of 40-track, floppies, or best of all (3) mount a PC stored image and handle it transparently as thought it were a floppy, but much, much faster transfers.

Sounds like I need to work on the Raspberry Pi idea some more.  I'm not CP/M guy, so I'll need help on that side of things.

Dan

Chris Elmquist

--
You received this message because you are subscribed to the Google Groups "SEBHC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sebhc+un...@googlegroups.com.
To post to this group, send email to se...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sebhc/20140607191148.GK24493%40n0jcf.net.

[Gregg Chandler]

Thanks for the tip on uIP and lwIP.

According to Wikipedia, (sorry I know they probably aren't authoratative,)
lwIP requires about 40K of code and 20K of data. Obviously the code size
depends upon processor, and the memory probably on number of simultaneously
open sockets, protocols supported, etc. My question is, are these numbers
in the ball park?

The description that I read of uIP indicated much lower code and data
requirements, but indicated potential performance implications due to a
single buffer. UIP sounded similar to what I ran on an Arduino that I
bought a few weeks ago. I was basically polled.

Are my impressions here close to right?

[George Farris]

+1 Chris.

George

[Dave McGuire]

On 06/07/2014 08:25 PM, Gregg Chandler wrote:
> Thanks for the tip on uIP and lwIP.
>
> According to Wikipedia, (sorry I know they probably aren't authoratative,)
> lwIP requires about 40K of code and 20K of data. Obviously the code size
> depends upon processor, and the memory probably on number of simultaneously
> open sockets, protocols supported, etc. My question is, are these numbers
> in the ball park?
>
> The description that I read of uIP indicated much lower code and data
> requirements, but indicated potential performance implications due to a
> single buffer. UIP sounded similar to what I ran on an Arduino that I
> bought a few weeks ago. I was basically polled.
>
> Are my impressions here close to right?

That sounds about right, yes. I haven't run lwIP personally, but I've
used uIP in several projects, using modern ARM processors. The ones
I've been working with have 512KB of ROM, which is plenty of course, but
only 64KB of RAM, which is limiting when you start talking about network
protocols. For the basic stuff I've been working with, though (remote
sensing and such), it's plenty of functionality.