NESASM - TASM

[jp48]

Hi all,

I need an assembler for 16-bit MSDOS, only one I found is TASM. Apparently some changes are needed to iNES-header (I've only used NESASM for programming NES), any tips for the header and possible other changes.

Here are examples of original NESASM code I've used (I work only with sound):

HEADER:

Code: Select all

	.inesprg 1
	.ineschr 1
	.inesmir 0
	.inesmap 0
	.org $8000
	.bank 0
	.bank 1
	.org $FFFA
	.dw 0
        .dw start
	.dw 0
	.bank 0
	.org $C000

VBLANK (timing):

Code: Select all

loop1
vwait
	lda $2002
	bpl vwait
	dex
	bne loop1
	rts

I compiled just header with NESASM, rest (usual NESASM) code, then combined the files (copy /b header.nes+dasdfd.nes file.nes), I hear that sound is switched on, then nothing. No errors in compiling.

Thanks for advance !


-jp

[Dwedit]

TASM is a nice assembler, but you will need to change quite a bit to make it work. For example, turn the header into a proper sequence of .db bytes instead of whatever there was before. Also add Colons : to the end of all labels.

TASM has label length limits, so watch out. I think the limit is 15 characters, not sure though. Remember to invoke Tasm in 6502 mode (-t65 command line option).

I think TASM 3.2 is a win32 console program, TASM 3.1 is the last DOS version.

By the way, you can run many Win32 console programs in DOS mode using the HXDOS extender.

[jp48]

Thanks, good advices, I need to translate the header first. I'm using TASM 3.1 in PocketPC, it works without problems (compiles as usually), just need to find the differences between NESASM and TASM.

Thanks !

-jp


ps. Seems that 3.1 use only -65 (without t) option.

TASM is a nice assembler, but you will need to change quite a bit to make it work. For example, turn the header into a proper sequence of .db bytes instead of whatever there was before.

TASM has label length limits, so watch out. I think the limit is 15 characters, not sure though. Remember to invoke Tasm in 6502 mode (-t65 command line option).

I think TASM 3.2 is a win32 console program, TASM 3.1 is the last DOS version.

By the way, you can run many Win32 console programs in DOS mode using the HXDOS extender.

[Memblers]

Another thing I often do, is keep the header as a seperate 16-byte file, then in my .bat file that builds it, it does a "copy /b header+rom rom.nes" type of operation. But that's largely because having the header built-in is a disadvantage for me. When I use my ROM emulator for testing, the header is of no use.

[jp48]

I tried this, but didn't worked. How did you compiled the header ? I compiled the header with nesasm, rest with TASM, added with "copy /b ...", but still it doesn't work.


Thanks !

Another thing I often do, is keep the header as a seperate 16-byte file, then in my .bat file that builds it, it does a "copy /b header+rom rom.nes" type of operation. But that's largely because having the header built-in is a disadvantage for me. When I use my ROM emulator for testing, the header is of no use.

[Dwedit]

You can just make a header with a hex editor.

[jp48]

Tried this too, made a 16-byte header of the working .nes-file. Compiling with

Code: Select all

tasm -65 -b file.asm file.nes

copy /b header+file.nes file1.nes

Still not working

You can just make a header with a hex editor.

[/code]

[Dwedit]

You need spaces, because + is a legal character in a filename.

[thefox]

Hi all,

I need an assembler for 16-bit MSDOS, only one I found is TASM.

There's also a 16-bit version of DASM out there. Google finds it.

[jp48]

Seems to work with and without spaces, the files are identical when checking with hex editor. Also, if I remember correctly + wasn't legal char in filenames in 16-bit DOS.

Anyway, thanks, all tips are appreciated !


-jp

You need spaces, because + is a legal character in a filename.

[jp48]

Thanks, found it, the code compiles without errors, but doesn't work with header added directly with "copy /b"-method.

Any hints to the iNES-header, so far:

Code: Select all

 processor 6502
 ORG $8000 

Not much yet. .

This would be much easier if I got any error messages but all compiles without problems, not getting any errors. Anyway, the problem must be in the header, code compiles with NESASM, TASM and DASM.


-jp

There's also a 16-bit version of DASM out there. Google finds it.

[Memblers]

How about your filesize, does it match up exactly with what the header says? You using CHR-ROM or CHR-RAM? If the emulator loads it without complaining about the size being wrong, the next thing to look at is the vectors, are they in the right place? Many times in FCEU if I didn't know WTF was going on, it helps to just go into the debugger, hit step so it pauses, then hit reset and step to see if it starts up properly.

We might have to see the complete source and build method to help you out.

edit: I think I see the problem maybe, your NESASM header (in your first post) is saying it's a 16kB ROM, but you are starting at $8000, then advancing to $FFFA for the vectors (this will result in a 32kB ROM in any normal assembler, dunno about nesasm..). You'll want to start at $C000 for 16kB (though technically you can put the vectors at $BFFA, no one usually does that).

[tokumaru]

Yeah, I think we need to see more code. I find it weird that in the code you listed as "HEADER" we can see your CPU vectors. Those vectors are not part of the header, and if by any chance you took that out of your program, that could mean you are generating a vectorless (!) ROM, which would obviously never work.

Also, it's nice that you have your NMI and IRQ vectors pointing to $0000. If you are not using those (and the fact that you are not using NMIs is not a good sign, because they are the best way to keep track of time), at least have them point to an RTI instruction somewhere in the ROM, to reduce the chances of your program crashing.

[jp48]

OK, good to know, and thanks all of information so far !

I compose experimental music using old consoles as sound sources, using simple vblank routine as timer is adequate, don't need more as the sound file or live settings is (heavily) modified. I use other languages to generate NESASM code, each NES-file is used once for one composition, then new program, another composition etc. I use NES, but others as well: SMS, Genesis, Atari 2600, 5200, GB, MSX and so on, different any languages I find those machines.

NES-files consist three components (the header is originally from some tutorial, tried to find without luck). It seems I posted the older version of the header, here's what I've used with NESASM currently:

Code: Select all

	.inesprg 1
	.ineschr 0
	.inesmir 1
	.inesmap 0
	.bank 1
	.org $fffa
	.dw 0
	.dw start
	.dw 0
	.bank 0
	.org $8000

Second component is timing:

Code: Select all

loop1:
vwait:
	lda $2002
	bpl vwait
	dex
	bne loop1
	rts

Then the last component, it consist just of direct writing to sound registers, depending what I'm working, but this is a short sample which contain what is needed (I hope):

Code: Select all

start:
	lda #15
	sta $4015    ; all four channels
start1:
	lda #70
	sta $4000
	lda #84
	sta $4001
	lda #167
	sta $4002
	lda #205
	sta $4003

        ....         ; more writing to sound registers

	ldx #16    
	jsr loop1 ;calling vblank

        ....          ; same continues until a loop is formed

        jmp start1 ; endless loop

That's all, header, enabling necessary sound channels, writing directly to sound registers, looped vblank for timing and back to start. Simple, clumsy, direct, but exactly what I need.

Thanks !


-jp

[tepples]

Yeah, I think we need to see more code. I find it weird that in the code you listed as "HEADER" we can see your CPU vectors. Those vectors are not part of the header

Someone who has previously dabbled in Super NES, Sega Genesis, or Game Boy might have been confused this way. All these platforms have a block of vectors right next to an internal header; see, for example, the SNES header. Even some later NES games have an embryonic form of the SNES-style header (what's that ZELDA at the end of the PRG of SMB2 (U)?). But iNES format is different in that the 16-byte board descriptor at the start of the ROM file isn't mapped anywhere that the CPU can see; it's solely an invention of pirates and independent archivists.