I connected my Apple IIe to a color TV. Why are the colors not clear, but they appear rainbow?
Thank you
G
Anonymous
User login
Please support the defense of Ukraine.
Direct or via Unclutter App
Active forum topics
Recent content
Navigation
No Ads.
No Trackers.
No Social Media.
All Content Locally Hosted.
Built on Free Software.
We have complied with zero government requests for information.
Your description is a bit vague, a picture may help show exactly what you are seeing. But also keep in mind that Woz sort of abused the NTSC standard when he designed the A2 composite signal. It works well with old CRTs, but newer LCD TVs may have issues decoding the slightly off spec signal. Trying a different TV you may see different/better results.
My Apple IIe is in PAL standard. The color TV is an old Sony 14 "CRT. I tried connecting a PAL Commodore 1084 color monitor (Philips branded) and the games show in grayscale.) Maybe the video output of my Apple IIe is monochrome?
On the PAL IIe, I believe there is a a color/mono switch in the motherboard. Did you confirm yours is set to color?
I thought you needed a PAL card in slot 7 to get color? Or is that only on Europlus? I don't know a lot about the European models since they are very rarely ever seen over here.
No, you are thinking of Europlus, which is an Apple II+. The European Apple IIe has the PAL card built straight into the motherboard.
I have the same problem with my Apple IIe in text mode with a 14" Sony Trinitron TV, model KV-14T1R. I also have a 14" JVC model C-F14EE, but it never happens on it. Both of these 14" CRT TVs from the 90s support PAL and NTSC and are great for European Apple II enthusiasts. The JVC even supports NTSC50 and is the most forgiving in terms of standards.
So, here is the problem on the Sony: when I first turn it on the picture looks like this:
IMG_5372.JPG
But sometimes if I wait a little, it just corects itself:
IMG_5374.JPG
The problem is not that the color burst killer circuit is not working - I checked with my osciloscope and there is no color burst in text mode. The signal level is just too high and I think the TV detects the remnants of the color burst.
I had the same problem with this TV on my NTSC Apple II+ and fixed it by reducing the signal level from the potentiometer on the Apple II+ motherboard. However I don't know how to reduce it on the Apple IIe, since there is no potentiometer. Also I can tell the signal level it too high, since the brightness is almost at a minimum.
There is no problem in color mode, but I can still tell that the signal level is too high just from the brightness:
IMG_5367.JPG
IMG_5364.JPG
With my Sony TV I only get the view as in the first image you showed me and with the passage of time nothing changes. With the 1084 color monitor I loaded Draw Poker and I see it in grayscale
If you don't see Draw Poker in color on the Sony it means your SW1 on the right side of the motherboard is set to Mono (the ON position). You need to switch it to Colour (the OFF position):
IMG_5382.JPG
If you see Draw Poker in color on the Sony, but not on the other monitor, the other monitor probably doesn't support PAL.
I found the switch and the problem is solved.
Thank you very much
G.
Edit:
With Sony TV white text characters on the screen always appear with shades of color, while with a game, the colors, it seems to be appear quite well. With the Commmodore CRT monitor, the white text characters and color characters appear much better in every case.
Yes, the Sony doesn't like this 1.3 Vpp plugged in, which is way outside the specified 1.0 Vpp for PAL. I just don't know why the Apple IIe doesn't have a potentiometer to regulate it, like the Apple II+ does.
Newfile1.png
It can be easily fixed by putting a potentiometer on the video output to act as a voltage divider.
I would have thought of making an RCA cable by inserting a potentiometer / trimmer in the cable itself in order to attenuate the incoming signal on the Sony TV. If anything, I would need the range and type of potentiometer / trimmer to use, how many KOhm and if it must be linear or logarithmic, in this specific case.
100 ohm potentiometer in a voltage divider configuration works fine. It should be linear, and it will be better if it's multiturn. You have to find the sweet spot - if you lower it too much the picture will start bending. Other values for the potentiometer will work as well, but this is the one I found in my spare parts.
Btw for double high-res on a monochrome CRT it needs to be switched back to MONO. I am thinking to somehow externalize this switch.
A2Desktop.jpg
Related, but only slightly... does anyone know exactly how the //e composite is out of spec for NTSC? It's bad enough that TVs can't always display the picture. I'm not sure if it's a sync timing, or something else slightly "off". But it's also fairly easy to correct if you run the //e out though a VCR which always had much better input signal processing the VCR output should display better on a TV.
@CVT: The "too bright" I don't think the //e luma output was conditioned for the "safe" range of TV displays. At least with NTSC there idea of "full range" and NTSC "safe range" basically clamp the singal to a ceiling (white @ 100IRE ) and floor (black @ 7.5IRE) so as to stay in this "safe" range. But AFAIK, while PAL has a similar white ceiling of 100IRE the black floor is at 0 IRE. So if the //e white exceeds 100IRE that could explain the over bright image. Computer monitors were designed for the computer signals and TVs were designed for broadcast signals and the two are different. Your II desktop looks awesome! Is that a different display than the one showing TR earlier?
There are lots of technical deviations from the NTSC standards in the Apple II video. Not the least of which is the use of progressive rather than interlaced scanning. But use of a VCR to "clean" the signal was always a good option.
As for the level of the video signal, it's a shame that Apple removed the adjustment pot found in the original Apple II. I also wonder if the TV display used properly terminates the video input. The Apple video out signal is meant to feed a 75 ohm input impedance. Many monitors of the time had a "termination" switch to select either 75 ohm or high impedance (so you could loop the video into another device). Most TV's lacked this feature and were somewhat iffy as to what impedance they presented an the Video Input jack. I'm not sure under what condtions the scope signals shown above were taken. I suspect that the Apple video was just fed into the scope (without terminating) and thus I would expect the level to be greater than 1.0 V P-to-P.
Yep, I think this is what's happening as well and it would explain why the potentiometer hack fixes it.
The picture of A2Desktop above is from this bulgarian BW monitor from the early 80s called VKP-170:
VKP170.JPG
As long as the VCR would keep it progressive and not turn it into interlaced, which would really suck.
The screen capture of the oscillogram above was taken while the Apple IIe was connected to the Sony Trinitron TV as it was displaying some text. I always use a T-connector to connect my oscilloscope, so the signal is terminated by the TV itself while it's on. Below is the signal of a cheap chinese PAL <=> NTSC converted, which I often use for its color bar pattern. This converter only produces interlaced signal and does a bad job when converting on top of that, so it's not useful for fixing the signal for a CRT TV.
BarPattern.JPG
I tried putting the potentiometer on the cable, the signal is attenuated overall, but the rainbow effect and character flickering remain.
Did you connect it as a voltage divider (pin 1: common ground, pin 2: output, pin 3: input)?
For me it worked, but it took some fine tuning of the potentiometer. The sweet spot is when pin 2 is about 70 ohms from pin 1. Also then I turn on the computer after it has been off for a while it doesn't work right away and I have to wait about 10 seconds.
Yes
In text mode running ProDOS it seems that the image is sharp, even if the brightness is low, while if I run a game or A2DeskTop I get a blurry image with the rainbow effect with fluid or wave moving characters and graphics.
Looks like you have lowered the level of the video signal way too much. It only needs to be lowered by about 25%.
As I already mention above, for A2Desktop to be sharp you need to turn off color from the switch on the motherboard and use a monochrome monitor. If you are getting waves that move vertically when displaying color graphics on a PAL color TV or monitor, you need to adjust the trimmer capacitor C112 on the motherboard until they go away.
I'm assuming you know the rainbow aliasing is normal for mixed graphics and graphics modes. There's usually no getting around that. But if that's understood, have you tried a different (i.e. better) composite cable? One of the problems with the "comes with ever video device" cables is they are crap and also not sheilded well. The result of bad shielding (especially in high "RF noise" locations) is things like you describe, wavy images or unstable pixels or dots jumping around on the screen. The wave can also be related to grounding (ie not properly grounded power) or ground loops, it all depends on exactly what you're seeing.
I managed with the potentiometer on the cable and with the adjustment of the C112 to obtain a satisfactory result, also considering the limits of the Sony monitor, the vertical waves are much more attenuated. The Sony monitor has the same defect for me that it had for you, in the sense that sometimes you turn it on and it gives the problem, then waiting a few seconds the signal adjusts itself. Sometimes you just need to turn your Sony monitor on and off to work fine.
So A2DeskTop can only be used with a monochrome monitor?
No, it works with any monitor. However if you are using a color monitor or TV, you need to set SW1 to COLOUR, and if you are using a BW monitor you need to set it to MONO. Otherwise A2Desktop looks really bad.
IMG_5382.JPG
This switch can be flipped while the machine is on without any adverse effects, which is why I think it will be a good idea to make it external, or maybe even hook it up to the alternative character set switch under the keyboard.
As far as the sharpness is concerned, the standard resolution CRT color monitors and TVs have a shadow mask or an aperture grille which limits the horizontal resolution. This is why they can't handle the 560x192 that A2Desktop uses as good as a monochrome CRT can.
I'm using my Sony color TV and SW1 on the Apple IIe is set to colour. Photos show what I get.
PRODOS.jpeg
A2DeskTop
A2DeskTop.jpeg
The color fringing in that doesn't look that abnormal for a composite video signal. The exact colors of the fringes must be a little different than what I'm used to since this is a PAL //e instead of NTSC which I'm used to.
This is as good as A2Desktop gets on a color CRT TV or monitor through composite video. If you want the Macintosh level of shapness, you have to get a monochrome CRT. :)
Here is my 14" Sony Trinitron for comparison: (All images are very high resolution, so open in a new tab to see them in full size.)
Sony Color.JPG
But for A2Desktop to get rid of the color artifacts, you can always dial down the color all the way to 0 from the TV's remote:
Sony BW.JPG
Here is the JVC for comparison. It doesn't look much better:
JVC.JPG
So you're telling me there's no decent way to display A2DeskTop in color taking advantage of the composite video signal?
Not on a CRT for sure. Composite just isn't great any way you look at it, and the way Apple II HIRES graphics work doesn't make it any better.
You may get better results with an RGB adapter.
But really, A2Desktop really isn't using color anyway, it's trying to look like a Mac, and at that time they were mostly monochrome.
So you're telling me that it's the graphical environment itself that wasn't designed in color? If so, it would be useless to use it on a color monitor.
But I ask, if A2DeskTop was designed in B/W, shouldn't I see it in B/W even on a color monitor? Maybe with an RGB adapter I could achieve this?
But why is there a "Desktop Pattern" box in the control panel with an RGB Color checkbox?
The Apple II doesn't really have a software control of the 'color killer' circuit in graphics modes. And even at that, it's often kind of under-achieving, especially on ][+ and more so the older the revision.
You're far from the first to complain about color fringing... look at old articles from the late 70s and early 80s.
The 560x192 resolution of the A2Desktop is the so-called "Double Hi-Res Graphics Mode" which is monochrome, because the Apple II only stores and reproduces 1 bit per pixel. When color is displayed, it does so by modifying the color of each pixel depending on its neighbors to the left and right.
http://lukazi.blogspot.com/2017/03/double-high-resolution-graphics-dhgr.html
I don't know for sure the function of the "RGB Color" checkbox, but the composite "artifact color" and RGB color do not use the same palette.
Yes, it was not designed for color. You can read this on their help page. Here they talk about how to turn off the color on various hardware: https://www.a2desktop.com/help
If you have a color TV with SCART input or an RGB monitor and if you get a really good RGB card, it will not show any color artifacts, but from what I've seen some of them fall short of that. However if it's a standard definition color TV, you are still left with the color CRT itself being physically unable to show clearly 560 horizontal pixels. So it might end up looking the same as what you have now with the color dialed down to 0 from the remote.
Now certain combination of vertical lines in double high resolution mode will produce solid colors on some color TVs/monitors through color artifacting. You can see these if you set the monitor in AppleWin to Composite Idealized:
A2DesktopColor.png
OK, now I'm curious to try RGB mode as soon as I can get hold of an adapter.
A2DeskTop, can only be run in high resolution and with an 80col card.?
Yes, A2Dektop requires double high resolution (560x192), which needs at least 128K RAM.
The only Macintosh-like program I have encountered that works on regular high resolution (280x192) is MousePaint, which even runs on the Apple II+ with just 64K RAM:
MousePaint.png
That's not correct, there's a way to kill color in software and it's documented in Don Lancaster's book. I recently found this book and shared with members of another group about the software VBI, and the discussion which followed came up with some interesting ideas. One of the members, Scott Elliott, put the discussion into practice and made some pretty cool screens. I belive these were created with a stock IIe.
298175242_10229398898181846_5956292841926954365_n.jpg
298337974_10229410085341518_7146909132747655164_n.jpg
297427047_10229410679916382_5148176656144755502_n.jpg
Here's the link to the book which generated the discussion:
Don Lancaster's Book on Archive.org
Can you post the link to the discussion itself? Also the link to the book is bad.
The previous poster is correct: the Apple II video logic generates COLOR BURST based only on the COLOR REF clock, TEXT MODE, and the horizontal timing signals. So the only control of color burst available to software is TEXT MODE ($C051).
Displaying graphics without color burst requires software to toggle the $C050 / $C051 switch twice on each horizontal line. I think that is what your third screenshot shows (the first two are not relevant to the subject). But the counters for the current screen location are not accessible in software: the only way to synchronize a program with a display location is to first fill the screen with special patterns and then read the floating data bus using soft switches, a technique described by Bob Bishop in Softalk in 1982: https://rich12345.tripod.com/aiivideo/softalk.html
Because the 1 MHz 6502 is so slow in relation to the video output, applications of this technique are limited. Turning $C050 on and off in a tight loop by counting cycles leaves no CPU time for any other task.
Note that the Apple IIe, IIc, and IIgs do have software access to the vertical blanking interval, which obviates the need for Bishop-style "vapor lock" code. But you would still need to count cycles if you wanted to change display modes on every horizontal line.
While it may be possible to turn off the color with software tricks, as mentioned in a previous comment, this isn't the same as a direct software control of the color killer circuit. The methods described by Lancaster, while very cool, have some limitations as also mentioned. But the biggest one is this. Techniques like that are really only applicable when you are writing your own software anyway. Most of the time when people use their Apple II they are going to be running existing software like A2Desktop, which won't have that code in it.
This phrase makes no sense and like much of this discussion is not technically accurate. Yes, you can detect the Vertical Blanking Interval (that only occurs at the start of each frame) and use counters to do all of the wonderful effects shown. But you can never "turn off" the color (or chroma signal) of an Apple composite video signal. Because the Apple's artifact color is not really a true chroma signal.
All but the earliest revision motherboards do have a "colorburst killer" cicuit. Note that this is often referred to as a "color killer" but again this does not technically kill any of the "color." What it does do is attenuate the colorburst portion of the video signal which is used by TV's (which have the real color killer circuit) to shut off decoding of the color information. And that can take a finite amount of time to go into effect. That is why all of the text in your first image still has the color fringing on it.
More importantly, the color burst signal only appears at the beginning of each line so you can't "turn color on or off" in the middle of a line. That is why the second to last photo you posted could only be done on an RGB display (which is ALWAYS "in color"). And in the last photo, since each line starts in the Text mode, it is the reason why every line (and thus the entire screen) is monochrome.
All excellent points. Many of the odd features of the Apple II and other early Apple products designs were due to Woz thinking outside the box. Often because he didn't really know where the box was. That led to the way that Apple II color graphics are generated, the weird memory mapping of video and use of GCR for floppy drives, among other things.
Unfortunately in many cases the clever hacks that made things possible (or affordable) in the late 70s sometimes turned into liabilities in the long run. Things that made things more difficult or required work-arounds to deal with. But hindsight is 20/20 and frankly I don't think Woz or even Jobs, like Bilbo Baggins ever imagined the journey they were about to embark on.
Although I wrote the routines that generated those pictures, I'm sorry to say that I didn't save most of those programs. I like to experiment with the "raw hardware" without booting any OS...then discard them because the
SAVEcommand isn't available without DOS / ProDOS.But I had a more interesting discussion on Slack in September about a routine called WINDOWTOGGLE that divides the screen into 10 side-by-side windows that can be individually set to display graphics or text. WINDOWTOGGLE uses a universal subset of vaporlock that should be compatible with Apple ][, Apple //e, and Apple //c.
Sep3D.png
To view the rest of the pictures from Slack, or if you want to try the routine yourself, I copied comments and pictures from Slack into a blogpost here. I haven't figured out how to post source code elegantly on AppleFritter, but I posted the raw machine code in case you want to type it yourself. These kinds of routines rely on hardware quirks, so they require a physical Apple II -- very few emulators can do it. (In fact, the Slack thread arose because S Champailler and xotwere trying to adapt their emulators to accurately reproduce the glitches in this picture.)
But that's getting too far off-topic for this thread. If anyone wants to talk about vaporlock fun, add a comment to the blogpost. (Or should I start a new thread somewhere?)
Can't help but remind you that in cases like this where you haven't loaded DOS, there still is a SAVE command that writes out to tape. This of course assumes you're not working on a //c or //c+.
This is correct. The built in AppleSoft commands LOAD and SAVE work with the tape interface. A lot of people forget about that because tape was rarely used on the Apple ][ after the Disk ][ came out. And as you say, the machines that didn't have a tape interface like the //c and //c+ they were understandably omitted, probably for ROM space for something else. Most people assume they are just DOS 3.3 or ProDOS commands because they are normally trapped by the OS and the disk version used.
Although it rarely involved Applesoft code, I sometimes used tape when I was cracking copy protection. I'd use an NMI to get a monitor prompt then save sections of memory using the monitor tape routines. Then I'd reboot and pull the data back in from tape and save it to disk... It was a crude technique but surprisingly effective.
Offhand I don't have the link to the discussion Jeff was referring to, but here's a functional (tested) link to Lancaster's book Enhancing Your Apple II:
Parts List for Software Color Killer
Don't be misled by the term "software" in the title. The color-killer enhancement in Lancaster's book requires hardware modifications, but it is software-controllable.
The book also proposes an enhancement similar to "vaporlock" using a hardware modification. Only later did Lancaster promote vaporlock as a practical method. (Maybe he hadn't yet read Bob Bishop's article when he wrote this book.)
First I'm going to say my memory was not as good as I thought. The method mentioned by Lancaster does require a simple hardware mod using the joystick port, and I had forgot that. But I'm glad Scott stopped by, because I thought he did it without the hardware mod.
Here's two more attempts at linking the book first is the windows fun URL copy/paste and I included the raw URL in case that doesn't work: Enhancing Your Apple II Volume 1 : Don Lancaster : Free Download, Borrow, and Streaming : Internet Archive
https://archive.org/details/enhancing-your-apple-ii-volume-1/page/16/mode/2up
@jeffmazur lol, cassette SAVE... who remembers that?!?!? =) So easy to forget, sounds like you relied on that a lot or have a fantastic memory!
Thanks for the link. It's maybe what the OP is looking for.
Thanks for the link. It's maybe what the OP is looking for.
Edit -- On second thought... no... I think the mod is for ][+... I thing the OP has a //e. Not sure if there is a way to do this mod on a //e.
Ah ha!
Yes, my color-killer works without any hardware mod. I inadvertently diverted the topic because those pictures in Comment #35 were from a discussion of Lancaster's book, Enhancing Your Apple II. I'm so sorry, I went off-topic onto the wrong off-topic-topic!
Here's a link to the original video post about a software-only color killer. I think this is the one you were trying to describe originally, but I don't think Facebook will let us share it with users outside the Call -151 group.
For anyone who's not in that FB group, I've re-uploaded the video to YouTube so you can view it with this link. Yes, it allows software to toggle color on-and-off without any hardware mod.
The video demonstrates it, shows listings, and tries to explain it. In short, it works exactly like @robespierre explained in Comment #37 -- meticulously-timed access to the
$C050and$C051switches to toggle graphics off during HBL.colorkiller.png
@robespierre was also right that the CPU has no time for other tasks, so my software-only color killer is not a practical solution for A2Desktop because it would hog the whole CPU!
Thank you!! I spent over an hour last night looking through all the old FB posts from early August trying to find that. Came up empty cuz I was looking in the wrong group!
Thanks too for the detials on how it was done and I still think all those experiments are beyond what I ever imagined that hardware could do.
If you have made a machine code program, then you can boot DOS and save it.
As long as the program is in a certain part of memory, because loading DOS do not erase all memory.
Even a Basic program can be restored as only a few bytes (mostly in zero page) is changed when loading DOS.
Necroposting for posterity...
On systems with a software-controlled color/mono mode -- including the IIgs (both RGB and composite), and the IIe with a Video-7, AppleColor, or Le Chat Mauve RGB card -- DeskTop by default forces the system into monochrome mode, as it was designed.
The "RGB Color" checkbox overrides this, so you'll get color output. Which is pretty yucky since most of the UI assumes monochrome, but it does mean you can get color on the desktop if you pick the right pattern. I find it entertaining for a few minutes at best, but people requested the feature so I added it.