[Does anyone actually pay $20 for ROMs?]

8 hours ago, CapitanClassic said:

Unless the US Copyright office has changed their position from ten years ago, I don’t think so (maybe Boulderdash could be argued, limited-run, but doesn’t go through an “art-market”)

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.

[Does anyone actually pay $20 for ROMs?]

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

[Does anyone actually pay $20 for ROMs?]

1 hour ago, Thomas Jentzsch said:

Isn't that kind of business the core of capitalism?

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.

[Does anyone actually pay $20 for ROMs?]

58 minutes ago, Andrew Davie said:

Of interest to me, on a bit of searching - I see there are already laws in Australia covering the resale rights of artworks, where 5% of the resale value is owed to the original creator of artworks. At least to my reading of the legislation at https://www.legislation.gov.au/Details/C2021C00461 -- and apparently this concept (called droit de suite) is standard practice in Europe (and of course Australia) but apparently rejected by the USA (although California did legislate similar requirements but overruled by the supreme court).

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.

 

[supercharge - alternative to makewav]

8 minutes ago, SvOlli said:

The only way to detect this would be a blacklist with md5sum or something like that. Because there's no way by looking at address $FF8 of the ROM image if this gets touched at any time in the game. Running through some kind of emulation does not work also, since the address could be access only after 2 hours of gameplay in a specific situation.

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.

 

[supercharge - alternative to makewav]

1 minute ago, SvOlli said:

This is technically not possible, because there is no generic patch. If you take a look around the old entries in the forum where 2K/4K patching games for SuperCharger is discussed, you'll see that there are different approaches

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).

[supercharge - alternative to makewav]

49 minutes ago, Al_Nafuur said:

I thought this too, but the wav files produced by makewav are surprisingly small, even smaller than the 192kbps mp3 rips from the "stella get's a new brain" CD.

 

What is the size of the mp3s you created?

 

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.

[supercharge - alternative to makewav]

52 minutes ago, SvOlli said:

A couple of years ago, I did a clean-up of the makewav code. Removed DOS parts and added support for generating audio directly using portaudio. It's available at: https://git.h8u.de/Atari_2600_Tools/makewav.

That's a nice idea.

[supercharge - alternative to makewav]

5 minutes ago, Al_Nafuur said:

Why mp3 ?

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

[supercharge - alternative to makewav]

1 hour ago, alex_79 said:

I did convert a test wav (Oystron) to mp3 using lame v 3.100.
It works with constant bitrate (-b option) set at 128 or 320 kbps, it doesn't at 64kbps.
Using variable bitrate (-V option), it seems to always work with setting from 0 to 3, it sometimes need a few attempts on 4 and doesn't work at all with 5+ values.

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.

[supercharge - alternative to makewav]

1 hour ago, alex_79 said:

Tried it and the generated audio files load without issues in a real Supercharger.

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.

[supercharge - alternative to makewav]

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.

 

 

 

[How Do I Access The Marriage Proposal Screen In Super Action Pak?]

18 hours ago, batari said:

I found the ROM here:

http://www.atarimania.com/game-atari-2600-vcs-super-action-pak-pitfall-grand-prix-laser-blast-barnstorming_7753.html

 

I tried in Stella. Didn't seem to work every time but I did get it to work once.

 

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:

 

[Myst (unofficial demake for Atari 2600) (completed)]

17 hours ago, deater78 said:

as a side effect of this work found a bug in the E7 cartridge support in javatari today, but found a fix and sent it upstream

What was the bug?

[Wen hop? The Search for Planet X]

2 minutes ago, TIX said:

The "smoother" falling rocks makes for a noticeable improvement to my eye, the falling speed seems to be actually more fair now.

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

[Gopher2600 (continuing development on Github)]

3 minutes ago, Andrew Davie said:

Also worth mentioning - there's a global flag for "Show Tooltips" in the Debugger Preferences. The aforementioned operation of tooltips with SHIFT to show is related to how tooltips work when they are turned off (my preference) via this flag.

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.

 

 

 

[Gopher2600 (continuing development on Github)]

1 minute ago, Andrew Davie said:

The "search for window" function is also dynamic, in that it will preferentially search for the window you last selected.  By that I mean if you have two windows whose name starts with "P" for example, the first time you might type "PERF" to get the performance window, but from then on you just need to go SHIFT+CTRL+P to get that window. In other words, your most-recent selected window with the given (so far entered) search string is selected first.  This is a fantastic "one keypress" way of getting to your most-used windows.  Now I just use SHIFT+CTRL+P and I'm at the performance window,  SHIFT+CTRL+T to go to the TV window, etc.

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

[Gopher2600 (continuing development on Github)]

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:

 

 

[SuperCharger now supported by the PlusStore]

Are you using the original Supercharger BIOS for this?

[Gopher2600 (continuing development on Github)]

Bug fix release https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.23.1

 

Fixes related to rewinding

[Stella - Monitoring Scanlines and Flagging]

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.

 

[Wen hop? The Search for Planet X]

22 hours ago, Andrew Davie said:

• There were lots of overtime/screen roll issues.  Actually I was not paying attention at first and did not realise they were playing on actual hardware.  So although I'd have preferred this to have been more stable, I'm delighted it actually works. I haven't tested on hardware for a year or more. More.  The rolling is basically my ARM code going overtime, and points to inaccuracy in the emulator timings.  @JetSetIlly.  Fortunately I should be able to calculate a decent time buffer to prevent this. Could also pretty easily setup a screen now where we could fine-tune those emulator numbers, because it was rolling consistently on the screen of boulders - so I could just reduce boulder count till it doesn't roll on real thing and that would give a baseline time for how much I can do per VB/OS.

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.

[Stella break command]

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.

[Stella break command]

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.

 

 

 

[Stella break command]

48 minutes ago, Thomas Jentzsch said:

Exactly.

Yup. I thought about this too. We are totally free here, the logic is in our code.

 

So, which groups do we need?

• Constants: We probably have to split the constants between e.g. color or game constants and hardware registers.

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.

 

48 minutes ago, Thomas Jentzsch said:

• Variables: Should we split this between ZP and extended RAM?

The addresses should give sufficient information. So one variable group would seem fine to me.

 

48 minutes ago, Thomas Jentzsch said:

• Banks: Just numbering them seems sufficient, no?

I think it is sufficient. All schemes basically boil down to having numbered banks, regardless of bank size or placement.

 

48 minutes ago, Thomas Jentzsch said:

• How about e.g. macros and subroutines, will they break anything?

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.