Suggested new features for Uzem

The Uzebox now have a fully functional emulator! Download and discuss it here.
Post Reply
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Suggested new features for Uzem

Post by CunningFellow »

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.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Suggested new features for Uzem

Post by uze6666 »

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!
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Suggested new features for Uzem

Post by D3thAdd3r »

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);
    }
I have never used those, but they seem pretty useful to me. It would be nice for a program to be able to turn on and off Uzem features for testing. Perhaps it takes the first byte as a command, such as PrintInt() to console, then the next bytes are arguments, and then it does whatever. I agree the Uzem codebase needs a clean up, I was pretty sensitive to it and wrapped up 8266/UART stuff as separated as possible in a class. Similar to this idea, what I did is add unofficial AT commands like "AT+DEBUG" which tells the core to display useful development information about UART/Net stuff.

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.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Suggested new features for Uzem

Post by CunningFellow »

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.

Code: Select all

             X 1440 clocks
Line1        |
Line2        |
Line3        |
...          |
Line7     |
Line8        |
...          |
Line14    |
Line15       |
...          |
Line223      |
Line224      |
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.
Post Reply