vram glitches

[infidelity]

Ahh the apu, I knew I missed a step. That, and adding an additional CLI at the end of my reset vector, are now making the irq split work perfectly, I have freedom to place the split wherever. So thank you for that!

And I'll never stop coding in hex haha! It's never failed me, if I need to remind myself of a specific register, I jot it down in my notes, same deal as writing a label for it by writing the progam, it's the same thing using hex, I find it much faster, and with the code data logger in fceux, you can see what's running and what's not.

[tokumaru]

And I'll never stop coding in hex haha! It's never failed me

I'm not questioning your ability to immediately recognize instructions and addressing modes from opcodes, I honestly believe that you can write simple programs straight in hex in an efficient way, but I think you may be underestimating the complexity of a full-blown game, with things like state management, object management, scrolling systems, sprite animations, and so on.

if I need to remind myself of a specific register, I jot it down in my notes, same deal as writing a label for it by writing the progam

It's not the same thing. Sure you can write down "$A7 is the address of the pseudo-random number", and look those notes up whenever you need to use the pseudo-random number, but if you ever need to move that variable to some other address, say, because you needed to enlarge an array that came right before it, you have to change every single instruction that ever touched that address. Can you remember them all? You need random numbers for a bunch of things, so chances are that variable is used all around the game. Even if you use logs or breakpoints, you're bound to miss some spot. And you probably have other variables after the pseudo-random number that will need moving as well, so you're looking at a ton of error-prone work here.

Same thing with addresses. As projects develop, you need to adjust subroutines, change the logic, and so on. Will you remember to change every JMP, every JSR, every branch, every look-up table, each time you need move the code a bit? Even if you do remember, which is extremely unlikely, changing everything each time something moves will be a monumental amount of work.

Unless you're making a really simple game, meaning you have lots of free RAM to make adjustments to variables/arrays later on, and lots of free ROM so you have a decent amount wriggle room around every subroutine, I seriously doubt anyone could finish an actual game like this.

with the code data logger in fceux, you can see what's running and what's not.

You can do that with assembled programs too.

[tepples]

And I'll never stop coding in hex haha! It's never failed me

I'm reminded of Mel the Real Programmer.

[alphamule]

I'll admit that the only reason the hex method worked so well for ShaneM, was that the code was being patched, not created with no existing infrastructure. It wastes a lot of time if you try to make a program like this and then it's not easily debuggable. :/

[tokumaru]

I know I'm repeating myself, but I strongly believe that the one absolute deal breaker for handwritten hex is code/data relocation. Programs are full of references to memory addresses, and when you're writing a program from the ground up, routines change size, arrays change size, variables are moved to other addresses, and so on. Every time something like this happens, several references break, and you have to go through the entire freaking program fixing them, which is a pain in the ass, takes a lot of time, and it's very likely you will miss at least a couple of spots each time, and the resulting bugs might not be immediately apparent, making them much harder to track and fix later on.

It's OK if you don't like macros, conditional assembly, expressions, or other amenities that assemblers normally provide, but labels are absolutely essential if a programmer expects to remain sane during the development of a complex NES game. Labels are essential to keep all the references consistent, even when things move around, and I can't believe anyone would choose not to have this kind of safety, and deliberately waste time that could be spent on actual development doing the ingrate task of fixing references.

Seriously. Say you have a routine at the beginning of the ROM, at address $807F. Somewhere in this routine there's an addition, and later into development you realize that you forgot to put a CLC before the addition. But this is late into development, and you may already have routines and data all the way up to $FB06. This 1 byte shift will change the location of over 30KB of code and data, and you'll have to manually revise every singe reference that was made to this space. Every single JMP and JSR instruction will have to be adjusted, every single access to data tables. Does that sound sensible at all? Of course not, that's absolutely insane! Only a masochist would choose that route.

[Quietust]

Some people like to deliberately do things inefficiently. If they want to waste their time being unproductive, that's their choice.

[dougeff]

Every time something like this happens, several references break, and you have to go through the entire freaking program fixing them,

I 100% agree with you that assembly is better in 1000 ways. But, all of my first test programs were in hex, and when you do that, you PAD each subroutine with tons of zeros, just in case you need to expand. Have you ever programmed in Apple Basic? You number things by 10s, and if you need to shove some lines in the middle, you can add 9 lines without changing anything else.

But, of course, calculating branch addresses by hand is insane and bug prone.

[koitsu]

Remind me to show tokumaru old Apple II and C64 magazines which published machine language code for useful/fun programs or games. ;-)

[tokumaru]

But, all of my first test programs were in hex

Not such a big deal for small test programs or sections of hacked code, definitely a problem for big complex games.

when you do that, you PAD each subroutine with tons of zeros, just in case you need to expand.

But then you make inefficient use of the space. By the end you might need space for a table or something and you might even have it, but it's scattered all around the ROM and you simply can't use it to hold the table linearly. Either way you're gonna lose on efficiency, be it because of holes in the ROM or by wasting the monumental amount of time adjusting references.

Have you ever programmed in Apple Basic? You number things by 10s, and if you need to shove some lines in the middle, you can add 9 lines without changing anything else.

Yeah, I know how it works, and Basic sucks.

But, of course, calculating branch addresses by hand is insane and bug prone.

Calculating then in the first place is already bad enough, but remembering to adjust them all every time a block of code moves is even worse.

Remind me to show tokumaru old Apple II and C64 magazines which published machine language code for useful/fun programs or games.

At least those were already finished by someone else, so you didn't have to worry about managing all the references... Unless you wanted to modify the programs, of course.

[dustmop]

Curious how well this technique works when doing even mildly complicated bank switches.

[koitsu]

Remind me to show tokumaru old Apple II and C64 magazines which published machine language code for useful/fun programs or games. ;-)

At least those were already finished by someone else, so you didn't have to worry about managing all the references... Unless you wanted to modify the programs, of course.

My point is that many of these are several hundreds of bytes (characters) long -- the odds of making a typo/messing them up is high, and fixing that one typo requires you re-type the entire thing (or at least from where you made the mistake)... that's just how we did things. When I started doing 6502 machine language (not assembly per se), after a few weeks I asked my teacher if there was an easier way than entering raw hex data into the Apple II Monitor, given typos being prevalent and he laughed and just handed me his Merlin 8 (assembler) book.

But I fully agree with what Q said earlier: different strokes for different folks.