5 replies to this topic

[grafixbmp]

I am sure many people have asked for many things before but this would help everyone from the novice to the expert IMO. I just read something someone wrote once about a point and clock programing way to the 2600. I feel the same way most of you do about this, that it isn't the best idea.
However, I do feel that there coiuld be a great bridge merged between the scripting editor and the emulator for testing. If there was an advanced editor made specificaly for the 2600, where you can see everything the system has to offer at your fingertips. Like a better layed out look similar to the stella debugger when your hit the "~" key.
Imagine writing the code realtime as you count your clocks and a counter that shows how many you have left per scanline. A visual cursor that follows along the screen leting you know how far you have gone raealtime and how much you have left to work with. great for kernal creation. and a dropdown display that shows all the ram you have and what is used and what is not. If you know how it will work as you do it, then you won't have to compile, test, debug, search code for errors, rewrite and do it alover again untill you find your problem.

Another thing would be have a the TIA atributes listed while you are coding like all sprites current horizontal trigger locations, width, color, vertical activation, etc. ANd a quick list of all flags and what they are set to as well. With a system that keeps track of these thiungs and the # of clock cycles the opcodes take, you can race the beam far better that ever before. You could also have macro inserts that trigger groups of code to insert themselves without having to create any header files that would be necessary when realeasing source code because the code would be written verbatim by the editor. and a display that shows current counts of the x and y registers so you always have them on hand when you need them to know what number you are at at all times. You could also section off areas in the program ROM just for improtant things and search for them when needed. For example, graphics data, sound data etc. Or howabout keeping your bankswitched roms in better order visualy, which will allow you to spendmore time on other improtant things.

I can give a basic layout visualy as a mockup if anyone likes this thought. I think it is time for more/better tools. Like how old is DASM and how many people use crimson cause it is the best one out there to date?

[BigO]

While I share your wish in some ways, the code would need to be executing and have input to cause it to branch appropriately in order to count cycles.

If you have no decisions being made in code, meaning there is only one execution path through the code so it will take the same number of cycles every time, you could count cycles at design time. Looping and other such constructs would also make this a very difficult task that could only be done practically at run time. (It's over my head anyway, but I'd be happy to be proven wrong.)

Are any of the emulator tools capable of reporting explicitly that too many cycles were used before a new line was detected? I can think of circumstances where this would be useless, but I'd like to have it as a debugging tool on occasion.

I was hoping for big things until I realized that "point and clock programming" was a typo. While stumbling and bumbling around trying to learn how to code for the 2600, I found myself wanting a debugging capability that would allow me to click a point on the display output screen and break into debug mode when the simulated TIA was writing to that pixel (and/or started that line or other options). Sure, I can break the code somehow, but it can take me a while to figure out which iteration of what loop is causing the flaky display.

[mos6507]

Stella already has a debugger. What it doesn't have yet is the ability to step through your actual commented sourcecode, which I hope they do eventually.

[grafixbmp]

why couldn't the software choose to follow all braches and then show which branch (if any) have a clock cycle over run. you could also have manual braching. once you step through your code, it would give you the choice of which brarnch to take and depending on your choice it would add up the clock cycles and compare them to see the diffrence. I know it could be done. give it more thought and explore the possibilities.

[BigO]

mos6507, on Tue Jul 24, 2007 1:28 PM, said:

Stella already has a debugger. What it doesn't have yet is the ability to step through your actual commented sourcecode, which I hope they do eventually.

If that was a response to me, I've used the Stella debugger. I like it and it has proven to be very useful. It just doesn't have my rare-occasion, wish-list functionality of clicking a spot on the screen and breaking into debug mode when the emulator is about to write that pixel.

I think it can break on memory access or change, but I haven't seen where picture elements are included in the monitored memory locations. I suppose one that could initially be set up using a manual Row,Column type reference. Probably not worth the effort for the programmer, though, as I doubt it would be one of the more popular features. Correlating the currently executing statement back to its counterpart in commented source code would undoubtedly be more useful to more people.

Edited by BigO, Mon Jul 30, 2007 7:48 AM.

[BigO]

grafixbmp, on Tue Jul 24, 2007 8:36 PM, said:

why couldn't the software choose to follow all braches and then show which branch (if any) have a clock cycle over run. you could also have manual braching. once you step through your code, it would give you the choice of which brarnch to take and depending on your choice it would add up the clock cycles and compare them to see the diffrence. I know it could be done. give it more thought and explore the possibilities.

To do it automatically, it would have to somehow know every possible valid value and combination of values for controller inputs and console switches and have some sort of scripting tool to apply those values during execution. Such testing tools exist for other platforms.

I believe with something like the Stella debugger, you should be able to do what you're proposing, albeit in a more manual way. I think it does count and report clock cycles, frames, scanlines, etc. A debugger, by it's nature, allows you to assert values for variables at given points during program execution, thus controlling the manual branching choices while stepping through the code.

BTW - I'm not necessarily arguing against your propsal, just sharing the thoughts that I have had about the subject in the past.

_{(I don't have a ton of experience with them, so don't be surprised if I misrepresent or overstate some of the functionality of existing 2600 code debuggers.)}