Jump to content
IGNORED

Six Forks Assembler Upgrades


Recommended Posts

I've finished typing in the original Six Forks Assembler and Linker manual, and added some pages regarding some of the changes I've made. Still need to fix the index page, and sort out the page numbers. Once that's done, I'll post it here for people to proofread.

 

The next set of new programs will be the SFAXL/SFLXL pair. I plan to introduce new features into the baseline programs, and then roll them into the other versions.

 

Last night I added .CBYTE, .SBYTE and .ASTR. The first two work like they do in MAC/65, while .ASTR produces a string variable in the format of an Action! array. The first byte is the length of the string, followed by the

actual string data. One flaw in this is that it doesn't permit reserving space, so I may change it to something like:

 

MYSTR .ASTR 40,"THIS IS MY STRING"

 

In that example, 40 bytes total would be reserved and the given string would populate the first 17 bytes.

 

I'm a bit on the fence regarding .FLOAT. I've never used it, or had a need for it, but I suppose if one was writing code to interface with BASIC, it might be useful. Does anyone think that a .FLOAT directive

would be a useful one to have in an assembler ?

 

I also plan to add a .IBIN to allow including binary data directly. I'm also trying to think of ways that SFLXL might be changed to allow it to create larger binaries without having any banked ram, perhaps by using a

temporary disk file.

 

Another tool will be something to handle relocatable files, to combine them into libraries, or to extract functions from a library. Libraries are a feature that were added into the linker but were never documented in the

manual. It also has the ability to export a symbol cross-reference file. I plan to do away with the xref file, but plan on adding the option to produce a file that would allow for source level debugging under Altirra.

 

The next big change will be to allow for 8 character label names. This will be to only the XE and 816 versions, since they can use banked memory to make up for the increased main memory usage. I've thought about making the

limit larger like say 12 characters, but I don't think I've seen much assembler where such long labels are used. Does anyone think it's a common use to have labels longer than 8 in assembler ? I noticed that the Atari OS

source code posted here a while back is all six byte labels, I think maybe DOS 2.0 is as well.

 

Anyway, that's the current status. I'll post a new ATR shortly, along with the revised manual.

  • Like 3
Link to comment
Share on other sites

No, I just sat here with the keyboard in my lap and the manual on the desk and typed it in. I brute force a lot of things; many years ago I typed in the whole Action! manual, although today I think I only have part 2.

 

Too many things to be done, not enough time for them all.

  • Like 4
Link to comment
Share on other sites

Hi,

 

If you have a smartphone, you can use Google translate to photo the text, Google will OCR the text, and you will get the original text, and text from whatever language you tell Google to translate to (this isn't important if you are just using Google translate to OCR text). It's a bit tedious, but this was how I translated the "Atari Magazin" articles on Happy 1050 programming.

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

We could request the other thread in it's entirety be move to this one... you can use the report function on the first post of the other thread and ask the entire thread be merged/moved into this one and then go about continue posts and updates here. That should accomplish what I interpreted as your intentions or thoughts for where the project should be placed here on AA.

Edited by _The Doctor__
Link to comment
Share on other sites

We could request the other thread in it's entirety be move to this one... you can use the report function on the first post of the other thread and ask the entire thread be merged/moved into this one and then go about continue posts and updates here. That should accomplish what I interpreted as your intentions or thoughts for where the project should be placed here on AA.

 

There's only a couple of posts over that would be informative, so I'm not going to bother asking for a thread merge.

 

I've been busy straightening out issues with the source. Unfortunately I made the 65816 changes to my baseline XE code and then when I ran into some challenges to add some other stuff, the 816 code was in the way. So I had to go back a fair ways, pulling code from the original Hume codebase. Since then I've mainly made changes to the internals, to make it easier for future updates, while still being able to generate binaries of varying abilities.

 

For the Bruce Lee project I'm running a version labelled XE8. This is basically the SFAXE line, except it handles 8 byte labels, rather than 6. The label names in the mads disassembly were so long that I was just having too much trouble condensing them to six characters. I've also removed the 65816 support, because I plan to implement it back in in a neater fashion. 8 byte names for external references is the S/370 standard for IEWL and I don't want to hear anything about GOFF or the binder.

 

SFAXE8 is about the limit of what Six Forks can handle without major internal revisions. The limit is 800 external references, with the assembler exporting a maximum of 384 labels. There's 187 bytes left in main memory for code expansion. For Bruce Lee, there's 524 bytes left in the 77K buffer to produce a binary file 41,528 bytes long. 748 external references. So that gives an idea of how large a project you can build with the XE8 line, which I will release here shortly. There's no other native Atari assembler than could even touch this project, and even it's teetering on the edge.

 

Edit: It takes 1:47 to link that 40K file with the screen on. I think I'm going to change the linker to turn DMA off if any XE banks were used to hold object data. Seems right since that would mean there was more than 20K of relocatable file data.

Edited by Alfred
  • Like 1
Link to comment
Share on other sites

Latest Six Fork disk. I've included most of the past versions as before. As mentioned above, the XE8 line is receiving the most effort. Due to the lack of memory, I think the XE8 will diverge from the plain XE and -require- XE memory rather than just use it if available. In order to add 65816 support, something has to give, because I want that version to be the most flexible in terms of size. It's pretty much right at the edge for Bruce Lee, and I want to eliminate that. So future changes will be to increase the number of banks used in the linker to 12 (192K) which ought to be good for about a 108K binary. Not that I think anybody would ever do such a thing. The SFAXE assembler will stay at 4 XE banks. Anything more and it'd be just too slow to tolerate, and handling huge assemblies isn't why you would use Six Forks.

 

I'm also including my draft of the original manual. Yes, I know, a lot of the chapter headings and footers are wrong, and they'll get fixed eventually I've corrected some small errors that were in the original, and added some new pages at the end to describe the changes and features added to the latest versions.

NewSixf.pdf

CURRENTSIXF.ATR

  • Like 4
Link to comment
Share on other sites

I've updated SFLXE8 to use 7 XE banks, if they are available (256KXL or 320K XE). This results in about 125K buffer, which should be sufficient to generate a full 64K binary for an eprom. Once I've made a few more changes, I'll post an updated ATR. The maximum number of external references is now 1024.

post-7980-0-43050700-1552962005_thumb.jpg

Edited by Alfred
  • Like 3
Link to comment
Share on other sites

  • 2 months later...

The manual in #7 seems to be with OCR or am I wrong?

 

Further, please Alfred, take a look at our ACTION! site regarding the manuals:

 

https://atariwiki.org/wiki/Wiki.jsp?page=Action#section-Action-ManualsAndDocs

 

GoodByteXL makes the best pdf files I know of. And I know a lot over the decades...

 

If we can help you, please let us know. The other assemblers, I will upload when time. Sorry, for the delay.

  • Like 2
Link to comment
Share on other sites

  • 4 months later...

Now that farming season is mostly over, I've returned to working on Six Forks. Tonight I've finally successfully bootstrapped Six Forks up to the 8 byte label version with the remodeled code. SFAXE was used to create the new SFAXE8 and then SFAXE8 assembled itself to produce another copy, which finally matches the base version. Ditto for SFLXE8. Maximum buffer is 132552 bytes which should be able to produce a 70K binary. 65816 code will require larger relocatable offsets for 32 bit values and 24 bit addressing, but hopefully SFLXE8 will be able to produce full 64K segments.

  • Like 1
Link to comment
Share on other sites

Well I have to say I'm a bit puzzled by the 23 downloads of the disk. Since nobody except maybe the Doctor replies, it doesn't seem like anybody is using Six Forks, so why bother downloading the updates ? Not that I care really, I'm upgrading it for my own purposes; it just seems like an odd thing. Anyway, I've added the first set of directives back for the 65816 (.ALLB/.ALLW, .ACCB/.ACCW and .INDB/.INDW). Tonight I'll add the single mnemonics like TYX that don't require code changes, and then the simple ones like BRA. Last will be the 24 bit mode instructions and MVN/MVP because those require major changes to both the assembler and the linker. I didn't do it properly first time around, but I will in this version.

 

Once that's done, I'll use SFAXE8 to produce a fully native SFA16 that will work like the WDC version. The architecture of Six Forks is meant to produce a linear binary, like every other Atari assembler. In order to produce full relocatable files as outlined in the DataQue T-816 document requires an assembler/linker that works like the WDC one, except without some of the odd behaviors that one evinces. I plan to mate the Action! editor (in 65816 mode) with Six Forks, along with a MAKE-type utility, and have something like the MAE system.

Link to comment
Share on other sites

Hi Alfred,

 

The problem is, the more complex the problem is, the more time you must give the users.

 

Not every user has a 65816 mode. Did you made contact to drac(?) in Poland, who is working on the 65816 as you are?

 

The same is true for the Atari Accountant. The most expansive program for Atari of all times, but nearly no user...

https://atariwiki.org/wiki/Wiki.jsp?page=The Atari Accountant Series

 

Same for Calculator in 2012, nearly no one was interested in. But 2 years later, more and more user are familiar with it.

https://atariwiki.org/wiki/Wiki.jsp?page=Atari Calculator

 

Or 1905: the theory of relativity (special), 3 people got it.

1915: the theory of relativity (general), 15 (?) people got it?

 

You are too far ahead of your time... ;-)

 

But we like you this way, of course.

 

If we preserve all the knowledge, so I think, it will be in the best hands for the generations who follow us.

Link to comment
Share on other sites

Just when updating the mnemonic tables, I realized Six Forks does not handle the BRK instruction properly. BRK causes the program counter to increase by two, yet Six Forks only treats BRK as a one byte instruction, so you must add a .BYTE after BRK to pad it out properly. Curious, I ran a test with MAC/65, and it doesn't handle BRK correctly either; it only increased the PC by one like SF does. I don't get why they treat it like that. It should be treated as a two byte instruction, because a default interrupt routine that consists of only an RTI would then cause the interrupted program to crash following a BRK, if you failed to pad it properly.

 

I get that it simplifies handling BRK and for that matter COP, but it's wrong. The assembler should not depend on the user knowing to correct its faulty implementation. I'd ask Lawrow if I knew how to reach him why he deliberately muffed it.

brkm65.jpg

Edited by Alfred
added pic
  • Haha 1
Link to comment
Share on other sites

I used the 1.01 cartridge. There's no reason to think any of them are different in this respect: it's a design decision, not a bug. I'll have to check the DataQue assembler and maybe MADS and see if they do the same thing. My own AlfAsm might have the same bug, I don't recall noticing the discrepancy back then. I've never used BRK.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...