is it possible to do color text and udg's in apple 2 basic? i.e text in high res graphics mode, etc
maybe it's usefull to view the site:
scroll down to section:
Programming Apple Graphics
there are several pages related to the topic...
please pay attention to the language flags at the end of the line
indicating the language of the contribution...
are any of these programs available as downloads?
Probably you did not look at the pages themselves ?
If the program is availiable as download it's
availiable at the link at the bottom of that page...
i did look at the pages. theres nothing there except a picture of a disk with no link and a pdf document
What is udg?
user definable graphics
Thanks for that: User Definable Graphics (UDG)
Anything is possible.
That doesn't mean it should be done.
You could use HPLOT statements, for example:
You could use DRAW statements with shape tables!
You could use one of the many HGR text character generators. A few of these do color. Here is a fairly recent tutorial by Michael Pohoreski:
are there any routines that do the hgr text generators that are in basic? also what address are the fonts stored at? or do u copy them from rom to ram and then call them?
ok, sorted it. i just wondered y the text comes out with weird colors? is the a way to change this?
i dont understand how the character sets r built up. they seem to b 16 bits long and 7 bits wide. is there somewhere where the color information goes?
> Are there any routines that do the hgr text generators that are in basic?
Maybe, but they might be very slow.
> Also what address are the fonts stored at?
That depends on the generator, and it could be uda -- a User Definable Address
> Do u copy them from rom to ram and then call them?
The TEXT ROM font is not accessible in memory from software. Just load them in to memory from disk, or make them udf -- User Definable Fonts
> i just wondered y the text comes out with weird colors?
That is the nature of HGR on the Apple II.
> is there a way to change this?
You can't change the hardware, but there are ways to display characters so that the colors show up better -- with caveats.
> i dont understand how the character sets r built up. they seem to b 16 bits long and 7 bits wide. is there somewhere where the color information goes?
A lot of the generators use fonts that are 8 pixels high x 7 pixels wide. Color depends on which method / generator you use. A very long time ago, I've used a font generator similar to Flex Type. Flex type might work better for you...
Set the font double wide, and you can set color.
many thanks for all the help btw...
whats a caveat? and how do i use these? and also i dont see a way to set the color of the font
> whats a caveat?
"A warning or caution; admonition."
... meaning that even though there are ways to display characters so that the colors show up better sometimes it doesn't work so well due to color bleed and just the way HGR works on the Apple II.
> and also i dont see a way to set the color of the font
You are right. I was surprised to see "Flex Type" isn't as flexible as it claimed to be. Maybe, there is a way to set colors, but I didn't see it. Maybe a different / newer version of Flex Type.
Anyways back in the 1980s, I think that I used "Higher Text" or "Higher Text II" or some version of these programs, as these HGR character generators can display double wide characters like Flex Type. The demo for "Higher Text II" shows double wide characters displayed in color. And double wide by double high characters can be displayed with alternating colors. There doesn't seem to be documentation for HIGHER TEXT about what the control codes are to set the colors, widths, and heights.
Here is what I gleaned, by dumping the hex in the monitor to see the codes using 4000.4080) from the demo Applesoft BASIC listing ...
Control+E = double high, double wide
Control+R = normal size
Control+L = CLEAR SCREEN
Control+C <number> = set color, you need to be in double wide for the color to work
Control+C 3 = set color to orange
Control+C 5 = set color to green
Control+C ... <= try some values in here to see what color you get.
You'll have to do a search for the "Higher Text II" dsk.
Back to posting #1:
Handling colors in HGR:
creating characters in HGR:
not to talk about the other contributions...
>The demo for "Higher Text II" shows double wide characters displayed in color. And double wide by double high characters can be displayed with alternating colors.
It's not surprising that color was limited to double-size characters, given the nature of the Apple II color system.
the777, it might be useful for you to read up in a bit more depth about how the color system works on the Apple II, as it sounds like you're more used to how other computers work. Wikipedia's article isn't terrible, and here's another article that gives an accessible introduction on how the Apple II plays strange games with NTSC color encoding to achieve color with very limited hardware. To cut to the chase: the Apple II can't apply a solid color other than black or white to every arbitrary pixel on the screen; the minimum size of a color spot on the Apple II's screen is two pixels wide, with the color itself being the result of how the TV interprets the interaction between the phase of the color carrier and the monochrome dot pattern it receives from the pixel output shift register.
Here's a PDF explaining how it works in more depth, and also explains why the Apple II uses the 8th bit in a byte of video memory to shift a pixel row over half a clock to achieve additional colors; the original Apple II motherboard revisions lack this ability.
In essence, what it all adds up to is the effective solid-color resolution of an Apple II is only 140x192, not 280x192, and there are additional limits that crop up when trying to place two different color dots adjacent to each other. (And this is also why if you draw characters not taking this into account, like approximations of the normal 7x8 pixel character glyphs, you get those weird color fringes and interference patterns; if the colorburst signal is enabled depending on where a dot is placed on the screen it might be interpreted as part of a color group instead of a single white or black pixel even when you don't want it to.) To create a clean, solid-color character the glyph will have to be written as the proper *pattern* of monochrome dots at the correct starting interval on the scanline, and the requirement that a "colorized" pixel is 2 mono dots wide means that you're not going to be able to squeeze more than 20 or so characters per line. (If you take some liberties you might be able to push that to, I dunno, maybe 28?, using 5 pixel wide character cells, which is about the limit before letters get pretty distorted.)
Obviously this is confusing compared to a computer that uses real "solid" colors with RGB modeling for pixel generation, but getting six color 280x192 graphics that way would have required at least three times the video RAM.