Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: mmphosis Newsgroups: comp.sys.apple2.programmer Subject: Re: Vertical Blank on Apple ][+ Date: Tue, 23 Aug 2016 02:30:01 -0000 (UTC) Organization: Mac GUI Lines: 25 Message-ID: References: <4b75fac1-2004-4e0b-b9e2-5dd131af84b5@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Tue, 23 Aug 2016 02:30:01 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="ac9e0e4d7dd3957fb97803ee6801bab8"; logging-data="6553"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19nl0vd7r4b9tXFnOsuDxIu" User-Agent: Mac GUI Usenet In-Reply-To: Cancel-Lock: sha1:xMcf6ENciyjnFrGcX7S7Ya7JVLU= Xref: csiph.com comp.sys.apple2.programmer:2993 From what I gather the vertical blank can be determined without extra hardware on the Apple II and Apple II+. The folklore story mentions a tight loop and another 17 cycle loop. > To synchronize with the video, Burrell had me fill the Apple II's frame > buffer so the low bit was on most of the time, but set off at the end of > the last scan line. I wrote a routine to sit in a tight loop, reading the > latch. When the low bit changed, we would know the vertical blanking > interval had just begun. > The Apple II wasn't fast enough to keep up with its own frame buffer. A > new byte of video data flew by every microsecond, which was only one > processor cycle. It took at least 10 processor cycles to iterate through a > loop, so we ran the risk of never seeing the low bit change. Burrell had a > way around this, though - if the loop time was relatively prime to the > display frequency, it eventually had to slip into place. I wrote a 17 > microsecond loop that fit the bill, and we were delighted to see it work > perfectly. I wrote routine with a 7 cycle loop that works on at least two emulators. I don't have real hardware to test this on. http://hoop-la.ca/apple2/2015/vbl/