SvOlli

Hello Tod, I've got an update for running Stella on the Chromebook. Since this week Stella is now available on flathub as a flatpak for installation. There are setup instruction for Chrome OS available at the flatpak website. The flathub build will be maintained not by the Stella team, but by me. You can consider it "semi-official" as some ports on the official Stella downloads page are already done by me as well.

Since I don't have an CBM RAM cart, I can't test it (and the dumper isn't implemented yet). What is the most common (= cheapest) PAL cart I could get? (I don't use my NTSC machine very often, and here in Germany, PAL carts are generally cheaper to get.)

Here we are leaving the digital area and go into analogue. Or to put it another way: I don't think there's a "correct" way to solve this problem, as I can think of ways to implement the bank switch before and after the triggering read. As it's by definition a strobe register, the value read doesn't matter. And the most important point: to have the dumper correctly mimicking a 2600 there, you need the correct "CPU" frequency to access the ROM, as well as "matching" pull-up resistors. And since the dumper is much slower because of getting all data through the UART, I never bothered, knowing the data I read will always be "too late", but never "too early".

I'd beg to differ on this one. I'd rather assume the start-up timing is different. The microcontroller on the cartridge needs to be initialized and ready when the 2600 comes out of reset state. If the FPGA is initializing too fast, the cartridge might not be ready. For the 3V vs 5V, this can be done using level shifters, it's just three additional chips, since the biggest ones I've seen so far are "8 bits wide".

I did a lightning talk once about a plasma demo effect done on the 2600, where I also explained the topic of circumventing the shortcomings of the PAL color palette. I also did something else: since I did a 256 bytes palette for "easy access", I reordered the 16 values of brightness to getting from dark to bright and bright again: 0, 2, 4, 6, 8, a, c, e, e, c, a, 8, 6, 4, 2, 0. This way cycling through the colors looks even better than using the original NTSC palette. The talk is available here: https://media.ccc.de/v/31c3_-_6563_-_en_-_saal_g_-_201412281245_-_lightning_talks_day_2_-_gedsic#t=1260

There also is a movie about the demoscene, called "Moleman 2". My guess is that in gaming - as the intros for cracked games led to the demoscene - the US shifted more to the consoles like the NES and SEGA Master System, while in Europe home computers like C64 and Spectrum were more popular.

This is possible, you can even use the seconds 2600 in "slave mode", and get the data "streamed" over the control port. But if I hear a musician complain about the 2600 it's never about "just two channels", but the "off tune".

These are very kind word, thank you. If you take a look at the 2600 section of Pouet, you find almost any demo ever released for the 2600. Nevertheless, I sent you a shortcut via personal message. Porting "Bang!" to NTSC would be more like coding the demo again for NTSC, as couple of effects require 256 lines of display for a correct loop, just as an example. In some parts is was hard enough to squeeze all calculation required in 312 lines. For more details on how things are done, you can look here.

Something like 10 years ago, I build a prototype of a link cable: You can use it to transfer bits from one console to another using a control port, and it's also rather cheap and easy to build. Nevertheless, no one was interested back then, and I don't do games, only demos. So this project never left prototype state. The biggest problem was, that it's just the low level sending and receiving of bits, duplex without timing constrains, as everything is buffered. So to use it for something really useful, there still is the need for a layer above that, that handles initial handshaking, check for data integrity, etc. But if you want to pick it up now, I can still help you.

Hello Tod, I think, I can help with that, since I've build Stella for several architectures. But I don't have a chromebook, so I can't do a "holding hands" approach. What I've seen so far that there are ways to get an environment that's capable of running the command line and the package manager "apt". Once you've got that, I can help you with a more current version of Stella than what's available in the official apt repository and the assembler that's been mostly used here (dasm). And about 2600 coding on ARM in general: that's no problem, I've done this quite some time on a couple of Raspberry Pis over the years. Hope this helps, SvOlli

Hello! While seeing this video yesterday, I noticed something that I want to point out here. I tried gaming on Linux... I've been around and still am part of quite some communities: Linux, retro computing, demoscene, makers, poetry slammers to name just a few. But I am still deeply impressed with how noobies are treated here. I've seen how communities have gone toxic over time. but here I am still impressed time after time after time, how you guys don't refer to a post that had answered a very similar question, but take the code in question, and solve the exact problem at hand. I've been a noob here about 11 years ago, and since then I refer to the 2600 coding corner on AtariAge as the most outstanding community I've seen so far in my life whenever that kind of topics pops up. But I never stated that towards the people responsible for this impressive achievement. Since I will forget way to many patient angels, I will not try to name you, you know who you are. And all I can offer you in return is my 2 cents of knowledge gained here I'm throwing in every now and then. And also a deeply sincere "thank you". Not just for the technical help, but also for showing what can be possible between people.

My suggestion on tackling this: for learning 6502 use the simulator like SpiceWare suggested. But as soon as possible, start with your desired target system the NES. Gather a nice dev environment with an emulator with debugging options, as much as example code as you can get your hands on, and an assembler that can work with your example code. Then take those examples as templates to come up with your own code, replacing more and more of the example with your own implementations. Not doing this was the biggest mistake I made when started to code for the 2600: I was accustomed to 6502 assembler from my childhood with a C64, took the original Stella programming manual, read it thoroughly and started creating my own code from scratch. My first code just didn't work, and frustrated after hours of not figuring out why, I switched to modifying example code to finally get some sort of result. Weeks later it turned out, that I missed a line the docs stating that I needed three lines for a sync, I just did one. When I do workshops showing how to code for the 2600, I typically use some code displaying a Space Invader using the mirrored playfield graphics. This code is then to be modified to display a bitmap using the asymmetrical playfield technique racing the beam. By modifying the example code, people can focus on the main goal, racing the beam, not caring about generating the sync signal, initializing the system or something similar. And since people do something timing critical, it is so much more than just a "hello world", and it really feels like an achievement.

When preparing my "Ultimate Atari 2600 Talk", I noticed, how clever the programmer was. The level-data contains the bitmaps of PF0, PF1, PF2 and the "mirror/repeat"-bit of CTRLPF. So the design of the levels is working with the quirks of the 2600, not against it. Short example for better understanding: Take a look at the stray purple fields at the top left corner. There are there, because the empty space is required for the corridor on the right. First it's repeated, then it's mirrored, so it's blocked above the key. And this kind of design goes through all the levels, which makes the game one of my favorite arcade ports to the 2600.

Simple: just concatinate the 4k-file two times into one 8k-file and you've got an F8SC.

Simple trick: just copy the 4kSC ROM two times to get an F8SC. When both banks contain the same, it does not matter when a bank-switch is triggered. Also when accessing original SARA, you have to take into account that the RAM is too slow for handling the "full" clockspeed of the 2600. This is why you can't have code running from $F0xx.

What you are experiencing is a so-called "ghost read". The CPU does a dummy-read on an address where the "summed up" hi-byte of the address was not taken into account.I ran into a similar problem when writing a UDP stack for a C64 network card. I noticed it in short here rather at the end:

If you want to set a sprite on a 3 colorclock cycle, I can offer this routine: https://www.pagetable.com/?p=669

You could also just Stellerator to create a webpage running your code in an emulator. Here is an example http://xayax.net/bang!/live.php . While I'm using it just to play a demo, interaction is possible.

Not in a way that's non-ugly. There is no way to let the 2600 know about a CPU reset except for turning on. One could go with an "evil hack ROM" that has be replace the currently running with a kind of hack to trick the CPU into going into a reset-like state and also reset the state of the cartridge to go to menu again.

Well you can, but then I could own your machine by adding a custom systemd with a backdoord integrated, or something like that. Not that I want to do this, but it's a risk you have to be aware of. Once this is out, you just can download http://deb.svol.li/repoadd.sh and run it. It takes distro name as a parameter, so it's "bullseye" for the 64bit version and "raspbian-bullseye" for the 32bit once, since I need to compile for ARMv6 architecture, a custom name was required.

More than overclocking the system gets sped up when using an NVMe SSD via USB 3.0 as storage. But that an extra cable on the back. Also you can find a more up to date Stella at http://deb.svol.li/bullseye/pool/main/s/stella/ . It's compiled the same way the official Raspberry Pi OS is, which is available at https://stella-emu.github.io/downloads.html, just using the 64 bit toolchain. Debian Sid (unstable) also has the current 6.6 version available, but that has the notification of a new version disabled.

My guess is that all the carts already had been produced, and since they're using OTPs, all of these carts would have been scrapped. And that's the difference between homebrew and professional. The professional also has to take costs more into account than an enthusiast, who seems have more pride in her/his work. I wouldn't hold that to much against AudacityGames, if it wasn't for the attitude shown at the release event, the very steep price and the very poor communication. I also wonder if that "bug-fiasco" of Circus Convoy was leading to Casey's Gold still not being released... Nevertheless, that whole AudacityGames thing has cost David Crane a lot of reputation in my eyes.

I can so relate to this, as I think the ESP32 with it's two cores is perfect for project, where you need the hard real-time code running on one core and the the "OS" providing Wifi, etc. on the other. This way you get best of both worlds. The only downer is the slow response time on GPIO changes (compared to ATmega, for example).

Just as a rule of thumb, I always mirror up the data on an (E)EPROM, when using a larger one than needed. It had never failed me so far, and even works if the most significant address bit(s) is/are floating. And I've seen guys trying to pull lines up/down using resistors to match the part of the EPROM they use. In theory it should work, practically they've fallen back to mirroring the data to get it stable. Pro-tip: look for some cheap 27SF256 EEPROMs. They can be used as a drop-in replacement for the 27C256, but can be reprogrammed without the UV-light step, similar to a flash chip. For these I've also got boards using zif-sockets for easy changing of the chip. One of 4k, F8, F6, and F4 each.

As already stated, not for a reasonable amount of money / effort. Also: the DPC (chip) should be considered an ASIC. But the only implementation worth the money is to use a microcontroller based board, like the Melody board, which can be bought at the store here, if you've got an own implementation in mind using the same architecture. If you just would like to fool around, Harmony or Uno/Plus/etc. will work. Yes, I remember watching an interview on YouTube, where DPC (David P. Crane) stated, even though the DPC (chip) was intended for generic use, Pitfall II was the only implementation using it.