[Gopher2600 (continuing development on Github)]

On screen display

 

[Gopher2600 (continuing development on Github)]

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.

 

 

[Gopher2600 (continuing development on Github)]

1 hour ago, Mr SQL said:

This is fantastic for developing cycle accurate SuperCharger code in Gopher guaranteed run on a real SuperCharger.

 

Stella and some emulated BIOS stubs have pitfalls and can run fakeout code that does not work on genuine SuperCharger hardware and gets locked in a loading loop at contest time. Not the best choice for pro quality development particularly with Audacity raising the bar on the classics  

 

How do you know when the tape is rewound? Do you mean when it stops?

 

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.

[Gopher2600 (continuing development on Github)]

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.

 

[Gopher2600 (continuing development on Github)]

39 minutes ago, Dionoid said:

The performance has increased a lot for version 0.14. Great work, @JetSetIlly!

 

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.

 

 

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

[Gopher2600 (continuing development on Github)]

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

 

 

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.

 

 

[Movie Cart]

2 minutes ago, Thomas Jentzsch said:

Good idea! But SECAM movies on an Atari 2600...?  

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

[Movie Cart]

Just now, Andrew Davie said:

 

That CRT filter sure seems to over-emphasises the vertical black lines between the sprites.

Maybe you could reduce the gap if you know the filter is on?

 

 

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.

 

[Movie Cart]

34 minutes ago, rbairos said:

Alright. Fixed!
716c14ecfc95b

Agreed.

 

On edit: For reference: Stella with fix.

 

[Movie Cart]

2 minutes ago, rbairos said:

First of all.
I know turning it into a video, blends alot of the jarriness back out, but holy moly looks great!

 

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.

 

2 minutes ago, rbairos said:

 

Okay, I'll poke around.
Im wondering if at that point in the encoding it was paused and restarted so there's two even (or odd ) numbered frames in a row, and I'm suddenly looking at the wrong buffer. Similar issues happened in the past.

 

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.

 

[Movie Cart]

15 minutes ago, rbairos said:

I'm not sure about that.
It happens on gopher as well?

 

No. It doesn't.

 

Two videos for comparison. Gopher2600 first

 

 

Stella

 

 

on edit: Gopher2600 without CRT filter for closer comparison

 

 

[Movie Cart]

10 minutes ago, rbairos said:

Yup, my OSD data array needed an extra blank line.
This is now part of the pull request.

(Couldn't reproduce the step-right issue, think it was user error, as I may not have been in timecode mode)
 

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.

[Movie Cart]

18 minutes ago, Andrew Davie said:

I'm encoding "Princess Bride"

 

When I was your age, DVDs were called Moviecarts!

[Movie Cart]

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.

[Movie Cart]

12 minutes ago, Andrew Davie said:

I am not setup with the correct branch of gopher to check/confirm behaviour definitively on that emulator.

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!

[Movie Cart]

14 minutes ago, Andrew Davie said:

I suspect a bug in stella implementation...?   Late in the "Kong" MVC, the movie starts exhibiting significant corruption.

Some stella frames...  we're looking at the horizontal lines/corruption

 

 

 

 

The reason I think the MVC file is OK is because Gopher displays the same without corruption (e.g., the last frame of the movie...)

stella...

gopher...

 

 

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

 

[Movie Cart]

14 minutes ago, rbairos said:

It may not have the same font installed on his mac that is used during encoding.

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

[Movie Cart]

1 hour ago, rbairos said:

Okay, I'll shift that dummy line.

Reason I have org's everywhere is the hardware version of this was implemented with a 1K dual-port ram.
It monitored line A7 to determine which of the eight 128-byte regions it was in, to know what to update.
The emulator also monitors A7 for the same reason.
Didn't know about the ALIGN macro, though I still have to be very specific where everything lives.

Stay tuned..
 

 

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

 

 

[Do you still use your Supercharger cassette tapes?]

1 hour ago, Mr SQL said:

You can also try KC OS online here in Javatari or play the ROM in Gopher which uses the real SuperCharger BIOS. Fancy carts are only partially supported but SuperCharger compatibility will improve as firmware upgrades more closely match the BIOS.

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.

 

[Movie Cart]

2 minutes ago, Thomas Jentzsch said:

Here is my simple kernel demo from above modified. No extra cycles and no flicker left or right anymore.

movie_kernel_v2.bin 2 kB · 1 download

Nice.

[Movie Cart]

4 minutes ago, Thomas Jentzsch said:

This is done to create a checkerboard which is inverse to the sprite checkerboard, right? So the background of each sprite is always black.

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

[Movie Cart]

1 minute ago, Thomas Jentzsch said:

So the playfield gets a fixed pattern? Colors seems to be updated for BK every line, for PF per frame. Correct? 

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

1 minute ago, Thomas Jentzsch said:

 

That means all 4 colors are in use. If none of them is set to permanent black, you cannot hide the background color changes. That leaves VBLANK (two extra TIA writes) or changing the BK (or PF) color twice per line (one extra TIA write).

I would agree with that.

 

 

 

[Movie Cart]

8 minutes ago, Thomas Jentzsch said:

Is there a summary how the picture is currently created? I know about the 10 flickering sprites, each having its own color. But how are playfield and background (colors) involved?

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

[Movie Cart]

13 minutes ago, rbairos said:

Still hunting for spare cycles.
Did a quick test where I only update audio every 2nd scanline for the visible 192 lines. (7.5 kHz)
To be honest, couldn't tell the difference.  (Even with overscan and vsync portions still updating at 15 kHz)

Probably blacking out the sides is worth dropping to 7.5 kHz, it seems.
 

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

[Movie Cart]

4 hours ago, rbairos said:

Hm. very interesting thread. Not sure I followed though.
Doesn't messing with Vblank cause the raster beam to shoot back up to the top early?
Also good reminder I should be using a proper color space in my search.
 

 

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.