I discovered this several months ago:

https://www.corshamtech.com/ss-50-65c02 ... xperiment/

So I contacted Bob Applegate and told him that I have been working on a debugger for the 6502 and will convert it into a monitor.

We were talking about operating systems. Most of the popular ones on the 6502 are wrapped tightly around its host hardware. None of them were anything like a CP/M or MS-DOS which can be readily adapted to a new system.

I brought up the OSI DOS. He said that he had looked at it and thought it was “clunky.” I had to agree because the user had to manually allocate disk tracks.

There is DOS/65, a CP/M clone, but there is not much information available on how to adapt it and build a boot disk.

While working on adding support for his SD card “disk system” in my debugger/monitor, I had a thought. Why not build a clone of FLEX for the 6502?

I started working on it and have most of the command line interface of the DOS portion working and can boot it off of a virtual disk in my emulator. Next up are disk drivers then the file system.

This morning, I reached out to Dave , local Ohio Scientific expert and owner of http://www.osiweb.org/ , for his input. We have been having some interesting discussions.

More to come…

Sounds interesting! A possible lesson from DOS/65 is that you get much better traction in the long run if you publish your sources and document your interfaces: please do that! It's best not to wait until everything is perfect: everyone understands and expects that published sources are a work in progress.

Amen on that!

My intent is to open source the bulk of the operating system. Essentially, everything which is a clone of the corresponding pieces of FLEX.

Unlike DOS/65, I intend to have virtual disk images ready to boot and run in my emulator so that it is very easy to give the system a test drive without have to do any configuration work or acquiring a specific set of hardware. Only then will the user have to do an adaptation to a specific hardware platform if they so choose.

There will be two "reference" implementations. Bob's system, essentially a clone of a SWTPC 6809 computer, but with a 6502 CPU. His mass storage is an SD card system based on an Arduino interfaced via a parallel PIA port. The other is basically a virtual version of Bob's system, but with a SWTPC DC-1 floppy disk controller within my emulator.

I will also have detailed instructions on how to build the system entirely from the source code if needed. Most should not need to rebuild everything; just customize and assemble the console and disk drivers, combine them with the core of the operating system and copy the result to the boot disk.

I am torn between whether to restrict commercial use like DOS/65 did. That was one of the reasons Bob and I chose to pursue something else. On the other hand, I would like to give Bob an exclusive on it for at least awhile if I can.

At long last, I am finally able to load and run a program from a binary file. A surprising amount of the file system had to be implemented in order to be able to do that. I am very thankful to be developing this using emulation. Using real hardware will have taken much, much longer.

It is often said that code on a 6502 tends to be faster but bigger.

The following subroutine in the FLEX file system copies an 8.3 file name to a temporary save area in a file control block.

The original 6809 code:




The 6502 code:




In this example, the 6502 code is 20 cycles faster, but 10 bytes bigger.

Fun Fact (?): 6809 performance is degraded by a very high proportion of instructions which include one or more dead cycles. Even an ultra-simple instruction like LDA abs (which is 4 cyles on 6502) takes 5 cycles on 6809!

(Most of these baffling dead cycles can be bypassed if you're using Hitachi's version, the 6309.)

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

The difference with some instructions between the two processors is due to the fact that the 6502 tries to pre-fetch the next instruction whenever the opportunity presents itself.

I used the 6809 version because I wanted to start with the latest code.

This is the same piece of code on the 6800:



When I first started with the 6809, I noticed that some of the instructions took longer for understandable reasons. The 6800 INX instruction takes four cycles while the 6809 "generalized" it to LEAX where any number can be added to the X register. An extra cycle is needed to fetch the extra postbyte.

The loop is still one cycle faster on the 6809.

That said, there are some "irregularities" I do not understand, such as why ldaa xxxx on the 6502 and 6800 takes 4 cycles while lda xxxx on the 6809 takes 5.

I hope I'm not drifting too far off-topic, but you really should be taking advantage of auto-increment for your 6809 code.

Here's an example of some typical 6809 code destroying the equivalent 6800 code due to the availability of Y and auto-decrement.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I think when TSC came out with the 6809 version, they did not spend the time to make it faster or smaller. They did not really need to - the OS resided in a separate 8K piece of memory and it mostly dealt with slow floppy disks and even slower humans.

While the processors are not binary compatible, 6800 code can be assembled into 6809 binaries, which is what TSC probably did. From the looks of it, the source code I found for the 6809 was probably a commented disassembly rather than the original, especially seeing constants written "$01" instead of just "1". I would strongly prefer seeing "inx" in my source code than "leax 1,X", and especially "clc" than "andcc #$FE".

We had that discussion here: https://talk.dallasmakerspace.org/t/pro ... r/18852/16

As is often the case, both routines could also be improved by performing the copy from the end to the beginning, so only one index register needs to be maintained. On the 6502, having set up the two pointers in ZP:

The file name starts at offset 4 in the FCB, not offset 0. So you will need another pointer in the zero page and more code to initialize it.

I can now view a catalog of files on a disk, type out the contents of text files, delete and rename files.

Overall, I am very pleased with the progress of this project; it was started on April 6, less than a month ago.

Next up, testing all of the ways to write files. That should keep me busy over the weekend.

While working on file deletion, it became obvious that a very safe and reliable file undelete utility can be built. Should I decide to develop that, I'll do it first on the 6502, then migrate it back to the 6800 and 6809.

Great progress! Thanks for all the updates.

I'd be lying if I said I was not bragging just a bit...

This is a bit of a one month progress report.

The FLEX file system (File Management System or FMS) is feature complete except for the portions dealing with the creation, reading and writing of random access files. FLEX stores data on disk as a linked list of sectors. Reading or writing an arbitrary location in a file is not a simple arithmetic calculation; a naive implementation would have to read every sector of the file to follow the list until the needed sector is found. To solve this problem, creating a random file adds two special sectors which contain the addresses of the sectors in the file as they are allocated. Reading a byte from random location in a file requires first reading this sector map then the sector.

The FLEX user interface is feature complete except for enhanced error reporting and background printing. When a random file named ERRORS.SYS is present, its contents is used to present a meaningful error message instead of an error code number. This capability is dependent upon FMS random access file support. Background printing is an option which requires a source of periodic interrupts. I have not investigated this feature very much yet; there are hooks for it in various parts of the system.

The third leg of the FLEX system triad is the Utility Command Set, a collection of small programs on disk which provide a large majority of the user commands. The following commands have been implemented:

ASN
BUILD
CAT
DATE
DELETE
JUMP
LINK
LIST
RENAME
TTYSET
VERIFY
VERSION

leaving these yet to be implemented:

APPEND
COPY
EXEC
I
NEWDISK
O
P
PRINT
QCHECK
SAVE
XOUT

The bootstrap loaders work so the operating system can be loaded from a disk image.

The system total so far is about 9K bytes of machine code. That is an average of around 300 bytes per day. It may not seem like much, but remember that it is all written in assembly language.

The current memory map is:

$0000..$00FF - Zero page, locations at $12 and above are free for application programs to use
$0100..$017F - FLEX line buffer
$0180..$01FF - Stack
$0200..$033F - FLEX entry points, variables and printer driver
$0340..$047F - System File Control Block
$0480..$0AFF - FLEX Utility Command Space
$0B00..MEMEND - User memory

Somewhere above that is about 6K of FLEX itself.

Unlike the 680x versions, the UCS area has been intentionally placed adjacent to free RAM so that a program needing maximum memory can easily use both.

The User's Guide is almost ready to publish; this is slightly modified from an original FLEX manual. The Programming Guide is about halfway done; it is a heavily modified version of an existing FLEX manual.

Finally, some preliminary work has been done on an editor and an assembler. The assembler subproject is actually comprised of four smaller projects:

* enhance the existing 6800 assembler to add features such as conditional assembly directives

* convert the 6800 assembler into a 6502 cross assembler running on the 6800

* convert the 6800 assembler into a 6800 cross assembler running on the 6502

* combine the three into a 6502 native assembler