JetSetIlly

It's worth emphasising that an important part of GNU GPL compliance is the right (or the ability) to install modified copies of the compiled source on the hardware. I assume the 2600+ allows this but have not read anything specific (I could well have missed that detail)

Based on what I'm reading from some of the people I respect most in the community (Andrew, Alex, Thomas, et al) and the fact that what is being said chimes with my own instincts, I feel there is now a need for a third-party forum for collective discussion of the 2600 (and 7800 etc.). I don't know what it would look like but a mailing list is probably a good starting point. (I realise that's highly ironic but that's all I have this morning)

Oh I see. Sorry 🙂

MVC is moviecart

Amazing! Are the game ROMs for the Tournament Table available anywhere?

@ZackAttack has put together an intriguing ROM using the new ELF/StrongARM "bankswitching" format. This particular ROM, Wushu Masters, has given me a real headache and for the longest time it looked like this: Obviously wrong but it wasn't at all obvious what the problem was. All the ARM instructions it uses are used by other ROMs which work just fine. This morning Zack pointed out that I wasn't executing the .init sections in the ELF file. I was loading them but not executing them. As the name suggests, these sections point to initialisation functions that must be run before the main() function. A quick change to the emulator and the problem immediately resolved itself: simplescreenrecorder-2023-08-29_20.59.41.mp4 Selectable characters, scrolling background and great colours. I hope @ZackAttack finishes this. It looks to be tremendous fun 🙂

Is that the version of the RPG I have here Marco?

Why have you chosen to avoid using illegal opcodes?

<removed>

StrongARM has been around for a while but @ZackAttack will know for sure. I think it came about as a consequence of the bus stuffing experiments.

That's a good way of thinking about it. That's right. In a pure StrongARM ROM there is no DASM stage, it's all C (although it doesn't have to be C of course). The 6507 code could be different for every frame.

I'm not sure there's any benefit to that because you need to keep the CPUs in synchronisation. Any advantage of parallel computation is lost because the synchronisation points are so frequent. That's my feeling anyway. It would be worth implementing and measuring. The StrongARM library contains functions that facilitate the insertion of 6507 instructions into the data stream. For example, the StrongARM function vcsJmp3() inserts a JMP instruction. The implementation for Gopher2600 is here, to give you an idea of what's involved: https://github.com/JetSetIlly/Gopher2600/blob/master/hardware/memory/cartridge/elf/strongarm.go (Note that I've tied StrongARM to the ELF loader but it could theoretically be used with the ACE loader too)

Funnily enough, that's something I've looked at and kept on the back burner for a couple of years. I've built the emulator so that the 2600 engine can be compiled into other things, including other GUI systems and I have a version that can be compiled to WASM. It's only a proof of concept so no debugger etc. but it runs, albeit too slowly to be of any use. I don't know what to do about it to be honest.

This is a philosophical question really. It's something I've thought about and I do have my own answer but I don't have the time right now to write it out 🙂 Marco and Zack are making these games regardless of whether emulation is possible. I view my role as making their life a little easier by providing tooling to make the development cycle faster and to provide insights into what is happening in their C programs. But I definitely take your point about being able to play the games and I'm thinking hard about how to improve the situation.

Great question. The main difference is that in Marco's ROMs and Zack's StrongARM ROMs, the ARM is being emulated for the entire screen, and not just just during VBLANK and Overscan like you would typically see in CDFJ ROMs. I don't think there's much more I can do in the way of optimisation. In the case of the StrongARM ROMs though, there are library calls that have been implemented natively and those ROMs run much faster. The performance drop is similar to what would happen if, instead of implementing CDFJ natively, we executed the instructions in the Harmony ROM under emulation and relied on the Harmony implementation. Although the drop wouldn't be as dramatic because there are fewer instructions per colour clock in the case of the Harmony ARM. I'm not too worried about the performance though. I think the real utility for this is ROM development. Faster would be nice but I have a couple of ideas for how to improve the development experience in lieu of that.

I've been working hard, with help from @MarcoJ, to knock the bugs out of the ARMv7-M emulation in Gopher2600. This type of ARM is found in the PlusCart and UnoCart and @MarcoJ and @ZackAttack are making good use of it. The FPU emulation has proven especially challenging. There's still a lot of work to be done but today I reached a significant milestone by gettng Marco's XWing / TIE Fighter 3D model demo working. Short video captured from the emulator below: out.mp4 To be clear this is not real time. The emulation is currently running at about 5fps on my machine. By way of comparison, the ARM in the Harmony is emulated at well over a 100fps. In addition to the 3D models, Marco's demo features music which relies on the FPU. This is also working under emulation but there are tuning issues so I won't post the results here just yet. I think the tuning issues are due to incorrect timing between the VCS and the ARM (the timer2 peripheral in the ARM being updated incorrectly/inconsistently) but I'm not entirely sure about this. More research and experimentation required. As part of the process of bug finding process, I've improved the breakpoint system and the reliability/accuracy of local variable inspection. I've also added the ability to step by ARM instruction for super-detailed understanding of what is happening in the ARM registers. I'll polish up what I have and hopefully have a new release in a couple of weeks. For anyone who is interested all code has been pushed to Github. Steve

Have you read the research done by @Crispy on this subject? The PDF is worth reading in detail if you've not done so already.

The TV it's been played on might not be sensitive to whatever is causing the issue for the video capture

Thanks for the video link. It was interesting to hear him put the game into context.

I think this is just because RAM is not initialised correctly. If you play through the first level then there are values in RAM which define the "duration" and "life" you were left with at the end of part 1. In other words, the game loop is testing for your end-of-life and ending immediately. Maybe there could be a special initialisation in the Uno/PlusCart firmware for multi-load tapes. This way the RAM can be initialised "correctly" For completeness the RAM addresses are: $f4 - last two digits of the life value $f5 - last two digits of the duration value $f6 - first two digits of the duration value $f7 - first two digits of the life value I've not studied the other addresses but I'm guessing some of them are seed values for placement of the treasure and traps.

Some interesting stuff in there. I think there's scope for further research. I'd like to see the WT internal documentation mentioned in the paper. There's an image of the cover but no links to the actual document. Does anyone know if this exists? I'd also like to see more information about HRCALC and CHRST. Both are in Carol Shaw's papers but I can't seem to find scans of those. Has anyone seen these original routines or have any more details about them?

This entire conversation is bizarre. I'm sorry I got involved in it.

Thanks. I see what's happening now.

But you do own it outright. You can sell it to whoever you like for whatever money you want. You could even destroy it if you wanted, because it's your property. The only difference is that if it's an artwork (which is quite a high threshold to attain) and it's sold for over a $1000 (or euros, or whatever) and the sale was "public" then you may owe 5% resale royalty to the artist if they want to pursue it. In the existing systems we're discussing here, there is no rake.

Nice idea! I don't understand how sub-expressions work though. For example, what is the correct form if I want to use the result of "+ 1 2" to multiply by 3?