JetSetIlly

Did you have any success getting Dall-E to draw something resembling an Atari 2600 or even a joystick? I've had amusing results but nothing anyone would recognise. (A recently launched alternative to Dall-E is "Stable Diffusion". You can get access straight away and also run it locally.)

This is exactly right and is something that many ARM criticisms perhaps don't take into account. The interaction of the ARM chip with the 2600 hardware is very interesting and not at all easy to get right for the game developer. It doesn't matter how fast the "coprocessor" is there are still significant limitations on what can be achieved.

I've implemented the bevel option and also a screen shine option. The shine effect is subtle but I think it works. https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.19.2 It's most noticeable with screen with a black background. But is also effective (but less noticeable) for more colourful backgrounds: It makes the Activision style HMOVE border more noticeable in any case. I'll add more control over both options in a future version. edit: Both options are disabled by default. To activate them press F10 to open the prefs window and click the "CRT" tab. Both options are in the bottom right.

I've decided to bundle some small changes and bug fixes from the current development branch. There are some major improvements coming and I'm not sure when they'll be ready for general consumption, so an interim release seems like a good idea. https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.19.1 There's a possibility of performance improvement on some systems (there was on mine) courtesy of improved interaction between the FPS cap and monitor synchronization. I hadn't noticed the problem but a recent OS change on my system revealed the issue. If you've tried the emulator before and been left disappointed this might have been the reason. Three bug fixes related to rewind: (1) Reset Missile To Player wasn't been "plumbed" correctly after a rewind. Not many games use this feature of the hardware but the bug caused havoc with Starpath's Frogger, for example. (2) Joysticks and gamepads are correctly put into a neutral state after a rewind event. (3) ARM statistics are more carefully collated during rewinding to avoid "spikes". I've also added a rounded corners effect to the CRT options (disabled by default). This is a work in progress but I think it can look quite effective in some situations. The problem it has is that the corners aren't always clearly visible when the VCS is displaying black in the corners of the screen. There is a "black level" option in the preferences which allows you to alter the value of "video black". That helps but it really needs a bevel surrounding the screen for the effect to be complete. Here's a WIP showing the potential.

Programming Boot Sector Games was an excellent read. Looking forward to this.

Thank-you for this. I love the idea of applying modern day gameplay ideas to older platforms. It can be surprisingly effective. Really looking forward to the demo.

It's definitely not a bug in Stella. It's because the player1 position is being reset (to clock 66) and then being drawn before a HMOVE is triggered (moving the counter to clock 60). You can see it if you single-step scanline 203 to 204 on a frame with the glitch.

(removed because I didn't notice this was posted on the Bb forum. I don't have a Bb answer).

I love the title screen.

Heh. I'll be interested to hear how you get on with this. A small request: could you keep a log of the steps you take? If you do get it working it would be good to post them on the project wiki. Cheers!

I'm not aware of anyone successfully using Festival on windows. How far have you got with it? Do you have a copy of Festival for Windows or are you still at the compilation stage?

I'd like to take a closer look at this but I can't build it because of a missing "tia_constant.h" file. Is that something you've created yourself? I've not seen it before. It looks like it contains definitions for NO_REFLECT and similar values.

Great fun to play... it's difficult but it's great fun ? Congratulations on another release!

Thanks for this. I've really enjoyed exploring the RetroVox. I plan to devote more time to it later this summer.

The Lode Runner port is ridiculously good.

A little more work on the painting concept. The new fill tool now makes as many searches and writes necessary to fill in a visual block of colour. The previous method was fine for a game like Pitfall but for games with more sophisticated player drawing routine the results were unsatisfactory. In the following video, I am re-colouring some elements in Real Sports Boxing. We can see the slower process required to fully change the shorts and boots of the boxer and also the scoreboard background at the bottom of the screen. Finally, to prove that the changes are persistent, I save the ROM and load it into Stella. demo_video-(3).mp4 A practical use for this would be an easy way of recolouring NTSC ROMs to PAL-60.

Playing around with an old idea this evening. I wasn't happy with the UI controls I had come up with previously, so I parked the code and forgot about it. But looking at it again this evening and I think there's potential here. A paintbox type window that allows you to recolour the screen by drag-and-drop. It works by searching for and changing values in the ROM. Playfield and background only for now but something to build on. Fun! No CRT effects in this video because the MPEG compression wrecks it. demo_video-(2).mp4

I've spent the last week looking for optimisation opportunities in the emulator. I thought I'd found them all but I've managed to squeeze a 16% to 18% improvement in uncapped frame rate for normal ROMs, and a 13% to 16% for ARM ROMs. Still nowhere near as performant as Stella but I think it's a big enough improvement for another binary release. https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.19.0

v0.18.0 https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.18.0 This release has focused on additional functionality for ARM developers. The performance window has been improved with the ability to focus on a specific kernel. That is ARM execution during the VBLANK, the visible screen, or the Overscan. This can usefully remove code not pertinent to that kernel from the performance list. Additional figures include an overall performance rating with respect to the selected kernel (or to the entire frame if no kernel is focused upon). Statistics can also be viewed as ARM cycle counts, as opposed to percentile figures. Gopher2600 can now track global variables. It understands all basic types, as well as arrays, structs, unions, pointers and typedefs. For CDF type cartridges (including CDFJ and CDFJ+) a stream visualiser is included. The visualiser will work even when no source is available. cdf_streams.mp4 Finally, the ARM illegal memory access monitor will notify the developer of null pointer dereferencing and stack collisions. Away from the ARM development features, the VCS RAM window now includes annotation of any symbol names. The yellow tabs indicate that that memory location has been named. Additionally, the red squares (as seen in the image) indicate the extent of the 6507 stack. Tooltips provide the additional detail on a memory location. The other feature worth highlighting is the TV screen scaler. In the very early days of Gopher2600, the window could be set to any size and the TV screen would scale. However, this resulted in uneven scanlines. Consequently, I changed the resizing policy so that the TV image would scale only to whole integers (ie. 1x, 2x, 3x, etc.) For this version, I've added a scaling shader which successfully irons out uneven scanlines. Moreover, a bug in the Windows and Mac versions has been fixed so that the user can see the scaling in "real-time". demo_video.mp4 Thanks to @Andrew Davie and @johnnywc for ideas and testing.

I agree, it would have been noted in the Speakjet manual. It seemed odd to me that a unit of time was not specified, but your explanation makes sense.

Interesting. Thanks. The Speakjet manual indicates that "speed" ranges from 0 to 127 with a default of 114. I'm not even sure whether higher numbers indicate "faster" - the manual isn't clear on that but I've assumed it is. In Festival fixed prosody, the duration value (of a phoneme) is defined in milliseconds, so I've naively assumed that whatever value is given by the Speakjet speed command is a duration in milliseconds. Undoubtedly wrong, but it seems to give reasonable results.

Simplest method other than (1) I know which is easy to remember. First published in 1960 https://dl.acm.org/doi/abs/10.1145/367415.367425 bitCount = 0 while val != 0 val &= val - 1 bitCount++ } Nice thing about this is that if there is only one bit set then the loop iterates once. If two bits are set then it iterates twice, etc.

Fantastic!

The personal message system here on AtariAge is good for discussion I've found. Wow! That's very encouraging news!

You're right. I'm using the Qix demo you released last year to test. I see the Quadtari message when the gamepad is attached. So I've changed the code so that INPT0 is high in addition to INPT1 and Qix says it detects the Gamepad. I wonder why INPT0 is high though? Is that because there's a third button that can be used? I'll take a look at the Quadtari this weekend. Could you send me the tester app? That would be useful.