Topics

Mass storage for Wichit Sirichote 1802 kit #Wichit

Peter Schmid
 

What about serial EEPROM as mass storage?
http://spyr.ch/twiki/bin/view/Cosmac/MassStorage

The 1802 kit seems to use memory mapped I/O therefore N1/N2/N3 can be
used for the EEPROM interface.
EF2 MISO
D0 MOSI
N1/TPB (wired and) CLK
N0 CS

Schematic:
http://spyr.ch/twiki/pub//Cosmac/MassStorage/mc-eeprom-u1.png

Anyone thinking of a design (even a primitive hack)?
Is this primitive enough ;-) ?

--
Peter

Mark Moulding
 

I was thinking along the same lines, except to use an SD card instead (which is also interfaced using basically an SPI interface).  Then I remembered stumbling across this:

USB-to-FAT-File-System-Control-Module-CH376-for-Arduino

This uses a CH376S chip, which provides three different interfaces: serial, which could easily be bit-banged (or use the onboard UART on Wichit's board, which might be necessary as the default baud rate is 9600), SPI (also bit-bangable), or parallel, which could sit right on the bus as an I/O device.  On the other side, it implements a full FAT (12, 16, or 32) file system, using high-level commands, on either a USB drive or an SD card.

There is a large list of commands, including things like GET_FILE_SIZE, DISK_MOUNT, FILE_OPEN, DISK_CAPACITY, SEG_LOCATE, DISK_READ (as opposed to FILE_READ for physical disk block access), etc - basically, everything needed to add a complete file system - compatible with a PLC - with very little work.  The MPJA module mounts the CH376 chip on a user-friendly board with a .1" IDC connector with all the interesting signals.

They're cheap, too - about $13 at MPJA, or as low as six bucks on Amazon.

The smallest commonly-available USB drive these days is 2 GiB - I think that's probably enough for an ELF...
~~

Mark Moulding

ajparent1/kb1gmx
 

over the years I've tried floppy, IDE, CF, Battery backed up ram (as disk),
serial EEprom, EEprom, to name a few.

Im current lusing SD/uSD as they are cheap, large 1Gb or much more
and easy to interface to Arduino.  However I do not use FAT FS.  I just
use it as randomly addressable block structured device.

I know every one claims you must use FATFS, its large and has too
much overhead.  the only value is if you need to read it on a PC with
nothing special (other than USB to SD adapter).   Me Its easy enough 
from linux to dd stuff to a set of blocks and read them from the target
system.  Its just a large number of addressable 512byte blocks.

What file system is used the SD/uSD device does not care its the
convenience of the target system for 8085/z80 I use CP/M or for 
other I have a simple tag and bag FS or even 1802 using Rileys
ELFOS.

Allison

Mark Moulding
 

I also used the SD card in its raw form as mass storage for a CP/M system I built - it worked just fine.  It was while I was tinkering with building an entirely new multi-user system that I contemplated putting a FAT file system on the SD card.  It would probably have not been too difficult, as I found some downloadable source from someone who had done it as a starting point, but then I found the CH376S, and it was just too easy after that.  I added another drive to that first CP/M system by mapping CP/M's drive into an 8 MiB file, which I could then manipulate using tools on my PC.  I meant to make a transfer utility to move files into/out of the CP/M disk image on the PC, but haven't gotten around to it yet...
~~

Mark Moulding

 

Hey, Mark.  You can purchase the same boards from AliExpress Vendors for less than $3 each (including shipping) if you don't mind waiting a few weeks for delivery.  I bought two of them a couple years ago but have yet to hook them up to anything.

Cheerful regards, Mike, K8LH


From: "Mark Moulding" <mark@...>
To: cosmacelf@groups.io
Sent: Saturday, April 6, 2019 7:23:56 PM
Subject: Re: [cosmacelf] Mass storage for Wichit Sirichote 1802 kit

I was thinking along the same lines, except to use an SD card instead (which is also interfaced using basically an SPI interface).  Then I remembered stumbling across this:


USB-to-FAT-File-System-Control-Module-CH376-for-Arduino

This uses a CH376S chip, which provides three different interfaces: serial, which could easily be bit-banged (or use the onboard UART on Wichit's board, which might be necessary as the default baud rate is 9600), SPI (also bit-bangable), or parallel, which could sit right on the bus as an I/O device.  On the other side, it implements a full FAT (12, 16, or 32) file system, using high-level commands, on either a USB drive or an SD card.

There is a large list of commands, including things like GET_FILE_SIZE, DISK_MOUNT, FILE_OPEN, DISK_CAPACITY, SEG_LOCATE, DISK_READ (as opposed to FILE_READ for physical disk block access), etc - basically, everything needed to add a complete file system - compatible with a PLC - with very little work.  The MPJA module mounts the CH376 chip on a user-friendly board with a .1" IDC connector with all the interesting signals.

They're cheap, too - about $13 at MPJA, or as low as six bucks on Amazon.

The smallest commonly-available USB drive these days is 2 GiB - I think that's probably enough for an ELF...
~~

Mark Moulding



Lee Hart
 

Mark Moulding wrote:
I also used the SD card in its raw form as mass storage for a CP/M
system I built - it worked just fine... I contemplated putting a
FAT file system on the SD card...
We did this on my Z80 Membership Card as well. It runs CP/M from an SD-card. Josh Bensadon wrote the software. The SD-card is formatted as FAT16 on a PC. Each CP/M "disk" is just a big FAT16 file. The Z80 doesn't need to know much about the FAT16 file structure, except how to find the start of each "CP/M disk" file.

Writing a bad file system is fairly easy. Writing a GOOD one is hard! I remember the ones on RCA's and Hughes Aircraft's 1802 development systems weren't very good.

Rather than invent a new one, it makes sense to pick one like CP/M that has a long track record of being simple, yet sufficiently powerful and bug-free. I'm sure the same thing could be done for the 1802.

but then I found the CH376S, and it was just too easy after that.
It's always easy when you can find that someone has already done it for you. We're living in a time when this is easier than ever. Though not as much fun. :-)

I added another drive to that first CP/M system by
mapping CP/M's drive into an 8 MiB file, which I could then manipulate
using tools on my PC. I meant to make a transfer utility to move files
into/out of the CP/M disk image on the PC, but haven't gotten around to
it yet...
Josh wrote a utility for the PC to add, delete, and copy files between these CP/M disk images and DOS. All the software is available for download from <http://sunrise-ev.com/z80.htm>.

--
Fools ignore complexity. Pragmatists suffer it. The wise avoid it.
Geniuses remove it. -- Alan Perlis, "Epigrams on Programming"
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com

John Miles
 

Hi Folks,

I´ve had great success using the following device with Arduinos:


…. an easy way of getting some kind of mass storage.

regards

John


On Sun, 7 Apr 2019 at 19:17, Lee Hart <leeahart@...> wrote:
Mark Moulding wrote:
> I also used the SD card in its raw form as mass storage for a CP/M
> system I built - it worked just fine... I contemplated putting a
> FAT file system on the SD card...

We did this on my Z80 Membership Card as well. It runs CP/M from an
SD-card. Josh Bensadon wrote the software. The SD-card is formatted as
FAT16 on a PC. Each CP/M "disk" is just a big FAT16 file. The Z80
doesn't need to know much about the FAT16 file structure, except how to
find the start of each "CP/M disk" file.

Writing a bad file system is fairly easy. Writing a GOOD one is hard! I
remember the ones on RCA's and Hughes Aircraft's 1802 development
systems weren't very good.

Rather than invent a new one, it makes sense to pick one like CP/M that
has a long track record of being simple, yet sufficiently powerful and
bug-free. I'm sure the same thing could be done for the 1802.

> but then I found the CH376S, and it was just too easy after that.

It's always easy when you can find that someone has already done it for
you. We're living in a time when this is easier than ever. Though not as
much fun. :-)

> I added another drive to that first CP/M system by
> mapping CP/M's drive into an 8 MiB file, which I could then manipulate
> using tools on my PC.  I meant to make a transfer utility to move files
> into/out of the CP/M disk image on the PC, but haven't gotten around to
> it yet...

Josh wrote a utility for the PC to add, delete, and copy files between
these CP/M disk images and DOS. All the software is available for
download from <http://sunrise-ev.com/z80.htm>.

--
Fools ignore complexity. Pragmatists suffer it. The wise avoid it.
Geniuses remove it. -- Alan Perlis, "Epigrams on Programming"
--
Lee Hart, 814 8th Ave N, Sartell MN 56377, www.sunrise-ev.com



ajparent1/kb1gmx
 

Lee,

Looked at the Z80 member card....  someday I may succumb as its cute.

While using FAT16 makes it easy at the PC end (I use linux) its also a lot
of overhead on the Z80 end without a Arduino in between.

I just use the device and ignore the native formatting (fat) and directly address blocks
as that lowers the overhead greatly.  The SD doesn't know or care.  

Since i have Z80 CP/M systems (many) I use send and receive a simple
named file binary block transfer with checksum and at what ever speed
that system can accommodate typically 19200 but I have a few that
run at over 100K.  Most of the time I have to move stuff between systems
with old media(8"), or floppies, CF, or incompatible media but all have serial.

The bios uses the usual logical blocking for multiple 8MB disks but no more
than 4 as it eats TPA.  A utility allows mapping in a new logical disk (about 128
on a 1gb sd) and it has its own internal system to track whos in use.  

I also Use ZRDos/Zsdos as that can map larger devices and still be CP/M
applications compatible.

For small stuff a system like NS* dos a tag and bag ( what and where on the media)
that makes you compact the disks to recover space but is also space efficient.  For
small disk based on EEprom/Eprom/Ram that's often good enough and very compact.

I'm also playing with a file system that is not FAT but can easily work with
larger disks and fragmentation of files.  The big issue is managing used
and free space.  I kinda like VMS (files-11/RMS) but that's fairly large.
For 8bitters is a balancing act and media size matching.

Multiuser CP/M.... MPM works.  I'd rather a unix like thing but UZI unix is
large and eats 32K for the system..

Allison

ajparent1/kb1gmx
 

Oh,  The full circle...

A goal, low parts count 1802 with SD for storage and a local display (LCD)
and keyboard.  Then an OS that can use the device without heavy loading of fat.

Maybe ELFOS or other.  Not a lot of native software out there.

Allison

Timothy Stoddard
 

Interesting! I have been thinking about doing this... can you elaborate on using dd to do this?
--
Tim Stoddard
"Life with technology: It's a roller coaster ride!"

Timothy Stoddard
 

I've been looking at something similar from Sparkfun, but for SD cards.
--
Tim Stoddard
"Life with technology: It's a roller coaster ride!"

Mark Abene
 

If you really prefer sdcard to cf-card, just get an adapter board that does ide to sdcard. There are a handful that support 8-bit ide, and the drivers are already written for ide in elf/os and work fine with these adapters.
I use the StarTech ide to cf adapter in my Elph. I posted a while ago the link to a known good ide to sdcard adapter that works fine with homebrews.

Mark


On Sun, Apr 7, 2019, 12:19 PM ajparent1/kb1gmx <kb1gmx@...> wrote:
Oh,  The full circle...

A goal, low parts count 1802 with SD for storage and a local display (LCD)
and keyboard.  Then an OS that can use the device without heavy loading of fat.

Maybe ELFOS or other.  Not a lot of native software out there.

Allison

ajparent1/kb1gmx
 

On Mon, Apr 8, 2019 at 10:22 AM, Mark Abene wrote:
StarTech ide to cf
I just use the EFL2000 or EELF  as that is native to use IDE/CF.

I like SD/uSD as they are smaller and less interface (SPI) hardware
and an even simpler socket.

Someone asked about dd, if you understand the linux raw read write utility its easy.
If not you can brick a device in a rapid moment.  For system using SD I declare
block number 1000 as a starting point for its storage system and then using the
SD and a usb to SD adaptor I can then write to SD starting at block 1000.
Obviously in both cases I've already set a standard for both so the "file system is"
not a define on but just sequential blocks starting at 0xnnnn.    Then i do not need
to have both ends know a specific or potentially bulky file system.

Since there are 2,097,152 (0x1fffff) 512byte "blocks" on a 1gb SD I can toss
away some as scratch areas.  Since I know the LBA  in use I can read and
write to an area with out any file system.

Most cases I reserve an early area of the SD (or CF and I've even done this on floppy)
to support a bag and tag file system (catalog) so I can make it easy.  This is a simplified
subset of what NS* dos did.   [NS*dos is Northstar dos a functional file system.]

An example might look like this for devices that are 1gb to 8gb in size.
;  File structure
;       Byte  0-9  symbolic name  10
;                 10  file type  if needed
;            11-12 file size blocks  (file of 65535 block is 33mb in size)
;            13,15 file first block address pointer (24bit logical block address, enough for 16,777,215 blocks or 8gb)

A catalog of one block (512bytes) is large enough to contain 32, 16byte entries.  Of course
each entry can be larger and contain more information and there can be more catalog blocks
reserved.

That's enough (minimal) information to store and retrieve programs or stuff. It also small and simple
enough that a program written in tiny based can read the catalog and read, create, and write files.

Its far less code to support that than say CP/M file system or FAT file system  ELFOS file system
is nearly as complex as FAT but a bit cleaner.

Allison

bill rowe
 

would it be possible to define a file system accessible from the pc that would reliably put data at a particular sector?


From: cosmacelf@groups.io <cosmacelf@groups.io> on behalf of ajparent1/kb1gmx <kb1gmx@...>
Sent: April 9, 2019 4:38 PM
To: cosmacelf@groups.io
Subject: Re: [cosmacelf] Mass storage for Wichit Sirichote 1802 kit
 
On Mon, Apr 8, 2019 at 10:22 AM, Mark Abene wrote:
StarTech ide to cf
I just use the EFL2000 or EELF  as that is native to use IDE/CF.

I like SD/uSD as they are smaller and less interface (SPI) hardware
and an even simpler socket.

Someone asked about dd, if you understand the linux raw read write utility its easy.
If not you can brick a device in a rapid moment.  For system using SD I declare
block number 1000 as a starting point for its storage system and then using the
SD and a usb to SD adaptor I can then write to SD starting at block 1000.
Obviously in both cases I've already set a standard for both so the "file system is"
not a define on but just sequential blocks starting at 0xnnnn.    Then i do not need
to have both ends know a specific or potentially bulky file system.

Since there are 2,097,152 (0x1fffff) 512byte "blocks" on a 1gb SD I can toss
away some as scratch areas.  Since I know the LBA  in use I can read and
write to an area with out any file system.

Most cases I reserve an early area of the SD (or CF and I've even done this on floppy)
to support a bag and tag file system (catalog) so I can make it easy.  This is a simplified
subset of what NS* dos did.   [NS*dos is Northstar dos a functional file system.]

An example might look like this for devices that are 1gb to 8gb in size.
;  File structure
;       Byte  0-9  symbolic name  10
;                 10  file type  if needed
;            11-12 file size blocks  (file of 65535 block is 33mb in size)
;            13,15 file first block address pointer (24bit logical block address, enough for 16,777,215 blocks or 8gb)

A catalog of one block (512bytes) is large enough to contain 32, 16byte entries.  Of course
each entry can be larger and contain more information and there can be more catalog blocks
reserved.

That's enough (minimal) information to store and retrieve programs or stuff. It also small and simple
enough that a program written in tiny based can read the catalog and read, create, and write files.

Its far less code to support that than say CP/M file system or FAT file system  ELFOS file system
is nearly as complex as FAT but a bit cleaner.

Allison

--
Bill Rowe
Olduino - an arduino for the first of us
https://olduino.wordpress.com/about-2/about/

ajparent1/kb1gmx
 

yes.

What one to use is far more complex as my system here is linux and I don't think the natic file system is 
simple.

The thought should be a PC can address anything its only a programming problem.
Think of the file systems that the various simulators can and do use.

Allison

ajparent1/kb1gmx
 

Bill,

First assume the pc is like any other computer, it can be programmed to address anything.

Also current PCs if there is a limitation its due to the OS not any specific file system.  An example
of that is Win10 does NTFS or FAT but does not have a user utility to read or write a sector.
Linux has dd that does that as part of the distribution but its a dangerous tool as you can corrupt
the system disk very easily.  In both cases its possible to have tools that are both smart and not
tied to the native file system and can address a non-system (typically not drive C: and D: in
windows parlance) device like a USB disk, USB memory dongle, a CF or SD/uSD in
an adaptor.

So:
Yes you can, and no sorta.  The first is any tag and bag file system its easy to read the catalog
and see where a specific file is.  Due to its simple nature it also does not allow for fragmented
files as they are by default sequential.   The basic structure is a file starts at block nnnn and
continues for nnnn blocks.  Everything you need to find the file is in the catalog/directory.

File systems like NTFS, HPFS, FAT, CP/M, ELFOS all allow for fragmented files as its efficient
use of space.  All of those directory systems are more complex but finding a specific file and
the blocks it uses can be done, with greater overhead.  To find a file and its pieces is harder
as the directory entry requires you to access several tables on the disk to assemble the
needed information.

The bottom line is a low overhead file system for a simple (bounded) computer like
ELF, SCAMP, or whatever is a handy thing if mass storage is needed.  While it is
possible to have a more sophisticated file system one often needs more ram and
EE/Eprom to support it.

While none of this talks about how to actually interface or do it we have the Arduino and
it interfaces to SD via SPI (it has that) and also has serial.  With its 30 some K of flash
its possible to put a Fat file system (there is a library for that) in the Arduino as is
commonly done and be able to access files on a PC using an USB to SD adaptor.
Then the ELF can use a serial IO to talk to the Arduino and read/write/delete a file
by name and conduct transfer to the SD.  This makes for simple things that can
send data to the PC or get data or programs from the PC.  That lowers overhead
but the expense(DC power, added code) is also a lot of MPU (arduino) doing the
heavy lifting.  While that works its kinda upside down, the powerful system [PC]
with all the IO should put stuff on the portable devices (SD) in a form that the
ELF can use directly and any filesystem work is placed on the PC.

Just me, but I see it as a way to have fun and apply stuff I've learned over the
last 50 or so years.

Allison