Welcome to asm6502 Discussions!

[boeckmann]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[waltje]

Great !

I am still working on my release, but here's my ChangeLog for you:

---

• implement full getopt interface
• full source restructuring, broken up into modules
• allow 'X' for .byte
• fix .org to auto-fill
• add a .end directive
• implement .fill
• fix the symbol table stuff, added 'where' to them
• add generating hex files for output
• add << and >> operators in expressions
• fix the ^ and / operators in expressions
• fix the ! (NOT) operator, added the ~ alias
• support '.', '*' and '$' for "current", not just @
• added "EQU" in addition to "="
• implement .binary (and .blob) for binary blob imports
• add ".page [plen[,pwidth]" and ".title [str]" directives
• add paged listing file
• add .cpu directive and underlying multi-target support

• implement .nol option
• implement .sym option
• allow [] for expressions, not just ()

• implement multiple source files on command line
• add generating .s19 et al (Motorola) files for output

• Add C02/RC02/WC02/816, 68xx, 80xx et al support.
  The basic infrastructure for multi-CPU support is in now in place; we can
  start adding more processors and their (sub-)models in the backend files.

• Filling, ORG and hex files.
  We currently allow for filling spaces and auto-filling the .org directive
  for use with straight-binary output files. This is, however, not necessary
  if we are using hex (IntelHEX) or srec (Motorola SRecord) output files, as
  those formats "know" that data does not have to be linear. For this to be
  implemented properly, we will have to re-work the "generating output" code
  to do it as it goes (in pass 2), and not only at the end of that pass. This
  allows such "jumping" to be handled by those file formats.

• Reading raw source data.
  We currently perform binary-mode reads on the input source files and all
  included files. Although this works fine on Linux (and, assumedly, on all
  such systems), it does not seem to behave the same way on Windows systems.
  The problem is that while we do an ftell() to get the size of a file, that
  will give us the "raw" size of the file, as it is on disk. We then allocate
  a buffer for the file using that size, and then read the file's data into
  the buffer using the fread(3) function. This is where things go wrong: EVEN
  if we open the file in BINARY ("rb") mode, the fread() function will STILL
  perform newline processing, resulting it it returning LESS data than we
  requested: it has stripped off the CR characters.. This was confirmed to
  be the case with both the MinGW-w64 (gcc) AND Microsoft's own Visual Studio
  compilers. Since MinGW uses the actual runtime from Microsoft (relatively
  old versions of the msvcrt.dll), this is most likely the source of it.
  That said, reading text files in binary mode is not a good practice to
  begin with, so most likely this problem will be fixed by changing the input
  scanner to process all input files in ASCII (text) mode instead. DONE.

---

Tables for several other processors are ready, but I have to clean up the output
code first, to cleanly add writing in SRecord format.

Fred

[boeckmann]

Nice job 👍

Some of the changes mentioned are also fixed in my branch, others I choosed not to implement. But unlike you I do not bother with compatibility to other assemblers :-)

Did you already implement the additional addressing modes provided by later 6502 versions, like the 65C02? I'd like to support the WDC65C02, because I plan to build a system with it. And that system I would like to program with my own assembler.

[waltje]

Yes, that is in the new (updated) backend for the 6502 family. I did those changes many years ago (pff, 1989 or so?) for my then-current macro assembler.  I backported those changes into a new backend for Vasm (name of the new fork), and I hope I can also "import" my old macro code into it. Question - would you have a problem with me using the BSD-3 license for my fork? Fred

[boeckmann]

Question - would you have a problem with me using the BSD-3 license for my fork? Fred

Not at all! Put it under BSD-3.