Re: CGA Graphics library

Posted on 2019-10-06, 14:12

by

by wbhart

in Milliways

in Milliways

There's a relatively short list of ellipses that yield glitches when comparing the most significant words of xdelta and ydelta. Most could be handled by ellipse code that only worked for small semiradii, leaving a very short list which would have to be handled by more general code. In fact, here is …

---

Re: CGA Graphics library

Posted on 2019-10-06, 00:40

by

by wbhart

in Milliways

in Milliways

I will check, but all attempts to lose any bits have so far failed for me. I've tried all sorts of things. It really seems like all bits are critical for the algorithm. But I now see what you mean about keeping xdelta live, etc. Of course it may be possible to replace the first comparison with a …

---

Re: CGA Graphics library

Posted on 2019-10-04, 10:01

by

by wbhart

in Milliways

in Milliways

Yes, I see what you mean. Then I only have to (explicitly) write them and not read them from memory. I'm not sure how possible that would be since both are accessed multiple times in each iteration. If one of those were not inside a conditional block it might work, since you'd know where it would be …

---

Re: CGA Graphics library

Posted on 2019-10-03, 23:18

by

by wbhart

in Milliways

in Milliways

Yeah, 24 bits seems to be enough, just. So if I didn't miscalculate, it is possible in terms of the number of registers if you drop the exploitation of symmetry. But this isn't a slam dunk if you want to only use short jumps. The code for updating 24 bit values is not cheap, especially as you have …

---

Re: CGA Graphics library

Posted on 2019-10-03, 23:05

by

by wbhart

in Milliways

in Milliways

@reenigne The problem is that one needs 32 bit values. As I see it, there are at least three required. That's already 6 registers. Here is some Julia code that shows the algorithm: function ellipse(r::Int, s::Int) x = r; y = 0; r_orig = r c = s*s a = r*r D = 0 xdelta = 2*c*r_orig ydelta = a while …

---

Re: CGA Graphics library

Posted on 2019-10-03, 18:06

by

by wbhart

in Milliways

in Milliways

I've now added special versions of circle drawing for colours 0 and 3 (which just use AND and OR), an XOR version and a circle blanking routine. The timings (on a 4.77MHz 8088) are now: full : 109 cycles/pixel or/and/xor : 98.5 cycles/pixel blanking : 78.5 cycles/pixel I thought about the ellipse …

---

Re: CGA Graphics library

Posted on 2019-09-18, 18:59

by

by wbhart

in Milliways

in Milliways

The full circle routine is working now and the timings are 109 cycles/pixel on the 8088 @ 4.77MHz, Next I will do the xor and blanking version and if I get motivated enough, maybe the special colour 0 and 3 versions.

---

Re: CGA Graphics library

Posted on 2019-09-14, 12:52

by

by wbhart

in Milliways

in Milliways

I've now added a circle drawing routine (with adjustment for a 1.2:1 CGA pixel aspect ratio) in cga_draw_circle1() in cga5.asm. It currently only draws the right hand side of the circle, but the other side will be analogous. After some timings, I get about 111 cycles/pixel on the 8088 @ 4.77MHz, …

---

Re: Vogons Video Announcement Thread

Posted on 2019-09-06, 19:30

by

by wbhart

in Milliways

in Milliways

My Channel is PCetroTech. This weekend I hope (but cannot promise) to put up a video about a new 486 build I've been working on. Just trying to get the case all cleaned up now. https://www.youtube.com/channel/UCWYne_mhlRE1AiN2ApjmZDA

---

Re: CGA Graphics library

Posted on 2019-09-02, 20:14

by

by wbhart

in Milliways

in Milliways

So I decided to have another go at this cycle counting business. I feel like I have more confidence doing this with AMD CPU's of 2008 era than the original 8086 because one can often prove optimality by counting retirement of macro ops. Anyhow, in the following I give two timings for each …

---

Re: CGA Graphics library

Posted on 2019-09-01, 21:34

by

by wbhart

in Milliways

in Milliways

I managed to shave a few cycles off the verticalish lines. The times are now down to 17.95s or ~106.5 cycles/pixel. I also dug an enormous amount of bugs and corner cases out of the code and wrote a verticalish line blanking routine. This is enough to get my original demo working again that started …

---

Re: CGA Graphics library

Posted on 2019-08-31, 18:15

by

by wbhart

in Milliways

in Milliways

To illustrate my point about instruction times, here is two pixels annotated with instruction times as per the 8086 book: mov al, [bx+di] ; 8 + 5 (Base rel. index. EA) and al, 0cfh ; 4 or al, 030h ; 4 mov [bx+di], al ; 9 + 5 (Base rel. index. EA) add dx, bp ; 3 jg line2_incx31 ; taken: 16, not taken …

---

Re: CGA Graphics library

Posted on 2019-08-31, 17:50

by

by wbhart

in Milliways

in Milliways

I really don't have any explanation for it. Nothing makes sense, because one sees the output on the screen, so it isn't as if I could be running the wrong executable. It's the first time I had it working at all, so I don't see how it could have been the wrong code. It's mystifying. Maybe the random …

---

Re: CGA Graphics library

Posted on 2019-08-31, 13:37

by

by wbhart

in Milliways

in Milliways

As the verticalish lines have to do precisely two CGA memory accesses per pixel, it seems like it could be a candidate for syncing with the CGA clock to avoid CGA wait states. What's not clear to me is at what point during execution of a memory access instruction the CPU will make the request on the …

---

Re: CGA Graphics library

Posted on 2019-08-31, 13:01

by

by wbhart

in Milliways

in Milliways

I implemented your [bx+di] trick again. No problems with byte counting this time. I don't know what I did wrong before. Anyhow, It is at 18.2s now, or ~108 cycles/pixel. I don't see any obvious improvements now. I think my version uses one less instruction per pixel on average than yours, but I …

---

Re: CGA Graphics library

Posted on 2019-08-31, 11:56

by

by wbhart

in Milliways

in Milliways

Something weird is going on. The timing that was 17.3s last night is 19.7s this morning. I do have a dodgy trimpot in my PC, and my understanding is it changes the clock frequency slightly, to alter the colours in NTSC output. But I don't know whether it could make that much difference. I'm quite …

---

Re: CGA Graphics library

Posted on 2019-08-31, 11:24

by

by wbhart

in Milliways

in Milliways

Something weird is going on. The timing that was 17.3s last night is 19.7s this morning. I do have a dodgy trimpot in my PC, and my understanding is it changes the clock frequency slightly, to alter the colours in NTSC output. But I don't know whether it could make that much difference. I'm quite …

---

Re: CGA Graphics library

Posted on 2019-08-31, 09:31

by

by wbhart

in Milliways

in Milliways

It might be better to put -8192 in bx and use "mov [di+bx],al" instead of stosb for even scanlines. The "+bx" doesn't involve any extra code bytes so is approximately free. Then you only need to adjust di every other scanline and it's with a one-byte immediate instead of a two-byte immediate. …

---

Re: CGA Graphics library

Posted on 2019-08-30, 22:09

by

by wbhart

in Milliways

in Milliways

The newest version (_cga_draw_line2 in cga5.asm) seems to be more or less correct, modulo some todos. I can now time it. I do lines from 0,0 to i,199 with i in [0, 198] in increments of 3, i.e. 67 lines. I repeat 60 times. The total time is 17.3s, which works out to about 103 cycles/pixel. Edit: no …

---

Re: CGA Graphics library

Posted on 2019-08-30, 20:11

by

by wbhart

in Milliways

in Milliways

It might be better to put -8192 in bx and use "mov [di+bx],al" instead of stosb for even scanlines. The "+bx" doesn't involve any extra code bytes so is approximately free. Then you only need to adjust di every other scanline and it's with a one-byte immediate instead of a two-byte immediate. …

---