FLEX internals - nealcrook/multicomp6809 GitHub Wiki
Apart from the source code itself, the best guide to FLEX internals is the TSC manual "FLEX Programmers Manual" (FPM) -- sometimes referred to as the Advanced Programmers Guide? (APG) which is now freely available in electronic form.
Multiple versions of 6800 and 6809 FLEX were released, and I have not seen any release notes or other commentary that enumerates the versions or the changes between versions. However, a little archaeology can uncover some facts.
FLEX Disk Format
See chapter V of the FPM. See also the TSC "6809 FLEX Adaption Guide".
FLEX File Format
See chapter V of the FPM. See also the TSC "6809 FLEX Diagnostics" manual (for details of the format of random access files).
FLEX Memory Map
The overall system memory map is shown below. This is a combination of material from the FPM (p57) and material from the FLEX source.
ADDRESS MODULE DESCRIPTION
0000 - BFFF User RAM (Some of the lower end of this area is used by
certain utilities such as NEWDISK.)
C000 - C07F Stack Area (SP is initialized to C07F)
C080 - C0FF Input Buffer
C100 - C6FF Utility Command Area
C700 - C83F SPOOL Scheduler & Printer Spooler
C840 - C97F FLEX System FCB
C980 - CBFF FLEX System Files Area
CC00 - D36F FLEX DOS
D370 - D3FF TERMIO Platform-specific terminal I/O
D400 - DDFF FLEXFMS FMS
DE00 - DFFF DISK Platform-specific disk drivers
The core executable of FLEX is loaded from the file FLEX.SYS, which is platform-specific. This in turn is created by appending platform-specific modules to the platform-independent FLEX.COR (refer to the Adaption Guide). Basically, FLEX.COR is the concatenation of SPOOL, FLEX and FLEXFMS. FLEX.SYS is created by appending TERMIO and DISK to FLEX.COR -- since TERMIO and DISK are platform-specific, their names might vary.
This, and the whole FLEX build process, is illustrated by examining the file flex_srces_dsk/MAKEFLEX.TXT
ASMB SPOOL.TXT,+LSY
ASMB TERMIO.TXT,+LSY
ASMB DMA8.TXT,+LSY
ASMB FLEX.TXT,+LSY
ASMB FLEXFMS.TXT,+LSY
APPEND SPOOL.BIN,FLEX,FLEXFMS,DMA8,TERMIO,1.FLEX.SYS
I'm using the word "module" to refer to these lumps of code, but they are simply FLEX bin files. The append process just puts them together into a single file; there is no linking or other resolution process involved. Any communication between the different modules is through "known" entry points.
Each FLEX bin file is in a record format. Its final sector is padded with null records. When the files are appended, that is done on a sector boundary, with the result that the null records remain between what were separate modules. Because of this, it is possible to take a FLEX.SYS or FLEX.COR and break it into its component parts.
The MAKEFLEX.TXT listed above is surprising (and unusual) because the APPEND would usually be a 2-stage operation, generating the FLEX.COR as well. However, whether FLEX.SYS is generated as a 1-step or 2-step operation makes absolutely no difference to its content or its size.
An additional consequence of the FLEX bin format is that the APPEND can list the component parts in any order provided there is no overlap between them. If an overlap occurs, the first reference to a memory location will get overwritten by a subsequent reference. This can (and is) used to add additional "meta-data" to bin files (example below).
Using flex_vfs to examine FLEX.SYS
Open multicomp09_flex.dsk in flex_vfs and look at FLEX.SYS in record format:
flex_vfs: mount 0 multicomp09_flex.dsk
flex_vfs: type 0.FLEX.SYS bin=record
The first record, at $CC00, is a set of codes followed by a date. The second record is also at $CC00 and so overwrites the first record. The first record looks like some kind of build/release date stamp. It would be created as a separate module and appended in the correct order during the generation of FLEX.COR -- the MAKEFLEX.TXT script above did not include that step.
The record format displayed by flex_vms shows where there is an address discontinuity in the binary data. This might be because an area in a module is used for data storage and is uninitialised, or it might simply be an unused region.
Looking through output, the following address boundaries are clear:
ADDRESS MODULE
C700 - C804 SPOOL
D400 - DDE2 FLEXFMS
DE00 - DEF3 DISK
D370 - D3FC TERMIO
The boundaries for the remaining module, FLEX, are less obvious - particularly without the ability to see sector boundaries.
Notes:
- None of these regions use up the whole of the space assigned to them.
- The modules are not in address order (as mentioned earlier, they do not need to be).
- Some of the data setup (notably for $CC35) is not in order and not grouped with its module?
The FLEX module
As observed above, the boundaries for the FLEX module are unclear. Examination of the source code (ver 3.01) shows multiple ORG statements in that source file, explaining how the output jumps around:
ORG $C838
ORG $C840
ORG $CA00 } see this code at the end of the image
ORG $CC00 }
ORG $CCC0 }
ORG $CCD8 } see this sequence at the start of the image
ORG $CCE4 }
ORG $CCF8 }
ORG $D3E5 } these are reserved spaces populated by termio.
This doesn't exactly correlate, but this source is 6809 FLEX Ver 3.1 whereas the image being dumped is 6809 FLEX Ver 9, so it probably just means that the source code was reorganised somewhat.
Transfer Record
Right at the end of the dump is a note about "Transfer Record". This is the record that determines the entry-point of the code after it is loaded. It needs to be contained in one of the files that were appended. If it's contained in more than one, the last occurrence is the one that will take effect.
A transfer record can be created manually - refer to porting FLEX).
For the MAKEFLEX.TXT listed above, it's created during the assembly process. Examination of the source file TERMIO.TXT shows how:
COLDST EQU $CD00 FLEX 9 cold start
..
.. body of file
..
END COLDST TRANSFER ADDRESS FOR FLEX
It's odd that the transfer address was not incorporated in FLEX, which is where address $CD00 is located.
FLEX Versions
From an inspection of files on the FLEX user group FTP site. The "VERSION" is how FLEX announces itself on boot. The "DATE" is from the $CC00 "meta-data" record in the file, if present. Many of the FLEX.COR files do not contain the word "FLEX" at all.
VERSION DATE SOURCE COMMENTS
FLEX 2.0 none FL2_0SWT.DSK FLEX.COR presumably 6800 FLEX
FLEX 2.0 none 6800FLEX.DSK FLEX.COR presumably 6800 FLEX
FLEX - Version 2.8:1 - SJT029.DSK FLEX.SYS
FLEX - Version 2.8:3 - SJT007.DSK FLEX.SYS
FLEX - Version 2.9:1 - Flex291.dsk FLEX.SYS
FLEX for MC6809 Version 2.9:2 -FLEX9MST.DSK FLEX.SYS
FLEX for KP MC6809 Version 2.9:2 56K
UNK4.DSK FLEX.SYS
6809 FLEX V3.01 FLEXSSB.DSK FLEX.SYS
FLEX V3.02 n/a source listing, junkbox computer
FLEX 9.0 08Nov1979 multicomp09_flex.dsk originally came from FLEX09BT.DSK
FLEX 9.0 10Feb1980 DMAF2_BOOT_dsk FLEX.SYS
FLEX 9.0 none flexcmds.dsk FLEX.COR
FLEX 9.1 none TSCFLX09.DSK FLEX.COR, FLEX.SYS
FLEX 9.1 none original_flex09_AB168.dsk FLEX.COR
FLEX 9.1 none original_flex09_AB178.dsk FLEX.COR
This wide range of numbering formats (and I'm not done yet) makes me wonder whether some versions did not actually originate with TSC. FLEX 9.1 also prints out a copyright message; the only version to spare bytes for this function!
Only Version 9.0 contains the date meta-data record, and there are two different dates.
FLEX version differences
The FPM states that FLEX 9.0 was the first version to support random files.
By inspection, the MAPUP flag is not supported in FLEX 9.0 (though it is supported in the junkboxcomputer listing, which claims to be V3.02).