Page 2 of 3
Posted: Sun Apr 20, 2008 4:48 pm
by Sik
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 ^_^'
Posted: Mon Apr 21, 2008 7:42 am
by TmEE co.(TM)
now, that you have gotten your routine to work, make some test ROM !!!
Posted: Mon Apr 21, 2008 3:03 pm
by Sik
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?!
Posted: Mon Apr 21, 2008 3:07 pm
by TmEE co.(TM)
Show me a screenshot of that garbage, and what the original image looks like...
Posted: Mon Apr 21, 2008 5:01 pm
by Sik

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
Posted: Mon Apr 21, 2008 5:11 pm
by TmEE co.(TM)
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

Posted: Mon Apr 21, 2008 11:15 pm
by Sik
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.
Posted: Tue Apr 22, 2008 1:44 am
by TascoDLX
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.
Posted: Tue Apr 22, 2008 2:12 am
by Sik
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
Posted: Tue Apr 22, 2008 2:38 am
by TascoDLX
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.
Posted: Tue Apr 22, 2008 3:14 am
by Sik
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 :/
Posted: Tue Apr 22, 2008 5:33 am
by TascoDLX
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
Posted: Tue Apr 22, 2008 5:51 am
by Sik
Didn't I replace that last lsl? >_> And by the way, trying tomorrow

Posted: Tue Apr 22, 2008 7:15 am
by TmEE co.(TM)
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.
Posted: Tue Apr 22, 2008 5:18 pm
by Sik
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...