Gopher2600 (continuing development on Github)

[JetSetIlly]

On 11/9/2023 at 7:12 PM, SpiceWare said:

Hopefully one of them can provide some insight on goimports.  In case it matters, Homebrew is what I used to install Go and SDL on my Mac.

The consensus from the Go developers I know who use the Mac, is to use the official Go distribution not the one from Homebrew. It installs to /usr/local though, so I'm not sure how you feel about that. https://go.dev/doc/install

[+SpiceWare]

43 minutes ago, JetSetIlly said:

The consensus from the Go developers I know who use the Mac, is to use the official Go distribution not the one from Homebrew. It installs to /usr/local though, so I'm not sure how you feel about that. https://go.dev/doc/install

Thanks! I'll uninstall homebrew Go and install the official one. Might be a few days before I get to it as the Houston Arcade Expo is this weekend. 

[JetSetIlly]

Following in the footsteps of @Al_Nafuur et al who are working to get Stella running on the Raspberry Pi, I'm doing the same with Gopher2600. First stage of the build is complete.

The first step was to rewrite the OpenGL renderer. I was targetting version 3.2 and using custom shaders for various things. The Pi however wasn't happy with that so I've added an alternative GL renderer that targets version 2.1. It's not fully featured but it's good enough for this experiment.

GPIO acess: To begin with, I'm taking a very naive approach and simply setting the address bus and reading the data bus immediately. I'm not thinking about timings on edge detection or anything like that. All I'm interested in at this stage is whether I can get data off the cartridge.

Whether that approach is successful depends very much on the cartridge. Fortunately, I happened to pick one that does work, Yar's Revenge. Here's a video showing the hardware and the game running in the emulator.

https://www.youtube.com/watch?v=sigMPHoeacM

The first thing to note is that it's slow. That's partly because Gopher2600 is not running at full speed on the Pi even for dumped ROMs, but the GPIO communication is introducing a little inefficiency too.

As a first experiment that took a couple of hours to get going (once I had all the necessary cables) I'm going to say this is small victory. 

Next step is to get multi-bank cartridges to work. But that'll take some hard thinking.

 

 

 

This follows on from some earlier work I did with reading cartridges over USB. It wasn't an entirely successful experiment - I expected USB to be slow but it turns out that it's literally thousands of times too slow. But I learned some interesting things about the emulator that I didn't realise and improved how "live disassembly" worked, amongst some other small changes.

Edited November 22, 2023 by JetSetIlly

[+Al_Nafuur]

47 minutes ago, JetSetIlly said:

Following in the footsteps of @Al_Nafuur et al who are working to get Stella running on the Raspberry Pi, I'm doing the same with Gopher2600. First stage of the build is complete.

The first step was to rewrite the OpenGL renderer. I was targetting version 3.2 and using custom shaders for various things. The Pi however wasn't happy with that so I've added an alternative GL renderer that targets version 2.1. It's not fully featured but it's good enough for this experiment.

GPIO acess: To begin with, I'm taking a very naive approach and simply setting the address bus and reading the data bus immediately. I'm not thinking about timings on edge detection or anything like that. All I'm interested in at this stage is whether I can get data off the cartridge.

Whether that approach is successful depends very much on the cartridge. Fortunately, I happened to pick one that does work, Yar's Revenge. Here's a video showing the hardware and the game running in the emulator.

https://www.youtube.com/watch?v=sigMPHoeacM

The first thing to note is that it's slow. That's partly because Gopher2600 is not running at full speed on the Pi even for dumped ROMs, but the GPIO communication is introducing a little inefficiency too.

As a first experiment that took a couple of hours to get going (once I had all the necessary cables) I'm going to say this is small victory. 

Next step is to get multi-bank cartridges to work. But that'll take some hard thinking.

 

 

 

This follows on from some earlier work I did with reading cartridges over USB. It wasn't an entirely successful experiment - I expected USB to be slow but it turns out that it's literally thousands of times too slow. But I learned some interesting things about the emulator that I didn't realise and improved how "live disassembly" worked, amongst some other small changes.

Nice Work! 👍

Are you using a levelshifter or are you powering the cart with 3.3V?

[JetSetIlly]

Just now, Al_Nafuur said:

Nice Work! 👍

Are you using a levelshifter or are you powering the cart with 3.3V?

I'm using the 5V pin

[+Al_Nafuur]

4 minutes ago, JetSetIlly said:

I'm using the 5V pin

😱

The GPIOs of the Pi are not 5V tolerant 

[JetSetIlly]

1 minute ago, Al_Nafuur said:

😱

The GPIOs of the Pi are not 5V tolerant 

 

The red pins are labelled as 5V. It's the power that's coming from the Pi.

Are you saying the 2600 cartridge will run just as well from 3.3V?

 

[+Al_Nafuur]

26 minutes ago, JetSetIlly said:

 

The red pins are labelled as 5V. It's the power that's coming from the Pi.

Are you saying the 2600 cartridge will run just as well from 3.3V?

 

Maybe, I haven't tried. But the GPIOs will be destryed when you continue to use 5V

[JetSetIlly]

Just now, Al_Nafuur said:

Maybe, I haven't tried. But the GPIOs will be destryed when you continue to use 5V

Good tip. I'll use the 3.3V from now on.

[+Al_Nafuur]

1 hour ago, JetSetIlly said:

Good tip. I'll use the 3.3V from now on.

Which GPIOs are you using? 0-12 for the address bus and 13-20 for data bus?

 

[JetSetIlly]

7 hours ago, Al_Nafuur said:

Which GPIOs are you using? 0-12 for the address bus and 13-20 for data bus?

No. I went with physical order.

 

var AddressBus = [13]int{
        9, 10, 22, 27, 17, 4, 3, 2, 14, 15, 23, 18, 24,
}

 

var DataBus = [8]int{
        11, 5, 6, 16, 12, 7, 8, 25,
}

 

[+Al_Nafuur]

1 hour ago, JetSetIlly said:

No. I went with physical order.

 

var AddressBus = [13]int{
        9, 10, 22, 27, 17, 4, 3, 2, 14, 15, 23, 18, 24,
}

 

var DataBus = [8]int{
        11, 5, 6, 16, 12, 7, 8, 25,
}

 

🤔

are you clearing/setting every bit separately?

[JetSetIlly]

8 hours ago, Al_Nafuur said:

🤔

are you clearing/setting every bit separately?

I am, which I know is probably a mistake. That's the first thing to remedy I suspect.

[+Al_Nafuur]

1 hour ago, JetSetIlly said:

I am, which I know is probably a mistake. That's the first thing to remedy I suspect.

every intermediate address on the bus that is stable too long (~40ns) will be interpreted as the next address and the next cycle by the cartridge. For the 2/4K ROMs this is not an issue, because you are only reading the response to the last address. But as soon as you are starting to test more complicated carts you have to make sure not to touch a hotspot, and have the correct amounts of "cycles" for the cart (e.g. FE and SuperCharger banking) 

[JetSetIlly]

1 minute ago, Al_Nafuur said:

every intermediate address on the bus that is stable too long (~40ns) will be interpreted as the next address and the next cycle by the cartridge. For the 2/4K ROMs this is not an issue, because you are only reading the response to the last address. But as soon as you are starting to test more complicated carts you have to make sure not to touch a hotspot, and have the correct amounts of "cycles" for the cart (e.g. FE and SuperCharger banking) 

Yeah. I'll have to work hard to get to that stage

[JetSetIlly]

https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.27.0

 

This new release is the first to show a version number to the user. This was asked for by @Spiceware and makes a lot of sense. There was always a way to get the git revision but that's an awkward way to do things. The version number is now shown in the title bar of the window.

 

 

 

I've added the UA bank switching scheme. This shows the value of browsing AtariAge - I saw someone mention Time Pilot and was disappointed to see it didn't work. Thankfully, it was easy to add support. Stella was used as a reference for the hotspot addresses and fingerprint bytes.

 

I've added a Cycle quantum state to the debugger. This is in addition to the pre-existing Instruction and Clock quantums. The quantum state affects how the user interacts with the emulation through the debugger. For example, stepping forward will move forward either one instruction, one CPU cycle or one TIA colour clock, depending on the quantum state. The state is changed via the Control window (or by the QUANTUM command in the terminal). The button next to the step command shows the three options when pressed.

 

 

For most development purposes the instruction quantum is all you need but occasionally it's useful to understand what's happening on the data/address buses or the precise state of the TIA whilst it is in the middle of an instruction cycle.

 

I've also overhauled the CRT effects. The 'noise' effect is gone and is now part of the 'interference' effect. This new combination is better IMO. There is also a 'flicker' effect that causes a subtle flutter of brightness on the screen. I've also improved the bevel effect.

 

 

 

 

 

[+Karl G]

You had mentioned possibility adding 7800 emulation previously, so I'm curious if you have done anything with that since then? 

[JetSetIlly]

7 hours ago, Karl G said:

You had mentioned possibility adding 7800 emulation previously, so I'm curious if you have done anything with that since then? 

I haven't. I got massively waylaid over the summer with work on the ARM emulation and time since then has been tight. It's definitely still something I want to do.

[JetSetIlly]

Mostly bug fixes in v0.28.0 https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.28.0

 

Paddle movement is much improved in this version. I thought the deficiency was lag in the display chain but it turns out I had an artificial lag in the user-input sub-system. That's gone now and paddles now feel much smoother. It should improve all input methods for the paddle including the Stelladaptor. Unfortunately, I don't have a Stelladaptor to test and the person who tested it for me seems to be out of action. So if anyone can test to see if it still works, that would be very much appreciated.

 

I'm currently working on adding a Vulkan rendering option. OpenGL is slowly being deprecated on many operating systems and besides, Vulkan offers some interesting possibilities above and beyond OpenGL. I'm not sure what the end result will be just yet but I'm hopeful.

 

[JetSetIlly]

Experimenting with an improved ROM selector. Support for the stella.pro file and the retroarch box art images https://github.com/libretro-thumbnails/Atari_-_2600/tree/master/Named_Boxarts

 

Here are the results so far:

 

 

 

The box art is picked out by fuzzy matching the name in the stella.pro file with the available list of images.

 

The animated thumbnail is a real emulation so it works with any ROM including brand new, never before seen homebrews. That element has been in the project for a while but I'm not sure if I've drawn attention to it before.

 

I'm thinking of using the box art to create a bevel around the screen. That will need some experimentation to get right but it could look quite nice I think.

 

Thoughts?

[Thomas Jentzsch]

That animated thumbnail is pretty cool.  

 

Does it get past a title screen? You could emulate switches or button presses.

[JetSetIlly]

54 minutes ago, Thomas Jentzsch said:

That animated thumbnail is pretty cool.  

 

Does it get past a title screen? You could emulate switches or button presses.

I've been thinking about that. Some ROMs looks fine if you just leave them alone (Like Frogger) but some would be better if the game was being played.

 

Here's a quick hack. If the pixels don't change significantly for 3 seconds the Reset button is pressed. This works well for a game like Megamania.

 

 

 

Obviously, there's a lot of research to do but it's a nice idea and better than a black screen.

[Thomas Jentzsch]

After RESET, I would add a fire button press (left+right, joystick+paddles) too.

Edited February 5 by Thomas Jentzsch

[JetSetIlly]

Just now, Thomas Jentzsch said:

After RESET, I would add a fire button press (left+right, joystick+paddles) too.

Yes. But where does it end!? 🙂  I'm happy with a moving image which allows you to recognise the game.

[Thomas Jentzsch]

2 minutes ago, JetSetIlly said:

Yes. But where does it end!? 🙂  I'm happy with a moving image which allows you to recognise the game.

Not all games start with RESET. Some wait for a button.