Is there a simple Applesoft like BASIC that can produce lines, plot points on the GS SHGR screens?

[Doug Dingus]

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.

Maybe I should just run a paint program?

All I want to do right now is plot some pixels and lines.

How is this kind of thing usually done?

[fadden]

Post by Doug Dingus
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, ...).

[Antoine Vignau]

Yes, it is Iconix by So What Software. Get it at https://www.whatisthe2gs.apple2.org.za/iconix.html

Antoine

[Doug Dingus]

Post by Antoine Vignau
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...

[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.

Post by Antoine Vignau
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...

[Michael J. Mahon]

Post 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.

Post by Antoine Vignau
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.

[Doug Dingus]

Post by Michael J. Mahon

Post 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.

Post by Antoine Vignau
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.

[Doug Dingus]

I happened to do a search just now and ran into this:

https://github.com/dschmenk/SHR-NTSC/blob/master/Artifact%20Colors:%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.

Post by Michael J. Mahon

Post 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.

Post by Antoine Vignau
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

[Michael J. Mahon]

Post by Doug Dingus
https://github.com/dschmenk/SHR-NTSC/blob/master/Artifact%20Colors:%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.

Post by Michael J. Mahon

Post 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.

Post by Antoine Vignau
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.

[Doug Dingus]

Post by Michael J. Mahon

Post by Doug Dingus
https://github.com/dschmenk/SHR-NTSC/blob/master/Artifact%20Colors:%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.

Post by Michael J. Mahon

Post 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.

Post by Antoine Vignau
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.