Stella 5.1 released

[Kiwi]

Unchecking Randomize zero-page and extended RAM, the FBP version works.

The Super Charger comes with a BIOS. It more likely clear the RAM first then boot up the play tape screen.

If people told you in the other thread that CBS ram-plus games initialized the RAM. Then it's most likely that the CBS RAM boot up at an unknown state.

 

Many old system boot up at an unknown state like NES, SMS, Colecovision, and etc. SMS, Colecovision and other system that have BIOS most likely clear all RAM before booting. You can bypass the Colecovision BIOS screen to boot the game in an unknown state. So, I have to make sure that my variable have an initial value before it get put on cartridge because Ultimate SD cartridge starts up at an known state since it clears the RAM before booting the ROM.

There's macro you could use to put zero every zero-page, extended RAM.

If you aren't sure, put the game on a CBS cartridge and boot it. I think it'll boot up at an unknown state.

Edited March 9, 2018 by Kiwi

[Thomas Jentzsch]

You should update to 5.1.

[Kiwi]

You should update to 5.1.

Done.

 

I tried it out and phosphor mode works a lot better along with VSYNC on. I usually get tearing because the laptop I have don't have a consistent 60 fps(59.97). I found the new developer setting and the option to randomize the state of the system.

[Mr SQL]

Gameworks.jpg

 

Unchecking Randomize zero-page and extended RAM, the FBP version works.

 

The Super Charger comes with a BIOS. It more likely clear the RAM first then boot up the play tape screen.

 

If people told you in the other thread that CBS ram-plus games initialized the RAM. Then it's most likely that the CBS RAM boot up at an unknown state.

 

Many old system boot up at an unknown state like NES, SMS, Colecovision, and etc. SMS, Colecovision and other system that have BIOS most likely clear all RAM before booting. You can bypass the Colecovision BIOS screen to boot the game in an unknown state. So, I have to make sure that my variable have an initial value before it get put on cartridge because Ultimate SD cartridge starts up at an known state since it clears the RAM before booting the ROM.

 

There's macro you could use to put zero every zero-page, extended RAM.

 

If you aren't sure, put the game on a CBS cartridge and boot it. I think it'll boot up at an unknown state.

 

You don't need to uncheck randomize zero page Kiwi, that gets cleared.

 

The macro idea is a good one and already implemented in BASIC (I don't use generic macros) and documented as a workaround in the manual to clear CBS RAM specifically for Stella.

 

I don't wish to implement it because all the other platforms disagree with Stella and no one is actually putting anything on CBS RAM carts, just talking about it for discussion which isn't the same thing.

 

Another option you have to play in Stella without changing the default options or adding macro code to clear CBS RAM is to just cross compile the game with SuperCharger BASIC instead of Flashback BASIC

 

0 if joy0up=1 then player0y=player0y+1:t=1-t:missile1y=missile1y+t else player0y=player0y-t:t=1-t:missile1y=missile1y+t

1 if joy0left=1 then player0x=player0x-1:missile0y=missile0y+1 else player0x=player0x+2:missile0y=missile0y+1

2 missile1x=missile1x+1:missile0x=missile0x+t:AUDV0=R(l):COLUBK=0

3 if g=0 then for j=0 to 3:player0(j)=pl(j):player0colors(j)=p2(j):next j else goto 5

4 for x=20 to 70 step 10:for y = 0 to 19:vwpixel(x,y,on):next y,x:player0y=50:player0x=52:BYTErowoffset=120:g=1

5 if e>7 then e=0:BITIndex=BITIndex+1:COLUP1=l*10 else e=e+1:return:data pl 240,255,127,240

6 if l<20 then l=l+1:x=BITIndex/10 else l=0:x=BITIndex/10:data p2 $36,$64,$76,$36:data R 3,8,2,0,3,8,8,5,3,0,3,5,8,8,5

7 if b=0 then x=BITIndex+10:vwpixel(x,R(l)+10,flip):vwpixel(x,R(l)+11,flip):data R2 5,8,5,3,0,2

8 if CXP0FB=130 or CXM1P>127 or CXM0P>127 then CXCLR=0:COLUBK=$34:AUDC0=4:AUDF0=l:AUDV0=31:g=0:BITIndex=0

9 if BITIndex>71 then BITIndex=0 else for j=0 to 9:rowcolors(j)=rowcolors(j)+2:next j:scrollvirtualworldtoggle=1

 

With larger games I do add the BASIC macro to clear the CBS RAM for Stella so people can enjoy them everywhere - Stella is a popular emulator.

 

This minor incompatibility is easy to resolve but I suggest Stella adopt the defaults that every other programming team is using for CBS RAM (Harmoy, Melody, Encore, Cuttle Cart, Javatari and the Atari Flashback Portable console; I have to support all of those too and it would make it easier if they used the same standards/defaults).

 

Here's a much tougher and more interesting fact of emulation involving artifact colors rendered over NTSC, and there are emulators that can actually do this for other systems that could serve as a guideline:

 

https://www.youtube.com/watch?v=aghqgf6qqRw

[alex_79]

Yeah, I'm sure the Stella team will consider adding an option to emulate "sticking a fridge magnet on a CRT screen to mess up the colors". No 2600 emulator would be accurate without that.

[Mr SQL]

Yeah, I'm sure the Stella team will consider adding an option to emulate "sticking a fridge magnet on a CRT screen to mess up the colors". No 2600 emulator would be accurate without that.

There's no fridge magnet Alex, I wrote commercial games with artifacting in the 80's, and it's equally applicable to the 2600 just not generally done given the large palette. The Immortal John Hancock and Metal Jesus filmed this effect off of CRT in their review, so it's been confirmed and it is possible to make an LCD emulate it or we wouldn't see it.

 

It's just another way to push the technology, and adding a high framerate for full screen animation is like putting a supercharger on artifacting; maximizes chroma bleed (that's why composite mod's don't always reproduce artifact colors well, the signal is too clean).

 

Try WARPDRIVE in Javatari or Stella and use the BW switch to activate the WARP, then try it on CRT over an RF connection (Vader has more bleed than a Jr, models vary) and see the difference for yourself:

 

http://javatari.org/?ROM=http://relationalframework.com/WARPDRIVE_AFP.bin

[Omegamatrix]

 

Well since no one is making CBS RAM carts all systems including the real hadware zero the emulated CBS RAM except Stella.

This simply is not true for real hardware. We tested that and proved that. Please re-read what you quoted and concured to me here:

 

http://atariage.com/forums/topic/276328-gates/?p=3981450

 

In what you quoted I would ask you to focus on this part:

CBS extra ram is also not zeros. Here's an old post I made 8 years ago which has interesting insights into CBS ram (FA bankswitching). Also this post I made in the same thread mentions other FA dumps on the net which had different values in the ram. I investigated old dumps from Rom Hunter's V1 collection (long, long ago). Some of the FA dumps had $FF and $7F in the ram locations. Others had $F0, $F4, and $FC. So it does not appear consistent or reliable, and certainly not all zero's.

 

Now here is that part with some extra help:

 

 

CBS extra ram is also not zeros. Here's an old post I made 8 years ago which has interesting insights into CBS ram (FA bankswitching). Also this post I made in the same thread mentions other FA dumps on the net which had different values in the ram. I investigated old dumps from Rom Hunter's V1 collection (long, long ago). Some of the FA dumps had $FF and $7F in the ram locations. Others had $F0, $F4, and $FC. So it does not appear consistent or reliable, and certainly not all zero's.

That CBS ram is always zero is simply not true. The other emulators got it wrong. This issue is resolved.

[alex_79]

There's no fridge magnet...

Too literal...

 

Those curved concentric color variations in the video you linked are tipically caused by the shadow mask of the TV set being magnetized: this deviates the three electron beams (one for each of Red, Green and Blue) making them hit the wrong coloured phosphors. This can be caused by a permanent magnet brought near to the screen (unshielded speakers for example) or and unshielded electrical appliance used near to the TV or even a lighting strike near the house.

Usually this can be corrected using an external degaussing coil, but if the magnetic field was too strong, the damage is permanent.

The console is not generating those artifacts, altougth the specific image displayed might make them more or less visible (e.g. large solid colored areas VS thin lines).

it's just a bad TV.

https://www.youtube.com/watch?v=3pVLizAHby4

 

 

...I wrote commercial games with artifacting in the 80's...

I don't care.

 

...and it's equally applicable to the 2600...

Past threads on this subject showed you don't even have a basic understanding about TV signals and how color artifacting was obtained in old computers (here an example of reasoned discussion on the subject), so I'm not inclined to trust your word on this without a technical explanation.

 

 

The Immortal John Hancock and Metal Jesus filmed this effect off of CRT in their review

Who? I'm not going to search for this video just because you're too lazy to provide a link.

Unless the same TV is used, I bet that "swirl" effect is not there. There's a remote possibility that their TV has a purity problem too and even in that case the chance that the color distortions are exactly the same is near to zero.

 

I guess I fed the troll more than enough, so I call it quits.

 

 

 

 

 

 

Edited March 10, 2018 by alex_79

[Mr SQL]

This simply is not true for real hardware. We tested that and proved that. Please re-read what you quoted and concured to me here:

 

http://atariage.com/forums/topic/276328-gates/?p=3981450

 

In what you quoted I would ask you to focus on this part:

 

Now here is that part with some extra help:

That CBS ram is always zero is simply not true. The other emulators got it wrong. This issue is resolved.

 

I think you misinterpreted this:

 

"Well since no one is making CBS RAM carts all systems including the real hadware zero the emulated CBS RAM except Stella. "

 

It's true because the keyword there is emulated - everyone else zero's their emulated CBS RAM to make it more compatible.

 

Flashback BASIC and SuperCharger BASIC games are played off of the SuperCharger, Cuttle Cart, Melody boards, Harmony/Encore, the Atari Flashback Portable, Javatari and Stella. All of that CBS RAM is emulated, and it's all zeroed by default for greater compatibility except Stella unless you change settings. Why choose to be less compatible?

 

 

I guess I fed the troll more than enough, so I call it quits.

 

Alex I liked the superchip dump because it was genuine research.

 

But you never wrote any games with artifacting (now or in the 80's) nor any programming languages, frameworks or soft blitter chips.

 

You're an expert in all of those technologies, so you shouldn't need to throw insults to prove it. Please go on

 

The link to the video with the artifacting is on the Flashback BASIC site next to the wall of games.

[Omegamatrix]

 

I think you misinterpreted this:

 

"Well since no one is making CBS RAM carts all systems including the real hadware zero the emulated CBS RAM except Stella. "

 

It's true because the keyword there is emulated - everyone else zero's their emulated CBS RAM to make it more compatible.

 

Flashback BASIC and SuperCharger BASIC games are played off of the SuperCharger, Cuttle Cart, Melody boards, Harmony/Encore, the Atari Flashback Portable, Javatari and Stella. All of that CBS RAM is emulated, and it's all zeroed by default for greater compatibility except Stella unless you change settings. Why choose to be less compatible?

Just to be clear here, there are only 3 games CBS made with their extra ram:

 

Mountain King

Omega Race

Tunnel Runner

 

So please don't start talking about the SuperCharger, Basic Games, and the AFP as they have nothing to do with these games.

 

The extra ram for these 3 games is stored on the physical carts, and we have demonstrated that this extra ram is not all zeros at power on. Randomized ram for CBS carts needs to be the default behavoir of Stella as it accurately reflects the real thing, and the real thing IMHO will always be a true CBS cart.

 

As a developer following the correct behaviour of the real thing is essential. If I wrote a new game and had it put on an old CBS board, then I sure would not depend on the ram being zero. My game would fail and that would be foolishly my own fault, for not clearing ram.

 

This is what makes Stella a great emulator. It emulates the real thing and helps the developer catch problems. Your games breaking in Stella are a problem. You just don't want to acknoweldge it is a problem, and instead want to say it is a problem with Stella. In fact Stella is the one that has it right.

[Mr SQL]

Just to be clear here, there are only 3 games CBS made with their extra ram:

 

Mountain King

Omega Race

Tunnel Runner

 

So please don't start talking about the SuperCharger, Basic Games, and the AFP as they have nothing to do with these games.

 

.

 

All of the games made with Atari Flashback BASIC are CBS RAM games, and most of them are SuperCharger games too as they cross compile.

 

My development languages target emulated RAM and 80's RAM respectively because that's what I have to support - there are real SuperChargers in use playing SuperCharger BASIC games but all of the consoles playing Atari Flashback BASIC games have to rely on emulated CBS RAM (I don't know of anyone putting a Flashback BASIC game onto a real CBS RAM cart to play it on a real console, they use a flash cart).

 

The CBS RAM and SuperCharger memory access schemes work very differently so cross compatible BASIC compilers requires a level of abstraction to do this, and it's not perfect but nearly all of the games can cross compile. Unless you need a little more RAM (SuperCharger BASIC) or a little more ROM (Flashback BASIC has an extra 1K).

 

I support Stella too and have two workarounds in the BASIC Programming manual to get Atari Flashback Games running in Stella - either recompile it as a SuperCharger BASIC game or add a line of code to clear the emulated CBS RAM.

 

I noticed I need to document modulus, having used it recently; that's on my todo list. I think I'll leave the choice to support Stella as the programmers option for Atari Flashback BASIC games.

 

Stella would simply have less games in the doesn't run on stella folder if they adoped wider compatibility settings; that's the reason other Atari platforms with emulated CBS RAM zero it by default.

 

Please share your perspective in this context of BASIC, the SuperCharger and the AFP and all of the emulators and consoles being used to play games because I am specifically supporting them with interoperable technology.

 

To be clear on terminology would you agree that all of the batari BASIC and Assembly games designed to use superchip RAM, are superchip RAM games?

 

[DirtyHairy]

But you never wrote any games with artifacting (now or in the 80's) nor any programming languages, frameworks or soft blitter chips.

 

You're an expert in all of those technologies, so you shouldn't need to throw insults to prove it. Please go on

 

I don't give a f*** about what people claim they did when no-one I know and respect was watching; I only care about what they have to show. Alex has shown that he knows what he is talking about many times, and he has been a valuable help in developing Stella. The only achievement from that I can see on these forums is your BASIC compiler and the scrolling playfield it provides. This is an achievement, but you are constantly damaging it by decorating it with absurd technobabble ("soft blitter chip"), and everything else that you might have to say drowns in a constant stream of misleading claims, half-truths and outright nonsense. This is unfortunate, because the consequence is people that won't touch your stuff with a ten foot bargepole; no matter how interesting it may be --- ultimately, you are hurting yourself.

 

The heart of the current discussion is that your compiler emits buggy code: it fails to initialize RAM properly. This is a simple bug, and it has an equally simple fix that will not change the number of BASIC lines your compiler has to process: include proper initialization of the hardware in the generated code, it can't be more than ten opcodes. There is nothing shameful in admitting this either: everyone who develops software knows that bugs are not a defect of the developer, but an unavoidable artifact of the development process. Instead, you first claim that your code is correct and that the hardware description in Stella is wrong and, after being disproven, just drop the hardware argument and continue to postulate that Stella is not following some hypothetical consensus on emulated VCS hardware that you postulate. This is nonsense: there is no such consensus, intialization with zero is just a simple default and, and in many languages (including javascript) *the* default for uninitialized arrays --- the runtime performs the initialization (hint-hint). Randomization needs implementation work and does not increase compatibility, this is why most emulators don't bother to do it, but it is part of an accurate hardware description and helps developers to identify buggy code.

 

So, instead of admitting a simple error, you try to make a fool of everybody who invests their time to talk to you. This is not only offensive, but you ultimately only succeed in making a fool out of yourself. Do yourself and your work a favor, fix your bug and start taking the input offered to you by others seriously. I, for one, am not participating in this discussion any longer.

Edited March 11, 2018 by DirtyHairy

[Mr SQL]

 

I don't give a f*** ... The heart of the current discussion is that your compiler emits buggy code

 

You don't get that I'm supporting real SuperCharger hardware defaults and emulated CBS RAM defaults; if you want to focus on real hardware, here is that SuperCharger binary flushing the unpatched Stella bug again:

BreaksOnSC.bin

 

Without getting angry and throwing insults, consider that batari patched the Harmony/Encore/Melody firmware so it might be a good idea to follow suit.

 

Here's a GATES GATE CRASHER contest you can participate in using any emu or real hardware Atari 2600 platform you like, why not have some fun and give it a try?

 

http://atariage.com/forums/topic/276511-gates-gate-crasher-atari-contest/

[Mr SQL]

 

You don't get that I'm supporting real SuperCharger hardware defaults and emulated CBS RAM defaults; if you want to focus on real hardware, here is that SuperCharger binary flushing the unpatched Stella bug again:

BreaksOnSC.bin

 

Without getting angry and throwing insults, consider that batari patched the Harmony/Encore/Melody firmware so it might be a good idea to follow suit.

 

Here's a GATES GATE CRASHER contest you can participate in using any emu or real hardware Atari 2600 platform you like, why not have some fun and give it a try?

 

http://atariage.com/forums/topic/276511-gates-gate-crasher-atari-contest/

 

And here's my CBS RAM research on the new Atari Flashback Consoles; that hardware works differently than Stella too:

 

http://atariage.com/forums/topic/260383-flashback-portable-f4-bankswitching/?p=3666740

 

http://atariage.com/forums/topic/259166-flashback-portable-needed-controller-hacks/page-4

 

imo Stella should support all the Atari 2600 consoles, particularly the one running an official Atari emulator.

[Keatah]

Does the afp emulator properly reproduce the tribal sound and solid bars?

[Mr SQL]

Does the afp emulator properly reproduce the tribal sound and solid bars?

 

The Flashback emu does the graphics well and the gameplay, the sound is off a bit like it is in Stella.

 

It was claimed Stellerator more accurately reproduces the tribal sound

 

I actually tried it in Stellerator but I think I must have grabbed the old link from the thread.

[+sramirez2008]

Hi everyone. I recently purchased my first Raspberry Pi (model 3 B+) and quickly installed Stella via the following command: sudo apt-get install stella.

 

Well it turns out that the install grabbed version 4.7.3. This may sound silly, but I'm new to Linux and am not sure how to upgrade from 4.7.3 to 5.1.1. Don't want to mess things up, trying this on my own.

 

Appreciate any help.

 

Thanks.

[mr_me]

You should run "sudo apt-get update" before installing packages. It updates the package index. Then try the install again. It could be that 4.7.3 is the latest in the repository. The Stella website doesn't have a compiled version for Raspberry Pi. You can try compiling from source yourself. Or get one compiled by others (e.g. Retropie); not sure what version of Stella Retropie has and it may not be compatible with current Raspbian.

Edited March 30, 2018 by mr_me

[+johnnywc]

I just installed 5.1.1 for Windows 10 and I'm having an issue with Savekey, but only for my games (Scramble, Super Cobra and Mappy). No matter what I do I can't get Stella to detect that I have a Savekey configured in the right port.

 

I have changed the Controllers for the Right port to be Savekey and restarted the ROM using Ctrl-R, but my games do not detect a Savekey. I've also tried via the command line with -rc savekey but still no luck.

 

I tried with 4.7.3 and all 3 of my games can find the Savekey with that version (as it does on real hardware). What's strange is that I tried Juno First on 5.1.1 and it *does* find the Savekey properly. I'm not sure if it's something in my code, but like I said it does work on real hardware and I had no issues prior to 5.1.1, so I'm not sure if it's Stella or something else.

 

I have uninstalled and re-installed Stella, deleted the entire AppData\Stella directory and re-installed, even installed the 32-bit version but no difference. Is there something in the registry that I may need to clean out?

 

Any one else experiencing the same issue? I've attached the final ROMs for Scramble & Super Cobra Arcade if anyone has a minute to try it in Stella 5.1.1 on Windows with Savekey enbaled; you should see "SAVEKEY FOUND" on start up with the Atari Age splash screen. Remember, you can enable Savekey by going to Options|Controllers and setting the Right controller to Savekey (or Atarivox) and then reloading the ROM using Ctrl-R.

 

Any help is appreciated!

 

Thanks,

John

scobra_FINAL_NTSC.bin

scramble_final_NTSC.bin

[Thomas Jentzsch]

Is only the message missing or do the games also not load and save scores?

[+johnnywc]

Is only the message missing or do the games also not load and save scores?

Hi TJ,

 

Message is not displayed, and I stepped through the code and it's not detecting the Savekey. Really odd behavior for sure!

 

Thanks,

John

[+stephena]

Github issue created for this: https://github.com/stella-emu/stella/issues/312

 

If possible, please direct further responses to the Github issue, so we can keep all relevant info in one place.

[+stephena]

Stella 5.1.2 is now released, which addresses the following:

• Fixed bug with SaveKey autodetection; some ROMs were not correctly detecting that a virtual SaveKey device was plugged in. This notably fixes issues in "Super Cobra" and "Scramble" ROMs.
• Make previously mentioned ROMs use the SaveKey device by default.
• Fixed bug in UI navigation with joystick hat movement.

The downloads are available at the usual place. Also, as always, donations are appreciated.