Mirrors/sf2000
2
0
Fork 0
mirror of https://github.com/vonmillhausen/sf2000.git synced 2024-11-04 17:15:11 +01:00
Code Issues Packages Projects Releases Wiki Activity
adf653fb7d
sf2000/tools/saveStateTool.htm

680 lines
56 KiB
HTML
Raw Normal View History

New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>Data Frog SF2000 Save State Tool</title>
<meta name="viewport" content="width=device-width">
Moved tool CSS to shared CSS file Just for future flexibility, moved the CSS from each individual tool to a shared CSS library
2023-06-26 14:19:47 +02:00
<link rel="stylesheet" href="tools.css">
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
</head>
<body>
<h1>Data Frog SF2000 Save State Tool</h1>
<p>The SF2000 supports save states for games, but it bundles the save state data into a custom format including a thumbnail and metadata; this bundle can't be directly used as save state data for other emulator platforms (e.g., Retroarch). This tool allows you to extract raw save-state data and thumbnails from SF2000 save-state bundles, in case you want to use them with the same emulator on another device; it also allows you to take save states from another device, and convert them to a format the SF2000 can parse. Please note this tool is provided as-is; make sure you have backups of anything you care about before potentially replacing any files on your SF2000's microSD card! 🙂</p>
<p>This tool makes use of the <a href="https://github.com/nodeca/pako">pako</a> JavaScript library.</p>
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
<div id="initialWarning"></div>
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
<hr>
<div id="steps">
<section id="modeSection">
<h2>Step 1: Select Operating Mode</h2>
<p>This tool can operate in two main modes - you can use it to convert save states <em>from</em> the SF2000 format <em>to</em> raw save-state data (and optionally download the thumbnail), or you can use it to convert raw save state data <em>from</em> another emulator <em>to</em> the SF2000 format. Choose the mode you want, and follow the next instruction that appears.</p>
<div class="controlContainer">
<label class="control"><input type="radio" id="radioFrom" name="toolMode" value="fromSF2000" autocomplete="off"> Convert <em>from</em> SF2000</label><br>
<label class="control"><input type="radio" id="radioTo" name="toolMode" value="toSF2000" autocomplete="off"> Convert <em>to</em> SF2000</label>
</div>
</section>
</div>
<script src="pako.js"></script>
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
<script src="tools.js"></script>
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
<script>
// Global Variables
// ================
var previewCanvasData; // Binary data used for drawing to our preview canvas
var saveFileName; // Name of the save state file chosen by the user
var downloadName; // Name we're going to give any download being sent to the user
var saveData; // Binary data of a save state file
var thumbData; // Binary data of a save state thumbnail
var thumbWidth; // Integer width of a save state thumbnail
var thumbHeight; // Integer height of a save state thumbnail
var romFileGood; // Boolean indicating if a chosen save state file appears to be binary or not
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
// Display our initial warning note...
setMessage("warning", "initialWarning", "<strong><em>NOTE:</em></strong> This tool will <em>not</em> convert save states from one emulator's format to another; it <em>only</em> gives you either the raw save state data the SF2000 generated (when converting <em>from</em> the SF2000), or allows you to take any random file and shove it into the container format the SF2000 uses for save states (when converting <em>to</em> the SF2000)… whether or not the SF2000 is able to understand the file you give it is up to the SF2000, not to me! If you're converting save states to the SF2000, and the SF2000 doesn't work with whatever kind of save state you provided, there's nothing I can do about that.<br><br>You can <a href=\"https://vonmillhausen.github.io/sf2000/#emulators\" target=\"_blank\" rel=\"noreferrer noopener\">find a reference to all the specific emulators and versions used by the SF2000 here</a>; you'll probably only have success if you're using at least the same emulator, if not also the same version. Also, to have any chance of success, you must be using the exact same ROM on both devices, and make sure save state compression is turned off if your save state is coming from Retroarch!");
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
// When the tool loads, add some event watchers for when the Step 1 radio
// buttons change; and depending on which mode the user selects, begin
// rewriting the rest of the page...
var modes = document.getElementsByName("toolMode");
for (var i = 0; i < modes.length; i++) {
modes[i].addEventListener("change", function() {
// Clear out any HTML that might already exist after Step 1, just so
// things are nice and clean for Step 2 to load into...
while(document.getElementById("modeSection").nextSibling) {
document.getElementById("modeSection").nextSibling.remove();
}
// Add the appropriate Step 2 depending on what was selected...
if (this.value == "fromSF2000") {
setupStepTwo_From();
}
else if (this.value == "toSF2000") {
setupStepTwo_To();
}
});
}
// This function sets up the HTML for "Convert from SF2000 > Step 2", selecting
// a save state file from the SF2000's microSD card that the user wants to
// convert to raw save state data and/or a thumbnail...
function setupStepTwo_From() {
// Create the new section, add our heading and our instruction paragraph...
var html = "<section id=\"selectSF2000File\"><h2>Step 2: Select SF2000 Save State File</h2><p>Select the SF2000 save state file you want to convert from. The save states are usually stored in the <code>save</code> subfolder where the ROM for the game is located. There can be up to four saves states per game, with the extensions <code>.sa0</code>, <code>.sa1</code>, <code>.sa2</code> and <code>.sa3</code> respectively.</p><div id=\"step2Messages\"></div>";
// Add our file chooser...
html += "<div class=\"controlContainer\"><label class=\"control\"><input id=\"inputSAFile\" type=\"file\" accept=\".sa0,.sa1,.sa2,.sa3,.skp,application/octet-stream\"></label></div>";
// Close off our section...
html += "</section>";
// Finally, add a <hr> separator after the last step, and append the new step...
document.getElementById("steps").insertAdjacentHTML("beforeend", "<hr>");
document.getElementById("steps").insertAdjacentHTML("beforeend", html);
// Attach our event handler to our new file input control...
var sf2000SaveInput = document.getElementById("inputSAFile");
sf2000SaveInput.addEventListener("change", function() {
// The user has chosen a new file; it should be a binary blob we can try
// to interpret as a save state file. First let's clear any old messages...
document.getElementById("step2Messages").innerHTML = "";
// And also remove any old HTML after the current section...
while(document.getElementById("selectSF2000File").nextSibling) {
document.getElementById("selectSF2000File").nextSibling.remove();
}
// Now let's read in our file data as a binary stream...
var frSave = new FileReader();
saveFileName = event.target.files[0].name;
frSave.readAsArrayBuffer(event.target.files[0]);
frSave.onload = function(event) {
// Let's run the file's data through our validation function; if the
// function returns true, then the file was a valid SF2000 save
// state file, and our global variables have been updated with the
// save and thumbnail data... otherwise, it returns false and we let
// the user know the file didn't appear to be valid...
if (validateSave(new Uint8Array(event.target.result))) {
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
// Great, the user selected a valid SF2000 format save state file!
// On to Step 3!
setupStepThree_From();
}
else {
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
// Whoops, the file doesn't looke like it was an SF2000 save state file.
// Let the user know and return...
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
setMessage("error", "step2Messages", "ERROR: The selected file does not appear to be a valid SF2000 save state file.");
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
return;
}
}
});
}
// This function sets up the HTML for "Convert to SF2000 > Step 2", selecting
// the non-SF2000 save state file the user wants to convert to an SF2000 save
// state bundle...
function setupStepTwo_To() {
// Start our new section, add our header and our instructions...
var html = "<section id=\"selectStateFile\"><h2>Step 2: Save State File</h2><p>Select the save state file from your non-SF2000 emulator that you want to convert to an SF2000-compatible save state bundle.</p><div id=\"step2Messages\"></div>";
// Add our file chooser...
html += "<div class=\"controlContainer\"><label class=\"control\"><input id=\"inputStateFile\" type=\"file\"></label></div>";
// Close our section...
html += "</section>";
// Finally, add a <hr> separator after the last step, and append the new step...
document.getElementById("steps").insertAdjacentHTML("beforeend", "<hr>");
document.getElementById("steps").insertAdjacentHTML("beforeend", html);
// Attach our event handler to our new file input control...
var userFileInput = document.getElementById("inputStateFile");
userFileInput.addEventListener("change", function() {
// First let's clear any old messages...
document.getElementById("step2Messages").innerHTML = "";
// And also remove any old HTML after the current section...
while(document.getElementById("selectStateFile").nextSibling) {
document.getElementById("selectStateFile").nextSibling.remove();
}
// Now let's read in the file...
var frImage = new FileReader();
frImage.readAsDataURL(event.target.files[0]);
frImage.onload = function(event) {
// The file is loaded; let's check to make sure we got a binary file (can't
// really do much more validation than that, alas)...
if (!event.target.result.includes("application/octet-stream")) {
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
// Whoops! Doesn't look like the user provided a binary file, so can't be
// a save state!
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
setMessage("error", "step2Messages", "ERROR: The selected file does not appear to be a binary file, and therefore can't be a save state file; please make sure you're selecting a valid emulator save state file.");
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
return;
}
// If we're here then it was a binary file; read the data into our global
// saveData buffer...
var base64Data = event.target.result.substring(event.target.result.indexOf(",") + 1);
var binaryData = atob(base64Data);
saveData = new Uint8Array(binaryData.length);
for (var i = 0; i < binaryData.length; i++) {
saveData[i] = binaryData.charCodeAt(i);
}
Update saveStateTool.htm Added some functionality to search for and strip Retroarch save state headers if they're found in the input data when converting to SF2000 format. See Javascript comments on function `stripRetroarchHeaders` for more details
2023-06-21 23:36:58 +02:00
// Let's check the provided data for Retroarch's save-state headers, and
// strip them out if we find them...
saveData = stripRetroarchHeaders(saveData);
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
// On to Step 3!
setupStepThree_To();
}
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
});
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
}
// This function sets up the HTML for "Convert from SF2000 > Step 2 > Step 3"...
function setupStepThree_From() {
// In this section, we'll be presenting the user with the thumbnail of
// their save state, and a download button for downloading the save
// state data itself. Let's start building our HTML...
var html = "<section id=\"sf2000StateDownload\"><h2>Step 3: Download Save State Data</h2><p>Below you'll find the thumbnail for your chosen save state file, as well as a download button which will let you download the raw save state data for use with other emulators/devices. If you want to save the thumbnail as well, just right-click or tap-and-hold on it like any other image, and save it that way.</p>";
// Next, we'll add the image preview...
html += "<div class=\"controlContainer\"><div class=\"control\"><canvas id=\"thumbnailPreview\"></canvas></div></div>";
// ... and the Download button...
html += "<div class=\"controlContainer\"><div class=\"control\"><input id=\"saveStateDownload\" type=\"button\" value=\"Download\"></div></div>";
// ... and lastly we'll close off our section...
html += "</section>";
// Add a <hr> separator after the previous step, and append the new step...
document.getElementById("steps").insertAdjacentHTML("beforeend", "<hr>");
document.getElementById("steps").insertAdjacentHTML("beforeend", html);
// Now, add our interactivity by attaching our event handler to the download
// button...
var downloadButton = document.getElementById("saveStateDownload");
downloadButton.addEventListener("click", function() {
// Before we kick-off our download function, let's determine the file
// name for the download. We'll default to just adding ".state" to the
// end, but we'll check specifically for the SF2000 double-extension
// naming convention (e.g., "Game.zgb.sa0"), and in that case we'll
// strip off both extensions and *then* add .state (Retroarch save
// state naming convention)...
downloadName = saveFileName + ".state";
var match = saveFileName.match(/(.+)\.([^.]+)\.([^.]+)/);
if (match) {
downloadName = match[1] + ".state";
}
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
downloadToBrowser(saveData, "application/octet-stream", downloadName);
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
});
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
// The last thing to do here in Step 3 is to perform our initial image
// data conversion and preview rendering... so let's do it!
convertFromSF2000AndRender();
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
}
// This function sets up the HTML for "Convert to SF2000 > Step 2 > Step 3"...
function setupStepThree_To() {
// In this section, we'll be rendering the HTML for some controls - the
// user needs to select the ROM file their new save state is for (so we
// can name the save state file correctly), and choose whether their new
// save state should be stored in slot 1, 2, 3 or 4 (again, required for
// the file name). Let's start by creating our new section, and add its
// heading and instruction paragraph...
html = "<section id=\"processUserFile\"><h2>Step 3: Select Game ROM And Slot Number</h2><p>To name your new SF2000 save state properly, this tool needs to know two things - the name of the game ROM file the save state is for, and which save slot (1, 2, 3 or 4) the save state should take up. Use the controls below to select your game ROM file from your SF2000's microSD card, and to choose which save slot you want.</p><p>When you've chosen a ROM file and a slot number, the Download button will become enabled, and can be used to download your new save state file. Put it in the <code>save</code> subfolder along-side wherever your ROM file is stored on the SF2000's microSD card (e.g., if your ROM file is <code>sd:/ROMS/Apotris.gba</code>, and you chose save slot 1, you'd put the resulting save state in <code>sd:/ROMS/save/Apotris.gba.sa0</code>).</p><p>The one special case is with arcade games; the ROM you need to select is one of the ones in the <code>sd:/ARCADE/bin/</code> folder, and the resulting save state bundle goes into <code>sd:/ARCADE/save/</code>. As an example, if you wanted to transfer a save state to the SF2000 for the game \"Metal Slug\" in slot 3, you'd select <code>sd:/ARCADE/bin/mslug.zip</code> and Slot 3, and the final location to put the save state would be <code>sd:/ARCADE/save/mslug.zip.sa2</code> - I hope that makes sense! You can <a href=\"https://vonmillhausen.github.io/sf2000/arcade/DataFrog_SF2000_FBA.html\" target=\"_blank\" rel=\"noreferrer noopener\">find a list of all potential arcade zip-file names and the full name of the game they represent here</a>, if it helps - the first column (\"rom\") is the name of the zip-file without the <code>.zip</code> part, and the second column (\"fullname\") is the full name of the game/romset.</p><div id=\"step3Messages\"></div>";
// Now let's add our controls (file browser for the game ROM, and four
// radio button inputs for the save state slot number); we'll group them
// in one of our control containers for neatness...
html += "<div class=\"controlContainer\">";
// ROM file browser...
html += "<div class=\"control\"><label>Select game ROM: <input id=\"inputROMFile\" type=\"file\"></label></div>";
// Save state slot number...
html += "<div id=\"slotSelector\" class=\"control\"><label><input type=\"radio\" name=\"saveSlot\" value=\"0\"> Save Slot 1</label><label><input type=\"radio\" name=\"saveSlot\" value=\"1\"> Save Slot 2</label><label><input type=\"radio\" name=\"saveSlot\" value=\"2\"> Save Slot 3</label><label><input type=\"radio\" name=\"saveSlot\" value=\"3\"> Save Slot 4</label></div>";
html += "</div>";
// ... and our Download button...
html += "<div class=\"controlContainer\"><div class=\"control\"><input id=\"saveStateDownload\" type=\"button\" value=\"Download\" disabled></div></div>";
// ... and lastly we'll close off our section...
html += "</section>";
// Add a <hr> separator after the previous step, and append the new step...
document.getElementById("steps").insertAdjacentHTML("beforeend", "<hr>");
document.getElementById("steps").insertAdjacentHTML("beforeend", html);
// Now we'll attach event listeners for all of the interactive elements in
// this step. Mostly this will just be for storing the provided details;
// we'll also call a little helper function for each one which'll determine
// if the Download button should be enabled or not...
// Let's start with the ROM file select...
var romFileInput = document.getElementById("inputROMFile");
romFileInput.addEventListener("change", function() {
// First let's clear any old messages...
document.getElementById("step3Messages").innerHTML = "";
// We're using a cheeky global variable to store whether this event
// listener thinks the chosen file is "good" (i.e., a binary file);
// a separate function then uses this information as part of a check
// to determine if the Download button should be enabled or not. We
// default to "false", and only set to true if the newly chosen file
// appears to be a binary file...
romFileGood = false;
// Now let's read in the file; we don't really care about its contents
// per-se (we only need it for its file name), but we may as well confirm
// it's a binary file while we're here...
var frImage = new FileReader();
saveFileName = event.target.files[0].name;
frImage.readAsDataURL(event.target.files[0]);
frImage.onload = function(event) {
// Check to make sure it's binary...
if (!event.target.result.includes("application/octet-stream")) {
// It's not! Our romFileGood variable is already set to false, so
// run our Download button state-checking function to make sure
// the button is disabled...
userStateDownloadCheck();
// Display a message to the user and return...
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
setMessage("error", "step3Messages", "ERROR: The selected file does not appear to be a binary file, and therefore can't be a game ROM file; please make sure you're selecting a valid game ROM file.");
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
return;
}
else {
// The file appears to be binary, at least! Update our romFileGood
// global to true, and run our Download button state-checking
// function (button may still be disabled if a save state slot
// hasn't been selected)...
romFileGood = true;
userStateDownloadCheck();
}
}
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
});
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
// Next up, our radio buttons...
var slots = document.getElementsByName("saveSlot");
for (var i = 0; i < slots.length; i++) {
slots[i].addEventListener("change", function() {
// The only thing we'll do here is run our Download button
// state-checking function; we'll pull the actual data from the
// selected radio button at run time during the download process...
userStateDownloadCheck();
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
});
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
}
// And last but not least, our Download button...
var dButton = document.getElementById("saveStateDownload");
dButton.addEventListener("click", function() {
// We're actually going to be doing quite a bit here - we'll assemble
// the binary blob of the new save state bundle before handing it off
// to our download function. First, let's try zlib-deflating the user's
// save state data...
var compressedSaveState = compressZlib(saveData);
if (!(compressedSaveState instanceof Uint8Array)) {
// Oh! We failed to compress the save state data using the pako
// library for some reason... display a message to the user and
// return...
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
setMessage("error", "step3Messages", "ERROR: Failed to compress the chosen save state file's data!");
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
return;
}
// We also need to check our compressed data is of an appropriate size...
if (compressedSaveState.length < 0 || compressedSaveState.length > 4294967295) {
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
setMessage("error", "step3Messages", "ERROR: Compressed save state data is not valid (either it was 0 bytes in length, or was larger than 4 GB)!");
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
return false;
}
// Great! We have enough data now to start assembling our final binary
// blob; we'll just re-use our saveData global for convenience...
saveData = new Uint8Array(4 + compressedSaveState.length + 4 + 4 + 4 + 15979 + 4);
// We'll also use a little "offset" variable, to help keep track of
// where we are in the array as we go...
var offset = 0;
// The first four bytes are a little-endian Uint32 version of our
// compressed save state data's length...
saveData[offset + 0] = compressedSaveState.length & 0xFF;
saveData[offset + 1] = (compressedSaveState.length >> 8) & 0xFF;
saveData[offset + 2] = (compressedSaveState.length >> 16) & 0xFF;
saveData[offset + 3] = (compressedSaveState.length >> 24) & 0xFF;
offset += 4;
// The next sequence of bytes are all of our compressed save state data,
// so let's just copy it in...
for (var i = 0; i < compressedSaveState.length; i++) {
saveData[offset] = compressedSaveState[i];
offset += 1;
}
// For reasons, we'll need our current offset a little later on, so
// let's make a note of it now...
var thumbnailStart = offset;
// The next three sets of four bytes are little-endian Uint32 versions
// of our thumbnail image's width, height and compressed data length;
// I've got all of those numbers pre-calculated, so I'll just add them
// in...
// Width...
saveData[offset + 0] = 64;
saveData[offset + 1] = 1;
saveData[offset + 2] = 0;
saveData[offset + 3] = 0;
offset += 4;
// Height...
saveData[offset + 0] = 240;
saveData[offset + 1] = 0;
saveData[offset + 2] = 0;
saveData[offset + 3] = 0;
offset += 4;
// Length...
saveData[offset + 0] = 107;
saveData[offset + 1] = 62;
saveData[offset + 2] = 0;
saveData[offset + 3] = 0;
offset += 4;
// Next comes the zlib compressed thumbnail data itself; I've already
// got that too :)
thumbData = atob("eJztnU18E9e5/3sDAfOS+2FJd7CDGzA2ecO3XcS8WjbJDV5d+26KWWGagGXSBpsusHgxliGfD/YqVjdFWdlOAthpm+AuMDbGb6SLsLt012zuLQmkSZtu/ud7NM9wNJoZjWRZcu//8FuMNBrJsuZrfnp+5zlndp3ddXbX+fyqUTq1QnRSKcp7Lkhnw/Wgu7zK937+T8nyZ/lbySr92S6PQn6nByHnfnGFKOw9mqo4HxG0pPdeaY4sf/93+Qs4dzWOKu21YR5cch8ukNPl1nIzsSJk+bP8rSQVee5glW0YLyY3XpWUowhcoQcB573SvluI9z74J+M073u3/FWcvf+v+PMwVHKn7Ffy3u535HdM2L4QHy4JwxH5LJfKxQSqcSS3T3kk++SYksnyZ/mrJH8+HIZpOeuSZfXjiGxFcsdOQ9775v4y+O/yk7k8ynn/lj/LXyX4WwpT/WXUcjMbwqTI5O+qksnZ1c5nMhnK4bYAvpbr3J9U8vprseK1luTJlj/LX4X5i6Ll8NsoXlwuD/Zy5Oeh7L+iNM6/0fHRN068cYL7bPkbeW/xvUWTQxHHXDnhSN0Oev1C/He52Cy7LH+WvwqqICrK6bcRvbhUObYw+NKHL3342vRr00E+Cj88/v3E9xNwJ7o5eHPwJ1/95Kssfh2f5vF3RzPiPcvj+RgrNWcnHeW4qHmOvfdln3lsgBebGY7lz/L3z8Bf0PmQ8bJKqaTjc2czXhvkcyZb8AdHVzKumeWR4rWwhwVvPPZMHf0d/f949I9HwqM8n9s3+m/0//Doh0dnFs8sfjf+3Tj7/Hzaz5fLwWVFZfmz/FVQoRRE8MJPlqBS+HBkRtXvyvmEE57rPbdSX/AY/JFHefkTL8V/4YnjRNwX/oQ96g2ew2PUK6c/PP0hDPrxB8/8TOFvOXjL8t5i/2eI4MPixZY/y99K5897npY0tia1QVjN4Kkf8qloH3Z48/rnZw8/e/jdxHcTOgfpvprzOPrHn//xZ+qJwycOuyxJjsI++OM15PNC+Db88bh4MLfxapjbcGyD69FyjGQy7P/Jn37yJz4b+VleP14OHleELH+WvwoqkKNl8NuSe7Hxnv0Y5DydHj09qv1WnUfOLRkIDHjHysz6AkZ5nsuJwR/39yzuWfx0/NNxeZyt5C9mJvM09TSF98Lrk9STFMfws3lvwp/4Odm1mU/DNO/hgfPdYCnMublL8f+z+KsEeYzlz/JXSf7kXBX8s4sjpmCuCvLfs7mey/kXv+Vccxyc3Bi8MZhVKxh5CTwgPJXn4p/wIVxxm3rB5A++eF3ZBy+67lD/YJ7ncB+2xds5jvcIk+wz2aVe4Xhvnm32dy2FyRUjy5/lr4KKwtRyeW4pPNhkknMiW9HLH76s82TteZ1vaL7OPDyjaxB9ptU+joM1na8owQznHmbwWR6jRpDjTU7c+2or/CLxT+GTjJrbv3/4+4fwaHq0mVvL3wT7YDCrX8HDX5Tzq/vmS+27fj5cZBZj+bP8rRj+KuW3efjK573CGqzglV5PxfOkXkDwBF94MPmIZMhSF6CN6JhHJ5Yo9Rr8PcC3/Jwng08GeS/CKBImdU3k1CRsYZr3rGshdV9YfPBP7MOWP8tfxfkLOPfl8t1C/ddksfps9VnJTuQ7Pr5n8vfy6Muj8MV5Er/lPucYH9a1iOGrwqnJHlk1P5tjb6ZupmAEjhG32cdjHAMfwtvhE8/0ho84lvfB3wfvj9fQ3qv+uewpSb4j7/ulX7/0a/HlwLNLPi5zKZfbg/P4cJAHW/4sfxXnbxl9t9i6Ip//esfMOL94757pPdOS8ZoMShYifPHamjEfn+W5T9NP059OfDpB1ox/i6gfqF/4WV7xmHks7wWu4BO2zJ9hcomv8lzG4JCZF0lGzfeE96bfm+Y27HEc7OseiTAGCxAZtWy9t819Jfdfy5/lr1L8BTATphuOzNteLaf/6rxcbeGM8853eljkHHJOhAWTPzxZj3FxXh2vFf64T37MOf7s0WePJCfWcu7zetJ3IJnyy464zT54/X7q+yn4zHoNQzyfn2X6vAhGpbbw9iGI/8Iy/NLLJf3+D8Lqj2LGFpbJhy1/lr8Vx1+BvluO+iLLf1GA/+JvnFN4k+/lfH/ncfc7vDm2pmSe747BjkF4EF/V/ql4g9N3x98d57UeJB4k3FokQr5i+ivP5TVk/E2/V0eSCfE7ep9njgtKPcJj3MZ3+b1g7veLv1/Myqad7yRL8V8/CT/m/VJ5seXP8ldR/iKyleOwg/n1iUfuviUyao61SYYi2ayMg+G3evy++2q3yR/Co8Vb2Zo9UrxuVl7S+UzeXDund8ErI8+BT+2jqZva501/hnt81TsGh6RfAv+FQX5Pfme+c0h/f76xuYqsoxzRgy1/lr+K8lcG3y3Wg08a8htzM3NZ2DH75b2eK9y5PquEJ0qGAR9yXBBvbjXQbcioEUJ5NDiEIx6HOcl35H3xfry1iZ4TqnyXmoPfm/ct/RNXDME1nu6OzRXoxfm813u7FJmM5c/yV1H+CvXeCL4b1Y+DvDgfk7uQkUHzuUvmLHOKrqDOTIaL54nXSV8V70d4c4lRz7nqI3f+pXN7V/+urPfg9xxfSQ+/h0nqIKmlhEXpURVx/4eHPzz86Vc//cqdq+Rh7x+PMoJBv7G5Snuvnwdb/ix/FeWvTL5biP9K5hLaa0/vgZKwwedu9h0cViL/oK5wx8OU1/H6+oyqx032wriBtZOpk6mP0x+nvx77euzxyOORj5Qejz3Wt9HHSjXjNePcfif1Tqp6sHpwMbGYyPJsj09n+TK1RX9Nv/l+YYrfLSvT6X7g/l3Jc1nTAzb53ag14JPMJ29/QgTvDfJhc39Jvv9Z/ix/FeAvHy+l8N1Q//X4cJbPKsaoK+AsizzD/8QDYc31XKfWgEnJWZ6kn6TNusL0VT+dGjw1+En6kzRMaa7GslUzkdEpj9i3a3yXPv4vSh+lP0ovJheTXj8373tZ5Hc2vy/wu5j9W+73BeW7r/3htT/I76l7bI8d1vPc8WlyapO/svlviAd7+7Asf5a/SvIX5oOl9t4o/mtmLZyHXz3+1WP9OQoZytOychh1X+oNYUv3ETjnT8bg8Fu/GsNkgdufpD5JxSfiEzD3lxElxZCwJNzB2Y2pG1M3J25OdIx3jL8z+M5gf3d/d1NnRjv7d/bjw7wGLPI6b6ffTl9JXEmE1SXiq5Ij8d7NvgV5TDjUvqv45HPDl6X2gEH+z4BBcmp6dKP6YZgPB2UxS8lgLH+Wv0ryF+q9JfDcqB7sxyA8UFPwOZJPCIOmH0sNwvniuaZvkbvk+G0iV3i367U4qGwdL901sUtvT02dmoK7jomOiZrRmtH1J9af2L91/9bJTR5tntzM/mR3sls8+S9jGe0c3DnozXXMfMf0Y1jjM5NxQnIZ6gvhj/PH78nfG8zxGJ+V1GFkNjlnfLn7sfJkL14PtvxZ/irJXzm9N5//5niq45vCFX1LZu5s5szUC8Ie+TKPmZ4bdK5vpG6k4MnNUoz6QmqKjqmOKeGIY5u6m7pX/XjVj3s2ZQRvaPrI9JH9tftr72y+s3lyy+QWHluzd81eeV1dj4x8NLJjcMdgUNbtzalhkPdLdiTjhnweOo9R4jGXQaeXP6cfwVEx3huUxXgfL/X3P8uf5a8c/K0E7xX/Fd+V4/EPahDG6clT+ez1Wj3KV13+1HniGOlnkrk7rucaHmt6LvnN7vHd2mfNPAWfhTHts0raO1X9wH5uzyfnk7CX2JTQ7B2oPVBb1VrVeqDuQN0FpenYdEzva65qFhYPNh5sfHvkbTezZrsztTMV5MNZfyPOmiC63nB6ZfV3C2N8TvrQyK75vbPWMA/gr5IebPmz/K0U/pbsu0FZcoG9BcKezJ9EfJdGkq/KPEeOE292e0mV6JnP8VxPrcE5JWOpnajNcOfUGrscie/CG8zsSO9Is+VYMpT92/dv165b1VO1evvq7RdjF2Mwd+/IvSMNbQ1tMaUL9Y5iF2JwiTc3JhuTO1I7UrwG/OnXVvdDfdinHpG/Q8Tfnfiw9KlSe5g9qboXS30OekW
for (var i = 0; i < thumbData.length; i++) {
saveData[offset] = thumbData.charCodeAt(i);
offset += 1;
}
// And lastly, our final 4 bytes are a little-endian Uint32 version of
// the offset within the file where the thumbnail stuff starts...
saveData[offset + 0] = thumbnailStart & 0xFF;
saveData[offset + 1] = (thumbnailStart >> 8) & 0xFF;
saveData[offset + 2] = (thumbnailStart >> 16) & 0xFF;
saveData[offset + 3] = (thumbnailStart >> 24) & 0xFF;
offset += 4;
// Just as a final sanity check, offset should now be equal to
// saveData.length... let's confirm!
if (offset !== saveData.length) {
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
setMessage("error", "step3Messages", "ERROR: Inconsistent data length when building save state bundle!");
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
return false;
}
// Before we kick-off our download function, let's determine the file
// name for the download. The SF2000 uses a slightly odd naming
// convention for its save state files. If the ROM is in the "USER"
// folder on the microSD card, then the extension of the ROM file
// gets capitalised in the save state name (e.g., "Apotris.sfc" would
// become "Apotris.SFC.sa0")... but this *only* happens in the "USER"
// folder from what I can tell. There's no way for me to know what
// folder the user's selected ROM is stored in, so I'm not going to
// bother matching that same convention here (and the SF2000 doesn't
// seem to care about the capitalisation when it comes to loading
// save states)... just thought I'd mention it! So all we're going to
// do here is just stick the appropriate ".sa#" extension on the end
// of whatever's store in saveFileName...
downloadName = saveFileName + ".sa" + document.querySelector('input[name="saveSlot"]:checked').value;
// Right, that should be everything we need... to the Downloadmobile!
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
downloadToBrowser(saveData, "application/octet-stream", downloadName);
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
});
}
// This function takes in a Uint8Array object, and attempts to inflate it using
// the pako library; returns a Uint8Array object containing the inflated data
// on success, or null on failure...
function decompressZlib(data) {
if (!(data instanceof Uint8Array)) {
return null;
}
try {
let decompressed = pako.inflate(data);
return decompressed;
} catch (error) {
return null;
}
}
// This function takes in a Uint8Array object, and attempts to deflate it
// using the pako library; returns a Uint8Array object containing the defalated
// data on success, or null on failure...
function compressZlib(data) {
if (!(data instanceof Uint8Array)) {
return null;
}
try {
let compressed = pako.deflate(data);
return compressed;
} catch (error) {
return null;
}
}
// This function validates that a provided Uint8Array object matches the format
// of an SF2000 save state file, and assigns the state data, thumbnail data and
// thumbnail dimensions to our global storage variables. The function returns
// true when successfully processing the array, or false otherwise...
function validateSave(data) {
// First check if data is a Uint8Array object...
if (!(data instanceof Uint8Array)) {
return false;
}
// Check if data has at least 20 bytes...
if (data.length < 20) {
return false;
}
// Read the first four bytes as a little-endian number and store it in saveLength...
let saveLength = data[0] + (data[1] << 8) + (data[2] << 16) + (data[3] << 24);
// Check if saveLength is positive and does not exceed the remaining bytes...
if (saveLength <= 0 || saveLength > data.length - 16) {
return false;
}
// Check if the next two bytes are [120, 156] (zlib header used by SF2000)...
if (data[4] !== 120 || data[5] !== 156) {
return false;
}
// Attempt to inflate the zlib data and store it in saveData...
saveData = decompressZlib(data.slice(4, 4 + saveLength));
if (!(saveData instanceof Uint8Array)) {
return false;
}
// Read the next four bytes as a little-endian number and store it in thumbWidth...
thumbWidth = data[4 + saveLength] + (data[5 + saveLength] << 8) + (data[6 + saveLength] << 16) + (data[7 + saveLength] << 24);
// Check if thumbWidth is positive...
if (thumbWidth <= 0) {
return false;
}
// Read the next four bytes as a little-endian number and store it in thumbHeight...
thumbHeight = data[8 + saveLength] + (data[9 + saveLength] << 8) + (data[10 + saveLength] << 16) + (data[11 + saveLength] << 24);
// Check if thumbHeight is positive...
if (thumbHeight <= 0) {
return false;
}
// Read the next four bytes as a little-endian number and store it in thumbLength...
let thumbLength = data[12 + saveLength] + (data[13 + saveLength] << 8) + (data[14 + saveLength] << 16) + (data[15 + saveLength] << 24);
// Check if thumbLength is positive and does not exceed the remaining bytes...
if (thumbLength <= 0 || thumbLength > data.length - (16 + saveLength)) {
return false;
}
// Check if the next two bytes are [120, 156] (zlib header used by SF2000)...
if (data[16 + saveLength] !== 120 || data[17 + saveLength] !== 156) {
return false;
}
// Store the next thumbLength bytes in thumbData, and attempt to inflate it...
thumbData = decompressZlib(data.slice(16 + saveLength, 16 + saveLength + thumbLength));
if (!(thumbData instanceof Uint8Array)) {
return false;
}
// Check to make sure there's only four remaining bytes...
if (data.length - (16 + saveLength + thumbLength) !== 4) {
return false;
}
// Store the last four bytes in lastFour...
let lastFour = data[data.length - 4] + (data[data.length -3 ] <<8 )+ (data[data.length -2 ]<<16 )+ (data[data.length -1 ]<<24 );
// Confirm the last four bytes equal the offset within the data of thumbWidth,
// i.e., first zlib stream length + 4...
if (lastFour !== saveLength + 4) {
return false;
}
// Provided data seems good, so return true...
return true;
}
Update saveStateTool.htm Added some functionality to search for and strip Retroarch save state headers if they're found in the input data when converting to SF2000 format. See Javascript comments on function `stripRetroarchHeaders` for more details
2023-06-21 23:36:58 +02:00
// This function runs through our binary save state data, and checks it for any
// of Retroarch's save state headers. If it finds them, it strips them out...
// See https://github.com/libretro/RetroArch/blob/master/tasks/task_save.c
function stripRetroarchHeaders(input) {
// Define an array of the possible Retroarch headers that we're looking for...
let headers = ["RASTATE" + String.fromCharCode([1]), "MEM ", "RPLY", "ACHV", "END "];
// Define a helper function that checks if a header starts at the provided
// index in the data stream...
function isHeader(array, i) {
// Starting at an index of i, convert the next 8 bytes to a string...
let str = String.fromCharCode(...array.slice(i, i + 8));
// Check if the string includes any of our defined headers...
for (let i = 0; i < headers.length; i++) {
if (str.includes(headers[i])) {
// It does! A header has been found, return true...
return true;
}
}
// If we're here, we didn't find a matching header, so return false...
return false;
}
// Create an intermediate storage array with the same length as input; we
// don't know how long our output length will be yet, but it won't be any
// longer than input, and this array will hold our modified data while we
// work...
let intermediate = new Uint8Array(input.length);
// Now, it's on to the meat of this function. We're going to loop through
// all of our current save state data, byte by byte, and check to see if
// we find a Retroarch save state header starting at the current byte. If
// we don't, we just copy the current byte to our intermediate storage
// array. If we *do* find a Retroarch header, we skip forward 8 bytes (all
// the Retroarch save state header blocks are 8 bytes long)...
let index = 0;
let intermediateIndex = 0;
while (index < input.length && !isNaN(input[index])) {
// Check if we have a header starting at the current index in our data...
if (isHeader(input, index)) {
// We do! Don't write any data, and just skip forward 8 bytes...
index += 8;
}
else {
// No header here, so write the current byte to our intermediate
// storage array...
intermediate[intermediateIndex] = input[index];
// ... and increment our indexes...
index++;
intermediateIndex++;
}
}
// If we're here, intermediate should contain our final output data.
// If the output data length is the same as the input data lenth, then
// we didn't change anything and can just return the input. Otherwise,
// we stripped *something* from the input data... so we'll copy our
// new, shorter intermediate data to a correctly sized Uint8Array
// object, and return that instead...
if (intermediateIndex == input.length) {
return input;
}
else {
let output = new Uint8Array(intermediateIndex);
for (let i = 0; i < intermediateIndex; i++) {
output[i] = intermediate[i];
}
return output;
}
}
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
// This function checks if we're both happy that the user-selected ROM file
// is binary, AND that a save state slot radio button has been selected; if
// both are true, it enables the download button, otherwise it makes sure
// the button is disabled...
function userStateDownloadCheck() {
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
if (romFileGood === true && document.querySelector('input[name="saveSlot"]:checked')) {
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
// Looks good - enable Download button!
var dButton = document.getElementById("saveStateDownload");
dButton.removeAttribute("disabled");
}
else {
// No good - disable Download button!
var dButton = document.getElementById("saveStateDownload");
dButton.setAttribute("disabled", "");
}
}
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
// This function takes our global thumbData object (Uint8Array), converts
// it to an ImageData object and assigns it to our previewCanvasData
// global; it then renders that ImageData to our preview canvas...
function convertFromSF2000AndRender() {
previewCanvasData = rgb565ToImageData(thumbData, thumbWidth, thumbHeight);
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
var canvas = document.getElementById("thumbnailPreview");
var context = canvas.getContext("2d");
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
canvas.width = previewCanvasData.width;
canvas.height = previewCanvasData.height;
context.clearRect(0, 0, canvas.width, canvas.height);
context.putImageData(previewCanvasData, 0, 0);
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
}
</script>
<hr>
Transitioned to shared Javascript library There was a lot of repeated JS across all my tools (e.g., image conversion, BIOS hash checking, etc.), and so I decided to move all shared code out to its own separate library. This will improve scalability and maintainability at the cost of portability - a fair trade in my opinion. This work also involved large-scale refactoring of all of the tools. There's no actual functional difference (all the tools should behave exactly the same), bar some UI improvements for the oldest tools as a result of moving to the same codebase used by the more recent tools.
2023-06-26 15:11:01 +02:00
<p><a rel="license" href="https://creativecommons.org/publicdomain/zero/1.0/">CC0</a>: public domain. Version 1.2, 20230626.1</p>
New Tool: Save State Tool Added a new tool for extracting and creating SF2000 save state files. Also added details to the main page about the save state file format, and about the mysterious arcade `.skp` files
2023-06-05 15:38:48 +02:00
</body>
</html>
Reference in New Issue Copy Permalink