New Harmony product: Harmony Encore

[Mr SQL]

You just use wav2bin to make a binary of a 2600 tape, or bin2wav to make a tape out of a binary (2K or 4K).

I don't get what you are saying.

iesposta,

I was saying what if the binary is held back a la BoulderDash meaning you can't dump it either (I think there was one guy dumping the BoulderDash binary eBay but it was prohibited).

[raindog]

Fortunately there are none.

 

No American work since 1976 has ever entered the public domain. (Few since the mid-1920s have, but a few fell through the cracks before the law changed in 1976.) Legal opinions differ over whether it's even possible to dedicate your work to the public domain explicitly, though it's a moot point since the person making that dedication would be the person who'd have to sue someone for subsequently infringing the copyright. Someone, somewhere, still owns the rights to the Cinematronics games, most likely Warner Bros. since they bought most of Midway's assets through bankruptcy proceedings, while Midway had bought Williams who had previously bought Cinematronics' assets. They may not know or care the way First Star does, but they could pop up at any time.

 

Trademarks, of course, are a different story, and Star Castle as a video game trademark expired decades ago. But the American copyright system in particular is ridiculous and extreme (see also: Nintendo able to get "Let's Play" videos of their gameplay removed from Youtube).

[Thomas Jentzsch]

Well, then: Fingers Crossed

[+save2600]

Aren't the game sounds of 2600 Pac-Man and Donkey Kong in the public domain?

[relo999]

The vectrex entered public domain in the mid-90's

[raindog]

Vectrex games aren't in the public domain; the rights holders just made public statements that non-commercial distribution of the ROMs was okay. That is not the same thing; a public domain work has no restrictions on it whatsoever, and is not owned by anyone. It may not actually be possible to put something in the public domain in the US before its copyright expires, even if you're the copyright holder, due to the exhaustive nature of the laws bought by the movie industry: http://readwrite.com/2009/03/11/cc_zero_a_tool_to_drop_your_rights_and_go_public_domain https://en.wikipedia.org/wiki/Public_domain_in_the_United_States#Section_203_of_the_Copyright_Act

 

There were two more paragraphs to my post, dealing with sounds created by computer programs and why I'm so interested in copyright law, but this wonderful Javascript editor seems to have seen fit to discard them along with my formatting. Ah well.

 

Edited January 25, 2014 by raindog

[HammR25]

Will this cart run Knight Rider?

[toiletunes]

Silly question, but...

 

When playing Escape from the Mindmaster on the older version Harmony, the end text is slightly garbled- does this happen with the Encore? IIRC, it was some kind of timing issue with the Starpath programming. Mindmaster is one of my top favorite games, but I'm not very fond of using the Supercharger.

[+batari]

Harmony Encore uses the same code for Supercharger, so it would look the same.

 

I did some digging and it appears that the final screen is relying on the sprite positioning (because the "press play on tape" screen inadvertantly positions them). Since Harmony has no need for that screen, the positions are not being set. I think it's a pretty easy fix. I'll try to get it into the next BIOS update.

[+batari]

Silly question, but...

 

When playing Escape from the Mindmaster on the older version Harmony, the end text is slightly garbled- does this happen with the Encore? IIRC, it was some kind of timing issue with the Starpath programming. Mindmaster is one of my top favorite games, but I'm not very fond of using the Supercharger.

Update to my prior post: this issue has been fixed and will be included in the next BIOS release (that will work on any Harmony.)

[Omegamatrix]

Update to my prior post: this issue has been fixed and will be included in the next BIOS release (that will work on any Harmony.)

I got to ask... will 7800 detection be in the bios?

[+batari]

I got to ask... will 7800 detection be in the bios?

Yep... it's working. Just trying to iron out some bugs.

[toiletunes]

Thank you batari!

[DBloke]

Any idea when its out?

Im so close to buying the first type, then someone says a new version is coming out.

 

(After a 7800 one as well)

[Bakasama]

Any idea when its out?

Im so close to buying the first type, then someone says a new version is coming out.

 

(After a 7800 one as well)

Think "It comes out when it comes out" is the best answer. Sure, it's a crap answer but it's best one we have for the time being.

[Andromeda Stardust]

Dang, how did I miss this thread. Anyway, my two cents:

 

512kb is not enough. It has to be 4Mb (megabytes) and here's why...

(please take the following tirade with a grain of salt)

 

The original Atari could only access up to 4kb of ROM data. As a natural extension of the bankswitch format of Atari games, you keep canabalizing more bankswitch adressses near the end of the ROM space. A read on a certain given address will swap out the banks. Each time you double the number of 4k banks, you reduce the remaining space you have to work with. For instance, suppose you have a 32kbyte ROM. Well, it's technically not 32768 bytes of data, more like 32760, because since you have 8 banks of 4k each, 8 bytes of each bank is used up by the bank switch protocol.

Under the current bankswitch system:

64k ROMs have 16 bytes of unusable data in each 4k bank.

128kb ROMs have 32 bytes of unusable data in each 4k bank.

256kb ROMs have 64 bytes of unusable data in each 4k bank.

512kb ROMs have 128 bytes of unusable data in each 4k bank.

Here we have reached the limits of the current future Harmony. Let us continue this trend:

1M ROMs have 256 bytes of unusable data in each 4k bank (6.25% wasted space)

2M ROMs have 512 bytes of unusable data in each 4k bank. (12.5% wasted space)

4M ROMs have 1k bytes of unusable data in each 4k bank. (25% wasted space)

8M ROMs have 2k bytes of unusable data in each 4k bank. (50% wasted space)

At this point, we have reached critical mass. A 16M ROM would require 4k of bankswitch data in every 4k bank, rendering the entire ROM inaccessible. However, looking at the 8M ROM, we discover a surprising reality: the upper half of every 4k bank is used for bankswitching, so we can disconnect the MSB data line from the ROM entirely and whenever this data line outputs a high logic signal, the remaining 11 lowest bits is fed to a latch circuit that selects the a new bank and locks it. In other words, the 4M ROM chip has 22 data lines. The most significant bit of the Atari's address space feeds a high logic state to a latch which writes the lower 11 address lines to the 11 upper address lines of the chip, and the latch stores this address until a new bank is selected.

Thus our game cartridge now uses this elegant solution:

4M ROM with 2048 x 2k banks (100% usable).

That is the theoretical limit for file size on an Atari ROM. Depending on workflow, it may be preferable to use a 4M ROM with 1k banks of 4k each (3k usable in each bank, 3M total) or further subdivide the remaining data into 2k banks of 2k; 100% of the address space will be usable but the program is further fragmented into 2k pieces.

The proposed "ultimate" bankswitch could easily be programmed onto a PCB and placed in a cartridge, and it would require only 2-3 chips, a 16-bit latch (or two 8-bit latches) and a single 4Mbyte EPROM. Someday somebody will build this massive 4M cartridge, load it with some ginormous and epic homebrew that's never before graced the likes of the VCS or any game console for that matter, and people are gonna complain that the Harmony Encore or whatever it is won't play their newfangled homebrew.

Then the Harmony Encore Deluxe or whatever will have to be released just to play this massively epic game and some guy on the internet will utter the words, "I told you so."

Don't make "some guy on the internet" utter the words "I told you so." Switch to Direct TV and save 25% or more over cable...

 

I'll let you programming hardware gurus come up with a more proper name for the "ultimate" 4Mb bankswitch (2k ROM x 2k banks) I just laid out.

 

Until that day comes, I'll be stoked just having the privilege to own the "puny" 512kb Harmony Encore...

 

Oh, and I hope you also add an option for saving cart data back to SD Card for DSP+ games like Chetiry and others that support "on cart" flash saves...

Edited February 20, 2014 by stardust4ever

[Thomas Jentzsch]

Given the experiences I had while developing Boulder Dash, I don't think such a bank switching would be very useful. It is not the sheer amount of ROM you have, but how it is organized and how flexible it is. And the more ROM, the more important this becomes.

 

It is very important that you are able to address more than one bank at a time (e.g. two 2K banks or four 1K banks). Else you will be forced to duplicate a lot of code or to permanently switch banks. Also with more ROM you need more RAM. So your bankswitching must allow accessing multiple RAM and ROM banks at the same time (e.g. you want to read RAM from one bank, process it in a ROM bank, call some subroutines in other ROM banks and then store the result in a different RAM bank).

 

Also the sizes of the banks should be flexible, e.g. big RAM banks to allow continuous addressing, small RAM banks to have a lot of ROM code and data to work with.

Edited February 20, 2014 by Thomas Jentzsch

[raindog]

A 16M ROM would require 4k of bankswitch data in every 4k bank, rendering the entire ROM inaccessible. However, looking at the 8M ROM, we discover a surprising reality: the upper half of every 4k bank is used for bankswitching, so we can disconnect the MSB data line from the ROM entirely and whenever this data line outputs a high logic signal, the remaining 11 lowest bits is fed to a latch circuit that selects the a new bank and locks it. In other words, the 4M ROM chip has 22 data lines. The most significant bit of the Atari's address space feeds a high logic state to a latch which writes the lower 11 address lines to the 11 upper address lines of the chip, and the latch stores this address until a new bank is selected.

 

Wait, if you can feed the bits from a write to a latch circuit, and store them until a new bank is selected, why isn't there already a "65536 banks of 4k" bankswitching scheme out there that uses only two trigger locations, storing the most significant byte until the least significant byte is written, providing up to 256MB? Or even a "256 banks of 4k" one that uses only a single location and eliminates statefulness while still providing a megabyte? (Or the equivalent of each of those with 2K banks that can be mixed and matched, at the expense of doubling the number of write locations to 4 or 2 respectively and halving the total amount of space.)

 

I realize that these questions must demonstrate my near-total ignorance of how hardware works, but I'm really curious.

[Wickeycolumbus]

 

512kb is not enough. It has to be 4Mb (megabytes) and here's why...

(please take the following tirade with a grain of salt)

 

 

Of course those types of bankswitching would be quite wasteful. Really anything over 32K should have a different way to switch banks, other than to decode an address for each bank. For example, the MegaBoy scheme uses a single address to access 64K. Although I wouldn't recommend using MB banking, since you have to cycle through all the banks to switch. The best way to do ROM only 4K banking would be to decode the address and data lines, so you could do something like this:

 

 

    lda BankToSwitchTo
    sta $1FFB

 

Where $1FFB would be the hotspot for all bank switches.

 

Given the experiences I had while developing Boulder Dash, I don't think such a bank switching would be very useful. It is not the sheer amount of ROM you have, but how it is organized and how flexible it is. And the more ROM, the more important this becomes.

 

It is very important that you are able to address more than one bank at a time (e.g. two 2K banks or four 1K banks). Else you will be forced to duplicate a lot of code or to permanently switch banks. Also with more ROM you need more RAM. So your bankswitching must allow accessing multiple RAM and ROM banks at the same time (e.g. you want to read RAM from one bank, process it in a ROM bank, call some subroutines in other ROM banks and then store the result in a different RAM bank).

 

Also the sizes of the banks should be flexible, e.g. big RAM banks to allow continuous addressing, small RAM banks to have a lot of ROM code and data to work with.

 

Of course, the more complex you get here, the less feasible this would be back in the day (if that matters to you). Remember, E7 required a 40 pin ASIC back in the day. Making bank sizes flexible may not have been possible to do cheap enough.

 

[RevEng]

I don't know if it's up to the task, but I was thinking the other day that something like Harmony/Melody could be used to create a pseudo-flat 32k memory scheme.

 

Give it a state machine for basic opcode info and PC tracking. If an absolute addressing opcode instruction is loaded from ROM like "lda $f234", when $1234 shows up on the address bus, give it the data in from the last 4k. Track when a 4k boundary is crossed through branch/jmp/jsr/fall-through, and change the "current" 4k block.

 

Indirect addressing would obviously bypass this, but you could just give the restriction that indirect addressing would always fetch either from the first 4k or the "current" 4k. Not a horrible trade-off for flat-ish addressing features elsewhere.

[+SpiceWare]

Really anything over 32K should have a different way to switch banks

There's already a different way, the Krokodile Cart already supports 512KB games by extending Tigervision's 3F bankswitching format. Writes to zero page address 3F control the bank selection, so there's no wasted bytes in the ROM. (I believe it's actually addresses $00-$3f, so you should use mirror addresses $40-$7f to update TIA)

 

The Krok Cart also supports up to 512KB ROM with 32KB of RAM by extending Tigervision's 3E format.

 

See pages 4 & 5 of the Krok Cart Manual.

Edited February 20, 2014 by SpiceWare

[+SpiceWare]

More info from Stella's source files. From Cart3F.hxx

This is the cartridge class for Tigervision's bankswitched
games. In this bankswitching scheme the 2600's 4K cartridge
address space is broken into two 2K segments. The last 2K
segment always points to the last 2K of the ROM image. The
desired bank number of the first 2K segment is selected by
storing its value into $3F. Actually, any write to location
$00 to $3F will change banks. Although, the Tigervision games
only used 8K this bankswitching scheme supports up to 512K.

From Cart3E.hxx

This is the cartridge class for Tigervision's bankswitched
games with RAM (basically, 3F plus up to 32K of RAM). This
code is basically Brad's Cart3F code plus 32K RAM support.

In this bankswitching scheme the 2600's 4K cartridge
address space is broken into two 2K segments. The last 2K
segment always points to the last 2K of the ROM image.

The lower 2K of address space maps to either one of the 2K ROM banks
(up to 256 of them, though only 240 are supposed to be used for
compatibility with the Kroko Cart and Cuttle Cart 2), or else one
of the 1K RAM banks (up to 32 of them). Like other carts with RAM,
this takes up twice the address space that it should: The lower 1K
is the read port, and the upper 1K is the write port (maps to the
same memory).

To map ROM, the desired bank number of the first 2K segment is selected
by storing its value into $3F. To map RAM in the first 2K segment
instead, store the RAM bank number into $3E.

This implementation of 3E bankswitching numbers the ROM banks 0 to
255, and the RAM banks 256 to 287. This is done because the public
bankswitching interface requires us to use one bank number, not one
bank number plus the knowledge of whether it's RAM or ROM.

All 32K of potential RAM is available to a game using this class, even
though real cartridges might not have the full 32K: We have no way to
tell how much RAM the game expects. This may change in the future (we
may add a stella.pro property for this), but for now it shouldn't cause
any problems. (Famous last words...)

[Thomas Jentzsch]

Of course, the more complex you get here, the less feasible this would be back in the day (if that matters to you). Remember, E7 required a 40 pin ASIC back in the day. Making bank sizes flexible may not have been possible to do cheap enough.

Sure. But since we are talking about 4M, any feasibilty back seems quite irrelevant.

[Thomas Jentzsch]

There's already a different way, the Krokodile Cart already supports 512KB games by extending Tigervision's 3F bankswitching format. Writes to zero page address 3F control the bank selection, so there's no wasted bytes in the ROM. (I believe it's actually addresses $00-$3f, so you should use mirror addresses $40-$7f to update TIA)

 

The Krok Cart also supports up to 512KB ROM with 32KB of RAM by extending Tigervision's 3E format.

That's the one we were using in Boulder Dash. With all the problems described there and some more.

[Andromeda Stardust]

So Boulderdash will run on the Crocodile cart but not Harmony? Yet Crocodile is somehow older and more outdated. Hmmm...