Jump to content

RevEng

Members
  • Content Count

    7,029
  • Joined

  • Last visited

  • Days Won

    11

Everything posted by RevEng

  1. Yes, that's the question, and there isn't a simple answer here. The 7800 has some signal quirks. e.g. A14+A15 being pulled up, A12+A14+A15 being run through AND gates before hitting the cart port. (introducing differences in timing between these lines and the others) Bus access happens at 1.19Mhz, 1.79Mhz, and 7.16Mhz, depending on what device is involved. Probably more that I'm not considering. Timing with these quirks, even with eprom based carts, has always been a bit hit and miss. I only wanted to add some clarity to the fact this likely isn't a software issue, since Versa is immune. I don't own a DF cart, and nor do I have the tools to do a signal timing analysis.
  2. Just to underline a point here... While getting rid of "BEQ $00" may have provided relief for Popeye from the 7800basic break protection, it's just masking the real problem. The argument byte of an opcode shouldn't be executed as it's own instruction ever, unless the program flow has gone completely off the rails. The fact that 7800basic calls a dead-stop when BRK is executed is meant to alert the programmer to the fact that something very dangerous has happened, and changing the code to remove the "0" opcode argument isn't really a fix, any more than disabling break protection would be. This sort of problem with flow control could either be a bad jump, bankswitch, or whatnot, or it could be a hardware issue. The fact that the problem with Popeye didn't manifest when Versa was used, demonstrates it's a hardware issue in that case. Perhaps it's the same here too, since many people can't reproduce it.
  3. Alternate history. 1977: An enhanced version of the VCS is released. 1979: a jealous George Plimpton convinces the Kremlin it should send a bomb to take out the Sunnyvale HQ. Ferris Bueller tries to stop the Kremlin computer from sending the bomb by playing 3D Tic-Tac-Toe with it, but he loses, and the bomb launches anyway. Luckily Nolan and the employees are all out back in the hot tub when the bomb hits, and are unscathed, except for some soot-covered faces and smouldering hair. With the building destroyed, George Plimpton convinces the bank manager to foreclose on Atari's mortgage, but at the last minute Nolan manages to sell the rights to the name "Atari" to some french company. Cut to Nolan, the employees, and Ferris Bueller all triumphantly dancing outside the rubble, and George Plimpton sulking away. If anybody reading is wanting to option the rights, I currently have several bidders, so come in with your best and final.
  4. + YM2151 + High Score Cart + Covox + xegs keyboard Plus the ability to play the Rescue on Fractalus demo without every other line messed up.
  5. Sure. But using the same display (hdmi TV) and the same controller that I was using on retroarch for RPi and Android, to me the latency difference is night and day. On those systems I wasn't able to play Caverns of Mars (A8) with any level of skill approaching what I used to have. I had written it off as just getting old, until I fired it up in MiSTer and played like my old self. Then the same experience repeated itself over and over with a number of games. But honestly, if you're happy with software emulation, for sure stick with it - to each his own, and I'm the last person to be slagging software based emulation.
  6. From the perspective of latency, it's night and day.
  7. As far as "ok", the de10 nano is warrantied up to 100 degrees celsius, and shouldn't exceed that during normal operation, so you're unlikely to break things any time soon running this way. However silicon longevity is always inversely related to the temp you're running at over the lifetime of the device, and I don't think we have the data for a specific answer here. i.e. I don't think we know the mean time before failure rate with any mode of cooling, let alone MTBF rates for different cooling scenarios. There are certain cores that are known to be less stable on some systems, and active cooling seems to improve the situation. This mainly seems to be the SNES and ao486 cores, from what I read. Being much simpler, the 7800 core shouldn't have the same problems. I could be entirely wrong here, but I also get a feeling these cores with thermal instability issues may be due to race conditions being won differently, after a temperature differential shows up between different parts of the fpga. I wouldn't expect problems with the 7800 core on this count either.
  8. I think the question can be equally framed as "why didn't the CC2 respond to $800-$FFF after warm-up?" on your first unit. Best guess is it's along the lines of @tep392's versa problem, with timing of some signal on the device being near some edge case. The warm-up seems to push the unit into not-working side of the edge case.
  9. You're welcome. I found an old doc (attached) that clears up the mystery a bit too. We likely gave it some impossible settings, which messed up the menu. Odd the messed-up menu didn't persist, as this is battery backed ram, but maybe it detects bad settings and re-inits for the next run. Or maybe Bob's battery isn't doing the job. CC2-techdocs.txt
  10. It's only tested in emulation so far, but give this a shot and let me know. Robotron 2084 (PAL HACK).a78 It's a (fairly involved) hex-edit hack that fixes the display to run on PAL, so no speed tweaks. (I don't know if speed tweaks are even possible.) Technical details ahead... The display and NMI for this game is a bit unconventional. There are mulitple NMI, and the NMI that's supposed to run at the bottom of the screen looks to see if a vblank transition happens soon, to ensure it actually is running at the bottom of the screen. If that transition doesn't come, it assumes the NMI order is off, and shifts the order. But if the vblank transition is never seen in any of the NMI positions, the shifting never ends. Due to this NMI scheme, this PAL hack hangs on NTSC consoles, for the same reason the NTSC retail release hangs on PAL. (no vblank transition near the NMIs)
  11. Pretty sure that from the cart's perspective, A12 being forced low (via U4) made access to $1800-$1FFF look like access to $800-$FFF. The CC2 likely has an undocumented mapping or hotspot in that range. Avoiding $1800-$1FFF seems to have done the trick.
  12. Hopefully this necropost can be forgiven, for providing new information. It was recently pointed out to me by @Kitrinx that the 7800 has phi0 being generated by Maria instead of TIA *and* this would impact correct RSYNC behaviour. So I gave this ROM a try via Harmony Concerto. I have the same result as you, which matches the rsync-not-properly-emulated result described earlier in the thread. (the alien is displayed quite a bit to the right of the dots eaten, walls are similarly offset from the actual player display) So I believe this result is a general 7800 thing. Homebrewers experimenting with or otherwise relying on RSYNC should be aware of this potential issue on 7800s.
  13. Heads up that some time ago I started a disassembly of Ken's 7800 Blocdrop game, with the intention of some day finishing it for him. While I made a good start of it (there's a fair bit of semantic info added, and it builds identically to Ken's last demo) there always seems to be more pressing hobby-business, so it hasn't moved much lately. I decided to throw this open to anybody that's interested. If you can move the disassembly forward, feel free to do so, and add your name to the contributors at the top. Contributions can be made via pull-request, or if you don't do git, just pass on your changed file. https://github.com/msaarna/7800blocdrop I can't promise any recompense for any work. If carts are some day produced, it's my intention to have dev proceeds go to an appropriate charity. If there are a lot of hands in this, it won't be possible to get carts to the contributors either. But adding your effort to the project would be a nice way of honouring someone who once added light to our hobby.
  14. It would be informative to know if it was gamepad directions (handled by RIOT) or gamepad buttons (handled by TIA) that trigger the issue. A lot of people have been using genesis controllers on the 2600, so I don't think it's a matter of of genesis controllers being problematic in general. The only joystick pins that could cause problems by being directly connected would be pin 7 (+v) and pin 8 (gnd) - the rest could be joined together in all kinds of combinations without any sort of issue like you're describing. Pin 7 on a genesis port is the "select" line, which controls which set of buttons the controller is reporting - this is an input to the controller, so I wouldn't expect the controller to ever be connecting it to ground. So I don't believe there's anything damaging for the 2600 going on. My best guess is that the multiplexer chip in this controller draws a bit too much current from your 2600. When you cut off the connection to pin 7, you've leaving the multiplexer chip unpowered. (a genesis controller plugged into a 2600 also gets it's power from the select line, but this is a back-fed power source, not the intended one.)
  15. RevEng

    Rikki & Vikki

    Presently only Bupsystem emulator works with it (which is the emulator bundled with the Steam release) but you need to actually choose the FoxBox.cdf file. It's sort of like a bin/cue deal, where cdf is a text file that specifies the FoxBox.bin file and also tells the emulator some extra info, like what order the music tracks are in. If you're trying to play R&V with the beta MiSTer FPGA 7800 core, you can skip the cdf, but you need to add an a78 header to FoxBox.bin, specifying the Souper format. This can be done with the latest version of 7800header, which is in the 7800AsmDevKit.
  16. It sounds like you don't need to, but you can also dim extra score variables, in addition to the two scores provided.
  17. BCD numbers are basically hex numbers. i.e. When you convert the decimal value "13" to BCD, it becomes $13. Since a byte's max value is $FF in hex, those 2 hex digits only allow for representing a BCD value up to "99". Yes, there could be a routine developed to return 2 bytes, but I try not to add a lot of functions that will go unused by a large number of games. How's your number generated in the first place, and what's it's max value? If it's updated with addition and subtraction, you could also use an extra score variable to track it in BCD. Or if we're just talking about a value with a max of 255, you could just do some iterative subtraction to pull out the 100's place.
  18. Yep, it's implements DMA limits, and it's pretty faithful compared to real hardware.
  19. Arbitrary user-interrupts (other than the current near-top, near-bottom, and offscreen ones) aren't planned in the near future. An NMI color change interrupt needs minimal overhead to be reliable - otherwise, adding more dma increases the chance of the color change not taking effect until the next scanline, to the point where the heaviest DMA limits can cause a miss in the most minimal color change code. I may change this in the future if I take on an NMI handling rewrite, but honestly I have a few different pieces I'd like in place before I consider that, to avoid painting myself into a corner.
  20. I must admit that you'd love one, too.
  21. The Haunted House issue isn't really a 7800 compatibility issue. HH has a code bug that accidentally loads a value from TIA instead of using a constant value. This is literally a goof-up on the programmer's part. On most consoles the game works despite the code bug, because those consoles have enough bus capacitance to give previously read values some hang-time, if the bits in question remain undriven. However this isn't expected or guaranteed behaviour. Some seemingly rare consoles don't have sufficient hang time to overcome this sort of code bug, including 2600s. I haven't seen any evidence that the 7800 is more or less prone to the issue than the 2600 is, though admittedly the rarity of these consoles makes the comparison a bit tricky.
  22. RevEng

    Get Lost!

    Yep, that's a clean result. If you have problems with ROM on the device, some of those blocks might turn red. It may be worthwhile to leave it running for a bit. The missing blocks are normal, and just ones I can't check for technical reasons.
  23. Yep, it's really very impressive! And doubly so, considering it's spendidnut's first dance with Maria.
  24. [edit - beat by Karl, but something odd seems to have happened to his post.] The font graphic data is in ROM, imported into the correct place and format via the incgraphic command. In the example I used, the character strings are in ROM. The RAM version of my example is nearly the same, except you dim a buffer "dim charbuffer=$2200" and use "memcpy screen1map charbuffer 288" (or whatever the size is) to populate it, and then plotmap the "charbuffer" ram buffer instead of the "screen1map" rom.
×
×
  • Create New...