There is some middle ground between basics and "assumed already expert" that something like this with practical examples can fill nicely. Seems like a great idea.
EG on disk handler sector read, what kind of status should we expect. If it fails should we try again, or assume bad sector.
On topic of exact cycle wasting I nominate clockslide https://www.pagetable.com/?p=669as one of the sneakiest tricks. Not something that instantly springs to mind!
6 cycle wait in 2 bytes if you don't mind messing up the carry
I always wondered why Atari offset the player/missile horizontal position by 40 pixels before becoming visible to the screen. Even at Quad width, the whole player is hidden if below a value of 24 anyway. Well a lot of the numbers for the Antic/GTIA do not make sense.
That one makes sense - it's so 128 is the exact centre of the screen.
A ':' specifies the number of times to repeat the line (in the case of a macro, this specifies a macro parameter by number if it is in decimal). The repeat count should be in the range <0..2147483647>. When repeating a line with ':repeat', it is possible to use the loop counter in the repeated line using a hash sign ('#') or the parameter :1.
Yes it is part of the arcade, but the chances of it happening in the arcade seem to have been less... maybe a 1 in 6 chance or whatever number that works best in the engine would be useful..
It's hard to compare as it's easier to hit the scenery in the Atari version. (I honestly don't know how the bullets miss the scenery so often in the arcade one. They seem to have some pretty funky logic). But if you want to see what 1 in 6 chance is like, please find attached.
Ah, I see what you're referring to now. Yes, there is a new big explosion for things on the ground. It seems to be working as expected from your video. There is a 1 in 4 random chance of it happening as long as things are not very close and in the distance. Yes, it can sometimes get in the way of seeing things, but it is in the arcade game.
Since the "likes" don't show up unless using desktop site, just wanted to say thanks for the compliments and feedback from everyone. Much appreciated.
It's not much different than the original, there's some source code floating about here somewhere. But basically, it's 2 joined channels at 1.79Mhz so the IRQ can be timed exactly to the scanlines, rather than all channels in 15khz.
As it's Antic D IRQs can interleave with the DLIs without much affect.
Monitor's black-point itself MUST be calibrated for standard NTSC signal:
You need colorimeter, or SMPTE pattern displayed from a source via SAME video interface of Atari (either Y/C or Composite), and then adjust Brig/Contr., to make sure your blacks are as black as they can be, without killing dynamic range.
This requires understanding how the Contrast function is applied by your monitor, as well as the Brightness:
Do you see highlights AND shadows boosted up?
Do you see brighter highlights and darker shadows?
Row #0 of (Atari) ColorMap utility shows a 16-shade gray-scale, starting with #0 as being "black".
A preliminary step (not mentioned on my previous related post) is about Atari's own BLACK-POINT calibration:
Patch #0 of Row #0 is set to match Monitor's BLACK-level (e.g. patch # 0 should NOT be visible ABOVE the monitor's own black, as set in step #1, or at least, should be VERY close).
This is VERY important to naturally maximize contrast and potentially improve gamma response, too.
It turns out that I had already done the above, and STILL see Space Harrier's "black-levels" not being true to calibrated levels. In other words, anything else I do at this point will corrupt the (correct) black-level derived from above adjustment.
In any case, I would still like to see Space Harrier's set to Atari's true (or nominal) black-level, as shown on Patch #0 , Row #0, in ColorMap matrix. I wonder how bothersome the flicker would be, as I can't see ANY flicker through DVDO iScan HD engine, except when displaying the Dragon's segmented body.