• Please review our updated Terms and Rules here

IBM 5150: VGA boots to BASIC, but CGA won't?

RootHouston

Member
Joined
Sep 12, 2020
Messages
20
Location
Houston, Texas, USA
Although it runs fine with my late '90s VGA card and display, I was recently able to get a more period-correct IBM 5153 display and Color Graphics adapter card for my IBM 5150. My hard card is malfunctioning, and I'm expecting to get to IBM Cassette BASIC, but in CGA mode, despite changing jumper settings, it POSTs properly, but after that, the fat boot cursor switches to a thinner white blinking cursor that reacts to key presses, but won't show any characters on the screen. Any idea what is going on? I don't actually have anything to boot to from floppy to test anything else right now.

I'm guessing that I am in BASIC, but not seeing anything there? Anyone have any ideas? Thanks.
 
Try doing something that would beep the speaker, or click the cassette relay. Or perhaps blindly type commands in that would print a stream of characters (something like: for i=1 to 9999 : print "hello" : next) and see if the cursor moves on its own. If that happens, that sounds like a fault in the CGA card such as the character generator ROM.
 
Welcome to these forums.

I was recently able to get a more period-correct IBM 5153 display and Color Graphics adapter card for my IBM 5150.
Always good to know what we are working with.

Did the supplier indicate that the items are fully functional ?

... but in CGA mode, ...
This needs expansion/clarification. Do you mean that the motherboard's two video switches are set for CGA ?

... despite changing jumper settings, ...
What jumpers are those? The IBM CGA card has no jumpers, and the 5150 motherboard has only one jumper which is a setting for the cassette port.

... it POSTs properly, ...
What do you see/hear that makes you believe that?

... that reacts to key presses, but won't show any characters on the screen.
So, the curcur simply moves one position to the right for each key press?

I'm guessing that I am in BASIC, but not seeing anything there?
Try typing in the following BASIC command, then press the ENTER key.
If you are in BASIC, that command will beep the speaker.

PRINT CHR$(7)

Anyone have any ideas?
VGA card removed?
 
Thanks everyone for responding to a newcomer. Just to clear-up some things:

  • I'd mistakenly called the DIP switches as "jumper settings". Forgive me.
  • The DIP switch settings are, in fact, configured for CGA cards. I have the 5 switch on, and the 6 switch off when the CGA card connected. I've included a photo here later in the post. For VGA, I use both 5 and 6 on. I am not attempting to use them simultaneously.
  • Trying BASIC commands was a great suggestion! It seems that I am definitely in BASIC, as performing the speaker beep and for loop both worked to prove that's where we are.
  • I've tried this card using both the 40x25 and the 80x25 color modes in the DIP switch settings. Swapping between them only changes the cursor sizes for me. Unfortunately, I still see no characters.

The company that I purchased the card from claimed that their items are believed to be in working condition, but this one in particular hadn't been tested by them. They have a return policy, that I guess I might have to exercise. It's too bad, as this card looks great physically. It arrived with no dust, and is free of any corrosion or damage on the chips. This is actually my second attempt to get a CGA card. The first time, the seller mislabeled the item, and sent me an MDA card instead. With this second seller, I get this issue.

Here are my jumper settings for CGA mode:
h9sUFlw.jpg


Here's a photo of the actual card:
OQI7Axg.jpg


Here are my questions now:
  • Are these cards very prone to failure? Not sure if I should be trying a modern, third-party solution instead
  • What is the probability that this is an issue with the CGA display instead?
  • Anything else I should try with this card before hanging it up?
Thanks to everyone.
 
I've never seen a CGA card failure where it displayed absolutely nothing; usually some bits of RAM are bad but never nothing at all.

If you see a blinking cursor, and a wider cursor when you switch to 40x25, then your monitor is working at a bare minimum of functionality with which to troubleshoot the CGA card and the rest of the system.

I would try to get yet another CGA card to see if that works, preferably a known working one.
 
Does the CGA card have a hardware cursor (IE, is the little blinking underline generated directly by the CRTC)? I *think* it does, and if so then theoretically there could be something up in the character generator/RAM circuitry that would prevent it from being able to display characters while the blinking cursor survives.

Just for laughs, what happens if you blindly type "screen 2" after it ends up in BASIC? That will switch it from text to 640x200 graphics, it's possible if the issue is with, say, the character generator the card will still be able to generate bitmaps.
 
The cursor is indeed hardware, however it's generated by the motorola 6845, and that's the character generator.

... are you sure about that? The 6845 is a CRTC, "CRT Controller", that generates the timing signals, memory address, and row offsets for the attached video generation hardware. The "character generator" is a 9264 ROM chip. The CRTC generates the address bits, and then the CGA card has a serializer section that takes output either directly from some latches in front of the RAM or indirectly from RAM contents run through the generator ROM and generates the actual video signal sent to the monitor.

Skimming the CGA schematics and the 6845 CRTC datasheet there's a "CURSOR" output on the CRTC that "indicates a valid cursor address to external video processing logic". It looks like this output goes to a gate that adds a tiny delay, which then goes to a horrible mess of gates that generates a signal called "alpha dots"(*), and then *that* disappears into a web of circuitry that makes my eyes bleed. My guess is that this is part of the serializer that allows this "cursor active" signal to be translated into a line/block of dots which is either overlaid or not over the character generator output depending on the status of the "blink" toggle. If that's all true then, well, if the serializer, RAM, or character generator ROM were broken in such a way that the other inputs to the serializer just looked like a bunch of black dots wouldn't that explain how you could have a cursor being painted but nothing else?

EDIT: I looked again at the inputs to that "Alpha Dots" section, and one of them is the serialized output from the 74LS166 shift register that's sitting on the output of the character generator ROM. It also takes cursor blink *and* attribute blink signals, so basically it's a catch-all for what dots need to be combined with the colors generated in the color attribute section. (which I now think is the really eye-bleedy part) So, yeah, if, for instance, that 74LS166 shift register were spitting out nothing but dark pixels that would totally explain why there's a cursor but nothing else.

I'd actually guess it's about a coin flip whether the graphics mode will spit out interesting output or not?

... another thing that might be interesting to try at the BASIC prompt: issue a COLOR statement that sets the background to something other than black.
 
Last edited:
Apologies for using incorrect terminology, and yes, I suppose it is possible. But in all my years handling 30+ CGA cards, I've never seen a failure like that. Still, anything is possible, which is why a known good working CGA card is required for the OP to continue diagnosing through process of elimination.
 
It almost seems like it has to be something broken in the memory-character generator-serializer chain. If the PC were mis-detecting the card it seems unlikely you’d get a clear cursor, because the CRTC has to be programmed to valid timings on startup. (And it’s honoring the 40/80 column switch.) Still really curious if the graphics mode works, because that’s a mostly separate hardware chain on the CGA card.
 
Does the CGA card have a hardware cursor (IE, is the little blinking underline generated directly by the CRTC)? I *think* it does, and if so then theoretically there could be something up in the character generator/RAM circuitry that would prevent it from being able to display characters while the blinking cursor survives.

Just for laughs, what happens if you blindly type "screen 2" after it ends up in BASIC? That will switch it from text to 640x200 graphics, it's possible if the issue is with, say, the character generator the card will still be able to generate bitmaps.

You are correct. It has the little blinking underline. Your suggestion was very interesting! I ended-up getting a screen with some text there that resembles BASIC in a weird way. I took a quick screenshot with my phone. Sorry for the quality. My cell phone doesn't seem to want to focus very well on these large dots. I do have another CGA card that is supposed to show-up this Friday. I guess we're safe to assume it's the character ROM now? Let me know if there are any other things you'd like me to test in the interim.

TX7NEVp.jpg
 
Still really curious if the graphics mode works, because that’s a mostly separate hardware chain on the CGA card.
Supporting that:

I removed the hard disk controller from my IBM 5160 so that the 5160 would boot to Cassette BASIC.
On the 5160's IBM CGA card, I removed the character ROM from its socket.
I then powered on the 5160.
I saw a white raster.
After the POST completed, the screen changed to that shown at [here].
After I entered "screen 2", the screen changed to that shown at [here].
 
* Are these cards very prone to failure? Not sure if I should be trying a modern, third-party solution instead
Not any more prone than any other card.

* What is the probability that this is an issue with the CGA display instead?
You mean the monitor? I'd say not likely.

* Anything else I should try with this card before hanging it up?
Since the character ROM is socketed, try carefully removing it, checking the legs and the socket, then re-seat it.
Also, try the "screen 2" command as Modem 7 suggested, if that displays something sane then that at least proves the video RAM is working fine. If it displays anything garbled, post a photo.
Whatever you do don't toss the card, I'm sure someone could repair it. If it happens to be just the character ROM, that would be an easy fix.
 
I saw a white raster.
After the POST completed, the screen changed to that shown at [here].

I was going to ask if you were able to see a blinking cursor, but I just verified that if the default underline cursor is over a character where there's white on the 8th line (like the solid block graphics character) then it doesn't XOR the existing dots during the blink, the cursor just disappears. So it'd be expected behavior not to see it.

Anyway, yeah, that certainly demonstrates the idea. You're getting white pixels instead of black because TTL logic inputs usually float high if they're not tied to something, so the 74166 shift register that sits on the character generator output is seeing all ones with it pulled out. If it is specifically the character generator that's blown on the OP's card it's messed up in some way that's making it output solid zeros instead.

If you still have the the thing pulled apart I'd be interested to see confirmation that issuing a "color" command would change the color of the raster. (Also, "key off" should get rid of the blank areas at the bottom...) With your card spitting out all "1"'s in the dot generation loop you'll probably only see changes to the foreground color, but with the OP's card if the problem is isolated to this area I'd expect issuing, say, "COLOR 4,1" should produce a red cursor on a blue background. (A "CLS" will fill the screen with the associated color.)

After I entered "screen 2", the screen changed to that shown at [here].

Woot.

So, yeah, if the OP's card *does* work in graphics mode that isolates the problem area a *lot*. In the chain between RAM and "alpha dots" there's a 74LS374 (?, from memory) latch, the character generator, the 74LS166 shift register, and the chain of gates in the "alpha dots" circuitry itself. (Since we see the cursor itself I'd expect the stuff downstream from Alpha Dots to be okay.) If graphics mode works it almost certainly limits the problem to that region, or *possibly* one of the clock/enable lines for one of those components.

(If graphics mode *doesn't* work and/or that test of trying to set color attributes fails then we're looking at a more general problem, like the video memory or possibly some brokenness in the support circuitry, like address generation or read pulse timing.)
 
Last edited:
I apologize for the disjointed replies, but since I'm new here, my posts are still being manually moderated and approved for posting. I am 35 years old now, and have never removed a socketed chip in my life, but with the help of YouTube, I got confident enough to try to reseat the character ROM chip as per a suggestion from Eudimorphodon. Unfortunately, it didn't have any effect. I then read here that the MDA cards used the same character ROM as the CGA, and realized that I had 2 of those lying around. The first came with my machine. The second one, as I may have mentioned previously, was sent to me in error.

Now, I'm not certain if the 6359300 and 5788005 chips are the same, whereas the CGA card had the 6359300 chip, and the MDAs both had the 5788005 chip, I swapped them anyway. Unfortunately, even swapping for the 5788005s had the same result. Unless I just have real bad luck or the 5788005 chip is just not compatible on this card, I'm guessing that the chip isn't necessarily malfunctioning, and something else is causing it to not work.
 
... actually, one thing does occur to me, since the OP never provided a picture of the screen. If it's *just* the dot generation that's broken and the condition is it's spitting out all "black" dots then, if everything else is working properly, in addition to the grey cursor they should also be seeing some gray blobs down at the bottom of the screen where the reversed-video function key labels are in BASIC. If they're not seeing those it might already be a tipoff of bigger problems. (Like RAM being broken so the writes to set the color attributes in those screen locations to reverse video went nowhere or otherwise can't take effect.)
 
Also, try the "screen 2" command as Modem 7 suggested, ...
Suggested by Eudimorphodon at post #7

If you still have the the thing pulled apart I'd be interested to see confirmation that issuing a "color" command would change the color of the raster. (Also, "key off" should get rid of the blank areas at the bottom...)
I will get onto that then report back.
 
If you still have the the thing pulled apart I'd be interested to see confirmation that issuing a "color" command would change the color of the raster. (Also, "key off" should get rid of the blank areas at the bottom...)
Entering "key off" removed the black blocks, and entering "color 4" showed a red block.
Photo at [here].
 
Back
Top