Jump to content
  • 0

Native assembler, preferably open source


Stefan
 Share

Question

Hello,

Is there an assembler for 6502 that could be made to run natively on the X16?

Preferably it would:

  • Be open source
  • Read source code from files
  • Assemble directly to files
  • Support at least named labels, basic compiler directives (for instance .byte, .word, .text) and macros, simliar to the Commodore Macro Assembler that you could use on the C64

I've been searching, but it seems hard to find.

I used the Commodore Macro Assembler a lot with my C64 in the 80s. Even though I had a disk drive, it was cumbersome and took quite some time to edit, save, assemble, load and test each change in a program. If the real X16 reads and writes SD card files at the same speed as the emulator, we would be getting much closer to a modern experience with a file based assembler.

Link to comment
Share on other sites

Recommended Posts

  • 0

I'm new to assembler, and I got confused in this discussion about different assembler implementations. X16 will ship with The Assembly Environment by @mjallison42, which is expected be the default and most common assembler for most X16 users.

What would be the purpose of other assembler implementetions discussed here? Is it alternatives, so each user could choose which one he likes more? Or rather additions with different features? Or an attempt to create your own yet another assembler because creating one is fun and interesting? I think any of these variants is okay. It is always good to have variety of software. I just wish to hear what others think and how they see this.

Link to comment
Share on other sites

  • 0
Posted (edited)

Even though there are a lot of 6502 platforms and even more assemblers, I would say there's a gap in the market:

  • Open source 6502 assemblers are rare.
  • 6502 assemblers are often tied to a development environment making them hard to port other 6502 platforms.
  • An assembler that uses source files as input should be much easier to use on different platforms.
  • Another advantage is that you are not tied to one development environment, but may use any editor of your liking.

I once heard an economics professor say: There might be a gap in the market. But is there a market in the gap? Let's find out!

Edited by Stefan
Link to comment
Share on other sites

  • 0

I don't think there is any lack of open source 6502 assemblers, with ca65 and acme leading the pack. Compiling them to run on a native 6502 platform may be difficult, but they do compile just fine for any modern platform, and using sophisticated macro assemblers like these are going to really require cross-assembly from something with more horsepower than the X16. @mjallison42's assembler will be in ROM, and that's going to be hard to beat as an online (in the original sense!) option.

Link to comment
Share on other sites

  • 0
Posted (edited)
3 hours ago, SlithyMatt said:

I don't think there is any lack of open source 6502 assemblers, with ca65 and acme leading the pack. Compiling them to run on a native 6502 platform may be difficult, but they do compile just fine for any modern platform, and using sophisticated macro assemblers like these are going to really require cross-assembly from something with more horsepower than the X16. @mjallison42's assembler will be in ROM, and that's going to be hard to beat as an online (in the original sense!) option.

I thought so too.

That was the start of this thread, calling out for open source 6502 assemblers that run natively on the 6502 and which with relative ease could be ported to the X16.

It turns out to be really hard to find any such open source assembler. This thread is all about native programming on the X16, so the CC65 suite, however great to use, doesn't count. All assemblers discussed so far in this thread have different issues: source code can no longer be found, may be widely spread and used but without clear legal basis and/or are so closely tied to a develop environment that porting to X16 would as hard as writing the whole thing from scratch.

That said, if there is an open source natively running 6502 assembler, preferably one that could be made to accept plain text files as source code, I'm listening.

Edited by Stefan
Link to comment
Share on other sites

  • 0
On 5/14/2021 at 10:09 PM, Stefan said:

All assemblers discussed so far in this thread have different issues: source code can no longer be found, may be widely spread and used but without clear legal basis and/or are so closely tied to a develop environment that porting to X16 would as hard as writing the whole thing from scratch

Um... the file based assembler has none of those problems. iIt has a few other issues so far, like no macros, no expressions, no includes, but with help, I think those can be fixed?

  • Like 1
Link to comment
Share on other sites

  • 0
Posted (edited)
56 minutes ago, desertfish said:

Um... the file based assembler has none of those problems. iIt has a few other issues so far, like no macros, no expressions, no includes, but with help, I think those can be fixed?

Yes. Sorry. I meant that we have not yet found a previously existing 6502 assembler without these problems. The question I was answering was why we would need yet another assembler - your file based assembler.

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

  • 0
On 12/31/2020 at 11:50 PM, desertfish said:

I prefer plain text files as well but mainly because I'm still focused on manipulating them on other systems outside of the Cx16 itself.  If we're strictly limiting ourselves to working on the cx16, the benefits of working with plain text files is less clear to me.  

There are some problems I think with text files as source.

- they take up much more memory and disk space than a binary format, so a source listing is quickly larger than the available memory. There is enough banked RAM to load it but dealing with data split up over different banks may complicate processing it as a single file a lot?
- text is inherently more complicated and slower to process than a dedicated binary format.   Although maybe the 8 mhz can just brute force negate this?
- editing can be problematic (naive inserting and deleting requires moving a lot of data around in memory).  Although you seem to have solved this admirably in your text editor already !

(1) I think a line oriented editor is fine with longer text files ... before it begins to be an issue, you should break the file up into pieces and use an include mechanism anyway.

(2) I do think the 8MHz makes it less of an issue than back in the day ... as does the speed of the SD card compared to the speed of a floppy drive (never mind a "random access tape drive" like the 1541)

(3) Responsive text editing with a 2MHz C128 or a 4MHz Osborne was already a thing back in the day, so if the editor is laggy, that's more a bottleneck to identify and fix than an intrinsic problem.

So regarding (1), yeah, getting an include mechanism working, mentioned as a MSD (MaybeSomeDay) on the GitHub is an issue. Also + ++ - -- to which I am now pretty much totally addicted.

Edited by BruceMcF
Link to comment
Share on other sites

  • 0

I would like to add a source and binary file including mechanism to the assembler, but that requires a total rewrite of the file I/O logic, to deal with multiple sources rather than one contiguous block of memory.  I also have no idea yet how to keep track of what file the currently parsed source line is coming from, if you're jumping between files due to includes.

Link to comment
Share on other sites

  • 0
Posted (edited)
5 hours ago, desertfish said:

I would like to add a source and binary file including mechanism to the assembler, but that requires a total rewrite of the file I/O logic, to deal with multiple sources rather than one contiguous block of memory.  I also have no idea yet how to keep track of what file the currently parsed source line is coming from, if you're jumping between files due to includes.

That would be very useful.

I guess it could be treated as a stack based problem, i.e. a stack that holds references to files and next line number within each file. On starting the assembler the first file is pushed onto the stack. When including a file, it's pushed onto the stack. When at the end of the include file, it's pulled from the stack, and so forth. The stack might have to be a custom software solution.

What I do not know is how to effectively handle multiple files from a file system perspective.

Can you keep multiple files open at the same time? If so, how many?

If not, when reopening a file, AFAIR there is no seek command. To get back to a specific line number within a reopened file you would need to read the file from start counting the line breaks. I don't know badly that would affect performance. 

Keep up the good work!

Edited by Stefan
Link to comment
Share on other sites

  • 0
2 minutes ago, Stefan said:

Can you keep multiple files open at the same time? If so, how many?

Commodore 64 BASIC allowed 10 open files. That may also be a kernal limitation, I'm not sure. Regardless, given that is the basis of X16 firmware, I think that should be adequate for most purposes.

Link to comment
Share on other sites

  • 0

@Stefan that file stack tracking the line number count is a solid idea.

@Scott Robison 10 files should be enough (tm) I'm glad to learn it is actually possible to keep multiple files open and read from each of them.   However maybe this isn't even necessary if we keep track of any import statements encountered along the way and executing them after the file they occur in has been fully read.

Allowing multiple open files at the same time would also require changing prog8's diskio routines -- they assume a single open file channel (hardcoded)

Link to comment
Share on other sites

  • 0
Just now, desertfish said:

@Stefan that file stack tracking the line number count is a solid idea.

@Scott Robison 10 files should be enough (tm) I'm glad to learn it is actually possible to keep multiple files open and read from each of them.   However maybe this isn't even necessary if we keep track of any import statements encountered along the way and executing them after the file they occur in has been fully read.

Allowing multiple open files at the same time would also require changing prog8's diskio routines -- they assume a single open file channel (hardcoded)

10 files is also a kernal limitation, after reading a bit further. Note that this is 10 files spread across all devices. From what I was reading, you might not be able to open all 10 files on a single device, so the limit might be lower, though given the X16 implementation, I suspect {knock on wood} that you should be able to open 10 at once via sdcard.

Link to comment
Share on other sites

  • 0

I guess in practice we have max 8 then as the keyboard and screen are already taken as default input and output io channels.   Still who's going to program on the cx16 and use that many files in a project?  (famous last words)

Link to comment
Share on other sites

  • 0
48 minutes ago, desertfish said:

I guess in practice we have max 8 then as the keyboard and screen are already taken as default input and output io channels.   Still who's going to program on the cx16 and use that many files in a project?  (famous last words)

640K is enough for anyone, so 512K + 64K + 128K = 704K is more than enough!

Link to comment
Share on other sites

  • 0
10 hours ago, desertfish said:

I guess in practice we have max 8 then as the keyboard and screen are already taken as default input and output io channels.   Still who's going to program on the cx16 and use that many files in a project?  (famous last words)

8 simultaneous files might very well be enough 🙂

The open file count doesn't limit the number of source files as such, but the level of includes (a file that includes a file, that in it's turn includes a file, that includes a file and so on). In 6502 assembly I seldom go beyond one level of includes.

If you would not like to have that limitation, I think it's doable.

The file stack mentioned above could hold the following info:

  • File number if file is open, otherwise a value telling us it's closed (a value that's not a valid file number).
  • File path, so we can reopen the file if need be.
  • Next line number, where to continue assembly when we get back to this file.

When including a file:

  • The line number where to continue assembly in the parent file is stored in its stack entry.
  • Check if there is a free file number that can be used by the include file
  • If no file number is free, one of the files on the stack needs to be closed. The file number stored in its stack entry is set to the chosen "closed value".
  • The new include file is opened and the details are stored on the file stack.

When reaching the end of an include file:

  • The included file is closed and removed from the file stack.
  • The parent file details are read from the file stack (without removing the entry of coarse)
    • If it's already open, set it as input file
    • If 'ts closed, open it, and read until getting to the line number where to continue assembly
Link to comment
Share on other sites

  • 0
11 hours ago, desertfish said:

I guess in practice we have max 8 then as the keyboard and screen are already taken as default input and output io channels.   Still who's going to program on the cx16 and use that many files in a project?  (famous last words)

In checking out Vice for C=64, the screen and keyboard are not "open" per se. You can open their device numbers directly, but they are the default stdin stdout devices apparently. So still 10 logical files can be open at once, but the number per device is device dependent.

Link to comment
Share on other sites

  • 0

For this assembler I'm assuming we have enough memory to
a) store all source text files in memory simultaneously
b) store the resulting machine code program in memory
c) have enough memory for the parsing and symbol table (the assembling process itself).

It's a 2-pass assembler so I think it should be possible to avoid having to use the stack of open files during the reads themselves. I think we could just read the files sequentially when the assembler encounters include instructions in phase 1. And use the stack only in phase 2 where actual machine code is generated.  This would reduce some complexity in the disk io routines (although the multi-file support across banked ram pages is still going to have to happen, rather than using one contiguous chunk of vera memory for storing the single source file currently)

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.

Guest
Answer this question...

×   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.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use