Jump to content

RevEng

Members
  • Content Count

    7,027
  • Joined

  • Last visited

  • Days Won

    11

Everything posted by RevEng

  1. Pretty sure it's just a high level simulation of the Williams sound code. Defender, Robotron, and Joust all use the same sound hardware, which is pretty much just a 6800 CPU connected to an 8-bit DAC. (more details here) Their sound algorithm (which is in the repo ZylonBane linked) is called with certain parameters to create all of the sounds. If you take a look at that interactive sound simulation I linked earlier, you can import/export, which I believe just lists the same parameters. It would be a bigger lift, but technically the same algorithm could be made to run directly on hokey. Not sure how accurate it is, but there's a higher level reimplementation of the sound code here. (he's called it out as Robotron, but I'm pretty sure it's the same algorithm in Defender, just the sounds are using different parameters.)
  2. I'm sorry to hear of this, Rafal. Unfortunately it's too common a story. Take care of yourself first, think about hobby stuff second. Wishing you a better turn of luck in this new year.
  3. Yep, it's arcade perfect.
  4. Speaking of Defender sound, I'll just leave this here... http://www.dl.unospace.net/defender_sound/
  5. I love the fade-in/out cursive credit at the start. Very tasteful. 🧐 And those random scrolled backgrounds look great!
  6. Yeah, probably. It looks like I goofed in that doc anyway - in the docs it should have listed $10 for that middle value, not $20. Serves me right for putting together a release in the wee hours. I've updated the github releases with an updated doc, that has the correction and an example.
  7. For sure, or perhaps off-screen enemies can have less-frequent more-coarse updates. But I think here we're seeing PMP just striving to make it arcade accurate, rather than hitting an actual implementation issue.
  8. Yeah agreed. Actually, it's already come in handy. Necessity is the mother of invention. There's two cases for this that I see. The regular one, where you have part of the sound naturally changing more quickly in some parts than others. An alternative case, is where use it for a long delay before the sound. (or in the middle)
  9. Ok, I dropped a new 7800basic release at github. Changes include... includes support for png files with more than expected colors. (thanks beoran!) bug fix for "loadrombank" bug fix for playsfx. (this one is pretty hard to trigger, which is why it's gone unnoticed) data for sound effects can now change their frame-rate mid-sound. updates to the 160b index-import order. (if you have a legacy project that uses 160B, you may wish to hang on to the old 7800basic, in case the new one forces you to reorder the 160B indexes)
  10. Honestly, it stopped my heart the last time the thread was bumped. Maybe we can rename it to something more expected, like "CPUWIZ in jail"
  11. Drop the diode, as it's not required. The schematic by Danjovic should work - I have a genesis pad modded to the same circuit, and it works great.
  12. As far as the default single-stick (proline) controls go, I believe we're nailed the scheme down really well. It will actually be my preferred way of playing the game, though we intend to offer the previously discussed alternatives. (another stick in port 2, a keyboard control in port 2, possibly others) I'm avoiding spoilers at this time, because we still need to finish off some of the conversion, and then give David a chance to review before we reveal any updates. (likely his channel will be where you see it first) But people don't need to worry about extra controllers or frequent lunging for the console buttons; none of that will be required for a good experience with the game.
  13. For 2600 homebrews, a completely packed display kernel is typical. If the game has a natural break in the display 3/5ths of the way down the screen where the game already changes kernel loops it may be fine, but again here we're looking at something non-typical. So it's doable, but the game has to give up something (display less objects, be less colorful, etc.). Since there's a lot of pressure in the 2600 scene to push the visual edge, I don't see snack support as an choice that will be made. (given the added resistance of needing your players to buy-in to the control scheme) For 7800 homebrews, it's doable for the most part. Games which really push DMA (time to render display objects) may have problems with the reading of values being delayed too long. For 7800basic specifically, I'd need to overhaul the current interrupt system to get an extra one in the middle of the screen, which competes with future plans I had for the interrupts. Overall the specific timing requirements required here are making snack a less optimal choice. Not impossible, not particularly difficult, just constraining.
  14. So cool! Your daughter is very talented.
  15. RevEng

    Salvo

    I won't be able to catch this one live (my cultural background celebrates Christmas Eve, rather than Christmas Day) but I wanted to say thanks for the playing my game, and I hope everybody enjoys themselves! I'll definitely catch the show after the fact. 🌲🌲🌲 Merry Christmas! 🌲🌲🌲
  16. As far as 7800basic goes, that approach should be fine. There's the possibility that interrupts may happen, so you just need to make sure your top/bottom routines don't do anything that would stomp on your break handling routine.
  17. Just a heads-up... it looks like SNACK uses particular paddle values though the range to signal particular buttons. Unlike A8, which has POKEY to do paddle AD conversion, the 7800 and the 2600 use a tight CPU polling loop to do the AD for paddle values. For reading larger paddle values, a full screen's worth of CPU is needed. So I think that SNACK as a standard for SNES controller reading in the 7800 and 2600 worlds isn't going to work.
  18. Can I use ROM for DLL and DL on modern carts? Honestly, depends on the cart+eprom. Apparently my using ROM for character strings in 7800basic caused some heartache for the AA cart designs. The fixes implemented for those may or may not be sufficient to allow for ROM based DLL and DL. I'd be very careful in testing this with the specific cart hardware you intend to use, since a corrupted DLL or DL would be tragic. Is there any special bit in header to set? [for mirror memory] Is there any emulator/cart supporting this cart? bit 7 of the cart-type. A7800 and Concerto implement this bit. Is it possible to use any emulator in RAM only mode? (all ROM addresses could be written like RAM) None of the current crop of emulators have this, AFAIK.
  19. Entirely correct - I saw the table and wrongly thought it was for SNACK. Your enhanced mode description sounds great. Thanks for the clarification and your SNACK support library!
  20. @Irgendwer Can all of the buttons from SNES->SNACK be identified separately? If I'm understanding the docs right, SNACK returns a combination of joystick lines that could also be valid actions in gameplay. e.g. the SELECT button on the controller would generate either be LEFT+UP or LEFT+FIRE, depending on the SNACK config selected. The PET version of Petscii Robots clocks the button data out of the SNES pad, with direct communication to the snes clock and data lines. This allows for unambiguous button combinations.
  21. Maybe possible, but not feasible for this project. The connector/splitter would need to be custom, mapping jag rows and column lines to different pins in each db9 port. Alternatively, a microencoder could be used to read and multiplex or serial-encode the jag controller output, sending it to a single db9, but again, not feasible for this project. A custom adapter is too big a lift.
  22. I had a look at the Jaguar controller pinouts, and it seems to use a keyboard-style matrix, with a lot more lines than we can muster in single joystick port. I'm guessing these jag->db9 adapters just hard-code for column 4 (with drections, button-a, and pause) and drop the other columns, ignoring the keypad entirely. So I don't think Jag pad is a feasible option here.
  23. A part-way unroll... I like it!
  24. Yeah, don't think you'll do better than Eagle's and SmittyB's countdown suggestion, without unrolling. (which would be ridiculous) If you're not already, you can run the radar clear+build during the visible screen, after the radar itself is displayed. You could also get away with splitting the radar clear+update into strips, and update each strip on different frames. At the coarse resolution of the radar, even 1 zone per frame would likely work.
  25. I feel your pain. As someone who runs a couple small domains for small family businesses, I've had to request whitelisting with large mail hosting services (microsoft, different telcos, etc) because they blacklisted entire ranges of IPs due to spammers having an address within. This is even with all of the good-mailhost practice (domain keys, spf, etc.) setup on my end. Worse yet, often these hosting companies will just spambox your mail for no obvious reason, and not formally reject it, so you don't even know there's a problem.
×
×
  • Create New...