Jump to content
IGNORED

The Stacks


Zoyx

Recommended Posts

6 hours ago, hizzy said:

This game looks nuts. Pedophiles, electric cloud thingees. I think I will stick with the movie. lol

Big fan of the movie? Read the book... it has almost NOTHING to do with the movie at all and if you grew up in the 80's it will hook you almost immediately. The book is my personal favorite of all time. 

  • Like 3
Link to comment
Share on other sites

2 hours ago, Jason123 said:

Big fan of the movie? Read the book... it has almost NOTHING to do with the movie at all and if you grew up in the 80's it will hook you almost immediately. The book is my personal favorite of all time. 

I agree 100%.  I got the audio book and listened to it to and from work.  Fantastic book and not a lot of parallels with the movie.  The audio version is ready by Wil Wheaton and he did a great job with it.

  • Like 2
Link to comment
Share on other sites

  • 3 months later...
  • 2 years later...
  • 1 month later...

Hi! This is an awesome original title for the Atari 2600, lots of things to do, nice graphics and animations!

Unfortunately there's an issue on Stella. Not sure if this was mentioned already, but When I run the file there's a random chance of the game start all messed up, which means I have to close and start the rom again. The issue only happens sometimes and seems to be some sort of desync.

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

1 hour ago, Phobos867 said:

Unfortunately there's an issue on Stella. Not sure if this was mentioned already, but When I run the file there's a random chance of the game start all messed up, which means I have to close and start the rom again.

That's a bug in the game: it doesn't initialize the decimal flag and glitches if the flag happens to be set when the game starts. On a real console, the state of the CPU flags and registers are undetermined at power on, and the game can glitch in the same way, requiring a power cycle to start correctly.

Turn off the option to randomize the flags to hide the bug.

stacks1.thumb.png.da4e820e3ea4fd0ae3d80b7e55c08c1b.png

stacks2.thumb.png.b92346e695b4abe183d25ead84e02c1b.png

  • Like 2
  • Confused 1
Link to comment
Share on other sites

This Stella "feature" can repeatedly set the decimal flag under testing and is not even properly randomized. It is a new Stella bug,

I added a patch to some ROM's to resolve this. The real hardware rarely if ever sets the decimal flag or perhaps it may be an elusive bug that depends on the CPU variant. This is another instance of an overdeveloped emulator breaking games, imo better to get the emulation right first. Why break ROM's instead? 

 

Link to comment
Share on other sites

1 hour ago, Mr SQL said:

This Stella "feature" can repeatedly set the decimal flag under testing and is not even properly randomized. It is a new Stella bug,

I added a patch to some ROM's to resolve this. The real hardware rarely if ever sets the decimal flag or perhaps it may be an elusive bug that depends on the CPU variant. This is another instance of an overdeveloped emulator breaking games, imo better to get the emulation right first. Why break ROM's instead?

It's common knowledge that the first thing you should do in ANY 6502 program that runs at startup is to initialize the decimal flag.  It's not a good strategy to depend on things being properly randomized.

 

A good programming strategy is to ALWAYS set the CPU / Memory to a known state.

  • Like 2
Link to comment
Share on other sites

Also, by default Stella runs with the Player settings, which doesn't do these kind of initial randomizations. Only if you explicitly switch Stella to Developer settings, it will do these randomizations to help the developer create more robust ROMs.

  • Like 3
Link to comment
Share on other sites

3 hours ago, Dionoid said:

Also, by default Stella runs with the Player settings, which doesn't do these kind of initial randomizations. Only if you explicitly switch Stella to Developer settings, it will do these randomizations to help the developer create more robust ROMs.

 

Just now, SpiceWare said:

How dare Stella offer an optional feature, that's turned off by default, to help developers discover bugs in their code that only show up on a subset of real 2600 consoles 🙄

 

Not always - as a member of the Retron77 development team I encountered this bug on the new Stella firmware for the Retron77 being on by default and had to patch ROM's for it for compatiblity. If it was always off by default then it wouldn't be an issue.

 

4 hours ago, splendidnut said:

It's common knowledge that the first thing you should do in ANY 6502 program that runs at startup is to initialize the decimal flag.  It's not a good strategy to depend on things being properly randomized.

 

A good programming strategy is to ALWAYS set the CPU / Memory to a known state.

 

Not always - after the loading bars were added for SuperCharger games for the UnoCart (and possibly ported to Stella) I had to add a patch to turn off symmetric playfields.

The real hardware does not do this so did not require the patch but I want to support the different platforms. 

When an emulator or emulation stub in this case breaks compatibility with the real hardware instead of emulating it properly it creates it's own platform that needs to be supported as another Atari 2600 console. Patches I added to CBS RAM to allow it to function on Atari's own Portable consoles in-house emulator are similar.

 

Stella is the most difficult platform to support possibly for having many developer opinions involved and being written in high level languages in contrast to Z26; Stella broke apart on my demos and had to be replaced with "Technical difficulties" at Silly Ventures live contests when we switched from the real hardware to using Stella simply by being less efficient than Z26 (not written in asm anymore). 

 

Link to comment
Share on other sites

47 minutes ago, Mr SQL said:

Not always - after the loading bars were added for SuperCharger games for the UnoCart (and possibly ported to Stella) I had to add a patch to turn off symmetric playfields.

Uh, that just enforces that "A good programming strategy is to ALWAYS set the CPU / Memory to a known state."  

 

 

  • Like 2
Link to comment
Share on other sites

1 hour ago, Mr SQL said:

Stella is the most difficult platform to support possibly for having many developer opinions involved and being written in high level languages in contrast to Z26; Stella broke apart on my demos and had to be replaced with "Technical difficulties" at Silly Ventures live contests when we switched from the real hardware to using Stella simply by being less efficient than Z26 (not written in asm anymore). 

Stella is not difficult to support if you write reliable code... which you seem adverse to doing.

 

I'll say it again:  "A good programming strategy is to ALWAYS set the CPU / Memory to a known state."

 

Now, I can understand that you like to write demo-scene code in which you'd prefer not to do that... BUT, continuing to blame Stella for not allowing you to "cheat" is a bit disingenuous.  If you really want to just target the hardware, you're free to do so.  No one is stopping you.

 

In the modern era, what language an emulator is written in doesn't really have that much bearing on how efficient it is because modern compilers are generally BETTER at producing optimal assembly language / machine code than developers are.  With that said, I have no doubts that Z26 is probably more efficient.  Stella is more focused on supporting modern hardware with cross-platform OS support.

 

All in all, you seem to be hinting that you like Z26 better.  Why didn't SillyVenture use Z26 to run your program?

 

  • Like 1
Link to comment
Share on other sites

2 hours ago, splendidnut said:

Uh, that just enforces that "A good programming strategy is to ALWAYS set the CPU / Memory to a known state."  

 

 

This is a matter of opinion. imo it is not always a good programming strategy, it depends. 

1 hour ago, splendidnut said:

Stella is not difficult to support if you write reliable code... which you seem adverse to doing.

 

I'll say it again:  "A good programming strategy is to ALWAYS set the CPU / Memory to a known state."

 

Now, I can understand that you like to write demo-scene code in which you'd prefer not to do that... BUT, continuing to blame Stella for not allowing you to "cheat" is a bit disingenuous.  If you really want to just target the hardware, you're free to do so.  No one is stopping you.

 

In the modern era, what language an emulator is written in doesn't really have that much bearing on how efficient it is because modern compilers are generally BETTER at producing optimal assembly language / machine code than developers are.  With that said, I have no doubts that Z26 is probably more efficient.  Stella is more focused on supporting modern hardware with cross-platform OS support.

 

All in all, you seem to be hinting that you like Z26 better.  Why didn't SillyVenture use Z26 to run your program?

 

 

That is not a matter of opinion because there was nothing wrong with my code it simply used an innovation to double the amount of cycles available per scanline and multiply the number of cycles available per frame which Stella could not handle initially (broke) and still breaks without very powerful hardware. 

 

Please be more specific; consider my programming examples with a soft blitter for advanced Atari games also breaks VICE without special settings not to drop frames for C64 emulation.

 

The Stella team initially explained no one should write code like that because no one else had done so which is not reasonable for being an innovation, and they followed by adding the innovation to support ARM advanced games. I prefer the Z26 model that is more efficient because it can render on less powerful hardware. Regarding SV we thought Stella could handle it and it can, with very steep hardware requirements and without too many other programs running. The dedicated Retron77 Stella based Atari 2600 console also drops frames running FLUIDCITY for being underpowered. That is a known issue and a good argument for more efficient assembly coding over high-level programming languages.

 

98% of the bottlenecks are generally in 2% of the code, it should be possible to get the Retron77 to show all frames in FLUIDCITY with optimizations, possibly including escaping hotspots in asm or not allowing system interrupts if that is ocuring. 

Link to comment
Share on other sites

49 minutes ago, Mr SQL said:

This is a matter of opinion. imo it is not always a good programming strategy, it depends. 

Sure, it depends.  Whether or not you agree, is on you.  But complaining about the state of the system you're trying to code on as not being reliable, is a bit silly when YOU can control that state.  I'll remove the word always, but repeat: "A good programming strategy is to set the CPU / Memory to a known state."

 

EDIT:

 

At this point, we're way off topic for the Stacks game.  I suggest we move discussions to one of your threads.

 

  • Like 3
Link to comment
Share on other sites

On 3/28/2023 at 10:06 PM, alex_79 said:

That's a bug in the game: it doesn't initialize the decimal flag and glitches if the flag happens to be set when the game starts. On a real console, the state of the CPU flags and registers are undetermined at power on, and the game can glitch in the same way, requiring a power cycle to start correctly.

Turn off the option to randomize the flags to hide the bug.

To add to this, here are a few clips where I power-cycle the game (BTW, the rom I'm referring to is the one in this post) running on a few consoles from the early "6-switch" model up to the late "Juniors" and also one of the Taiwanese clones that were still produced in the mid to late '90s. I find this interesting, and maybe someone else will too.

 

The rom is flashed into an Harmony cart in single-game mode, that is overwriting the Harmony bios. So it works exactly like a standalone cartridge and the game code is executed right at power on, without first running the Harmony menu (which will initialize CPU and RAM and would hide initialization bugs in the games themselves). The colors in the following videos are off, because all the consoles I'm testing are PAL, while the rom is coded for the NTSC palette. Apart from that, it works exactly the same as in a NTSC console. It's very easy to see when the Decimal flag is set, as the game will glitch in a specific way in that case (as emulated in Stella): slight jitter during the initial animation, and then corrupted graphics and rolling screen during the game itself.

 

I already tested this in the past and the result was that it was VERY easy to have the decimal flag set, with ANY console I tried, despite what the known "disturber" claims (without doing any research, as usual) in his now decade-long crusade against Stella. This is confirmed here too. The behavior is quite erratic, as sometimes the flag seems to always start in the same condition (either set or clear) for several power cycles, while sometimes it changes more frequently.

 

Light Sixer:

(at about 2 min. I try another cart and then I switch back to "The Stacks" as it seems that this can help changing the flag when it has been stuck for a few power cycles)

 

4 switch "Vader"

 

Early "Atari, Inc" Junior (made in '84)

 

late "Atari Corp" Junior ('91)

 

Taiwanese "Vader" clone with 128 games built in (about '95-'96).  It has an "Atari on a chip" integrating 6502, TIA and RIOT in a single package.

 

 

It is of course possible that some console will behave in a more predictable way. But even in that case, there's no guarantee that it will keep doing so in the future.

 

 

The official technical docs are very clear about this too:

 

MCS6500 Family Hardware Manual, page 40

Quote

The RES line is used to initialize the microprocessor from a
power-down condition. During the power-up time this line is held low, and
writing from the microprocessor is inhibited. When the line goes high, the
microprocessor will delay 6 cycles and then fetch the new program count vec-
tors from specific locations in memory (PCL from location FFFC and PCH from
location FFFD). This is the start of the user's code. It should be assumed
that any time the reset line has been pulled low and then high, the internal
states of the machine are unknown and all registers must be re-initialized
during the restart sequence.
Timing for the reset sequence is shown in
Figure 1.13.

 

 

MCS6500 Microcomputer Family Programming Manual, from page 126

Quote

9.2 START FUNCTION
While the reset line is in the low state, it can be assumed that
internal registers may be initialized to any random condition;
therefore,
no conditions about the internal state of the microprocessor are assumed
other than that the microprocessor will, one cycle after the reset line
goes high, implement the following sequence:
[...]

9.3 PROGRAMMER CONSIDERATIONS FOR INITIALIZATION SEQUENCES
There are two major facts to remember about initialization. One, the
only automatic operations of the microprocessor during reset are to turn
on the interrupt disable bit and to force the program counter to the vector
location specified in locations FFFC and FFFD
and to load the first instruc-
tion from that location. Therefore, the first operation in any normal pro--
gram will be to initialize the stack.

[...]

Once this is accomplished, the two non variable operations of the
machine are under control. The program counter is initialized and under
programmer control and the stack is initialized and under program control.
The next operations during the initialization sequences will consist of
configuring and setting up the various control functions necessary to
perform the I/0 desired for the microprocessor.
[...]
The last instruction in the start-up sequence should initialize
the decimal mode flag to the normal setting for the program.

The next instruction should be the beginning of the user's normal
programming for his device, everything preceding that being known as
"housekeeping."

 

 

 

So, as said, the bug is in the game. no way around that.

Randomizing the flags is just correct emulation. And IMO that's very important in order to properly document and preserve of the Atari 2600.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, alex_79 said:

I already tested this in the past and the result was that it was VERY easy to have the decimal flag set, with ANY console I tried, despite what the known "disturber" claims (without doing any research, as usual) in his now decade-long crusade against Stella.

I stopped reading your post right there, you've had a crusade against some of my games like DEFENDER III just for looking like STARBLITZ which runs at 30 Hz despite running at 60 Hz so you are not very objective and you don't write any games now or bitd or have the skill to write an emulator either.  I wrote a bare metal emu 2600 emu for the C64, programming is individual script k1ddy ;) 

Here's an example of Berzerk breaking on an oddball CPU that may be relevant. Go check it on 50 PAL consoles too:

 

 

 

  • Like 1
Link to comment
Share on other sites

1 minute ago, splendidnut said:

Pot calling the kettle black.  You've had a crusade against the Stella team for a long time now.

Never have, just broke it with a soft blitter despite your claims of "cheating"; not sure what you meant. 

Instead of derailing the thread why not take the personal claims to one of your own threads Jr programmer.

  • Like 1
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...