graphics

[jeesus]

I made cga program and it doesnt work properly. Placing nops in random placecs makes it work better or worse. When in make exe of same program it doesnt work at all. What causes those weird exe and nop things?

[Frank Kotler]

Jeesus, you don't give us a lot to go on!

You've got a "cga program"... Okay, you got a cga card, or are you expecting a modern card to emulate cga properly? (might, but I wouldn't count on it) You doing this with BIOS? Ports? IOCTLs?

Is there some pattern to the random places that nops make it work better/worse?

I'm afraid you're going to have to give us a lot more information! What did you do, exactly? What did you expect to happen? What happened instead?

Best,
Frank

[jeesus]

http://pena.dy.fi/jako/hiiri.asm Program is like that. It should draw dot at place where mouse is and draw line between places where left mouse button is pressed. I have tried real cga card computer. Usually program terminates when i try to change to graphics mode. When changing to graphics work then program behaves like some lines of source code would be missing. Sometimes program just makes screen black and computer wont respond to anything. Placing nops sometimes fixes those things. I dont see nop pattern. Usually nop fixes one problem but causes another.

[Frank Kotler]

Mmmmm... apparently the winner of some kind of contest. Obfuscated code?

;segment code

;..start:
;mov ax,stack
;mov ss,ax;
;mov ax,sl
;mov sp,ax

This cruft with ss:sp is not necessary (I know the example in the manual does it...). What you do need to do, if you're assembling into an MZ .exe, is set up ds (and es?) on startup. Easier to leave it as a .com file, if that's acceptable to you.

org 100h

mov ax,es            ;cga
mov es,ax

These two lines do nothing useful.

mov bx,410h
mov ax,[es:bx]
and ax,11001111b
or ax,00100000b
mov [es:bx],ax

Here's your problem! This is apparently intended to modify your "equipment list" at 40h:10h (or 0:410h), but instead is scribbling on your code. That's why the "nop"s are making a difference - you're scribbling on a different place. I question the effect of forcing this to a different value, in any case - it ain't going to change the equipment!

mov ah,0
mov al,4
int 10h

Did it work? Apparently this interrupt doesn't set carry-flag on failure(). Maybe check with int 10h/0Fh?

mov ax,0
mov es,ax            ;cga laitettu

If this were done before the access to [es:410h], you'd be in the right place! Completely useless here, as you promptly overwrite it! Move it up!

mov ax,0xb800
mov es,ax

Now es points at "screen memory", as we want it...

I'd have to fire up dos and test it, to get much farther than this. I will, if this is really the example you want to work with. Honestly, I don't see much to recommend it.

Do you really want to do this in mode 4? Or is this just the only "etch-a-sketch" example you could find? I think it can be made to work - perhaps just setting es in the right place will fix it. I think your time might be better spent starting from scratch. What's the "goal" here?

Best,
Frank

[jeesus]

Program uses cga for compatibility. After fixing that mov ax,es to mov ax,0 it stared to work somehow. Some or byte[es:bx],dl parts of program seems to cause program to jam if nops arent added. In exes int 10h causes program to terminate.

[Frank Kotler]

Well... after a session of bashin' at it... (I don't miss dos as much as I thought I did)... I've found at least part of the problem...

Code: [Select]

...
lviiva2:
 cmp dx,1   ; x1, x2 have been swapped
 jz lviiva3
...

...
lviiva3:
cmp dx,1
jz lviiva2
...

As you can see, once it falls into this, it never gets out. Program hung. "lviiva1:" and "lviiva4:" do the same thing. Simply commenting out the offending code keeps the program "alive", but not working quite right - some of the lines are being drawn in the wrong place. I haven't quite worked through what we *are* supposed to be doing there. Are you familiar with Bresenham's algorithm at all? I've read through how it works - he essentially starts with "y=mx+b", and hoists calculations out of the loop until practically everything is "pre-calculated" before the actual line-drawing starts. Very clever! It can be further optimized by dividing the line in two, and calling itself recursively... until it gets down to one pixel, and it plots it as it "ret"s (as I recall, that's how it goes). This implementation doesn't attempt that optimization (fortunately, perhaps). It depends on calling a different routine, depending on how the line is sloped... and that's where we're screwed up (I think). I'll have to refresh my memory on how it's supposed to go, before I can fix this, I think. I'll attach what I've got - it's "closer" but not there yet.

If you want to assemble this in "-f obj" mode for an .exe - the "trick" is that your data's in the code segment, not its own data segment, so your "startup" code should be just "push cs"/"pop ds"...

I may attempt another session at this... I'd like to get it working... but it's highly unimpressive, even when it works, and I don't think it's worth putting a lot of effort into it. A "hi-res" implementation... maybe... but mode 4? Ehhh...

Best,
Frank

[jeesus]

Its working now. Somehow that int 10 causes program to terminate if space reserved for stack is about 100 words or less.