Jump to content
IGNORED

Stella 5.1 released


stephena

Recommended Posts

Hm... A release full of new features results into discussing folders only.

 

That definitely makes me wonder... :ponder:

 

It's probably something with the changing & new demographics of people entering into the hobby and some old hands moving on.

 

People taking it all for granted. Excessive smartphone usage changing how people consume tech. Tech is just supposed to work and be disposable and upgradeable if it doesn't. Smartphone usage decreases appreciation for technical excellence.

 

And then there's the FPGA stuff. People instantly see that FPGA = hardware = exact replica. Exact replica is seen as something software can never achieve. Software is cheap, and free, and therefore not enough effort has gone into it. FPGA = expensive = good quality. I hear it all the time. True or false, it's how they see it and their minds tend to be closed to other solutions. Hate to say it, emulation is still fighting a bad rap with accuracy and lag. And even "because cartridges"! Buggy and bloated PC's don't help. And a slim'n'trim Linux is not an option for most. The whole situation is as bad as the Flat Earthers

 

---

 

BTW: the wife is being a tease because she found a way to stop the rogue folder creation but isn't telling me yet. :mad: SO FOLDERS!! Or folded tacos!!

  • Like 2
Link to comment
Share on other sites

Ah, greatness! ;-)

The 'time machine' will be priceless to hunt down rare bugs. Thanks a lot for keeping this gem alive and active!

Stella is usually the first thing I compile on new computer setups and I am always amazed how well it all works out of the box.

I am certain that your efforts will pay off in better code/releases in the long run.

Cheers,

Martin!

  • Like 2
Link to comment
Share on other sites

Tiny fix in documentation? It says:

-ppblend <number> Set "Display.PPBlend" property, used for phosphor effect (0-100). Default is 77.

 

Isn't the default 50?

 

---

 

And while in-game, doing TAB> Video Settings> TV Effects> and adjusting the phosphor here has no effect, but the other sliders work. You must exit the game and reload for the phosphor change to take place. Shouldn't all the sliders work all the time?

 

Though the in-game hot keys ALT-I and ALT-O work to change the phosphor.

Link to comment
Share on other sites

Tiny fix in documentation? It says:

-ppblend <number> Set "Display.PPBlend" property, used for phosphor effect (0-100). Default is 77.

 

Isn't the default 50?

Are you sure you have the latest doc for 5.1? Mine says "Default is whatever is specified for tv.phosblend."

Link to comment
Share on other sites

  • 2 weeks later...

Just made a suggestion of upgrading SDL.

 

I work in Mac OS X in windowed mode because I find slow the transition to full screen (nifty effect anyway), but when opening the debugger in windowed mode it opens with full screen size so I lose several lines at bottom, so I've located the portion of code for desktop size in order to remove dock from it but it requires SDL-2.0.5 at least and Stella is compiled with SDL-2.0.4.

Link to comment
Share on other sites

Wonder if there should be a switch to determine how Stella behaves on power-up, I ask because this ROM doesn't work. Something with the sound I guess.

http://atariage.com/forums/topic/276328-gates/

 

 

The fact that the "AFP version" linked above doesn't work in Stella has nothing to do with audio, but is caused by the ROM not initializing the in-cartridge RAM --- it relies on the initial RAM values which are randomized by Stella, which matches the behavior of (most?) RAM. It is theoretically possible that CBS RAM initializes to zero, but no-one has ever tried to probe this. I have laid out a way to test this in the thread you quote, and such a test would be the only reason to reconsider the current implementation. In absence of data on the behavior of historic hardware, we make educated guesses and extrapolate, and common lore seems to be that SRAM does not power up in a well-defined state.

 

The audio "issue" is the current Audio implementation in Stella which is not cycle-exact. On the other hand, I compared the supercharger version of gates between Stella 5.1 vs. 6502.ts/Stellerator (which is based on work by crispy and cycle-exact) to my current wip audio code in Stella (which is ported from 6502.ts and cycle exact) to my PAL Jr., and, to my ears, the "Tribal Drums" sound the same everywhere --- check it out yourself :)

Edited by DirtyHairy
  • Like 2
Link to comment
Share on other sites

I understand about not making changes to Stella (or any emu) to support non-standard programming practices. It shouldn't be done. And I don't care about the AFP rom. Just the Supercharger version.

 

At the same time I dislike that he doesn't take time to properly initialize RAM.

 

Also, if we don't know the state of CBS RAM on power up for certain, wouldn't it be best to support both random and zero'd conditions through an option? After all, who's to say what is right or wrong until solid evidence is shown.

 

---

 

Another quick question. Not related to CBS RAM, but instead RIOT.

 

The StartupValues.bin ROM shows random data that is different on each power up in earlier versions of Stella. In the latest 5.1 release, it's all Zeros. That supposed to be that way?

 

Never mind, found the developer's menu..

Edited by Keatah
Link to comment
Share on other sites

Another quick question. Not related to CBS RAM, but instead RIOT.

 

The StartupValues.bin ROM shows random data that is different on each power up in earlier versions of Stella. In the latest 5.1 release, it's all Zeros. That supposed to be that way?

Stella has an option for randomizing RAM on init.

 

Previously this option was hidden in the debugger and most likely you had it enabled. Now the option can be found in 'Developer settings', were it got a new name due to the player vs developer settings. Default for player mode is all zero.

  • Like 3
Link to comment
Share on other sites

I understand about not making changes to Stella (or any emu) to support non-standard programming practices. It shouldn't be done. And I don't care about the AFP rom. Just the Supercharger version.

 

At the same time I dislike that he doesn't take time to properly initialize RAM.

 

Also, if we don't know the state of CBS RAM on power up for certain, wouldn't it be best to support both random and zero'd conditions through an option? After all, who's to say what is right or wrong until solid evidence is shown.

 

 

Keatah, I could add a line of code to make the game compatible with Stella but it's a 10 line BASIC game.

 

Adding another line would disqualify the AFP version - the SuperCharger version and the AFP version are cross compiled from the same 10 lines of BASIC.

 

I'll add such a line to most of my games, but not to break a 10 liner by making it 11 lines, particularly when all other emulators and hadware setups that we can identify disagree with the Stella implementation; best practice suggests there's likely a reason for it.

  • Like 1
Link to comment
Share on other sites

I don't have any CBS cartridge with RAMPLUS chip, but I just dumped a few times the ram of a superchip game (original STARGATE cartridge from my original collection), powercycling after each dump:

dump1:
00000000  37 54 91 eb 33 8f da 5d  91 a2 0c c5 dd 4a 71 0a  |7T..3..].....Jq.|
00000010  3f 6c 9a c8 e2 1f 1a ca  a9 ea ca 51 10 db 84 e9  |?l.........Q....|
00000020  3a 60 f3 55 11 63 cb 4b  f1 16 ee f1 d2 89 59 4c  |:`.U.c.K......YL|
00000030  62 2b 35 9d b2 55 06 ca  73 af 0a 76 90 6d 74 7a  |b+5..U..s..v.mtz|
00000040  92 1b 3f 0c c7 30 da 5c  e2 8a fa 7a b2 ef f6 b9  |..?..0.\...z....|
00000050  5c b7 5c ed 52 cd 0a 8d  93 61 97 34 3d 50 a8 3a  |\.\.R....a.4=P.
00000060  b1 34 2e a5 41 95 85 65  cb 21 5c 77 10 0b 67 d7  |.4..A..e.!\w..g.|
00000070  c2 b8 45 6c b8 34 fc 6d  eb 24 a6 eb 0e 40 19 db  |..El.4.m.$...@..|

dump2:
00000000  15 ef b0 e8 36 cd e2 5e  c4 a6 4c be 19 6e 65 4a  |....6..^..L..neJ|
00000010  3f 78 90 c9 4a 0b 9f ee  89 ae 7a 49 18 9e 84 6e  |?x..J.....zI...n|
00000020  3b e0 c3 95 01 71 7b 48  f4 32 f6 31 fa 81 d9 5e  |;....q{H.2.1...^|
00000030  6a 61 29 d5 bb 71 0a 4a  32 a5 08 70 a0 6d b4 1f  |ja)..q.J2..p.m..|
00000040  da 79 6b 0d cf 7c 4f d8  22 8e fa 4a 73 cf be fd  |.yk..|O."..Js...|
00000050  14 97 5c ed 7e c5 1a 88  17 6f 36 74 3d 74 84 1e  |..\.~....o6t=t..|
00000060  31 7c 3e e2 41 11 9f e5  ca ff 1c 36 19 28 63 f7  |1|>.A......6.(c.|
00000070  e2 ba 45 e9 dd 34 fc 41  f9 74 6f ab 8c f9 5b 8b  |..E..4.A.to...[.|

dump3:
00000000  27 fd d0 e3 71 8d fa df  91 a3 cc 75 d9 6a 71 ea  |'...q......u.jq.|
00000010  1f 4c 9b c9 ca 0f 1c 82  3d a8 4b 71 10 1f 84 6d  |.L......=.Kq...m|
00000020  7a e0 f3 55 11 61 9a 4e  f0 92 f0 f1 72 88 d9 5c  |z..U.a.N....r..\|
00000030  63 2f 3d ed 3b 75 0e 6a  7b af 0a 76 84 6f 37 fb  |c/=.;u.j{..v.o7.|
00000040  fa fb 7b 6d ff fc db fe  fb be fa fa fa ef fe fb  |..{m............|
00000050  0c 97 0c ac 5a 85 03 0c  17 00 07 20 2d 50 84 18  |....Z...... -P..|
00000060  b1 74 fe a5 41 95 95 f5  ca f5 de 77 10 26 25 f5  |.t..A......w.&%.|
00000070  82 91 4d 25 1d 14 ec 0d  cb 20 ae 8b 0e 48 1d 8b  |..M%..... ...H..|


The ram is definetely not cleared at startup and it's different each time. (I only dumped from the read port at $1080-$10ff, of course, and if I dump without power cycling the content stays the same, so the dumper software isn't affecting the result)

  • Like 2
Link to comment
Share on other sites

Awesome research Alex, it would be best if we had a CBS RAM dump but the superchip is close enough it likely has similar characteristics.

 

So which console and product group should Stella emulate? You actually have a similar support issue that I have with Flashback BASIC and SuperCharger BASIC - I want them to run everywhere with maximum compatibilty, and you want maximum compatibility with all Atari games.

 

So far you have a solution to patch the RAM behavior changing settings on a menu.

 

I have a similar solution to add a line of code, but our defaults don't match in this instance creating incompatibilty.

 

Products with defaults that match: Flashback BASIC, Harmony/Melody, Atari Flashback Portable Consoles, Javatari.

 

Defaults that don't match the above group: Stella and likely vintage CBS RAM chips that no one uses anymore to create carts or even to test (would account for the reason everyone else is clearing CBS RAM and Sara RAM; we couldn't compare it to the vintage chips for not having a model).

 

I think I still have to support the marjority of Atari platforms and use a workaround for Stella, putting in a hotfix when space allows for most games.

 

Keatah what are your thoughts?

 

Link to comment
Share on other sites

It's really very simple. Yet the devil is in the opinions. Stella should match real hardware as close as possible. If something works on real hardware then it should work in Stella. There is no debate on that. It's either done right or wrong. No in between.

 

If there are two versions of something in real hardware then a toggle should be made. Not unlike switching between variants of the 8-bit machines in Altirra. 800 or 800XL. Computer console or 5200 game console. Switch between them.

 

If CBS-SARA RAM powers up dirty & random then Stella should emulate that. If CBS-SARA RAM powers up in a known consistent state reliably (like all 0's) then Stella should emulate that. If it is unknown what the proper (or actual) state is then it is suggested that both modes be emulated. If both conditions have been observed over the years, then a toggle option is required to accommodate both versions. Otherwise the emulation is incomplete.

 

If real hardware is proclaimed to operate one way and has become accepted standard over the years, and software is using that accepted standard, then Stella should follow it. Especially in absence of proof otherwise.

 

AFP isn't considered "real hardware". It is buggy emulation. Hence all the patched roms for it. AFP is different enough at a low level to, well, be a variation. It is not Stella's place to emulate AFP's quirks & differences, unless Stella developers want to extend the scope. Maybe write a separate AFP emulator?

 

It is always good practice to zero-out or pre-set to known conditions RAM and variables and such things and continue from there. Programs should set-up the machine as needed.

 

If it is known there are different versions of real & expansion hardware and there slight differences in behavior between the versions, then it also becomes the responsibility of the programmer to cover those versions. Especially if it is a simple matter like something in the boot sequence or initialization.

 

Programs should, when possible, pertinent, and practical, check to see what version hardware they're running on.

 

And around'n'round we go. In the end, it is the emulator's task to mimic the real deal.

Edited by Keatah
  • Like 1
Link to comment
Share on other sites

I promised myself I wouldn't comment on this again, but it just won't seem to die, so here I am. These are the facts:

  1. On some systems, RAM is zero'ed; on others it isn't.
  2. It isn't consistent when each case happens; it could be one or the other.
  3. There is no definitive research that shows that it should work "this way" or "that way".
  4. So we offer the option to do either one: by default, RAM is zero'ed, but it can be toggled to be randomized instead.

As for Stella being like real hardware, what real hardware? By definition we have two classes of real hardware; one that zero's RAM, and one that doesn't. Stella happens to default to zero'ing RAM, but can be toggled. Other emulators variously default to either zero'ing or randomizing. Which one is correct? The answer is they both are! When you have two possible sets of initial conditions, both can be correct (BECAUSE THERE'S NO WAY TO DIFFERENTIATE BETWEEN THEM).

 

In any event, the entire reason these options were added to Stella is so that a developer could see whether different initial conditions would have an adverse effect on their code. If it did, then they could modify their code to fix their assumptions (IE, if you have a ROM that is sensitive to initial RAM conditions, you modify your code to take that out of the equation -> IOW, you zero your own RAM).

 

Again, this is what we have:

  1. A ROM that is sensitive to initial RAM conditions.
  2. A set of hardware that behaves differently under different circumstances (with no clear consensus on which behaviour is correct).

How can anyone not see that the proper approach here is to modify the ROM to zero its RAM? If it wants its RAM to be guaranteed to start in a known state, IT SHOULD MAKE IT SO, AND ZERO THE RAM ITSELF.

 

I don't understand how we can even be still talking about this two years later. Arrgh.

  • Like 8
Link to comment
Share on other sites

I promised myself I wouldn't comment on this again, but it just won't seem to die, so here I am. These are the facts:

  1. On some systems, RAM is zero'ed; on others it isn't.
  2. It isn't consistent when each case happens; it could be one or the other.
  3. There is no definitive research that shows that it should work "this way" or "that way".
  4. So we offer the option to do either one: by default, RAM is zero'ed, but it can be toggled to be randomized instead.

As for Stella being like real hardware, what real hardware?

 

 

 

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

 

And the AFP is real hardware too since it's a 2600 powered by an official Atari emu.

 

Two years ago we were talking about the SuperCharger bug; Fred fixed it in the Harmony/Melody firmware but Stella still has that bug despite that you like to insist it's not a bug (so what did Fred fix, an imaginary bug?)

 

The reason you're still talking about it two years later might be because you keep bringing it up; I already have a workaround published in the Flashback BASIC manual to zero the CBS RAM for Stella compatibilty. It's there so that developers can make the games work on Stella platform too since it's an Atari platform, but it's not a best practice for writing 10 liners (now or in the 80's).

 

btw I think those Jr's with the bad TIA's are hardware emulation; not too different than software emulation in that respect. They can't play Kool-aide man :)

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