• Please review our updated Terms and Rules here

Composite out on CGA is coming out B&W

Early articles on the IBM PC showed it being used with an Amdek monitor, which was then a very popular choice for other computers which didn't (yet) provide their own color monitor, such as the Apple II and Atari 800.

E8oXOlJVoAIgiAn.jpg
 
krebizfan said:
That is the maximum so presumably most bytes will be transferred over the span of fewer horizontal retraces. Looking at the horizontal refresh loop (mvm_1 to mvm_h_wait), it looks like multiple single byte transfers would be handled between each vertical refresh cycle. I don't have the proper system to profile the actual code speed and determine how many bytes will be transferred.
Click to expand...

Looking at the whole code block:

Code: 
mvm_1:
        dec     bx
mvm_h_refresh:
        in      al,dx
        test    al,h_retrace
        jnz     mvm_h_refresh           ; wait for a non retrace period

;       the next statement is commented out to prevent comm char loss
;       cli                                     ; disable interrupts while waiting (not long)
mvm_h_wait:
        in      al,dx                   ; get the retrace status
        test    al,h_retrace            ; check for retrace in progress
        jz      mvm_h_wait              ; wait until retrace

        movsb                           ; now move one byte
;       sti                                     ; and now enable interrupts again

        cmp     bx,0                            ; are we finished?
        je      mvm_end
        loop    mvm_1                   ; only if cx not 0
        cmp     bx,0
        je      mvm_end

I'm sort of an assembly newb, but I don't see how this moves more than one byte per horizontal refresh. This is how I interpret the flow of this:

  1. Before we end up here BX is loaded with that count of the number of horizontal refresh actions we intend to do outside of the vertical blanking area. (Up to the max of 196 in the fragment earlier.)
  2. mvm_h_refresh spins until we enter the active area for whatever line we're on when we start this.
  3. mvm_h_wait is executed when we leave the active area. Inside this function this happens:
    1. We check again to make sure we're actually in the blanking area.
    2. When we're sure of that we move one byte
    3. We check to see if we're done with our (1 to 196) bytes, if we are, jump to the escape hatch.
    4. Otherwise loop to mvm_1...
... And when we loop back to mvm_1 where we're going to spin our wheels until we get to the next blanking period? I don't see how this could ever move more than the one byte inside each horizontal blanking area.

EDIT: Keep in mind that the standard H_BLANK interval is only about 12 microseconds. For a 4.77mhz 8088 isn't that only about 10 machine-language instructions, best possible case?
 
Last edited:
Not necessarily more than 1 byte per horizontal refresh but certainly more than one byte over the span of 196 horizontal refreshes between vertical refreshes. Combined with the vertical refresh byte movement, that should allow replacing all the text more than four times a second. I think that would be faster than the INT 10h routines the code aims to replace.
 
krebizfan said:
Not necessarily more than 1 byte per horizontal refresh but certainly more than one byte over the span of 196 horizontal refreshes between vertical refreshes.
Click to expand...

Sure... but it's the one byte per each horizontal refresh I was talking about. I was never arguing that it couldn't move... 196 (each horizontal) + 210 (vertical blank) = 406 bytes per frame. A rate that should make it able to replace the entire screen (4000 bytes) in 10 frames, so, sure, more than four times a second. If we say it's four that gives us a character rate of 8000 characters per second (because of attributes our character rate is half our byte rate).

That actually seems lightning fast? The video benchmarks in Check-It! tells me that my 7.16mhz XT's VGA BIOS can do 1103 characters per second and the direct video speed is 6651 CPS, which it pegs as 1.63x and 1.33x times the speed of an IBM PC/XT respectively. I assume whatever it's doing must be more complicated than a scroll.
 
Eudimorphodon said:
Sure... but it's the one byte per each horizontal refresh I was talking about. I was never arguing that it couldn't move... 196 (each horizontal) + 210 (vertical blank) = 406 bytes per frame.
Click to expand...

210 is how many words it moves during vertical blank, not bytes. So it adds up to 616 bytes per frame.

It's possible to do even more - the thing is, the code can only monitor for vertical retrace, which starts some 24 scanlines into the vertical blanking period. Those extra 24 scanlines don't have to be wasted, but the CGA's status bit 0 only tells you whether the raster is blanked - you don't know whether the blanking is vertical or horizontal. So it's not exactly straightforward to tell when vertical blanking begins.

It's possible to get around that, but for a general purpose TSR (where you can't really get away with disabling interrupts entirely) it can be tricky.
 
VileR said:
210 is how many words it moves during vertical blank, not bytes. So it adds up to 616 bytes per frame.
Click to expand...

Doh! Yeah, totally didn't notice the difference in the two routines.

All credit where it's due, it's genuinely impressive that the person that wrote this code bothered copying the one byte they could fit into the horizontal blanking area. That's seriously going to the mat to wring every ounce.
 
@vwestlife The article you reference (looks like Jan '82 if I'm reading that right, nice!) - in that article it says "a redefinable character set like the Atari 800" - what's up with that?


And, this snow is just in software that uses the "i" or intensity bit? So...... it might be easier to just hex-edit the MODM.COM to not issue any high bit colors? :)
 
voidstar78 said:
And, this snow is just in software that uses the "i" or intensity bit? So...... it might be easier to just hex-edit the MODM.COM to not issue any high bit colors? :)
Click to expand...

No. I mentioned that in reference to the fact that there was some explicit support for RGB monitors that didn't support the intensity line. It has nothing, absolutely nothing, to do with the snow. (You asked about what monitors people used before IBM started selling the 5153.)
 
voidstar78 said:
- in that article it says "a redefinable character set like the Atari 800" - what's up with that?
Click to expand...
The author was on crack, or they mistook the ability to draw text at "full resolution" in graphics mode for real redefinable characters.

(Edit: it's the latter... or, well, the author is knowingly talking about graphics mode. If you look up the article, Byte, Jan 1982, he explains how the BIOS routines for printing text in graphics mode have built in support for pointing to a custom character table.)
 
Last edited:
I see - yea I figured it might have been referring to the system having a graphics mode.

On the other hand, according to the TV series Halt and Catch Fire, crack was pretty popular in the early days of the PC industry ;) Maybe it was just an early 80's thing altogether. I was always curious how "accurate" HCF series was about that (as almost everything else about it was fairly twisted and fabricated, and yet did maintain some similarities). But that's probably for a different forum :D
 
@Trixter Hey in 8088mph, during the "follow the line" part of the demo - for whatever reason, I accidentally pressed a key during that part of the demo. Doing so makes the line stutter. That's understandable. Well, being even more curious, I pressed more keys - and guess what happened? The key buffer thing made the speaker beep, but ALSO it made the cassette relay (in the 5150) click! Neato. But, then it locked up the demo. I can't remember if I was running the original party version of the newer one. Or does the cassette relay always click when the keyboard buffer gets full? I had the case cover off, so maybe the clicking was just more apparent because of that.
 
You must log in or register to reply here.
Back
Top