I dove headlong into the assembler. Implementing conditional assembly does not initially appear to be very easy.

So to learn the code, I made a few changes to fix some things which have always bothered me about this assembler:

* The assembler does not allow placing a colon after a label. It now allows but does not require it.

* The assembler distinguishes between upper and lower case in symbols. That is now a selectable option.

* The assembler reformats the source code when it generates a listing. It originally printed "ldaa" as "lda a"; it now preserves both forms of the mnemonic as written. I am still investigating making the reformatting a selectable option.

A simple and elegant solution presented itself after I slept on it and came back to look at the problem from outside of the box: format each line of code, or not, in this case, as if the whole thing was a comment.

This is ideal for those of you on the spaces side of the Great Spaces versus TABs Debate. FLEX already provides automagic space compression on disk as sequences of two or more spaces (up to 255) are replaced with two bytes: a tag and a count. You may now make your code listings look exactly like you want.

Despite having this feature, many early FLEX programmers got into the unusual habit of separating fields in their assembly language programs with a single space and relying on the assembler to make listings legible.

Those on the TAB side were left out because the tag byte was, you guessed it, the hard TAB character. FLEX text files cannot contain hard TABs the way the tools were configured. Editors responded to the TAB key by inserting an appropriate number of spaces.

Any chance of seeing some screen shots of directory listings, etc?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I have been known to say that programming a 6502 in assembly language is tedious compared with other processors. However, I just encountered an example in which the 6502 absolutely blows away the 6800.

One of my current projects is to convert the original 6800 FLEX assembler into a cross assembler running on the 6502.

Its symbol table is an array of eight byte entries: two bytes for the value and six for the symbol name. The symbol name is hashed to obtain an index into the array. In case of a collision, the name is rehashed up to a maximum of forty times to try other locations.

At the end of the assembly process, the table is packed and sorted, then the entries are printed in alphabetical order.

A subroutine swaps two entries addressed by the variables I and J, a task which the 6502 does with ease. It has just enough registers to avoid unnecessary memory accesses. I have observed in the past that the 6800 can be severely hampered by having only a single index register and that the 6502 addressing modes are particularly well suited for marching in lockstep through two parallel arrays.

The 6502 version of the subroutine consumes less than half the cycles while also being much smaller.

The 6502 code:



The original 6800 code:



On further examination, the 6800 version can be made substantially faster than the 6502 version by completely unrolling the loop but the code is almost twice as big. (The XSUB8 subroutine is also used elsewhere, so it cannot be eliminated in the process.) A small speed gain by a similar transformation of the 6502 version does not justify the massive increase in code size required.

Yeah, (zp),y is a real jewel. Whoever invented it certainly deserves our appreciation.

_________________
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 keep forgetting that (zp,X) has the same effect as (zp),Y when both X and Y are zero.

It would be nice if (abs),Y was also available...

Yes, the same effect. But FWIW (zp),Y avoids a dead cycle when y=0. By comparison, (zp,X) always entails a dead cycle, making it one cycle slower in this case.

Yeah. Instead you need to simulate this addressing mode. One solution begins by copying the two bytes to zero-page (assuming you have two zero-page bytes available). Another begins by copying the two bytes into the operand field of an abs,y instruction that follows the copy -- IOW, self-modifying code. In the linked article Garth explains how, among other things, SMC can make up for instructions or addressing modes the processor doesn't have.

-- Jeff

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

Very true. But that one dead cycle is much less than ping ponging the Y register between 0 and some other value.




When working on the assembler, and soon the editor and BASIC interpreter, I have the luxury of using as much of the zero page as needed. Most of the variables have been in the zero page so that simulation is not necessary.

The FLEX operating system, on the other hand, endeavors to continue the tradition on 680x processors in which application programs and not the operating system gets to use the zero page. Within the operating system code, the copying of addresses to the zero page is excessive. Self modifying code is out of the question as some have expressed a desire to place the FLEX operating system code in ROM.

I have to partially retract that statement. Somehow, I managed to forget that the 6800 only has one index register; the X register must to be ping ponged between I and J. Still, completely unrolling that loop makes the 6800 code about as fast as the 6502 version, but with much bigger code size. The result would look something like this:



There are two other service subroutines for the symbol table sorter.

CMPLBL compares two symbols, pointed to by the variables I and J. Note that the 6800 version uses a couple of temporary variables instead of modifying I and J, then fixing them after the loop is finished; this same approach would have made the exchange subroutine better. Completely unrolling the loop is again the fastest implementation.

The original 6800 code:



The 6502 code:



PUSH pushes an address onto a software stack. This code is an even test which illustrates shortcomings in both processors. The 6800 does not provide easy access to the index register; this is corrected in the 6809. The 6502 does not provide an easy way to perform 16-bit arithmetic.

The original 6800 code:



The 6502 code:



At this time, the symbol table sorter has been completely coded. Wish me luck as I begin to test it...

I am now able to cross assemble most inherent 6800 instructions.

While 6800 binary files currently have no value on a 6502, this means that a large part of the fundamental infrastructure of the assembler is working.

Next up, evaluating expressions...

This project is now two months old.

The FLEX file system (File Management System or FMS) is still lacking the code for writing random access files until I can come up with a good way to test it. I may go ahead and write the code but leave it disconnected to get an idea how big it is likely to be.

The FLEX user interface portion is feature complete except for background printing. Again, I may write the code to find out how large it will be. The error message reporting mechanism is complete.

There was little progress on the Utility Command Set this month. The SAVE utility has been written, but not thoroughly tested.

The 6800 assembler now runs on the 6502 as a cross assembler. To help test it, I have started implementing the text editor. It can currently create a text file and make some simple edits to it. The editor is definitely more difficult code than the assembler has been.

The current system 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.

It is time to start trying to freeze the memory organization. I am considering making a somewhat radical change to move the public portions (entry points, variables, Utility Command Space) from $200 up to $2000. Why? Doing this will make it possible for a KIM-1 or clone with a expanded RAM and a serial port to run FLEX. The operating system itself can reside from $200 to $2000 on systems which allow that and at the top of user memory otherwise. Because the binary file format consists of a collection of separate chunks, pieces of the system can potentially be built to load into several disjoint places where memory is available.

Another decision is whether the system should reserve a part of the lower or upper end of the zero page.

The important part now is to determine where the public portions are located. This is where I need your input as to what your particular system requires and allows. It may not be possible to please everyone, but the main goal is to have one version of the utilities and application programs which work on all supported platforms.

The text editor code has been difficult; I can only stand to work on it a bit at a time.

The 6800 version keeps values in the X register for long stretches of code, sometimes across several subroutines. I am about to give up trying to keep it in 6502 registers even part of the time, but to declare RegX, a 2-byte variable in the zero page, and copy values into and out of it as the 6800 loads and stores X. Addresses already have to be stored in the zero page to access memory. It will not be as efficient, but the code will be somewhat clearer; this program really needs that.

So far, the following functionality is complete:

loading a file
saving a file
text buffer management
Print command
Insert command
Delete command
Renumber command
Overlay command
Find command

The Copy command has been coded, but it does not work. When that is done, the Move command should be easy as it does a copy followed by a delete. I would guess we are somewhat past the halfway mark.

During breaks, I have been working on assemblers.

First, I added the SET directive to the 6800 ASMB. It is like EQU, but a label may be assigned a value more than once.

I have always liked the local labels in RELASMB, the 6809 relocatable assembler, and wished that ASMB implemented them.

Local labels work like this: a one or two digit number in the label field is considered to be a local label. It is referenced by stating the number followed by a "b" or "f" to designate whether to search for the nearest occurrence of the number before or following the current line. Note that it is not possible to find a local label on the current line. For example:



Advantages of a local label include doing away with the need to come up with meaningful and unique names for short, trivial branches and a local label uses less memory than a regular symbol.

A web search for local label uncovered no prevalent standard, but a number with a "b" or "f" suffix is a very common form.

I will put a seemingly arbitrary limit on local labels: the number may not consist of only "0" and "1" digits. Why? ASMB 6800 accepts binary numbers in both the %xx and xxb forms. Something like "1b" is ambiguous.

I had been initially tempted to limit the reference of local labels to relative branch instructions to prevent people writing FORTRANish code, but RELASMB does not have that restriction. And it is convenient to be able to do something like the following:



I am currently implementing local labels in my 6502 cross assembler. Should that go well, the capability will be migrated to the 6800 and 6809 assemblers. Then I will implement it in ASMB 6800; ASMB 6502 will inherit that functionality.

Great to see you making progress with this project. Unless I missed it, I think you're doing all of this on an emulated 6502 system, correct??

If yes, what would be an actual hardware configuration to implement with a 6502 system? I've been working on an IDE interface for my SBC and will eventually create a BIOS to access it. Perhaps FLEX could be implemented as the OS?

_________________
Regards, KM
https://github.com/floobydust

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