Jump to content
IGNORED

Gopher2600 (continuing development on Github)


JetSetIlly

Recommended Posts

  • 1 month later...

I've been hard at work getting together the graphical debugger for Gopher2600. As you can see from the latest screenshot below pretty much everything is now accessible through a GUI. The line terminal is still available and can be still be used for more "advanced" operations, such as watches, scripting and more complicated breakpoints (simple PC breakpoints can be added by double clicking in the Disassembly window).

 

Source code and x86 linux binary on Github https://github.com/JetSetIlly/Gopher2600/releases/tag/v0.1

 

keystone_imgui4.png

 

My next step is to use the debugger to help me develop a 2600 ROM/game. That way I can see what other tools will be helpful. I think the framework I've developed is pretty flexible so it should be easy to add specialist features as and when needed.

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

First effort at CRT post-processing:

 

* suggestive bend on the screen

* scanline shadows

* color separation

 

TODO:

* scanlines to follow tube contours

* meaningful color separation

* anti-aliasing

* phosphor fade

 

Still getting to grips with GLSL but it's okay I think.Untitled.thumb.png.d65cacbfc4567fd07c67a4f6b5de9818.png

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

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

 

I'd be very grateful if people could give this a go and I'm open to all criticism and suggestions for improvements. One of my goals for the emulator was to improve my understanding of the 2600 so any commentary is welcome.

 

I've asked the following question in another thread but I'll repeat it here where it is perhaps more relevant.

 

I don't fully understand how some cartridge formats work. For example, the Tigervision cartridge (3F) works by writing the bank number to address 3F which is technically a TIA address. I don't understand how the cartridge can "see" what is happening at this address. So my question is: what is actually happening in the cartridge when 3F is written to? I have a solution in the emulator but it's definitely not technically correct.

 

I'm also not fully aware of how DPC and DPC+ cartridges work. Can anyone point me to documentation for either of these two formats?

Link to comment
Share on other sites

4 minutes ago, splendidnut said:

The Atari 2600 Cartridge slot has access to ALL the address lines of the CPU.   So it can see what is written to any address in the 6507 address space.

 

As can be seen in the schematic:

 

https://atariage.com/2600/archives/schematics/Schematic_2600_Low.html

Ah. Okay. It does make sense then! I don't think I'd seen that schematic before. Thanks.

Link to comment
Share on other sites

For DPC and DPC+, a good resource is the Stella source code.

 

DPC was (to my knowledge) only used for Pitfall II.  The patents are probably the only "official" documentation of that scheme; though, I believe there is a mapper doucment out there somewhere that goes over the registers used.

 

Asking @SpiceWare is probably your best resource for DPC+ information.  Note: almost all of the DPC+ games require some kind of ARM CPU emulation also.

  • Like 1
Link to comment
Share on other sites

Here's the DPC patent. Note that table 1 shows all the registers at addresses $000-$07F, but they're located within the cartridge so are actually at $1000-$107F and the mirrors at $3000-$307F, $5000-$507F, ..., $F000-$F07F.

 

DPC contains a number of features that were not used in Pitfall 2 - ways to read data fetchers with nybbles swapped, bytes reversed, rotated, etc. Since nothing used them they haven't been emulated.

 

Some AA topics that could help:

  • Like 2
Link to comment
Share on other sites

DPC+ started as an expansion of DPC - namely a larger ROM size, improved music, and replacing the unused DPC features with others. The ability to call custom ARM code was added late in the design, its use is not required though most DPC+ games do utilize it.

 

I'd recommend to start with the DPC+ Demo I posted, it does not require custom ARM code support. Be sure to check out the comments in the DPCplus.h file, such as this:

 

;----------------------------------------
; Random Numbers
;----------------------------------------
; DPC+ provides a 32 bit LFSR (Linear feedback shift register)
; which is used as a random number generator.  Each individual byte of the
; random number will return values from 0-255.  The random numbers will follow
; an exact sequence, so it's best to clock them at least once per frame even if 
; you don't need the value (this allows the amount of time it takes the user to
; start the game to select a random starting point in the sequence)
;----------------------------------------
RANDOM0NEXT   DS 1    ; $00 clock next 32 bit number and returns byte 0
RANDOM0PRIOR  DS 1    ; $01 clock prior 32 bit number and returns byte 0
RANDOM1       DS 1    ; $02 returns byte 1 of random number w/out clock
RANDOM2       DS 1    ; $03 returns byte 2 of random number w/out clock
RANDOM3       DS 1    ; $04 returns byte 3 of random number w/out clock

 

You will need to refer to Stella source files CartDPCplus.cxx and CartDPCplus.hxx for some of the details, such as:

void CartridgeDPCPlus::setInitialState()
{
  ...
  // Initialize the DPC's random number generator register (must be non-zero)
  myRandomNumber = 0x2B435044; // "DPC+"
  ...
}

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
inline void CartridgeDPCPlus::clockRandomNumberGenerator()
{
  // Update random number generator (32-bit LFSR)
  myRandomNumber = ((myRandomNumber & (1<<10)) ? 0x10adab1e: 0x00) ^
                   ((myRandomNumber >> 11) | (myRandomNumber << 21));
}

// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
inline void CartridgeDPCPlus::priorClockRandomNumberGenerator()
{
  // Update random number generator (32-bit LFSR, reversed)
  myRandomNumber = ((myRandomNumber & (1U<<31)) ?
    ((0x10adab1e^myRandomNumber) << 11) | ((0x10adab1e^myRandomNumber) >> 21) :
    (myRandomNumber << 11) | (myRandomNumber >> 21));
}

 

The 0x10adab1e = LOADABLE, and is the signature in the ROM that the Harmony uses to detect a custom cartridge bankswitch driver like DPC+ and CDFJ.

 

797051314_ScreenShot2020-04-22at10_05_17AM.thumb.png.9a3d3798b88e4ba066e6bb7d233ea448.png
 

I think there's a finished game or two that used DPC+ without custom ARM code, but don't recall which off the top of my head. @iesposta might know.

  • Like 2
Link to comment
Share on other sites

1 hour ago, SpiceWare said:

Here's the DPC patent. Note that table 1 shows all the registers at addresses $000-$07F, but they're located within the cartridge so are actually at $1000-$107F and the mirrors at $3000-$307F, $5000-$507F, ..., $F000-$F07F.

 

DPC contains a number of features that were not used in Pitfall 2 - ways to read data fetchers with nybbles swapped, byte reversed, rotated, etc. Since nothing used them they haven't been emulated.

 

Some AA topics that could help:

Brilliant. Thank-you very much for pulling all this together.

  • Like 1
Link to comment
Share on other sites

On 4/22/2020 at 3:40 PM, SpiceWare said:

Here's the DPC patent. Note that table 1 shows all the registers at addresses $000-$07F, but they're located within the cartridge so are actually at $1000-$107F and the mirrors at $3000-$307F, $5000-$507F, ..., $F000-$F07F.

 

DPC contains a number of features that were not used in Pitfall 2 - ways to read data fetchers with nybbles swapped, bytes reversed, rotated, etc. Since nothing used them they haven't been emulated.

 

Some AA topics that could help:

 

I've implemented the DPC patent. It works well with the test ROMs and Pitfall 2 but I have a question about the free-running clock in the cartridge.

 

The patent says that the clock runs at 42Khz (in the preferred embodiment). I implemented this by sending a signal to the cartridge every CPU cycle and discounting the extra cycles and updating the data-fetcher every 28 cycles (1.19Mhz/42Hkz == 28)

 

However, using this value means that the tuning isn't right. Tuning by ear the number a value of 59 produces better results. By my reckoning, this means the clock is only running at 20Khz (1.19MHz/59 == 20Khz)

 

Now, as you've already said, Pitfall 2 differs slightly to what's in the patent. Is the clock different too? Or have I made a mistake somewhere else?

 

https://github.com/JetSetIlly/Gopher2600/blob/master/hardware/memory/cartridge/cartridge_dpc.go

Link to comment
Share on other sites

There's a bit of variance with the clock used in Pitfall 2, so different cartridges will sound different. As of 6.1 Stella has an option for you to set the DPC clock, from the change log:

Quote

March 22, 2020

Stella release 6.1 for Linux, macOS and Windows is now available.

...

  • Added option to change pitch of Pitfall II music.

 

This was implemented in issue 502, which includes a reference to this mappers doc:

Quote

There's been some discussion about the pitch of the music generated by this chip,
and how different carts will play the music at different pitches.  Turns out, on the
cart, the frequency is determined by a resistor (560K ohms) and a capacitor integrated
onto the die of the DPC chip itself.  The resistor is a 5% tolerance part, and the
process variations of the DPC itself will control the frequency of the music produced
by it.

 

If you touch the resistor on the cartridge board, the music pitch will drastically 
change, almost like you were playing it on a theremin!  Lowering the resistance makes
the music pitch increase, increasing the resistance makes the pitch lower.

It's extremely high impedance so body effects of you touching the pin makes it 
vary wildly.

 

Thus, I say there's really no "one true" pitch for the music.  The patent, however,
says that the frequency of this oscillator is 42KHz in the "preferred embodiment".
The patent says that it can range from 15KHz to 80KHz depending on the application
and the particular design of the sound generator.  I chose 21KHz (half their preferred
value) and it sounds fairly close to my actual cartridge.  

 

The Stella implementation is defaulting to 20,000 which matches what you've come up with.

 

1240732091_ScreenShot2020-04-26at4_07_20PM.thumb.png.006935292f25212eb2a8e54fc72e8895.png

 

 

  • Like 1
Link to comment
Share on other sites

52 minutes ago, SpiceWare said:

There's a bit of variance with the clock used in Pitfall 2, so different cartridges will sound different. As of 6.1 Stella has an option for you to set the DPC clock, from the change log:

 

This was implemented in issue 502, which includes a reference to this mappers doc:

 

The Stella implementation is defaulting to 20,000 which matches what you've come up with.

 

1240732091_ScreenShot2020-04-26at4_07_20PM.thumb.png.006935292f25212eb2a8e54fc72e8895.png

 

 

Thanks again for your help. I wonder why Pitfall 2 differs from the information in the patent?

Link to comment
Share on other sites

  • 1 month later...

I've added DPC+ support to Gopher2600. Doesn't support ARM yet but that'll be the next job. And then onto CFDJ.

 

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

 

I've made other changes too. Internal and visual. There is now a cartridge specific window menu if appropriate. For example, when a DPC+ cartridge, a registers window and a data window is available. Screenshot below:

 

1165000621_Screenshotfrom2020-06-1120-19-31.thumb.png.4f50a7f5b8e5add415b83ee85cfc0786.png

 

The TV screen window in the debugger is generally better. It's more easily resizable and the reflection system has been improved allowing for overlays and floating tooltips. These are best demonstrated by video. I've been uploading small videos to my Twitter, rather than upload them here, I'll link to them.

 

 

 

 

 

 

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

I played a bit with it (despite the fact that my old PC can't run it at full speed) and it keeps getting better.


The overlays are very effective, and it's interesting watching the game running with those enabled.


The mouse tooltips showing the line of code corresponding to the screen area you're pointing to (with correct variable names if you have a dasm sym file alongside the rom) are a nice touch.

 

I like the UI with separate windows that can be independently moved and resized, and how each window is layed out (e.g. in the TIA window, I find useful the little dot that indicates the pixel of the gfx register corresponding to the current cycle).

 

Keep up the great work!

 

 

 

  • Like 1
Link to comment
Share on other sites

17 minutes ago, alex_79 said:

I played a bit with it (despite the fact that my old PC can't run it at full speed) and it keeps getting better.


The overlays are very effective, and it's interesting watching the game running with those enabled.


The mouse tooltips showing the line of code corresponding to the screen area you're pointing to (with correct variable names if you have a dasm sym file alongside the rom) are a nice touch.

 

I like the UI with separate windows that can be independently moved and resized, and how each window is layed out (e.g. in the TIA window, I find useful the little dot that indicates the pixel of the gfx register corresponding to the current cycle).

 

Keep up the great work!

 

 

 

Thanks for the feedback!

 

Yes. The speed issue is a shame. It's a combination of language choice and my emulation method. It might get faster in the future. It wasn't my intention to create a complete emulator when I started.

 

The overlays idea is something I hope to expand. I think I'll know overlays are done when the user can mix and match what appears in the overlay.

 

The windowing system is provided by Dear IMGUI. That's a very modern UI system without which I probably wouldn't have bothered with a GUI at all. I like the TIA window too. For it to get better I think it needs to be able to show the different TIA parts side by side, as required.

 

There's more work to be done on how audio is debugged. Disassembly isn't perfect yet so that needs improving. It also needs a way of showing differences in RAM from cycle-to-cycle/frame-to-frame etc. TIA/RIOT emulation is done but TV decoding is not perfect yet. In particular, deciding the bounds of the screen. It's not as simple as just looking for VBLANKS.

 

Has anyone noticed the video-cycle level stepping? This was invaluable to me when developing the emulator particularly when getting into the nitty-gritty of NUSIZ and HMOVE but I'm curious as to whether anyone thinks it will be useful during game development. I've not really had a chance to try it out yet.

 

There's a toggle in the Control window which when in the right position, puts the emulator into video-cycle mode.

 

image.png.a722667215072b078c2953d07b79434c.png

 

 

  • Like 1
Link to comment
Share on other sites

4 hours ago, Andrew Davie said:

Up and running with a build on my MacBook. Looking great; amazing job.

I am hoping you will consider supporting 3E+ bankswitching method soon, as that is my immediate need for use/testing.

 

 

Thanks for looking. Pleased to see it's running on your machine.

 

I must confess, I've not heard of 3E+ bank switching. I'm going to use the post below (from you) below as my guide.

 

https://atariage.com/forums/topic/307914-3e-and-macros-are-your-friend/?tab=comments#comment-4561287

 

  • Like 1
Link to comment
Share on other sites

1 hour ago, JetSetIlly said:

 

Thanks for looking. Pleased to see it's running on your machine.

 

I must confess, I've not heard of 3E+ bank switching. I'm going to use the post below (from you) below as my guide.

 

https://atariage.com/forums/topic/307914-3e-and-macros-are-your-friend/?tab=comments#comment-4561287

 


 

You can find a sample rom in my Chess thread, or I can PM you.

Edit: I had posted a snippet from the 3E+ comment (definition) in the stella code, but have removed this because I thought it may cause issues related to use/licensing.  In any case, my independent post/thread you reference is correct and complete, I think.

 

Edited by Andrew Davie
Link to comment
Share on other sites

2 hours ago, Andrew Davie said:


 

You can find a sample rom in my Chess thread, or I can PM you.

Edit: I had posted a snippet from the 3E+ comment (definition) in the stella code, but have removed this because I thought it may cause issues related to use/licensing.  In any case, my independent post/thread you reference is correct and complete, I think.

 

Code pushed to Github. I've not prepared a new release so you should pull it from master https://github.com/JetSetIlly/Gopher2600

 

1341801942_Screenshotfrom2020-06-1310-59-07.thumb.png.7634be44bb0b84faa8b4ab41ffc8c69d.png

 

edit: I've noticed that the pixel renderer causes the horizontal lines to be drawn with different thicknesses. Obviously a problem with the scaling algorithm. I'll look at that later this weekend.

Edited by JetSetIlly
Link to comment
Share on other sites

8 minutes ago, JetSetIlly said:

Code pushed to Github. I've not prepared a new release so you should pull it from master https://github.com/JetSetIlly/Gopher2600

 

1341801942_Screenshotfrom2020-06-1310-59-07.thumb.png.7634be44bb0b84faa8b4ab41ffc8c69d.png

Odd.

First I did "git pull" and build. No luck.

Then a clean clone from github still gives me cartridge error.

 

Edited by Andrew Davie
Link to comment
Share on other sites

13 minutes ago, Andrew Davie said:

Odd.

First I did "git pull" and build. No luck.

Then a clean clone from github still gives me cartridge error.

 

 

Try again.

 

I must have been using an older bin file from your Chess thread. I was partially basing the 3e+ fingerprint on the file having a particular size. I've fixed it so it should work with any cartridge size.

Edited by JetSetIlly
Link to comment
Share on other sites

6 minutes ago, JetSetIlly said:

 

Try again.

 

I must have been using an older bin file from your Chess thread. I was partially basing the 3e+ fingerprint on the file having a particular size. I've fixed it so it should work with any cartridge size.

 

Thanks for taking the time to do this. Working now.

Just a few issues...

 

1) The colours are wrong. The squares should be blue. Perhaps an NTSC/PAL detection issue?  This is a 276 scanline NTSC ROM. Have attached the latest ROM because I was playing with colours in earlier releases and I want to give you a guaranteed correct colour one to test.

2) Bit of a screen jump at the start - I don't think the code actually does this.

3) Technically 3E+ allows really odd ROM sizes. Don't rely on things being anything but... odd. Stella pads ROMs to 1K boundaries after loading.

 

Thanks again!

chess.bin

Edited by Andrew Davie
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...