GroovyBee Posted March 27, 2010 Share Posted March 27, 2010 As part of the ProSystem update I'm proposing to add the following to the *.a78 header format :- byte index 58 - Save data peripheral. Which has the following values :- 0x00 - None (default for all games currently released). 0x01 - High Score Cart (HSC). 0x02 - SaveKey. 0x04 to 0x80 - To be defined. This change will allow games to automatically enable their HSC/SaveKey/other support without the player thinking about it. The settings can be overridden by the emulator. Quote Link to comment Share on other sites More sharing options...
+Mitch Posted March 27, 2010 Share Posted March 27, 2010 Sounds reasonable to me. You might want to run it by Dan Boris since he is the one who invented the A78 format. Also, I think Art Krewat was interested in updating the A78 format to allow for more flexible RAM assignment. Rolling all of the enhancements into one update might make it easier to keep track of. Hopefully Dan and Art will see this thread and comment. Mitch 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted March 27, 2010 Author Share Posted March 27, 2010 PMs sent to Dan and Art. Quote Link to comment Share on other sites More sharing options...
krewat Posted March 28, 2010 Share Posted March 28, 2010 Interesting. Let me think about this a few days. I wanted to add more flexible static ram support, but not sure it's even necessary, since the only reason I wanted it was to allow some prototype code I found to run. Quote Link to comment Share on other sites More sharing options...
Shawn Posted March 28, 2010 Share Posted March 28, 2010 Interesting. Let me think about this a few days. I wanted to add more flexible static ram support, but not sure it's even necessary, since the only reason I wanted it was to allow some prototype code I found to run. That is reason enough in my books! Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted March 28, 2010 Author Share Posted March 28, 2010 Interesting. Let me think about this a few days. I wanted to add more flexible static ram support, but not sure it's even necessary, since the only reason I wanted it was to allow some prototype code I found to run. If you need a special build of ProSystem let me know where the RAM is, what size it is and any address line quirks and I'll add it. Quote Link to comment Share on other sites More sharing options...
DanBoris Posted April 4, 2010 Share Posted April 4, 2010 PMs sent to Dan and Art. Strange, never got the PM. Yes, this seems like a good idea to me. If you decide to go ahead with this let me know and I will "officially" document this on my web site. Dan Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted April 4, 2010 Author Share Posted April 4, 2010 Strange, never got the PM. My mistake. I PM'd "Dan Boris" . Yes, this seems like a good idea to me. If you decide to go ahead with this let me know and I will "officially" document this on my web site. I have already made the changes to ProSystem and manually hex edited Food Fight and Robotron to make sure that it works. Quote Link to comment Share on other sites More sharing options...
+Mitch Posted April 4, 2010 Share Posted April 4, 2010 Have you had any thoughts about how to update the cart RAM info? Mitch Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted April 4, 2010 Author Share Posted April 4, 2010 Have you had any thoughts about how to update the cart RAM info? What else needs supporting besides 8K/16K/RoF at $4000? Quote Link to comment Share on other sites More sharing options...
+Mitch Posted April 4, 2010 Share Posted April 4, 2010 Have you had any thoughts about how to update the cart RAM info? What else needs supporting besides 8K/16K/RoF at $4000? I believe Art said his California Games proto used RAM in the $2600-$2700 area. Mitch Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted April 4, 2010 Author Share Posted April 4, 2010 I believe Art said his California Games proto used RAM in the $2600-$2700 area. That address range is already covered by the 7800's internal RAM from $1800 to $2800. Quote Link to comment Share on other sites More sharing options...
+Mitch Posted April 4, 2010 Share Posted April 4, 2010 I thought that's what he said but I could be misremembering. I'll let him respond since it seemed like it was something non-standard. Mitch Quote Link to comment Share on other sites More sharing options...
krewat Posted April 5, 2010 Share Posted April 5, 2010 There was ram at $4000-5fff for one, and at $6000-7fff for another. I think. Just checked my hacked source, and for some reason, I made a bank of RAM from $2600 through $7fff which covered all the prototype code I found. Dunno why $2600-up had to be setup by me separately, but I did. I'll see if I can figure out why tomorrow. In the meantime, I think it's prudent to make it possible to assign RAM to any location. Who knows, it might be in our best interests to be able to do that for future games. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted April 5, 2010 Author Share Posted April 5, 2010 How about the ability to put RAM anywhere in $0000 to $8000 in chunks of 1K? I'm thinking of defining 4 bytes to do something like this :- 00000000 00000000 00000000 00000001 - 1K at $0400 00000000 00000000 00000000 00000010 - 1K at $0800 00000000 00000000 00000000 00000100 - 1K at $0C00 00000000 00000000 00000000 00001000 - 1K at $1000 00000000 00000000 00000000 00010000 - 1K at $1400 00000000 00000000 00000000 00100000 - 1K at $1800 00000000 00000000 00000000 01000000 - 1K at $1C00 00000000 00000000 00000000 10000000 - 1K at $2000 00000000 00000000 00000001 00000000 - 1K at $2400 00000000 00000000 00000010 00000000 - 1K at $2800 00000000 00000000 00000100 00000000 - 1K at $2C00 00000000 00000000 00001000 00000000 - 1K at $3000 00000000 00000000 00010000 00000000 - 1K at $3400 00000000 00000000 00100000 00000000 - 1K at $3800 00000000 00000000 01000000 00000000 - 1K at $3C00 00000000 00000000 10000000 00000000 - 1K at $4000 00000000 00000001 00000000 00000000 - 1K at $4400 00000000 00000010 00000000 00000000 - 1K at $4800 00000000 00000100 00000000 00000000 - 1K at $4C00 00000000 00001000 00000000 00000000 - 1K at $5000 00000000 00010000 00000000 00000000 - 1K at $5400 00000000 00100000 00000000 00000000 - 1K at $5800 00000000 01000000 00000000 00000000 - 1K at $5C00 00000000 10000000 00000000 00000000 - 1K at $6000 00000001 00000000 00000000 00000000 - 1K at $6400 00000010 00000000 00000000 00000000 - 1K at $6800 00000100 00000000 00000000 00000000 - 1K at $6C00 00001000 00000000 00000000 00000000 - 1K at $7000 00010000 00000000 00000000 00000000 - 1K at $7400 00100000 00000000 00000000 00000000 - 1K at $7800 01000000 00000000 00000000 00000000 - 1K at $7C00 Obviously some addresses would clash with the 7800's internal RAM. To map the RAM you want you just logical OR the values above together. So in Arts example of RAM at $4000 to $5FFF he'd need the following :- 00000000 01111111 10000000 00000000 or $00 $80 $7F $00 How about using header indexes 59, 60, 61 and 62 for this? If they are all $00 (the state for all games before this change) no extra RAM will be mapped in. Quote Link to comment Share on other sites More sharing options...
krewat Posted April 5, 2010 Share Posted April 5, 2010 Bee, that works GREAT! It has my approval Quote Link to comment Share on other sites More sharing options...
DracIsBack Posted April 5, 2010 Share Posted April 5, 2010 Bee, that works GREAT! It has my approval Can't wait to see what you've got up and running! Quote Link to comment Share on other sites More sharing options...
+Mitch Posted April 5, 2010 Share Posted April 5, 2010 How would backward compatibility work? Can the old setting be used as sort of an enable/disable switch? Mitch Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted April 5, 2010 Author Share Posted April 5, 2010 How would backward compatibility work? Can the old setting be used as sort of an enable/disable switch? The new changes are backward compatible. The extra 1K RAM chunks are only mapped in if ProSystem finds any bits set in those locations I specified in the A78 header. If no bits are set (hopefully the default for all the older games) then there will be no extra RAM available unless the header already defines the game as a super cart with RAM. In which case they'll still have 16K of RAM mapped to $4000. I'll be checking as many of the old games as possible to make sure I haven't disturbed anything before the next release of the ProSystem emulator. Quote Link to comment Share on other sites More sharing options...
+Mitch Posted April 5, 2010 Share Posted April 5, 2010 How would backward compatibility work? Can the old setting be used as sort of an enable/disable switch? The new changes are backward compatible. The extra 1K RAM chunks are only mapped in if ProSystem finds any bits set in those locations I specified in the A78 header. If no bits are set (hopefully the default for all the older games) then there will be no extra RAM available unless the header already defines the game as a super cart with RAM. In which case they'll still have 16K of RAM mapped to $4000. I'll be checking as many of the old games as possible to make sure I haven't disturbed anything before the next release of the ProSystem emulator. Excellent! With the amount of changes it's probably worth incrementing the A78 version number also. Mitch Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted April 5, 2010 Author Share Posted April 5, 2010 With the amount of changes it's probably worth incrementing the A78 version number also. ProSystem doesn't do anything with that information at the moment. I could add a check for the version number as an extra safety check before enabling these new features. As a side note this change will allow new 8K/16K/32K homebrew games to enable external RAM in the emulator without having to be expanded into a super cart image. Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted April 6, 2010 Author Share Posted April 6, 2010 ProSystem now expects to see a version number greater than or equal to 2 before HSC/SaveKey support and 1K RAM chunks are enabled. Quote Link to comment Share on other sites More sharing options...
+Propane13 Posted April 6, 2010 Share Posted April 6, 2010 ProSystem now expects to see a version number greater than or equal to 2 before HSC/SaveKey support and 1K RAM chunks are enabled. From a software configuration management perspective, I think this was a very good idea (up-revving the version number, and then having prosystem do the check). Just wanted to offer my 2 cents of approval. -John Quote Link to comment Share on other sites More sharing options...
DanBoris Posted April 6, 2010 Share Posted April 6, 2010 (edited) I disagree with adding this to the header since all these different configurations won't necessarily show up in an actual game. Remember that the header is not just for the convenience of using images with an emulator they are also there as historical documentation. For that reason I don't like the idea of providing features that may never be used in a game. If we start down this road we could end up with all kinds of bits in the header for special hardware configuration that may never get used. If you want to have and emulator support this as a configuration option that is fine, but I don't like the idea of putting it into the header. Dan How about the ability to put RAM anywhere in $0000 to $8000 in chunks of 1K? I'm thinking of defining 4 bytes to do something like this :- 00000000 00000000 00000000 00000001 - 1K at $0400 00000000 00000000 00000000 00000010 - 1K at $0800 00000000 00000000 00000000 00000100 - 1K at $0C00 00000000 00000000 00000000 00001000 - 1K at $1000 00000000 00000000 00000000 00010000 - 1K at $1400 00000000 00000000 00000000 00100000 - 1K at $1800 00000000 00000000 00000000 01000000 - 1K at $1C00 00000000 00000000 00000000 10000000 - 1K at $2000 00000000 00000000 00000001 00000000 - 1K at $2400 00000000 00000000 00000010 00000000 - 1K at $2800 00000000 00000000 00000100 00000000 - 1K at $2C00 00000000 00000000 00001000 00000000 - 1K at $3000 00000000 00000000 00010000 00000000 - 1K at $3400 00000000 00000000 00100000 00000000 - 1K at $3800 00000000 00000000 01000000 00000000 - 1K at $3C00 00000000 00000000 10000000 00000000 - 1K at $4000 00000000 00000001 00000000 00000000 - 1K at $4400 00000000 00000010 00000000 00000000 - 1K at $4800 00000000 00000100 00000000 00000000 - 1K at $4C00 00000000 00001000 00000000 00000000 - 1K at $5000 00000000 00010000 00000000 00000000 - 1K at $5400 00000000 00100000 00000000 00000000 - 1K at $5800 00000000 01000000 00000000 00000000 - 1K at $5C00 00000000 10000000 00000000 00000000 - 1K at $6000 00000001 00000000 00000000 00000000 - 1K at $6400 00000010 00000000 00000000 00000000 - 1K at $6800 00000100 00000000 00000000 00000000 - 1K at $6C00 00001000 00000000 00000000 00000000 - 1K at $7000 00010000 00000000 00000000 00000000 - 1K at $7400 00100000 00000000 00000000 00000000 - 1K at $7800 01000000 00000000 00000000 00000000 - 1K at $7C00 Obviously some addresses would clash with the 7800's internal RAM. To map the RAM you want you just logical OR the values above together. So in Arts example of RAM at $4000 to $5FFF he'd need the following :- 00000000 01111111 10000000 00000000 or $00 $80 $7F $00 How about using header indexes 59, 60, 61 and 62 for this? If they are all $00 (the state for all games before this change) no extra RAM will be mapped in. Edited April 6, 2010 by DanBoris 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted April 6, 2010 Author Share Posted April 6, 2010 I disagree with adding this to the header since all these different configurations won't necessarily show up in an actual game. Remember that the header is not just for the convenience of using images with an emulator they are also there as historical documentation. For that reason I don't like the idea of providing features that may never be used in a game. Its ideal for Beeb ports. Typically Beeb games are 16K or less (it depends on the graphics mode used in the original). The port of Beeb Tempest now uses the new header format. If I do any other Beeb ports they'll most likely use the new header format too. In my opinion continually forcing homebrew developers to use the "old" cart models is going to hamper development on the system. If we start down this road we could end up with all kinds of bits in the header for special hardware configuration that may never get used. I have lots of plans for the 7800 some of which will most likely need header file changes to correctly configure the emulator. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.