Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


RevEng last won the day on September 5

RevEng had the most liked content!

Community Reputation

5,391 Excellent


About RevEng

  • Rank
    ​​ 👾 Space Cowboy​ 👾 ​

Profile Information

  • Gender
  • Location
    ​ 🇨🇦 

Recent Profile Visitors

44,461 profile views
  1. OG Xbox was a great platform with some fun quirky exclusives... Kung Fu Chaos, Jet Set Radio Future, Grabbed by the Goulies, the Burger King games, etc. This console generation was the height of couch co-op, and is the last gen I look fondly back on.
  2. It might not matter to the store short-term, but it should matter to them long term. The goods being sold are donated by the community as an act of charity. If the public perception shifts to these places being a haven for merchants and ebay flippers, and not serving the community, I suspect that supply of goods will begin to dry up.
  3. I see... yeah, after clearing memory and registers, the rest of the bB startup.asm code sets up the scorepointers, etc. There shouldn't be a reason you need to wipe all of memory for each screen or section of assembly code you run. So I'd skip the general memory clear routine in your logo assembly - that way you can avoid touching memory that bB needs (like the score pointers) and you can restore/clear only the registers and memory you did happen to use in your logo routine.
  4. Just copy the lines of code between the Reset and StartOfFrame to below EndOfLogo, and change this new section of code to reference "Clear2" rather than "Clear". Alternatively you could try to selectively clear your memory and registers, based on what you actually used in your logo code, but the clear routines is so short it's probably not worth the effort.
  5. I don't know about the "very very small" description. 256 characters provide 6 screens of 160A/320A characters, which is a lot for certain game designs, and insufficient for others. (acknowledging that this is worse for other character modes.) The problem is, when you go beyond 256 characters, you start to run into rom storage issues. Beyond a width of 682 you've exhausted the ability of one 16k bank to hold your map data. Beyond a width of 2048 you've exhausted the ability of 48k's worth of address space to hold your map data. All of this storage assumes no vertical scrolling, and one level of data; If that's not true, then multiply the storage requirement by the number of vertical screens, and again by the number of levels your game has. It seemed a reasonable design decision to make 256 the limit for the 7800 plotmap routines, avoiding code complexity for all game designs that can make use of maps up to 256 width. To go beyond those limits, you need to use ram based tiles and roll your own method of tile map compression, screen loading, screen updates, etc. There's no one-size-fits-all generic scroll solution that can be applied to any 6502 level machine. Some scrolling games store groups of tiles as meta tiles, some use compression based on certain attributes of the level data, some may procedurally generate content, etc.
  6. In this latest version, when you clear a group of gems, part of the game code tries to write to the cart rom address space. (assuming accidentally) Trebor uses an nvram based flash cart, which would explain his crashing out in real hardware. If you PM me the list file that was generated along with your those latest attached roms, I can tell you which command is doing this. [edit] teaching a man to fish... if you want to check it out yourself, have a look at quality check your beta games with the debugger section of the "introduction to the mame debugger" wiki page.
  7. This is a question that needs to be answered by devs, and I can only speak for myself... I don't personally intend to target dual pokey or yamaha while there's only one device to play them back, and said device only works with roms. Everybody has their own motivations for making games, but a big part of it for me is the real cart on the shelf. Hopefully other devs will sound off, because what I do or don't do doesn't amount to a lot; while I have a homebrew in the works, I don't churn out games one after another. As far as my developer influence with 7800basic, the YM tracker is already written, so if devs wants to make YM songs for their games they have everything they need, including samples in assembly code and 7800basic. 7800basic doesn't presently have native pokey support built into it's tracker - I was never very keen to make the pokey famine worse - but I'll likely be looking at adding it when hokey arrives. I'll also look at the possibility of RMT/SAP import. Not sure about dual pokey for either, because CPU and RAM are always at a premium.
  8. My ballpark calculation is to start with a full line is 454 maria cycles in length, and subtract out all of the time DMA can't be processing your DL objects. It doesn't matter where the dma starts exactly, as we can just assume it starts at the same position each time. So take that absolute maximum of 454 cycles, and subtract the 28 cycles that maria allows the 6502 to run prior to dma, and then further subtract normal dma startup+shutdown penalties. (16=other line, 24=last line. we'll disregard interrupts, which are another kettle of fish). That gives you 410=last line, and 402=other line. I believe the only factor not taken into account here is the dma startup and shutdown clock alignments. i.e. maria delaying the 6502 halt/resume to ensure the generated 6502 clock is at a non-fractional position. I now believe the long instructions and riot access, etc., only take away from DMA in this way, since Maria doesn't wait for a 6502 instruction to complete before halting. So for worst case numbers, you can drop another 6 maria cycles (3 for dma start, 3 for dma end) from the above totals.
  9. It may be worth trying out another TV for this specific issue. ESB only puts out 2 lines of vsync signal instead of the recommended 3. Some displays will be more sensitive to that than others. Easy thing to try, anyway. BTW, I absolutely love the channel. 👍
  10. Anything could happen, but I think it's right to put any hopes of XM aside and move on with other plans. The YM tracker was indeed mine, and I'm quite proud of it. I had more stuff planned for the tracker, and XM in general as I'm sure Bob and Perry did, and probably others... the first stage of getting XM into dev hands got the ball rolling, but that second stage of getting XM into player hands needed to happen to keep the ball rolling. My hobby coding time is a finite resource, so there's only so much code I'll write on faith. But even without a bunch of XM specific games, any 7800basic games that need RAM, HSC, or Pokey and don't find that hardware, will automatically probe for XM and enable it. Then there's the titles that could have just plain used the HSC or Pokey without being XM aware. Anyway, moving on. Even if XM doesn't get finished, we'll eventually figure out how to reuse the work and resurrect the better parts, in one form or another.
  11. Anything over the 8/16 boundary is ignored.
  12. Yeah, this appears to be a bug on my part. I'll need to dig into it... if you use a narrower width, say 128 or 132, it seems to work.
  13. Obviously too late to help here, but maybe adding a diode in to these barrel-connector conversions would be in order... not sure if the 9v being dropped a tiny bit will affect things or not, but I suspect not. This is the reason I've put off any such conversion - not that I'll personally blow it, per se - but that someday someone else will plug in the wrong adapter while playing adapter roulette.
  14. Well, it's more data for me as I figure out the work-around, so it can only help. 👍
  15. Great catch, Andrew! 👍 bB and 7800basic both have a remove_trailing_commas() function that gets called to work around the dasm trailing comma behaviour, but apparently the ";" comments in the source interfere with the work-around. I'll need to look into that.
  • Create New...