| cycle-counting in textmode [message #374202] |
Sun, 30 September 2018 15:32  |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
So I was playing some games doing cycle-counting in text mode to see
how much of a lowercase charset I could fake on a stock Apple II+.
Screenshot here:
http://www.deater.net/weave/vmwprod/megademo/
You can make a more convincing lowecase I by using Y+' if you set the
page flipping split one line lower, but then you lose being able to
make a small o with '8'+' '.
Extra challenge in that the II+ and IIe offset the fonts one line off
so the code has to autodetect and compensate for this.
While doing this I also managed to find a few ways (at least on Applewin)
to confuse things enough where I was getting the colorburst disabled while
in graphics mode. Is there a known way to do this, to force black and white
mode even on a color monitor?
Vince
|
|
|
|
| Re: cycle-counting in textmode [message #374228 is a reply to message #374202] |
Mon, 01 October 2018 01:12  |
|
|
Originally posted by: awanderin
vince@pianoman.cluster.toy writes:
> So I was playing some games doing cycle-counting in text mode to see
> how much of a lowercase charset I could fake on a stock Apple II+.
>
> Screenshot here:
> http://www.deater.net/weave/vmwprod/megademo/
>
> You can make a more convincing lowecase I by using Y+' if you set the
> page flipping split one line lower, but then you lose being able to
> make a small o with '8'+' '.
>
> Extra challenge in that the II+ and IIe offset the fonts one line off
> so the code has to autodetect and compensate for this.
>
> While doing this I also managed to find a few ways (at least on Applewin)
> to confuse things enough where I was getting the colorburst disabled while
> in graphics mode. Is there a known way to do this, to force black and white
> mode even on a color monitor?
>
> Vince
>
You are awesome! Great work!
I think the color-burst is enabled or not per-line by the video
circuitry but a lot of older TVs would lock in for a whole frame. I
suspect modern TVs that still have composite inputs do the same.
Michael Mahon will almost certainly set the record straight here. He's
a wealth of knowledge about all things Apple II.
--
Jerry awanderin at gmail dot com
|
|
|
|
|
|
| Re: cycle-counting in textmode [message #374234 is a reply to message #374231] |
Mon, 01 October 2018 09:30 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2018-10-01, Antoine Vignau <antoine.vignau@laposte.net> wrote:
> Why do you write page 1 and 0? Isn't that page 2 and page 1 instead,
> is it? Page 0 is the $00..$FF area for me.
I've been programming in C too long so I index my arrays starting at 0.
So I mean GR_PAGE1 and GR_PAGE2 in this case. When looking at the machine
code though I have offsets 0 and 4 I add to the high byte to switch between
them and it's easier for me to map 0->PAGE0 4->PAGE1 in my head rather than
0->PAGE1 4->PAGE2. I should be more careful when I write things up though
bceause I'm not always consistent.
Speaking of the PAGE2 value, I set PAGE2 with "bit $C055" and some of
my cycle counting code jumps into the middle of this instruction to
get a 4-cycle "eor $C0,X". First time I've used that trick.
Vince
|
|
|
|
| Re: cycle-counting in textmode [message #374235 is a reply to message #374228] |
Mon, 01 October 2018 09:34 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2018-10-01, awanderin <awanderin@gmail.com> wrote:
> I think the color-burst is enabled or not per-line by the video
> circuitry but a lot of older TVs would lock in for a whole frame. I
> suspect modern TVs that still have composite inputs do the same.
> Michael Mahon will almost certainly set the record straight here. He's
> a wealth of knowledge about all things Apple II.
On each line I was switching to text mode early in HBLANK and not switching
to graphics mode until halfway across the screen, and at least on AppleWin
this left things in black-and-white for the whole screen. Didn't get a
chance to try on real hardware yet.
On a somewhat related note, I somehow thought that if I draw GR blocks in
a compatible HGR color, then drew the same pattern on the HGR screen, then
flipped between the two pages they would look identical. But the GR line
seems off by 1/2 a pixel. I guess that's expected? I'm going to have
to re-read that chapter in the Sather book again.
Vince
|
|
|
|
| Re: cycle-counting in textmode [message #374236 is a reply to message #374202] |
Mon, 01 October 2018 09:49 |
mmphosis
Messages: 163
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Awesome!
When I was playing around with this I learned that I couldn't just flip into
TEXT mode and kill the color, easily.
http://hoop-la.ca/apple2/2015/winterwarmup/#2015-01-25
IIRC, others here (probably Michael J. Mahon) made me realize that playing
around with the color kill was more difficult than I realized. Maybe, you
need to set TEXT mode (kill the color) just after the end of every line
(back porch), and set the mode you want just before each line (after the
front porch.) Keep the color killed during the vertical blank interval:
setting TEXT mode after the end of the 192nd line should do this. Keep
doing this for every video frame. I think that depending on the TV you are
using it takes more or less frames for the color kill to kick in.
With what you've accomplished so far, I think you could do mixed hi-res /
lo-res / text with color kill!
|
|
|
|
| Re: cycle-counting in textmode [message #374238 is a reply to message #374202] |
Mon, 01 October 2018 10:09 |
|
|
Originally posted by: frank_o_rama
That's fun!
After your last post I realized you would have something like half a cycle per pixel (120 cycles per 192 pixel horizontal line I think?) in "text graphics" mode. Not even close to enough time to address individual pixels. This is a really clever alternative.
According to Sather (Understanding the IIe), colorburst happens during HBL (page 8-6), after the horizontal sync pulse on the "back porch" (page 8-3).
f
|
|
|
|
| Re: cycle-counting in textmode [message #374244 is a reply to message #374238] |
Mon, 01 October 2018 13:12 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
<frank_o_rama@hotmail.com> wrote:
>
> That's fun!
>
> After your last post I realized you would have something like half a
> cycle per pixel (120 cycles per 192 pixel horizontal line I think?) in
> "text graphics" mode. Not even close to enough time to address individual
> pixels. This is a really clever alternative.
Just for the record, the full duration of each scan line (including blanked
borders) is 65 cycles plus a 140ns “stretched” cycle.
> According to Sather (Understanding the IIe), colorburst happens during
> HBL (page 8-6), after the horizontal sync pulse on the "back porch" (page 8-3).
>
> f
Exactly. The horizontal blanking interval between each line and the next
consists of the right black border, the short “front porch”, the horizontal
sync pulse (“blacker than black”), the longer “back porch” which contains
the color burst if in graphic mode, and the black left border. Each line is
active for just 40 cycles of the 65, so the horizontal blanking interval
described above is 25 cycles long.
Most analog monitors will take many lines of burst it no burst to switch
between color and monochrome display modes. In NTSC television broadcasts
(RIP), the burst switching usually occurred both preceded and followed by
several black frames, so the transition time was not critical and invisible
to viewers.
Fast switching was a bad idea, because interference could frequently result
in several lines of corrupted color bursts, and sets were designed to “ride
through” these interruptions. The color burst served to phase lock a
crystal oscillator which could “flywheel” through several lines of missing
burst with little phase drift.
Digital monitors may or may not respond quicker, but if they were designed
for off-the-air reception, they should have made similar provisions for
noise immunity.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: cycle-counting in textmode [message #374245 is a reply to message #374244] |
Mon, 01 October 2018 13:14 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
Michael J. Mahon <mjmahon@aol.com> wrote:
> <frank_o_rama@hotmail.com> wrote:
>>
>> That's fun!
>>
>> After your last post I realized you would have something like half a
>> cycle per pixel (120 cycles per 192 pixel horizontal line I think?) in
>> "text graphics" mode. Not even close to enough time to address individual
>> pixels. This is a really clever alternative.
>
> Just for the record, the full duration of each scan line (including blanked
> borders) is 65 cycles plus a 140ns “stretched” cycle.
I should have said “including” a 140 ns stretched cycle...
>> According to Sather (Understanding the IIe), colorburst happens during
>> HBL (page 8-6), after the horizontal sync pulse on the "back porch" (page 8-3).
>>
>> f
>
> Exactly. The horizontal blanking interval between each line and the next
> consists of the right black border, the short “front porch”, the horizontal
> sync pulse (“blacker than black”), the longer “back porch” which contains
> the color burst if in graphic mode, and the black left border. Each line is
> active for just 40 cycles of the 65, so the horizontal blanking interval
> described above is 25 cycles long.
>
> Most analog monitors will take many lines of burst it no burst to switch
> between color and monochrome display modes. In NTSC television broadcasts
> (RIP), the burst switching usually occurred both preceded and followed by
> several black frames, so the transition time was not critical and invisible
> to viewers.
>
> Fast switching was a bad idea, because interference could frequently result
> in several lines of corrupted color bursts, and sets were designed to “ride
> through” these interruptions. The color burst served to phase lock a
> crystal oscillator which could “flywheel” through several lines of missing
> burst with little phase drift.
>
> Digital monitors may or may not respond quicker, but if they were designed
> for off-the-air reception, they should have made similar provisions for
> noise immunity.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| cycle-counting in textmode [message #374269 is a reply to message #374202] |
Tue, 02 October 2018 12:06 |
Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
> doing cycle-counting in text mode
Just a heads up. If you use AppleWin version 1.27.4 (or higher) the debugger PROFILE command will now show cycles. :-)
i.e.
<F7>
PROFILE RESET
<F7>
// Run performance sensitive code
<F7>
PROFILE LIST
PROFILE SAVE
> While doing this I also managed to find a few ways (at least on Applewin)
to confuse things enough where I was getting the colorburst disabled while
in graphics mode.
If you find bugs in AppleWin please
* post them over in comp.emulators.apple2, or
* better, create an issue on GitHub: https://github.com/AppleWin/AppleWin/issues
My "Apple Lab" has various models: ][+, //e, //c, //c+, IIgs, Laser 128, Laser 128EX, so we can repro. on real hardware if you need.
> Is there a known way to do this, to force black and white mode even on a color monitor?
Not that I'm aware of.
Michael
|
|
|
|
| Re: cycle-counting in textmode [message #374271 is a reply to message #374269] |
Tue, 02 October 2018 14:46 |
|
|
Originally posted by: frank_o_rama
Hmmm... If the colorburst signal is only produced when in graphics mode, maybe timing the cycle so that just before the colorburst signal is produced, switch to text mode, and then back to graphics mode after the colorburst section of the "back porch"?
f
On Tuesday, October 2, 2018 at 9:06:45 AM UTC-7, Michael 'AppleWin Debugger Dev'
>
>> Is there a known way to do this, to force black and white mode even on a color monitor?
>
> Not that I'm aware of.
>
> Michael
|
|
|
|
| Re: cycle-counting in textmode [message #374274 is a reply to message #374271] |
Tue, 02 October 2018 16:40 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
<frank_o_rama@hotmail.com> wrote:
>
> Hmmm... If the colorburst signal is only produced when in graphics mode,
> maybe timing the cycle so that just before the colorburst signal is
> produced, switch to text mode, and then back to graphics mode after the
> colorburst section of the "back porch"?
>
> f
Yep, that should do it.
I once used a similar timing trick to shorten the leading edge of the first
*vertical* sync pulse to create an interlaced 384-line graphics display,
combining HGR1 and HGR2.
It required an external AND gate and an annunciator output.
>
>
> On Tuesday, October 2, 2018 at 9:06:45 AM UTC-7, Michael 'AppleWin Debugger Dev'
>>
>>> Is there a known way to do this, to force black and white mode even on a color monitor?
>>
>> Not that I'm aware of.
>>
>> Michael
>
>
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: cycle-counting in textmode [message #374281 is a reply to message #374202] |
Tue, 02 October 2018 20:44 |
|
|
Originally posted by: Du Hast
On Sunday, September 30, 2018 at 3:32:37 PM UTC-4, vi...@pianoman.cluster.toy wrote:
> Is there a known way to do this, to force black and white
> mode even on a color monitor?
>
> Vince
On the Apple Color Composite monitor there was a switch by the contrast/etc. knobs that would force into black and white. Great for finding the secret doors in Ultimas...
|
|
|
|
Members
Search
Help
Register
Login
Home
