USB Flash drive interface for the Microbee
It uses a CH376 interface board (about ~$5-$10 on aliexpress) and connects to the data bus of a bee and a few signals with 14 wires. I'm currently running a freebee cf coreboard and have it plugged into the (for me) unused ide interface with the addition of a couple of links.
I snaffled the software from the romwbw project and modified it for the ch376 chip. (it originally came from https://github.com/wwarthen/FAT)
The usb flash drive is formatted to fat32 and I can r/w on windoze then plug it into my bee and copy files to/from fat32 on the flash drive to cpm format on my cf.
I still need to clean it up and write up the connections. The code needs a little polishing and hopefully it will allow hotplug of the usb flash drive when I've finished.
Others have used the same ch376 chip for mouse and keyboard interfacing, so there is some potential there.
It is using lba mode to address the usb drive so, with some changes to the bootrom and bios in theory it would be possible to boot from a usb flash drive.
Currently I'm using the cpmtools on linux to r/w directly to the cpm formatted cf drive to transfer files. This is, hopefully, one step less in the process.
More to come!
there is two models of the ch376 interface board, one with a 3 pin header and one with a 6 pin header. I'm using the 3 pin header at the moment but have a 6 pin on order. As far as I can work out, apart from the 3/6 pin the other difference is in the dual row header where one has the data lines facing in and the other has them on the edge of the board. Functionally I believe they are the same. They use the same chip. If you were laying out a pcb to interface I've seen one version where a triple row header was used and you just plug the board one side or the other. It'll make sense when you see the boards.
I'm chasing a bug that the first access to the flash drive fails but the second and subsequent work fine. I've added rtc for the writes to fat. But I'll need some logic to make sure it still works with no rtc fitted.
I've found that you can hot plug the flash drive to the ch376 board but I'll look at adding a 'dismount' function or simply turning the power off the flash drive after access. There's a led on the interface board and I'm assuming that it comes on with power.
Hardest part so far has been fighting with the build systems. I initially tried to port the original code to compile under Hitech C but it got to hard when I had issue with the underlying FatFs code needing to many changes. So I moved to using SDCC as per romwbw project does and that was another experience. It currently uses a windoze script to build it rather than a make script and it wasn't rebuilding after any edits which made debugging entertaining to say the least.
Sorry, no drawing but it's pretty straight forward.
ch376 interface board to microbee interface
| FreeBee CF coreboard x2 | CH376 pin |
| Pin 3 CFD7 - D7 | D7 |
| Pin 5 CFD6 - D6 | D6 |
| Pin 7 CFD5 - D5 | D5 |
| Pin 9 CFD4 - D4 | D4 |
| Pin 11 CFD3 - D3 | D3 |
| Pin 13 CFD2 - D2 | D2 |
| Pin 15 CFD1 - D1 | D1 |
| Pin 16 CFD0 - D0 | D0 |
| Pin 19 - GND | GND |
| Pin 20 - +5V | VCC |
Pin 21 - WR link to pin 2 ic19 WD2793 (iorw unusable as gated with io port 60) | WR |
| Pin 25 - IORD | RD |
| Pin 27 - CS link to pin 12 ic13 74HC138 | CS (i/o port 0x58) |
| Pin 35 - A0 | A0 |
| n/a | RESET leave o/c |
CH376 is at i/o port 0x58 & 0x59
Pins 21 and 27 on x2 are currently unused so patched ungated wr and new cs through them.
I don't think the cf logic on iowr is needed but it isn't causing any problem.
Just wires, no cut tracks required. And one of these https://www.aliexpress.com/item/32877955370.html
This is the one with 3 pin header, the other type has a 6 pin header. dual row header swaps the data and control signals from one side to the other. I'll try the other type when it arrives to see if there is any difference between them.
They both have a 3.3v regulator on them but, I haven't had any problems r/w to the ch376, nor has it had any observed impact on the cf onthe coreboard.
Three pin header near usb socket
six pin header near usb socket
Note the 16 pin dual row header pinouts are different. same connections just swapped from one side to the other.
The comment re the addition of the RTC is that FAT drives have a timestamp on them and cpm 2.2 doesn't. Without the RTC code any file copied to the usb flash drive from the bee would have a generic timestamp, by adding the code to read the bee's rtc it now displays the copy time similar to windoze/linux does.
I'm using a subset of the ch376 functionality. It supports some fat functions directly but I'm using it in 'block' mode with the FatFs software providing the FAT interface. There is a series of the chips with increasing functionality and theoretically the ch375 should work as it also supports the block mode. That said one site https://github.com/djuseeq/Ch376msc has reported different firmware versions of the ch376 having differing success. From what I can gather I have an older version of the chip on a 3 pin header board with a sandisk 32g flash drive on it and it appears to be working fine. I have another board on order with the 6 pin header so I'll check that as well. The web site quoted appears to use the ch376 in it's inbuilt fat support while I'm not. So his comments may be not relevant.
They are pretty cheap though.
Looks like I won't be testing the alternate ch376 board anytime soon. Supplier has shipped the completely incorrect item twice now.
fwiw my bee now has ~65GB of storage, cf 1GB, usb flash in gotek 32GB and usb flash on ch376 32Gb. I may have to find some different projects.
Reading from USB flash and writing to CF ~ 5 times faster than reading from USB flash and writing to gotek.
Reading from usb flash and writing to m drive marginally faster than writing to cf. However the transfer to/from FAT isn't optimised. It only reads a single sector at a time and then copies to cpm which has to squeeze that through 8 x 128 byte cpm sectors onto the storage medium. Without delving into cpm bdos/bios internals I think this means a factor of 8 multiplied sector writes to achieve.
I've been making a backup of my CF to the usb flash drive and updated my cf image (new ram arrived) then restored from usb flash. Makes updating and transferring files much easier and quicker. Probably an opportunity to make some submit files to semi automate the backup.
I haven't had a chance to try the '6 pin' module, they shipped incorrect modules to me. The extra 3 pins are used for a serial interface which I'm not using and the other difference is the '3 pin' module has a connection for reset which I'm also not using. the reset is active high rather than the bee's active low reset. The adapter board powers up fine with the circuity on the adapter so I've just left it o/c on mine.
The circuit for the '6 pin' is here https://zerowincoding.tistory.com/entry/CH376S-Arudino-Disk-Read-write-Module-USB-Flash-Disk note the 0.47uF on the reset pin. I haven't found a cct for the '3 pin' version. My translation of the device spec sheet has the reset input with an internal pull down.
I've not had any issues requiring a power on reset so far. I have also hot plugged and unplugged the flash drive and it has worked without any noticeable issues.
Software and source code for the FAT program and some floppy images with a copy of the run time program (FAT2.COM, I renamed if for some reason) here.
And that’s about all I wrote up about the project.
addendum
And I found this sub file I knocked up
Backup.sub
user $2
fat copy $1:*.* 0:/$1$2
usage: ss backup.sub [src drive] [src user]
It backs up all files on src drive user to the usb drive on /src driveuser, ss backup.sub a 3, all files from cpm a3 end up on the cf in folder /a3
(ss -> actually supersub)
Easy to backup all of your cf drive