nesdev.org

Posted: **Sat Apr 04, 2015 6:27 pm**

Espozo wrote:Well, that's a lot... (or do the 65816 and 6502 just have a very small amount of registers? I recall ARM having about the amount you showed.)

It's not really that many. Of the 14 registers in the 80(1)86, 7 are useful for common tasks. Compare that to the 68000, which has 15 useful registers, or MIPS, which has about 25! (For reference, the 6502 has 6 registers, and only 3 are useful for common tasks.)

Espozo wrote:So, If I were to take an "immediate" and store it in a "direct", I'd do something like this?
Code: Select all
mov  [F8800], 1F

That's basically correct. You'll have to fix the syntax, and the 80(1)86 is limited to 16-bit offsets. You'll probably end up doing something along these lines:

Code: Select all

mov ax, 0xF800
mov ds, ax
mov byte [0x800], 0x1F

lidnariq wrote:PTR

This is MASM syntax, not NASM syntax.

Espozo wrote:I actually kind of like it better than Mame normally, because you don't have that dumb filter that makes me feel like my vision is even worse than it is.

I don't think MAME has any filters by default. Do you have something in one of your .ini files?

Posted: **Sat Apr 04, 2015 6:30 pm**

Not so obvious to me.

To bad no consoles that I'm aware of do this. Maybe we would have seen 3 4bpp BG layers on the SNES...

Which means it'd take about 15 minutes to make a tool to translate them in and out of Super NES 4-bit tile format by reinterleaving the bytes.

Not that I have any clue how to make one...

lidnariq wrote:
Espozo wrote:-nofilter[...]I actually kind of like it better than Mame normally, because you don't have that dumb filter that makes me feel like my vision is even worse than it is.
I recently discovered that MESS has a drum machine emulator in it.The only video output on this drum machine is a single HD44780 LCD, with 16x2 6x8-dot characters.

Having MESS blow that tiny thing up to full screen with bilinear filtering? Bleh.

What? Drum emulator?

You know though, this whole things been pretty fun! (For me, anyway.) Hopefully, I'll be able to show you guys something simple at some point.

Edit: about the filter thing, I mean it does this:

Posted: **Sat Apr 04, 2015 7:22 pm**

Espozo wrote:What? Drum emulator?

https://github.com/mamedev/mame/blob/ma ... s/alesis.c

Emulator for the Alesis HR-16 and SR-16 drum machines.

I don't really understand why it's in MESS, but, hey, whatever. The hardware in it isn't all that different from half of an arcade machine.

Posted: **Sun Apr 05, 2015 7:39 am**

Good news again! I'm pretty sure I found what files hold the sprite graphics, because this:

Looks remarkably like this:

: GunForce 2 Sprites.png (38.22 KiB) Viewed 2894 times

There are also 3 other files that are named similarly to that one and they seem to supplement it because they appear to have each bit per pixel spread across 4 chips just like the BG tiles. The graphics in the files I found also seem to be very 16x16 ish, so I think I'm right.

Well, here's something that says how many files have had their purpose discovered:

a2_000.8a = Sprite Graphics Bit 1
a2_010.8b = Sprite Graphics Bit 2
a2_020.8c = Sprite Graphics Bit 3
a2_030.8d = Sprite Graphics Bit 4
a2_c0.1a = BG Graphics Bit 1
a2_c1.1b = BG Graphics Bit 2
a2_c2.3a = BG Graphics Bit 3
a2_c3.3b = BG Graphics Bit 4
a2_da.1l = PCM Samples
a2_sh0.3l = ???
a2_sl0.5l = ???
a2_h0-a.6h = ???
a2_h1-a.6f = ???
a2_l0-a.8h = ???
a2_l1-a.8f = ???

Oh, and also, do you think this code looks good?

Code: Select all

CPU 80186

  mov ax, 0xF800
  mov ds, ax
  mov byte [0x800], 0x1F

infinite_loop:
  jmp infinite_loop

"0xf8800" is the first color in cgram (or whatever it's called here) and "0x1F" is, just like on the SNES and GBA, solid red. So if I'm not mistaken, this code should turn the screen red. I ran it through yasm and it made a file, which is good. By the way, why do we need the "0x"? Do I actually need to specify where the code starts somehow?

Edit: Oh yeah, do you think I could run the remaining files through some sort of disassembler and see if it gives me anything logical? Where could I find one?

Posted: **Sun Apr 05, 2015 9:43 am**

I lost power twice while typing up my reply. Clearly someone doesn't want me to answer your questions.

Espozo wrote:Oh, and also, do you think this code looks good?

It looks like it will do what you expect it to do. You still need to put some code at the reset address, or the CPU will get stuck executing garbage instead of running your code.

Espozo wrote:By the way, why do we need the "0x"?

Why do we need "$" in 6502 assembly?

Espozo wrote:Do I actually need to specify where the code starts somehow?

If you don't specify, the assembler assumes it starts at offset 0. This is not the same as physical/linear address 0.

Espozo wrote:Oh yeah, do you think I could run the remaining files through some sort of disassembler and see if it gives me anything logical? Where could I find one?

I usually use objdump. There's also ndisasm (included with NASM) and unidasm (included with MAME). Also, don't forget MAME has a built-in debugger. For short snippets of code, I sometimes use this disassembler.

Posted: **Sun Apr 05, 2015 11:56 am**

Joe wrote:I lost power twice while typing up my reply. Clearly someone doesn't want me to answer your questions.

I was almost done writing and I accidentally exited out of the window like an idiot...

Well, anyway, I replaced each of the 6 files with the one that I made, and here are the results:

a2_sh0.3l and a2_sl0.5l: Runs, but with no sound. It passes the self check.

a2_h0-a.6h and a2_l0-a.8h: The screen is dark, and the self check doesn't even start. cgram (or whatever it's called here) is filled with 2 1bit RGB palettes in every 16 color palette. The game does this before it starts the self test normally. I'm pretty sure these files have to do with the CPUs. There are 2 files, so should there be 1 for each CPU?

Joe wrote:
Espozo wrote:Oh, and also, do you think this code looks good?
It looks like it will do what you expect it to do. You still need to put some code at the reset address, or the CPU will get stuck executing garbage instead of running your code.

That's probably why. I'll fix it and report the behavior later.

a2_h1-a.6f and a2_l1-a.8f: These go to the self check, but they give these respectively:

: Self Test.png (3.98 KiB) Viewed 2870 times

Then it turns to something like this... (It is different for each file changed. This is the second one.)

: Result....png (20.4 KiB) Viewed 2870 times

The game actually runs completely normal, despite it looking like that...

Edit: Oh yeah, this is sad, but what do you mean by "put some code at the reset address"?

Posted: **Sun Apr 05, 2015 12:38 pm**

Espozo wrote:Edit: Oh yeah, this is sad, but what do you mean by "put some code at the reset address"?

The 8086 family always starts executing code at FFFF:0000. (Unlike the 6502, which reads a 16 bit pointer from $FFFC) Unfortunately, I don't immediately see in MAME's source what's mapped at that location, so I'm not certain what happens next in the M92.

Posted: **Sun Apr 05, 2015 1:03 pm**

Do you know if there's a way to search for "FFFF:0000" on this webpage? https://github.com/mamedev/mame/blob/ma ... vers/m92.c
The search bar at the top looks through al the documents on the website, not the specific document.

Posted: **Sun Apr 05, 2015 1:18 pm**

Well, I did find this in the source:
AM_RANGE(0xffff0, 0xfffff) AM_ROM AM_REGION("maincpu", 0x7fff0)
so the hardware on the board causes the values at FFFF:0 to be fetched from 7FFF:0 ... which maybe means it's here?

Code: Select all

ROM_START( bmaster ) /* M92-B-B PCB used for program rom locations */
        ROM_REGION( 0x100000, "maincpu", 0 )
        ROM_LOAD16_BYTE( "bm_d-h0-b.5m", 0x000001, 0x40000, CRC(49b257c7) SHA1(cb4917ef6c5f959094f95b8535ea12e6b9b0bcc2) )
        ROM_LOAD16_BYTE( "bm_d-l0-b.5f", 0x000000, 0x40000, CRC(a873523e) SHA1(9aee134c299e12064842e16db296f4259eccdf5b) )

I forget whether ROM_LOAD16_BYTE's 3rd argument is in bytes loaded, or range written. If the former, then I guess it is there...

Posted: **Sun Apr 05, 2015 1:21 pm**

So now we need to see what's at 7FFF:0 instead of FFFF:0?

Edit: The author of the web page I showed earlier said that the V30 only does stuff with the sound, so all I need to worry about is the V33 for now. I really have no idea how to work two CPUs at a time, so that's nice to hear. it looks like things are really starting to come along!

Edit 2: Actually, I'm going to show the message the person sent me because maybe it will be useful. I'm sure he wouldn't mind.

If you look back in the driver link I sent, you can see how the roms are used:

ROM_START( gunforc2 )
ROM_REGION( 0x100000, "maincpu", 0 )
ROM_LOAD16_BYTE("a2-h0-a.6h", 0x000001, 0x040000, CRC(49965e22) SHA1(077283c66a4cc2c47221c5f3267f440223615a15) )
ROM_LOAD16_BYTE("a2-l0-a.8h", 0x000000, 0x040000, CRC(8c88b278) SHA1(0fd8e663619dcd8c81b3baa290bb0e72c185273a) )
ROM_LOAD16_BYTE("a2-h1-a.6f", 0x080001, 0x040000, CRC(34280b88) SHA1(3fd3cdf8acfa845abacb0708fb48741ee44dbf13) )
ROM_LOAD16_BYTE("a2-l1-a.8f", 0x080000, 0x040000, CRC(c8c13f51) SHA1(fde3fd983ebb920f79e6898aa0576da9dd9f0c15) )

So those 4 are the main program, you can see l0/h0 load to 0 in the memory map, and h1/l1 load to 0x80000. Now because this is a 16 bit CPU and these roms are 8 bit how it actually works is the 'h' rom provides the high byte for the 16 bit word, and 'l the low bit - so to be able to disassemble you have to interleave these roms byte by byte. Hope that makes sense!

If you find a debug version of Mame, or compile it yourself you can run the game with the debugger and then save out the roms already interleaved. This would be a good start to modify things, as you could hook a subroutine and copy your own program code there. You can use the built-in Mame debugger to try stuff out.

The V30 just does the sound - it doesn't affect gameplay at all - so the V33 communicates just by writing a byte and firing an interrupt on the V30 to tell it the byte is ready to be read (see m92_soundlatch_w)

Edit 3: (Yeah, I know...) From what he said, it seems that I'd have to split whatever code I'm making between two files? Why are there four then? I guess just for the extra space? Because of how it's set up, I guess "a2_sh0.3l" is the high byte for the sound CPU, or the V30, (hence the "h") and "a2_sl0.5l" is low byte for it. (hence the "l")

Posted: **Sun Apr 05, 2015 9:30 pm**

Just thinking, tepples said it would "it'd take about 15 minutes to make a tool to translate them in and out of Super NES 4-bit tile format by reinterleaving the bytes." when he was referring to graphics, and, would it be too bad if someone made a tool that would alternate between two files to take bytes to put them into one larger file and also do the same thing except reverse?

This is because of the way the M92 looks between two chips for the code.

Edit: Wait, I'm stupid. Why would I want to put the two files together? All I want is the ability to split a file apart. Surely there must be something someone has made...

Edit 2: I've tried to see if someone had already made a tool that could do this, but I've ran into the worst of luck. I followed a download link to one someone said they made and it gave me a 404 error, and 2 others weren't "compatible with my computer" or whatever because they were for 16 bit processors. (What, can a 64 bit processor not perform 16 bit instructions?)

Posted: **Thu Apr 09, 2015 5:39 pm**

Well, I used Kasumi's newly made file splitter and split the assembled version of this:

Code: Select all

CPU 80186

  mov ax, 0xF800
  mov ds, ax
  mov byte [0x800], 0x1F

infinite_loop:
  jmp infinite_loop

into 2 files because of the 8 bit rom thing and I replaced "a2-h0-a.6h" and "a2-h1-a.6f" with the 2 newly made ones (I made tried it both ways, with the first file going to "a2-h0-a.6h" and then with it going to "a2-h1-a.6f") and ran it in the Mame debugger, but unfortunately, it didn't work both times, with it just loading a black screen and not even going to the self test. This is also what it looked like in the debugger both times:

(Is this essentially just 0s the whole way through?)

I'm also pretty sure it isn't the file splitter's fault, because both files are exactly half as large as the original, (6 vs. 12) so I don't have the slightest clue what's wrong. It appears that the program isn't starting at the right place?

Edit: I'm not sure if this is of any use to anyone, but this is how the game normally looks: (How in the world could there be ???)

Posted: **Thu Apr 09, 2015 6:16 pm**

Espozo wrote:Is this essentially just 0s the whole way through?

Yes.

As mentioned earlier, you need to put some code at linear address 0xFFFF0 (ROM address 0x7FFF0) or the CPU will begin executing garbage instead of your code.

Espozo wrote:I'm not sure if this is of any use to anyone, but this is how the game normally looks:

That corresponds to the following code:

Code: Select all

cli
jmp 0x0040:0xE354

MAME is using mnemonics from NEC instead of Intel, which is why they don't look like x86 instructions.

Espozo wrote:(How in the world could there be ???)

Those are invalid opcodes.

Posted: **Thu Apr 09, 2015 6:54 pm**

Joe wrote:As mentioned earlier, you need to put some code at linear address 0xFFFF0 (ROM address 0x7FFF0) or the CPU will begin executing garbage instead of your code.

How do you do that though? I know this is probably basic stuff...

Joe wrote:Those are invalid opcodes.

You mean like numbers that don't respond to anything? What are they even doing there? How does the processor even handle something like that?

Posted: **Thu Apr 09, 2015 7:54 pm**

More recent processors will essentially BRK on invalid opcodes, calling one of the interrupt vectors.

nesdev.org

Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?

Re: Is Anyone Willing to Explain This C++ Code?