32 replies to this topic

[GroovyBee]

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.

[Mitch]

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

[GroovyBee]

PMs sent to Dan and Art.

[krewat]

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.

[Shawn Sr.]

krewat, on Sun Mar 28, 2010 2:57 PM, said:

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!

[GroovyBee]

krewat, on Sun Mar 28, 2010 2:57 PM, said:

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.

[DanBoris]

GroovyBee, on Sat Mar 27, 2010 12:19 PM, said:

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

[GroovyBee]

DanBoris, on Sun Apr 4, 2010 7:23 AM, said:

Strange, never got the PM.

My mistake. I PM'd "Dan Boris" .

Quote

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.

[Mitch]

Have you had any thoughts about how to update the cart RAM info?

Mitch

[GroovyBee]

Mitch, on Sun Apr 4, 2010 3:19 PM, said:

Have you had any thoughts about how to update the cart RAM info?

What else needs supporting besides 8K/16K/RoF at $4000?

[Mitch]

GroovyBee, on Sun Apr 4, 2010 3:30 PM, said:

Mitch, on Sun Apr 4, 2010 3:19 PM, said:

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

[GroovyBee]

Mitch, on Sun Apr 4, 2010 4:40 PM, said:

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.

[Mitch]

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

[krewat]

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.

[GroovyBee]

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.

[krewat]

Bee, that works GREAT! It has my approval

[DracIsBack]

krewat, on Mon Apr 5, 2010 9:11 AM, said:

Bee, that works GREAT! It has my approval

Can't wait to see what you've got up and running!

[Mitch]

How would backward compatibility work? Can the old setting be used as sort of an enable/disable switch?

Mitch

[GroovyBee]

Mitch, on Mon Apr 5, 2010 11:49 AM, said:

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.

[Mitch]

GroovyBee, on Mon Apr 5, 2010 12:18 PM, said:

Mitch, on Mon Apr 5, 2010 11:49 AM, said:

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

[GroovyBee]

Mitch, on Mon Apr 5, 2010 12:24 PM, said:

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.

[GroovyBee]

ProSystem now expects to see a version number greater than or equal to 2 before HSC/SaveKey support and 1K RAM chunks are enabled.

[Propane13]

GroovyBee, on Tue Apr 6, 2010 6:18 AM, said:

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

[DanBoris]

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

GroovyBee, on Mon Apr 5, 2010 7:02 AM, said:

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, Tue Apr 6, 2010 2:12 PM.

[GroovyBee]

DanBoris, on Tue Apr 6, 2010 2:11 PM, said:

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.

Quote

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.