JetSetIlly

Interesting. I've not seen that before. I'll take a closer look tomorrow. Thanks for alerting me to it.

I'm not sure I'm familiar with that. Are you referring to the file archiver?

Yeah. The trick is to do it over and over again until you find what you want.

The rewind system is very flexible. Not so flexible that I can actually run the execution backwards(!) but flexible and fast enough to perform searches reasonably quickly. In a nutshell, I just spawn a new emulated VCS, load an earlier state from the rewind history (a frame before the current one will probably be good enough in most case) and run it from there. I note all the instances where the GFX register is written to with the value that I want to change. The most recent of those writes is the instruction I will then follow. For example, if the instruction was a STA instruction, I want to find the instruction that loaded the value into the A register. It carries on like that until I reach an instruction that loads an immediate value or another value from the ROM. At that point I can just POKE the new value.

This is a bit of fun I've been working on today. I've been thinking about how to do visual editing of 2600 ROMs and this is what I've come up with so far. The short video shows me live-editing the colors in Pitfall by (a) selecting the area on the screen that I want to change, and (b) picking the new color from the TV color palette. As we know, there's no screen buffer in the Atari2600 so changing the values such that the changes aren't lost on the next frame takes a bit of work. In this implementation it works by a series of searches. Not searches of the binary but of the execution itself. Starting at the current frame, the execution is searched (backwards) looking for the instruction that loads the color value into the color register. From there we look for the instruction that put that value into the CPU register. We continue this reverse search until we find the value in an immediate instruction or otherwise stored in the cartridge data. Obviously, there are limits to this technique but it'll be interesting to see how far it can be pushed. Unwanted side-effects are likely, but even so it should be useful for quickly prototyping graphical changes. I've not pushed the changes to Github because there's still a lot of work to make sure it works in all cases. But it shouldn't be too difficult now that the proof-of-concept is working. Any ideas or thoughts about where this could wrong?

The cream of the crop.

I don't know to be honest. I'm assuming that cost would always be a factor in decision making but maybe 128k wasn't as prohibitively expensive as I'm imagining.

True. It would only be the cost of such a large ROM that would have been prohibitive. I mentioned it only to illustrate that they follow the homebrew scene.

It flips automatically between joystick and paddle controller depending on what (hardware) controller you're using. So yeah, if you used the analogue joystick (or triggers) or the mouse (when the mouse is captured), it will flip to paddle control resulting in changes to the RIOT register that the ROM isn't expecting. The auto-changing is nice but it needs to be more robust I think. Thanks for the feedback. on edit: the menu bar in GlacierBelle will stop moving if you use the DPad or the cursor keys - the emulation flips back to joystick control and sets the RIOT registers appropriately.

v0.9 https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.9 I've released this now because I added Superbank earlier in the week after learning Circus Convoy uses it. I thought it would be interesting for someone to try once it's up for sale (undecided if I'm going to buy it). Gamepad support. I'm using SDL so it should work for all platforms but I've only tested on this Linux box with a wired XBox360 controller. I'll be interested in hearing of any problems https://github.com/JetSetIlly/Gopher2600#hand-controllers Supercharger: better support for multiloading. The "tape" will stop automatically and restart and rewind as required. Also 8bit WAV files will now load correctly. Multiload .BIN files will also work as expected. @Mr SQL Your Supercharger BASIC .BIN files should multi-load correctly now. TIA revisions. I've added support for the notable TIA variations, as described in http://www.ataricompendium.com/faq/vcs_tia/vcs_tia.html You can bring up the preferences window in playmode with the F9 key. Here's a video of Cosmic Ark. debugger-2021-03-13_12.30.26.mp4 And also debug mode. Here's a demo showing how He-Man is affected by the TIA options. debugger-2021-03-13_12.39.58.mp4 Thanks again to @Al_Nafuur for making sure the Windows binary works.

I don't know if they went into detail in the stream but I asked Garry Kitchen earlier in the week what bank-switching method they are using and he straight up admitted that it was Superbank. I would call that a modern method.

Hi, I have a couple of A4000s that miraculously haven't leaked. Obviously, I need to get onto a recap and battery replacement as soon as possible. What's the best source of information for Amiga motherboard care? These are Revision B motherboards. Cheers

I'd like to see the Spectrum version if you release it. Where will you announce it?

DPC is defined in a US patent. https://patents.google.com/patent/US4644495A/en And for DPC+ I found these links very helpful but nothing as far as I know, nothing formal as a patent. https://atariage.com/forums/topic/163495-harmony-dpc-programming DPC+ with ARM https://atariage.com/forums/blogs/entry/11712-dpc-arm-development/?tab=comments#comment-27116

I don't use Windows here but I can say for certain that you need to run it from a dos prompt. I'll be adding a startup window in the future but for now you'll need to do something like: gopher2600 pitfall.bin or for the debugger gopher2600 debug pitfall.bin @Al_Nafuur helps me with the Windows builds so maybe he can help if you have any problems.

I'm not ready to release another binary just yet but I think today's progress is worth sharing. With relatively little tweaking of the TV implementation I've managed to get smooth playfield scrolling working as is being discussed in: If you're in a position to compile Go code then by all means feel free to have a play around with it. debugger-2021-03-03_11.26.39.mp4

Heh. You're right. The same thing happens in Gopher2600 (when random pins is on) I was confused by the Stella UI. I thought selecting Developer Settings in the TIA Tab would turn on developer settings only for the TIA but it turns them on everywhere. debugger-2021-02-21_22.29.51.mp4

This is definitely a bug. Even, if you set the Developer Settings but with the "Standard" chip type, the effect shown in the video is still visible. This is Stella 6.5.

It does look weird. Especially as there is no missile activity on the title screen.

Trying out the new demo of Ladybug Arcade. When running on Stella with TIA developer option "Inverted HMOVE clock phase for Missiles", the demo ROM reacts like in the attached video. Is this what happens when the demo is run on a hardware 2600 with "inverted HMOVE clock phase"? debugger-2021-02-21_18.38.41.mp4

The "2 or 3" issue as described on http://www.ataricompendium.com/faq/vcs_tia/vcs_tia.html The machines were that effect can be seen, do those machine also have (occasional) visible issues in Barnstormer? Does anyone have a machine of that type on which they can test? If my solution to the 2/3 issue is correct then I believe we will occasionally see such issues (example image below). But if we don't see those issues in Barnstormer then that means my reasoning as to the cause of the issue is incorrect. on edit: To clarify, the bug will only be seen during play and would be temperature related. 2nd edit: I can narrow down the conditions under which the bug manifests but it would be interesting to know if other ROMs (like Barnstormer) are affected.

Interesting. I've been working through the ataricompendium website that @Thomas Jentzsch linked. I've managed to replicate both conditions (playfield color in Quickstep, and playfield bits in Pesco) by moving the code that responds to playfield register changes to after the point where the TV signal is generated. So in effect, from the point of view of the TV, the playfield is updated a cycle late. This makes sense because as @alex_79 says in reply 37 of the Light Sixer Repair thread, the RGB mod will add latency to the register write to the TIA. Causing any TIA on the edge of tolerance to respond as we can see in Quickstep and Pesco. I've also been playing with the "2 or 3" sprite problem and have added a rudimentary emulation of the increasing operating temperature. Are there any ROMs that are affected by this phenomenon besides the one in the biglist archives? https://www.biglist.com/lists/stella/archives/199901/msg00089.html

Question: What is "James' console"?

Interesting. Thanks.

Has anyone ever compiled a comprehensive list of TIA differences between the different 2600 models? I've been thinking about the work @alex_79 did on finding the issues in the 36 character demos and was wondering if we have similar comprehensive results of other variations, or maybe even just a list.