|
|
| Re: Is there a simple Applesoft like BASIC that can produce lines, plot points on the GS SHGR screens? [message #400435 is a reply to message #400430] |
Wed, 23 September 2020 11:11   |
|
|
Originally posted by: fadden
On Wednesday, September 23, 2020 at 4:12:14 AM UTC-7, doug....@gmail.com wrote:
> I was looking to create a few simple graphics like one would on the non GS graphics displays and was unable to find anything simple, low overhead, speed is not important.
Once upon a time, I threw together something that used the QuickDraw toolbox from Applesoft ("AmperQD", https://fadden.com/apple2/misc.html#amperqd). IIRC it only works if you boot directly into ProDOS 8 (i.e. don't boot GS/OS first), and is generally rather unstable. But it might serve your needs..
A better approach would be to use a IIgs language, perhaps one of the BASICs (TML, Micol, GSoft, ...).
|
|
|
|
|
|
| Re: Is there a simple Applesoft like BASIC that can produce lines, plot points on the GS SHGR screens? [message #400456 is a reply to message #400454] |
Wed, 23 September 2020 18:07 |
|
|
Originally posted by: Doug Dingus
On Wednesday, September 23, 2020 at 2:18:00 PM UTC-7, ntn.v...@gmail.com wrote:
> Yes, it is Iconix by So What Software. Get it at https://www.whatisthe2gs..apple2.org.za/iconix.html
>
> Antoine
Thanks! I got the image and will fire it up. Really, I am into CRT displays and such right now and just want some simple "programmer", "tester" type graphics to understand what I'm seeing better.
Re: GS Languages
I saw those and really didn't want to wade into the QuickDraw environment at this time. I was about to just write a little '816 routine to turn the screen on and drop values into RAM and call it good. Maybe later I can revisit QuickDraw. I've never used it.
My machine is a ROM 1, I think. 256Mb style GS. It had a Transporter card in it, and a partially populated 1Mb memory expansion. Not enough to run most recent GS OS at this time. For now, I want to basically tinker with it some, maybe do some '816 programming, etc...
|
|
|
|
| Re: Is there a simple Applesoft like BASIC that can produce lines, plot points on the GS SHGR screens? [message #400793 is a reply to message #400456] |
Sun, 04 October 2020 23:10 |
|
|
Originally posted by: Doug Dingus
Thanks Antoine!
Iconix was exactly the thing I needed. I wanted to take a quick look at the GS through it's composite video output. Apple has the pixel clock just a shade off from being aligned with the NTSC color cycle. The little color sample program did what I was looking to do quick and easy.
I have had fun and often great results doing artifact color on every machine I've gotten hold of. Was hoping the GS was more like the CoCo 3, where on that machine the 640 pixel mode, with the palette set to black, white and two greys, will deliver a nice, 8bpp color screen, one byte per pixel. Programming that machine, in this way, is a lot of fun. Simple bytes makes things easy.
The GS will do the pixels and palette, but the alignment is just a shade off, which gives a rainbow effect for some combinations, and a varying hue effect on many others.
Now my curiosity is satisfied quick and easy. Wanted to take a peek at this one for a long time.
Thank you again.
On Wednesday, September 23, 2020 at 3:07:09 PM UTC-7, Doug Dingus wrote:
> On Wednesday, September 23, 2020 at 2:18:00 PM UTC-7, ntn.v...@gmail.com wrote:
>> Yes, it is Iconix by So What Software. Get it at https://www.whatisthe2gs.apple2.org.za/iconix.html
>>
>> Antoine
> Thanks! I got the image and will fire it up. Really, I am into CRT displays and such right now and just want some simple "programmer", "tester" type graphics to understand what I'm seeing better.
>
> Re: GS Languages
>
> I saw those and really didn't want to wade into the QuickDraw environment at this time. I was about to just write a little '816 routine to turn the screen on and drop values into RAM and call it good. Maybe later I can revisit QuickDraw. I've never used it.
>
> My machine is a ROM 1, I think. 256Mb style GS. It had a Transporter card in it, and a partially populated 1Mb memory expansion. Not enough to run most recent GS OS at this time. For now, I want to basically tinker with it some, maybe do some '816 programming, etc...
|
|
|
|
| Re: Is there a simple Applesoft like BASIC that can produce lines, plot points on the GS SHGR screens? [message #400871 is a reply to message #400793] |
Wed, 07 October 2020 17:01 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
Doug Dingus <doug.dingus@gmail.com> wrote:
> Thanks Antoine!
>
> Iconix was exactly the thing I needed. I wanted to take a quick look at
> the GS through it's composite video output. Apple has the pixel clock
> just a shade off from being aligned with the NTSC color cycle. The
> little color sample program did what I was looking to do quick and easy.
>
> I have had fun and often great results doing artifact color on every
> machine I've gotten hold of. Was hoping the GS was more like the CoCo 3,
> where on that machine the 640 pixel mode, with the palette set to black,
> white and two greys, will deliver a nice, 8bpp color screen, one byte per
> pixel. Programming that machine, in this way, is a lot of fun. Simple
> bytes makes things easy.
>
> The GS will do the pixels and palette, but the alignment is just a shade
> off, which gives a rainbow effect for some combinations, and a varying
> hue effect on many others.
>
> Now my curiosity is satisfied quick and easy. Wanted to take a peek at
> this one for a long time.
>
> Thank you again.
>
>
> On Wednesday, September 23, 2020 at 3:07:09 PM UTC-7, Doug Dingus wrote:
>> On Wednesday, September 23, 2020 at 2:18:00 PM UTC-7, ntn.v...@gmail.com wrote:
>>> Yes, it is Iconix by So What Software. Get it at
>>> https://www.whatisthe2gs.apple2.org.za/iconix.html
>>>
>>> Antoine
>> Thanks! I got the image and will fire it up. Really, I am into CRT
>> displays and such right now and just want some simple "programmer",
>> "tester" type graphics to understand what I'm seeing better.
>>
>> Re: GS Languages
>>
>> I saw those and really didn't want to wade into the QuickDraw
>> environment at this time. I was about to just write a little '816
>> routine to turn the screen on and drop values into RAM and call it good.
>> Maybe later I can revisit QuickDraw. I've never used it.
>>
>> My machine is a ROM 1, I think. 256Mb style GS. It had a Transporter
>> card in it, and a partially populated 1Mb memory expansion. Not enough
>> to run most recent GS OS at this time. For now, I want to basically
>> tinker with it some, maybe do some '816 programming, etc...
>
Unlike the 8-bit Apple II’s, the composite video output of the IIgs is not
a directly generated digital signal.
The IIgs is a natively RGB machine, and the composite video is generated by
an MC1377 RGB-to-NTSC converter chip. In the non-SHR modes, the typical
Apple video signal is first processed by a built-in RGB “card”, whose
output is then converted *back* to composite by the MC1377.
This causes the composite output for traditional HGR modes to be subject to
two sequential sources of error: first, the digital video to RGB
conversion, which always fails to convert the subtle artifacts in pursuit
of “sharpness”, and second, the chroma matrixing of the MC1377.
There is no way the pixel clock of the traditional modes can be off in
frequency, since all signals are directly derived from the master
oscillator at 14.3818MHz, exactly 4x the NTSC color reference frequency.
The exact phases of the pixel pulses relative to this reference are
determined by shifting out four bits per subcarrier cycle, so their
relative phases are also “baked in”.
Of course, no crystal oscillator is precisely on frequency, but it will be
well within the chroma lock range for any monitor designed to accommodate
the standard subcarrier frequency tolerance.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: Is there a simple Applesoft like BASIC that can produce lines, plot points on the GS SHGR screens? [message #400901 is a reply to message #400871] |
Thu, 08 October 2020 18:47 |
|
|
Originally posted by: Doug Dingus
On Wednesday, October 7, 2020 at 2:01:58 PM UTC-7, Michael J. Mahon wrote:
> Doug Dingus <doug....@gmail.com> wrote:
>> Thanks Antoine!
>>
>> Iconix was exactly the thing I needed. I wanted to take a quick look at
>> the GS through it's composite video output. Apple has the pixel clock
>> just a shade off from being aligned with the NTSC color cycle. The
>> little color sample program did what I was looking to do quick and easy..
>>
>> I have had fun and often great results doing artifact color on every
>> machine I've gotten hold of. Was hoping the GS was more like the CoCo 3,
>> where on that machine the 640 pixel mode, with the palette set to black,
>> white and two greys, will deliver a nice, 8bpp color screen, one byte per
>> pixel. Programming that machine, in this way, is a lot of fun. Simple
>> bytes makes things easy.
>>
>> The GS will do the pixels and palette, but the alignment is just a shade
>> off, which gives a rainbow effect for some combinations, and a varying
>> hue effect on many others.
>>
>> Now my curiosity is satisfied quick and easy. Wanted to take a peek at
>> this one for a long time.
>>
>> Thank you again.
>>
>>
>> On Wednesday, September 23, 2020 at 3:07:09 PM UTC-7, Doug Dingus wrote:
>>> On Wednesday, September 23, 2020 at 2:18:00 PM UTC-7, ntn.v...@gmail.com wrote:
>>>> Yes, it is Iconix by So What Software. Get it at
>>>> https://www.whatisthe2gs.apple2.org.za/iconix.html
>>>>
>>>> Antoine
>>> Thanks! I got the image and will fire it up. Really, I am into CRT
>>> displays and such right now and just want some simple "programmer",
>>> "tester" type graphics to understand what I'm seeing better.
>>>
>>> Re: GS Languages
>>>
>>> I saw those and really didn't want to wade into the QuickDraw
>>> environment at this time. I was about to just write a little '816
>>> routine to turn the screen on and drop values into RAM and call it good.
>>> Maybe later I can revisit QuickDraw. I've never used it.
>>>
>>> My machine is a ROM 1, I think. 256Mb style GS. It had a Transporter
>>> card in it, and a partially populated 1Mb memory expansion. Not enough
>>> to run most recent GS OS at this time. For now, I want to basically
>>> tinker with it some, maybe do some '816 programming, etc...
>>
> Unlike the 8-bit Apple II’s, the composite video output of the IIgs is not
> a directly generated digital signal.
>
> The IIgs is a natively RGB machine, and the composite video is generated by
> an MC1377 RGB-to-NTSC converter chip. In the non-SHR modes, the typical
> Apple video signal is first processed by a built-in RGB “card”, whose
> output is then converted *back* to composite by the MC1377.
>
> This causes the composite output for traditional HGR modes to be subject to
> two sequential sources of error: first, the digital video to RGB
> conversion, which always fails to convert the subtle artifacts in pursuit
> of “sharpness”, and second, the chroma matrixing of the MC1377.
>
> There is no way the pixel clock of the traditional modes can be off in
> frequency, since all signals are directly derived from the master
> oscillator at 14.3818MHz, exactly 4x the NTSC color reference frequency.
> The exact phases of the pixel pulses relative to this reference are
> determined by shifting out four bits per subcarrier cycle, so their
> relative phases are also “baked in”.
>
> Of course, no crystal oscillator is precisely on frequency, but it will be
> well within the chroma lock range for any monitor designed to accommodate
> the standard subcarrier frequency tolerance.
>
> --
> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
I didn't look at the DHGR and below modes as I have an //e for that. :D
Let me put it this way, had the GS spread those pixels out just a little more, they would fall right on color clock period boundaries.
Another way to say it would be a slightly wider screen display, or fewer pixels in the current active display area would have made the composite display, in GS modes, much better.
Looks for all the world to me, and I've not put a scope on the machine just a quick look by eye, like the 640 pixels got packed into the same portion of the active scanline as the 560 pixels from the //e currently occupy. This, of course, matches all the monitor settings, and such. But, was aggressive for composite. It will generally work, but not work all that well.
I've done similar things with my own signals over composite, and one can see similar things happen with one of those processors that can scale an image, for example.
|
|
|
|
| Re: Is there a simple Applesoft like BASIC that can produce lines, plot points on the GS SHGR screens? [message #400907 is a reply to message #400871] |
Thu, 08 October 2020 18:59 |
|
|
Originally posted by: Doug Dingus
I happened to do a search just now and ran into this:
https://github.com/dschmenk/SHR-NTSC/blob/master/Artifact%20 Colors:%20TNG.pdf
640 SHR pixels crammed into same space as 560 DHGR pixels, meaning 4.5714.... pixels / chroma cycle.
So yeah, by eye matched up. It's an uneven number of pixels per chroma cycle, which explains the banding and general level of composite error seen on the GS.
On Wednesday, October 7, 2020 at 2:01:58 PM UTC-7, Michael J. Mahon wrote:
> Doug Dingus <doug....@gmail.com> wrote:
>> Thanks Antoine!
>>
>> Iconix was exactly the thing I needed. I wanted to take a quick look at
>> the GS through it's composite video output. Apple has the pixel clock
>> just a shade off from being aligned with the NTSC color cycle. The
>> little color sample program did what I was looking to do quick and easy..
>>
>> I have had fun and often great results doing artifact color on every
>> machine I've gotten hold of. Was hoping the GS was more like the CoCo 3,
>> where on that machine the 640 pixel mode, with the palette set to black,
>> white and two greys, will deliver a nice, 8bpp color screen, one byte per
>> pixel. Programming that machine, in this way, is a lot of fun. Simple
>> bytes makes things easy.
>>
>> The GS will do the pixels and palette, but the alignment is just a shade
>> off, which gives a rainbow effect for some combinations, and a varying
>> hue effect on many others.
>>
>> Now my curiosity is satisfied quick and easy. Wanted to take a peek at
>> this one for a long time.
>>
>> Thank you again.
>>
>>
>> On Wednesday, September 23, 2020 at 3:07:09 PM UTC-7, Doug Dingus wrote:
>>> On Wednesday, September 23, 2020 at 2:18:00 PM UTC-7, ntn.v...@gmail.com wrote:
>>>> Yes, it is Iconix by So What Software. Get it at
>>>> https://www.whatisthe2gs.apple2.org.za/iconix.html
>>>>
>>>> Antoine
>>> Thanks! I got the image and will fire it up. Really, I am into CRT
>>> displays and such right now and just want some simple "programmer",
>>> "tester" type graphics to understand what I'm seeing better.
>>>
>>> Re: GS Languages
>>>
>>> I saw those and really didn't want to wade into the QuickDraw
>>> environment at this time. I was about to just write a little '816
>>> routine to turn the screen on and drop values into RAM and call it good.
>>> Maybe later I can revisit QuickDraw. I've never used it.
>>>
>>> My machine is a ROM 1, I think. 256Mb style GS. It had a Transporter
>>> card in it, and a partially populated 1Mb memory expansion. Not enough
>>> to run most recent GS OS at this time. For now, I want to basically
>>> tinker with it some, maybe do some '816 programming, etc...
>>
> Unlike the 8-bit Apple II’s, the composite video output of the IIgs is not
> a directly generated digital signal.
>
> The IIgs is a natively RGB machine, and the composite video is generated by
> an MC1377 RGB-to-NTSC converter chip. In the non-SHR modes, the typical
> Apple video signal is first processed by a built-in RGB “card”, whose
> output is then converted *back* to composite by the MC1377.
>
> This causes the composite output for traditional HGR modes to be subject to
> two sequential sources of error: first, the digital video to RGB
> conversion, which always fails to convert the subtle artifacts in pursuit
> of “sharpness”, and second, the chroma matrixing of the MC1377.
>
> There is no way the pixel clock of the traditional modes can be off in
> frequency, since all signals are directly derived from the master
> oscillator at 14.3818MHz, exactly 4x the NTSC color reference frequency.
> The exact phases of the pixel pulses relative to this reference are
> determined by shifting out four bits per subcarrier cycle, so their
> relative phases are also “baked in”.
>
> Of course, no crystal oscillator is precisely on frequency, but it will be
> well within the chroma lock range for any monitor designed to accommodate
> the standard subcarrier frequency tolerance.
>
> --
> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: Is there a simple Applesoft like BASIC that can produce lines, plot points on the GS SHGR screens? [message #400983 is a reply to message #400907] |
Sun, 11 October 2020 10:54 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
Doug Dingus <doug.dingus@gmail.com> wrote:
> I happened to do a search just now and ran into this:
>
> https://github.com/dschmenk/SHR-NTSC/blob/master/Artifact%20 Colors:%20TNG.pdf
>
> 640 SHR pixels crammed into same space as 560 DHGR pixels, meaning
> 4.5714... pixels / chroma cycle.
>
> So yeah, by eye matched up. It's an uneven number of pixels per chroma
> cycle, which explains the banding and general level of composite error seen on the GS.
>
>
>
> On Wednesday, October 7, 2020 at 2:01:58 PM UTC-7, Michael J. Mahon wrote:
>> Doug Dingus <doug....@gmail.com> wrote:
>>> Thanks Antoine!
>>>
>>> Iconix was exactly the thing I needed. I wanted to take a quick look at
>>> the GS through it's composite video output. Apple has the pixel clock
>>> just a shade off from being aligned with the NTSC color cycle. The
>>> little color sample program did what I was looking to do quick and easy.
>>>
>>> I have had fun and often great results doing artifact color on every
>>> machine I've gotten hold of. Was hoping the GS was more like the CoCo 3,
>>> where on that machine the 640 pixel mode, with the palette set to black,
>>> white and two greys, will deliver a nice, 8bpp color screen, one byte per
>>> pixel. Programming that machine, in this way, is a lot of fun. Simple
>>> bytes makes things easy.
>>>
>>> The GS will do the pixels and palette, but the alignment is just a shade
>>> off, which gives a rainbow effect for some combinations, and a varying
>>> hue effect on many others.
>>>
>>> Now my curiosity is satisfied quick and easy. Wanted to take a peek at
>>> this one for a long time.
>>>
>>> Thank you again.
>>>
>>>
>>> On Wednesday, September 23, 2020 at 3:07:09 PM UTC-7, Doug Dingus wrote:
>>>> On Wednesday, September 23, 2020 at 2:18:00 PM UTC-7, ntn.v...@gmail.com wrote:
>>>> > Yes, it is Iconix by So What Software. Get it at
>>>> > https://www.whatisthe2gs.apple2.org.za/iconix.html
>>>> >
>>>> > Antoine
>>>> Thanks! I got the image and will fire it up. Really, I am into CRT
>>>> displays and such right now and just want some simple "programmer",
>>>> "tester" type graphics to understand what I'm seeing better.
>>>>
>>>> Re: GS Languages
>>>>
>>>> I saw those and really didn't want to wade into the QuickDraw
>>>> environment at this time. I was about to just write a little '816
>>>> routine to turn the screen on and drop values into RAM and call it good.
>>>> Maybe later I can revisit QuickDraw. I've never used it.
>>>>
>>>> My machine is a ROM 1, I think. 256Mb style GS. It had a Transporter
>>>> card in it, and a partially populated 1Mb memory expansion. Not enough
>>>> to run most recent GS OS at this time. For now, I want to basically
>>>> tinker with it some, maybe do some '816 programming, etc...
>>>
>> Unlike the 8-bit Apple II’s, the composite video output of the IIgs is not
>> a directly generated digital signal.
>>
>> The IIgs is a natively RGB machine, and the composite video is generated by
>> an MC1377 RGB-to-NTSC converter chip. In the non-SHR modes, the typical
>> Apple video signal is first processed by a built-in RGB “card”, whose
>> output is then converted *back* to composite by the MC1377.
>>
>> This causes the composite output for traditional HGR modes to be subject to
>> two sequential sources of error: first, the digital video to RGB
>> conversion, which always fails to convert the subtle artifacts in pursuit
>> of “sharpness”, and second, the chroma matrixing of the MC1377.
>>
>> There is no way the pixel clock of the traditional modes can be off in
>> frequency, since all signals are directly derived from the master
>> oscillator at 14.3818MHz, exactly 4x the NTSC color reference frequency.
>> The exact phases of the pixel pulses relative to this reference are
>> determined by shifting out four bits per subcarrier cycle, so their
>> relative phases are also “baked in”.
>>
>> Of course, no crystal oscillator is precisely on frequency, but it will be
>> well within the chroma lock range for any monitor designed to accommodate
>> the standard subcarrier frequency tolerance.
>>
>> --
>> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
>
You are correct. The SHR modes use a different pixel clock, unrelated to
the NTSC color subcarrier frequency. This is fine for native RGB displays,
but leads to unusual results when encoded as composite video.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: Is there a simple Applesoft like BASIC that can produce lines, plot points on the GS SHGR screens? [message #400989 is a reply to message #400983] |
Sun, 11 October 2020 16:33 |
|
|
Originally posted by: Doug Dingus
On Sunday, October 11, 2020 at 7:55:01 AM UTC-7, Michael J. Mahon wrote:
> Doug Dingus <doug....@gmail.com> wrote:
>> I happened to do a search just now and ran into this:
>>
>> https://github.com/dschmenk/SHR-NTSC/blob/master/Artifact%20 Colors:%20TNG.pdf
>>
>> 640 SHR pixels crammed into same space as 560 DHGR pixels, meaning
>> 4.5714... pixels / chroma cycle.
>>
>> So yeah, by eye matched up. It's an uneven number of pixels per chroma
>> cycle, which explains the banding and general level of composite error seen on the GS.
>>
>>
>>
>> On Wednesday, October 7, 2020 at 2:01:58 PM UTC-7, Michael J. Mahon wrote:
>>> Doug Dingus <doug....@gmail.com> wrote:
>>>> Thanks Antoine!
>>>>
>>>> Iconix was exactly the thing I needed. I wanted to take a quick look at
>>>> the GS through it's composite video output. Apple has the pixel clock
>>>> just a shade off from being aligned with the NTSC color cycle. The
>>>> little color sample program did what I was looking to do quick and easy.
>>>>
>>>> I have had fun and often great results doing artifact color on every
>>>> machine I've gotten hold of. Was hoping the GS was more like the CoCo 3,
>>>> where on that machine the 640 pixel mode, with the palette set to black,
>>>> white and two greys, will deliver a nice, 8bpp color screen, one byte per
>>>> pixel. Programming that machine, in this way, is a lot of fun. Simple
>>>> bytes makes things easy.
>>>>
>>>> The GS will do the pixels and palette, but the alignment is just a shade
>>>> off, which gives a rainbow effect for some combinations, and a varying
>>>> hue effect on many others.
>>>>
>>>> Now my curiosity is satisfied quick and easy. Wanted to take a peek at
>>>> this one for a long time.
>>>>
>>>> Thank you again.
>>>>
>>>>
>>>> On Wednesday, September 23, 2020 at 3:07:09 PM UTC-7, Doug Dingus wrote:
>>>> > On Wednesday, September 23, 2020 at 2:18:00 PM UTC-7, ntn.v...@gmail..com wrote:
>>>> >> Yes, it is Iconix by So What Software. Get it at
>>>> >> https://www.whatisthe2gs.apple2.org.za/iconix.html
>>>> >>
>>>> >> Antoine
>>>> > Thanks! I got the image and will fire it up. Really, I am into CRT
>>>> > displays and such right now and just want some simple "programmer",
>>>> > "tester" type graphics to understand what I'm seeing better.
>>>> >
>>>> > Re: GS Languages
>>>> >
>>>> > I saw those and really didn't want to wade into the QuickDraw
>>>> > environment at this time. I was about to just write a little '816
>>>> > routine to turn the screen on and drop values into RAM and call it good.
>>>> > Maybe later I can revisit QuickDraw. I've never used it.
>>>> >
>>>> > My machine is a ROM 1, I think. 256Mb style GS. It had a Transporter
>>>> > card in it, and a partially populated 1Mb memory expansion. Not enough
>>>> > to run most recent GS OS at this time. For now, I want to basically
>>>> > tinker with it some, maybe do some '816 programming, etc...
>>>>
>>> Unlike the 8-bit Apple II’s, the composite video output of the IIgs is not
>>> a directly generated digital signal.
>>>
>>> The IIgs is a natively RGB machine, and the composite video is generated by
>>> an MC1377 RGB-to-NTSC converter chip. In the non-SHR modes, the typical
>>> Apple video signal is first processed by a built-in RGB “card”, whose
>>> output is then converted *back* to composite by the MC1377.
>>>
>>> This causes the composite output for traditional HGR modes to be subject to
>>> two sequential sources of error: first, the digital video to RGB
>>> conversion, which always fails to convert the subtle artifacts in pursuit
>>> of “sharpness”, and second, the chroma matrixing of the MC1377.
>>>
>>> There is no way the pixel clock of the traditional modes can be off in
>>> frequency, since all signals are directly derived from the master
>>> oscillator at 14.3818MHz, exactly 4x the NTSC color reference frequency.
>>> The exact phases of the pixel pulses relative to this reference are
>>> determined by shifting out four bits per subcarrier cycle, so their
>>> relative phases are also “baked in”.
>>>
>>> Of course, no crystal oscillator is precisely on frequency, but it will be
>>> well within the chroma lock range for any monitor designed to accommodate
>>> the standard subcarrier frequency tolerance.
>>>
>>> --
>>> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
>>
> You are correct. The SHR modes use a different pixel clock, unrelated to
> the NTSC color subcarrier frequency. This is fine for native RGB displays,
> but leads to unusual results when encoded as composite video.
> --
> -michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
His presentation and static images were impressive though! Nice work on a tough problem.
I am going to get a cable and run my GS in RGB. Play a few games I missed out on.
A PAL GS may perform significantly better over composite due to the much closer alignment with color cycles.
|
|
|
|
Members
Search
Help
Register
Login
Home
