Well, sorry for not posting on this in a while, but I saw this:
I wrote:
Well, relating to sprites, I forgot about how I found something called "sprite control" located at 0xF9000 through 0xF900F, so it's only 16 bits long. I look at the other file, and this is what I found:
Code:
62 WRITE16_MEMBER(m92_state::m92_spritecontrol_w)
63 {
64 COMBINE_DATA(&m_spritecontrol[offset]);
65 // offset0: sprite list size (negative)
66 // offset1: ? (always 0)
67 // offset2: sprite control
68 // offset3: ? (always 0)
69 // offset4: sprite dma
70 // offset5: ?
71
72 /* Sprite control - display all sprites, or partial list */
73 if (offset==2 && ACCESSING_BITS_0_7)
74 {
75 if ((data & 0xff) == 8)
76 m_sprite_list = (((0x100 - m_spritecontrol[0]) & 0xff) * 4);
77 else
78 m_sprite_list = 0x400;
79
80 /* Bit 0 is also significant */
81 }
82
83 /* Sprite buffer - the data written doesn't matter (confirmed by several games) */
84 if (offset==4)
85 {
86 /* this implementation is not accurate: still some delayed sprites in gunforc2 (might be another issue?) */
87 m_spriteram->copy();
88 m_sprite_buffer_busy = 0;
89
90 /* Pixel clock is 26.6666MHz (some boards 27MHz??), we have 0x800 bytes, or 0x400 words to copy from
91 spriteram to the buffer. It seems safe to assume 1 word can be copied per clock. */
92 timer_set(attotime::from_hz(XTAL_26_66666MHz) * 0x400, TIMER_SPRITEBUFFER);
93 }
94 // logerror("%04x: m92_spritecontrol_w %08x %08x\n",space.device().safe_pc(),offset,data);
95 }
So if you write a number to offset 0, (which is 0xF9000?) the number of sprites will be the same as the number you moved there? What's up with this then?
Code:
67 // offset2: sprite control
...
72 /* Sprite control - display all sprites, or partial list */
73 if (offset==2 && ACCESSING_BITS_0_7)
And I saw
Quote:
Joe wrote:
That code says you need to write a value to 0xF9000 that will determine how many sprites to draw, then write 8 (or a word with 8 in the low byte) to 0xF9004 to make the sprite drawing logic use that number. Afterwards, write any value to 0xF9008 to copy the sprites from sprite RAM to the internal drawing buffer.
It looks like this logic was designed specifically for rep movsw.
Edit: these registers start at 0xF9000, not 0xF0000.
So I wrote (should I keep copying the whole thing, or do you think we're good?)
Code:
;========================================================================
;Section IVT
;========================================================================
cpu 80186
section ivt start=0 ; you will need this later
idt:
dw diverr_handler, (section.code.start >> 4)
dw brk_handler, (section.code.start >> 4)
dw nmi_handler, (section.code.start >> 4)
dw int3_handler, (section.code.start >> 4)
dw into_handler, (section.code.start >> 4)
dw bound_handler, (section.code.start >> 4)
dw undefinst_handler, (section.code.start >> 4)
dw nocoprocessor_handler, (section.code.start >> 4)
dw vbl_handler, (section.code.start >> 4)
dw sprbuf_handler, (section.code.start >> 4)
dw raster_handler, (section.code.start >> 4)
dw sound_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw coprocessorerror_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw def_handler, (section.code.start >> 4)
dw vbl_handler, (section.code.start >> 4)
dw sprbuf_handler, (section.code.start >> 4)
dw raster_handler, (section.code.start >> 4)
dw sound_handler, (section.code.start >> 4)
;========================================================================
;Section Code (Pointers)
;========================================================================
section code vstart=0 align=16
diverr_handler:
iret
brk_handler:
iret
nmi_handler:
iret
int3_handler:
iret
into_handler:
iret
bound_handler:
iret
undefinst_handler:
iret
nocoprocessor_handler:
iret
vbl_handler:
iret
sprbuf_handler:
iret
raster_handler:
iret
sound_handler:
iret
def_handler:
iret
coprocessorerror_handler:
iret
;========================================================================
;Section Code (Main Code)
;========================================================================
main_code:
;Set Stack Location
mov sp, 0xE000
mov ss, sp
xor sp, sp
;White Color Upload
mov di, VideoHardwareRamStart
mov ds, di
xor di, di
mov [PaletteRam], word 0xFFFF
sti ;Enable Interupts
;Display Sprite
mov [SpriteControlRam + 0], word 0xFFFF
mov [SpriteControlRam + 4], byte 0x08
mov [SpriteControlRam + 8], byte 0xFF
infinite_loop:
add [PaletteRam], word 0x0001
hlt
jmp infinite_loop
;========================================================================
;Section Data
;========================================================================
section data vstart=0 align=16
;========================================================================
;Section Reset
;========================================================================
section reset start=0x7FFF0 vstart=0
cli
jmp (section.code.start >> 4):main_code
times 16-($-$$) db 0
;========================================================================
;Section RAM
;========================================================================
segment bss start=0xE0000 vstart=0 nobits align=16
;Define Stuff:
WorkRamStart equ 0xE000
VideoHardwareRamStart equ 0xF000
SpriteRam equ 0x8000
PaletteRam equ 0x8800
SpriteControlRam equ 0x9000
ScreenWidth equ 320
ScreenHieght equ 240
But nothing happened, and yes, I have graphics at the beginning of chr rom for sprites. I think I remember running into the same situation and thinking that maybe it needed to go in vblank (which at the time wasn't set up right) but I noticed this:
Code:
65 // offset0: sprite list size (negative)
What does it mean be "(negative)"? I just wrote 0xFFFF and it didn't seem to work, so I'm assuming I did this wrong. You know, is it me, or have I already asked this exact same thing before? I just can't find it...
Another thing is I wonder if I could try to contact someone again. I remember I went to some MAME forum and asked them some stuff about this, and they basically told me that they didn't have a clue and that I should look at the "official" MAME developer's forum and asked, but it's one of those places where you sign up and wait to be approved, and I checked it after two weeks and I had still never been verified... I have a sad feeling that I know just about as much as this arcade board as anyone else...
(Kind of shows you Nintendo's screwed up priorities...)
I'm glad we finally got vblank to work correctly. Next up, sprites...
Well, I'll just sick with "xor ax, ax" I'm sure it also takes less memory, not like I really care though.
It won't be so much of a problem once you're more familiar with x86.