Although it has.been a while since I last posted an update, the project is still alive. The log summarizes all that I have been doing in the last year

The DSKviewer code produced a directory listing of a Flex disk image, however the formatting was messy and that made reading the output more difficult than it could have been. I  added a formatting function to the code to fix this, and placed the new code on GitHub here.

I had planned to boot Flex from the CF card just like it would have been done in the days of floppies, but realised that the memory area Flex is placed in is within the range covered by my PROM. The PROM is copied to RAM then disabled after reset, so there is no reason not to put an image of Flex in the PROM and have an ‘instant-boot’ Flex computer, so that is what I (eventually) did.  Of course,  there were a few complication along the way.

Based on the DSKviewer code I had previously written, I wrote a program to extract the sectors for any chosen file, which can then be processed further. The first sector of a SYS, COR or CMD file starts with the following information -

   Byte 0 Next track (or 0 for last sector)
   Byte 1 Next Sector (or 0 for last sector)
   Byte 2 Most significant byte of number of sectors in the file
   Byte 3 Least significant byte of number of sectors in the file
   Byte 4  ($02)
   Byte 5 Most significant byte of the load address
   Byte 6 Least significant byte of the load address
   Byte 7 Number of data bytes in the record
   Byte 8-n Binary data

What should be noted, however, is that the data can span sector boundaries - only the first sector is guaranteed to start with this information. It is quite a simple process to take the address and data fields and convert them into s09 records, although one line in the flex file may require several s09 lines. The code FlexExtractor writes an s09 file to disk that can then be downloaded to the SBC.
I processed a random flex.sys file with this code and downloaded it to my computer, which promptly froze. Looking at the s09 file I could see that the drivers for the original computer were located in the same space as my monitor, so I edited the s09 file to remove them and tried again. I already had the terminal IO code in memory, so used G CD00 to jump to the start of Flex. This is what I saw on the terminal -

ASSIST09-Flex
:G CD00
@
FLEX 9.0

DATE (MM,DD,YY)? 28,04,24

DISK ERROR #
+++

As there were no disk drivers installed this is what i expected, so I now have Flex half-working on my computer. With the disk drivers installed and a formatted CF card I will have a working Flex computer.
With this success I searched the archive of Fles disks to find .COR files rather than .SYS, trying each in turn until I found the most up to date version of Flex I could. I found a 9.1 version, and tried programming this into EEPROM where I ran into the next challenge.
The srecord program can combine multiple files into a single file suitable for my programmer. I could combine the Assist09 monitor and terminal drivers happily, however the s09 file for Flex caused errors. The .COR file contains patches applied to earlier code, and therefore had repeated data for fixed addresses. That's fine in the original use case and when downloaded to RAM, where memory contents can be changed any number of times before code is executed, but not for PROMs. I wrote another Octave program (SRecordFilter) to read an s09 file and recreate the memory map. This gave a final image of the memory that could be sorted into ascending addresses and written back to disk. The sort used was a simple bubble-sort so the process is slow, but only needed once.
With this the three pieces of code could be combined and the EEPROM programmed. 
I now have a computer with Assist09 working, which can switch to Flex when wanted so I now need a formatted CF card to go further.