VLBitmap2Scroll

Sik · Post by **Sik** » Sun Apr 20, 2008 4:48 pm

I really don't know what happened, the only thing I've done since that copy was replace a "lsl.w #2, d3" with two "add.w d3, d3"... I should go and try to get that function again, and see if it works.

It may be too that maybe I'm giving it the wrong parameters o_o'

EDIT: it may be also that the tool I used to convert a BMP to a 4BPP raw bitmap is actually wrong and generated a wrong bitmap really ^_^'

TmEE co.(TM) · Post by **TmEE co.(TM)** » Mon Apr 21, 2008 7:42 am

now, that you have gotten your routine to work, make some test ROM !!!

Sik · Post by **Sik** » Mon Apr 21, 2008 3:03 pm

I never said I fixed it >_> And I did make a test ROM, otherwise I wouldn't have said this. But it isn't working properly (it's loading garbage), so nevermind...

Ugh, this subroutine was working when I first made it, what's wrong?!

TmEE co.(TM) · Post by **TmEE co.(TM)** » Mon Apr 21, 2008 3:07 pm

Show me a screenshot of that garbage, and what the original image looks like...

Sik · Post by **Sik** » Mon Apr 21, 2008 5:01 pm

The weirdest is that tiles are loaded in random order, so maybe actually the problem is in VLWriteScrollFillEx... Oh, I'm getting crazy x_X Here goes the faulty ROM (with no scrolling so no benchmark

):
http://srb2town.sepwich.com/junk/bmpdemo.bin

TmEE co.(TM) · Post by **TmEE co.(TM)** » Mon Apr 21, 2008 5:11 pm

ok.... some things get to wrong places... and the white lines with blue ones on some tiles show that data gets loaded incorrectly.... I think

EDIT : And check your mail

Sik · Post by **Sik** » Mon Apr 21, 2008 11:15 pm

TmEE co.(TM) wrote:ok.... some things get to wrong places... and the white lines with blue ones on some tiles show that data gets loaded incorrectly.... I think

Also notice how tiles are loaded in a random order. Weird, as I never change the VDP address to write next. So maybe VLBitmap2Scroll isn't the only problem... Gotta check VLWriteScrollFillEx again.

TascoDLX · Post by **TascoDLX** » Tue Apr 22, 2008 1:44 am

Sik, could you check where your fetching data for the name table? It looks like you've missed initializing a register, but actually, I don't see any name table data at all within the ROM.

Sik · Post by **Sik** » Tue Apr 22, 2008 2:12 am

The only register that can cause such a bug is the autoincrement one, and I didn't touch it, so it stays at the value VLInitLibrary gives to it, which is 2. So no. Wait... I forgotten I could use KMod's debugger as this ROM works in Gens. So well, let's take a look to the registers:

Definitely the autoincrement register is set at 2. So nop, the problem doesn't come from there. Let's check VRAM, just in case:

W00t, the bitmap is being loaded wrong, but more like an interlaced read (or maybe I really made the bitmap tool wrongly), and it doesn't justify the way it looks on screen. So definitely VLBitmap2Scroll isn't the only problem. Weird, I was sure VLWriteScrollFillEx was working...

I don't think that can be much useful

Well, here goes a dump of VRAM, just in case you want to check:
http://srb2town.sepwich.com/junk/bmpdemo_VRAM.ram

TascoDLX · Post by **TascoDLX** » Tue Apr 22, 2008 2:38 am

It was not a VDP register to which I was referring. It is a 68K register, namely A0. The name table data is being read from ROM 000000, so it is basically nonsense data.

Also, I just noticed that KMod dumps VRAM byteswapped? Odd, I never noticed that before.

Sik · Post by **Sik** » Tue Apr 22, 2008 3:14 am

If you're talking about VLWriteScrollFillEx, is because it doesn't use a name table. It writes consecutive values into VRAM, starting from the value set in d5 (well, when working properly

). The one that uses a nametable data is VLWriteScrollEx.

Huh, waaaaait a second... WTF I'm using VLWriteScrollEx instead of VLWriteScrollFillEx O_O *fixes* OK, redownload ROM

The bitmap is wrong through. Those who have a program that can read raw 4BPP bitmaps, can you please check if the bitmap is OK? Because if it's wrong I don't want to scramble up VLBitmap2Scroll for no reason :/

TascoDLX · Post by **TascoDLX** » Tue Apr 22, 2008 5:33 am

Here are your corrections, Sik. I hope I made them clear enough. Enjoy!

Code: Select all

VLBitmap2Scroll:
    movem.l d0-a1, -(sp)
    andi.l  #2047, d2
    lsl.l   #7, d2
    lsr.w   #2, d2
    ori.w   #$4000, d2
    swap    d2
    move.l  d2, ($C00004).l
    lsl.w   #2, d0          ; *** changed : lsl.w #1,d0
    andi.l  #$FFFF, d0
                            ; *** removed : lsr.w #3,d1
    subq.w  #1, d1          
    lea     ($C00000).l, a1

Code: Select all

VLBitmap2ScrollVLoop:
    move.w  d0, d3
    lsr.w   #2, d3          ; *** changed : add.w d3,d3
                            ; ***           add.w d3,d3
    subq.w  #1, d3
    swap    d1

EDIT:

Here are some PAR codes for a quick fix. Same changes as above.

Code: Select all

00034E:E548
000356:4E71
000384:E44B
000386:4E71

Sik · Post by **Sik** » Tue Apr 22, 2008 5:51 am

Didn't I replace that last lsl? >_> And by the way, trying tomorrow

TmEE co.(TM) · Post by **TmEE co.(TM)** » Tue Apr 22, 2008 7:15 am

you should use a 4-bit BMP image for debugging, just start reading it form the right part (where the actual image starts)... just see my code for right offset.

Sik · Post by **Sik** » Tue Apr 22, 2008 5:18 pm

Except for a little detail... If I'm not mistaken, bitmaps are stored flipped vertically, that is, the bottom row first, the top row last. Exactly the opposite as hardware. No idea why this happens. OpenGL? (normally OpenGL has the coordinate system set for that)

Anyways, now the code works... through the benchmark is low >_> Ugh... Argh, stupid memory, I thought it was faster

Redownload ROM...