Jump to content
JetSetIlly

Gopher2600 - v0.14.1

Recommended Posts

on edit: Latest version is 0.14.1 https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.14.1

 

Hello AtariAge,

 

I've been working a Atari 2600 emulator for the last year or so and thought AtariAge would like to see what I've been up to. I originally started it as a fun way to learn the Go language but it's turned out to be quite usable so I've decided to release it. It's not a complete emulator yet but it runs at full speed on modest machines (although not as efficiently as a C or C++ implementation), has audio (based on Ron Fries' original code), accurate video output, and a fairly useful debugger. The GitHub repository is here:

 

https://github.com/JetSetIlly/Gopher2600

 

I appreciate that the implementation language is a little unusual so I've also prepared a binary. Linux only I'm afraid because I don't have access to any other type of machine. Binary is here:

 

https://github.com/JetSetIlly/Gopher2600/releases

 

As I say, the project is not yet complete but I would love it if some of you could have a play and see if you can break it. I'm sure you can. Not all CPU opcodes are implemented - I've taken the view that I should only add undocumented 6507 opcodes when I encounter them. Similarly, not all cartridge formats are supported. Currently, it supports: the atari formats; parker bros; mnetwork; cbs; and tigervision (including 32k tigervision). However, I don't know if they work in all cases.

 

Also, I can only apologise for the debugger. It currently does not have a GUI interface, aside from the TV screen output. But if you can stand using a line terminal, it works quite well.

 

I've listed the resources I've used in the GitHub readme. It may not be clear from that however, just how useful the AtariAge discussion boards have been. In particular, the test roms that are often posted here, have proved invaluable. For example, NUSIZtest.bin, from this page:

 

 

And many other such examples. I've used these ROMs, and some of my own, during regression testing. The emulator has a nice feature which automates regression tests and it would be nice to release the regression database alongside the binary. I've not done this yet however, because I don't want to distribute other people's work without the correct licencing. What would the AtariAge position be on this?

 

Finally, for a bit of fun, this is a screen recording I made of an earlier version of the emulator running the demo, Chiphead by KK of Altair. I made a mistake when recording it, and it is running in NTSC with NTSC colors but even so, it shows off the emulator quite well I think.

 

 

 

Edited by JetSetIlly
  • Like 15
  • Thanks 2

Share this post


Link to post
Share on other sites

I'll try this my laptop. I primarily use 2600.emu to run roms before they get put on my Harmony. Using a smartphone more often that a PC it's a convenience thing. Glad to see someone else dedicating themselves to 2600 emulation.

Sent from my SM-N960U using Tapatalk

  • Like 1

Share this post


Link to post
Share on other sites

Very nice work, that's very good TIA emulation. I have gone though some of the usual suspects that I remember from the top of my head and didn't manage to break it 😛 There's a whole bunch of tricky testcases on the Stella bug tracker, but I am afraid that I don't have time to go through those right now. I have attached my Mac binary, hopefully, this will widen the circle of testers a bit.

 

gopher2600.zip

  • Like 2

Share this post


Link to post
Share on other sites

OK, I finally found some ROMs with glitches: Mr. Roboto (a Bezerk hack by Paul Slocum) and Panda Chase. However, I think those are more likely related to RIOT emulation. I think you will find the following thread from the Stella tracker interesting: https://github.com/stella-emu/stella/issues/97 

 

I really hope that you continue to develop this and add support for more cartridge formats --- imo it is really good to have more emulators with that level of accuracy around 👍

Edited by DirtyHairy
  • Like 1

Share this post


Link to post
Share on other sites
3 minutes ago, DirtyHairy said:

OK, I finally found some ROMs with glitches: Mr. Roboto (a Bezerk hack by Paul Slocum) and Panda Chase. However, I think those are more likely related to RIOT emulation. I think you will find the following thread from the Stella tracker interesting: https://github.com/stella-emu/stella/issues/97 

 

I really hope that you continue to develop this and add support for more cartridge formats --- imo it is really good to have more emulators with that level of accuracy around 👍

Cheers. I'll play around with those two ROMs tomorrow and see what the problem is. I'll report back.

 

I've attached a playback recording of Panda Chase. Is this the glitch you're talking about or is there something else? (you can play back recordings by specifying the recording file instead of the cartridge. So long as the actual ROM is in the correct location then it'll work. In this case "Panda Chase.bin" should be in the directory from where you launch the program.)

 

I'll definitely be continuing development. I have plans for tooling that I want to implement and of course lots of bugs to fix 🙂

 

Thanks for your help.

recording_Panda Chase_20200119_001736

Share this post


Link to post
Share on other sites
12 hours ago, JetSetIlly said:

I've attached a playback recording of Panda Chase. Is this the glitch you're talking about or is there something else?

Yes, that's what I meant. There are other artifacts in other parts of the game, but the ROM is pretty buggy, and I have not done a detailed comparision, so it might well be that those others are actually correct ;) 

Share this post


Link to post
Share on other sites
2 minutes ago, DirtyHairy said:

Yes, that's what I meant. There are other artifacts in other parts of the game, but the ROM is pretty buggy, and I have not done a detailed comparision, so it might well be that those others are actually correct ;) 

Excellent. I've literally just found and fixed that bug (in Panda Chase)

 

It was caused by the timing of when HMOVE values are set. I had previously decided that there must be a delay (in video cycles) before a new HMOVE value is valid. Midnight Madness for example, requires a delay of at least cycle and the Barber Pole test requires no more than 3. I wasn't sure which value was required exactly, and had arbitrarily gone for 3 cycles. However, Panda Chase has confirmed that the delay must be (at least in my code) no more than 2 cycles. I've now set it at 1 cycle.

 

I've pushed the changes to the master branch in the GitHub repository.

 

I've also found the bug in the Mr Roboto ROM and know exactly what's wrong but I'm not sure the best way of fixing it. I'll look again this evening. I may have some questions though because it's in an area of the VCS I'm unsure about.

 

Thanks again for your help.

Share this post


Link to post
Share on other sites
14 minutes ago, JetSetIlly said:

It was caused by the timing of when HMOVE values are set. I had previously decided that there must be a delay (in video cycles) before a new HMOVE value is valid. Midnight Madness for example, requires a delay of at least cycle and the Barber Pole test requires no more than 3. I wasn't sure which value was required exactly, and had arbitrarily gone for 3 cycles. However, Panda Chase has confirmed that the delay must be (at least in my code) no more than 2 cycles. I've now set it at 1 cycle.

Yeah, there is a clocking delay before a new HMOVE value takes effect. In my core (Stella and 6502.ts), the delay is set to two cycles, but of course, the exact value depends on the details on how timing is implemented in the code, so that may just as well correspond to one cycle in your core 😏

 

14 minutes ago, JetSetIlly said:

I've also found the bug in the Mr Roboto ROM and know exactly what's wrong but I'm not sure the best way of fixing it. I'll look again this evening. I may have some questions though because it's in an area of the VCS I'm unsure about.

 

Thanks again for your help.

Sure, happy to be of assistance. As I said, I am excited by another, completely independent, VCS emulation with that level of accuracy.

Edited by DirtyHairy

Share this post


Link to post
Share on other sites

The Mr Roboto ROM problem: The artifacts on the left hand side of the title screen are missiles that have been enabled in error. Why have they been enabled in error?

 

On the affected scanlines, they are enabled (or not) by the STA instruction at $f095. The A register has just been set by a post-indexed indirect LDA.

 

0xf093 LDA ($8f),Y
0xf095 STA ENAM0

 

The question is why does A have an incorrect value after the LDA? On scanline 121, for example, A contains the value $2b. Why?

 

Well, at the time of the instruction, the Y register contains the value $2b and memory address $8f contains a value of zero. So the address the LDA will read from is $2b. Which is a mirror of $0b, or INPT3.

 

Now, here was my mistake. I had been lazy when building the CPU to memory interface and effectively said that, "reading any address of $ff or below is a zero page address". But of course, this isn't true. Post-indexed indirect addressing always "sends" 16 bit addresses, the LSB followed by the MSB.  In the example, the MSB of the address is $00. So the returned data is the high-bit of INPT3 combined with the lower-7 address bits of the MSB and NOT the LSB.

 

I've corrected the mistake by and updated the GitHub repository.

  • Like 1

Share this post


Link to post
Share on other sites

Hello everyone. Thanks for the help that has allowed me to get this far in the development of Gopher2600.

 

I'm posting again because I've recently added paddle and keyboard support to Gopher2600. Both work well and it would be great

if other people had a look and gave me some feedback.

 

I've also fixed some TIA timing issues since my last post and you may notice an improvement in the responsiveness of the GUI. The GitHub readme file has also been greatly expanded and covers topics I had previously glossed over. Source and readme here:

 

https://github.com/JetSetIlly/Gopher2600

 

Binary pre-release for 64bit Linux systems added to the releases section. DirtyHairy: please could you prepare a MacOS binary again? And if someone else could help to prepare a Windows binary, that would be fantastic.

 

https://github.com/JetSetIlly/Gopher2600/releases/tag/atariAgePreview010220

 

Edited by JetSetIlly

Share this post


Link to post
Share on other sites
5 hours ago, Thomas Jentzsch said:

You could checkout the games which caused (and cause) problems in Stella:

 

https://github.com/stella-emu/stella/labels/glitched game

 

Interesting. I've not seen this list before. In fact I've not even heard of some of the games mentioned!

 

The Cosmic Ark style star effect problem is interesting, isn't it. Up until now, in my code, the stars never disappeared in Cosmic Ark. They only fluctuated between one and two clks. I hadn't really noticed before but the "starfield" and "StarsEffect" test ROMs have helped me better see the

problem.

 

This was the AtariAge discussion I originally used to help me understand what was going on.

 

 

I've committed my changes to GitHub master. I'm reading that Stay Frosty utilises this effect but that ROM isn't working for other reasons so I can't test it just yet. I'll fix that problem next.

 

on edit:

 

Hmm. My code initialised Atari carts to point to the *last* bank in the cartridge. Never been a problem before but Stay Frosty has revealed that to be an error. Infuriatingly, my code is lacking commentary for why I decided the starting point should be the last bank. Either way, I'm pleased to see the star effect is present.

Edited by JetSetIlly

Share this post


Link to post
Share on other sites
7 hours ago, Thomas Jentzsch said:

You could checkout the games which caused (and cause) problems in Stella:

 

https://github.com/stella-emu/stella/labels/glitched game

 

It's interesting following the links and reading how some of these issues have been recognised and resolved. For instance, the Keystone Kapers problem, when the ball is being reset at the very end of the scanline. I know this scenario well and it gave me headaches trying to figure out what was happening. What I find interesting is that the direction I've solved it from seems to be different to the direction from which the problem was solved in Stella.

 

 

My interpretation of what is happening is that the delay, although affected by HBLANK, is not the whole story. Rather it is the order of events, that happen in the system as a whole, which is of more importance to this particular problem. In fact, it was this very bug which made me realise that and it led to a massive breakthrough in the TIA implementation. Playing with the delays did not help me at all in this instance.

 

Maybe Stella had the correct ordering before the problem was noticed and only needed the delays to be tweaked; whereas in gopher2600's case the opposite was true.

 

Whatever the reason, this justifies my development approach: to only use Andrew Tower's TIA document, the schematics and only looking for general discussion when stuck and never at implementation details. Otherwise my interpretations would have been influenced by what had gone before, and what would have been the point in that?

 

I'm still having fun 🙂

Edited by JetSetIlly
  • Like 3

Share this post


Link to post
Share on other sites
13 hours ago, JetSetIlly said:

Whatever the reason, this justifies my development approach: to only use Andrew Tower's TIA document, the schematics and only looking for general discussion when stuck and never at implementation details. Otherwise my interpretations would have been influenced by what had gone before, and what would have been the point in that?

 

 

I'm watching your excellent work with interest. Great job!

I take some credit for personally introducing Andrew Towers to the '2600. He and I worked together briefly many years ago.

Smart guy.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
2 hours ago, Andrew Davie said:

 

I'm watching your excellent work with interest. Great job!

I take some credit for personally introducing Andrew Towers to the '2600. He and I worked together briefly many years ago.

Smart guy.

 

He is a smart guy. It comes through in the document.

 

Thanks for you interest!

Share this post


Link to post
Share on other sites
On 2/3/2020 at 7:07 PM, JetSetIlly said:

Whatever the reason, this justifies my development approach: to only use Andrew Tower's TIA document, the schematics and only looking for general discussion when stuck and never at implementation details. Otherwise my interpretations would have been influenced by what had gone before, and what would have been the point in that?

 

I'm still having fun 🙂

X2! Awesome - and definitely the most fun.

 

It's good to see programmers taking different paths and approaches for emulation instead of reusing the same codebases. You miss out on a lot otherwise particularly on solving the puzzles with a different approach :)

 

  • Like 1

Share this post


Link to post
Share on other sites

I mentioned in a previous post about how I recognised that the ordering of events during a video cycle was important. The events effect one another even during a single video cycle and must be treated with care. I thought it would be fun to illustrate this with a timeline diagram of the video cycle as interpreted by Gopher2600. I consider this to be a first draft.

 

https://github.com/JetSetIlly/Gopher2600-Dev-Docs/blob/master/Gopher2600 Video Cycle Timeline.pdf

 

This sort of exercise is always worthwhile I find. It gives you a different perspective on the code. In fact, while I was preparing this document this evening, I've spotted areas in the code that will benefit from some more attention - additional commentary, untangling of some thorny conditions, etc. But that's a task for tomorrow.

 

Enjoy!

 

Edited by JetSetIlly
URL of document changed

Share this post


Link to post
Share on other sites

I've added a new windowed interface to Gopher2600. This will form the basis of a new debugger. I've pushed the changes to the Github repository but not packaged a new release so anyone interested will have to compile it themselves. Go has a very good build system so there shouldn't be any problems if anyone chooses to do this.

 

The new interface is specified with a command line flag:

 

    gopher2600 -imgui <path to rom>

Screenshot below for people who do not have a Go dev environment or want to install one.

 

I've also added an audio silence detector, which helps with audio buffer exhaustion on slow machines (like mine 🙂)

 

(Updated screenshot 14/02/20)

 

keystone_imgui2.thumb.png.46ef59d72c3e88d13ecfd118389bb144.png

 

(Original screenshot)

 

keystone_imgui.thumb.png.04815703e208b783b56585236bb1c9b1.png

Edited by JetSetIlly
Updated screenshot

Share this post


Link to post
Share on other sites
10 hours ago, JetSetIlly said:

I've added a new windowed interface to Gopher2600. This will form the basis of a new debugger. I've pushed the changes to the Github repository but not packaged a new release so anyone interested will have to compile it themselves. Go has a very good build system so there shouldn't be any problems if anyone chooses to do this.

 

The new interface is specified with a command line flag:

 

    gopher2600 -imgui <path to rom>

 

Screenshot below for people who do not have a Go dev environment or want to install one.

 

I've also added an audio silence detector, which helps with audio buffer exhaustion on slow machines (like mine 🙂 )

 

keystone_imgui.png

Dear ImGUI... excellent !

 

Share this post


Link to post
Share on other sites
22 hours ago, FizzyChicken said:

Dear ImGUI... excellent !

 

It is. It has an unusual API but it's very flexible. I'm very happy with it.

Share this post


Link to post
Share on other sites
On 1/18/2020 at 3:17 PM, JetSetIlly said:

I've been working a Atari 2600 emulator for the last year or so and thought AtariAge would like to see what I've been up to. I originally started it as a fun way to learn the Go language

 

 

Using "Go" to write an "Atari" emulator? How appropriate! 😎

  • Haha 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...