Removers library version 1.3.1

[SebRmv]

Just found the bug, before going to work!

Thanks for spotting it. Do you want the fixed version of vline.s ?

[Hyper_Eye]

Yes. That is what the screenshot shows. It is pretty strange. Once I go beyond a certain ymax the pixels start coming down on the right based on the ymax value. Then if I start increasing my ymin the amount on the right moves down with the ymin. Not only does it move down... it also shrinks and the intended line moves further down the screen. Eventually the line on the right will disappear while the intended line reaches the bottom of the screen with the top starting significantly lower than the other lines.

[SebRmv]

Yes. That is what the screenshot shows. It is pretty strange. Once I go beyond a certain ymax the pixels start coming down on the right based on the ymax value. Then if I start increasing my ymin the amount on the right moves down with the ymin. Not only does it move down... it also shrinks and the intended line moves further down the screen. Eventually the line on the right will disappear while the intended line reaches the bottom of the screen with the top starting significantly lower than the other lines.

 

Hi. As I said, I have found the bug. I don't think I will release an update just for that fix, but here is the patch.

 

In vline.s, replace the block (after label .depth_ok)

or.l #XADD0,d0
move.l d0,A2_FLAGS
moveq #0,d0			    ;; remove
move.w SCREEN_W(a0),d0    ;; remove
move.l d0,A2_STEP
move.l d1,B_CMD
wait_blitter d0

 

by

 

or.l #XADD0,d0
move.l d0,A2_FLAGS
moveq #1,d0			    ;; fix
swap d0					    ;; fix
move.l d0,A2_STEP
move.l d1,B_CMD
wait_blitter d0

 

As every bug, this one was really stupid! Instead of doing Y++ between each inner loop, it was doing X+=W.

 

The bug happened when X wrapped around 65536, so in this case at line 204. Because X was initially equal to 240.

Indeed 240+204*320 = 65520 but 240 + 205*320 = 65840 >= 65536

And 65840 mod 65536 = 304. So an artefact occured at X = 304!

[Hyper_Eye]

Sorry. I didn't see your last post because it was on the next page and I didn't notice the new page. Sorry about that. I'm glad the bug is resolved. I will apply the fix and give it a shot. In my testing last night I had found that 204 was the magic number. It all adds up!

 

That worked perfectly. Thanks!

Edited February 1, 2012 by Hyper_Eye

[SebRmv]

Hi,

 

I just made a bugfix release of jlibc & rmvlib. I also added a new example showing how to communicate with the Skunkboard thanks to rmvjcp.

[SebRmv]

For those of you who want to try but are afraid to install linux, I have set up a VirtualBox machine with the Removers development kit installed on it.

Download link is at http://removers.atari.org/softs/download.php under the name JagStation.

[rush6432]

Nice, ill have to give this a shot and test it out! Ive got a custom environment in linux right now for my own but i always like seeing other setups

[SebRmv]

It is my pleasure to announce that jlibc and rmvlib are now hosted on github:

 

https://github.com/sbriais/jlibc

https://github.com/sbriais/rmvlib

[Hyper_Eye]

That's an excellent development. Thanks for your continued work on these great tools.