There are two things I would like to see added to Uzem.
I may have a go at doing myself, but giant C projects on desktops scare me. I didn't mind modifying Uzem to add the timer compare interrupt support for the new video modes as it didn't have to do any I/O. These two ideas are going to have to add something to the screen (like Lunatic did with the RAM visualizer) and/or write something out to a log file. Its those two things I don't think I am capable of doing
Any way the two things I would love added are
1, H_Sync timer tracking.
2, Stack Usage Tracking
Neither of them are NEEDED, but they are time saving in the long run.
Number 1 is only of use when someone is developing a new video mode. So limited scope of use, but how good would it be and how much easier would it make it to really push the envelope with custom modes. In particular I was thinking of non tile based modes or modes that have small windows of high res FMV on an otherwise static ROMTile screen.
I still think there are a lot of boundaries to be pushed in non-tile modes. Giants scaled sprites, compressed video, Doom/Raycasters that all are going to need a lot of H_Sync counting.
Number 2 is something I already have code to do on the Uzebox side, but it would be easier if the emulator could just tell you the lowest address the stack pointer got too. It's also something the should be reasonably easy to do.
It could probably save people a fair bit of time that are having unexpected crashes due to stack collision.
Suggested new features for Uzem
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Suggested new features for Uzem
Both would make great features. For me the first one is something I use often, though I use the Atmel emulator in AvrStudio\AtmelStudio to track the timer1 with cycle precision. Are you using it? How do you see that functionality implemented in uzem? Just display the value of timer1 at some fixed point in time?
Just displaying values should not be a big deal. The problem is uzem code base is getting harder to maintain and I don't really like way the visualizations has been implemented with some inline code. We are at a point where a rewrite and re-architecture would be badly needed. But who has time for this!
Just displaying values should not be a big deal. The problem is uzem code base is getting harder to maintain and I don't really like way the visualizations has been implemented with some inline code. We are at a point where a rewrite and re-architecture would be badly needed. But who has time for this!
Re: Suggested new features for Uzem
Code: Select all
#ifdef USE_PORT_PRINT
else if(addr == ports::res3A){
// emulator-only whisper support
printf("%c",value);
}
else if(addr == ports::res39){
// emulator-only whisper support
printf("%02x",value);
}
Things like the visualizer, eh it's a cool feature, but the development value was a bit dubious for the added mess in the source. I'd rather see things like a GUI with keymapping or graphics options before more bells and whistles. I would love to clean up Uzem, but I have a bad habit of loving to do a lot of things, so never any time to complete anything. I like both the features Cunning mentions but not sure what the best way to implement it would be.
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Suggested new features for Uzem
The stack pointer should be easy, as I don't think anyone does/should use the heap. Simple use the command line to pass in a HIGH address (stackstart in normal usage) and LOW address (highest variable in RAM) and then it can plot a guage/bar-graph of where SPH:SPL is in this range. (the high & low address is needed in case someone decides to steal SP for other uses). Then on exit print to the console the lowest memory address (in range) that SP got too.
[quote=uze]though I use the Atmel emulator in AvrStudio\AtmelStudio to track the timer1 with cycle precision. Are you using it? How do you see that functionality implemented in uzem? Just display the value of timer1 at some fixed point in time?[\quote]
During vector game I used AVR Studio and looked at the TCNT1 to check the H_Sync time.
After I started using the interrupt to end the scanline in T2K it got messier. I mainly tried to count cycles in a spreadsheet. I did test in AVRStudio often though. It required
TCNT1 just before I trashed it
TCNT1 as HSync happened
The free running cycle counter to time between HSync
I had to transcribe numbers to cells in a spreadsheet for it to check for me it all added up, and point me to which part was a wrong.
It was very messy in T2K as I used the extended front/back porch to feed the SD card and clear the VRAM.
For video modes that are not going to have fixed units of time/real-estate (8 pixel x 5 clocks x 32 tiles is fixed) the whole counting thing is going to get messier and harder.
There are a few things I would like to see for the HSync checking.
First a simple visualizer on the side of the screen.
That way you could in the example above see that every 8th row was X clocks short. I would probably have the visualizer bar 17 pixles wide
>= 8 short
7 short
6 short
...
1 short
1440 cocks
1 long
...
>= 8 long
and have the 1440 as a green pixel and the others as RED and have the fade the same way as lunatics visualizer did.
The other thing I would like to see is a table written to a log file effectively the same info. I big table that is 17x224 cells each with a count of how many times that HSync-Time happened.
If you SEE something red in the visualizer, you can import that table into a spread sheet and hunt it down.
Finally, if there is going to be some way of counting clock cycles being done anyways, I would love to be able to pass in two addresses and have the emulator spit out to a log file the clocks between these two addresses being executed. That would make profiling complex things easier.
[quote=uze]though I use the Atmel emulator in AvrStudio\AtmelStudio to track the timer1 with cycle precision. Are you using it? How do you see that functionality implemented in uzem? Just display the value of timer1 at some fixed point in time?[\quote]
During vector game I used AVR Studio and looked at the TCNT1 to check the H_Sync time.
After I started using the interrupt to end the scanline in T2K it got messier. I mainly tried to count cycles in a spreadsheet. I did test in AVRStudio often though. It required
TCNT1 just before I trashed it
TCNT1 as HSync happened
The free running cycle counter to time between HSync
I had to transcribe numbers to cells in a spreadsheet for it to check for me it all added up, and point me to which part was a wrong.
It was very messy in T2K as I used the extended front/back porch to feed the SD card and clear the VRAM.
For video modes that are not going to have fixed units of time/real-estate (8 pixel x 5 clocks x 32 tiles is fixed) the whole counting thing is going to get messier and harder.
There are a few things I would like to see for the HSync checking.
First a simple visualizer on the side of the screen.
Code: Select all
X 1440 clocks
Line1 |
Line2 |
Line3 |
... |
Line7 |
Line8 |
... |
Line14 |
Line15 |
... |
Line223 |
Line224 |
>= 8 short
7 short
6 short
...
1 short
1440 cocks
1 long
...
>= 8 long
and have the 1440 as a green pixel and the others as RED and have the fade the same way as lunatics visualizer did.
The other thing I would like to see is a table written to a log file effectively the same info. I big table that is 17x224 cells each with a count of how many times that HSync-Time happened.
If you SEE something red in the visualizer, you can import that table into a spread sheet and hunt it down.
Finally, if there is going to be some way of counting clock cycles being done anyways, I would love to be able to pass in two addresses and have the emulator spit out to a log file the clocks between these two addresses being executed. That would make profiling complex things easier.