Jump to content

RevEng

Members
  • Content Count

    6,767
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by RevEng

  1. So flipping beautiful, and that title screen is just crazy cool! Great job! I really like the animation on the background characters, but I think it gets a bit distracting once the game starts... almost over-stimulating. Maybe it could be slowed down a bit at that point? If the change in speed looks jarring, then maybe it could be accelerated/decelerated over a second or two.
  2. Awesome work-around. I have an idea at what's at the heart of this, but it's not easily solved. Basically the 8-bit values can underflow near or past the 0 coordinate edges. To work around it, I add an offset, but that can only go so far before you introduce the opposite problem at the max-coordinate screen edges. So Y box checks are reliable up to heights of (256-192)/2, or 32. X box checks are reliable up to widths of (256-160)/2, or 48. Beyond that, things get unreliable at the screen edges. This could be fixed by using 16-bit math, but that would cripple the performance. I do need to document these limitations better. Really this all dawned on me some time after boxcollision was written.
  3. No, not really normal. I haven't seen one die like that before. Usually it's just typical wear and tear type stuff. No directions is a bit odd, since up and down should work no matter what the select line sees. I'm trying to imagine what in the console could cause such varying symptoms between your two different genesis controllers. Maybe a marginal riot, or possibly the power supply isn't sufficient. Dunno.
  4. I use a generic 6 button, but they should all be more or less the same. The protocol to select the additional buttons on a 6-button controller hasn't been implemented in any 2600 games. The up and down directions aren't usable when the select line (pin 7, which is +5v on the 2600) is low. Are you using a joystick extension cable? Also, do paddle controllers still work in your console? If it's not an extension or console issue, then yeah, the mux chip in your genesis controller has probably died or the select line has somehow been broken.
  5. Yeah, highly likely you'll break your box if you try to upgrade glibc in isolation. Pretty much everything links to it. If one is determined to take this approach, then doing an upgrade of your entire OS using it's documented process would be the best way. But what you did - using your dist's stella and pointing ADS at it - is by far the easiest way to solve the problem. Great job!
  6. It's sorta known. (no need for apologies!) There's a few statements that eat a lot of rom, and as such cause branch-errors in the if...then logic. Resolving it requires a bit of re-write, and probably will grow the usage of if...then by a few bytes for each one, so I've been putting it off. For now, you can work-around by putting the rom-hungry statement on it's own line and using if...then to conditionally jump past the statement. As for the reason why plotsprite triggers the issue with a variable pallete failing but a constant one working... variable palletes use a bit more rom. plotsprite appears to be on the cusp of the if...then hungry-statement issue.
  7. I have a hacked version of a7800 that subtracts the dma cycles used from the total in each frame. When the action is at a suitable point I just exit and check the values printed out on the console. I'll share it, or something like it in the future, but it's very rough around the edges right now.
  8. The answer is "it depends on how much you're making Maria do". But here's some figures of non-DMA cycles per game frame, for some common games. This is in the midst of action, with a moderate number of game objects moving around. Alien Brigade 13163 Bentley Bear 12024 Choplifter 19660 Commando 16996 DigDug 20401 Food Fight 23198 Froggie 9052 Ms Pac 14871 Popeye 11506 Robotron 26260 Sirius 14971 T:ME Salvo 16970 Bear in mind that a good chunk of that will be updating display lists ("plotting" in 7800basic) so you don't have all of that time available, unless your game isn't plotting objects. But at least it should give you a ballpark idea.
  9. It can go anywhere - inline with your main loop, or within a sub that gets called from the main loop. The main consideration is that it needs to be part of your control handling code, since it allows/denies player movement in a given direction. As such you'd usually run it once per frame.
  10. Nerds often refer to the period symbol as "dot", when it's not being used at the end of a sentence. That would have helped with the search. A label that begins with a dot is limited in scope. i.e. if you use a particular dot label somewhere in a dasm subroutine, you can use the same dot label elsewhere for some other purpose, without a name clash. The reason for the dot label in this particular case is to make it possible to "gosub unrand" directly from bB source code. bB prepends a dot to all of it's labels, which means the basic code "gosub unrand" becomes the assembly code "jsr .unrand". A natural follow-up question might be "why does bB internally add a dot to each label?" The reason bB does that is to support line numbers as labels. Dasm doesn't support symbols that are just numbers, or even those that begin with numbers. So adding the dot to each label was batari's way to turn the line numbers into a label that dasm would accept. (bB doesn't actually use dasm subroutines at all, as far as I recall) The colon is just an optional dasm syntax for labels. Some people use it to make labels more obvious in their assembly source, or because they previously used an assembler that required the colon for labels. I typically don't use it, but I did for some reason here. (and inconsistently too, since .unrand doesn't have one)
  11. It's a 16-bit LFSR. "rand16" holds the upper part of the seed. Try something like... rand=15 rand16=42
  12. Deflemask can import OPM files for it's ym2151 instruments. There's a vgm2opm converter somewhere out there, but you can also just grab the ripped opms instead. A good chunk of all of the games that ever played through a ym2151 is available. The 7800.8bitdev.org wiki OPM Instrument Collection page has a link to the "Mega Arcade Collection" OPM pack, which includes the files for the R-Type games. (and a lot more) To save you the hunting, I've also attached a zip here with just the R-Type OPMs. R-Type_OPM.zip It's also worth mentioning that the x68000 collection on the same wiki page also has the R-Type OPMs used with that platform.
  13. vgm appears to just be a realtime dump of each register hit... it makes sense that you couldn't convert through those formats. I looked at one of the r-type vgm rips. Each song is ~200k. So I don't think it's feasible from a rom perspective to just take vgm on it's own and import. It's the same problem we find with midi files being very rom-expensive, since none of the repetitive bits of the song structure is encoded. [edit...] Hmmm, I think some PCM data was encoded in that one. Other ym2151 rips are about 20k per song, which is still a bit expensive, but at least doable.
  14. RevEng

    HOKEY demo

    I'm late to the party, but this is fantastic news, Fred! It would be best to send the player @mksmith put together for these tunes to Fred in PM, along with your notes on what Pokey settings were used. The M+M demo Fred is using didn't have all the areas, and the player will make it more convenient to check any one song.
  15. It looks like a Windows-specific 7800basic bug, the root of which is Windows both ignoring and gleefully adding capitalisation to file names. The problem is those file names turn into case-sensitive symbols in 7800basic. I've worked around this for the most part, taking the capitalisation desired from the "incgraphic" statement instead of the OS. Unfortunately this doesn't work if the capitalisation inside the tiled file differs from the rest of the usage in the basic file. I'll have to figure out a fix, though it's not quite clear to me what that will look like yet. For now the work-around is to either ensure your incgraphic statement (and other references) matches the OS file name capitalisation, or to open the tmx in a text editor and fix any references inside to match the capitalisation used in your incgraphic statement. (e.g. "Untitled" can be manually changed to "untitled".)
  16. Here's the relevant excerpt from the yellow screen of death section of the manual...
  17. Sure, it's a valid format. The ROM in 32k+ram is the same as plain old 32k format. (i.e. no banking required)
  18. Karl is correct. You can just break out of the inner loop with a goto, as you have here. The outer loop "next" won't get confused with the inner loop one.
  19. Serpentine does indeed support external POKEY. The original A8 game didn't exactly push POKEY's limits, so there's not a huge difference between what you hear when using TIA vs POKEY. With TIA playback, the original music is pitched upwards a bit to avoid sounding sour, and the slithering sound has been modified to be less annoying than it otherwise would be with TIA's coarser volume resolution. If you spent your early years playing Serpentine on A8 you might notice those differences.
  20. Fair point. I guess I let the infamous laughing shoes post, and historic resistance to opening things up to front-ends, incorrectly colour my perception on the general ARM-for-emulation point here.
  21. Nope. I just see someone else's perspective on the matter, and how they might have been led astray, or have a different opinion without the facts. I don't assume bad faith or intent, like you have. For sure "lazy" was insulting, and I didn't defend it. My preference is always debate, discussion, and education, unless someone has historically proven themselves to argue in bad faith. It seems that you don't feel the same, or you've already put me in that latter category. Either way, not much point to further discussion, then. As for questions being "pretty much answered", sorry, but I don't recall OP asking people to stop answering the open questions posed. I do think my replies added to the conversation. Apologies they were too wooden for your taste.
×
×
  • Create New...