Sohl

Certainly coding styles vary, but I wonder if Stella could have an option to prefer symbols with lower or mixed cases to take priority in the RAM range of 0x80 to 0xFF if there are multiple symbols for a same value (the other(s) being all UPPERCASE)? Such an option could encourage programmers to use mixed case for variable names and labels for noteworthy locations in code while uppercase could be used for numeric constants and other data unrelated to a given address. This seems natural to C programmers at least. Perhaps now, Stella just uses the first symbol it parses from the .sym file for a given RAM address and ignores later symbols for the same value? I notice that the DASM .sym output file is sorted into alphabetical order, so in my example, the CONST symbol name is alphabetically earlier than the RAM variable address it matches in value. Given this behavior, I suppose with clever naming, or consistent use of some special characters, one could ensure the RAM symbols are output first in the .sym file and therefore be the ones Stella will use in the debugger UI. Yes, if Stella always does "use first instance of a symbol with a given value", perhaps DASM could be changed to organize the .sym file non-alphabetically to sort mixed-case symbols before uppercase-only ones, or output them in order of appearance in the source code, or something else the programmer can control in a more flexible manner. Again, this is just an annoyance since I only have couple of conflicts like this. I just wanted to make sure I was not missing some simple option to avoid it! But perhaps it plants a seed for future Stella and/or DASM update ideas.

Stella is great, and I'm happy to report that the weird zoomed-out text boxes (in OpenGL rendering modes) I sometimes saw are gone! Bravo. However, one minor annoyance I had in the 6.5x and now 6.6, is that when I load a ROM with the .sym file for debugging (so I can get the tooltip popup for the symbolic names of each RAM location when I hover my mouse over the RAM display, and see the variable name in the broken-out display under the array of RAM cells), if I have any other constant value defined that has a value between $80 and $FF, it can mask the normal RAM name I've defined using "ds" directives in my DASM assembler source code file. I tried looking through the DASM manual to see if there is a way to prevent some symbols from being output for the .sym file, but I did not see anything like that. There is such a thing to control the listing file (LIST ON | LIST OFF), but that does not affect the .sym file. Does anyone have any ideas short of filtering the .sym file? I could write a little C program to strip out any symbols defined in all UPPERCASE that have numeric values from $80 to $FF, I suppose. In the attached picture, I have a RAM variable I named 'InfectState' at RAM location 0xDE, but I also defined a constant for a color as 'ENERGY_MOL_CLR' (energy molecule color) that has a value of $DE, so Stella happens to chose the ENERGY_MOL_CLR symbol for the debugger UI displays instead of InfectState. Reordering the definitions in my .asm source file did not help. Thanks if you can suggest a better way for me to work with symbols or attempt to change Stella to pick the more likely symbols for RAM.

Typically, if you only have one object that will be drawn with P0, you would do the write to RESP0 to set the position (and HMOVE, if desired for fine-tuning position) during the VBlank period before the visible screen generation done in the Kernel code. If you have multiple things to be drawn with P0, you would need to use RESP0 (and perhaps HMOVE) for each subsequent object during the Kernel code after the prior P0 object is drawn.

Wow, I better be there!

After a bit more testing, I'm deciding to release the "Dec. 31" version of Immunity demo today. It will have a few bugs and some unbalanced aspects of the gameplay, but I hope you enjoy the new features and provide some feedback! immunity_2021_Dec_31.bin

Not sure why I had so much trouble yesterday capturing my Stella session to video, but I got it working today! Here's a link to a clip on Odysee. My shooting accuracy is terrible in this captured session, especially in the first 30 seconds or so, but you can see energy getting bumped into a mitochondria at about 0:35. Anyway, all the main features of the Intracellular playmode do get demonstrated. It's still a bit buggy and I hope to refine it quite a bit but at least you can get a better idea of what this will be like to play. https://odysee.com/@Sohl:0/Immunity_Work_In_Progress_Intracellular_Playmode:8?r=2dG4SJwawMXaxH94dXASdt5jRERjyQyJ

I noticed SnapFish had recent promotions to photo-print coffee mugs for cheap. I ordered at a sale price of $2.99 each (+ about $4 shipping and handling), but I saw it as low as $0.99/mug a few months back. Anyway, I took some "glamor" shots of my own heavy-sixer. I needed to squash the aspect ratio a bit to still be able to see the nice Atari logo and the switchgear at the same time, but wrapped around the mug, it does not look all that distorted. I would have preferred to print it on an all-black mug, but this turned out pretty well as is! (Bonus appearance by one of my cats in the photo.) I also did a Commodore 64 version too! I had two of each style made in case I break any. If you wish to print your own, I'll provide the stretched images here.

Made some decent progress on the intra-cellular playmode. I am having some trouble capturing it as video, so I will just describe the current playmode and attach a few screenshots Basic Idea: You control the "free ribosome" that can shoot sideways back and forth through the cell. It can collect "Vitamin" molecules (which look like a 'V'), that allow it it to kill viral RNA and new Virus copies without loosing energy or health. The "Energy" molecules (looking a bit like an 'E') need to be bumped into the mitochondria at the sides of the playfield for the energy to be absorbed. When there is more energy, the free ribosome will shoot faster. If there is only minimal energy, it cannot kill a new virus attempting to escape (it will just bounce off). If the ribosome has at least an energy of level 1, hitting a free virus will kill it and leave behind some loose spike proteins that can be collected to build antibodies (useful in the other phase of the game). You can also hit the g viral RNA and attempt to neutralize it before it implants on the endoplasmic reticulum, where it can grow new virus copies. Viral RNA will expire after growing several virus copies, but new viral RNA will inject to take its place. After an infection round of several RNA strands, once there are no more live RNA or free viruses, the play will switch back to the external cell mode, but if new viruses escaped, the total viral load will be higher! Hopefully you built up some extra antibodies. There is a trick to bump the outer cell membrane with the free ribosome by moving up toward it and hitting fire at the right time. If successful, it can shake some spike proteins from the externally-latched viruses that can be collected to build new antibodies (but this feature seems to be bit buggy right now) Your vitamin and energy levels are shown in the low part of the screen as playfield rectangles. I hope to have a more iconic way to represent this in the future.

I've made some good progress in recent weeks with the intracellular play mode. I got the vitamin chomping with effects done. I got the "nudge Energy molecules into mitocondria" working. I got the "bump the upper cell membrane to knock loose spike proteins, and collect to make antibodies with" working. I got vRNA implanting at the bottom and growth of new viruses. There still some issues between when to release the new virus versus letting more vRNA to descend, and I don't have the vRNA or virus attach feature is still missing. BUT... in a cruel twist of irony, the inspiration of the game has become very real for me. I'm on the 10th day of symptoms, which are "mild" I guess as far as these things go, but the yo-yo fevers, chills, and headaches are not very conducive to 2600 development. I had saved up some vacation days for the end of the year and hoped to use many of them as a 2600 development sprint, but that plan is mostly falling apart. If you are the praying/spiritual type, I'd appreciate any prayers or good vibes on my behalf! I really hope I'm starting to turn the corner a bit and will get productive again soon.

Wow, sounds interesting! Looking forward to hearing more about this. @Kenneth Cochran I'm a big fan of Forth starting about 1990. I had the Atari 2600 BASIC programming cart and keypad before that, and was frustrated by how limited the thing was. Happily, I moved on to a TRS-80 Color Computer in `81 and a C64 in `83 or so. Forth was traditionally an interpreter with a teletype or video terminal interface where the developer iteratively built software in RAM, which would be tough to do interactively in a ROM-only cart, as you point out with only 128 bytes of RAM, but perhaps some very tiny apps could be built that way. Probably a much more viable approach is cross-compiling Forth source into a ROM image that can use RAM for stacks and variables, but that sacrifices the interactive nature, of course. If you are using it to make video games, you'd need a few CODE routines with tight native code to implement the drawing kernels and some other really time-critical code. Perhaps a full keyboard can be interfaced to the 2600 to make it interactive, but there'd be scant space to extend the dictionary of Forth words unless you use a cart with much more RAM.

I got my copy last week. I really appreciate the little updates like the PFA cycle deadlines on pg 38. Thanks! I wonder if you could get permission to include the symmetric and assymetric PFA cycle timing diagrams that are posted here in the AA forum in an appendix? And/or maybe the sound programming info from RandomTerrain (Duane Hahn) here: https://www.randomterrain.com/atari-2600-memories-music-and-sound.html ?

Question for @zhorton or perhaps others... these new Magnavox Odyssey homebrews... is it true that at least some of them are using a new circuit game card/cartridge along with new screen overlays and accessories, or are they all just re-implementations on one of the original game card/cartridge set? I would think the range of possible alternate games possible with new plug-in cards would be fairly small, but I'm curious how it could-be/is-being done and how much is possible in the future. My family had an original Odyssey system when I was young, so the new publicity online of the original games has been nostalgic for me and the new game development is really amazing!

Al: Sounds Exciting! Hope it goes well through its launch.

@Keatah Thanks! I don't have an official release worked out on the business side yet. I'm hopeful to at least offer a boxed cartridge through the AA store, with some original catalog inspired box design. Maybe AA can sell digital downloads too for the full game, but I don't think they are doing that yet. Either way, I expect to have some beta releases here and a playable demo of the final release here, so keep posted.

Some further work in the kernel... simplified the drawing to not use one of the missile objects, changed the way the RNA and new virus looks so they can both be drawn with just one sprite, but with colors changing per row.

Sounds great! I just ordered a copy. I have been using PDFs of the programmers guide for years, but there's definitely times that it would be convenient to have a hardcopy reference.

Oh my, things are not looking too well for our plucky cell!

After an overly-long hiatus, I've resumed work on 'Immunity'. The gameplay I intended for the "intracellular" screen was proving quite difficult to render in the 2600 drawing kernel, which was rather demotivating to me, plus I has some competing activities and family matters going on until recently. However, I really want to get this game developed into a more finished state. Now that I've had a bit more usable time, I've thought of another type of gameplay that is more straightforward to implement and should still be quite fun to play, perhaps even more than what I first wanted. I'm still a long ways from a playable screen, but I've got the basic kernel worked out that draws the three main moving objects of this screen and some playfield. The lowest portion of the screen can have some extra things going on that I will work on soon! Here is a teaser shot, with graphical warts and all! It shows the free ribosome that the player controls, plus a viral RNA strand and an energy molecule the player can interact with. There will be a few other types of moving objects as well. I have no idea how long it will take, but I'm now motivated to get something roughly playable by the time the ZPH Twitch show gets back from its planned break in early December. Let's see!

I agree! If you didn't know or recall, I made 2048 for the 2600:

As I said in ZPH last night, really great sprite design especially with the color changes! I will try on my real hardware later today/tomorrow!

@Thomas Jentzsch OK, thanks again. I'll try it that way too. I can live with the zoom glitch easier than the unexpected aborts, but maybe the software rendering will be more robust even if less efficient.

@Thomas Jentzsch: Yes, similar. It's an HP 840 G1 laptop with a Core i5-4300U, 16 GB RAM, 64-bit Windows 10 Pro. No external GPU, so its just using what's built into the CPU (Intel HD 4400).

@Thomas Jentzsch: Thanks for the help! My rendering option on Win10 was set to DirectX. I switched it to OpenGL. After a good bit of use, I had no unexpected aborts (?), but in debug mode, I did sometimes see the entire window show some small elements of the GUI expanded to fill the entire window, as shown in the attached jpeg. When it was in this state, the window flashed back to normal and this zoom image, alternating, and if I tabbed or moved the mouse, which graphic element that was zoomed could change. -- Mike

@Thomas Jentzsch I was not aware that there is an option for this. Let me try it, and I will post my results.

Hi all. I mostly love Stella and it's been extremely useful to me in my homebrew development work, especially the debugger mode. With the current 6.5.3 version, however, I'm having some random sudden aborts, usually when I tap the backtick (`) key to resume running from the debug window, but sometimes the other way, from the running game when I tap backtick. The aborts tend to be "streaky" meaning that I can invoke and use Stella successfully for several iterations of debugging, then I get a bad streak where it will abort on me in use for a few invocations in a row before working normally again. I don't see any error messages or log files (at least where I looked) on my console, even when I use command-line options to increase the logging level. I start with the -debug command so it always first comes up in the debug GUI, and I run from there. I can't tell if Stella is crashing or thinks I requested to exit somehow. It's possible my keyboard is a bit flaky and my backtick key is bouncing and sending a few very closely-spaced keypresses, but I'm not sure. I'm running on Windows 10 and launching from the "cmd" command line. Any ideas on what I can do to avoid this or help you troubleshoot and fix it?