You need the delay since you're disabling the VBlank, it needs to execute once to store the DMA shadow.
Weird that you'd get inconsistencies with that example - of course the duty cycle of the wave won't be 50% - the two POKEs will execute fairly quickly but the GOTO suffers from Basic needing to scan from the start of the program to find the target line - although every chance it might be quicker as the POKEs themselves have to convert 2 numbers from BCD to binary.
That's the weakness of Basic right there - you can't depend on it for much better than 1/50th or so of a second re timing and even then the control isn't very granular or reliable.
Using assembler would cure almost all of the problems - one problem I found though is that the rise time from 0 -> 1 of PORT bits is inconsistent and can take a few cycles, the fall time from 1 -> 0 is almost instant.
But that was for triggering scope monitoring of the video signal which requires that accuracy to give you a consistent trace.
Disabling VBlank or at least Stage 2 might help a bit too.
But VBlank is just a blip, the screen DMA would be the largest spoiling factor for timing. Onscreen there's around 40% slowdown, offscreen about 8% slowdown.
Another problem with Basic timing is that Floating-Point operations can be inconsistent in timing.
The best method overall would probably be to use Pokey Timers and an assembly routine. It's the best method for doing waveforms/speech, and allows you to have the screen active and program running normally in the foreground. You still get some jitter but it's only noticable if you're dealing with waveforms over about 4 KHz.
Graphics mode just puts constraints on how often a DLI can occur. In some cases it's not desirable for a DLI every line anyway because the overhead is such that you're not left with much time left to do stuff.
In Gr. 1 it's easy enough - just use a store to WSYNC to skip ahead to the end of the visible display. So for striped text you'd just setup a table with the colour values then read them in a loop.
Left is a photo of my 32 inch LCD TV from 130XE Composite video, right is Altirra screenshot with frame blending enabled.
The LCD isn't quite as I expected - I thought the saturation wouldn't have suffered so much although I've got the colour control on the TV set fairly low. Frame blending is definately going on here as there is no flicker at all. The same thing on a CRT looks an absolute mess.
Also, the colour bars themselves would probably look better if done solid or at least with black inbetween. But the program is there, so can be played around with.
The DATA lines 100,110 hold the palettes for each frame - line 115 has the colour data with luma 2, change which of 110 or 115 is a REM to select alternate colour set.
It does illustrate though that this technique can be done cheaply in CPU terms - there's only a VBI going on, no DLIs at all, a few dozen cycles burnt per frame.
If the 80 x 48 mode is desired, then it could be done with memory savings and not much extra cost in CPU terms.
In my experience it's just easier to do graphics in whatever PC-based package you want to use, taking into consideration pixel aspect ratio and palette limitations. Then just save as raw or BMP and do a quick/dirty Basic program that imports the data and writes to a file on the Atari.
Set in the early 1980s, series dramatizes the personal computing boom through the eyes of a visionary, an engineer and a prodigy whose innovations directly confront the corporate behemoths of the time. Their personal and professional partnership will be challenged by greed and ego while charting the changing culture in Texas' Silicon Prairie.
Only just noticed this. Grabbing a torrent now.
No idea if it centres on real or ficticious characters, or any of the pioneering companies we all know.
Just hoping it's not all about Steve Jobs.
Docs and dramas of such events that just centre on IBM, Apple & HP tend to piss me off.