Jump to content

gstanton

Members
  • Posts

    12
  • Joined

  • Last visited

Everything posted by gstanton

  1. I've been slowly working on a newer version of the ProSystem emulator so I thought I would start a new thread detailing the progress and to get feedback. Just from looking around the forums I've noted that the timing in the emulator (Maria) does not match the documents and causes a lot of graphic glitches. This is one things that I'm addressing in the newer version. Here is a list of the known things that should be fixed that I know of: 1. Maria cycle timing / DMA cycle stealing 2. 2 Button Joystick support 3. Riot Timer 4. Accurate INPTCTRL port emulation (MEN, Bios/Cartridge switch, lock, etc) 5. Rendering pixels during and after DMA stops 6. Lightgun support 7. Slowdown for TIA/RIOT memory accesses 8. RIOT I/O port read/write masking I plan to take into account changes that have been added since 1.0 (ie 1.1, 1.2, and 1.3) and put them into version 2. Version 2 is being written from scratch. I've finished the 6502 emulation already. The CPU is emulated at the cycle level (not instruction level) and should perform the correct read/write access to memory per cycle. This will help to emulate the TIA/RIOT slowdown emulation. I've also re-done how the memory is mapped. It will emulate the MEN (Maria ENable) memory mapping better and allow for 7800 or 2600 modes. I'm now working on the MARIA emulation. I've created a GUI debugger in order to track down some of these problems and hope to release that as well. My goal is to make this emulator as accurate as possible. My second goal is to provide a tool so that we can create some more games for the system (Moon Patrol anyone?). I would like this thread to start fleshing out some of the details of what is wrong with the current emulation and to collect in one place. Feedback is appreciated.
  2. At the time that I wrote the ProSystem emulator there were only a few documents available. I had to make assumptions on timing based on current emulators (MESS and V7800) and the few documents that were available. I've been currently working on a version 2 of the emulator that includes the more exact timing for the Maria processor and takes into account the slow down when accessing TIA and RIOT addresses. The ignore WSYNC was a hack to get Kung-Fu Master working with the current timing numbers.
  3. Great job Leonis! I updated the ProSystem web page to include your new bits. I'm currently working on version 2, but it is going slowly. The plan is to incorporate all the updates made to version 1.0 and add more functionality including Linux/Mac support to the newer version. Enhancement requests are welcome.
  4. Hi Trebor, All the officially released games should work with version 1.0. Some of the rom images are not internally organized correctly (?) and some of the rom headers are incorrect. What I did notice when working with the emulator were many of the graphic glitches. I would love to clean those up as well. For that, I would need a create a good debugger. I appreciate the suggestions.
  5. Hmm... I just checked the forums and had no idea until now that there's been 3rd party development going on with this. I'll have to try out a newer version. Yeah, ProSystem never emulated the buttons correctly. I remember that was something I always wanted to fix. There has been some further work with the original emulator source. Most of it was done by Brian Berlin who added some bug fixes and added the joystick support. My ideas for a newer version included multi-platform (Linux) and a debugger (among other things).
  6. Does anybody still use the ProSystem Emulator? I released the emulator 3 years ago and meant to update several times but I got to busy with life. I've been toying around with releasing a new version (version 2.0) that worked with SDL and/or Java (using JNI and C++ core). I would like to add some new features but wanted to know if people are interested, how much they use the emulator (if at all), and what features and/or bug fixes they would like to see? I've been out of the emulator scene for a while and it seems to have died down. Cheers, Greg Stanton
  7. If there is enough interest in the emulator, I was going to go from using DirectX to using SDL. If and when I release the source code, someone could port it over to other platforms.
  8. I haven't released the source code yet. I'm haven't had the time to get it prepared. Someday soon... I'm still deciding if I want to go with the GPL license and release the source or not. Since I'm still testing the software, I'm going to hold off for a while.
  9. Strange, I was able to play it fine on my machine???? Can you check the ProSystem.log file to see if there are any errors? Has anybody else gotten Beef Drop to work?
  10. The emulation is not cycle exact (as in DMA cycle stealing) for every ROM. Only some of the rom images have the cycle stealing enabled. The flags entry in the ProSystem.dat file indicate if DMA cycle stealing is enabled or not (flags=1). I implemented the cycle stealing as accurately as I could, but some of the games do not work well with it turned on. There is not a built in monitor or debugger. I built one for myself while testing the emulator, but it was very slow. Maybe someday....
  11. Hi all, I've just finished initial development of a new atari 7800 emulator which I call the ProSystem Emulator. The emulator runs on the windows platform. Most of the code was written from scratch by me (using C/C++) including the emulation of the 6502 (Sally), Maria, Riot, etc. If you would like to help me test the emulator or are just curious, please go to: https://home.comcast.net/~gscottstanton/ The emulator was unit tested by me on Windows 2000 and 98 SE. I have not optmized the code yet, so performance is still a bit slow. A 1GHz procossor is needed to run with sound and without skipping frames. Send me an email if you find any problems or have any questions. Thanks, Greg Stanton gscottstanton@comcast.net
  12. I've been programming/playing around with the 7800 and I wanted to know more about the CTRL register, specifically what the Color Kill (CK) bit does? According to the documentation it shuts off color burst to prevent arifacting? What does that mean exactly? Does the screen turn to black and white, or does this just happen for the current scanline? I know some of the commercial games (Desert Falcon, etc) turn the CK on and off during gameplay along with the border control bit.
×
×
  • Create New...