[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Floating Bus quirks
On Thu, 25 Mar 1999 22:05:27 -0600, Rubywand <rubywand@swbell.net>
wrote:
>Jonathan Schattke writes ...
>>
>> I was reading the October, 1982 issue of SofTalk, wherein Bob Bishop has
>> a nice little article that starts with a quick little program that
>> displays text in the upper half of the screen, and graphics in the lower
>> half.
>>
>> It's a pretty neat trick, although it needed a little tweaking on my
>> Apple //e to work properly. However, this trick will not work on
>> emulators.
>>
>> So, since I'm working on AppleWin anyway, I think I will make it conform
>> to the actual floating bus concept, primarily by setting the video code
>> free from the processor code (since the Apple ][ effectively
>> multi-processed the CPU and video logic), then having a global variable
>> which would be the "last data", which would be the contents of the
>> memory that the video code was looking at. Then any read which was from
>> a null-i/o would have that data set.
>
> ....
>
> Video on the 8-bit Apple II's pretty much just spits out bits on its own with the
>user being free to, at any time, flip registers which affect source memory and format.
>It's a fairly mindless (but fast) approach which allows split-screen tricks like the one
>you mention.
>
> _If_ the emu does not allow mid-frame switching of the video mode, then it seems
>likely that it has virtually no soft emulation for actual A2 video hardware. (If it
>does, there are easy ways to get all sorts of grahics/text combinations.) So, it sounds
>like implementing the "last data" idea could significantly slow the display.
>
>
>
>Rubywand
I suspect the real problem with emulating mid screen mode changes is
that they rely on the refresh rate of the monitor. I don't know what
rate Apple monitors were refreshed, but I'm sure it was a fixed
frequency and probably a lot slower than todays monitors (which
refresh at many different frequencies). To emulate this correctly,
you'd need to very accurately emulate the refresh rate of the apple
monitor and render the screen image in a buffer, and then copy that
buffer to the real video memory during the real vertical retrace.
This would probably be a lot easier to pull off under DOS than
Windows.
Pete