Page 1 of 1

Better editor than Crimson Editor?

Posted: Tue Mar 10, 2020 10:04 pm
by NeverCameBack
Does anyone use Crimson, and is there an error log? I searched it, but came up short.

If not, is there another editor that will tell you why your NES game is not compiling? Right now I'm forced to write small bits of code at a time, checking the time stamp of my .NES file each time. If it doesn't compile, I have to comment out the newest lines of code until I find the reason.

For example, I made my character jump up, but in writing the code for him to come back down... My code just will not compile with this line un-commented out.. I can't figure out why.

It is the first time I'm storing the accumulator value into the variable "landframecnt". I tried initializing the value of the variable to zero first, and it didn't help. I also tried using the x register instead of A to increment "landframecnt". That didn't work either. I'm feeling like Crimson does not want my character to land after the jump.
Capture.PNG
Capture.PNG (11.1 KiB) Viewed 3338 times
A screenshot of my program so far:
Capture2.PNG

Re: Better editor than Crimson Editor?

Posted: Wed Mar 11, 2020 5:05 am
by Quietust
Without being able to see more of the surrounding code, I can only assume that you're running into something like a branch distance overflow - relative conditional jump instructions (BEQ, BNE, BPL, BMI, BCC, BCS, BVC, BVS) can only reach about 127 bytes in either direction, so if you've got logic that's trying to branch past your jumping code, it's possible that extra STA pushed it over the limit. If that's what it is, you can replace the conditional instruction with an opposite-condition branch which skips a JMP instruction (e.g. "BEQ skip_loop; ... ... ... ; skip_loop:" to "BNE skip1; JMP skip_loop; skip1: ... ... ...; skip_loop:").

On a side note, directly manipulating your local copy of Sprite RAM probably isn't the most efficient way of doing things - it'll work for an extremely simple demo, but once you start having to manage multiple sprites it's going to get out of hand, especially when you need to worry about reordering them to get around 8-sprite overflow (to make them flicker instead of having the last N sprites simply never appear).

Re: Better editor than Crimson Editor?

Posted: Wed Mar 11, 2020 8:00 am
by dougeff
6502 asm notes.

adc usually needs clc before it

clc
adc #1

sbc usually needs sec before it

sec
sbc #1

you can use the "inc" command directly on an address without using a register.

inc $200

Re: Better editor than Crimson Editor?

Posted: Wed Mar 11, 2020 11:06 am
by NeverCameBack
Thanks, I will try to restructure my loops around to see if that helps.
I don't have too many JSRs, or anything really nested though.

My goal was:
- The A button is pressed
- A variable is set to 1
- When this variable is set to 1, a routine runs where the sprite starts to get moved up - one frame per NMI.
- When the apex is reached, a routine runs where the sprite gets moved back down - one frame per NMI.
- When the landing is done, the variable is set back to 0 (ready to jump again).

Do you know of any links on a better way to move sprites around? If you know of a sample plat-former program, maybe I could try to decipher it and pick up some new techniques... Thanks for the response.

Re: Better editor than Crimson Editor?

Posted: Wed Mar 11, 2020 11:24 am
by NeverCameBack
Thanks NESDoug, I remember checking your site out and playing your Ninja game a few years ago before I started really trying to get into making an NES game.

Is it good practice to always use SEC or CLC before the add and subtract with carry instructions?
Just in case something earlier in the program set the carry flag?
I seem to remember the Udemy teacher for an atari game saying it. That is how I got started with this.

Re: Better editor than Crimson Editor?

Posted: Wed Mar 11, 2020 12:14 pm
by dougeff
The carry flag is for calculations over 8 bit.

But, you should make a habit of clearing carry before all adds and setting the carry before all subtractions. If you choose to skip it, because carry flag is known, you should document (comment) the reason.

In those examples, the carry flag status looks unknown to me, so definitely put clc and sec in.

Example of 16 bit, adding #$1234 to speed (16 bit)

LDA speed
clc
adc #$34
sta speed
lda speed+1
adc #$12
sta speed+1

note, no clc before the second adc. The first adc is setting or clearing carry, depending if it's result is >255.

Re: Better editor than Crimson Editor?

Posted: Wed Mar 11, 2020 2:31 pm
by Memblers
NeverCameBack wrote:
Tue Mar 10, 2020 10:04 pm
If not, is there another editor that will tell you why your NES game is not compiling? Right now I'm forced to write small bits of code at a time, checking the time stamp of my .NES file each time. If it doesn't compile, I have to comment out the newest lines of code until I find the reason.
That sounds like a pain. I haven't used Crimson Editor, but often a programming text editor will let you have a separate frame at the bottom of the screen that shows console output when you run the build command, and that's where you would see the error info. And I would recommend having the build process begin by deleting the old .NES file. Even when I can see the error message, I've been bit by that before, accidentally running the old version and wondering why nothing changed.

Re: Better editor than Crimson Editor?

Posted: Fri Mar 13, 2020 4:37 am
by Pokun
NeverCameBack wrote:
Wed Mar 11, 2020 11:24 am
Is it good practice to always use SEC or CLC before the add and subtract with carry instructions?
Not just good practice, it's a requirement in 8-bit math (unless like Dougeff said, the carry flag's state is known) and in the first operation of 16-bit math (or higher).
ADC and SBC means add with carry and subtract with carry. Some other processors (like the Z80) has ADD and SUB instructions as well as ADC and SBC. ADD and SUB adds and subtracts without considering the state of the carry flag. The 6502 doesn't have those instructions and needs to use CLC/SEC together with ADC/SBC to simulate ADD/SUB.

In an addition operation, a set carry flag means there was an arithmetic carry in the previous addition operation (that's why it's named "the carry flag"), and therefore it must always be clear in the first operation (which is the only operation in 8-bit math). The reason why SEC is used with SBC is because a cleared carry flag indicates an arithmetic borrow in subtraction operations on the 6502 (this is not the case on Z80 where a set carry flag means an arithmetic borrow in subtractions).

Re: Better editor than Crimson Editor?

Posted: Tue Mar 17, 2020 10:44 pm
by NeverCameBack
Thank for the tips.

For anyone with a similar question, here is the solution:

Just noticed when I compile in Crimson editor, a black window for NESASM3 shows up for a fraction of a second. I slow motion video taped it from my phone, and it is in fact a list all the errors in compiling.

Then I found another post on this sub, I learned that I could create a .bat file with the contents:

nesasm3 MyGame27FEB20.asm
pause

Then save this as a .bat file into a folder with NESASM3.exe, and your project files (including the .asm file), and when you double click it, it will give you the error log.

I guess just the phrase "pause" at the end of this causes that black window to stay put.

Furthermore, I just figured out that there is a check box here, so the above is no longer necessary:
Crimson_Capture_Output.PNG