I just checked out the new sound features and it's really cool!
Anyway, i've got lots of other feature requests, too (sorry!): -Skipping an instruction. Move the PC to the next instruction (useful for jr $ breakpoints) -Related to the previous, a debugger option to treat jr $ as a breakpoint (ie bring up the debugger when a jr $ instruction is executed) -Define a section in memory (width in bytes/height) to preview the contents as if it were the LCD. So if i'm using the gbuf as a buffer, i can type in the address: $9340, the width: 12, and the height: 64 and see a preview of the gbuf. -A keyboard shortcut to change between full speed and normal calculator speed (more speed options wouldn't be bad, either, in particular slow-motion ) -A "set PC to highlighted line" option (though you can just adjust the PC manually, so it's not super important) -It'd also be nice to see the HEX code beside the instructions (and optionally be able to change them, like the memory editor beneath it) -Maybe the debugger could pop up when your code jumps out of the executable code range? -Conditional breakpoints: stop execution only when a certain flag is set/reset or a register(/register pair) = a certain value.
There are already a ton of features that i'd never thought of before but which i use everyday now, like the execute until ret feature and the run 'til next line feature. Also, the read/write breakpoints are really handy. Thanks a bunch to you and contra!
(EDIT: And these are just ideas, please don't think they're demands or anything like that!)
Cool! Is there a way to turn sound on, yet? I don't see anything in the Preferences menu.
EDIT: And i just installed from the SVN, i like the new debug features (like being able to scroll through the stack entries and the keyboard shortcut to jump to a new address), but a "skip instruction" command would still be really useful
start: ldir keyMask,4 ;not sure what this does...? .db 03,03,01,03 ;enable key0/1,sprites 0/1,turn on LCD update, and ldir sAddress,10 ;load the two sprites .dw 256+light_ball \ .db 03,03,02 ;x,y,sprite type .dw 256+dark_ball \ .db $55,$35,02 ;x,y,sprite type loop: add (sX0),$01 cp (key1),kClear ;$BF jrf z,quit jrb loop quit: ld (sMask),$80
Btw, i think you accidentally put in an extra sMethod before sUpdate, so some of the equates at the end are one byte off. Here's an include file i've started but haven't tested/finished yet:
If the source gets released, it will most certainly be possible Perhaps there could be two versions, a lightweight hex-input version and a slightly larger note-based version?
Xeda, i would love to play around with this if you ever get around to releasing something! I like the idea of trying to make games fit in small places and working with memory directly sounds interesting. Is the code then stored in your hex format and parsed?
It could be that the first character needs to be a capital letter (or θ). At least the program menu might be that way, i'm not sure if it's the same for the memory menu... That's how a lot of fake RAM clearers used to work, changing the first letter of every program in the VAT so that going to the program menu would bring up nothing.
Iambian might use TASM, but i think they also use spasm. The E:SoR source compiles with spasm, at least. But i guess it doesn't really matter, what is more important is getting started writing cool stuff
I'm teaching again, which has slowed down my progress with the Russian language pack. (I know that at least two people want it, and I want it to be good rather than just "thrown together")
If i'm not included in those two people, then three
How long ago was this added? It's possible it's always been there but we haven't noticed it 'til now. Really it's just yet another sign that TI doesn't really care about us, which i suppose isn't any sort of surprise. Like any (successful) company the $$$ comes first. Even if they did try to enforce it, though, trying to wipe out their (free) competition to force users to use their (non-free) "simulators" (i don't know if they even have debugging support...? Certainly nothing comparable to community emulators) would just be laughable. I can't see it having any effect apart from increasing the number of places you can find TI ROMs online.
Maybe a decade ago it seemed like half the community ended up working for TI at some point or another, now TI seems to be trying to push itself as far away as it can from the community
To me, Brass seemed much more complicated. Spasm is super fast, has powerful macro support, and can compile about anything easily (except maybe nostub TI-83 programs). Brass has lots of features and seems to be good for organizing your code. Use whichever one you like, i chose Spasm because it's faster and more lightweight, plus your code can be compiled on Linux/Windows/Mac. If you use certain features of Brass you might be limited to Windows, unless you want to reformat the file to be "spasm-compatible". Actually, my claim that Spasm is faster is based off of when i used Brass several years ago, so that might not be correct anymore. I don't know if Brass has seen much development since then but it's still a very powerful assembler (i think it can even rle compress your data for you). I just know that Spasm can compile a 40kb (final on-calc size) project importing lots of .bmps in the blink of an eye, which you'd realize how amazing that is if you'd ever used TASM before
And i don't think anyone still uses TASM anymore, it's a pain just to get it to run and the other alternatives (namely, Brass and Spasm) are much more convenient and feature-rich.
As to which one to use? You pick, it'll probably be the first one you get working. DJ_O says most people use Brass nowadays, and maybe that's true, but apart from Kerm and probably Benryves, i don't really know of anyone else. Maybe it's because a lot of the assembly programmers i speak to don't use Windows and have no other choice or maybe because the format feels closer to what we were used to with TASM or maybe just 'cuz it's so straightforward, i dunno. If you're going to start a huge project you might like some features of one over the other that let you organize your code more easily, but really it's not going to make that much of a difference: the assembled output will be exactly the same using both assemblers
Show Posts
)
DJ_O says most people use Brass nowadays, and maybe that's true, but apart from Kerm and probably Benryves, i don't really know of anyone else. Maybe it's because a lot of the assembly programmers i speak to don't use Windows and have no other choice or maybe because the format feels closer to what we were used to with TASM or maybe just 'cuz it's so straightforward, i dunno. If you're going to start a huge project you might like some features of one over the other that let you organize your code more easily, but really it's not going to make that much of a difference: the assembled output will be exactly the same using both assemblers