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!

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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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

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

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Sounds like a nice simple approach.

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!

_________________
Regards, KM
https://github.com/floobydust

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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.

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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

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

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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 ...

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!