realtime "cycle track" for IDE software

[+grafixbmp]

I've been wondering this for a long time and haven't seen any helpful tools along these lines. It seems one of the hardest parts of 6502 assembly is keeping track of your cycles and I was wondering what you guys thought of this.

 

We know how long each opcode takes and that any type of branch or loop takes diffrent times depending on which path is taken. And we know that most each scanlines start is dependant on WSYNC. However, it seems most times when cycles are concerned are either on crossing page boundaries, starting a new full frame, or the end of a scanline. I know it would probably be the best help for me and I would think for others as well, to be able to write your code and know how far you have gone in cycles, in turn, allowing you to know how much time is left per scanline, possibly per frame. It would also be nice to know where a page boundary is as well.

 

I was thinking about something for scanlines as a red bar that fills in as you write opcodes like for 76 cycles intervals:

----------------------------------****************************************** 34/42

And then as you write you can check to see what you have left to work with.

 

For cycle offset conditionals, how about something like this:

--------------------###***************************************************** 20/53: 3

That way you know your conditionals as well for a scanline basis. when your cycles match back up agin (if you want them to meet at the end) the off set can dissapear.

 

page boundaries could be done as this:

------------***********************|***************************************** 12/ 64 |35/36

As you write opcodes and additionals, the page boundary crossing adjusts its location with how much you have left till you get to it in conjuction with the scanline counter. This of course depends on if you use 1 2 or 3 bytes of memory each time you write something.

 

I know it would be extremely difficult to keep track of a whole program but for smaller parts of one, this could be rather helpful, I would think. Would anyone else appreciate a tool like this.

 

Incidently, This type of counter could also display space left to program with for each bank you have depending on your project, but this is an afterthought.

Edited May 24, 2008 by grafixbmp

[+batari]

Cycle counting isn't that hard, just tedious at first. Print out a chart with all cycle counts, and add them as comments after each instruction. After a few weeks of doing this I had everything memorized.

 

If you want a tool, however, the Stella debugger does just what you say.

[+grafixbmp]

Cycle counting isn't that hard, just tedious at first. Print out a chart with all cycle counts, and add them as comments after each instruction. After a few weeks of doing this I had everything memorized.

"tedious" is the word. It may not be hard for you but it is time consuming to say the least and doing it manualy allows the door to be open for human error in counting. I have worked at 3 diffrent retail and grocery stores for a total of around 7 years. 5 of thoes years at Wal-Mart and 2 of the 3 stores, worked a register. If the registers never gave me any values or a running total to work with on the screen, THAT job would be tedious let me tell ya. The idea with this is to be even more organized and save time in the process. Many tools used mainly build data like drawing and music programs but how many help to keep track of it while programing.

If you want a tool, however, the Stella debugger does just what you say.

The key here as you say is 'debugger', which indicates after the fact of coding. Granted that programing is to create code, build BIN and test for errors. However that process is also repeditive, tedious and time consuming as well. Trial and error works but it helps to avoid it where ever possible. The less things you yourself have to keep track of the better. For isn't that one of the reason computers exist?

 

The more you can take care of at a time the less you have to stop and check. In my experience when I was little, I loved programing things on the commodore 64 computer. I could hardly wait to test my work and so I would run many of times what I had done before I was finished and obviously it would not work correctly cause not everything was there. When it comes to doing this with Atari games, if you have large amounts of code that is workable and go to debugg it, its that much more you have to meed through to find your error if stella doesn't catch it right away.

 

Bottom line: I'm not so worried about debugging as keeping track of my cycles as I go without having to take the time to do so manualy. The quicker a project is completed, the quicker you can start another. I'm all for nostalgia in Atari but not doing things so archaic like the games were done in the past.

[+batari]

Bottom line: I'm not so worried about debugging as keeping track of my cycles as I go without having to take the time to do so manualy. The quicker a project is completed, the quicker you can start another. I'm all for nostalgia in Atari but not doing things so archaic like the games were done in the past.

There isn't even a real IDE specifically for 2600 asm programming to which to add this functionality, so it's not likely you'll have this in the future. Also, I suspect that the Stella debugger is not what you think it is. You should try it out, as it's pretty nice, and not just for "debugging."

 

I think that having cycles counted for you from the get-go would actually be a crutch in the long term. It's really better to struggle with it like everyone else, and before you finish your first program, you'll have it down. For example, suppose you are writing a kernel and you have 13 cycles in each scanline free. If you know the cycle counts of certain instructions, you will know ahead of time what you can and can't fit in that space. You'll know the most efficient way to do certain things without having to write a bunch of code and have an IDE count the cycles. Without knowing cycles, you will end up wasting lots of time trying to write code that will never work.

 

Of course cycle-counting is subject to human error, but you can at least try to count cycles and use the debugger to see if you were right. The debugger actually is an IDE of sorts, and your code does not need to be "working" or even close. You can single-step through even the most rudimentary, non-functional code that has no chance of displaying anything useful on the screen, and debugger will count the cycles for you.

 

An alternative (but less useful, IMO) is to write your code, assemble it, then disassemble it with distella. This will show the cycle count on each instruction, but of course all your labels, comments, formatting and the like will be lost, so you'd probably want to manually copy all of the cycle counts over to your code.

Edited May 25, 2008 by batari

[+grafixbmp]

There isn't even a real IDE specifically for 2600 asm programming to which to add this functionality, so it's not likely you'll have this in the future.

 

Actualy depending on if strides are made further than what they currently are, Eclipse might one day support some exclusive plugins for atari considering it seems to be the most versital and configurable IDE Dev kit out there for modern programing. Which is a topic Cybergoth started a few topics back. This could then support exclusive features only Atari programers could appreciate.

 

It's really better to struggle with it like everyone else, and before you finish your first program, you'll have it down. For example, suppose you are writing a kernel and you have 13 cycles in each scanline free. If you know the cycle counts of certain instructions, you will know ahead of time what you can and can't fit in that space. You'll know the most efficient way to do certain things without having to write a bunch of code and have an IDE count the cycles. Without knowing cycles, you will end up wasting lots of time trying to write code that will never work.

 

You just stated the reason I find this type of cycle tracking handy. This instantly lets you know you have 13 cycles left from the beginning without having to count them and after you do an opcode with operands, the number would change to reflect that. Obviously geting down the cycle counts for each instruction won't be a problem, but keeping track of more than a handful is just a few more things to handle that the computer could do for you. And if you know you need to fit a short routine that take say 15 cycles. You can then go back and possibly shave out 2 more cycles and instantly know if it is possible. This would just make this process so much quicker in the long run, not just on a time by time basis.

And who says anyone should have to struggle with it if there could be any better ways. Original atari programers didn't have the tools that we have today (emulators, advanced IDE environments, etc). Does that mean we should have a cut off point that we no longer have any helping upgrades to the development process? Even the slightest ones?

[+batari]

A cycle counting IDE is unlikely to be able to follow the discontinuous paths of a real program (as they always have branches) but rather just display the individual cycle counts for each instruction as you type them. The former would require much of the functionality of a 2600 emulator built into the IDE while the latter would require just some lexical analysis. So you'd be doing the actual counting anyway.

Edited May 26, 2008 by batari

[+grafixbmp]

A cycle counting IDE is unlikely to be able to follow the discontinuous paths of a real program (as they always have branches) but rather just display the individual cycle counts for each instruction as you type them.

 

my first post:

I know it would be extremely difficult to keep track of a whole program but for smaller parts of one, this could be rather helpful, I would think.

 

I only am refering to scanlines and end of frames. And I only was giving an example of branching for a scanline basis only. Nothing beyond that. And WSYNC would automaticaly render a cycle tracker no longer useful anyway.

This kind of tool is more for use in kernal programing anyway. That is hwat I was aiming tward

 

The former would require much of the functionality of a 2600 emulator built into the IDE while the latter would require just some lexical analysis. So you'd be doing the actual counting anyway.

 

Since when was having a piece of software count cycles 'much of the functionality of a 2600 emulator' ? The counter wouldn't care what the codes did, just how many cycles do they take.

 

Besides, I got to thinking about this and any IDE could benifit from this kind of tool. It could be a forefront program that feeds keystrokes to the IDE but captures them first. Speech to text programs work in much the same way.

[mos6507]

A cycle counting IDE is unlikely to be able to follow the discontinuous paths of a real program (as they always have branches) but rather just display the individual cycle counts for each instruction as you type them. The former would require much of the functionality of a 2600 emulator built into the IDE while the latter would require just some lexical analysis. So you'd be doing the actual counting anyway.

 

I personally would enjoy the latter if it had a destignated startpoint and "total". It doesn't have to be perfect, just a guideline to help time up register writes and avoid completely overruning 76 cycles.

[+batari]

Since when was having a piece of software count cycles 'much of the functionality of a 2600 emulator' ? The counter wouldn't care what the codes did, just how many cycles do they take.

 

Besides, I got to thinking about this and any IDE could benifit from this kind of tool. It could be a forefront program that feeds keystrokes to the IDE but captures them first. Speech to text programs work in much the same way.

I may be wrong, but it sounded to me like you wanted something that would count cycles from an arbitrary place and count cycles to the end of a scanline. In order to trace the code in this way, the IDE would not only need to assemble on the fly, but simulate the code so it knew where branches (they have 2, 3 or 4 cycles) and where page-wraps (add a cycle) may occur. Since you have a branch roughly every 4-6 instructions and you can't always easily tell before runtime where page-wraps occur, you'd need nearly a full emulator.

 

So what I'm saying is it's only really feasible to have an IDE look at individual instructions you just typed and calculate the cycles for each individual instruction, and leave the actual tallying to the programmer (which as I said earlier, varies depending on taken/not taken branches and/or page wraps.)

 

FWIW, if such an IDE that allows custom coding ever surfaces for 2600 asm, the individual instruction cycle count *might* be possible and not too hard.

Edited May 26, 2008 by batari

[+grafixbmp]

The whole process I've been postulating could be more flevible where you canl click one particular opcode and a second several lines down and pull a total for say a subroutine. Saves counting each one. Noone said this had to be perfect. Or you could set a starting point and count from there. It could count branches,but could have alimit up to 3 or so.It doesn't have to keep track of all of them. It would then act more as an interpreter rather than an assember so no code would need to be compiled. And then only small sections would need interprating.

 

Think of it as having an inline calculator you can set variables with and it adds up the cycles, with in its ability to, for you. If there is too much for it to do, it simply throws back an error or how ever far it could count safely. It would probably be a work in progress anyway when it eventualycomes about.

 

On a side note, I went ahead and grabbed the only plugin for eclipse that does 6502 and the source so I may feed of of it and possibly work on the TIA side of things as well. Given that cybergoth wrote he is no longer intrested cause he had trouble running it.

[Sub(Function(:))]

Do people actually develop for the 2600 using eclipse?

 

I ask because from what I have read so far the Assembler of choice seem to be DASM. DASM is not a linking assembler, am I right? If so this means that there are not multiply source files in an individual programming project, and this sort of makes eclipse the sledgehammer for the 2600 nut.

 

I would have said a good text editor would be more suited to the job in hand. It should simply be able to run external applications from a key press; Assemble current source, launch emulator. I was planning on using Semware editor as it is small, has a great macro language, and runs from my USB flash drive so I can work anywhere. down side is it is commercial software

 

I only mention this because I want to start programming the 2600, and also would like quick information regarding opcode timings. I would have said a good macro language in the text editor or a few external scripts would have been sufficient.

 

What I would have proposed would be as set of scripts:

ShowTimings() :- For a selected block of text/assembly display the timings preceded with timing information. This is nondestructive to the original source.

Insert timings() :- Actually insert text in to the lines comment field with the timing information.

SumTimings() :- for a given range of assembly statements calculate the min and max timing information

 

The above functions would only require minimal parsing of the lines of source. search for an opcode on a line of text and see if it has an op code on it. then find out its addressing mode. look up this information and output the result... If you design the look up table for timing information correctly you could also have code size returned as well (but you would have to be careful of the data storage pseudo-ops [:Db etc].

 

What do all you think?

 

All the best.

[+grafixbmp]

Do people actually develop for the 2600 using eclipse?

 

I ask because from what I have read so far the Assembler of choice seem to be DASM. DASM is not a linking assembler, am I right? If so this means that there are not multiply source files in an individual programming project, and this sort of makes eclipse the sledgehammer for the 2600 nut.

 

I would have said a good text editor would be more suited to the job in hand. It should simply be able to run external applications from a key press; Assemble current source, launch emulator. I was planning on using Semware editor as it is small, has a great macro language, and runs from my USB flash drive so I can work anywhere. down side is it is commercial software

 

I only mention this because I want to start programming the 2600, and also would like quick information regarding opcode timings. I would have said a good macro language in the text editor or a few external scripts would have been sufficient.

 

What I would have proposed would be as set of scripts:

ShowTimings() :- For a selected block of text/assembly display the timings preceded with timing information. This is nondestructive to the original source.

Insert timings() :- Actually insert text in to the lines comment field with the timing information.

SumTimings() :- for a given range of assembly statements calculate the min and max timing information

 

The above functions would only require minimal parsing of the lines of source. search for an opcode on a line of text and see if it has an op code on it. then find out its addressing mode. look up this information and output the result... If you design the look up table for timing information correctly you could also have code size returned as well (but you would have to be careful of the data storage pseudo-ops [:Db etc].

 

What do all you think?

 

All the best.

I have tried twice to resply to your post and my computer is messing with me so I will just post the files I intended and you can do with whatever. Hope noone cares me posting these. Work needs to be done on them for TIA support. Got them through some links on the forums. here is both

cpu6502_0.5.0.zip cpu6502_0.5.0_src.zip

 

These are suppost to be for eclipse BTW. At least that is what I was told.

Edited June 11, 2008 by grafixbmp

[+SpiceWare]

I ask because from what I have read so far the Assembler of choice seem to be DASM. DASM is not a linking assembler, am I right? If so this means that there are not multiply source files in an individual programming project, and this sort of makes eclipse the sledgehammer for the 2600 nut.

By using INCLUDE you can have multiple source files.

[Sub(Function(:))]

I ask because from what I have read so far the Assembler of choice seem to be DASM. DASM is not a linking assembler, am I right? If so this means that there are not multiply source files in an individual programming project, and this sort of makes eclipse the sledgehammer for the 2600 nut.

By using INCLUDE you can have multiple source files.

 

Possibly so, but you are only assembling 1 source file. The other source files are simply included into the one they are called from. So there is no need for an external linking process. This, to my mind at least, means there is no need for complex build tools. A single command line to assemble source code, and create a binary image for execution, that is called by pressing a key from the editor. Perhaps another key to execute the emulator.