JetSetIlly Posted February 10, 2020 Author Share Posted February 10, 2020 39 minutes ago, JeffJetton said: Using "Go" to write an "Atari" emulator? How appropriate! ? I took me a couple of seconds to get it but I suppose you're right, it is appropriate ? Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted March 21, 2020 Author Share Posted March 21, 2020 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 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. 2 Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted April 8, 2020 Author Share Posted April 8, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted April 22, 2020 Author Share Posted April 22, 2020 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? Quote Link to comment Share on other sites More sharing options...
+splendidnut Posted April 22, 2020 Share Posted April 22, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted April 22, 2020 Author Share Posted April 22, 2020 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. Quote Link to comment Share on other sites More sharing options...
+splendidnut Posted April 22, 2020 Share Posted April 22, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted April 22, 2020 Share Posted April 22, 2020 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: How exactly does the Pitfall 2 DPC work? - specifically replies by @batari DPC Music demo by @cd-w DPC Sprite Demo by me 2 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted April 22, 2020 Share Posted April 22, 2020 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. 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. 2 Quote Link to comment Share on other sites More sharing options...
+splendidnut Posted April 22, 2020 Share Posted April 22, 2020 Of note, ChaoticGrill currently uses DPC+ without any custom ARM code... but it does not use all of the features available (mainly, the music/sound features). 2 Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted April 22, 2020 Author Share Posted April 22, 2020 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: How exactly does the Pitfall 2 DPC work? - specifically replies by @batari DPC Music demo by @cd-w DPC Sprite Demo by me Brilliant. Thank-you very much for pulling all this together. 1 Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted April 26, 2020 Author Share Posted April 26, 2020 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: How exactly does the Pitfall 2 DPC work? - specifically replies by @batari DPC Music demo by @cd-w DPC Sprite Demo by me 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 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted April 26, 2020 Share Posted April 26, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted April 26, 2020 Author Share Posted April 26, 2020 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. Thanks again for your help. I wonder why Pitfall 2 differs from the information in the patent? Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted June 11, 2020 Author Share Posted June 11, 2020 (edited) 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: 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 June 11, 2020 by JetSetIlly 3 Quote Link to comment Share on other sites More sharing options...
alex_79 Posted June 12, 2020 Share Posted June 12, 2020 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! 1 Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted June 12, 2020 Author Share Posted June 12, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted June 13, 2020 Share Posted June 13, 2020 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. 2 Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted June 13, 2020 Author Share Posted June 13, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted June 13, 2020 Share Posted June 13, 2020 (edited) 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 June 13, 2020 by Andrew Davie Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted June 13, 2020 Author Share Posted June 13, 2020 (edited) 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 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 June 13, 2020 by JetSetIlly Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted June 13, 2020 Share Posted June 13, 2020 (edited) 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 Odd. First I did "git pull" and build. No luck. Then a clean clone from github still gives me cartridge error. Edited June 13, 2020 by Andrew Davie Quote Link to comment Share on other sites More sharing options...
JetSetIlly Posted June 13, 2020 Author Share Posted June 13, 2020 (edited) 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 June 13, 2020 by JetSetIlly Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted June 13, 2020 Share Posted June 13, 2020 (edited) 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 June 13, 2020 by Andrew Davie Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted June 13, 2020 Share Posted June 13, 2020 Note the addition of a test rom in previous post. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.