Jump to content

playermissile

+AtariAge Subscriber
  • Content Count

    290
  • Joined

  • Last visited

Community Reputation

450 Excellent

1 Follower

About playermissile

  • Rank
    Moonsweeper

Contact / Social Media

Profile Information

  • Gender
    Male

Recent Profile Visitors

7,644 profile views
  1. Thanks! And I had planned to talk about Miner 2049er in my next episode, so instead of my own in-depth gameplay review, I will point to your episode. The game reviews are always the most difficult part for me to force myself to produce. And, unless it's Ferg, I like the 2 person banter format better anyway, and I liked your banter as much as some of my other favorites (No Quarter, Ten Pence Arcade, etc).
  2. Enjoyed the first two episodes and looking forward to more! I enjoyed the banter: that the game Miner 2049er allowed me to learn a little about coal mines in West Virginia is a vindication of all the time I spent playing games on my Atari. To my parents I say: "see, I did learn something from playing games!"
  3. There's some support on the observation end of things, like UBYTE *libatari800_get_main_memory_ptr(); and all the CPU state is available through access of a structure, but yes, there does need to be a better interface. The real issue is that this control would only be possible at frame boundaries due to the current design of the atari800 code. There is an example of accessing the CPU state in the source: atari800/src/libatari800/libatari800_test.c
  4. Yep, that's a limitation. I don't understand how it generates samples or how it synchronizes or anything. So, I left it out of libatari800, but it is on my mind and I will figure it out at some point. The way atari800 is written, less-than-full-frame emulation requires a separate thread because the only place the atari800 code returns to a user program is after the frame is complete. I have a multithreading implementation that allows stepping by instruction because that's what I needed to make the debugger in Omnivore, but I didn't integrate that code into libatari800 because I thought it was too specific to Omnivore. But I know the core atari800 folks have talked about a multithreaded debugger for a while, so I will talk to them on the mailing list and see if it could be used as a starting point.
  5. Thanks! It certainly is a lot of work, but all the effort to write it and rewrite it to make it understandable to someone else allowed me to (finally!) really understand the concepts. It's a win-win!
  6. Added an example for independent scrolling regions: https://playermissile.com/dli_tutorial/index.html#multiple-scrolling-regions
  7. I finished writing my tutorial on fine scrolling which includes a complete code walkthrough of a joystick controlled, 8-way fine scrolling example program. Thanks for feedback and suggestions in the earlier thread.
  8. Plenty of surprises! Just none about Jumpman. I think Kevin is still waiting on a fix for a specific feature in the level editor, and I need to publish a beta version of Omnivore 2 with executables for Win and Mac so other people than Kevin and I can create levels with custom code. I have created a tutorial on Display List Interrupts as the result of my work on the Roomba level, and I'm working on the possibility of player multiplexing as an optional feature for levels designed in Omnivore for Jumpman II.
  9. Thanks for all the feedback. Got some corrections and additions published now.
  10. For my DLI tutorial I'm trying to work up to an example where there are multiple scrolling regions, like Nautilus or something. But it turns out I have not done any real programming with scrolling before, so I'm creating a scrolling tutorial as I build my way toward my goal. Scrolling has been covered more than DLIs and there are lots of resources out there, but I'll throw this out there too in case anyone finds it useful. http://playermissile.com/scrolling_tutorial/index.html
  11. Would you mind posting a copy of the xex with the problem? I'd like to try to run it through Omnivore 2 with the emulator rewind capability that I'm still working on. (It remembers all history so you can go look at previous frames and do sort-of post-mortem debugging.)
  12. Episode 23 is published. June 1982 magazines and a review of Quarxon. I abandoned the attempt to look at Galahad and the Holy Grail because Quarxon uses display list interrupts and I wanted to look into that for my new reverse engineering focus of the game review section.
  13. Just added a simple example of parallax scrolling.
  14. I thought ATasm was populating $2e0 automatically, but that's a big nope so they were all missing. They're all updated now, and I hope to finish my SDrive-Max soon so I can test on real hardware. I fixed all the other typos you mentioned, thank you. Ah, ok, so ... I'm not sure which frequency the actual hardware crystal oscillator was (NTSC colorburst timing of 3.579545 MHz, or 4x at 14.31818 MHz), but that result was divided down either by 2 or 8 to get to the 1.7897725 MHz at which the processor ran. So, then, 262 scan lines at 114 cpu cycles = 29868 cpu cycles per frame and 1789772.5 cpu cycles per second means 1789772.5/29868 = 59.9227 frames per second. Reading this now pretty much just restates what you've written in the Altirra hardware reference manual, but now the cloud in my brain has lifted. Thanks!
×
×
  • Create New...