DigicoolThings Forum

Hi David,

Thanks - another OS to look at once I get further along with the 6809/6800 implementation.

Thanks for the discord invite - I think I'm in now (took me a while to work out where it sent ... I'm fairly new to discord).

Cheers,

Emil.

Hi All,

I've made some progress in porting the fujinet library to the Digicool MECB 6809 board:
It can now query the host/drive slots, scan for WiFi networks, and get the directory from a mounted host (from the SD card or remote). Now for the important bit ... seeing if I can actually read/write to files and/or images.

Cheers,

Emil.

That looks nice, good to see something on 6809, safe territory for coding
n.b. maybe counting hidden nertworks? the dates look a bit odd too.

Another update ...

Unfortunately, I haven't been able to get the file handling to work - I suspect maybe it isn't implemented in the firmware (though I wouldn't totally exclude the possibility that I'm trying to call it in the wrong way).

On the plus side, I was able to get the disk image mounting and reading work. It is a little bit tedious in the way it works and it is very specific about what file extensions and file sizes it accepts (which initially threw me off when I was trying to read a FLEX disk). Eventually I passed it a Z80 CPM 2.2 disk and it was able to read that. I'll either need to make some firmware changes to make it recognise FLEX disks or I'll need to embed the image within a CPM-shaped disk. At least I can see a path forward for that.

Unfortunately, I was hoping to use the file reading to make use of a configuration file (to specify the locations of disks for the different operating systems that might be present on the SD card and which disk slots/drives to use) but I might have to skip that idea for now. To take the next steps I'll just initially hardwire these in the code that ultimately does the boot loading.

Woohoo, success - finally able to boot into 6809 FLEX via the FujiNet card
It required some minor changes to the firmware (to fix what I believe are bugs there). It's still needs a little bit more work to make the boot process a bit more usable ... but pretty happy that it is now working.

Well done Emil, a great achievement. looking forward to seeing all the details of how you did it.
Best Regards, David.

Hi David,

I'd have to admit that I took the path of least resistance just to get to a point where I could convince myself it could work ... so that entailed a LOT of short-cuts e.g. FujiNet has 512-byte sectors but FLEX wants 256 - so I just modified the FLEX disks so that the sectors occupied 512-bytes but the upper 256 bytes aren't used (I'm not so fussed that the disks occupy double the space ... but it's a hassle to have to convert original disks to work with this). FujiNet is also quite specific about the disk sizes so I also had to pad out the doubled-up FLEX disks to suit one of the acceptable sizes (e.g. a standard 1.2 MB or 1.44 MB PC floppy). Now that I know that it works I can look into defining some default disks that match what is more appropriate for FLEX (and possibly even a HD). It's still a bit annoying having the fixed 512-byte sectors (there's actually no real reason why the FujiNet can't make this variable to match the system it is being attached to but it seems there is quite a bit of opposition to this - LOL, there is a comment in the firmware that states "// variable sector lengths are evil!") - the biggest annoyance is requiring a separate buffer to hold the sector in memory (8-bit machines are already tight with space and this is a sizeable chunk) ... and, of course, the extra wasted cycles in reading those additional 256 bytes that won't be used and having to then copy the 256 bytes that are needed into the appropriate location (normally you would just tell the routine to dump the sector where it is needed but that can't be done because it is bigger than what it expects ... and the FujiNet protocol insists on sending the full sector otherwise the command will fail).

Once I had much of the FujiNet library ported to the 6809 creating the drivers for FLEX was relatively simple - it basically just expects some basic I/O routines to be pointed to within a defined set of memory addresses. There are some rather clunky bits required e.g. by default I mount four of the device slots as disks 0-3 in FLEX (I haven't actually tested to see what happens if the disk is changed after boot up - I "think" if it has the same sectors/track it'll work but if it is different it could confuse FLEX), also the boot process need to read a specific sector fairly early on in order to determine how many sectors/track the boot disk has otherwise it can't work out how to convert the physical track/sector into a logical one (that FujiNet requires). Whenever the FujiNet routines are called they only return an error code in relation to the protocol itself e.g. a function not supported, or communication with the device failed but if the communication with the device worked OK it doesn't actually report whether the requested command succeeded e.g. a disk read. I "think" there is another command to request this but I haven't tested that yet. So at the moment there isn't much in the way of error checking.

Finally, the drivers and FujiNet library are all loaded into memory - which is a bit of a hassle to do every time you want to bring up the OS. Once I get things cleaned up then I should really move this all into the ASSIST09 ROM to make life a bit easier.

Anyway, plenty more to do ... but at least it I was able to demonstrate that it is possible to get it running. Oh, I also need to try set up a FujiNet server on another PC at home to see if I can boot "remotely" - I "think" that should be pretty much transparent to FLEX itself so it just requires me changing the device setup so that the disk image is on the remote server ... I might actually give that a try as a proof of concept - it'd be a nice demonstration of what this card can do and make use of the WiFi side of things.

Regards,

Emil.

Some slight improvements:

- Doubling of sector size no longer required (the driver will now adjust for the difference in sector size).
- Fixed a few minor bugs in the error handling.
- The boot process is a single-step process now (load the boot loader and run).
- Verified that FLEX can access drives on a remote server (well, remote as in another room).

Unfortunately a conversion process is still required to make FujiNet to accept the FLEX disks - but this is simple enough i.e. it just requires padding the FLEX disk to match one of the known sizes that FujiNet understands.

It's pretty cool seeing FLEX boot up wirelessly on a remove drive - something that was probably never envisioned when FLEX was first developed.

I've now got FLEX 2.0 (and 3.0) booting off "the Internet". with FujiNet using drivers I've written for the MECB 6802 board (now updated with DigiBug):

https://www.youtube.com/watch?v=ZE6BzCaVQ_w

I've added the drivers to my 6800 GitHub (including the boot disk and some Python tools to read FLEX disks):

https://github.com/epaell/MECB/tree/main/MECB_6800/SW

The FujiNet library I've implemented for the 6800/6802 is only the subset needed to run FLEX at the moment. There is still something not quite right with the FujiNet firmware which causes issues if the CPU is running too slowly (I ran into this issue when testing with my original 6800 board as that only clocks at 1 MHz).

If I get a chance I might look into making use of the network time to set up the FLEX time at boot up - that would be a nice addition.

I've also added similar libraries for the 6809 board to allow FLEX to boot via FujiNet (including disk images):

https://github.com/epaell/MECB/tree/main/MECB_6809/SW

Going back to the 6809 board for a while (just because it is easier). Managed to open up a network connection via the FujiNet interface and read the contents of a web service I made for work (it returns the positions of the planets at the time the query is made):