| Lo-res 40x96 Demo (kfest hackfest entry) [message #371190] |
Tue, 24 July 2018 12:44  |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
Hello
I've posted video of my Kansasfest Hackfest entry here:
https://youtu.be/iqAYvZl2iIE
And you can find a disk image and source code here:
http://www.deater.net/weave/vmwprod/kfest18/
Keep in mind it was written in 4 days at Kfest.
It creates a 40x96 Lo-res graphics mode by flipping between PAGE1 and PAGE2
every two scanlines. It finds beam position at startup using the
floating bus / vaporlock and then does cycle counting for the page
flipping and does all of the rasterbars/mockingboard music/text scrolling
in the VBLANK period.
Note that this is completely unrelated to double-lores (which is 80x48
using 80col+AUX memory). This 40x96 mode should in theory work even on the
original Apple II.
I've tested it on my Apple IIe Platinum and it works fine. It failed on
various machines I tried at Kfest but they all had accelerator cards and
I think they don't handle PAGE2 lores very well.
Vince
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371199 is a reply to message #371190] |
Tue, 24 July 2018 15:25  |
|
|
Originally posted by: Nicola
On 24/07/2018 18:44, vince@pianoman.cluster.toy wrote:
> Hello
>
> I've posted video of my Kansasfest Hackfest entry here:
>
> https://youtu.be/iqAYvZl2iIE
>
> And you can find a disk image and source code here:
>
> http://www.deater.net/weave/vmwprod/kfest18/
>
> Keep in mind it was written in 4 days at Kfest.
>
> It creates a 40x96 Lo-res graphics mode by flipping between PAGE1 and PAGE2
> every two scanlines. It finds beam position at startup using the
> floating bus / vaporlock and then does cycle counting for the page
> flipping and does all of the rasterbars/mockingboard music/text scrolling
> in the VBLANK period.
I'm speechless!
The effect is emulated well by Virtual ][ (graphics+sound), Jace and
OpenEmulator (without sound), even on an Apple II+ (I haven't tried on
an Apple II).
Since I have seen French Touch's marvelous demos I have wondered: what
is the history of such mixed mode techniques? Were they known in the
'80s? If so, is there any book that describes them? Have they ever been
used in any software? Or have they been discovered/invented more
recently? AFAIU, your demo is the first time 40x96 is seen on an
Apple II, isn't it?
Thanks for the enjoyable demo!
Nicola
|
|
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371202 is a reply to message #371199] |
Tue, 24 July 2018 16:03 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2018-07-24, Nicola <nvitacolonna@gmail.com> wrote:
>
> Since I have seen French Touch's marvelous demos I have wondered: what
> is the history of such mixed mode techniques? Were they known in the
> '80s? If so, is there any book that describes them? Have they ever been
> used in any software? Or have they been discovered/invented more
> recently? AFAIU, your demo is the first time 40x96 is seen on an
> Apple II, isn't it?
I actually personally only found out about this technique about a year
or two ago, but from what I understand it was realtively well known in
the 80s.
For example, my code is at least partly based on that by Bob Bishop's
"Have an Apple Split" article from Softalk, October 1982. This
can be found online.
I also understand Don Lancaster had a series of articles on this as well,
he's the one who called in "Vaporlock".
Why isn't it more common? Well it's a *huge* pain to get it working,
with the cycle counting. And even when you do, your code has to
race the beam at 60Hz.
For example, with this current demo I only really have 4550 cycles during
VBLANK to run the code, that's why the rasterbar is only in a 24x16
window, because that was the largest I could draw in that timeframe.
In theory you could also do stuff in the 120 cycles or so leftover
between the pageflipping every other line but that starts to get
complicated.
My split-screen demo has it a bit easier as I'm only flipping modes
three times per frame (instead of 48 times) so there's enough time
to move some text and draw some sprites. But even so it limits a
bit what you can accomplish with it.
Finally, as far as I know this was the first demo showing off 40x96
graphics mode, but I have to admit there is a huge gap in my
knowledge of Apple II historical software as I was quite young
back then.
Vince
|
|
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371209 is a reply to message #371190] |
Tue, 24 July 2018 23:21 |
Kirk Mitchell
Messages: 55
Registered: July 2013
Karma: 0
|
Member |
|
|
On Tuesday, July 24, 2018 at 10:44:02 AM UTC-6, vi...@pianoman.cluster.toy wrote:
> Hello
>
> I've posted video of my Kansasfest Hackfest entry here:
>
> https://youtu.be/iqAYvZl2iIE
>
> And you can find a disk image and source code here:
>
> http://www.deater.net/weave/vmwprod/kfest18/
>
> Keep in mind it was written in 4 days at Kfest.
>
> It creates a 40x96 Lo-res graphics mode by flipping between PAGE1 and PAGE2
> every two scanlines. It finds beam position at startup using the
> floating bus / vaporlock and then does cycle counting for the page
> flipping and does all of the rasterbars/mockingboard music/text scrolling
> in the VBLANK period.
>
> Note that this is completely unrelated to double-lores (which is 80x48
> using 80col+AUX memory). This 40x96 mode should in theory work even on the
> original Apple II.
>
> I've tested it on my Apple IIe Platinum and it works fine. It failed on
> various machines I tried at Kfest but they all had accelerator cards and
> I think they don't handle PAGE2 lores very well.
>
> Vince
That was great! I bow to you!
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371214 is a reply to message #371202] |
Wed, 25 July 2018 01:23 |
|
|
Originally posted by: Nicola
On 24/07/2018 22:03, vince@pianoman.cluster.toy wrote:
> I actually personally only found out about this technique about a year
> or two ago, but from what I understand it was realtively well known in
> the 80s.
>
> For example, my code is at least partly based on that by Bob Bishop's
> "Have an Apple Split" article from Softalk, October 1982. This
> can be found online.
>
> I also understand Don Lancaster had a series of articles on this as well,
> he's the one who called in "Vaporlock".
I have found those references: they look very interesting.
> My split-screen demo has it a bit easier as I'm only flipping modes
> three times per frame (instead of 48 times) so there's enough time
> to move some text and draw some sprites. But even so it limits a
> bit what you can accomplish with it.
That's quite an accomplishment anyway!
Nicola
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371215 is a reply to message #371199] |
Wed, 25 July 2018 02:25 |
Michael J. Mahon
Messages: 1773
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
Nicola <nvitacolonna@gmail.com> wrote:
> On 24/07/2018 18:44, vince@pianoman.cluster.toy wrote:
>> Hello
>>
>> I've posted video of my Kansasfest Hackfest entry here:
>>
>> https://youtu.be/iqAYvZl2iIE
>>
>> And you can find a disk image and source code here:
>>
>> http://www.deater.net/weave/vmwprod/kfest18/
>>
>> Keep in mind it was written in 4 days at Kfest.
>>
>> It creates a 40x96 Lo-res graphics mode by flipping between PAGE1 and PAGE2
>> every two scanlines. It finds beam position at startup using the
>> floating bus / vaporlock and then does cycle counting for the page
>> flipping and does all of the rasterbars/mockingboard music/text scrolling
>> in the VBLANK period.
>
> I'm speechless!
>
> The effect is emulated well by Virtual ][ (graphics+sound), Jace and
> OpenEmulator (without sound), even on an Apple II+ (I haven't tried on
> an Apple II).
>
> Since I have seen French Touch's marvelous demos I have wondered: what
> is the history of such mixed mode techniques? Were they known in the
> '80s? If so, is there any book that describes them? Have they ever been
> used in any software? Or have they been discovered/invented more
> recently? AFAIU, your demo is the first time 40x96 is seen on an
> Apple II, isn't it?
>
> Thanks for the enjoyable demo!
> Nicola
>
>
>
Check out Bob Bishop’s “APPLEVISION” demo on, IIRC, the DOS 3.3 MASTER
disk.
As Vince explains later, the “vaporlock” technique for switching video
modes synchronously with the raster scan was understood (and occasionally
used) quite early in the history of the Apple ][. ;-)
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371216 is a reply to message #371215] |
Wed, 25 July 2018 03:44 |
|
|
Originally posted by: Nicola
On 25/07/2018 08:25, Michael J. Mahon wrote:
> Check out Bob Bishop’s “APPLEVISION” demo on, IIRC, the DOS 3.3 MASTER
> disk.
Ah, APPLEVISION! After more than thirty years I have finally realized
that the text is not hi-res fonts!
> As Vince explains later, the “vaporlock” technique for switching video
> modes synchronously with the raster scan was understood (and occasionally
> used) quite early in the history of the Apple ][. ;-)
Yet, it's remarkable that new applications of it come after several
decades :)
Is 80-column, double hi-res infeasible for this technique?
Nicola
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371232 is a reply to message #371190] |
Wed, 25 July 2018 11:41 |
|
|
Originally posted by: frank_o_rama
On Tuesday, July 24, 2018 at 9:44:02 AM UTC-7, vi...@pianoman.cluster.toy wrote:
> It failed on
> various machines I tried at Kfest but they all had accelerator cards and
> I think they don't handle PAGE2 lores very well.
>
Really cool! Nice work. The pixel aspect ratio has a bit of an "atari" feel to it which makes me hope for a port of "Oystron" someday. :)
From "Understanding the Apple II" (p. 5-38):
"A very heavily loaded data bus may not reliably store video data long enough to be read by the MPU. Apparently, some commercially available peripheral cards cause this condition when plugged in. Beware!"
Also, I've always seen 'vapor lock' use hires graphics mode to find VBL. Is it maybe less reliable under text/lores mode?
I tossed the "RASTER C" binary on a ProDOS volume and it occasionally de-syncronizes just before moving the color bars for the first time. It scrolls the sprites fine for a few frames before that, however. Not sure if this is related to your timing issue. (tested in both Virtual II and AppleWin)
F
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371244 is a reply to message #371232] |
Wed, 25 July 2018 15:12 |
mmphosis
Messages: 168
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
> Also, I've always seen 'vapor lock' use hires graphics mode to find VBL.
> Is it maybe less reliable under text/lores mode?
cut from here:
https://github.com/deater/dos33fsprogs/blob/master/kfest2018 /raster2.s
;=====================================================
; attempt vapor lock
; by reading the "floating bus" we can see most recently
; written value of the display
; we look for $55 (which is the grey line)
;=====================================================
; See:
; Have an Apple Split by Bob Bishop
; Softalk, October 1982
; Challenges: each scan line scans 40 bytes.
; The blanking happens at the *beginning*
; So 65 bytes are scanned, starting at adress of the line - 25
; the scan takes 8 cycles, look for 4 repeats of the value
; to avoid false positive found if the horiz blanking is mirroring
; the line (max 3 repeats in that case)
vapor_lock_loop: ; first make sure we have all zeroes
LDA #$00
zxloop:
LDX #$04
wiloop:
CMP $C051
BNE zxloop
DEX
BNE wiloop
LDA #$55 ; now look for four all grey
zloop:
LDX #$04
qloop:
CMP $C051
BNE zloop
DEX
BNE qloop
; found first line of low-res grey, need to kill time
; until we can enter at top of screen
; so we want roughly 10 lines * 4 = 40*65 = 2600+4550-65
; +4550 - 65 (for the scanline we missed) = 7085 - 12 = 7073
I think this text/lores mode method of finding the VBL is just as reliable
as using use hires graphics mode. My own routine for hires only searches
for a single byte, whereas this text/lores search repeats the search on the
border and then repeats the search for a known color pattern. I think there
is an advantage to using the smaller memory footprint of text/lores (1K) vs
hires (8K), and not having to clobber hires memory. Going forward, I will
probably use Vince Weaver's method.
Lacking internet in the '80s, I found out about LDA $C050 either by
experimentation or word of mouth.
http://hoop-la.ca/apple2/2011/rainbow/
|
|
|
|
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371248 is a reply to message #371216] |
Wed, 25 July 2018 16:24 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2018-07-25, Nicola <nvitacolonna@gmail.com> wrote:
> On 25/07/2018 08:25, Michael J. Mahon wrote:
>
> Ah, APPLEVISION! After more than thirty years I have finally realized
> that the text is not hi-res fonts!
yes, it didn't occur to me that the text wasn't a hi-res font either.
> Is 80-column, double hi-res infeasible for this technique?
I was thinking of some other modes, such as double-lo-res doubled like this,
but besides the horrible complexity of this, I guess it's not a win at all
and you couldn't accomplish anything that double hi-res could give you.
While this was being discussed on twitter, someone posted a program they made
that did 80-column text using cycle-counting on an Apple II+ without an
80-column card:
https://www.youtube.com/watch?v=tV5bJIk8Lx8
Vince
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371252 is a reply to message #371232] |
Wed, 25 July 2018 16:45 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2018-07-25, frank_o_rama@hotmail.com <frank_o_rama@hotmail.com> wrote:
>
> Also, I've always seen 'vapor lock' use hires graphics mode to find
> VBL. Is it maybe less reliable under text/lores mode?
>
> I tossed the "RASTER C" binary on a ProDOS volume and it occasionally
> de-syncronizes just before moving the color bars for the first time.
> It scrolls the sprites fine for a few frames before that, however. Not
> sure if this is related to your timing issue. (tested in both Virtual
> II and AppleWin)
Yes, there is something going on with the initial vapor lock and I haven't
figured out what it is yet. One thing is that the code is a bit handwavy
about where in the horizontal retrace it initially locks, and possibly
some times it misses.
Also the code looks for 4 consecutive same values before it has a lock,
but in theory if the off-screen RAM values that are scanned during
horizontal blank randomly happen to have the value we are looking for it
could cause the lock to be off by 4 or more cycles. There are safer lines
to use for the lock, my code was arbitrarily picking one that was convenient
because I wanted to draw there eventually anyway.
I finally got around to looking at Don Lancaster Vapor Lock articles, and
he has a huge mass of code that he uses for guaranteeing a lock, and handles
edge cases such as the Apple II+ being a cycle off from the Apple IIe in some
places. I'll have to look through that article to see if maybe something
in there is throwing off my lock.
Vince
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371254 is a reply to message #371252] |
Wed, 25 July 2018 17:58 |
|
|
Originally posted by: John Brooks
On Wednesday, July 25, 2018 at 1:45:40 PM UTC-7, vi...@pianoman.cluster.toy wrote:
> On 2018-07-25, frank_o_rama wrote:
>>
>> Also, I've always seen 'vapor lock' use hires graphics mode to find
>> VBL. Is it maybe less reliable under text/lores mode?
>>
>> I tossed the "RASTER C" binary on a ProDOS volume and it occasionally
>> de-syncronizes just before moving the color bars for the first time.
>> It scrolls the sprites fine for a few frames before that, however. Not
>> sure if this is related to your timing issue. (tested in both Virtual
>> II and AppleWin)
>
> Yes, there is something going on with the initial vapor lock and I haven't
> figured out what it is yet. One thing is that the code is a bit handwavy
> about where in the horizontal retrace it initially locks, and possibly
> some times it misses.
>
> Also the code looks for 4 consecutive same values before it has a lock,
> but in theory if the off-screen RAM values that are scanned during
> horizontal blank randomly happen to have the value we are looking for it
> could cause the lock to be off by 4 or more cycles. There are safer lines
> to use for the lock, my code was arbitrarily picking one that was convenient
> because I wanted to draw there eventually anyway.
>
> I finally got around to looking at Don Lancaster Vapor Lock articles, and
> he has a huge mass of code that he uses for guaranteeing a lock, and handles
> edge cases such as the Apple II+ being a cycle off from the Apple IIe in some
> places. I'll have to look through that article to see if maybe something
> in there is throwing off my lock.
>
> Vince
BTW: The offscreen video fetches don't happen on the Mega2 (//e card on Mac LC and on GS), so vapor lock techniques that use the screen holes will fail on those machines. Possibly also on Platinum //e as the Mega2 was derived from Platinum //e.
The GS does border color access and SCB/Palette access during offscreen cycles, unlike the //e.
-JB
@JBrooksBSI
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371256 is a reply to message #371244] |
Wed, 25 July 2018 18:08 |
Michael J. Mahon
Messages: 1773
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
mmphosis <mmphosis@macgui.com> wrote:
>> Also, I've always seen 'vapor lock' use hires graphics mode to find VBL.
>> Is it maybe less reliable under text/lores mode?
>
> cut from here:
> https://github.com/deater/dos33fsprogs/blob/master/kfest2018 /raster2.s
>
> ;=====================================================
> ; attempt vapor lock
> ; by reading the "floating bus" we can see most recently
> ; written value of the display
> ; we look for $55 (which is the grey line)
> ;=====================================================
> ; See:
> ; Have an Apple Split by Bob Bishop
> ; Softalk, October 1982
>
> ; Challenges: each scan line scans 40 bytes.
> ; The blanking happens at the *beginning*
> ; So 65 bytes are scanned, starting at adress of the line - 25
>
> ; the scan takes 8 cycles, look for 4 repeats of the value
> ; to avoid false positive found if the horiz blanking is mirroring
> ; the line (max 3 repeats in that case)
> vapor_lock_loop: ; first make sure we have all zeroes
> LDA #$00
> zxloop:
> LDX #$04
> wiloop:
> CMP $C051
> BNE zxloop
> DEX
> BNE wiloop
>
> LDA #$55 ; now look for four all grey
> zloop:
> LDX #$04
> qloop:
> CMP $C051
> BNE zloop
> DEX
> BNE qloop
>
> ; found first line of low-res grey, need to kill time
> ; until we can enter at top of screen
> ; so we want roughly 10 lines * 4 = 40*65 = 2600+4550-65
> ; +4550 - 65 (for the scanline we missed) = 7085 - 12 = 7073
>
>
> I think this text/lores mode method of finding the VBL is just as reliable
> as using use hires graphics mode. My own routine for hires only searches
> for a single byte, whereas this text/lores search repeats the search on the
> border and then repeats the search for a known color pattern. I think there
> is an advantage to using the smaller memory footprint of text/lores (1K) vs
> hires (8K), and not having to clobber hires memory. Going forward, I will
> probably use Vince Weaver's method.
>
> Lacking internet in the '80s, I found out about LDA $C050 either by
> experimentation or word of mouth.
>
> http://hoop-la.ca/apple2/2011/rainbow/
>
>
>
>
You can read any address that doesn’t drive the bus. An output-only I/O
address is standard.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371270 is a reply to message #371254] |
Thu, 26 July 2018 11:02 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2018-07-25, John Brooks <jbrooks@blueshiftinc.com> wrote:
> BTW: The offscreen video fetches don't happen on the Mega2 (//e card
> on Mac LC and on GS), so vapor lock techniques that use the screen
> holes will fail on those machines. Possibly also on Platinum //e as
> the Mega2 was derived from Platinum //e.
interesting. This might explain why the code always works on my
Platinum //e but fails sometimes on the emulator (and also apparently
on older machines).
Maybe the AppleWin floating bus code assumes an older machine?
Vince
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371275 is a reply to message #371216] |
Thu, 26 July 2018 11:46 |
|
|
Originally posted by: awanderin
Nicola <nvitacolonna@gmail.com> writes:
> On 25/07/2018 08:25, Michael J. Mahon wrote:
>
>> Check out Bob Bishop’s “APPLEVISION” demo on, IIRC, the DOS 3.3 MASTER
>> disk.
>
> Ah, APPLEVISION! After more than thirty years I have finally realized
> that the text is not hi-res fonts!
>
>> As Vince explains later, the “vaporlock” technique for switching video
>> modes synchronously with the raster scan was understood (and occasionally
>> used) quite early in the history of the Apple ][. ;-)
>
> Yet, it's remarkable that new applications of it come after several
> decades :)
>
> Is 80-column, double hi-res infeasible for this technique?
>
> Nicola
Applevision *does* use hi-res fonts. No vapor-lock there. Just hit
Control-C after the demo runs through and you'll see the text sitting
there on the screen.
Or type:
TEXT
POKE -16304,0
--
Jerry awanderin at gmail dot com
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371286 is a reply to message #371248] |
Thu, 26 July 2018 14:50 |
scott
Messages: 4380
Registered: February 2012
Karma: 0
|
Senior Member |
|
|
In article <slrnplhn33.mp5.vince@pianoman.cluster.toy>,
<vince@pianoman.cluster.toy> wrote:
> While this was being discussed on twitter, someone posted a program they made
> that did 80-column text using cycle-counting on an Apple II+ without an
> 80-column card:
> https://www.youtube.com/watch?v=tV5bJIk8Lx8
I don't think you need cycle-counting for that. If I had to guess, it's
just flipping between the two Hi-Res pages. One page has all the high bits
clear (for even-column pixels) and the other has all the high bits set (for
odd-column pixels). You could also use this technique for something
approximating double Hi-Res graphics.
That said, making the page switch happen during the vertical-blanking
interval most likely involves a loop that would keep the processor busy,
polling for the VBI.
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?
|
|
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371369 is a reply to message #371270] |
Sat, 28 July 2018 08:55 |
sicklittlemonkey
Messages: 570
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Friday, 27 July 2018 03:02:08 UTC+12, vi...@pianoman.cluster.toy wrote:
> On 2018-07-25, John Brooks <jb...@blueshiftinc.com> wrote:
>> BTW: The offscreen video fetches don't happen on the Mega2 (//e card
>> on Mac LC and on GS), so vapor lock techniques that use the screen
>> holes will fail on those machines. Possibly also on Platinum //e as
>> the Mega2 was derived from Platinum //e.
>
> interesting. This might explain why the code always works on my
> Platinum //e but fails sometimes on the emulator (and also apparently
> on older machines).
>
> Maybe the AppleWin floating bus code assumes an older machine?
It would be very interesting to verify whether the Platinum //e is different.
I wrote the floating bus code around 2001-2002 in another emulator and donated it to MESS and later AppleWin, though since then they've both changed quite a bit.
AppleWin still has the original code in Video.cpp in VideoGetScannerAddress(). The code is written for relative clarity - i.e. not optimized - based on the logic equations given in Sather's books.
It still has the check that differentiates Apple II/IIe HBL scanning in TEXT/LORES - the Apple II scans the address | 0x1000. I hope that code is still being used, but I don't have a dev environment handy to check.
That's the only II/IIe scanning difference I'm aware of.
Sather's summary starts on page 5-40 of his IIe book.
Cheers,
Nick.
|
|
|
|
| Re: Lo-res 40x96 Demo (kfest hackfest entry) [message #371378 is a reply to message #371369] |
Sat, 28 July 2018 10:12 |
TomCh
Messages: 242
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, July 28, 2018 at 1:55:53 PM UTC+1, Nick Westgate wrote:
> On Friday, 27 July 2018 03:02:08 UTC+12, vi...@pianoman.cluster.toy wrote:
>> On 2018-07-25, John Brooks <jb...@blueshiftinc.com> wrote:
>>> BTW: The offscreen video fetches don't happen on the Mega2 (//e card
>>> on Mac LC and on GS), so vapor lock techniques that use the screen
>>> holes will fail on those machines. Possibly also on Platinum //e as
>>> the Mega2 was derived from Platinum //e.
>>
>> interesting. This might explain why the code always works on my
>> Platinum //e but fails sometimes on the emulator (and also apparently
>> on older machines).
>>
>> Maybe the AppleWin floating bus code assumes an older machine?
>
> It would be very interesting to verify whether the Platinum //e is different.
>
> I wrote the floating bus code around 2001-2002 in another emulator and donated it to MESS and later AppleWin, though since then they've both changed quite a bit.
>
> AppleWin still has the original code in Video.cpp in VideoGetScannerAddress(). The code is written for relative clarity - i.e. not optimized - based on the logic equations given in Sather's books.
>
> It still has the check that differentiates Apple II/IIe HBL scanning in TEXT/LORES - the Apple II scans the address | 0x1000. I hope that code is still being used, but I don't have a dev environment handy to check.
>
It's no longer used, but IIRC I've tested that the output from your code matches the 2x NTSC look-up tables.
In fact it'd be good to use your code to initially generate the 2x look-up tables. I'll take a look at doing this soon.
If there's a 3rd table to generate for the Platinum //e then I'm very interested too!
Tom
|
|
|
|
Members
Search
Help
Register
Login
Home
