|
Post by DarkKobold on Jan 18, 2020 23:55:00 GMT
bm_write char bm_write(char *buf, char *name, int offset, int nb); [ 1.5+ ]
Write into the file named 'name'. Data to write are in the buffer 'buf' and 'nb' bytes are written from offset 'offset' in the buffer.
Return backup ram status as defined in the huc.h file.
bm_read char bm_read(char *buf, char *name, int offset, int nb); [ 1.5+ ]
Read 'nb' bytes from file named 'name' and put them into 'buf'. I'm not sure whether the 'offset' is relative to the buffer or the file ...
Return backup ram status as defined in the huc.h file.
According to ArchaicPixels - the offset in bm_read and bm_write are offsets from the buffer, which makes no sense. You want to be able to do multiple saves, so they should be offsets relative to the file start in BRAM.
I tried to open huc_bram.asm to check it, but it looks like greek to me.
|
|
|
Post by cabbage on Jan 19, 2020 11:57:52 GMT
huc probably handles the filesystem stuff for you so you don't have to mess with bram offsets and risk corrupting other games' saves the offset presumably allows you to read/write only part of your save data if you feel so inclined and if you want to make multiple saves, change the "name" param--e.g., CATASS1, CATASS69, CATASS420, etc.
|
|
|
Post by dshadoff on Jan 19, 2020 13:57:51 GMT
Those functions are wrappers for the BIOS functions, which I have never used. I just peeked at the Japanese Develo book's description (BM_READ = $E04E), and it says pretty much the same thing, without explanation either.
Here's my advice: 1) Play a game and get some save data 2) Go into the CD System Card, backup memory area to learn its name 3) Use the bm_read function to try to read it, with the simplest of possible parameters: all offsets = 0, buffers should be larger than necessary (I'm pretty sure name also needs trailing spaces). 4) Once you get something being read, then play with parameters to see the difference.
bm_write will be a match
|
|
|
Post by Arkhan on Jan 19, 2020 15:09:33 GMT
Im not at a computer or anything but if you can wait, i can show you atlantean bram.
I forget if our protocade stuff had bram stuff in it.
In the meantime, check that and see!!
(ㆁᴗㆁ✿)
|
|
|
Post by dshadoff on Jan 19, 2020 16:20:58 GMT
Those functions are wrappers for the BIOS functions, which I have never used. Well, looks like I spoke too soon - apparently I have used them, on a previous version of HuC. In fact, I even created code examples. Please go here, on Page 2, under the heading "Backup RAM/Password Generators": www.zeograd.com/creation_download.phpThis will correspond to an old version of HuC, but I expect that it should mostly still work on the current version (untested). Many people may have overlooked this as a resource of example code - it was, in many cases, easier and less time-consuming to write code examples than to write the kind of documentation which some people are looking for. I think it's a vital resource for HuC programmers to draw upon.As I recall, Zeograd is hosting these "Creations Pages" on a personal server of his. It has failed a couple of times in the past 20 years, and also suffered at least one PHP incompatiblity issue more recently (which he fixed for me). Since he has left the PC Engine scene, I don't know how much longer we can expect this resource to continue to exist. Does anybody have a good idea of where to relocate it ? It seems like it should be somehow adjacent to HuC (or at least pointed to by HuC's documentation).
|
|
|
Post by Arkhan on Jan 19, 2020 17:24:46 GMT
I used those and mml source years ago.
Id be willing to migrate it all to aetherbytes hosting since im already doing so, and the bandwidth will be shrimpy.
I always assumed anyone using huc saw this, but with the new version and github, its probably become less noticed.
It was always known until then, AFAIK
|
|
|
Post by spenoza on Jan 19, 2020 19:23:45 GMT
Id be willing to migrate it all to aetherbytes hosting since im already doing so, and the bandwidth will be shrimpy. That’s a kind offer. I think we should also check with Paul. After hosting all the PCE Bible stuff, programming resources could make a nice addition to this site.
|
|
|
Post by DarkKobold on Jan 19, 2020 22:34:27 GMT
huc probably handles the filesystem stuff for you so you don't have to mess with bram offsets and risk corrupting other games' saves the offset presumably allows you to read/write only part of your save data if you feel so inclined and if you want to make multiple saves, change the "name" param--e.g., CATASS1, CATASS69, CATASS420, etc.
I think this is probably the appropriate solution - is this how most games do it? I guess that also makes sense, so the user only need the kb free for a single save. Wasn't anticipating this, gotta go re-write my save functions.
Thanks!
|
|
|
Post by elmer on Jan 19, 2020 23:44:51 GMT
and if you want to make multiple saves, change the "name" param--e.g., CATASS1, CATASS69, CATASS420, etc. I think this is probably the appropriate solution - is this how most games do it? I guess that also makes sense, so the user only need the kb free for a single save. Wasn't anticipating this, gotta go re-write my save functions. Not really, that method is OK on computers but, depending upon how you implement it, it breaks Nintendo/Sony/Microsoft QA standards and would get your game rejected (although your publisher's QA dept would find it way before you went for manufacturer-approval). The cardinal rule of console game backup is " The player must never be put in the position of unintentionally losing game-state", i.e. hi-scores or current progress. That hasn't changed over the years, and gredler should be able to dig through his development system docs at work and confirm that all manufacturers still include tests for that situation (if he has the lot-check/lot-test docs on his computer). So that means ... 1) You create all of the save files that you need in BRAM the first time that your game executes. Those files are a fixed size, and that size must never ever increase. 2) If any of those files are missing when you run your game, you must create the missing files immediately. (That typically means that developers just create a single BRAM file, and then store different save "slots" at different offsets within the one file.) 3) If you are unable to create your save file(s) when the game starts, then you must warn the player that they may/will be unable to save their game state, and give them the option to either continue knowing that they may lose their game position, or that they must free up enough space in BRAM and tell them how much they need. (These days the utility to do so is built into the console firmware, but back-in-the-day, it might have been on a game's CD/cartridge, or it might have been something that developers had to write for themselves). 4) When you save the state within a game, you do it as quickly as possible, verify that the save was written correctly, and warn the player if something goes wrong, then give them the option to retry/quit/continue-without-saving.
|
|
|
Post by elmer on Jan 20, 2020 22:37:58 GMT
Please go here, on Page 2, under the heading "Backup RAM/Password Generators": www.zeograd.com/creation_download.phpThis will correspond to an old version of HuC, but I expect that it should mostly still work on the current version (untested). Many people may have overlooked this as a resource of example code - it was, in many cases, easier and less time-consuming to write code examples than to write the kind of documentation which some people are looking for. I think it's a vital resource for HuC programmers to draw upon.Nice! There are definitely some useful bits of example source there, thanks! If they don't build with the current version of HuC, then they can probably be updated really quickly. And yes, I agree. For a lot of programmers, writing examples is *much* more likely to happen than editing documentation. While I hope that someone does make a working backup copy of the site for future reference, I'd really like to just include more documentation and examples like those in HuC itself so that new folks don't have to go through the offputting step of playing hunt-the-snark through old abandoned corners of the internet looking for information. Until Uli came along, HuC hadn't been touched since 2005, and its forefather MagicKit hasn't been touched since 2000 ... and since MagicKit is a DOS program, it won't even run on modern Windows computers. When it comes to HuC 3.21, well that isn't in much better shape. Yes, the old Windows build still runs, but it won't compile any more with modern tools, and so fixes can't be made. Even on linux, attempting to compile HuC 3.21 on a reasonably-modern 64-bit system fails almost-instantly. Whether it is my fork of Uli's updates, or someone else's ... those updates seem to be critical to keeping HuC/PCEAS/MagicKit alive and compiling on modern computers, to fixing bugs, and to extending the functionality. From my point of view, I believe that it makes the most sense to just throw as much of the available documentation and examples as possible into HuC on github, and to try to make it a one-stop-shop for new PCE developers, whether they wish to program in either C or in assembly-language. Speaking of documentation ... from a quick glance, the HuC documentation on ArchaicPixels looks like it is really nothing more than a wiki version of the documentation that is already in HuC's doc/huc/ directory. If that is the case, then updating the HTML documentation in HuC's "doc" directory would seem to make as much sense, if not more, than updating the ArchaicPixels wiki, especially since it is something that any interested parties can already do, without needing to seek out BT Garner to get editing permission for the ArchaicPixels wiki.
|
|
|
Post by dshadoff on Jan 20, 2020 23:35:12 GMT
You can certainly take any of my code and include it as part of the HuC package if you like. The example code (I believe a little over half of all I wrote) was written expressly for that purpose.
I find that it's not just more likely that a programmer will *write* code than documentation, it has also been my experience that a lot of documentation is too cryptic to use, and requires concrete examples in order to move forward. If *I* find that to be the case, it must be really bad for somebody just starting out.
|
|
|
Post by DarkKobold on Jan 21, 2020 18:22:09 GMT
1) You create all of the save files that you need in BRAM the first time that your game executes. Those files are a fixed size, and that size must never ever increase. 2) If any of those files are missing when you run your game, you must create the missing files immediately. (That typically means that developers just create a single BRAM file, and then store different save "slots" at different offsets within the one file.) 3) If you are unable to create your save file(s) when the game starts, then you must warn the player that they may/will be unable to save their game state, and give them the option to either continue knowing that they may lose their game position, or that they must free up enough space in BRAM and tell them how much they need. (These days the utility to do so is built into the console firmware, but back-in-the-day, it might have been on a game's CD/cartridge, or it might have been something that developers had to write for themselves). 4) When you save the state within a game, you do it as quickly as possible, verify that the save was written correctly, and warn the player if something goes wrong, then give them the option to retry/quit/continue-without-saving. 1.) I don't think this is necessary - the Turbo Duo/PC Engine Duo has limited memory. Creating saves that never get used is foolish. 2.) This was the initial problem I posted about - the offset in HuC doesn't work properly. It's offset from buffer (which is hella stupid imo), rather than from the save file. 3.) I agree if you have 3 possible save positions, and none exist, and there isn't sufficient free space, throw a warning when the game boots. If you have either an active save file or enough space, I'm not going to bother the player. Maybe they don't want to spend their limited memory on my game, so I'm not going to force save creation of 3 files, that's just being a memory hog. 4.) I'm not sure why I need all this error checking, this seems way over the top. Does the BRAM fail often or something? If I do all the checks from the start, this seems totally unnecessary. If the BRAM reports that it found a save file and/or created a save file, I feel like its sufficient to trust that the data is what it says it is.
|
|
|
Post by gredler on Jan 21, 2020 19:01:18 GMT
That hasn't changed over the years, and gredler should be able to dig through his development system docs at work and confirm that all manufacturers still include tests for that situation (if he has the lot-check/lot-test docs on his computer). I'd have to go ask an engineer, or dig through the wikis, but the art department is far removed from whoever would be handling these things
|
|
|
Post by turboxray on Jan 21, 2020 19:45:14 GMT
1) You create all of the save files that you need in BRAM the first time that your game executes. Those files are a fixed size, and that size must never ever increase. 2) If any of those files are missing when you run your game, you must create the missing files immediately. (That typically means that developers just create a single BRAM file, and then store different save "slots" at different offsets within the one file.) 3) If you are unable to create your save file(s) when the game starts, then you must warn the player that they may/will be unable to save their game state, and give them the option to either continue knowing that they may lose their game position, or that they must free up enough space in BRAM and tell them how much they need. (These days the utility to do so is built into the console firmware, but back-in-the-day, it might have been on a game's CD/cartridge, or it might have been something that developers had to write for themselves). 4) When you save the state within a game, you do it as quickly as possible, verify that the save was written correctly, and warn the player if something goes wrong, then give them the option to retry/quit/continue-without-saving. 1.) I don't think this is necessary - the Turbo Duo/PC Engine Duo has limited memory. Creating saves that never get used is foolish. 2.) This was the initial problem I posted about - the offset in HuC doesn't work properly. It's offset from buffer (which is hella stupid imo), rather than from the save file. 3.) I agree if you have 3 possible save positions, and none exist, and there isn't sufficient free space, throw a warning when the game boots. If you have either an active save file or enough space, I'm not going to bother the player. Maybe they don't want to spend their limited memory on my game, so I'm not going to force save creation of 3 files, that's just being a memory hog. 4.) I'm not sure why I need all this error checking, this seems way over the top. Does the BRAM fail often or something? If I do all the checks from the start, this seems totally unnecessary. If the BRAM reports that it found a save file and/or created a save file, I feel like its sufficient to trust that the data is what it says it is. For #1, it seems like a way to keep fragmentation down. Having only 2k of memory, that would seem important since many games use it. Why they didn't go 8k like the NES and everyone else is beyond me hahah. FWI - in emulators you can set it to 8k and it works 99%, but I think one or two games fail because of this (I don't remember the exact reason, but mednafen author found it out). Some games allow BRAM management. Do any do de-fragmentation? As to #4, I mean if the BRAM contents do get corrupt.. that does affect user experience if it affects how the game logic responds to it? I rather have an error message saying your save game was corrupt (checksum fail) than just a random crash. Plus, it could potentially cause your game logic to crash and execute data or code in the wrong order; causing it to put the system in a harmful state (rare, but setting the VDC to drive hsync/vsync pins instead of having them as input from the VCE, etc).
|
|
|
Post by DarkKobold on Jan 21, 2020 20:51:29 GMT
1.) I don't think this is necessary - the Turbo Duo/PC Engine Duo has limited memory. Creating saves that never get used is foolish. 2.) This was the initial problem I posted about - the offset in HuC doesn't work properly. It's offset from buffer (which is hella stupid imo), rather than from the save file. 3.) I agree if you have 3 possible save positions, and none exist, and there isn't sufficient free space, throw a warning when the game boots. If you have either an active save file or enough space, I'm not going to bother the player. Maybe they don't want to spend their limited memory on my game, so I'm not going to force save creation of 3 files, that's just being a memory hog. 4.) I'm not sure why I need all this error checking, this seems way over the top. Does the BRAM fail often or something? If I do all the checks from the start, this seems totally unnecessary. If the BRAM reports that it found a save file and/or created a save file, I feel like its sufficient to trust that the data is what it says it is. For #1, it seems like a way to keep fragmentation down. Having only 2k of memory, that would seem important since many games use it. Why they didn't go 8k like the NES and everyone else is beyond me hahah. FWI - in emulators you can set it to 8k and it works 99%, but I think one or two games fail because of this (I don't remember the exact reason, but mednafen author found it out). Some games allow BRAM management. Do any do de-fragmentation? As to #4, I mean if the BRAM contents do get corrupt.. that does affect user experience if it affects how the game logic responds to it? I rather have an error message saying your save game was corrupt (checksum fail) than just a random crash. Plus, it could potentially cause your game logic to crash and execute data or code in the wrong order; causing it to put the system in a harmful state (rare, but setting the VDC to drive hsync/vsync pins instead of having them as input from the VCE, etc). #1 - Because there's no defragmentation, you can't really say one is better than another. If you make a save thats 300 bytes instead of 3 saves that are 100 bytes each, you mess up the game that needs 400 bytes, but saves the game that needs 200 bytes. #4, I don't know if HuC has a built in checksum checker... but if the save gets corrupted, then its already lost. Maybe the game crashes? But that seems like such a rarity. Also, that's at load, not save. Is there any reason to think that, at save time, the memory wouldn't get written right? I am somewhat dependent on HuC, so if these functions aren't working properly...
|
|