FLEX for the 6502 or building a compatible operating system.

[floobydust]

BillG wrote:

Yes, it has been developed so far only using emulation.

The current virtual hardware is essentially a SWTPC 6800 computer with a 6502 processor instead of the 6800, 56K of RAM (though it will not require that much), an ACIA for a serial port and a WD 1771 for a disk controller.

My intent is to support the Corsham SD card system for mass storage once I figure out how to emulate it. That will likely be the first supported configuration in actual hardware. https://www.corshamtech.com/product/sd-card-system/

Maybe you can be the first?

FLEX has broken out the console and disk drivers into separate files and only those need to be reimplemented to adapt the system to custom hardware.

This is the manual for adapting 6809 FLEX to a new system. The process for the 6502 is similar. http://www.flexusergroup.com/flexusergr ... 09fadg.pdf

Other FLEX manuals can be found at: http://www.flexusergroup.com/flexusergroup/fug4.htm

Thanks for the additional info.... very interesting.

I did some light reading on the Flex implementation guide. It seems pretty simple for console and disk access routines, which would basically qualify as BIOS on the target system. My current C02 Pocket SBC has some core routines in the BIOS that should work with some minimal modification and perhaps a new routine or two for the Console part.

I already have some Western Digital floppy controllers... WD1772, WD2792 and the one Atari made which qualifies as a WD1772 with fast clock support for HD floppies. I can likely put together a floppy controller without too much difficulty and write the BIOS for the required routines. This should be more straightforward as Flex essentially uses the specifics of the WD177x FDC.

My SBC is 32KB of RAM from $0000-$7FFF and EEPROM from $8000-$FFFF. I/O is on Page $FE00: 5- I/O selects which are 32-bytes wide. One is used for the UART console and the other four are available on an expansion connector. The next burning question... would it be possible to locate Flex in the EEPROM? I have ample available space, upwards of 24KB. It would be a nice option and keep most of the RAM for user apps or whatever. If not, I could modify the C02 Pocket and piggy-back a second 32KB RAM chip, then reprogram the CPLD glue chip and only address the EEPROM at the top 8KB.

Last... is the port to the 6502 only using 6502 opcodes and addressing modes or are you taking advantage of the CMOS enhancements? Thanks for entertaining the above.... this sounds like a fun expansion project.

[BillG]

floobydust wrote:

The next burning question... would it be possible to locate Flex in the EEPROM?

While it is not currently configured that way, my intent is to be able to build a ROMmable system image. It will end up no bigger than 8K, probably more like 6K.

floobydust wrote:

Last... is the port to the 6502 only using 6502 opcodes and addressing modes or are you taking advantage of the CMOS enhancements? Thanks for entertaining the above.... this sounds like a fun expansion project.

Only 6502 instructions are used for greatest compatibility. It has been very tempting to use the 65C02 enhancements, but doing so would exclude many potential users.


Now we get to the part I have not worked out yet: how to get all of this code onto a target system.

Life is easy in emulation as there is no hardware divide to cross.

For floppy disks, the best would be to use an existing machine which has the capability to format and write a compatible disk. It need not be running FLEX, though that precludes the need to write as much custom software. Lacking that, the capabilities of the monitor ROM in the target system can be used to download code using a serial port to format a disk, then copy the various programs to it.

For systems using an IDE (actual disk or compact flash) or SD card, a design decision is needed between treating the media as one disk drive, possibly with partitioning, or as a way to serve virtual disk images to the operating system. The latter technique generally uses some form of FAT file system containing the virtual disk files. IDE or SD card media has the advantage that it can be mounted onto a modern computer and manipulated. For FAT formatted ones, files are simply copied.

The Corsham SD card interface uses an Arduino Mega to handle the FAT file system and communicates with FLEX drivers through a parallel port.

[floobydust]

I just finished reading most of the FLEX User Manual. It does state that a minimum of two drives are required. In the old diskette world, this can become a bunch of parts and cables. As I prefer to keep with the existing small pocket size board (3.8" x 2.5") I'll likely look at using an IDE interface.

For IDE, every IDE device (physical rotating disk, solid-state (IDE or Compact Flash) defaults to a 512-byte sector size. As the drive electronics are built in, it's unlikely you'll find any native support for 256-byte sector formats. As every IDE drive will already have a low-level 512-byte hardware format, it's easy enough to query the drive for parameters. Once this is known, I would likely look to divide the IDE device into multiple drives and manage them logically via a layer on top of the raw BIOS that accesses it.

From a FLEX view, it appears that it uses track and sector access only (no head number), so that will limit the maximum addressable size of a logical drive. Most older systems were limited to four actual diskette drives. As the WD Floppy Controllers are all 8-bit registers, tracks numbers can be from 0-255, while sector numbers can be from 1-255. As FLEX doesn't know about multiple heads, that would put the limit at 256 tracks * 255 sectors * 256 bytes/sector = 16,711,680 bytes. Not bad overall... and with support up to four drives, that would be about 64MB total. Smaller compact flash drives could be a nice fit for this.

To load onto an existing system, can you create S-record (S19) or binary files? I can download files via the console port using Xmodem-CRC. The SBC Monitor also detects and handles S19 files with or without an offset (and can write it to the EEPROM insitu), so it depends on how you generate your code. I can also add data into the Programmer and burn an EEPROM.

[BillG]

floobydust wrote:

I just finished reading most of the FLEX User Manual. It does state that a minimum of two drives are required. In the old diskette world, this can become a bunch of parts and cables. As I prefer to keep with the existing small pocket size board (3.8" x 2.5") I'll likely look at using an IDE interface.

Technically, you can get by with only one drive, but because many of the commands reside on disk and the lack of an included utility to copy a file from one disk to another with only one drive, it may not be pleasant. Especially back in the days of single sided, single density media. I did that at first.

Several people, including me, have written single disk copy utilities. It is not difficult, but you have to be aware of the existence of random files; you have to take one additional step when creating it.

Luckily, FLEX comes standard with hooks to install commands resident in memory. With your big EEPROM, you will probably want to look into that... See the programmer's guide.

floobydust wrote:

For IDE, every IDE device (physical rotating disk, solid-state (IDE or Compact Flash) defaults to a 512-byte sector size. As the drive electronics are built in, it's unlikely you'll find any native support for 256-byte sector formats. As every IDE drive will already have a low-level 512-byte hardware format, it's easy enough to query the drive for parameters. Once this is known, I would likely look to divide the IDE device into multiple drives and manage them logically via a layer on top of the raw BIOS that accesses it.

A common approach used by people who have interfaced FLEX directly to IDE or SD media is use only the last 256 bytes of each sector. Ignore the first 256 when reading; write 256 0s, then the actual data. Sure, you waste half of your disk space, but you have plenty to work with. Do not do that if you go with the files in a FAT file system approach.

floobydust wrote:

From a FLEX view, it appears that it uses track and sector access only (no head number), so that will limit the maximum addressable size of a logical drive. Most older systems were limited to four actual diskette drives. As the WD Floppy Controllers are all 8-bit registers, tracks numbers can be from 0-255, while sector numbers can be from 1-255. As FLEX doesn't know about multiple heads, that would put the limit at 256 tracks * 255 sectors * 256 bytes/sector = 16,711,680 bytes. Not bad overall... and with support up to four drives, that would be about 64MB total. Smaller compact flash drives could be a nice fit for this.

You are correct in your calculations. For FLEX, 16MB is huge.

There was an add-on for the 6809 to allow creating and using subdirectories; I have never used it since I did not have a hard drive. I had forgotten about that; I need to look into it.

floobydust wrote:

To load onto an existing system, can you create S-record (S19) or binary files? I can download files via the console port using Xmodem-CRC. The SBC Monitor also detects and handles S19 files with or without an offset (and can write it to the EEPROM insitu), so it depends on how you generate your code. I can also add data into the Programmer and burn an EEPROM.

The FLEX assembler can create FLEX format binary files or S19 files with a bit of fiddling. My cross assembler can create either of those plus Intel hex. If you need just a plain flat binary image, it is not difficult to write a simple program to do that.

[floobydust]

Hi Bill,

Yesterday was road trip day... 620 miles in the car

Thanks for responding... good info again. I'm thinking that having Flex in EEPROM is a good concept... it can always be updated as needed. It also allows more RAM to be used for either user programs, buffers or whatever. S-Record (S19 format) works best for me, as both the Dataman programmer and my C02 Pocket SBC Monitor support it.

I'm working on my existing IDE/RTC adapter and swapping out the 44-pin (2.5-inch) IDE connector with a 50-pin Compact Flash socket. I think this would be a good choice for storage with Flex. I was planning on writing a BIOS that would query the drive parameters and then allow for a utility to manage the CF card. As Flex requires a driver that provides specific functions, I'm thinking the Flex driver routines would provide the layer between the raw BIOS that supports core functions of the CF card and map them to the Drive/Track/Sector routines that Flex requires for access. This should make it fairly transparent for Flex to use the CF card.

This would of course, require a utility that would be able to partition the CF card and have it presentable to Flex via it's documented interface via the mapping layer. I would suggest that the first sector, which is the traditional boot sector, be used for setting up partitions, albeit in a different manner so the Flex driver routines can easily adapt and access the partitions. Once this is done, there's still the need to provide a disk format routine to initially setup the partitions and format them so they can be used by Flex.

I also have a RTC on the same I/O adapter, so I think this could also be leveraged so that Flex can (by default) get Date/Time information from the hardware vs the user on startup. Thoughts, insights??

[BillG]

floobydust wrote:

I'm working on my existing IDE/RTC adapter and swapping out the 44-pin (2.5-inch) IDE connector with a 50-pin Compact Flash socket. I think this would be a good choice for storage with Flex. I was planning on writing a BIOS that would query the drive parameters and then allow for a utility to manage the CF card. As Flex requires a driver that provides specific functions, I'm thinking the Flex driver routines would provide the layer between the raw BIOS that supports core functions of the CF card and map them to the Drive/Track/Sector routines that Flex requires for access. This should make it fairly transparent for Flex to use the CF card.

This would of course, require a utility that would be able to partition the CF card and have it presentable to Flex via it's documented interface via the mapping layer. I would suggest that the first sector, which is the traditional boot sector, be used for setting up partitions, albeit in a different manner so the Flex driver routines can easily adapt and access the partitions. Once this is done, there's still the need to provide a disk format routine to initially setup the partitions and format them so they can be used by Flex.

Using the first (boot) sector for the partition table is what many other operating systems do.

The partitioning code should size each partition to a multiple of 255 sectors since 255 is the maximum number of sectors FLEX allows on a track. Luckily, converting track,sector to LBA is easy.

Track * 255 + (Sector - 1)

which can be efficiently calculated by

Track * 256 - Track + (Sector - 1)

The formatter does not need to find bad sectors by reading each one.

If you put FLEX in ROM, you will not need a boot sector in each partition.

Write the System Information Record to track 0, sector 3.

The directory starts with track 0, sector 5 and occupies the rest of the track. Your sector links will look like:

T 0, S 5 -> T 0, S 6 -> T 0, S 7 -> ...... -> T 0, S 253 -> T 0, S 254 -> T 0, S 255 -> T 0, S 0 (for end of sector list)

Finally, starting with track 1, sector 1, link the rest of the sectors in the partition into a free list, again with the last sector "pointing to" (0, 0)

floobydust wrote:

I also have a RTC on the same I/O adapter, so I think this could also be leveraged so that Flex can (by default) get Date/Time information from the hardware vs the user on startup. Thoughts, insights??

FLEX does not currently store the time in directory entries, only the date. We have been discussing maybe creating an updated version of FLEX after almost 40 years among some members of the user group. RTC support and tracking the time is one of the proposals. There are currently several unused bytes in each directory entry; two of these can be used to store the time with a resolution of two seconds like MS-DOS does.

An extension of the console driver or a whole new clock driver can be defined to interface the RTC. FLEX already has a DATE utility to show and set the date for those without RTC hardware.

[floobydust]

True, the first sector of hard drives back in the 80's was the partition record... along with enough code to load the boot sector from the active partition. Back in the 80's I wrote a custom partition loader (record) that would softload the drive parameters, as the BIOS on the PC-AT only supported a limited number of drive configurations. We got in some early Seagate 80MB drives, but the PC-AT BIOS had nothing close built into BIOS, so I wrote a custom partition loader and a utility to write the partition record. The default drive type always worked as all drives had at least 4 heads

Back to IDE and Compact Flash. I have a simple way to clone the smaller flash cards... back in the 80's I wrote the first hard drive cloning software. It was a simple sector level copy using the PC BIOS Int 13H interface. It was limited to 8064MB, as this was the limit of the BIOS interface. This worked starting with ESDI, SCSI and later IDE drives, as these were logical translations to cylinder/head/sector and the drives had onboard defect mapping, so there were never any exposed bad sectors. The drive had it's own defect map for bad sectors which could be updated if/when more bad sectors happened. I later changed the code to be able to write an image file (as well as a drive to drive copy), which would allow a complete drive image to be saved on a LAN server or a local drive large enough to handle the image. I used this back in the 90's to clone drives for demos and manufacturing started using it to preload the OS. I later started using it to backup CF cards with an IDE adapter.

I need to find my old code.... several disk utilities which will scan an entire drive, clean an entire drive and clone it, plus writing single sectors as needed. It's all on a 3.5-inch bootable diskette.... somewhere

I'm in the process of doing a PCB for a CF card interface.... have to create the CF Card template based on the 3M socket specification. Once that's done, I should be able to finish up the PCB and get some boards made.

[BillG]

floobydust wrote:

Back to IDE and Compact Flash. I have a simple way to clone the smaller flash cards... back in the 80's I wrote the first hard drive cloning software. It was a simple sector level copy using the PC BIOS Int 13H interface. It was limited to 8064MB, as this was the limit of the BIOS interface. This worked starting with ESDI, SCSI and later IDE drives, as these were logical translations to cylinder/head/sector and the drives had onboard defect mapping, so there were never any exposed bad sectors. The drive had it's own defect map for bad sectors which could be updated if/when more bad sectors happened. I later changed the code to be able to write an image file (as well as a drive to drive copy), which would allow a complete drive image to be saved on a LAN server or a local drive large enough to handle the image. I used this back in the 90's to clone drives for demos and manufacturing started using it to preload the OS. I later started using it to backup CF cards with an IDE adapter.

There is an advantage to building a virtual disk on a modern computer then copying it to the actual media - the relative ease of installing other software.

[floobydust]

Well, I've got numerous computers... from the 70's to as recent as a few months... many would qualify as "Modern"... 64-bit CPUs, multicore/multithreaded, gigs of memory and terabytes of storage, etc.. Exactly what (software) are you using to build a virtual disk image and what media are you copying it to?

Back on the CF-Card adapter. I've basically completed the PCB layout. I still need to validate the GAL programming, as WinCUPL is inverting one of the signal definitions and ignoring another, which has forced me to change the GAL specifics and PCB layout... but beyond that, I should be able to order PCBs in the near future.

[BillG]

floobydust wrote:

Exactly what (software) are you using to build a virtual disk image and what media are you copying it to?

Currently, I am developing in emulation only.

The emulator uses flat files containing the raw sectors of virtual disks. A virtual disk having 40 tracks of 10 sectors each is 256*10*40 bytes long.

I have some old (about 20 years) tools to deal with the FLEX format, format (create a new virtual disk), extract a file, insert a file, view the directory, etc.

[floobydust]

I'm about finished with the CF-Card/RTC adapter design and PCB layout. A few more checks on the PCB layout and another confirmation of the GAL code and I'll be placing the order for PCBs.

I also managed to find my old disk utilities on a 96MB DOS bootable CF-Card I now have this running on an old Advantech PCM-5280 biscuit PC (National Geode based) with a 4.32GB IDE drive. I can now scan, clean and copy (clone) any IDE device up to the old PC BIOS limits (~8GB) which works for this project.

More reading on the FLEX manuals.... seems FLEX is limited to a maximum of 4 drives, unless you're planning to increase this. With 4 drives as the limit, anything beyond a 64MB CF-Card will not be addressable by FLEX. Using LBA addressing is looking to be the most sensible so far... and using a custom partitioning scheme to divide a CF-Card into 4 partitions evenly if/when possible.

Based on the manuals, I'll need to create a NEWDISK program to format the drive partition for use with FLEX. I've got a few CF-Cards kicking about... a couple 32MB and a 16MB which I can use for test formatting.... but that will be after the adapter is completed and an initial BIOS is written for access.

[BillG]

floobydust wrote:

More reading on the FLEX manuals.... seems FLEX is limited to a maximum of 4 drives, unless you're planning to increase this. With 4 drives as the limit, anything beyond a 64MB CF-Card will not be addressable by FLEX. Using LBA addressing is looking to be the most sensible so far... and using a custom partitioning scheme to divide a CF-Card into 4 partitions evenly if/when possible.

Yes, FLEX is limited to four drives. Back in the day, the most someone had was a pair of 8" and a pair of 5 1/4" drives. A lucky few had a hard drive and one or two floppies.

One potential solution is for your partitioning tool to allow any number of partitions, but specify which four are mapped to drives 0 to 3.

The File Management System caches the start and end address (track and sector) of the free list and the number of free sectors for each drive. In addition, it has a table for the starting track and sector of the directory for each drive; I do not know why they did this as the directory always started with sector 5 on track 0. Maybe they were planning ahead to implement a hierarchical directory structure which a third party vendor eventually did.

Documentation at

http://www.flexusergroup.com/flexusergr ... ierman.pdf

and

http://www.flexusergroup.com/flexusergr ... erutil.pdf

A limit of four seems limiting to me as well. Fortunately, the memory layout on the 6502 permits expanding the maximum number of drives. The current overhead per drive is 8 bytes. It does not seem unreasonable to go from 32 to 80 bytes so that up to 10 drives can be had. Note that a robust implementation of subdirectories may require also caching the volume name and number for each drive (10 more bytes per drive) for a somewhat more reliable way to detect a disk change.

Most software, with the exception of specialized disk utilities, need not be aware of the number of available drives.

floobydust wrote:

Based on the manuals, I'll need to create a NEWDISK program to format the drive partition for use with FLEX. I've got a few CF-Cards kicking about... a couple 32MB and a 16MB which I can use for test formatting.... but that will be after the adapter is completed and an initial BIOS is written for access.

If you implement your partitioning utility to write the System Information Record to logical track 0, sector 3 and your disk driver package ready to translate track/sector to LBA, the formatting tool only has to do these things:

* ask for volume name and number; write these to the SIR (or your partitioning tool can do this)
* read the SIR to determine the number of tracks in the partition and the number of sectors per track
* create the directory starting from sector 5 to the last sector on track 0
* create a linked list of free sectors
* update the SIR with the start and end of the free list and the number of free sectors

[floobydust]

Some other inquiries on the Disk Driver Routines... in the adaptation guide, it shows the X register on the 6809 holding the address for a sector read or write operation. On the 6809, this is a 16-bit register. When porting this over to the 6502, that's not an option. I can see using the X and Y registers for Track and Sector, so perhaps the A register could be used to point to a Page Zero location using indirect addressing, or define a default (Page Zero) location for the 16-bit address for sector read or write operations. An alternate option could be to use the A register for a sector count to transfer... albeit this could alter how FLEX works beyond maintaining compatibility... and likely wouldn't be valuable based on how FLEX allocates sectors by using the first two bytes to point to the next sector of data. Another option could be to specify the drive ID in the A register.

Restore, Drive, Chkdy (and Quick) also use the X register for physical drive selection via pointing to a FCB where the drive ID is an offset to the 16-bit address specified. I don't see it as a complicated scenario, but one which just needs to be decided and defined for running with a 6502. I'm guessing (aka hoping) you've already decided on an approach for this. Perhaps an updated adaptation guide for the 6502 will be required at some point. I can also see that some streamlining of the console and disk driver routines might be useful during the port.

NOTE: For the native BIOS interface to the CF-Card, I'm planning to use a 512-byte buffer for sector data for read/write operations. My existing Pocket-SBC already allocates low memory; Page Zero has some space used for the BIOS and Monitor, Page 1 is the stack, page 2 is the console UART buffer (128 bytes for send and 128 bytes for receive) and page 3 for vectors, soft config data and other buffer/work areas. I've also allocated an additional 1024 bytes for expansion. The IDE BIOS will take at least 512 bytes, so I specify that user RAM starts at $0800. This leaves 30KB of accessible RAM. The EEPROM starts at $8000 and can have up to 24KB free space if the BIOS and Monitor are all that's loaded. Configuring FLEX for EEPROM, that does keep the RAM free for any user code.... just my thoughts here. I think there's a lot of homebrew 6502 systems that are common with 32KB or RAM and 32KB of ROM with some I/O space carved out.

[BillG]

floobydust wrote:

Some other inquiries on the Disk Driver Routines... in the adaptation guide

I currently have this. It is still subject to change.

Read, write, verify:

A:X = sector buffer address
Y = track number
stack = sector number (1 based, caller removes)

Seek:

Y = track number
A = sector number (1 based)

Restore, select check ready:

A:X = FCB address

floobydust wrote:

Perhaps an updated adaptation guide for the 6502 will be required at some point.

That is going to be a huge job. Most of it will have to be rewritten.

[floobydust]

BillG wrote:

floobydust wrote:

Some other inquiries on the Disk Driver Routines... in the adaptation guide

I currently have this. It is still subject to change.

Read, write, verify:

A:X = sector buffer address
Y = track number
stack = sector number (1 based, caller removes)

Seek:

Y = track number
A = sector number (1 based)

Restore, select check ready:

A:X = FCB address

floobydust wrote:

Perhaps an updated adaptation guide for the 6502 will be required at some point.

That is going to be a huge job. Most of it will have to be rewritten.

Thanks for the reply. I've never been a big fan of using the stack for parameter passing... no particular reason, just don't like it. I would think defining an indirect page zero address for the sector buffer address would be simple and could also be used for the FCB as well. The Y register would be an index to that and it should be pretty simple to transfer the 256 bytes of sector data for read, write and verify. Just my $0.02 of course.

Agreed on the adaptation guide... would likely end up as a full rewrite. Not a fun task, as I've done a fair amount of technical writing over the decades. But if the goal is to make FLEX an easy to implement OS for the 6502, then having it would be a big plus. I know this (porting) is a large undertaking... much appreciated and hoping I'll be able to get it functioning on my C02 PocketSBC with the upcoming CF-Card/RTC adapter.