JetSetIlly

I've added the new kernel binary to Gopher2600 and made the necessary changes to the emulation. Looks pretty good I think! The recorded video is adding additional compression artefacts, but even so I'm particularly impressed with how the mouth movement is visible with this new method. Good job @rbairos debugger-2021-09-08_20.17.01.mp4

I think your most recent suggestion is fine.

Nice new emulator for the ColecoVision. https://github.com/drhelius/Gearcoleco

I like that.

I would agree with this. My only reservation is how the version number of the platform is encoded. Personally, I would advocate a separate "version" field.

Vastly improved. These are just proof of concept changes at the moment are they?

This is the TIA audio implementation for Gopher2600, which might give you a different view on it. In a nutshell, the audio.Mix() function is called every TIA video cycle. That function counts to 114 in order to produce the 31403Hz sample frequency from the 3.58Mhz video clock. On every 114th video cycle the two audio channels are processed and the volume of each channel mixed to produce a single volume value. https://github.com/JetSetIlly/Gopher2600/tree/master/hardware/tia/audio When writing to an audio buffer therefore, an output volume (an 8bit value in the case of Gopher2600) is written every 114 video cycles. If the playback sample rate is set to 31403Hz then the sound heard should be correct. To answer the question, "what kind of result should I get in the buffer?" my answer is a stream of samples (bytes) at a rate of 31403 per second. Hope this helps.

Superb

What about the 1973 George Lucas film, American GraffiTIA?

No. There isn't. I think we can get the amount of flickering much lower. It would be nice to replicate this rendering kernel for the game.

Heh. Cheers. It's only an experiment really and people are free to hack on it to improve it.

Yes. I thought about using the second keypad in this way. Another possibility is the paddle to quickly scroll to the correct letter. All good ideas to experiment with.

I can't see the image but anything that can improve input would be good.

Sorry. Here's the binary. https://github.com/JetSetIlly/Adventureland-2600/releases/tag/v0.1

I've had a go at porting Scott Adams' Adventureland, mainly out of interest to see if this kind of text adventure was possible on the 2600. It's a more or less straight compile (some changes) of the C version of Adventureland to ARM. I added the main ARM program which: - accepts keypad input by cycling through groups of letters (phone pad style) - packing letter glyphs into datastreams (two glyphs per datastream) - does some basic word wrapping The 6507 program meanwhile renders the 15 datastreams producing a 30 column text display. For this first version, the renderer is very simple and works over three frames so a slow phosphor fade is recommended. Adding a more advanced text renderer (ie. one that works over two frames) should be possible It's just a case of reading and ordering the 15 datastreams appropriately and you shouldn't need to touch the ARM program. Binary and source on github. https://github.com/JetSetIlly/Adventureland-2600/ As I say, I wrote it out of curiosity and experimentation but it might prove fun to play.

This is a lot more effective than I was expecting. Well done.

Quite a lot has changed in the few weeks so I've packaged up another release. Windows and Linux binaries (AMD64) on the github page. https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.13 Full change log in the link but the most significant changes are: 1) Better ARM/Thumb cycle counting. This still isn't 100% but I've managed to improve the accuracy considerably after chatting things through with @Thomas Jentzsch and getting some valuable feedback from @Andrew Davie. More significant than cycle-counting, Andrew identified an issue that turned out to be a subtle but serious bug in the LDMIA instruction. This is now fixed along with a bug in the format 15 CMP instruction. 2) Support for the STM32F407VGT6 memory map. This is the ARM chip that is found in the PlusCart. This should help when developing CDFJ games that can run on that cartridge. I know @Al_Nafuur has been trying this out and has had some success. 3) Better ghosting effect on the TV screen. My previous bilinear filter was applied horizontally and vertically. This is wrong and created ugly artefacts, more noticeable on some ROMs that others. Using Zookeeper as an example, this is from the new version. And a close up from Hack'Em Hangly Man If the ghosting effect is too strong, there is a slider in the CRT Preferences window (F10 in playmode) for you to adjust. 4) Also added is a screen roll sensitivity slider. This controls how tolerant the screen is of unsynced TV frames. Related to this is how aggressive screen "resizing" is. By this I mean the process of deciding how many scanlines are required to be displayed but no more than necessary (and it's not as easy as looking for the VBLANK signal). I've tried several strategies over the last year or so and I'm now finally satisfied with it. As part of these improvements the FPS indicator (F7 in playmode) now shows more information. In addition to current FPS it will now show basic TV information including whether the screen in "unsynced". 5) Better static disassembly and fixed symbols usage. Figuring out what bytes in a ROM is an instruction is not always straightforward without actually executing the ROM. This is now a lot better I feel but as ever I welcome feedback on this and any other issue. Enjoy.

A few months ago I was talking about techniques for capturing screenshots of games that use flicker kernels. Today when I was implementing a pause feature for play-mode I was reminded that similar problems exist for the paused screen. My solution is to assume that a display is interlaced on a two-frame cycle and to continue the flicker through inference. I think the results are pretty good (video below) Of course, the same problems that arise when creating screenshots also apply here. So, displays that flicker on a three frame cycle or have elements that flicker at different rates will have suboptimal results. Also, displays that have no flicker but have moving objects will "shimmer" when paused. But IMO, this is better than showing a single frame which to the eye looks to have missing elements. Ideally, we would be able to detect what kind of kernel the ROM is using and use the appropriate method. However, this would involve an analysis of the pixels being pushed by the TIA I think and isn't at all trivial. But it is something to keep in mind I think. output.mp4 Game is Zookeeper from @johnnywc

I've used the data and ROMs Thomas has posted and used them to improve the cycle counting in Gopher2600. There are a couple of problem areas but on the whole it seems fairly consistent in all combinations. Certainly, all real-world ROMs that I have been using for testing (Turbo, Draconian, Zaxxon, etc.) continue to perform as expected (causing screen roll or not depending on the MAM settings). If nothing else it shows that 100% accuracy is within reach.

This is really useful data. For what it's worth, Gopher2600 is close in some areas and not in others. If we look at MAM-0 for example O0 and Os are pretty around 100% but O2 and O3 are less than 100% so something is happening in the optimised code which is upsetting the emulation. I'll take a closer look to see what the differences are.

Oh I see what you mean. Yes. I've been working on the assumption that SRAM has no waiting.

It affects peripherals. So, anything with an address in the range 0xE0000000 to 0xEFFFFFFF is on the peripheral bus. SRAM is not on that bus so is not affected by the APB divider.

Thanks.

Do we know if the Harmony driver sets the APB divider to 1 or if it has been left at the default rate of 1/4. I'm guessing it's set to 1 but I don't know.

Does the Encore have a 70MHz processor like the original Harmony?