Jump to content
IGNORED

64k edition?


e1will

Recommended Posts

Are there any thoughts/plans for doing a version of the Harmony cart with 64k flash memory instead of 32k?

 

I know 32k is sufficient for practically all the games that now exist, but since some of the recent homebrews have been maxing that out I wonder how feasible it would be to stretch the maximum supported ROM size, if only in a deluxe or limited edition.

 

--Will

  • Like 1
Link to comment
Share on other sites

Are there any thoughts/plans for doing a version of the Harmony cart with 64k flash memory instead of 32k?

 

I know 32k is sufficient for practically all the games that now exist, but since some of the recent homebrews have been maxing that out I wonder how feasible it would be to stretch the maximum supported ROM size, if only in a deluxe or limited edition.

 

--Will

There are a few options. If you don't need instant access to the resources beyond 32k, an EEPROM chip is on Harmony (and can be added to Melody) that can swap a bank into RAM in a few milliseconds. We are working on support for this. The EEPROM in Harmony is 512k and chips are available up to 4M bytes.

 

It is also possible to make version of Melody with 128k of flash which is all instantly available. The 128k chips do not work as Harmony carts, but I can add the Harmony daughterboard and just not attach the SD card slot, and it can be programmed with Harmony programming software using the Development tab and only allow a single game at one time (though we need to allow for custom bankswitching for 128k as no schemes support beyond 32k at the moment - we are working on this.)

 

Also, keep in mind that the 128k chips are approximately $4-$5 more than the 32k chips so this would add some cost to your homebrew and drive up the price. It can be done, though, and I'd be willing to make one for a developer serious about using the larger chips.

 

I don't want to get hammered with requests from collectors for a 128k Melody so just developers who are serious about it for now, please.

Link to comment
Share on other sites

There are a few options. If you don't need instant access to the resources beyond 32k, an EEPROM chip is on Harmony (and can be added to Melody) that can swap a bank into RAM in a few milliseconds. We are working on support for this. The EEPROM in Harmony is 512k and chips are available up to 4M bytes.

 

It is also possible to make version of Melody with 128k of flash which is all instantly available. The 128k chips do not work as Harmony carts, but I can add the Harmony daughterboard and just not attach the SD card slot, and it can be programmed with Harmony programming software using the Development tab and only allow a single game at one time (though we need to allow for custom bankswitching for 128k as no schemes support beyond 32k at the moment - we are working on this.)

 

Also, keep in mind that the 128k chips are approximately $4-$5 more than the 32k chips so this would add some cost to your homebrew and drive up the price. It can be done, though, and I'd be willing to make one for a developer serious about using the larger chips.

 

I don't want to get hammered with requests from collectors for a 128k Melody so just developers who are serious about it for now, please.

 

A somewhat-unrelated Harmony question (I apologize if this has been already answered elsewhere): With the 32k F4SC bankswitching examples I've seen, the extra RAM bytes are padded with $FF, which I assume is because the traditional hardware used volatile memory for that. Is there any reason a 32k F4SC game couldn't be created to run on Harmony that was pre-loaded with game code or graphics (rather than $FF padding bytes) in that 128 bytes of RAM?

 

And if that's feasible, would it be possible to extend that scheme to a 128k flash so that it contains 64k of code in the RAM portion, which could then modify itself? For example, addresses $F000-$F7FF in each of the 32 4k banks are the RAM "read" addresses preloaded with game code, and $F800-$FFFF are write addresses which the code would use to modify itself... assuming the bankswitching triggers were handled by a zero-page RAM write (e.g. LDA #desired_bank STA $3F).

 

--Will

Link to comment
Share on other sites

A somewhat-unrelated Harmony question (I apologize if this has been already answered elsewhere): With the 32k F4SC bankswitching examples I've seen, the extra RAM bytes are padded with $FF, which I assume is because the traditional hardware used volatile memory for that. Is there any reason a 32k F4SC game couldn't be created to run on Harmony that was pre-loaded with game code or graphics (rather than $FF padding bytes) in that 128 bytes of RAM?

That is possible. I'm not sure why $FF is there but it does help with proper detection of the bankswitching scheme in Harmony. I'll look at the code and see if adding RAM code there will cause issues with detection.

And if that's feasible, would it be possible to extend that scheme to a 128k flash so that it contains 64k of code in the RAM portion, which could then modify itself? For example, addresses $F000-$F7FF in each of the 32 4k banks are the RAM "read" addresses preloaded with game code, and $F800-$FFFF are write addresses which the code would use to modify itself... assuming the bankswitching triggers were handled by a zero-page RAM write (e.g. LDA #desired_bank STA $3F).

 

--Will

Well, the 128k chips have 16k of RAM, so unless I'm misunderstanding, 64k RAM won't work.

Link to comment
Share on other sites

Are there any thoughts/plans for doing a version of the Harmony cart with 64k flash memory instead of 32k?

 

I know 32k is sufficient for practically all the games that now exist, but since some of the recent homebrews have been maxing that out I wonder how feasible it would be to stretch the maximum supported ROM size, if only in a deluxe or limited edition.

 

--Will

It is also possible to make version of Melody with 128k of flash which is all instantly available. The 128k chips do not work as Harmony carts, but I can add the Harmony daughterboard and just not attach the SD card slot, and it can be programmed with Harmony programming software using the Development tab and only allow a single game at one time (though we need to allow for custom bankswitching for 128k as no schemes support beyond 32k at the moment - we are working on this.)

 

Also, keep in mind that the 128k chips are approximately $4-$5 more than the 32k chips so this would add some cost to your homebrew and drive up the price. It can be done, though, and I'd be willing to make one for a developer serious about using the larger chips.

 

I don't want to get hammered with requests from collectors for a 128k Melody so just developers who are serious about it for now, please.

 

I'd potentially be interested in a larger melody. I'm actually starting work on a game that may turn out to be rather large (64K or over). I haven't done much yet, but hopefully it will be finished and released some day.

 

Will: If you are speaking of my demo I posted, the first page of each bank is filled with $FF for no particular reason. It is not possible to use the first page of each bank for ROM when using the SARA chip (for the original hardware), so I just filled it with a random number.

 

By the way, if you were to modify/make a new 32K/super chip Atari style scheme for the Harmony, it may be better to use zero page hotspots.

Edited by Wickeycolumbus
Link to comment
Share on other sites

Well, the 128k chips have 16k of RAM, so unless I'm misunderstanding, 64k RAM won't work.

 

Let's say you have a 32k .bin file that contains game code. As I understand it now, Harmony could either treat this as all ROM (if it thinks it's an F4 bankswitching game) or a mix of RAM and ROM (if it thinks it's coded to use F4SC). Is there any reason it couldn't treat it as all RAM?

 

--Will

Link to comment
Share on other sites

Well, the 128k chips have 16k of RAM, so unless I'm misunderstanding, 64k RAM won't work.

 

Let's say you have a 32k .bin file that contains game code. As I understand it now, Harmony could either treat this as all ROM (if it thinks it's an F4 bankswitching game) or a mix of RAM and ROM (if it thinks it's coded to use F4SC). Is there any reason it couldn't treat it as all RAM?

 

--Will

The Harmony has 8k of RAM. You could certainly have more than 128 bytes but not the full 32k.

Link to comment
Share on other sites

How is it going to write to that ram bank, since the 2600 cart pinout has no write-indicator line?

 

If you take the sara chip approach of repurposing an address line as a write-indicator you lose half of the 4k address space in the bank.

 

There's a few alternate schemes I can think of, but they have serious pitfalls.

Link to comment
Share on other sites

How is it going to write to that ram bank, since the 2600 cart pinout has no write-indicator line?

 

If you take the sara chip approach of repurposing an address line as a write-indicator you lose half of the 4k address space in the bank.

 

There's a few alternate schemes I can think of, but they have serious pitfalls.

 

If the full 8k is available, could you use $1000-$13FF to read a 1k RAM slice, $1400-$17FF to write to that slice, and $1800-1FFF for a 2k slice of ROM?

 

Then you could swap among the 8 1k RAM slices using one bankswitch trigger (e.g. write the desired RAM bank # to $3E) and swap among the ROM slices using another (e.g. write the desired ROM bank # to $3F).

 

That would let you access all the ROM from all of the RAM, and vice versa. You just couldn't access all of the RAM from the RAM, or all of the ROM from the ROM.

 

--Will

Link to comment
Share on other sites

Sure, that would work.

 

2k ROM banks is a bit tight, but that's a heck of a lot of ram to play with!

 

Well, if it turns out that the RAM zones can be preloaded with code (and I assume they can), then it's more like 3k of "ROM", 1k of which is modifiable.

 

That would be a great way to save kernel cycles: just modify certain spots of the kernel before calling it. If nothing else you could replace all the 5-cycle "LDA (PTR),Y" calls with 4-cycle "LDA ptr,Y" calls. Might not seem like a lot but I have a couple of kernels-in-progress that would really benefit from that.

 

--Will

Link to comment
Share on other sites

Well, a proposed expansion to E7 banking was proposed privately, which allows for 31.5k ROM and up to 7k of RAM. Maybe it was 7.5k.

 

I will look up the details in case anyone is interested.

 

Yes, I'd love to see that! That could really open up some possibilities.

 

--Will

Link to comment
Share on other sites

I've taken the description of E7 from the old sizes.txt document from Kevin Horton (and edited it because there are errors in it):

The last 1.5K in the cart always points to the last 1.5K of the ROM image, while the first 2K is selectable. You access 1FE0 to 1FE6 to select which 2K bank. Note that you cannot select the last 2K of the ROM image into the lower 2K of the cart! Accessing 1FE7 selects 1K of RAM at 1000-17FF instead of ROM! The 2K of RAM is broken up into two 1K sections. One 1K section is mapped in at 1000-17FF if 1FE7 has been accessed. 1000-13FF is the write port, while 1400-17FF

is the read port. The second 1K of RAM appears at 1800-19FF. 1800-18FF is the write port while 1900-19FF is the read port. You select which 256 byte block appears here by accessing 1FE8 to 1FEB.

32k E7 would be the same as above except 16k of code space would precede it. This 16k would contain 8 more 2k ROM banks accessed at $1FD8-$1FDF.

 

Optionally, more RAM would be available. Nothing was finalized, but possibly $1FEC-$1FF1 could add another 1.5k for the 256-byte banks.

 

As for the rest, $1FE7 still selects a 1k bank, but $1FF2-1FF6 selects which one of 5 1k banks will go there.

 

It looks like the full 7.5k RAM will be usable. As for the 32k ROM (actually, 31.5k as there is a 512-byte hole at $7800-$79FF) there might need to be a little bit of space reserved at the beginning in case the bankswitch code can't fit in the 512-byte hole.

Link to comment
Share on other sites

I've taken the description of E7 from the old sizes.txt document from Kevin Horton (and edited it because there are errors in it):

The last 1.5K in the cart always points to the last 1.5K of the ROM image, while the first 2K is selectable. You access 1FE0 to 1FE6 to select which 2K bank. Note that you cannot select the last 2K of the ROM image into the lower 2K of the cart! Accessing 1FE7 selects 1K of RAM at 1000-17FF instead of ROM! The 2K of RAM is broken up into two 1K sections. One 1K section is mapped in at 1000-17FF if 1FE7 has been accessed. 1000-13FF is the write port, while 1400-17FF

is the read port. The second 1K of RAM appears at 1800-19FF. 1800-18FF is the write port while 1900-19FF is the read port. You select which 256 byte block appears here by accessing 1FE8 to 1FEB.

32k E7 would be the same as above except 16k of code space would precede it. This 16k would contain 8 more 2k ROM banks accessed at $1FD8-$1FDF.

 

Optionally, more RAM would be available. Nothing was finalized, but possibly $1FEC-$1FF1 could add another 1.5k for the 256-byte banks.

 

As for the rest, $1FE7 still selects a 1k bank, but $1FF2-1FF6 selects which one of 5 1k banks will go there.

 

It looks like the full 7.5k RAM will be usable. As for the 32k ROM (actually, 31.5k as there is a 512-byte hole at $7800-$79FF) there might need to be a little bit of space reserved at the beginning in case the bankswitch code can't fit in the 512-byte hole.

 

Interesting... So is that 7.5k RAM plus 31.5k ROM, or is the 7.5k within that 31.5k (i.e. 7.5k RAM, 24k ROM)?

 

Are there benefits in using $1Fnn bankswitch triggers instead of zero-page ones?

 

--Will

Link to comment
Share on other sites

I've taken the description of E7 from the old sizes.txt document from Kevin Horton (and edited it because there are errors in it):

The last 1.5K in the cart always points to the last 1.5K of the ROM image, while the first 2K is selectable. You access 1FE0 to 1FE6 to select which 2K bank. Note that you cannot select the last 2K of the ROM image into the lower 2K of the cart! Accessing 1FE7 selects 1K of RAM at 1000-17FF instead of ROM! The 2K of RAM is broken up into two 1K sections. One 1K section is mapped in at 1000-17FF if 1FE7 has been accessed. 1000-13FF is the write port, while 1400-17FF

is the read port. The second 1K of RAM appears at 1800-19FF. 1800-18FF is the write port while 1900-19FF is the read port. You select which 256 byte block appears here by accessing 1FE8 to 1FEB.

32k E7 would be the same as above except 16k of code space would precede it. This 16k would contain 8 more 2k ROM banks accessed at $1FD8-$1FDF.

 

Optionally, more RAM would be available. Nothing was finalized, but possibly $1FEC-$1FF1 could add another 1.5k for the 256-byte banks.

 

As for the rest, $1FE7 still selects a 1k bank, but $1FF2-1FF6 selects which one of 5 1k banks will go there.

 

It looks like the full 7.5k RAM will be usable. As for the 32k ROM (actually, 31.5k as there is a 512-byte hole at $7800-$79FF) there might need to be a little bit of space reserved at the beginning in case the bankswitch code can't fit in the 512-byte hole.

 

Interesting... So is that 7.5k RAM plus 31.5k ROM, or is the 7.5k within that 31.5k (i.e. 7.5k RAM, 24k ROM)?

 

Are there benefits in using $1Fnn bankswitch triggers instead of zero-page ones?

 

--Will

The 7.5k RAM is in addition to the 31.5k ROM.

 

The reason for the $1Fnn triggers is because it's a superset of an existing scheme that uses them already. That is, you may start developing your E7 game in an emulator now and move on to the larger scheme without major changes (initially, just 16k of zeros before your current binary.)

Link to comment
Share on other sites

The 7.5k RAM is in addition to the 31.5k ROM.

 

The reason for the $1Fnn triggers is because it's a superset of an existing scheme that uses them already. That is, you may start developing your E7 game in an emulator now and move on to the larger scheme without major changes (initially, just 16k of zeros before your current binary.)

 

OK. That's useful information. There's a game I had wanted to write that suddenly becomes feasible with that amount of RAM and ROM.

 

Thanks!

--Will

Link to comment
Share on other sites

Well, a proposed expansion to E7 banking was proposed privately, which allows for 31.5k ROM and up to 7k of RAM. Maybe it was 7.5k.

 

I will look up the details in case anyone is interested.

 

I need to get my Atari stuff unpacked (moved it to a new house after I got married) so I can get back to working on that stuff. I'm a fan of bank-switch addresses in the 0x400-0x0FFF range. There are lots of them, so one can switch directly among many banks. I'm also a fan of being able to access RAM via multiple methods (e.g. for E7-style banking, allow the same parts of RAM to be banked in at $1000/$1400 or at $1800/$1900, or allow 2K of contiguous RAM to be banked read-only at $1000-$17FF). Do the extended E7 formats allow for any of those things?

Link to comment
Share on other sites

Well, a proposed expansion to E7 banking was proposed privately, which allows for 31.5k ROM and up to 7k of RAM. Maybe it was 7.5k.

 

I will look up the details in case anyone is interested.

 

I need to get my Atari stuff unpacked (moved it to a new house after I got married) so I can get back to working on that stuff. I'm a fan of bank-switch addresses in the 0x400-0x0FFF range. There are lots of them, so one can switch directly among many banks. I'm also a fan of being able to access RAM via multiple methods (e.g. for E7-style banking, allow the same parts of RAM to be banked in at $1000/$1400 or at $1800/$1900, or allow 2K of contiguous RAM to be banked read-only at $1000-$17FF). Do the extended E7 formats allow for any of those things?

Not currently, but they probably could.

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...