Jump to content

splendidnut

+AtariAge Subscriber
  • Content Count

    335
  • Joined

  • Last visited

Community Reputation

471 Excellent

About splendidnut

  • Rank
    Moonsweeper

Profile Information

  • Gender
    Male
  • Location
    PA/NY Border

Recent Profile Visitors

5,752 profile views
  1. Ok, fair enough. I'll have to explore my ideas on my own. Thank you.
  2. I kind of knew coming here with this problem that I'd be opening a can of worms. My original goal of this thread was to be able to have Stella use the appropriate labels for memory locations in the debugger. Currently, some of the locations end up with the names of constants instead of vars. I'm not sure why that is.... Eventhough I've defined all variables first, I have at least one memory location that is labeled with the name of a CONSTANT that's not even defined until the middle of the ChaoticGrill code base. It things like that which cause problems when trying to debug things. So I've tried to change the way I define variables to something which seems more appropriate, but that ended up exasperating the problem. So instead of doing things smarter, I had to revert to a "hacky" way of defining variables: one by one using specifically assigned memory locations. I understand the point of view that dev tools should be kept as simple as possible/no simpler than that. They also should serve the developer and also interface nicely with the rest of the world where/when possible. I already use naming conventions to differentiate between constants and variables, but that doesn't solve the problem that Stella doesn't know which is which. My personal feeling on this is that type information should be in the symbol file. Stella really isn't the one who should be figuring out that information, it should just need to understand an input file.... Unless, of course, you want to turn Stella into a complete development environment.... which I'm not opposed to since I currently have to bounce between three different windows to develop, build, and run. For right now, the best solution seems to be: physically make and print out a memory map of the variables if I want them to be completely correct.
  3. Hmmm... an idea comes to mind: Wouldn't the better approach would be to have DASM itself analyze the use cases and create a more robust symbol file that can denote const vs var? For starters, labels could be considered constants if they are only used in immediate mode instructions. ... I have a big interest in getting this all figured out... I have a compiler I've been developing that outputs DASM-based assembly files and also it's own version of a symbol map file. It'd be cool if I could find a way to interface that nicely with Stella.
  4. Thinking a bit more on this, I think this is a bit more complicated than I originally thought. There seems to be no easy way to differentiate between variables and constants in DASM. Unless, of course, I'm missing something... ... I've thought about helping out with Stella, but I would first need to figure out how to get it to compile on Windows using CLion (JetBrains product for C/C++ development). I started playing around with that a bit this weekend, but it looks like I would have to dedicate quite a bit of time to get Stella to compile with my preferred toolchain (mingw/cmake). I'd like to avoid having to setup another IDE/build environment.
  5. That's a good question. I've just gotten thru converting my variables back to using "var = $80" style and now I've got back all the variable names I want showing in the Debugger. So it seems Stella currently ONLY uses "=" labels for the RAM labels and generally the first ones it finds. So I would start by adding support for "ds" style variables. Then, being as variables should be defined in SEG.U name, couldn't you use the name to select which group of labels to show? I know that's an overly simplified approach. I'm not sure how others define their variables and constants. Before I asked my question originally, I had some weird ideas about doing some "hacky" things like figuring out a way to assemble my variable definition file and then somehow import the resulting sym/lst into Stella separately... That didn't sound like a great idea so I started this thread instead.
  6. Well, that's a bit disappointing. That really limits the usefulness of the variable labels in the Stella debugger. Taking a closer look, I'm now noticing that I've lost a bunch of variable labels in Stella by using "ds" instead of "=". So I'll have to move away from "enemyY ds 4" back to "enemyY1 = $88", "enemyY2 = $89"... and do my meticulous manual variable tracking again (not really that big of a deal). At least then, all zeropage RAM locations will have a label, even if it's not the correct one. Switching back to the old way of doing things will let me use the variable definition file itself as a reference as to where the variables reside in RAM. For module local/temp variables, they're already defined in a specific area of memory. This isn't too much of a big deal, as that's the way I was originally doing things. I was just hoping there was an easy way to tell Stella, "Here's the variable label list I want you to use". As for cleanup of other code areas, I was looking to avoid that until I finished up with these rewrites. For the most part, my code is not that much of a mess... that chef var name was just a quick and dirty example I could use... and it was the one that made me start to question things. In the actual code, I have playerState (main game var) and chefState (title screen var) as the two labels. So I just confused myself by not denoting that chefState is the name used only in the titlescreen (i.e. named ts_chefState instead). At the very least, I will go thru and change that stuff now. Thanks for the quick response Thomas!
  7. Currently I'm working on completely rewriting the burger logic code in Chaotic Grill. I've run into an issue where the variable labels in Stella don't match the variables defined in a DASM "SEG.U vars" set. At first I thought it was a bug in Stella, but then I realized that my new title screen variables overlap with the main game variables and are defined later in the code base, which probably causes the issue. The main game variables are: - defined in a SEG.U vars segment - defined as: chefState ds 1 OR enemyY ds 4 The title screen variables are: - defined after the main game variables - defined outside the SEG.U segment - defined as chefState = $87 Now I realize I'm might be shooting myself in the foot by using two different methods to define variables... but I've only recently switched to using SEG.U with the main game variables and haven't gotten around to cleaning up the other areas of code that define their own variables. What are my options for "forcing" Stella to use a certain set of variable labels? Currently I'm just using the DASM built lst/sym files.
  8. The first thing that comes to my mind is this might just be an issue with your friend's light sixer. The cartridge slot might need to be cleaned. Or there might be a power issue. Unless you're really not certain that your code is good. Have you wrapped everything in timers (vblank region, display kernel, overscan region)? Also, are you willing to post the source code or a ROM to try out/take a look at?
  9. Seems that way. Maybe it's due to trying to work around Aerlan's schedule? (Seems he's quite the busy man right now)
  10. No worries, it happens. I usually get tripped up with the limited STX/STY instructions and the lack of instructions supporting ZP,Y addressing mode.
  11. The operation LDX (addr),Y doesn't exist as a standard 6502 instruction: http://www.6502.org/tutorials/6502opcodes.html#LDX
  12. Good questions. But you're killing my potential answers by stating "Besides ease of use..." being as that's the key thing you have got here, and the thing I would attempt to correct with TIA Tracker. TIA Tracker has the power and flexibility (ex: Instrument Editor for editing envelopes), but it lacks the approachability. There's a learning curve, but I think that's mainly because it's a Tracker style editor and they all have that initial learning curve (Create instrument, then you can start making music by adding notes into a list). Atari-Riff-Machine has the nice piano-roll style editor which you can throw notes onto. Makes it quick and easy to throw something together. BUT it would be better if both channels could be displayed on the same roll, instead of the user having to scroll up and down. Also it would be nice to have a piano key display to go with the piano roll. There's a lot more you could do with this. As I said before, you seem very enthusiastic about making tools, so I thought I would stop by, make some suggestions, and try to gauge how far you want to go with this. I do enjoy playing around with your tools especially since they are web-based and I can access them anywhere. But I would also like to see you push them a bit further and polish them up a bit... ..... then combine them together with a text editor.... and viola, a new Visual bBatari Basic... Yes, I know, easier said then done
  13. That's what I thought you might say. I was asking about MIDI specifically so I could use one of my MIDI keyboards for input. TIA Tracker is what I've been using. And has been working out alright so far... If I could take what you've been doing, merge it with TIA Tracker, and add MIDI support, I'd probably have everything I needed. I know, I know... I'm a bit demanding of the tools I use. Just thought I'd ask since you seem very enthusiastic about making tools.
×
×
  • Create New...