Eris 2010 SBC

[geb]

Spending way too much time at home during the Covid 19 pandemic, I built a little SBC based on the 65C02 CPU running at 4 MHz with 8 KB ROM and 32 KB RAM. Once I got the system running on a breadboard, I created a PCB and a case for it. (Well, the case is just two layer of acrylic sheets and four spacers.)
Besides the required components (CPU, RAM, ROM), it contains an ACAI 6551 for serial communication and a 6522 VIA for GPIO. The 6551 connects to a USB2Serial converter, and the 6522 connects to an SD card reader. Glue logic is provided by an ATF16V8 EEPLD.
Software can be uploaded via the serial interface or read from an SD card. The SD cards are written in a very primitive, proprietary file system. Besides ports of Tali Forth 2 and Tiny-BASIC, I also wrote configuration files and I/O libraries for CC65 such that the system can be programmed in C.
Reset logic is implemented with an NE555. The NMI line connects to a button. Triggering a NMI either dumps memory or jumps into Wozmon.
The main communication interface is via the serial line. Additionally, a user port allows connecting to the VIA. Buses and other internal lines are accessible via an expansion port.
The whole system was designed and programmed using free software. For the PCB I used KiCad and FreeRouting (part of LayoutEditor). I programmed the ATF16V8 with GALasm.
A detailed description of the system, including pictures, a video, all hardware design documents and ported software, is available here: https://frombelow.net/eris2010/
I hope you like it!

[BigEd]

Welcome - very nice! I'll have a good read of your site.

[BigDumbDinosaur]

Looks like a nice, neatly organized unit.

geb wrote:

The SD cards are written in a very primitive, proprietary file system.

Which filesystem is that?

[barrym95838]

BigDumbDinosaur wrote:

Which filesystem is that?

From a brief glance at the documentation provided we get a clue:

Quote:

SD cards can store up to 10 programs. The file system format is as follows:

Block $00000000 is loaded on initialization. The first two bytes should be $E215. This indicates the file system type. The third byte should be $00. This is the version of the file system. The fourth byte is the number of the program to start automatically, or $ff. In case of $ff, a menu of the programs on the card is presented for the user to choose.

The storage space for the first program starts at $00000001. The storage space for the second program starts at $00010001, for the third program at $00020001, … Thus, each program has a total of $ffff blocks of 512 bytes each available. The first block of each program is the program header. It contains the number of blocks to be loaded, and the app name, a null-terminated string. The actual program code starts with the next block. The program is loaded to address $0200 and executed.

On the PC, use tools/kfs.py to write the SD card.

Despite your claim, you're really a big smart dinosaur, so we shouldn't have to define "proprietary" for you.

[BigEd]

Sounds like a nice simple approach.

[floobydust]

It is a simple approach, albeit with limitations as a result, but I'm thinking it's not much coding to implement.

Another option would be write a BIOS/SIM interface and use Richard Leary's DOS/65. This would yield a CP/M-like environment and likely be more useful. My current CMOS version (of DOS/65) is ROM based and only uses 6.5KB. Richard had sent me code earlier in the year that was being used with Daryl's SBC2.5 with a SD card interfaced to one of the 6522 ports.

In any case, a nice project... as I looked over some of the materials... thumbs up!

[BigDumbDinosaur]

barrym95838 wrote:

Quote:

SD cards can store up to 10 programs...

Despite your claim, you're really a big smart dinosaur, so we shouldn't have to define "proprietary" for you.

I read all that. It doesn't explain a whole lot about the filesystem, e.g., does it have hierarchical directories, what is the maximum file size that can be handled, what makes it “proprietary,” etc. Incidentally, when I see “proprietary” in the description of a homebrew computer project I have to wonder what it is that we are not seeing.

[geb]

Thanks for the warm welcome. There is actually not (much) more to the filesystem than quoted by barrym95838: It can store up to 254 applications, and it does not allow for subdirectories. Each application has a total of $ffff blocks of 512 bytes each at its disposal. The first blocks of these $ffff blocks contain the executable itself. Since the number of blocks occupied by the executable is stored as a byte, the maximal size of an executable is $ff * 512 bytes, which should be plenty for a 32K RAM machine. Once the program is loaded, the ABI in the ROM just provides an interface to read and write blocks.
The filesystem is proprietary just in the sense that it is not based on an existing design; it is completely open and free.
It took quite some time to get the communication with the SD card right. A standard filesystem would be nice, obviously, but for now I am just happy that everything is working. Thanks to floobydust for the suggestion regarding DOS/65! I will look into that.

[drogon]

geb wrote:

Thanks for the warm welcome. There is actually not (much) more to the filesystem than quoted by barrym95838: It can store up to 254 applications, and it does not allow for subdirectories. Each application has a total of $ffff blocks of 512 bytes each at its disposal. The first blocks of these $ffff blocks contain the executable itself. Since the number of blocks occupied by the executable is stored as a byte, the maximal size of an executable is $ff * 512 bytes, which should be plenty for a 32K RAM machine. Once the program is loaded, the ABI in the ROM just provides an interface to read and write blocks.
The filesystem is proprietary just in the sense that it is not based on an existing design; it is completely open and free.

It's a good, solution - cheap and quick. Partitioning the SD card into "volumes" and looking into something like Acorn DFS or even Apple DOS 3.x might be the next step. Apple's DOS was relatively simple - good enough to store a number of files of varying length with a directory (catalogue/index) of files. Acorns early DFS was even simpler. I opted for using Apple ProDOS as a template for my own filing system on my Ruby projects but thinking of degenerating to MS DOS/FAT in the future just for ease of getting data on/off the SD card.

My guess is that english isn't your first language and "proprietary" is simply something that's not worked well in translation. "Bespoke" may be better here.

Cheers,

-Gordon

[BigEd]

Homebrew is a good word too. Thanks for open-source licensing your project, geb!

[BigDumbDinosaur]

geb wrote:

There is actually not (much) more to the filesystem than quoted by barrym95838...

What kind of directory structure does it use?

Quote:

The filesystem is proprietary just in the sense that it is not based on an existing design; it is completely open and free.

Ah-so. In other words, an RYO filesystem. (Roll-Your-Own)

Quote:

It took quite some time to get the communication with the SD card right. A standard filesystem would be nice, obviously, but for now I am just happy that everything is working.

Working with mass storage communication can be quite the challenge. I've been writing a new SCSI driver for my POC V1.3 unit that can read/write anywhere in the 65C816's address space, and support both block and stream devices. It's not a simple thing to implement. Plus SCSI has a huge variety of features to add to the fun.

[BigDumbDinosaur]

BigEd wrote:

Homebrew is a good word too.

Plus “homebrew” is traditional with roll-your-own computers.

[barrym95838]

drogon wrote:

My guess is that english isn't your first language and "proprietary" is simply something that's not worked well in translation. "Bespoke" may be better here.

I have been reading, writing and speaking English for over 50 years, and you have just increased my vocabulary by one word this morning. Thank you! "RYO" is a nice choice in this context too, but I've already seen that one ...

[geb]

BigDumbDinosaur wrote:

What kind of directory structure does it use?

The SD card storage area for each program is fixed. The storage area for the first program starts at $00000001, the storage area for the second program starts at $00010001, ... In these storage areas, the first block contains the program header, which itself consists of two parts: The length of the executable to be loaded (number of blocks), followed by the program name as a null-terminated string. The following blocks contain the executable. All blocks not occupied by the executable can be used by the program for data storage. There is no separate directory structure. The launcher simply reads the headers and prints a list of the names.

PS: Thanks to everybody helping to clear up the confusion about the term "proprietary". Yes, it's a bespoken homebrew RYO filesystem.

[BigDumbDinosaur]

geb wrote:

BigDumbDinosaur wrote:

What kind of directory structure does it use?

The SD card storage area for each program is fixed. The storage area for the first program starts at $00000001, the storage area for the second program starts at $00010001, ... In these storage areas, the first block contains the program header, which itself consists of two parts: The length of the executable to be loaded (number of blocks), followed by the program name as a null-terminated string. The following blocks contain the executable. All blocks not occupied by the executable can be used by the program for data storage. There is no separate directory structure. The launcher simply reads the headers and prints a list of the names.

So, it would appear to be somewhat of a “linear” directory a la the UNIX S51K filesystem, but not stored block-random.