-Set up the "official" memory map - see http://wiki.intellivision.us/index.php?title=Memory_Map
--Things I didn't do:
---Accessibility.
---Additional Occupied Memory Ranges.
---Addresses Available to Cartridges
---Initialize any of the byte arrays.
--Not sure which of these I need to do, but clearly the byte arrays have to be initialized somewhere to something and there's a lot of gaps in this memory map.
2. Changed StopOnEnd to StopOnFrame. This expands the functionality so that you can tell the emulator to run and then stop at a predetermined point.
3. Expanded the functionality of RewindToFrame to handle more cases. Now you can go back or even forward to a frame and it handles the execution and greenzone appropriately.
4. Due to the change in structure some code was changed to check the index of the first and last saved states in the greenzone rather than relying on the size of the saved state list.
5. Changed the list of saved states in the movie log from a list of byte[] to a list of structures (the structure has an int for the index and byte[] for the state).
6. Saved an init state in the movie log. This is used to go back to the beginning if the beginning of the movie is no longer in the list of saved states.
7. Expanded the AddState and SetFrameAt logic in the movie log to account for the fact that the size of the saved state list is now capped.
8. Fixed a bug in the log interpretation for SMS.
9. Fixed a bug in the sms virtual controller, buttons 1 and 2 were hooked to the wrong objects.
10. Fixed the tastudio listview to show lag as pink.
-Made it so that each new search zeroes out the change count.
--This prevents all non-zero items from starting out with 1 change.
--A similar fix needs to be applied to Ram Watch (Filing issue...).
-Allowed changing data size, endian, and unaligned address setting in the middle of the search and maintaining valid values, fixing Issue 72 (The last open Ram Search issue until my "Difference" idea is hopefully accepted).
--Unlike my previous model, this does not align unaligned addresses; all it does is change the size / endian and PeekAddress.
--It does remove unaligned addresses, however, if you have it set to.
--This version converts System Bus instantly whereas the previous version stopped responding.
-The number of watches in Ram Watch is now updated in UpdateValues instead of LoadWatchFile, meaning that it's updated every time items are added / removed.
--Also noticed that separators count as watches. Filter these out and exclude them from the count, adelikat?
-UGLY REDUNDANT UGLY REDUNT UGLY REDUNDANT (Especially for DoSpecificValue() and DoPreviousValue()).
-I tested every possible scenario for the aforementioned abomination and it seems to work.
-I applied SignedVal and UnsignedVal to the comparison functions for sorting, the ToString functions, and specific value and previous weedings. I don't think there's any other places where this is an issue.
TODO:
-Try my mid-search data size conversion code again.
--Use it on System Bus and see if it is as slow (Not Responding) as it was previously now that 3 lists have been removed.
--Try allowing unaligned addresses and see if that makes any difference.
-Convince adelikat that moving "Prev value as change" to its own data item and column ("Differences" seems more appropriate) is the only sensible way.
-Maybe move all of the previous definitions from Ram Search to Ram Watch (With the exception of "Since last Search" of course.
-Perhaps allow the viewing / hiding of more columns on Ram Watch / Search.
--Well, data size and endian don't, but they will once these changes take effect in the middle of a search.
-Previous can now be defined as the last change, fixing the enhancement shown in Issue 73 (Ram Watch equivalent might come later).
-Fixed unsigned sort.
--prevList, undoPrevList, and redoPrevList removed. All of the definitions for previous are now stored in separate data items.
---Should yield small speed increases.
---Makes it easier to port these definitions to Ram Watch eventually.
---Auto-aligns data, making it impossible for issues, such as the original values not aligning with the correct values because the prevList wasn't recreated, impossible.
---Makes it possible for the field to automatically update when the definition is changed (Implemented).
--Value/PrevToString() now use the same code.
--Reduces redundancy.
---This was a problem as PrevToString wasn't taking into account the data type, whereas Value was. This is now fixed.
-Watch now stores the data for the "last change" previous definition. Now I just have to set up the option in the GUI.
2. Fixed issues with the light blue current frame pointer in tastudio
3. Removed a totally useless index that was being kept seperately in the movie log.
4. Moved the tastudio update after the check to see if the rest of the saved state list is valid.
5. Changed some function/variable names related to the movie log for clarity.
1. Added a list of save states to the movie log.
2. Added corresponding support functions for the save states.
3. Added double click to the list view to load a previous frame.
4. Added a context menu to the list view with insert and delete.
5. Fixed some issues with the green zone of valid state history.
6. Fixed an input bug that I had unwittingly created, as well as issues with the nes log format.
1. Hooked up Fast Forward, Fast Forward to End
2. Made a placeholder for Turbo Fast Forward.
3. Fixed rewind to not stomp on the previous frame with new input.
4. Fixed rewind to stop at the beginning of the movie instead of freaking out.
5. TAStudio now shows data from the most recent frame.
6. CommitFrame is called even if not recording so played back frames also show up in TAStudio.
7. Play mode only stops at the end of the movie if you tell it to. Your emulator normally continues to play with no input after the end of the movie.
8. TAStudio is now updated after a rewind (even though the rewind doesn't play a new frame).
9. Split the tools update into before and after updates.
10. Going into read-only mode adjusts the movie mode.
11. Implemented New, Open, Save, and Save As for TAStudio.
12. Fixed an issue where frames past the end of the log would default to the input from the last frame of the log.
13. Fixed a problem where you couldn't rewind to frame 0.
14. Fixed a scrolling issue in the TAStudio list view.
15. Fixed an issue with the TAStudio virtual NES controller not matching up with the log.
16. Fixed an issue where the NES reset button would get held in when rewinding.
17. Added/Modified a couple of button graphics.
--Gets worse as the scale increases.
--For x3, the box doesn't increase size, but the box still changes position. I think there might be a difference between the TargetZoomFactor and the actual screen size, so perhaps we should tie this to something else.
-Working on very small optimizations to the NES PPU with CorruptedSyntax...this is more fun, so we'll do this first.
--Eliminated an entire loop.
--Branched to two loops instead of branching for every iteration in one loop.
--Got rid of some redundant instructions using temporary variables.
--This may be completely premature, but I seem to have gained a few FPS from doing this. For me, I get 38-39 FPS where I'd previously get 33-34.
Moves calls to AVIStreamWrite() to a separate worker thread. They are where all of the cpu time for video compression is used, so can give a decent speedup. Could conceivably go slower on pathetic single core machines due to synchronization and copy overhead.
--If there is no controller parameter, then all of the buttons are returned as they are stored in the system, just like joypad.set(input) takes button names as is.
--If there is a controller parameter, all of the buttons for that controller are returned without the "PX ", just like joypad.set(input, controller) takes button names without the "PX " and assigns them to the matching buttons for that controller.
--No one approved this change, but seriously, this is common sense. I expect some "change denied" April Fool's stuff tomorrow...
-Implemented a blacklist for ButtonCount. By default, Lag, Pause, and Reset are blacklisted. I don't think any of these buttons should be tracked.
-adelikat has informed me that in FCEUX, savestates contained the button state of the frame on which you saved on. He claims that this is redundant because you could retrieve the state from the frame you're loading on, so BizHawk will not do this.
-As such, I just retrieved the input for the frame you're saving on before associating the data with the state.
--This essentially includes the missing info without having to depend on a movie frame to get the data from.
--In order for this to make sense, I made it so that the main joypad.get() doesn't run on a frame you're saving / loading on.
--Finally, in order to show the data from before the save frame when loading the data, I cached that data as well.
---The two above steps require collecting the data for a state once and using that until the frame is advanced or a state is loaded. Otherwise, I'd be able to increase the count significantly by saving multiple times.
-All this said and done, I think this script is perfect now, and is way more convenient to use than the FCEUX counterpart.
Notes:
-As mentioned before, it seems that the scripts are disabled when the console is reset / a movie begins playing. I don't like this to begin with, but worse yet, I noticed that this somehow makes the button data carry over from before the reset. Why is this?
-It seems that using gui.text in savestate.registersave/load causes the text to be written over the previous text instead of clearing the screen and then writing. Is this expected? How can I avoid overlapping text?
--TODO: Disallow Reset, Lag, and other non-buttons. Pause?
--If this works like adelikat says, my missing load state idea will be possible.
-Made the loading information show up on the console instead of the gui.
Note: Still need savestate.registersave/load!
ListView Refreshes When Loading A Session From Recent
When Clicking On New Lua Session Option, It Now Cleans The CurrentLuaSession String. This Will Prevent Some Unwanted Results When Saving A Session.
-As you'll recall, the script has 3 methods of keeping track of input:
--1. Tracking the button counts in real time. This took some minor adjustments, but seems to work fine.
--2. Parsing the button presses from a loaded, read-only TAS file when starting the script, if possible.
---This works well enough after a good amount of refactoring, but I only have it rigged to work for NES.
---As always, note that this method is very slow for big movies, which is why we only use it once.
--3. Caching the counts when saving a state and loading them when loading a state.
---savestate.registerload and savestate.registersave are not currently supported by BizHawk, so this is not functioning at all.
-I propose that a function called movie.getframe(frame) be added that gets status of all of the buttons, just like joypad.get(), for a given frame of a movie.
--This makes the would make method 2 trivial and fast.
--It would allow me to generalize the function for all platforms easily.
---Certainly there might be some discrepancies about which buttons should be disallowed, if any (Is Reset a button press?), but still.
--If this method could somehow work for non-readonly movies, then I'd be able to use the movie to get the counts when I load a state that doesn't have cached data.
---Trust me when I tell you that this would be immensely useful for minimum button TASing. The process would be seamless, and all of these methods combined would provide perfect accuracy while being fairly efficient and only using intensive routines when absolutely necessary.
Note: Earlier, I came up with the idea for a function that lets you set what frame of the movie you are on, which would be useful for endless TASes like we've already discussed, adelikat. Do you still think this is worth having?
-Line count: 583.
TODO: The one I really didn't want to deal with...Gameboy. Why did you have to make this a NESControllerTemplate instead of a GameboyControllerTemplate[]?
--As it'd be obnoxious to make CONTROLS a string, object dictionary and have casts all over the place, I just made a TI83Controls string array to match CONTROLS["TI-83"].
--Positioned the fields as well as I could.
--The config for ( and ) were switched. Fixed. Yet another example of redundant code failing! :)
-Line count: 741.
-Started merging TI-83 to Do:
--This is going to be difficult because the field names are not the same as the label names, meaning that I'm going to have to use a dictionary for TI-83, if not for all of the controls.
--I have to create a formula that calculates the proper row / column for a given field to be placed. Sounds like fun.
-Because I have been advised not to convert the objects to dictionaries, and because using the equivalent of typedef seems confusing if it isn't outright impossible, I had to implement switch statements to handle certain aspects on a platform to platform basis.
-These will end up being much bigger than I would have hoped, but the entire file will be much, much smaller.
TODO: Implement all of the other platforms using these functions.
Note: It seems that the Enabled checkbox doesn't do anything other than persist its state. I checked the latest release, and the same issue was there, so I didn't break it!
--Created CONTROLS constant which contains all of the controls in one dictionary.
--Shrunk DoNES significantly.
TODO:
-Shrink UpdateNES.
-Generalize both functions and apply to NES.
-Have all of the platform specific functions utilize these generalized functions.
-Combine all of the platforms.
while true do
joypad.set("Up", true)
local buttons = joypad.get()
local result = {}
for index, value in pairs(buttons) do
table.insert(result, index .. ": " .. tostring(value))
end
gui.text(0, 36, table.concat(result, "\n"))
emu.frameadvance()
end
For some bizarre reason, after a while, the ordering of the buttons goes from stable to chaotic, making it impossible to read the buttons pressed. adelikat says not to worry about this because order is meaningless in Lua. Still, this is very curious...
TODO: Set using a ClickyVirtualPadController and Global.StickyXORAdapter.SetSticky(Controller + " Up", false)...whatever that means.
-No info on the control bytes, so I'm not dealing with them right now.
-It seems like there's an extra byte for at the beginning of input for NES that doesn't exist for PCE.
--I think it might be the "1 byte for power-on and reset" that the docs refer to, though I'm not sure why this would exist for NES and not PCE...because NES supports control commands and PCE doesn't?
--Perhaps this will become more apparent if I write the importers for SMS, GG, GB, and GBA. I'll need access to a Linux machine to do these, though.
--FDS commands in ImportFMV.
--Bad ROM checksums in ImportText. TaoTao: There's nothing wrong with using warningMsg; it just is limited to showing the first warning message that occurs.
-ImportNMV
--Nintendulator's Four Score recording is seemingly broken.
TODO: ImportMCM clean-up / expansion, Intellivision research.
-Finished ImportVMV:
--I'm not sure what the following comment means: "For the other control bytes, if a key from 1P to 4P (whichever one) is entirely ON, the following 4 bytes becomes the controller data." I'm going to assume this is a bad translation that is the equivalent of my 4 controllers = 4 bytes comment.
--Nesmock has a block of code that seems to handle, or at least account for, commands (Lines 207 - 239 of virtuanes.hh). I don't do anything about this, but it doesn't seem like Nesmock does much of anything about it either. I'll ignore this for now.
TODO: ImportNMV, clean up ImportMCM, and perhaps support other platforms for .MCM, although everyone thinks it's a waste...I like writing importers! I'm afraid of writing cores!
-Made it so that .tas is appended to the file path instead of changing the extension to it.
-Added default emu/MovieOrigin comments to the importers that don't have explicit ones.
-ImportVMV header / added blank frames
-Moved the MnemonicsGenerator declarations outside of the loops.
TODO: Finish ImportVMV (I don't think the provided documentation explains how the input works...) and figure out if my re-record count is off by one or if TASVideos.org is.
This is (almost, bar some local resource hacks) enough to start the
emulator on Linux/Mono, load a ROM and watch the demo (input and
audio don't work yet).
-Fixed ImportFMV's movie title; before, I mistook it for the game name.
-Made "comment" and "SyncHack" constants.
-Moved the "ControllerDefinition"s outside of all of the loops.
-ImportGMV:
--Emulation Version => Movie Version.
--Added the PAL header.
--Made it so that the 6-button error is a warning; considering that the code already properly handles the controller properly and all that needs to be done is have Bizhawk actually support that kind of input, I don't feel there's a reason to go so far as to kill the conversion in this case.
--Reformatting.
---Notably, I added a player loop to simplify the frame data.
--It seems that 1937M uses a 6-button recording and 1731M has 2-player input...bizarre. Anyway, this means that ImportGMV should be good now.
TODO: ImportVMV, ImportNMV, ImportMCM, ImportSMV, Atari core? :)
-Fixed InputAdapters with regards to the Genesis 3-Button Controller. It previously did not have a flag placeholder.
Potential issues that I don't have the time to investigate right now:
-When importing 1937M, I get the error "6 button controllers are not supported." Is this a false positive?
-The result of importing 1731M seems sane, but has 2-player input. This run is classified as "One player in a multiplayer game". Is this input normal?
--Because there are way more bytes used to represent the other GUIDs than this one, I just appended -0000-0000-0000-000000000000 to this per zeromus' request.
-Got rid of the hex part of the BytesToString function. We apparently have BizHawk.Util.BytesToHexString.
-Converted BytesToString to r.ReadStringFixedAscii, an extension method. I've determined that extension methods are cool and that I should use them more often.
-Fixed some error and warning messages:
--Made it so that the first .FCM warning is shown instead of the last.
--Added an error for .FCM files that aren't version 2.
--Did the same for ImportVBM, but with version 1.
-Cleaned up comments / code throughout.
-Fixed the file format for GBx; it had an extra bar which made reading Player 1 impossible.
-Seemingly finished ImportVBM.
--The results seem same. I have no way of testing whether they sync up or not.
--As I can't actually handle additional controllers, I just skip the bytes for them.
--As I can't actually handle the miscellaneous buttons and commands (Ex. L, R, Reset), I just give warnings whenever they come up in the file.
TODO: ImportGMV, ImportVMV, ImportNMV, and maybe ImportSMV...I'm going to need a new assignment soon! :)
-Set the buttons to the opposite state when they are updated.
--Presumably, this is how this works.
-Read the delta bytes.
TODO: Figure out where in the world the writing of frames actually comes into play. Bisqwit gave me some insight on this.
-Set the buttons to the opposite state when they are updated.
--Presumably, this is how this works.
-Read the delta bytes.
TODO: Figure out where in the world the writing of frames actually comes into play.
-Added a FourScore header and applied it to ImportFile and ImportFCM.
--Not sure if there's any equivalent header for FMV/FCM.
-Seemingly have the update bytes being read properly.
TODO: Make ImportFCM actually utilize the update bytes to write frames.
-Added PAL handling to ImportText.
-Finished the header and metadata of ImportFCM.
TODO:
-Input handling for ImportFCM.
-Find out what the format for the FDS data is on FMV, as it occurs to me that I already handle FDS data in ImportText by giving warnings, so I might as well do the same thing in this case.
-Figure out whether or not I should be using "using" for the BinaryReader objects, as it seems like they do in fact have .Close() methods.
-There's "FDS data" stored in the frames of FDS recording. I have no idea how to handle this. If we do in fact support these features, they should be utilized in the TODO section provided.
-99M syncs with this...isn't this a problem? Wouldn't this imply that bizhawk is as inaccurate as Famtasia? I'm pretty sure this run didn't sync when I tried it on my now broken NESBot.
TODO: I guess I'll try to move on to ImportFCM now. Although I heard this is a difficult format to work with, my favorite console is the NES, and this'd be useful for console verification if the NESBot Lua script gets adapted for bizhawk, so I think I'll give it a shot.
-Added RemoveNull to get rid of the null characters in the author and game names for .MMV.
-Formatted the MD5 for .MMV.
TODO:
-Write ImportFMV. I think I understand how these formats work well enough to try this now.
-Realized that the the ImportMMV function probably still works, but that Grunt's Sonic run merely desyncs. If I move the second pause button one frame later, it will make it past the title screen.
TODO: Comment / clean / and understand ImportMMV before moving on to ImportFMV.
-Made it so that any of the exceptions thrown from the Import* functions get converted into a string and stored in errorMsg. Now I can investigate what's wrong with ImportFCM.
-Realized that there's already a function that decides which SMV function to import with (ImportSMV, duh), so now that's used for it. Outputs a movie with messed up headers except for the Re-record count, which works fine.
-Added format URLs for all of the movie formats except for SMV 1.52, which doesn't seem to have a documentation page yet.
--Moved the command message in ImportText to this.
-Converted ImportVBM to use a MnemonicsGenerator.
--This should work, but I can't test as I still don't know for sure as the import fails and displays "Not a valid VBM platform type."
--I iterated through the buttons using a list and left-shifting. I applied this method to ConvertMMV, which works.
TODO:
-Comment MovieImport.cs.
-Fix the exception that is thrown for Gameboy games.
-Get ImportVBM to actually work, scanning through the input to see if it seems sane.
-Figure out why pressing Pause on GameGear results in a "P" instead of a "p", and whether or not this is a factor in runs syncing.
--Note that I don't think that the calculator pad simulator is registering when I click 0, and that this doesn't seem to be related to any changes I made.
-Inadvertently fixed the seemingly broken Genesis 3-Button Controller mnemonics...the controllers weren't responding at all before. I guess refactoring and working with simplified code IS worth it. <_<
--That said, this is still really broken:
---Mnemonics don't show up while recording.
---Input goes past the frame length, and it's never labeled finished.
---Doesn't seem to sync at all.
---This exception:
---------------------------
Oh, no, a terrible thing happened!
System.Exception: unhandled opcode at pc=013648
at BizHawk.Emulation.CPUs.M68000.MC68000.ExecuteCycles(Int32 cycles) in C:\Users\Administrator\Repo\bizhawk\BizHawk.Emulation\CPUs\68000\MC68000.cs:line 147
at BizHawk.Emulation.Consoles.Sega.Genesis.FrameAdvance(Boolean render) in C:\Users\Administrator\Repo\bizhawk\BizHawk.Emulation\Consoles\Sega\Genesis\Genesis.cs:line 106
at BizHawk.MultiClient.MainForm.StepRunLoop_Core() in C:\Users\Administrator\Repo\bizhawk\BizHawk.MultiClient\MainForm.cs:line 1676
at BizHawk.MultiClient.MainForm.ProgramRunLoop() in C:\Users\Administrator\Repo\bizhawk\BizHawk.MultiClient\MainForm.cs:line 346
at BizHawk.MultiClient.Program.Main(String[] args) in C:\Users\Administrator\Repo\bizhawk\BizHawk.MultiClient\Program.cs:line 47
---------------------------
System.Exception: unhandled opcode at pc=013648
at BizHawk.Emulation.CPUs.M68000.MC68000.ExecuteCycles(Int32 cycles) in C:\Users\Administrator\Repo\bizhawk\BizHawk.Emulation\CPUs\68000\MC68000.cs:line 147
at BizHawk.Emulation.Consoles.Sega.Genesis.FrameAdvance(Boolean render) in C:\Users\Administrator\Repo\bizhawk\BizHawk.Emulation\Consoles\Sega\Genesis\Genesis.cs:line 106
at BizHawk.MultiClient.MainForm.StepRunLoop_Core() in C:\Users\Administrator\Repo\bizhawk\BizHawk.MultiClient\MainForm.cs:line 1676
at BizHawk.MultiClient.MainForm.ProgramRunLoop() in C:\Users\Administrator\Repo\bizhawk\BizHawk.MultiClient\MainForm.cs:line 346
at BizHawk.MultiClient.Program.Main(String[] args) in C:\Users\Administrator\Repo\bizhawk\BizHawk.MultiClient\Program.cs:line 47
---------------------------
OK
---------------------------
--I don't think I broke anything...if anything, I fixed it slightly so that input is at least recognized in some way.
--Question: Is Genesis going to be properly supported by release time? If so, I might hold off a Genesis TAS until this is done. I hate Gens.
-Moved BUTTONS, COMMANDS, and new variable PLAYERS, which indicates how many players are for a given system, to Global.cs.
--If there's a better place for this, please let me know.
--That said, if there are places in the code that refer to the mnemonics of button names of a given system, we should definitely apply these variables for easier modification. Please let me know where these places might be.
-Fixed ImportText(). It now only reads as many controllers as the given system supports.
TODO:
-Merge the TI-83 stuff.
-Mnemonic header.
-Comment!
-Fix the TI-83 mnemonics with the IRCs blessings.
-Port the new mnemonics to the wiki.
-Fix the importers.
--I don't think ImportMMV handles the Pause and Reset commands (Or buttons, I don't even know) covert.
-Made other commands lowercase.
-Added more mnemonics to the table.
-Added a command table. The writing of headers, as currently inconsistent, will probably be done manually, but it will still reference the table for easy modification.
TODO:
-Create a mnemonic header using the tables (Format now seemingly agreed upon is "Mnemonic |UDLRsSBA|").
-Generate button handling using the table, sandwiching this simplified code with the command handlers.
-Fix the TI-83 mnemonics (It has at least two redundancies: 1 and 2).
-Port mnemonics table to wiki page.
-Convert the remainder of the importers, working or not, from the string building method to the mnemonic generating one.
-Start working on more importers!
-Realized that FixMnemonic is useless as GetControllersAsMnemonic() + WriteMovie() = Fixed.
-Finished the NES / PCE importers, now without string builders (Thanks zeromus)!
-Converted ImportMMV to this same method.
TODO:
-Decide how's the best way to handle the mnemonic header and implement it. Apparently, anything other than a predefined header and a | is considered as a comment, so I might do something like:
comment Mnemonic format:
[0|UDLRsSBA]
-Realized that FixMnemonic is useless as GetControllersAsMnemonic() + WriteMovie() = Fixed.
-Finished the NES / PCE importers, now without string builders (Thanks zeromus)!
-Converted ImportMMV to this same method.
TODO:
-Decide how's the best way to handle the mnemonic header and implement it. Apparently, anything other than a predefined header and a | is considered as a comment, so I might do something like:
comment Mnemonic format:
[0|UDLRsSBA]
adelikat
