JetSetIlly

Thank you for that link, it's an interesting find. I was wondering what was meant by "art market" but the document states in section 6 that: "In the UK, the Artist’s Resale Right covers works sold on the secondary market with the involvement of art market professionals, which includes auction houses, art galleries and art dealers. It does not cover works being sold for the first time". It's not clear whether this includes eBay. Either way, Andrew has identified an interesting moral question. As that document explains, resale royalties do not interfere with first sale rights - the artist cannot prevent a sale from happening although can declare a right to be given preferable terms of sale. The Resale Royalty is simply a cut (5%) of the sale price. I don't think that's unreasonable.

I should also add that the resale value has to be significant (>$1000) and not be a private transaction.

The thing is, Andrew's right because Australia has a law that allows for Resale Royalties on artworks. It's not clear to me if video games are covered but they do seem to be because the Australian scheme specifically lists "digital works". However, it might be dependent on how it was sold and what they buyer thought they were buying. (It's worth noting that the law specifically covers the creation of a limited number of copies, the production of which was "overseen" by the original artist. I'm not sure what "overseen" means here) Other countries have Resale Royalty laws. The only one I'm familiar with is the UK but that doesn't list "digital works" in the list of covered works. And then there's the question of reciprocity between nations that have Resale Royalty laws. So on the surface it seems like a simple application of the first sale doctrine but it really isn't. If Andrew considers his creation an artwork then he may well be due royalties. But honestly, I'm not really qualified to know.

In the UK at least, Resale Royalties do not cover the sale of video games. If you created and sold one copy of the game and declared it to be an artwork then you might have a case but otherwise, it's just the regular selling on of property to someone else. In other words, once you've sold a copy of a video game (in the form of a cartridge or otherwise), you've "exhausted your rights" over that copy.

I think a static analysis of the ROM might get you there in 80% of the cases, but I agree that you can never know for sure.

A good alternative might be for the program to simply detect that the ROM can't be converted and refuse to produce the WAV file (unless forced).

I converted Pitfall with supercharge and produced a WAV file of 298814 bytes. Converted to a 128kbps MP3 with lame gives me a file of 109504 bytes. That seems a significant saving to me.

That's a nice idea.

Smaller files. No other reason. There are other formats producing smaller files of course but MP3 feels like a good solution.

Thanks. That's good to know. I'd prefer it if the program would output MP3 by default rather than WAV so this is great research for the future.

Excellent. Thanks for testing. It would be good if you could test the audio file after it has been converted to MP3. I can't get that to load here. If it also doesn't load on a real hardware then we can say that the WAV file isn't suitable for conversion for whatever reason. Interestingly, I can load the MP3 files from the "Stella Gets A New Brain" collection. So I think there's something about the construction of the WAV file that's being damaged by the MP3 compression.

I've written an alternative to makewav for making Supercharger WAV files. It's a terminal program and can work on batches of files. There's currently no way of changing the parameters for the WAV file creation, but it uses the same default values as makewav so it should work in most instances. Source code here: https://github.com/JetSetIlly/supercharge. There are windows and linux binaries (for AMD64) in the releases page. If you want to try the Windows binary remember that it's intended to be run from the terminal. I wrote this because I wanted a way of loading a Supercharger tape in Gopher2600 without having to go through the manual process of converting a binary file into a WAV file. As part of that development I wrote the command line interface you see here as a separate project. It currently only supports 4k files but I'll improve on that as I feel the need. I'm also happy to take suggestions, bug reports and pull requests. Short video showing the auto-conversion process in Gopher2600.

It's a bit awkward to get at with the joystick buttons isn't it. But you can force the proposal screen by setting address $9b to $ff and the second proposal screen to $01. Setting it to $2 will show an alarming combination of the two:

What was the bug?

I agree. It's easier to see and understand what is happening.

Yes. Clicking on the icon in the menubar also toggles the global setting. The video shows the icon and the preferences checkbox working in unison. simplescreenrecorder-2023-06-18_23.17.14.mp4

Yes. I forgot to mention that. It's effectively a way of quickly and dynamically creating a hotkey for a window.

v0.24.0 mainly consists of debugger improvements. Not much here except for developers. The first two improvements were courtesy of feedback from @Andrew Davie Full release notes https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.24.0 Search For Window The Gopher2600 debugger can get quite busy if you have a lot of windows open. This new feature allows you to search for a window by name. Press and hold CTRL+SHIFT to bring up the search tool in the menu bar. Type the name (or part of the name) of the open window you wish to bring to the front. In the screenshot above, the string "per" is enough to identify the performance window. Tooltips Tooltips are useful but they can often get in the way. The menu bar now includes a speech bubble icon that indicates whether tooltips are switched on or off. Click on the icon to change this state. If the icon is solid white then tooltips will always show. If it is gray (as in the screenshot) then they will appear only when you press the SHIFT key when your mouse is hovering over an area of interest. The icon will turn to white temporarily to indicate if there is a tooltip underneath the mouse. Timeline Window The timeline window was added as a sketch and a way of quickly rewinding back and forth in the debugger. The new timeline window is resizable, includes frame count guidelines. The tooltip has been replaced with a more informative status bar at the bottom of the window. The timeline thumbnail is still available but is turned off by default. Turn it on via the preferences window if you want it. You can now also set the "comparison frame" via the timeline window. Using the context menu (right mouse button) the comparison frame can be set to the frame under the mouse pointer. The "Lock Comparison Frame" option meanwhile, stops the comparison frame from being updated automatically. If you're wondering what a "comparison frame" is, the feature has been in Gopher2600 for a long time but has never been controllable before. It's similar to the Stella feature which shows which RAM addresses have changed recently. In Stella: And similar information in Gopher2600:

Are you using the original Supercharger BIOS for this?

Bug fix release https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.23.1 Fixes related to rewinding

My emulator, Gopher2600, has a timeline window in the debugger. This shows the history of the scanline count over recent frames. For example, when running your ROM I can see there was a scanline issue during the switch from the title screen to the play screen. The red line gives a general idea of what is happening to the scanline count each frame and the red triangle draws attention to it. Hovering over the timeline gives numeric detail and thumbnail of the offending frame I've played the game a little and I didn't encounter any other scanline issues. edit: You can also set a breakpoint with BREAK JITTER that will halt execution whenever the scanline count changes.

I'm watching the video now and the majority of issues looked to me to be overtime of just one/two scanlines. Finding a spot in emulation to match an example in the video: This cycle count looks very close to dangerous to me so I'm guessing this is what is causing the jitter on real hardware. The occasional screen roll, of course, will be the cumulative effect of whatever is causing the jitter. But this is useful information! The combination of the ROM and the video will be useful reference for when revisit the cycle counting problem.

This is a good time to summarise my thoughts on this thread: For me, this thread is about enforcing a protocol between DASM and the disassembler by way of the symbols file. What Omegamatrix outlines in his last post would work, but it would not be clear to me from a ROM programmers point of view how to deal with for example, small banks. Yes, there is a way to do it but personally, I believe a BANK directive in the assembler would be a better solution because it enforces the rule. (The reason Stella or any other emulator hasn't tied symbols to addresses is because it's not at all clear that this is a standard way of doing things. Making a declaration now that this is how should work wouldn't change that, IMO 🙂 ) In the absence of a BANK directive, the macros have been a way of exploring different ways of achieving the same goal. The implementations are messy but I believe Thomas' new sort method is good enough to allow simple macros to be created. The macros would be contained in a "standard" 2600 header file, maybe macro.h or maybe a new header file.

It might be best if we simply say the following pattern is reserved 2600CONST_<group> and then allow the programmer to define the groups as they see fit. Same with variables: 2600VARIABLE_<group> Banks would have to be limited to numeric information I think 2600BANK_0 2600BANK_1 ... edit: Or maybe allow a bank label 2600BANK_0_<label> or just 2600BANK_0 if the ROM programmer doesn't want one.

Being able to split constants into colors and other variables would be useful. You don't *need* a hardware registers group. If you know the bank switching scheme then you know the registers. But I suppose if the ROM programmer defines them then they need a group to go in. The addresses should give sufficient information. So one variable group would seem fine to me. I think it is sufficient. All schemes basically boil down to having numbered banks, regardless of bank size or placement. If you want to encode information about macros and subroutines then I think we're looking at something more complex than a symbol file. It would be very nice to have but if you want to go down that road it might worth thinking about a new format altogether.