freem / asm6f

A fork of loopy's ASM6, a 6502 assembler.

too many projects, not enough time

Neo-Geo Stuff

The primary Neo-Geo repository of interest is the freemlib, as incomplete as it is.

Tools

• NeoSpriteConv - Convert tile data from 4BPP SMS/GG/WSC format to Neo-Geo sprite format.
• NGPalTool - Neo-Geo Palette Tool
• romwak - port of Jeff Kurtz's romwak to ANSI C (no longer being updated)
• adpcma - command-line ADPCM-A sample encoder (no longer being updated, use superctr's adpcm instead)

---

NES/Famicom Stuff

The freemco NES corelib is the main repository for my NESdev escapades.

Tools

• asm6f - a fork of loopy's asm6 with enhancements

Demos, etc.

• VT03 Color Test - Palette tester for VT03's 4bpp palette mode.
• livenes - Quick and dirty fork of livenes to add support for VT02 sound channels
• nesmon - perpetually unfinished tool, meant to be similar to Chris Covell's pcemon

---

Wrestling Game Stuff

Virtual Pro-Wrestling series

See also: the AKI Club organization.

• aki_lzss - Tool for compressing/decompressing LZSS files found in AKI Corporation's N64 wrestling games

Fire Pro Wrestling series

• FPRLogoViewer
• VPF0Viewer

---

Other Stuff

Anything that doesn't fit in the above sections goes here.

• Eldpack Continued - Continuation of Eld's Eldpack 16px Minecraft texture pack. A group effort between many collaborators over the years.
• random_crap - "you need more description than the repository name??"
• FCEUX Lua Scripts - "some FCEUX Lua scripts I've written"

StepMania

These are only provided as archives, and will not be updated.

• ultralight - StepMania 5.0 theme
• SMOnline v1 - Clone of the original repository

asm6f's Issues

support of the various directives from asm6n

asm6n has support for a few directives that mimic ones found in NESASM:

• inesprg: Number of 16K PRG-ROM banks
• ineschr: Number of 8K CHR-ROM banks (or 0 for CHR-RAM)
• inesmir: (default) Nametable Mirroring
• inesmap: iNES mapper number (0-255)

Furthermore, an inesins directive exists to write the header output.

While I personally wouldn't use the directives, it might make the assembler easier to use for people who don't want to figure out a 16 byte sequence (or use various alternatives for header generation/creation). That, as well as making NESASM code a little easier to port. (Well, without the following paragraph, anyways.)

As it stands, I would personally only find them useful under the following conditions:

1. Support for NES 2.0 header values. This would require a number of new directives to be added.
2. As koitsu mentioned on the NESDev forum, there should be some sensible defaults set (e.g. 16K or 32K PRG-ROM, 8K CHR-ROM, NROM/Mapper 0, flip a coin for mirroring or ask someone what the default should be) that can be substituted in the absence of those directives. This would allow for the removal of inesins.

Implementation notes:

• A variable, named generate_ines_header (or similar), set to 0 by default. Using any of the ines header directives would change this value to 1 (which would generate the header at the output pass).
• A few variables corresponding to possible values for each directive, populated with sensible defaults (either 16K or 32K NROM/Mapper 0, no SRAM/WRAM, etc.).

Console text output directive

Recently, tokumaru made a post about a 6502 assembler he's developing, which would be similar to asm6 but with some slight changes. One such change is "a directive to print text without aborting assembly". This doesn't sound like it'd be too complicated to add to asm6f.

Absolute addressing for zero page variables

This has been discussed before, but it's being brought up again because @morskoyzmey has proposed a solution...

• nesdev forums thread
• relevant diff

I'm not sure if this is the best way of doing it, but I don't have any alternate solutions at the moment.

Mesen labels export is flawed

In the function export_mesenlabels(), it is assumed that all labels of type LABEL are program code labels, and all labels of type VALUE or EQUATE are either RAM variables or registers.

This assumption is not very good, as all .dsb definitions, even when wrapped inside an .enum or .ignorenl, is treated as program code labels and given the P: tag in the resulting .mlb file.

This can be worked around by never using the .dsb directive and always manually deciding upon RAM locations with = or EQU assignments, but this is very unwieldy and unfriendly. It means you have to manually assign addresses to every variable instead of letting the assembler do the heavy lifting.

In the VALUE or EQUATE section of the function, the type of RAM (or register) assigned is based on some simple heuristics based on address ranges. Maybe the same system could be used in the program section? From what I understand, if an label is pointed to anywhere between $0000-$07FF, you can be certain it's the NES internal RAM, and so on.

Lastly, it would be great if the .ignorenl directive also worked for export_mesenlabels just like it does for FEUX, as you can often have hundreds of constants with various integer values, which will currently be forcefully exported to the .mlb file and cause all manner of nonsensical labels at random places.

[REQUEST] Directives for Non-ASCII Text Formatting via tables (character codes)

This is relating to how strings written for NES, C64, and other game systems not exactly supporting the ASCII Standard for Text.

The character mapping feature is to be made from how Thingy and ASAR (XKAS 6) uses them, using the table format standard

These are the directives:

.RTLTABLE "Include.File" - Include a Table for Non-Standard Text, Formatted Right To Left.
.LTRTABLE "Include.File" - Include a Table for Non-Standard Text, Formatted Left To Right.
.TEXT "String" - Adds Non-Standard Text, uses ASCII by Default.
.CLRTABLE - Clears and Resets the table back to the Default ASCII standard

Support is REALLY appreciated!

Commit 1e0e399 inadverently reverted PR #35 (Remove use of vfprintf() and friends)

Original PR: #35 (Remove use of vfprintf() and friends)

Merged in commit 2cf2d3f

However, commit 1e0e399 appears to have reverted these changes.

Can these be put back? If you need another PR to restore them (to make your life easier), let me know.

.cdl file location

The .cdl file is currently hardcoded to be created in the same directory as the input file.

It should be configurable, just like the output file, list file, etc.

Or at the very least, the default path should be the same directory as the output file rather than the input file, as that's where emulators look for it.

Character mapping / table support

Many games on the NES do not have graphics that align with ASCII values. As such, text can be difficult to add/modify.

I propose something like this (name is a suggestion only)

REMAPTABLE font1
  'A' = #$00 
  'B' = #$01
  ...
  ' ' = #$99
  '\'' = #$9A
ENDREMAP

; ...

.db font1!'This is some string', $20, font1!'to be remapped.'
.db font1!'The raw $20 would not be changed.'

Could throw an error or warning if a character that is not in the table is used.

IFNDEF directive is maybe broken

I tried to do "header guards" by using the IFNDEF directive, but the file ends up not being included at all

Here's what I've done on the inc file:

.ifndef HEADER_NAME
  HEADER_NAME = 0
  ; code here
.endif

Then I have included the inc file in my main file using .include "incfile.inc" and it doesn't get included.

.FUNCTION

I can't do dev right now so this issue is more a self-reminder than anything. (This, if implemented, could actually be merged into the original asm6).

ca65 lets defines double as functions like:

.define valplustwo(val) (val+2)

This functionality can be replicated in asm6 with:

.function valplustwo val
.return val+2
.endf

Used like lda #valplustwo(12).
This could be good for making fancy tables and stuff. Thoughts?

[REQUEST] Add support for INES 2.0 header support

Hey there, Is there any way you can add INES 2.0 header support to ASM6F? This program will get better to use if so.

INCBIN/BIN bugfix, code cleanup

Just wanted to note this here: you may find some, most, or even all of my commits here useful: https://github.com/koitsu/asm6f/commits/master

An executive summary would be the following:

• Bugfix: INCBIN/BIN fix for unquoted filenames using size/offset args
• Other: Document that INCBIN/BIN and INCLUDE/INCSRC support quoted filenames
• Other: Document how to build asm6f and its pre-requisites (ex. GNU make)
• Other: Revamped Makefile for proper dependencies, effectively add clang support, hopefully better Windows support (untested), enforcing more extreme warnings when build=debug (justifies most of the cleanup commits), and treating warnings as errors
• Code safety: use snprintf() instead of sprintf()
• Code safety: cease use of vfprintf() and friends (valgrind et al does not like it)
• Cleanup: removing trailing tabs/spaces, as well as blank lines with such
• Cleanup: add many missing function prototypes
• Cleanup: use var->member not (*var).member, constify things, make my_malloc() comply with real-world malloc()
• Cleanup: don't cast findlabel()'s return value to ptrdiff_t
• Enhancement: make INCBIN/BIN show an error if the calculated fread() size doesn't match what was read off disk (this usually means disk I/O error when reading). This needs further testing, but pretty sure I tested it well...

At bare minimum, the INCBIN/BIN fix from 40706e3 should be brought in. I would strongly suggest parts of the Makefile as well, particularly proper use of make variables for dependencies.

The warning-related stuff took me several hours to actually clean up/work out. When I started, I actually had to use -ferror-limit=0 due to the code having almost 200 warnings once more extreme warning flags were added.

Anyway, I'd love for these to be brought in, simply because we have enough forks already... :-)

All of this needs very thorough testing, i.e. on a big/hefty project. There are some things I changed (example) that make me a little bit wary.

Macros for use in expressions

In cases of stupid addressing like the PPU, addresses are usually written as .db $20, $00, as opposed to the usual way, due to having to write the high byte to PPUADDR first.

I wanted to do something like this:

MACRO vram addr
      .byte >addr, <addr
ENDM

SampleLabel:
;      .BYTE $20, $00, $60, $FD
      .BYTE vram($2000),  $60, $FD

However, this gives me a warning that macros aren't allowed to be used as expressions.

I got around it right now by removing the .byte:

SampleLabel:
      vram($2000), $60, $FD

...but that will only work if it's the first entry on a 'line', and feels pretty hokey.

This is probably a lot tougher than it sounds, but I at least have a workaround for it right now, so it isn't a huuuuuge issue.

Allow unix absolute file path

It's not possible to pass absolute file names (starting with '/') as arguments.
I propose this change to fix this issue:

--- asm6f.c	(revision 762c948875e7b8c478b917f88f82c8f77b2308f8)
+++ asm6f.c	(revision )
@@ -1814,7 +1814,7 @@
 	initcomments();
 	notoption=0;
 	for(i=1;i<argc;i++) {
-		if(*argv[i]=='-' || *argv[i]=='/') {
+		if(*argv[i]=='-' || (*argv[i]=='/' && strlen(argv[i]) == 2)) {
 			switch(argv[i][1]) {
 				case 'h':
 				case '?':

make asm6f one program

The build process and distribution of the program would probably work better if asm6f was one binary with instructions UNSTABLE and HUNSTABLE to enable the corresponding opcodes. The opcode reading function in the program would just search through an array of unstable (or highly so) instructions and if it's a match but the appropriate directive hasn't been called, throw an error.

I just don't think it's necessary to have three different binaries for an assembler like this.

.nl generation omits last constant symbol

When telling the assembler to output an .nl file, the last constant will not appear in the file. Labels seem to work alright, though.

Tested with commit hash 3b68946

Example source (test.asm):

.enum $0000
	item  .db 0
.ende

.org $8000
	lda item
	sta $00
here:
	jmp here

Command line used: asm6f -n test.asm test.nes

Expected outcome: test.nes.ram.nl will have an entry for the "item" variable (specifically: $0000#item#)

Actual outcome: test.nes.ram.nl is empty.

How to confirm: Add another variable after item, such as item2. The line for item will now appear in test.nes.ram.nl

Regression notes: I can't recall if this has always been an issue; I've always had more than one RAM variable defined and never thought to check closely.

CDL file output, more precise label file format

Hey, (and sorry in advance for the wall of text below!)

I've been wanting to integrate asm6 with Mesen and was faced with a number of issues.
Parsing the .lst files is possible but complex, and FCEUX's .nl label format can be imprecise for projects that use bank switching.

Mesen's current internal representation of labels is precise - labels are based on the memory type (e.g 2kb internal ram, work ram, save ram, prg rom) and the address is based on the offset from the start of that memory type. So a label might be type "PRG ROM" at offset $38000, for example

Essentially, I implemented a new switch option in asm6 (based on this fork) to dump the labels into a format that matches Mesen's. The format I came up with (.mlb) is similar to .nl files and is simple to parse. e.g:

R:700:MyLabel
P:38A00:AnotherLabel:And a multi-line\ncomment\nabove it

Each line is formatted as "Type:Address:Label:Comment", with the "comment" portion being optional. New lines in comments are escaped as "\n" in text form.
Types: 'R' = internal ram, 'P' = prg rom, 'S' = save ram, 'W' = work ram, 'G' = "registers" (which is essentially a way of giving names to addresses in the CPU's memory space ($0000-$FFFF))

I also added a switch to create a basic CDL file (which can be used in both Mesen & FCEUX) since they are used by Mesen's disassembler to remember which portions of the PRG ROM is code and can be disassembled.

Testing with this project and loading the mlb & cdl files into Mesen's debugger, I get a pretty good result:

Basically, I'm wondering if you'd be interested in merging my changes?
I tried to use the same code/naming style as the rest of the code. My C is quite rusty (haven't actually used plain old C in ages), but I think it turned out ok. I might still have to make some modifications (I haven't even completely finished coding the import/export to .mlb feature I want to add to Mesen yet), but I think this format makes sense(?).

There's still room for improvement, though. For one, being able to distinguish between constants used like "LDA #Constant" and actual memory locations like STA MyVariable would be great - but it doesn't look like there's any simple way to accomplish this?

EDIT: I added the ability to import/export labels in the same format to Mesen and fixed a couple of issues I noticed along the way.

I updated the file format/fork to move the comment to be on the same line as the label (and available for any type of label). I also tweaked the CDL file output so that anything generated via the "filler" function is no longer marked as data.

No binaries available

Not everyone has the time or patience to compile it themselves. A binary release (at least for Windows) would be appreciated.

Recent release won't run: missing msys-2.0.dll

The current binary release from March 10th 2018 (commit 762c948) does not run on Windows citing at least one missing DLL: msys-2.0.dll. Others experience the same problem, so it's not limited to just me: http://forums.nesdev.com/viewtopic.php?f=2&t=17945

Older 32-bit and 64-bit releases (June 24th 2015, commit 105ee3c) both run without a hitch.

Lua-compatible symbol files

reset = 0xC000 zeropage = 0x01
For easy live variable printing in FCEUX with Lua scripts (memory.readbyte(zeropage)). Should be easy.

Tag for original source

Hi,

Could you please (for reference) place a tag for the import of the original source ?

Thanks in advance :-)

Symbol to fetch the output address of a label

NESASM has a built-in function called BANK() which returns an integer indicating what bank a certain label belongs to. This can be quite the useful piece of functionality as you can create a primitive type of pointer, or simply make your code truly relocatable, or allow for data sets that expand over more than one bank and automatically adapts.

It's perhaps the only piece of functionality I truly miss when moving from NESASM to asm6f, as I now have to manually hard-code the bank integers and hope I remember to change it by hand later if need be.

asm6f doesn't have the concept of banks so the same functionality is impossible at first glance, but, if there was a way to fetch out the real address of a label (the actual offset into the output file as opposed to the virtual address often changed by .base directives) then the programmer could easily calculate what bank a label belongs to.

My suggestion is to add some symbol you can put before a label to indicate that you want it's output address, something like ?MyLabel.

Macro parameters not handling any expressions

I have been trying to simplify things by moving as many function calls inside macros as I can and move away from manually loading function inputs into registers before calling the function, etc. since these things don't cost any CPU time to do from a macro. It seems though that I'm getting incorrect results whenever the macro parameters are not just bare symbols. The example is from a list file where I am demonstrating the issue:

09F13                           		@thing = sfx_denied_thump|param_sfx_pulse
09F13 A2 81                     	ldx #@thing
09F15                           		sfx @thing
09F15                                      ; Start sfx ID 0-31 with attribute flags 2,N,P
09F15 A2 83                     	ldx #sfx_confirm|param_sfx_pulse
09F17 20 3B 9A                  	jsr InitSfx

My macro sfx is supposed to load the X register with the immediate value and then call the function. Other than the sfx ID I can also specify which sound channels I want to use, so the channel flag constants need to be ORd with the sound ID. This produces incorrect results, and it does not matter if I put an extra layer by providing my input in a local symbol either (the local symbol takes on the correct value of 0x81). I initially tried sfx sfx_denied_thump|param_sfx_pulse but that does the same thing, resulting in 0x83 getting loaded into the X register. Even just putting sfx sfx_denied_thump without expressions resolves to ldx #sfx_confirm|param_sfx_pulse even though there was no OR with anything.

For clarity here are the definitions of the macro and the sound IDs:

	                            .macro sfx input
	                            ; Start sfx ID 0-31 with attribute flags 2,N,P
	                            	ldx #input
	                            	jsr InitSfx
	                            .endm
	                            	param_sfx_pulse = %10000000
	                            	param_sfx_noise = %01000000
	                            	param_sfx_prio	= %00100000 

092DB                           .enum 0
00000                           	; sfx IDs
00000                           	sfx_text0			.dsb 1
00001                           	sfx_denied_thump	.dsb 1
00002                           	sfx_mvsel			.dsb 1
00003                           	sfx_confirm			.dsb 1
00004                           	sfx_numberofsounds	.dsb 1
00005                           
00005                           		.if sfx_numberofsounds >= 32
00005                           			.error More sound effects than supported.
00005                           		.endif	
00005                           .ende

So I don't know how to proceed with using macros for anything other than very simple things. Any help is appreciated!