Testing code

Hello!
I'm quite new in assembler and nes. I'm using CA65. I was wondering if there is a way to test a part of the code. I mean, outside the nes and the nes emulator. Some simple program where I could write a code in assembler and use something like the typical "System.out.println" just for see how the code branch (or maybe if I can not print text, just be able to see the value in a memory position, or whatever).
I don't know if I'm explaining myself properly, but I'm looking for a easy way to just test some lines in assembler.
Thanks!

If you don't need to interface with the PPU or other hardware accelerated features, there's a couple of online emulators you can test code snippets in listed early on this page:

http://www.6502.org/tools/emu/

Thank you! yes, the idea is something like that. Indeed I was trying the easy6502 one, that is similar to this one: http://www.6502asm.com/ before to post this, but I'm not sure why I can't compile this:



I keep getting this: Syntax error line 1: LDA #%00000001

This particular assembler doesn't seem to recognize % or b (usual signs for binary values). It might use some nonconventional sign or it might not support binary values at all. You can still use hexadecimals to the same effect of course.

If you know js, you can check the source here. (i don't).
https://github.com/skilldrick/6502js

Thanks for the link mate, but it doesn't recognize binary neither...

The main problem is that I want it mainly for understand binary comparison, hahaha (and obviously for other things in the near future)

On top of my head, maybe you don't need a full blown assembler and 6502 emulator for that? I know trying for yourself is of better value, but we can do an experiment halfway at least. Bitwise logic operations is pretty universal. here's an interactive logic gate simulator you can experiment with.

What an AND 6502 instruction does can semantically be divided into two steps.
-The first is the same as in that simulator, if you set up 8 AND gates (one for each bit) and 2x8 inputs (the two values to be compared).
-The second part is what it outputs as a result and to where. It will output to status flags S and Z, as well as the accumulator it just compared with. Subsequent BEQ and BNE will look for the Z flag.

If any two AND-compared bits are 1, the output is an 1. That also means the resulting output to the accumulator is a non-zero value. thus, the Z flag will be off/0.

BNE will branch on this condition
BEQ will not.

As you might know, "equal" and "zero" are synonyms here. Proof: if a - b = 0, it means a and b must be of equal value. Hence the names of these branch instructions and why they look at zero flag.

Functionally, AND can be used as a mask that only lets one or a few select bits through. You only want to look at a single bit in an 8-bit word and ignore all others? Then you can do it like this:



So in the former example, BNE will not branch, but BEQ will.
In the latter example, BNE will branch, but BEQ won't.

Side notes:
The difference between AND and CMP is that CMP won't save the result in the accumulator - it only compares as if it was carrying out a mathematical or logical operation, whereas AND actually does it. On the other hand, CMP also affects the carry flag. So you can also use BCC and BCS subsequently on CMP, which wouldn't work with AND. Bonus point: AND can reversely be used if you have something stored in carry you don't want to overwrite, to be used later on.


--
Sorry if this wasn't what you were looking for. Just going for the few resources i know which might help.

OR:

For whenever i can't note down a value in binary, i use win10's improved calc.exe in toggle switch input mode to quickly check binaries and their hexadecimal counterparts.

That way you can quickly do your experiments in easy6502 even without binary notation support.

Thanks mate!

I think that you solved some of my doubts, so thank you I think I will use the hexadecimal way for me to test it in easy6502, that sounds good enough for me right now, so thank for the idea.

The plan for me to test the code separately is for me to be able to play with the code, and learn making changes, but I think I can use the easy6502 in hex for me to learn all this.

Thanks!

Glad i was able to help you out.

A second approach to test code snippets quickly would be to do it in asm6 instead of ca65.
This would also let you write, read and evaluate CPU external hardware registers.

Asm6 lets you build a NES ROM with far less overhead. All you need is an NROM header (which you can copy off the nesdev wiki) and ideally a template warmup and initialization routine (which can also be found on the wiki).

Asm6 even lets you drag and drop a text file onto its icon to produce a ROM, provided the syntax is alright of course.

Then you can test stuff with about the same syntax as in ca65, including binary values, and check the result in any emulator, preferrably one with a debugger such as fceux or mesen.

An easy way to test if/what branch was taken is to set a colour emphasis bit under a label which a branch points to.

For example

MyLabel:
LDA #%10000000 ;tint the screen blue
STA $2001
LoopForever:
JMP LoopForever

That sounds so interesting, and I will keep it for the future. I will try not mess with more programs in this moment, but it sounds interesting for the future. Also I will need to understand properly how to debug with fceux, because now I just use it for run the rom, haha.

If you're windows, you can try the 6502 macro assembler: http://exifpro.com/utils.html

It does use a different format for binary (#@00001111), but is otherwise probably exactly what you want.

That's what I used when I was first learning 6502 assembly. I even used it to make my first few NES programs, since it can export binaries.

For actual testing you can use
https://github.com/martinpiper/BDD6502

this is behavior driven development, so you make tests and then run them as you would any modern language. It written in Java so you will need the JRE installed to use it. Looking at the examples and reading up on gerkin would be usefull. Sadly the latest release doesn't include my "export string from within code" updates(if you want it let me know and I will prod martin to do a new release), but you can make it run to a point and then do a hex dump. You could use CC65 in 'prg' mode, but I would recommend you use acme from the same author as it will output labels in the right format for BDD. I have a simple script that will convert tass ( which is a much better assembler ) if that would help you, let me know.

If you prefer "unit tests" you can use https://csdb.dk/release/?id=172719&show=summary#summary

Cool! I will take a look to all this in a few days, thank you so much guys!