JetSetIlly

More work on the magnification window as requested by @johnnywc. Now more interactive: . magnified area can be easily moved. . magnified area indicated on main display

https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.21.0 The most significant change in this version is a 13% to 18% increase in performance (measured by uncapped framerate). Also significant but maybe less noticeable is improved scaling of the TV image. In earlier versions, the image was sub-obtimal when scaled to non-integer scaling values, resulting in visible artifacts in many ROMs, particularly those with flickering displays. Preliminary support for the Stelladaptor has been added. As I don't have a Stelladaptor, this was done with the guidance of @SpiceWare Note that only Joystick and Paddle are supported for now. Driving controllers aren't yet supported by the emulation at all. The debugger can now magnify the TV screen. This can be seen either as part of the popup window under the mouse or as a separate window. This is very much a work in progress so what we see here is a first sketch. There are several bug fixes but the most important one is the correct calculation of the Call Frame Address with respect to ARM programs. This improves the reliability of local variable inspection.

ACE support is patchy in Gopher2600 at the moment. Some builds of Lord of Biscay work and some don't. I'm working towards full compatibility but work on this has taken a back seat for now. The problem is synchronizing the 2600 and ARM. It's very difficult to get right and because of how Marco has implemented his engine there are no emulation shortcuts that can be made, like with CDFJ and the other ARM strategies. This also means it emulates much slower than other ARM games. The newer ELF format also suffers from the same problem but in practice I imagine most ELF games will use the StrongARM functions. Judging by current tests, using the StrongARM functions as synchronization points works well. Whatever the emulation issues, Lords of Biscay is a triumph and it's well worth the time to load onto your PlusCart 🙂

Nice. It looks similar to the effect on the title screen of Assembloids.

v0.20.0 of Gopher2600. I've sat on some of these new features for a long time and sometimes we need a milestone to encourage ourselves along. https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.20.0 The big change in this version is better debugging for ARM cartridges. It's now possible to add breakpoints to the C code and to inspect local variables. This was very difficult to do correctly. Hopefully, I've worked out the major bugs but there are bound to be some left. I won't go into too much detail - I'll leave that for a future document. In the meantime, here's a screenshot of the @SpiceWare CDFJ demo project, "Collect3", as seen through the Gopher2600 debugger The source code window now includes breakpoint information in addition to performance information The new local variables window shows the local variables that are in scope at the current execution point Adapting existing CDFJ and DPC+ projects for the new debugger is very easy. A new page on the Gopher2600 wiki explains the process: https://github.com/JetSetIlly/Gopher2600-Docs/wiki/Preparing-ARM-Enabled-Projects-for-the-Gopher2600-Debugger As well as CDFJ and DPC+, all aspects of Gopher2600 now support the new ELF and ACE formats. The ACE format still needs work but many ACE ROMs do work well (albeit very slowly 🙂) Thanks to @ZackAttack @MarcoJ and @Al_Nafuur for help with this. As part of the work on ELF and ACE, I have also implemented the Thumb-2 instruction set. This extended instruction set is found in modern ARM CPUs, such as those found in the UnoCart and PlusCart. There will be some instructions that I haven't implemented yet but the all the major instructions are present. The upshot of this is that ELF and ACE projects can be compiled for ARMv7 if required. Away from the ARM side of things, there are a few new features. The notable ones: Implementation of the Wickstead Design bankswitching format and support for very small Atari cartridges (1k etc.) Better stereo effect. The new method preserves some of the distortion that can be heard in the mono mix that emulates the hardware Better indication of scanline jitter on the timeline window. Screenshot below taken of the infamous Snow White ROM, which jitters like crazy. For terminal users, some new commands have been added to support the new debugging features. For instance, "DWARF LOCALS DERIVATION" will explain the how the locations of the current local variable were derived. Useful for some people. I've also added better emulation of how the PlusCart sends data over the network. The hardware PlusCart sends data relatively slowly which means it's possible for data to be corrupted before it's actually sent. It is now possible for a running game to corrupt this data in the same way. And bug fixes of course: An obscure bug in audio generation was fixed. Remarkably, this bug was related to RSYNC. Entirely my fault and an interesting one to think about. A small mistake in the RIOT address bus mask, causing some games to fail when reading the Timer (for example the original Lock'n'Chase from MNetwork) and many more I'm sure I've forgotten about (but everything is in the git log for the interested)

Do you know which 2600 games support three buttons?

I've not had chance yet, sorry. Just looking at the Joy2b+ project now though https://github.com/ascrnet/Joy2Bplus and there's a chance that it might already be (partially) supported. I have 2-button support in the emulator already. I have an XBox360 pad that I use and games that support 2 buttons work fine. It's not clear to me how a Joy2b+ joystick is attached to the PC but it might already be detected. Have you tried it? If it works, I'll just need to add support for a third button.

It's very difficult to keep a consistent frame rate on a multi-tasking system so your likely to see stuttering when the computer is under load. Increasing the phosphor value in the TV emulation is a good way of mitigating the problem. In Stella the setting is in the TV Effects tab of the Video & Audio Preferences window.

The ID is visible in the Gopher2600 debugger - the PlusROM Nick window, which you can open from the PlusROM menu. It's not selectable though so you can't copy it to the clipboard. I'll change that. It's also visible in the preferences file, which is a normal text file.

I think the categories are fine as they are. The games should be judged on enjoyment level. The technical categories (best graphics, best music) is a place to judge non-game elements. My only suggestion would be a "best use of cartridge" category, or something like that.

I only ask because Gopher2600 works with DWARF data to help debug C programs compiled for the ARM (PlusCart, Harmony, etc.) at the source code level. It's very useful and would be reasonably easy to expand to a C like language targeting the 6507. Are you planning to output 6507 binary directly, removing the need for DASM?

Nice work. Any plans to output DWARF data?

"The Blue Loon Blunder"

ChatGPT is a great natural language interface but the results aren't great. So as long as you know that, it's fine. I actually used it to propel me forward when I was stuck with DWARF parsing recently. It was almost like pair programming when you talk through a problem with a partner. The answers aren't definitive but having a natural language conversation somehow clarifies your own thoughts.

"Indie Game: The Movie" was very good, if it's the one I'm thinking of. I think it was the one that followed the development of Fez. Braid and its developer Jonathan Blow are also in it I think. Bedrooms to Billions is one people seem to like. There are a couple of spin off documentaries too. There's one focused entirely on the Amiga for example. YouTube is a good for original content on this type of thing, but they tend not to be "cinematic" films (like the King of Kong, for example). But some are very well made. The Noclip channel is worth looking at and Summoning Salt if you're interested in the history of speed running. Both make feature length videos (ie. 70 minutes plus).

🙂 I'm literally just implementing Wickstead Design for Gopher2600. Never really heard of it before today and now you've mentioned it here! Do you happen know anything about the history of the Stella implementation of WD? For example, how was it discovered that the bank switch takes three cycles to take effect? Was it discovered through an analysis of the Pink Panther prototype or some other way? What about the bad ROM dump? Where did that come from?

Oh I see what you mean. Yes. CALLFN should ideally be triggered close to the start of the cartridge mirror addresses.

But you only have 4096 addresses before you hit non-cartridge addresses, no matter where you position the PC. Place it at 0x1000 and you hit a TIA address at 0x2000

Yes. Or set the 6507 to execute from VCS RAM and take as long a slice as you want.

It does, but once it starts reading 0x0000, the cartridge can no longer respond with the NOP byte, meaning the processor starts executing unwanted instructions. Which generally means carnage.

Yes. It's the only way for the recent ROMs by @MarcoJ and @ZackAttack to run without hardware. I agree, it does seem ridiculous 🙂 but I'm having fun and it's not far from working. Edit: On reflection, we might be talking at cross purposes. It is ARM emulation (Thumb-2 instruction too if necessary). But those recent ROMs I mentioned are completely custom ARM programs and use the ARMs GPIO to communicate with the 2600 half of the system. There's very little room for optimisation by implementing the driver in native code, like we do now with CDFJ+ etc.

The RESPx issue has been fixed in the latest version, but there's still another issue with the rendering at the bottom of the screen. Not sure what's causing this exactly but a quick look at the disassembly suggests it's NUSIZx related. If you want an emulation with which you can guarantee correct results, you should use one of the emulators I mentioned before. For your purposes I would recommend Stella. For an IDE, a lot of people like using VSCode with Atari Dev Studio. https://marketplace.visualstudio.com/items?itemName=chunkypixel.atari-dev-studio

It's a flaw in 8bitworkshop's emulation unfortunately. The balloons case is caused by how the RESPx signal interacts with the signal that indicates the player should start drawing. To my knowledge, there's no hardware version of the Atari2600 that exhibits this behaviour. Personally, I wouldn't try to work around it and to use Stella (or Gopher2600 or 6502.ts) when exploring these more advanced ROMs. 8bitworkshop is awesome but these more advanced methods aren't always displayed correctly.

Have you looked at scoremode? It's probably of no help but it's worth thinking about.

Indeed. For modern formats it makes sense to add a signature to help emulators and multi-format cartridges. In this instance though, it throws up a false positive (EFSC when the ROM doesn't require a superchip) Thanks. It's a comprehensive list. I've mainly used Kevin Horton's "Cart Information" document in the past, which is great for "classic" bank switching schemes. For modern schemes I've struggled to find good information. Dr Boo's list would benefit from having links to example ROMs.