Those who are massive Amiga fans as well as TAS enthusiasts may get one of their dreams in the coming days/weeks/months/however long the feature takes to solidify.
WinUAE 2.3.1 public beta thread:
http://www.winuae.net/files/b/winuae_2310b1.zip
Beta 1
!!!!!! NOTE: Re-recorder thread will be opened later. All posts related to new input recorder in this thread will disappear. !!!!!
*snip*
- "re-recorder" implemented (completely rewritten combined input/state recorder). More information coming later.
- many statefile related changes for input/state recorder compatibility, may break something else..
* WARNING: statefiles created with betas may not be compatible with future versions!
* save current track's data and density in statefile if disk drive motor was active (regenerated
raw track data/density after state restore may not be identical if using ipf or fdi images)
* state save/restore while disk DMA is active is now fully supported
* save strings in utf8 (should have been done long time ago during unicode updates..)
* useless DMAC chunk was saved in non-CDTV configurations (2.3.0)
* CD state chunks were saved even if selected configuration didn't have any CD drives (2.3.0)
* 68020 cache and prefetch pipeline saved and restored
* debugger memory watchpoints saved and restored
* save active (very rare) interrupt delays (interrupts that have been triggered but have not yet been noticed by Paula)
* mid-instruction CPU state save support, restored state CPU state is now exactly same as when state was saved (68000 CE only, 68020 CE later), previously current instruction was simply restarted (this was really complex and non-trivial task, it is only easy if you accept much higher CPU usage. Which isn't good idea...)
* full blitter statefile support in cycle exact mode, state capture/input recorder only currently. This saves blitter emulation variables, not real hardware state (internal statemachine state, latches, counters etc..) because internal structure is unknown. State capture only because it requires 100% identical state after restore (normal blitter state forces current blit to finish). This is not enabled in normal state saving because it is very difficult to keep state saving compatibility between versions when state is hardcoded to current emulation implementation.
I posted that quote about the thread, as I wouldn't want anyone going over there and posting in the normal beta thread just now, yet everyone here would be the best team to beta-test rerecording features for WinUAE, as this is pretty much the home of modern TAS development. I've also notified the EAB forum that I've informed you guys about the rerecorder, so that interested parties can assist with the beta process.
Note: I have not looked at this build of the emulator, so I know absolutely nothing about the rerecording features, other than what I quoted above.
Edit: Of course, since the new version of WinUAE is in beta testing, I would suggest holding off on using it to make actual, published runs - the input recorder and savestate functionality seem to have been recoded from the ground up. Feel free to use it for POC runs or in developing a route for an Amiga game, however. A500 cycle-exact emulation is fairly rock-solid nowadays - Toni fixes a few bugs here and there but I think the focus nowadays is more on A1200 compatibility (at least in terms of the cycle-exact emulation). Needless to say, for reasons obvious to anyone who has any knowledge about the TAS process besides than "load emulator, load ROM, load movie file" or "click YouTube video link", the rerecorder will require cycle-exact mode. Suffice it to say, trying to TAS games running under JIT mode with Picasso96 and immediate blitter enabled will probably not work yet, if ever =P
Edit: Quick statement from Toni (you have to understand, there have been lots of bad, useless bug reports in the past with the emulator as a whole, and so Toni likes to keep things a bit more organized):
There is very good reason why no talk about rerecorder yet: it is too early for public testing. It still in private testing (it already works, looking for last few glitches)
Any so called "bug report" I see will only make me annoyed. Especially if I see even one so called "recording" without using very specific methods to record it. It has very strict requirements which will be explained soon.
Don't do it if you want to see finished rerecorder.
So, basically, this is just a heads up that it's coming, DO NOT use the current version of the emulator to do any non-BS rerecording.
Hey there, I've been waiting for some kind of re-recording on WinUAE for a while and now it's here! I've spent some hours trying it and now I'm getting quite used of it.
So far i didn't experience any problem with it and I used many features that were all really useful.
You start re-record on WinUAE 2.3.1 from system start or from savestate. Then you can do the following while Tasing :
- Adjust most graphical host settings (that include choosing the FPS rate from 1 to 99)
- save your final recording anytime any number of times
- quicksave your position or use autosave every n seconds, so you can quickly reload it
- rewind back to the last quicksave that was created before the last one you did
You can also play the result of a recording after saving it and switch to re-record before it has finished playing!
Here's a little TAS of lotus turbo challenge, it has a few mistakes but it still should be interesting
http://www.youtube.com/watch?v=sUZYOc_XC1U
Looking forward Amiga TAS from real experts :D
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
So a couple old threads were merged, and to bump it properly, encouraging people to brainstorm and/or test TAS features of WinUAE for real, here are 2 quotes from Tub that are very important if we want to get to Amiga TASing some day:
Tub in 2007 wrote:
there are two problems: writeable disks, and copy protection. First, you'll never really know if your copy (or original disk) is unmodified. Second, copy protected games can only be played using .ipf-images, which cannot be read in a deterministic way. Either that, or the copy protection needs to be removed, and hacked images are not allowed on this site.
So even if the emulator is reliable enough for synced rerecording someday, we'll miss out on most of the best games. :(
The problem with the Amiga is a different one. UAE already supports savestates, and some of the runs on the (now inactive) recordedamigagames.org were using some kind of tool assistance.
But most amiga games have some kind of copy protection. Usually invalid sectors on the disks that return different data each time they're read. So, game dumps come in two flavors:
* .adf images. They just store the data of reading each sector once, and will thus fail to boot copy protected games. Most games distributed by .adf are cracked, i.e. have the copy protection removed. Tasvideos.org does not accept run on modified games.
* .ipf images. This stores the results of reading the disk several times, but it's a proprietary, closed source format made by the Software preservation society. As far as I know, it is not deterministic and cannot be used in a rerecording emulator. Not to mention that we couldn't claim that everyone dumped the original disks themselves: the tool to dump disks in this format isn't public.
Thus, while it should be possible to add rerecording to UAE, the list of games we could actually TAS would be minimal.
Is there anyone inventive who knows how to solve this? Writes to disks can probably be trapped in a sensible way, but what to do about copy protection?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 11/27/2017
Posts: 87
Location: United Kingdom
The use of cracked games is an obviously murky one. Not being a TASer I don't really have an opinion on this.
Now, IPF files.
* .ipf images. This stores the results of reading the disk several times, but it's a proprietary, closed source format made by the Software preservation society.
The format source is available under a rather unusual “SPS Freeware License Agreement”. Reading through this agreement is quite confusing though. I was planning on supporting this format for ZXHawk eventually, although by writing my own IPF image parser rather than using their binaries. If I can make it work that would mitigate any weird licensing issues.
As far as I know, it is not deterministic and cannot be used in a rerecording emulator.
I don't believe it this matters if we are writing our own IPF parsing tools. On a real disk, the data is written in such a way that errors are returned on successive reads, corrupting certain return bytes in certain sectors. I imagine IPF will just be storing multiple copies of sectors with CRC errors (much like the EDSK format), then the emulator (or library) will return a random 'mutiple copy sector; on each read.
On ZXHawk, I overcame this by making the 'random' choice of duplicate sector deterministic. It just has an internal counter that increments and that is used to select the duplicate sector data. Because copy protection is generally performing successive reads of a sector looking for specific differences, this method works quite well. If you only have 3 copies within the image and are choosing truly at random there is a good chance that the protection check will fail every so often.
Not to mention that we couldn't claim that everyone dumped the original disks themselves: the tool to dump disks in this format isn't public.
This point is moot.
This is the tool:
https://kryoflux.com/?page=download
The hardware floppy controller is purchasable and the software is freely downloadable for non-commercial use.
I followed the instructions on this page, but when I want to replay a movie I get dozens of these error messages with different numbers and the movie either stops playing or desynces nicely.
Did someone manage to reread a movie without any problem, and if so, with which configuration?
Joined: 4/17/2010
Posts: 11495
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Okay so here's the workflow that should work:
http://tasvideos.org/forum/viewtopic.php?t=20837
It's using FS-UAE and libTAS, so no need to worry about internal support for rerecording, since we can just force it from the outside!
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
