RevEng

Thanks for the kind words of encouragement. No good deed goes unpunished, I guess.

Also, there were missing undocumented opcodes, which did impact some homebrews. Despite that, i agree that it's a shame the ASIC was lost/abandoned.

Just throwing an idea out here... we have 2 kinds of multibutton adapters now, mega7800 and snes2atari, that are in a number of players hands already thanks to 7800GD and Petscii Robots. @batari announced his intent to create a snes2atari+ adapter, which will support proline emulation and native snes2atari. I see these adapters getting even more popular as time goes on, if only to allow couch-complaint pause, reset, new rom selection in flash cart, etc. In 7800basic I put together a "multibutton" build option, and every 64 frames any default-proline controler is probed to see if either of these adapters are present. If one of them is found, its driver runs once per frame and updates SWCHA and INPT1 faux registers, with extra button bits stuffed into the INPT1 faux register. From the game code perspective, the game just checks the faux registers, which is a nice generic interface. I'm not pushing for any asm game author to do all that, but I am using it to illustrate that support for multibutton controls using these adapters are likely to be a thing going forward. It's also worth highlighting that the flashback controls aren't something that are easily obtainable anymore.

I ran the test, and it's actually worse - you lose 3 cycles of DMA for sprites with graaphics that are in the hole. (in addition to the header dma, of course) Additional info is over in the 7800 Hardware Facts thread.

It's been a while since I posted here, but I have another dma wrinkle to spell out... the 7800 Software Gude states "If holey DMA is enabled and graphics reads would reside in a DMA hole, no DMA penalty is incurred", but that doesn't appear to be true. The following test creates: two zones, each with 2x 5-byte sprite objects with 10 bytes of graphics per sprite. two zones, each with 8x sprites as above, but the graphics data is in a DMA hole. Then the test draws bars using kernel-style register hits. The X position of the color bar increases in proportion to how much DMA occurred in that zone. (fyi, the bar width is 12 Maria cycles) The expected DMA for the first set sprites is 80 cycles ((5 byte header * 2 cycles + 10 byte gfx * 3 cycles) * 2 sprites) If we follow the guide statement, the DMA for the second set of sprites is 80 cycles ((5 byte header * 2 cycles + 0 graphics) * 8 sprites) So if the guide is correct, the bar X should be the same for both portions of the screen. But they differ... The X for the second bar is offset by 24 Maria cycles. It seems we're paying the dma penalty for the first byte of sprite graphics, at which point the hole is discovered and the object render is aborted. I think I actually inferred this a while back, as a7800 has the same assumption already coded, but I didn't have solid evidence for it until today. I've updated the DMA section of the7800 Software Guide at the wiki. dmaholecycles.a78

1. It's been suggested in the past that an object's holey dma takes up 1 maria cycle, rather than none, for the calculation/abort. It's one of those things I should have verified a while back, but haven't done yet. I used the +1 cycle per holey graphic in my calculation, to err on the side of caution. 2. That should work - nice variation! Maria still "renders" objects that are outside the 0-159 range, with all the regular dma costs. It just doesn't actually update the scanline buffer with any out-of range pixels.

Maria was engineered for a particular cost target, and they already had to drop the on-board sound-chip to keep within the silicon budget. The 320 modes economically use the same underlying circuitry as the 160 modes, including the palettes and transparency. I'm pretty sure the design goal was the 160A, 160B, and 320A modes, which are all normal enough, with the other 320 modes being bonus/hack modes. In other words, nothing is free. Having quirk-free-high color 320 modes would have required a much more complicated design.

Heads up there's a new v0.29 7800basic release at github. Changes include... feature: added "set 7800GDmenuoff" statement, to flag that 7800GD shouldn't use the menu. feature: added "set 7800header" statement, to allow adding ad-hoc 7800header commands. feature: plotchars now can plot more than 32 characters, when working with 160A, 320A, or 320D. fix: 7800header was sanitising mega7800 controllers on reload. fix: dasm updated. Inability to grow pass-buffer now handled gracefully. fix: plotmap causing compilation errors due to missing multiplication library. I would normally wait more than a week between releases, but the plotmap bug is compile-breaking, so a quick release was warranted.

That music is amazing, and there's so many different themes! Fantastic job @miker!!!

Asteroids_PAL.a78 [edit - the posted rom was updated to flag "pal" in the header too]

Oh dear. Seems like off-by-one errors have now crept into my documentation. Fixed now.

That's a dasm error. It has a "pass buffer" which is used to suppress errors in one pass that actually go away in later passes. If the buffer isn't sufficient to store the next line of output, the buffer gets reallocated to twice the size it was previously. That reallocation is what failed. First thing I'd try is a reboot. If you've been running for a while, even if you have memory, your free memory might be fragmented such that the OS can't hand out a contiguous block.

Thanks for the kind words, guys! As SainT said, I'm looking forward to seeing what you guys do with it. I think it's a worthwhile addition to any proline based game, if even just to allow the player to pause the game from the couch.

I dropped a new v0.28 7800basic release at github. Changes include... feature: new multibutton controller paradigm, which allows simplified support for proline, snes gamepads (via snes2atari), and megadrive gamepads. (via mega7800) Controllers are autodetected and updated on-the-fly by 7800basic. feature: megadrive gamepad support. (via mega7800) feature: freed up space in 7800basic reserved area for converttobcd and math routines, if they're not used. feature: freed up space in 7800basic reserved area by making pokey-based sound effects optional. feature: added "-s" to 7800rmtfix, to produce stripped rmt files, suitable for use with incbin or compression. fix: throw error when rmt is included without pokey support. (reported by AtariusMaximus) fix: increased maximum number of dasm passes to allow complex projects to build. (reported by mksmith) fix: incorrect abort due to space overflow. (reported by darryl1970) fix: rare overflow in if...then parsing. (reported by AtariusMaximus) A big thanks to: @SainT for donating a 7800gd and mega7800 to the cause, and providing sample mega7800 code! @Muddyfunster and @mksmith for running the new multibutton code through it's paces! All of the bug reporters!

You could use PHA in place of the indexed writes, and you'll save 1 cycle per write. You could also save 2 cycles on your X adjustment if you're willing to use undocumented opcodes. (LDA #$FF, SBX #5) [edit: TXA; SBX #5 would be 1 byte less]

hram is "halt-banked ram". Presently it's just implemented in banksets.

The void is just an empty level, which would normally force you to fall down and die. You can survive the void by grabbing a helipack or bubble first, and if you do, eventually you run into some golden platforms that push you off the top of the screen. There's no video of it that I'm aware of, but here's a post that has screenshots of the wall/gold-bars at the end. It's been a while since I did the whole run, but IIRC there's a bunch more bars, but they flicker in and out of existence. e1will also put together a hack that pins the player to the top of the screen, which you can use to see the void+wall and beyond.

For sure, from a technical perspective. Without Alex's permission, it doesn't feel quite right to me, though I do see an argument that it's been abandoned and fair game.

I think that's the most likely hypothesis, but it's not so much that he chose to quit - lots of people move on the from the hobby - it's the no-contact thing that's odd. He doesn't owe anybody anything, but just a simple "I've moved on, guys" statement without any follow-up would have at least put it all to bed. Even better would have been "I've moved on. Here's the source - if someone wants to finish it for a co-credit, go for it", but that's just me being greedy.

Glad to give you something to start with! It was fun getting the z-modem upload to work on my end. I *think* it probably would have been easier to use syncterm to accomplish it, but I did the z-modem upload in the old Unix man way. I posted an earlier version of that demo at AA before, but the version I uploaded is a TheWall exclusive, which I tuned and tweaked a fair bit, to be smoother and more aesthetically pleasing.

There's now one file that can be downloaded. (provided you have a terminal with z-modem support)

I've come to terms that it won't be finished, but Alex's abrupt and complete departure from the hobby has always felt a bit unsettling to me. Short of showing up on his doorstep, everything was done to try and get a hold of him, to see if the game publishing could be moved forward. He either isn't seeing the messages, or he's decided to go no-contact with the entire community.

It's a masterpiece. I think the "giant void/giant wall" ending was probably what he wanted to fix, before calling it done. Even with that ending it's still gold. Alex's domain herbs64.com, where he used to document his various projects, now appears to be a Japanese porn site.