Fixing timing, and new features

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

Re: Fixing timing, and new features

Post by CunningFellow »

uze6666 wrote:<SNIP>but this is something that could/should be handled by a Uzebox eclipse plugin. Uzebox Studio anyone? ;)
WHAT is involved with this ?

Would it be possible to make the install as easy as

1, Install latest eclipse
2, got to eclipse "market place" and click on "uzebox studio"

and it does the CDT, AVR and Uzebox stuff automatically ?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Fixing timing, and new features

Post by uze6666 »

CunningFellow wrote:
uze6666 wrote: WHAT is involved with this ?

Would it be possible to make the install as easy as

1, Install latest eclipse
2, got to eclipse "market place" and click on "uzebox studio"

and it does the CDT, AVR and Uzebox stuff automatically ?
Essentially, yes. Depends on what is meant by AVR and UZebox stuff. But it should be possible to fork the AVR plugin and add more stuff. So yeah, you'd only have to download the latest Eclipse CDT version and the plugin. One nice thing I noticed with the latest version is it has native GIT support in it. So it makes it very easy to pull the repo and work with it all within eclipse. I've been wanting to do this for a long time to make it easy to start development on multi platforms. Plus all the auto complete support in Eclipse is such a time saver.

As for functionality, for me at minimum I was seeing:
-Create Uzebox projects with our standard structure. Provide wizard pages to choose video modes and various compile time options.
-Import existing projects
-If possible try to make debug setup for uzem simpler. Possibly create it when the project is created.
-Create I/O views for the debugger like in AVR Studio simulator
-Better flash to chip support

With more efforts with could add:
-graphics and map/level editors
-Project's compile switches editor
-???

We still have the need for the binay tools and build them so we can't really have the plugin to do it all. Well, unless all tools are ported to java, including uzem! :?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Fixing timing, and new features

Post by uze6666 »

In response to Lee's message on another topic, let's discuss improvements to the capture mode. A couple ideas:
  • Have a format header to indicate the uzem version used to record other flags.
  • Have the eeprom and rom hex in the cap file
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Fixing timing, and new features

Post by Artcfox »

uze6666 wrote:In response to Lee's message on another topic, let's discuss improvements to the capture mode. A couple ideas:
  • Have a format header to indicate the uzem version used to record other flags.
  • Have the eeprom and rom hex in the cap file
Speed control would be my #1.

I have a script setup so every time I run uzem, it runs in capture mode, and frequently I'll find a bug in my code that needs fixing, or sometimes I just want to observe something that happened in slow motion. Unfortunately, sometimes the event of interest happens 10 or 15 minutes into the capture. It would be amazing if I could use a hotkey to speed up the emulation to fast forward through the boring parts of the capture, and another hot key to slow down the parts where I really want to see what is happening (sometimes as slow as frame-by-frame).

That feature could serve double-duty for the cases when I'm actively playing a game. Right now I have to go back and change my WaitVsync(1) call to a WaitVsync(10) call, recompile the game, and attempt to play through the majority of a level by hand in super slow motion just to get to the part of the level that I want to play-test in slow motion. If I could play through, say, the first 2 sections at a normal speed, and then hit a hotkey to let me slow everything down right before I get to the third section, play-test something that's very-timing critical, and then hit another hotkey to speed everything back up to normal, that would be super awesome.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Fixing timing, and new features

Post by uze6666 »

Speed control would be my #1.
+1. I had given a serious thought for the speed up bit since I had to wait a lot for the audio glitch with your cap. This could be done but would be limited by the speed of your machine since we need to compute each cycles to get the state right, specially when peripheral like the SD card are active. Unless we save the full state of the emulator each frame which is obviously not a solution. So I think it's possible to have a hotkey to remove/augment the framerate control to speed up. Slow down and single step should be even easier. Well in fact, it would be affecting uzem as a whole, not just the cap. So you could play in slow-mo if you'd want.
That feature could serve double-duty for the cases when I'm actively playing a game. Right now I have to go back and change my WaitVsync(1) call to a WaitVsync(10) call, recompile the game, and attempt to play through the majority of a level by hand in super slow motion just to get to the part of the level that I want to play-test in slow motion. If I could play through, say, the first 2 sections at a normal speed, and then hit a hotkey to let me slow everything down right before I get to the third section, play-test something that's very-timing critical, and then hit another hotkey to speed everything back up to normal, that would be super awesome.
One thing I did a couple time was to use L/R shoulder to control the number of frames in WaitVsync(n).
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Fixing timing, and new features

Post by D3thAdd3r »

Everything I can think that could cause desynch of the playback are:
*Random Seed, AI or other things could behave differently according to it
*Rom CRC, the previously release Loderunner demo might not work with the new more aggressive enemies code fix
*Uzem version, hopefully it wouldn't matter too much at this point though
*EEPROM, especially a game like Zelda or Mario World would be affected

That faster playback sounds very handy. I'm not too sure a lot of computers could run Uzem even 2x the speed it currently does, even without drawing. What if during recording there was a hotkey to save a machine state to the header and all previous input/state was erased and the following input/state proceeded to be saved, until you pushed the hotkey again or quit uzem. This would allow you to record only the point of interest of a longer periods, and as long as you were conscious to push the hotkey every now and again. You could have control that it never takes too long to get to the point of interest in the playback.
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Fixing timing, and new features

Post by uberlinuxguy »

I have been working on something of a "new feature" recently. I think I finally have the SPI RAM code working in the emulator. But since you have also made heavy changes, I want to make sure I help merge what I have done (if you like it of course) with what you have done. My changes mod quite a few files, so I'm not sure how you want me to handle it. The changes were against the master branch as of... oh master rev 6d4ece56be527360e330cc848954e147d8287a5e.

I've merged changes in current master to my copy (which incidentally includes some fixes to the kernel for the SPI RAM stuff, and adds that functionality there too) so my copy is up to date with the current master branch.

Thoughts on how you would like me to send you that Uze6666?
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Fixing timing, and new features

Post by uberlinuxguy »

So I guess if you want to try to apply it, to a fresh branch of master, you can do:

git apply --check 0001-Update-to-kernel-and-Uzem-to-support-SPI-RAM.patch

If that goes clean, you can run

git apply 0001-Update-to-kernel-and-Uzem-to-support-SPI-RAM.patch

To apply it. I have attached the patch here.
Attachments
0001-Update-to-kernel-and-Uzem-to-support-SPI-RAM.zip
Update to kernel and Uzem to support SPI RAM.
(19.74 KiB) Downloaded 592 times
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Fixing timing, and new features

Post by uze6666 »

Esssh, the master branch is pretty "old" for uzem. The best way I see is instead to pull uzem140 branch and merge your changes in there. The uzem140 branch has a lot of changes and refactoring so hopefully it wont be too hard (or was it the master? can't remember).
uberlinuxguy
Posts: 86
Joined: Sun Jan 04, 2015 4:38 am

Re: Fixing timing, and new features

Post by uberlinuxguy »

I was afraid you might say that. Lol. I'll give it a try tomorrow. And repost a git diff.
Post Reply