• Please review our updated Terms and Rules here

Video mode 6 (640x200)

Maybe you could adjust the CRT to reduce the overscan area, thus making the text (and everything else) slightly bigger? If it's anything like my IBM 8513 monitor, then it has an unusually large border around the text/graphics area, so out of the 12" picture tube, you actually only get around 10" worth of usable image.
 
It takes SO much to get inside the computer to adjust it, but it does have a large border, just like my 8512..

Besides, the POTS haven't been touched, and last time I messed with a POT that old, it spazzed out and required replacement.

The 8x8 fonts are actually perfect.. I just want it to stay running.
 
In most cases, the answer to the question of, "Why on Earth would the engineers do that?", is "For good reason".
I know the usual reason for leaving a large border/overscan area is to avoid the distortions that can occur as the image gets close to the edge of the CRT, but on these IBM monitors the border area is rather excessive, compared to any others I've ever used.

My 8513 also does a weirdo thing where using 640x350 EGA mode results in no border at the top and bottom of the image -- it goes right up to the edge -- making the image look vertically stretched. It's always done that since my dad bought it brand new in 1993, but I don't know if they all do that or if mine was simply misadjusted at the factory.
 
Cool... getting better at writing code for hardware I don't have...

Yup... congrats :cool:

Unfortunately I've never been able to get wrapping INT 10h to work on anything...

Well, the first random source from google does it this way:

Code:
  mov ax, 3510h                               ; save interrupt 10h vector
  int 21h
  mov [oldint10h], bx
  mov [oldint10h + 2], es

  mov ah, 25h                                 ; install new
  mov dx, newint10h                           ; interrupt 10h handler
  int 21h

Don't see anything special in the rest of the code. So this just ought to work...
 
Don't see anything special in the rest of the code. So this just ought to work...
That's actually not where the problem lies -- it's in the ISR itself where things go wierd. It's calling oldint10h inside newint10h that's the problem. With every other ISR you just go:

pushf
call oldint10h

For some reason when I try that, oldint10h doesn't do anything anymore... and we still need the old one called since all we want to trap is sub-function AH=00h, and only when AL=02 or AL=03...
 
Any updates on this? I love the program, but dislike having to re-load it.

If you can fix this problem, I would be very grateful.
 
Back
Top