Jump to content
IGNORED

Gopher2600 (continuing development on Github)


JetSetIlly

Recommended Posts

1 hour ago, Andrew Davie said:

Loving the functionality of the debugger! Great work; amazing skill... TY

 

1290031813_ScreenShot2021-01-29at2_33_20am.thumb.png.8d33bcd96c3c6b5bc701aa0530106c54.png

Cheers. I'll push the changes I've made over the last couple of days this evening. I just need to replicate what I've changed for CDFJ in the DPC+ code. And I need to check how it interacts with the rewind system too, but I don't see any big problems with that.

 

on edit: changes pushed to GitHub https://github.com/JetSetIlly/Gopher2600 @Andrew Davie

Edited by JetSetIlly
  • Like 2
Link to comment
Share on other sites

10 hours ago, JetSetIlly said:

Short video of the debugger with an ARM timing overlay (the purple pixels) sketched in. Still work in progress and it's nowhere near 100% accurate but I wanted to post now to show the potential of the idea.

 

What I need to do next is to factor in the speed of the different memory types.

 

At the moment I'm assuming that S and I cycles are the same length and N cycles are double the length of an S cycle. From what I understand of the ARM (which admittedly is not much) it is the length of the S cycle that can change depending on the memory type being accessed (N cycles being double of whatever the S cycle is).

 

The next step is add a to configuration window that will allow the dialing in of precise timings for each memory type.

 

From an emulation point of view this is now working more like what happens in the Harmony, although not precisely. Step 2 is a fudge, albeit one without serious side effects.

 

1) CallFn register is triggered

2) ARM program is run in it's entirety and number of ARM cycles consumed is returned

3) Reading cartridge memory results in a NOP being returned (put on the data bus)

3b) This continues for the length of time the ARM program requires to run (even though it has finished in actuality)

4) When ARM program has concluded, the three bytes of JMP <resume adddress> is put on the data bus

 

As far as I can see, the only value of running the ARM program in parallel with the 6507 program would be the ability to monitor the ARM program step-by-step and possibly to add breakpoints, but I don't believe it's required to get accurate timing information.

 

I would love to put these stars in my game

Link to comment
Share on other sites

1 hour ago, Xan said:

I would love to put these stars in my game

 

That's from Draconian, I discuss how it was done in my blog entry It's full of stars! Back then I was writing it using DPC+*. A few years after that we created CDF and I reboot Draconian using it as covered in the blog entry reboot is underway.

 

CDF has seen some enhancements and is now known as CDFJ. If you're interested in it check out the Harmony/Melody club.

 

* Looks like you're using bB, note that this is not the same as bB DPC+.  @RevEng posted bB starfield effect that you may also find useful.

 

  • Like 2
Link to comment
Share on other sites

New Linux and windows builds with the new method of executing the ARM.

 

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

 

I've added a note about the new execution method in the readme: https://github.com/JetSetIlly/Gopher2600/blob/master/README.md#arm7tdmi-emulation

 

@Andrew Davie causing the emulation to break when the CPU is left too long can probably be done with the current breakpoint system. You can set PC breaks with the disasm window but more complex conditions are currently only available through the terminal. The terminal can be opened through the "Debugger" menu in the menubar.

 

The BREAK, TRAP and WATCH commands can be used to target a number of areas of the emulation. The HELP BREAK command lists them all. In this case a simple "BREAK $0000" is probably sufficient.

 

I plan to add a more friendly way of adding breakpoints in the future but it keeps getting pushed down the list. One thing I had in mind was a "recipe book" for common conditions, partly depending on the cartridge format. So in the case of ROMs that require and use the ARM, a useful recipe might be "Halt when PC wraps around to 0x0000".

 

 

  • Like 3
Link to comment
Share on other sites

  • 1 month later...

I'm not ready to release another binary just yet but I think today's progress is worth sharing. With relatively little tweaking of the TV implementation I've managed to get smooth playfield scrolling working as is being discussed in:

 

If you're in a position to compile Go code then by all means feel free to have a play around with it.

  • Like 4
Link to comment
Share on other sites

3 minutes ago, tabar said:

is there a special way to run Gopher2600 under windows 10. whenever i run it, a window pops up then off.

 

I don't use Windows here but I can say for certain that you need to run it from a dos prompt. I'll be adding a startup window in the future but for now you'll need to do something like:

 

     gopher2600 pitfall.bin

 

or for the debugger

 

    gopher2600 debug pitfall.bin

 

@Al_Nafuur helps me with the Windows builds so maybe he can help if you have any problems.

Link to comment
Share on other sites

39 minutes ago, tabar said:

is there a special way to run Gopher2600 under windows 10. whenever i run it, a window pops up then off.

If you just double click on gopher2600.exe in the explorer window it will terminate because it was started without a ROM file. You have to start it from the command line from the folder you downloaded it or with the full path and give as parameter the ROM file (with the full path) to start.

 

gopher2600.exe path\to ROM file\Pitfall.bin

 

  • Thanks 1
Link to comment
Share on other sites

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

 

I've released this now because I added Superbank earlier in the week after learning Circus Convoy uses it. I thought it would be interesting for someone to try once it's up for sale (undecided if I'm going to buy it).

 

Gamepad support. I'm using SDL so it should work for all platforms but I've only tested on this Linux box with a wired XBox360 controller. I'll be interested in hearing of any problems https://github.com/JetSetIlly/Gopher2600#hand-controllers

 

Supercharger: better support for multiloading. The "tape" will stop automatically and restart and rewind as required. Also 8bit WAV files will now load correctly.

 

Multiload .BIN files will also work as expected. @Mr SQL Your Supercharger BASIC .BIN files should multi-load correctly now.

 

TIA revisions. I've added support for the notable TIA variations, as described in http://www.ataricompendium.com/faq/vcs_tia/vcs_tia.html

 

You can bring up the preferences window in playmode with the F9 key. Here's a video of Cosmic Ark.

 

 

And also debug mode. Here's a demo showing how He-Man is affected by the TIA options.

 

 

 

 

Thanks again to @Al_Nafuur for making sure the Windows binary works.

 

 

  • Like 4
Link to comment
Share on other sites

Had a look-see. I wanted to see if the PlusCart 32-char display (revised) exhibited any issues on these odd-TIA machine variants.

Good news is it appears to be rock-solid in all situations.

Just one oddity - when I ran it and then pressed ESC (as it traps the mouse in a weird way that's hard to get out of), and then moved the mouse, the menu bar started moving as if I was moving the joystick. And didn't stop. Looks like some sort of intentional mouse/joystick thing, but it's odd and I thought I'd report it. Binary I used is attached.

 

GlacierBelle.bin

Link to comment
Share on other sites

6 minutes ago, Andrew Davie said:

Had a look-see. I wanted to see if the PlusCart 32-char display (revised) exhibited any issues on these odd-TIA machine variants.

Good news is it appears to be rock-solid in all situations.

Just one oddity - when I ran it and then pressed ESC (as it traps the mouse in a weird way that's hard to get out of), and then moved the mouse, the menu bar started moving as if I was moving the joystick. And didn't stop. Looks like some sort of intentional mouse/joystick thing, but it's odd and I thought I'd report it. Binary I used is attached.

 

GlacierBelle.bin 32 kB · 2 downloads

 

It flips automatically between joystick and paddle controller depending on what (hardware) controller you're using. So yeah, if you used the analogue joystick (or triggers) or the mouse (when the mouse is captured), it will flip to paddle control resulting in changes to the RIOT register that the ROM isn't expecting.

 

The auto-changing is nice but it needs to be more robust I think.

 

Thanks for the feedback.

 

on edit: the menu bar in GlacierBelle will stop moving if you use the DPad or the cursor keys - the emulation flips back to joystick control and sets the RIOT registers appropriately.

 

Edited by JetSetIlly
  • Thanks 1
Link to comment
Share on other sites

This is a bit of fun I've been working on today.

 

I've been thinking about how to do visual editing of 2600 ROMs and this is what I've come up with so far.

 

The short video shows me live-editing the colors in Pitfall by (a) selecting the area on the screen that I want to change, and (b) picking the new color from the TV color palette.

 

As we know, there's no screen buffer in the Atari2600 so changing the values such that the changes aren't lost on the next frame takes a bit of work. In this implementation it works by a series of searches. Not searches of the binary but of the execution itself.

 

Starting at the current frame, the execution is searched (backwards) looking for the instruction that loads the color value into the color register. From there we look for the instruction that put that value into the CPU register. We continue this reverse search until we find the value in an immediate instruction or otherwise stored in the cartridge data.

 

Obviously, there are limits to this technique but it'll be interesting to see how far it can be pushed. Unwanted side-effects are likely, but even so it should be useful for quickly prototyping graphical changes.

 

I've not pushed the changes to Github because there's still a lot of work to make sure it works in all cases. But it shouldn't be too difficult now that the proof-of-concept is working.

 

Any ideas or thoughts about where this could wrong?

 

 

  • Like 4
Link to comment
Share on other sites

2 minutes ago, Thomas Jentzsch said:

I wonder how you plan to run the execution backwards? E.g. you cannot know the value of RAM or a register before it got loaded with a new one. So what's your trick?

 

The rewind system is very flexible. Not so flexible that I can actually run the execution backwards(!) but flexible and fast enough to perform searches reasonably quickly.

 

In a nutshell, I just spawn a new emulated VCS, load an earlier state from the rewind history (a frame before the current one will probably be good enough in most case) and run it from there. I note all the instances where the GFX register is written to with the value that I want to change. The most recent of those writes is the instruction I will then follow. For example, if the instruction was a STA instruction, I want to find the instruction that loaded the value into the A register.

 

It carries on like that until I reach an instruction that loads an immediate value or another value from the ROM. At that point I can just POKE the new value.

 

 

 

Link to comment
Share on other sites

9 minutes ago, JetSetIlly said:

 

I'm not sure I'm familiar with that. Are you referring to the file archiver?

 

ZackAttack built the ACE format for C++ development.  I understand there is a classic "chicken and egg" problem; it might not be worth all the time and effort.  It would really help me out, though.  Working exclusively on real hardware feels like a time warp.

https://atariage.com/forums/topic/281105-open-source-c-project-template-now-available/

 

PM if you need some test roms.

 

 

Edited by orange808
Link to comment
Share on other sites

3 minutes ago, orange808 said:

ZackAttack built the ACE format for C++ development.  I understand there is a classic "chicken and egg" problem; it might not be worth all the time and effort.  It would really help me out, though.  Working exclusively on real hardware feels like a time warp.

https://atariage.com/forums/topic/281105-open-source-c-project-template-now-available/

 

PM if you need some test roms.

 

 

Interesting. I've not seen that before. I'll take a closer look tomorrow.

 

Thanks for alerting me to it.

Link to comment
Share on other sites

On 3/20/2021 at 11:43 PM, orange808 said:

ZackAttack built the ACE format for C++ development.  I understand there is a classic "chicken and egg" problem; it might not be worth all the time and effort.  It would really help me out, though.  Working exclusively on real hardware feels like a time warp.

https://atariage.com/forums/topic/281105-open-source-c-project-template-now-available/

 

PM if you need some test roms.

 

 

 

I've had a quick look and I'm reasonably confident that it's something I can do but it'll take me some time.

 

From what I can tell, it'll require me to write a full ARM and Thumb-2 decoder. Much of the logic in my Thumb implementation could be reused but even so, it's quite a bit of work to go through the Cortex-M4 documents. I've downloaded them and they're sat on my desktop to remind me ?

 

I'll put it on the todo list but I don't know when I'll be able to get to it. I've got a lot of stuff that needs doing to get me to a version 1.0 release. I can start to think about it properly after that.

  • Thanks 1
Link to comment
Share on other sites

  • 2 weeks later...

With the support of @rbairos I've added Movie Cart support to Gopher2600. Source and binaries can be found on my Github page

 

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

 

I've put a video of the Walter Cronkite demo movie on my YouTube channel. This should be watched in HD in order to get the full 60FPS. Watching in SD will cause the movie to play at 30FPS meaning you won't get the full effect.

 

 

 

In addition to Movie Cart, I've fixed the Superbank bank-switching method. I don't have a copy of Circus Convoy to test that but hopefully someone can try it to see if it works.

 

I've also tweaked how game pads works. Left thumb-stick now controls the joystick and not the paddle. This feels more natural to me and besides, I'm not convinced the narrow range of the stick is good for paddle control.

 

The analogue triggers will still control the paddle but will no longer auto-center. Auto-centering made games like Night Driver too easy.

 

Other control methods (ie. DPad, cursor keys for joystick and mouse for paddle) still work as before.

 

There is also a nice icon set of icons that will be displayed briefly in the corner of the screen to indicate the control method has changed. The screenshot below shows the moment when the paddle has just been activated.

 

image.thumb.png.28f5ba57e9621d78f2fc8c4cbbb78a56.png

 

 

Thanks again to @Al_Nafuur for help with the Windows binary. Much appreciated.

  • Like 3
Link to comment
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...