Jump to content
IGNORED

A78 header changes


GroovyBee

Recommended Posts

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.

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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! :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 by DanBoris
  • Like 1
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...