Six Forks Assembler and Linker

[Alfred]

This will be a bit of a wall of text, but oh well.

So back when Six Forks was created, floppy disks were the main storage medium. If you use Six Forks to develop software and you follow Hume's methodology of small modules, you can end up with a lot of them. Case in point, Six Forks itself consist of a lot of files: 77 for the assembler, 61 for the linker and 36 for the utilities package. Since most Dos' can't store so many files in one directory (SDX I think is only one > 128) , Hume used a file he called PACKID as a way of labeling diskettes, as he explains in the manual. This allowed you to keep track of which diskettes were source code and which ones were object files. The latest updates that I've posted, while they still require you to specify the PACKID labels, neither the assembler or linker verifies them. I removed the check because with hard disks, it didn't seem necessary, although I expect it's a pain under MyDOS without batch files.

Even with batch files and SpartaDOS it's still a nuisance copying the .R and .E files to a separate directory, and you still can't put all your relocatables together if you have too many. So to try and fix it without having to totally rewrite Six Forks, I'm making the following change to PACKID processing.

The name specified on the .OUTPI statement will henceforth be treated as the name of the PACKID file, rather than PACKID. So .OUTPI ALFRES will look for a file in the current directory called ALFRES. It will then open that file and read the first line of text and use that line as an output path for both .R and .E files. So for example, if ALFRES contains the line D1:R> then any .R/.E will be written to the R subdirectory of the current directory. Or you could put the full true path, which for me would be D1:>SIXF>SFAV2>R>

This should make using Six Forks a lot more convenient. I'm currently testing it, as well as testing some early 65816 stuff. I've added all the mnemonics, but the first release will only enable the ones that will work in a 16 bit environment. So for example JML and JSL will not be available, and instructions like LDA will not accept 24 bit addresses. Long zero page will also not be available in the first pass.

After that, next will be the addition of a .IPATH directive will will work like .OUTPI except it will apply to files open for input. This is to allow a .INCF include directive, to include additional source files. This turns out to be necessary because the assembler doesn't support instructions like : LDX #vart-chart where both variables are virtual. The Action! source has that kind of thing all over, and rather than cut and paste the equates into all the different files, an include mechanism seemed neater.

The XE version of the assembler has also been updated to allow for 2048 lines of source code, compared to the current 1280.

I'm only posting SFAXE tonight, it's the only one that's changed. .OUPTI pathing is in effect. All 65816 instructions that have no operands, like XCE should be usable. Others, that have 16 bit modes like BRA or STZ should also work, but only for 6502 modes. LDA (zp) is the only new addressing mode that is working. Next I'll do the [zp] modes, and then maybe the long branches. I'm not sure yet about the 24 bit address modes, it might not be possible to enable those in this level of Six Forks. I've updated the decimal conversion routines, but 24 bits will need a lot more work than that.

SFAXE.OBJ

[Alfred]

An updated ATR this time.

 

SFAXE now handles the [zp] form of instructions. PER, PEI, PEA should all work, as well as BRL. SFAXE and SFLXE also display the proper values for bytes available and bytes used in the buffer.

 

SFAXE is not XE specific, it should work fine on an XL. It's just if you run it on an XE or Axlon 800, it can use the extra ram, whereas the non-XE versions will not.

LatestSixf.atr

[Alfred]

Updated SFAXE. Stack relative forms exp8,S and (exp8,S),Y now valid.

 

Probably the last update to the assembler for a while. The remaining exp24 forms will need some work, and MVN/P turn out to be a lot more trouble than I thought because of that second one byte value.

 

So probably next I will fix the linker to use input and output pathing for the .R/.E files, since I'm about at the limit. I think I have 124 object files in the assembler directory currently. So the linker will be changing such that:

 

/INPUTS ON ALFRES: will open the file ALFRES and read the first line of text and use it as an input path.

 

/BINOUT ON BINRES: will open the file BINRES, get the line and then use that as an output path.

 

If either file is missing, then the current directory will be used, same as the assembler currently does,

SFAXE.obj

[Alfred]

I have a rough first pass of the assembler and linker with full 65816 support. All instructions, and all address modes are supported. One of the major issues that I'm not sure is completely resolved is the handling of 24 bit addresses. While the assembler has no trouble dealing with something like STA $123456, problems arise when dealing with virtuals. Under the 6502, all addresses are 16 bit, so no problem. A virtual reference on the 65816 however can be either 16 or 24 bit, and the assembler simply cannot tell which it is. The WDC assembler handles this by requiring you to code the forced long ">" address command if you know the external variable is going to be 24 bit. Or I think you can tell it all external references are to be treated as 24 bit, I don't recall atm. I don't like either solution. The first one is too much typing, and the second seems wasteful. Since your code mostly won't cross a bank boundary, why pay the time and space penalty for every external reference.

 

Now for zero page, Six Forks has the .VIRT8 which allows you to signal virtuals which are to be treated as 8 bit values. I am toying with the idea of adding a .VIRT24 to do the same thing for external 24 bit references, of which there should not be many. The main case would be all the OS equates in bank zero, which would all have to be long references for anything not running in bank zero. I am thinking maybe a special .PUB24 directive to be used with the .ENTRY directive to force the output file to forced 24 bit references, and then include that file, rather than use virtual references. I don't like having to use a .include but I don't see many options.

 

Anyone else have any other ideas on how to handle 24 bit virtual references ?

[Alfred]

Also, I've started typing the original Six Forks manual into some cheap PDF editor I bought. So at some point I'll release a new manual with some pages added describing the updates I've made to the package.

[Alfred]

I've added the .INCF directive to include additional files. It's only meant really to be used in the case where you have virtual references use in immediate operands. Six Forks only supports one virtual in any given expression, so in the Action! source where you have things like:

 

CHART = 1

VART = 8

 

LDX #VART-CHART

 

Six Forks can't resolve the expression because both values would be virtual if the source was properly structured. .INCF is meant to be used here so that these multiple references for immediate operands can be resolved. The case doesn't seem to come up with anything but immediate operands.

 

I think at this point that's about as far as I'm going to extend the base Six Forks. The programs are too big to fit into a standard cartridge and it would be a large amount of work to fix it for any cartridge because I'd have to move a boatload of self-modifying code and variables out of the cartridge area. That seems like a lot of work for nothing. So what I'm thinking of at this point is to produce a new 65816 only version of the entire package along the lines of MAE. Put the Action! editor in as the text editor, along with the assembler, the linker and maybe a DDT like debugger that I have here that I wrote but don't think it's fully debugged, heh. I think having all the programs loaded up at once would make them a lot more usable, just from using the editor a lot. I don't know that it will all fit into a stock 130XE, might have to have 256K minimum, at least for the linker. Or perhaps I'll allow it, you'll just have to deal with the issue that the linker won't be able to build as large an object file as it could.

 

While I'm sure I'm going to use 65816 operands, I'm a bit on the fence about whether to make it work if you have some sort of extended memory, either Axlon or a D301 upgrade. I expect I'll do both, because while I only have banked ram on my T816, I expect that I'll get a Rapidus in the near future.

 

One last change I might do is increase the label size to eight characters, six just doesn't seem to be quite enough when dealing with other people's code (OSS). If anyone has any other ideas about other features to add to Six Forks, I'd be interested in hearing them. With the 65816, memory isn't the problem that it might otherwise be. A macro facility is an obvious one.

[Alfred]

Mostly out of curiosity I phoned Hume tonight. He's still alive and is doing things with embedded devices. Pretty good to still be coding in C at 77. About Six Forks though, his memory is a bit spotty, but he did agree to have a look at some things I was curious about if I emailed him the code, so we'll see.

[Alfred]

An updated ATR. The main change here is to SFAXE which now supports the .INCF directive:

 

.INCF ACTZP

 

will include the file ACTZP from the current directory, -appending- it to the source code already in memory. It's only needed if you have to include some equates to resolve the case where you have two virtuals in an expression, which really ought not to happen often.

 

This will be the last update to Six Forks for a while, unless I come across some bugs. One thing to note, with regard to MVN/MVP. The usage in Six Forks is backwards, and matches the object code. Normally you code MVN as:

 

MVN src,dest

 

and the object code results in $54 dest,src. In Six Forks you code it as : MVN dest,src and then you get $54 dest,src. For us S/370 people dest,src is the natural order of things anyway

 

Eventually I'll fix it to match the WDC spec, but because of how SF handles expressions it was just much simpler to do it this way for now.

 

So next is I'll get AlfDOS finished, and then I'll return to Six Forks and produce a new version which will be more like the WDC assembler, with support for named sections. I'll also be bundling it up to be like MAE, so it's only going to work on machines with banked ram, at least 192K or real 65816 machines with >64K installed. It'll be the Action! editor along with Six Forks, and maybe some kind of Make facility, I'm not sure. I want to add something to make it easier to manage all the source files, so some kind of project manager will get in there, just not sure what at the moment.

LatestSixf.atr

[Alfred]

Much to my surprise, it turns out that the WDC 65816 assembler is unsuited to creating binary files for the Atari. One of the problems is it insists on sorting segments by address and then filling in the gaps, even when told not to do so. So for example, by adding a run vector at $02E0 you end up with 32K of padding between $02E2 and say $8000 where the program starts. So I think I will have to return to Six Forks and polish it up some more in order to make progress with my other 65816 projects.

 

I'm going to more clearly delineate between the versions and their abilities. So SFASM and SFLINK will remain as the baseline original programs. SFXL and SFLXE will revert back to 6502 code only with any new features that do not involve the 65816 like .INCF. SFAXE and SFLXE will remain as they are, with 65816 code ability. They will also get increased label length, since they can use extra memory. Labels will be increased to a maximum of eight characters long. SFLXE will be able to handle object files from either SFAXE or SFAXL or even SFASM.

 

Finally, a new version of the two programs will be forthcoming as SFA16/SFL16. These are native 65816 versions and will only work if you have a 65816 cpu installed. They also require some form of extra memory, either 192K of XE style memory or 240K of Axlon type memory. I think I have it set at the moment that 12 banks is minimum required.

[Alfred]

I'm going to close this thread out, and post future updates in the Programming section. I think that's a more appropriate forum to discuss programming tools and ideas.

[_The Doctor__]

what's the link in the programming section.. curious to see the updates, I think you've made a few to get to work on Bruce Lee...

[flashjazzcat]

http://atariage.com/forums/topic/288955-six-forks-assembler-upgrades/?do=findComment&comment=4239350

 

I think you already posted in the thread.

[_The Doctor__]

Got to it and didn't get back to update my post before edit window expired...

[Alfred]

Here is the original source code for the Six Forks Assembler and Linker.

 

Since it's a linker based package, you will notice the extensive commentary Mr. Hume has placed in every file. This is one of the Six Forks advantages, you can do this without it causing size issues when it comes to assembling the source. Compare this to say the Blue Max or Envision source code. Having such commentary has made it enormously easier to update the package.

OldSixfSrc.atr

[+MrFish]

Here is the original source code for the Six Forks Assembler and Linker.

 

Thanks!

 

 

Since it's a linker based package, you will notice the extensive commentary Mr. Hume has placed in every file. This is one of the Six Forks advantages, you can do this without it causing size issues when it comes to assembling the source.

 

The comments far outweigh assembly instructions, to the point it's almost hard to recognize as being source code. First Atari source code I've ever seen like this.

 

 

Compare this to say the Blue Max or Envision source code.

 

Haha... I don't think Blue Max has a single comment. I imagine he had, at least, some basic notes on the source.

[Kyle22]

I LOVE fully commented source code.