Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


RevEng last won the day on February 6 2014

RevEng had the most liked content!

Community Reputation

5,054 Excellent


About RevEng

  • Rank
    Space Cowboy

Profile Information

  • Gender
  • Location
    bottom of the stack

Recent Profile Visitors

44,106 profile views
  1. [edit - this time SmittyB beat me to it. alphadata can be easily copied to ram in 7800basic, as can pretty much any data type, as long as you know the size of the data. character plotting routines can be pointed to memory instead of rom.] Just wanted to point out that some duplication of data and/or code in different banks is common practice, and pretty much the nature of the beast. I get that it feels wasteful, but often enough the duplication allows you to reduce the complexity of your code, making the trade-off worth it. Heads up that copying a rom table to ram can be done pretty easily with the "memcpy". In the samples directory "ramcharmap" has example code that loads different character level data to a ram-based character buffer. The bankswitching constraints are actually not very different from vanilla bB, but for sure different than the DPC+ bankswitching you're used to. DPC+ has ARM-based RAM that's used for update of display objects, and can be accessed from any bank.
  2. there's different emphasis in our replies, so both are helpful. 👍
  3. The alphadata needs to be visible to Maria when it's the time to render them on the screen. If you store your character data in a non-permanent bank and switch away during the visible screen (where much of your 7800basic game will run) then you will likely corrupt the character display. There's a few common solutions to this: store your character data in a permanent bank (last bank in rom sizes that are multiples of 128k. first+last bank in rom sizes that are multiples of 144k) store your character data in the same bank as your main loop. copy your character data to ram, and plot that instead. (as you worked out) keep a copy of the character data in the exact same place in both banks you're switching between. (possible, but not always practical) wait for the visible screen to complete before bankswitching by using the "drawwait" command (hugely wasteful of available CPU time, so really only useful for non-main-loop situations) The reason that clearscreen+plotmap+savescreen doesn't work to fix the issue, is that those are all commands that just prepare display objects in advance of maria drawing the visible screen. They don't actually render the characters on the screen at the time you issue those commands; Maria has no framebuffer, so it needs to be able to fetch that object data at the exact moment in time the beam is drawing the scanlines where your object should be. (i.e. Maria is racing the beam)
  4. Sadly, not a whole lot of helpful info there. Just one shot in the dark - can you try setting up a7800 in a location without spaces in the path? I don't think it should make a difference, but it's the one thing that's sticking out to me.
  5. It may be useful if you launch A7800 from a CMD window instead, as that way you'll see any error output. Also you might want to double check that the a78 file actually is correct in size. The only time I've seen a7800 crash out personally is when I've accidentally specified a wrong-sized file of the wrong type.
  6. The CC2 has had a long good run, and the rom format updates released by Mitch have undeniably extended t's usefulness. It is looking a little long in the tooth, though. I'll agree with these points that others have raised... The menu app is a pain, especially if you're not running Windows. To be fair, the Mateos filesystem rituals sound worse. The MMC card is problematic to replace. Related to that, card readers that support MMC aren't universal. I have the Canadian equivalent of a Micro Center nearby, and when I asked if they had a card-reader that said it supported MMC, I then had to explain to the salesperson what an MMC card was. 😆 And I'll add a point... The plastic holder for the MMC has a tendency to shear off, and has done so for a number of members. (guessing that this is the nature of the repairs that -^CrossBow^- was doing)
  7. It's a good idea. I tried that a while back. It definitely helps push that lower threshold, but the separation between the bottom and top of visible is about 70 lines, vs 192 between the top and bottom, so it's not perfect. Also the bottom of the visible screen marks the beginning of non-visible CPU time, which is very precious on the 7800. Ideally I'd have an interrupt for a second check smack-dab in the lower section of the visible screen, but I try to avoid mid-screen interrupts, as it will likely tie my hands with other features I have planned, like vertical scrolling. For now anyway, allowing the game designer to tune the timing of the driver will work. If the game is using driving controls as paddles, it will almost certainly support paddles too, so the game will have to budget CPU time for reading those.
  8. I mentioned previously I was referring to the 2600 driving wheel, but using it as a paddle replacement. Reading it once per frame is great when you're using it like a 16-position steering wheel. When you spin moderately fast (like I did in my demo) it misses values all over the place. To get traction on the screen from the 16 position wheel, I'm doubling the distance, and also applying an acceleration curve.
  9. I ran though a test where I entirely disabled the branch at the end, and added "inc leftmove" and "inc rightmove" to the relevant parts of the driver. (fire button in the demo clears the values, to make it easy to see changes) Allowing only one pass simulates a near-worst case for DMA. 100% DMA usage, while possible in theory, would be quite difficult to achieve with a real game design. With this demo, turning the driving control at quick speeds with my fingers or palm on the control at all times, I can't get backwards values to register at all. (clearly the controller does get stalled values at quicker rates, as it slows down when it should be going faster). I can get some small number negative values on a positive spin if I slap spin it, the same way one might keep a basketball spinning on their finger, but otherwise don't see negative values with any technique that seems useful for game play. Going back to the numbers... The wheel has 16 positions encoded per 360 degree turn, which means to get it to miss a value you need to be spinning faster than 1/16 revolutions per frame, and to start getting false negative values, you need to exceed 1/8 revolutions per frame. Converting to rotations/second (using PAL) for those numbers gives you 3.125 rotations/second, and 6.25 rotations/second, respectively. The lower threshold comes into play, but the upper one seems difficult enough to hit that it doesn't warrant worrying about it. Anyway, thanks again for the help. Your version of the driver is in place and working well. 👍
  10. You're welcome. For sure it's on the list of things to fix. Glad you're back on track now!
  11. It's a bit tough to make out, but for each life the ship has a different name on it's side... Chico, Harpo, Groucho, Gummo, and Zeppo. 👍
  12. You're not going to like this... the a78 file you provided does play the sounds as intended. a7800 isn't great when dealing with both [email protected] and supergame. It's an issue inherited prior to being forked from Mame. If you launch with an "XM" plugged in, it will work. e.g. "a7800 a7800 -cart1 xm -cart2 sounds.bas.a78"
  13. Sure, but a quick clockwise overturn isn't trivially detectable from a slow counterclockwise turn. I don't think it's a common enough failure to warrant potentially throwing what might be good samples, but I guess I need to do some testing to back that up. The C64 had hardware sprites, so it's DMA wasn't quite so involved. The 7800 renders everything - sprites and characters - to a scanline buffer. (technically there's 2 buffers, and while one is used for rendering, the other is displayed.) As part of that, Maria needs to traverse data structures you setup in RAM that describe the objects in the current set of scanlines (aka the zone). It's a sort of cross between hardware sprites and soft sprites - I've always described it as hardware-assisted soft-sprites - and as a result the whole thing is quicker than soft sprites, and slower than hardware sprites. It has it's pros and cons. The main pro is that the 7800 can throw a lot of sprites at the screen with this system, at the cost of losing CPU time that you'd otherwise have access to. Its a very unique machine.
  14. Despite both devices using rotary encoders, reading a Trakball is a different problem being solved. The trakball is much closer to a mouse in resolution, and this sort of device doesn't have the same resolution problems as the driving controller being used like a paddle. The relatively unoptimised mouse driver I presently have performs smooth as silk on the 7800. To use a picture analogy, you won't notice the occasional bad pixel in a high-res photo, but if you expand a 16x16 icon to the same size as that photo, one bad pixel sticks out like a sore thumb. Even if they were comparable controls, the Arkanoid WIP has a little more DMA burden than Centipede.
  • Create New...