Bennet

Yep! Exactly as I remembered it! Thank you for finding that. I'm surprised it was so short, it felt way longer when I saw it as a kid. Amusingly, I first booted without Basic and it went to DOS and it was DOS 2.5+ for a 256K machine? That'd be surprising if the original disk had that.

That's awesome! I'll check it out as soon as you post it. I didn't pull out my disk because it's buried in storage, deep in a box behind a bunch of other boxes. But if you found it, I'll know instantly.

Seems to have fixed it! Thank you! I would have complained sooner, but it was really sporadic and hard to spot.

There's a bug I keep running into with Quick Save State/Quick Load State that makes PM graphics 'glitchy'. I found a game that repros it more easily than others, "Bounty Bob Strikes Back". It'll happen in many games, and it causes a PM to be drawn at the wrong horizontal location. It flickers a bunch but the misdrawn parts do seem to have a pattern to the flicker. To hit it, just 'Quick Save Sate' then 'Quick Load State' until one of the 'Quick Load State's will result in the PM's glitching like you can see below: You can see two of them doing this 'strip glitch', one near the middle of the screen, and another lower down. When running it cycles each frame as to which ones are glitching (harder to show). Once in this state, doing 'Quick Load State' again won't fix it, and it will stay in this state even after doing a cold reset. Doing 'Quick Save State' then 'Quick Load State' can get it back out of it, oddly enough. If you have any other games/apps to try when in this state that'll give you a clue let me know! For other ones like 'Jumpman' it's harder to spot as it'll just be one frame in many. The PM collision detection applies in the glitched location (which of course kills you in many games).

I'll dig out the disk and take a photo. And by unreadable, I mean the disk surface was physically damaged. I'll try and show a photo of that too.

Yeah, it's not that one. I already had that one But thank you for trying.

Sadly the copy I have was unreadable so I couldn't make an image of it, but it's a demo disk from Epyx for these games: Crush, Crumble, and Chomp Crypt of the Undead (Might just be 'The Crypt' on this disk) Ricochet ? (maybe others, I forget) Would be awesome if someone had a copy of it, as I can't find it mentioned anywhere. I have the physical disk so I'm not imagining it! Edit: All of the demos played themselves, almost like commercials for the games, you couldn't play yourself from what I remember. But I used to watch them over and over as a kid, would be neat to see them again.

In my document it's the 'V' values that happen after cycle 105. I called them virtual reads because Antic would have done DMA at that location and everything internal to Antic acts as though a read happened, yet no DMA happens. Since they affect DMA cycles they definitely affect the outside world since with a large enough HSCROL value you actually speed up perf because you'll get back 3 DMA cycles per scanline.

By taking an actual Atari, an LCD panel that displays the overscan area, the Antic patents and diagrams, some knowledge of digital chip design, and a lot lot lot lot of time reverse engineering it based on how it actually behaves. All of the surprises I discovered were very explainable (the virtual reads the Antic does for example). So it's as accurate as I could possibly make it, but as I saw above if there's different memory refresh circuitry for different types of memory then those wouldn't match my table. It's my little gift to the Atari world -Bennet

Oops! Someone accidentally deleted the Antic_Timings.txt on my website. Even though this thread has a copy of it I put it back just in case. So far nobody has ever sent me any corrections/additions to it, but I figure there are only a couple people on the planet who actually would be so interested as to research it. -Bennet

Go Don Go! Or to be really optimal, you make it so that your ring buffer is 256 elements and then your get/put indices are bytes. Then when incrementing the byte past 255 it naturally wraps back to 0 for you. I was thinking this is what you'd have used on the 800, but 256 entries per list is a lot and would potentially use up the memory too fast. Also, I've always avoided MOD (%) since it involves a divide instruction. Making your buffers powers of two in size, then just AND'ing against the appropriate bit fields is a much faster instruction. (Ex: buffer holds 64 elements, then you do 'index &= 64-1;' or 'index &= 0x3F'. -Bennet PS - Thanks for the email, it totally explained why the enemies would move through a mostly destroyed wall

Wow! It seems that once a year I'd do a search to see if the 'Registered Version of Gauntlet by Donald R. Lebeau' surfaced anywhere online and it looks like it just came out! I was only 9 or so when the shareware one came out and I remember asking my Dad many times to buy the real version. (I asked him about it a few days ago and he still remembers the game and me asking!) It had to be one of the most played games on my Atari 800XL, and one where I never fully figured out the 'magic' that made it work! Like how the enemies detected line of sight when the terrain was destructible... I have guesses now as to how it'd work but back then it was pure magic! Years later when I learned 6502 assembly I wanted to see if I could cheat in the game, my goal was to make the ship invulnerable to damage. So I disassembled the game file looking for suspicious 'dec' instructions. It took a few tries but I finally nop'd the right one and it worked. Crazy! I'd have loved it if the source code survived... I still would have loved to read it today. I agree with the other posters that the final version is much harder than the original. I was killed in the first few screens until I found out that flares are my new weapon of choice since they're the only weapon that can cut through the constant stream of shots firing towards the player! So thank you for the many years of fun and for sharing the inside info about it! I'd have gladly sent the $35 now also, though since you don't want money I'd at least share how much I enjoyed it! -Bennet

Very useful! I never tested this myself, but what you did shows that the Antic's does not start counting through video memory always at the start of wide, it starts when the playfield starts. As in, if the numerical character values lined up vertically it would mean it always start at wide, and they don't. Is there a way to see what happens if you switch off the DMA mid-scanlile? Or on scanline 4 of the character mode to see if it stops fetching character graphics for the remaining lines? (or if it simply grabs bus noise)

It makes sense to me. but the formatting makes it very hard to read here. Any way to edit out those extra line breaks? It looks like the file came from an Atari! Sounds like it's saying how you can make Antic display multiple lines of Mode F? (or any other mode) by setting VCTR to an invalid value through scrolling. Based on the internal workings I've seen this is to be expected.

Yea, especially on the high resolution character modes, the CPU is frozen. Which made me wonder how other computers of that era did their high resolution displays given you can only read so many bytes per scanline. I think the refresh system could have gotten away with less but probably not much less. I think the refresh circuit increments sequentially whenver it gets a cycle to run. I like how it handles getting preempted. I also wondered if there was a way to alternate the VSCROL on some high res modes to make a bunch of 1 scanline 48 column text mode lines, but I didn't think further than that.