JetSetIlly

On screen display debugger-2021-10-26_19.47.04.mp4

Demo video of the emulator running the excellent Game Of The Bear @vhzc. This demonstrates the rewind system now that it is available from the "playmode". There's no OSD yet but hopefully it is obvious when the rewind is being applied.

The tape "plays" and "stops" and "rewinds" automatically when the 6507 requires it. This is my current strategy: 1) Tape will play when address 1ff9 (or any of the cartridge mirrors) is read. The RAM write bit must also be set for the tape to start playing. 2) Tape will stop when address fa1a (specifically) is read. This is the point in the BIOS at which the program jumps to VCS RAM (at address 0x00fa) and the loaded program begins. 3) Rewinding: The "tape" is just a sound file (the emulator supports most WAV and MP3 files) so "playing" is nothing more than keeping track of how much of the file has been read and moving that progress pointer along every CPU cycle. "Rewinding" therefore, is just a case of resetting the progress pointer to zero when the end of the file has been reached. An interesting question is: can you turn those signals I've described above into hardware? Somebody might have already done this but I wonder if you could have a Commodore 64 type cassette recorder than started and stopped automatically when the above conditions are met? But that's a question for the electronics experts.

I've added a feature to the debugger this weekend that I've wanted to add for some time. A timeline window showing information traces for the system over time. For now, it is only showing traces for TV stability (the red line) and left-player input (the green line). But there's potential for lots more I think. Network / tape activity; ARM CPU load; audio activity; all sorts of things I'm sure. The TV trace in particular should prove useful to help visualise and quickly find problem frames (ie. scanline count changing from frame to frame). The window also doubles up as a way of rewinding to a previous state. The moving orange bar indicating what states are available. The latest code is on Github for those interested. And if anyone has any ideas for how I can extend this idea, I'd love to hear them. debugger-2021-10-16_18.22.59.mp4

Cheers. I've got some performance improvements for the debugger in the pipeline for the next version. This has allowed me to make the rewind feature more interactive and more natural feeling. I've attached a short video below. debugger-2021-09-26_22.18.00.mp4 Simply by selecting the pixel on the screen, the emulation instantly sets itself to how it is at that *video cycle*. As of version 0.14 you can do this but it feels clunky by comparison to the development version. Notice how the CPU window is showing half decoded instructions. Stepping by CPU instruction is the usual thing in a emulator/debugger, but I feel that being able to step (forwards and backwards) by color-clock is helpful. Particularly with the 2600 where the image on the screen is so closely tied to the current state of the machine. Incidentally I snuck out v0.14.1 yesterday which has support for the right-side player joystick. I added this when @Al_Nafuur pointed out that he couldn't play Nukey Shay's Missile Command hack without it. Keys for the second joystick are the same as the defaults in Stella. https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.14.1

v0.14 is about 10% faster on my development machine. Feedback from MacOS and Windows users also indicate noticeable improvements. https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.14 Among the changes is the addition of stereo sound. Selectable in the preferences window (F10 in playmode; in the menus in the debugger). I've also included a three point slider to indicate the amount of stereo separation (narrow, wide, discrete). I've also improved the mono mixing as advised by @Crispy in his document "TIA Sounding Off in the Digital Domain". I've not yet tackled the other audio issue mentioned in this thread (below). Also worth mentioning that these changes to the audio system seem to have fixed sound issues that @Al_Nafuur was experiencing on Windows. So if you're a Windows user and were put off by this, give it another go and see what you think! I managed to break the VSYNC counter sometime between v0.12 and v0.13. This wasn't noticeable except for the effect it had on RSYNC, which is rarely seen. One particularly neat RSYNC demo is now working again as intended. The Smooth Scrolling Playfield by @eshu Supercharger tape loading is improved and seems to be less fussy about MP3 and WAV files than before. In particular, at @Mr SQL's request, I've made sure that his KC OS can load as intended. I've also added a nice notification icon to indicate when the Supercharger tape is being played. There's a similar notification for when the tape has been rewound. Similarly, PlusROM cartridges will notify when there is network activity. (Both of these notifications can be turned off in the preferences window) Finally, there is support for the new Moviecart kernel. @rbairos has done some smart work improving what was already an impressive project. Demo video (encoded by @Andrew Davie). debugger-2021-09-16_18.45.17.mp4 You can also see me fiddling with the CRT controls in this. The gaps you can see in the moviecart display are caused by bilinear filtering. This is my way of emulating RF ghosting sometimes seen on televisions fed by an analogue signal. They can be a bit distracting so I lowered the intensity while the moviecart was playing. My TODO list isn't getting any shorted so I'll be adding to the emulator for a while yet. In the meantime, I'd be very pleased if you could all give it a go and let me know what you think.

If the format is to include metadata then it should include the name of the movie too.

Yeah. It's bilinear filtering to emulate ghosting. I have it set like by default so the separation in the Zookeeper bricks is nice and sharp. You can scale the effect strength down. Here's another version with it set to the minimum. debugger-2021-09-12_23.12.26.mp4

Agreed. On edit: For reference: Stella with fix. debugger-2021-09-12_21.33.45.mp4

It does, doesn't it. I kept the window small and that helps but honestly it looks good "live". It's an excellent encoding algorithm. Maybe. I set the oddField flag by looking at bit 0 of the fieldNumber value that is encoded in the movie file. It's a few months since I looked at that bit of code but from memory, I treated fields differently to how you did in Stella. So it's possible I've accidentally smoothed over the issue.

No. It doesn't. Two videos for comparison. Gopher2600 first debugger-2021-09-12_20.31.10.mp4 Stella debugger-2021-09-12_20.31.56.mp4 on edit: Gopher2600 without CRT filter for closer comparison debugger-2021-09-12_20.38.02.mp4

The issue @Andrew Davie described with the Kong video is still present or is that what you mean by the step-right issue? If you just let the video play, without fast forwarding, the video breaks down towards the end.

When I was your age, DVDs were called Moviecarts!

Feature idea: Encoding with the intention that the TV is to be viewed on it's side. By doing this, you could get a picture wider than it is tall and closer to the normal TV ratio. Additional idea: a single bit in the cartridge that indicates the orientation of the encoding. It wouldn't do anything on the hardware (except maybe an LED indicator) but it could be used by emulators to rotate the TV output automatically.

New moviecart core pushed to master branch of Gopher2600, @Andrew Davie For future reference, after you've cloned a repository (git clone <url>) you can pull another branch with "git pull origin <branch>". After that you can checkout the branch with "git checkout <branch>" @rbairos It looks and sounds fantastic!

Interesting. Although we should be careful because the version of Gopher2600 you've tried there is using the older core.bin from last week. Whereas Stella is using the newer core.bin from today. Pull this branch of Gopher2600 for a true comparison https://github.com/JetSetIlly/Gopher2600/tree/moviecart That said, you might be right. This the last frame with the new core.bin

Gotchya. The Volume bars and labels are part of the hardware/emulation but the time code is part of the encoding.

The time-counter OSD for the movie files @Andrew Davie has created are messed up when compared to your files, @rbairos. In Stella as well as the Gopher2600 port. Why would that be? on edit: added screenshots. * using the latest core.bin so the gap is present. But it is also the case with the previous core.bin

Thanks for the endorsement but I should mention the KC OS wav files struggle on the current release of Gopher2600. It works nicely on the development version though. I'll release a new version of the emulator soon hopefully. Couple of other things I want to tick off the TODO list first.

Nice.

That's not my understanding. The playfield/background will show through the gaps in the sprite, giving more colour resolution to the movie per scanline (six colours per scanline by my counting).

The PF pattern is fixed. Colours for PF and BK are set every alternate scanline. For the duration of a scanline, one of the colours will be black and the other will be another colour (possibly black). I would agree with that.

Playfield and background show through the gaps in the player sprites.

How will this affect the fill_addr_right_line() and fill_addr_left_line() functions?

Enabling VBLANK is quite flexible and a good way of adding video-black to the image. From memory Custer's Revenge does this, as well as one of the recent Donkey Kong ports. Didn't know about the Parrot Kernel but yes, that's probably the best example in relation to movie cart. If you can find the CPU time to do this it would make the project even better I think.