It is currently Thu Oct 18, 2018 1:31 pm

View unanswered posts | View active topics


Board index » NES / Famicom » NESemdev

All times are UTC - 7 hours





Post new topic Reply to topic  Page 1 of 4
  [ 47 posts ]  Go to page 1, 2, 3, 4  Next
  Print view Previous topic | Next topic 
Author Message
Alyosha_TAS
 Post subject: 3D Block (Hwang Shinwei)
PostPosted: Thu Jul 27, 2017 2:46 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 71
I am trying to figure out how to get this game working.

To initialize, it does 4 writes:
0x32 -> 0x4800
0x37 -> 0x4900
0x1 -> 0x4A00
0x18 -> 0x4E00

I'm not exactly sure what they do, but it looks like it's setting up some IRQ behaviour. The write of 0x1 might be setting up mirroring mode?
The game expects to split the screen using IRQs (more then one per frame)

Here is the IRQ:

Code:
====IRQ====
0201:  4C  JMP $CF02       A:10 X:00 Y:00 P:24 SP:FA Cy:1281871 nvTbdIzc
CF02:  85  STA $F7         A:10 X:00 Y:00 P:24 SP:FA Cy:1281874 nvTbdIzc
CF04:  EE  INC $01E4       A:10 X:00 Y:00 P:24 SP:FA Cy:1281877 nvTbdIzc
CF07:  AD  LDA $01E4       A:10 X:00 Y:00 P:24 SP:FA Cy:1281883 nvTbdIzc
CF0A:  29  AND #$01        A:03 X:00 Y:00 P:24 SP:FA Cy:1281887 nvTbdIzc
CF0C:  F0  BEQ $CF20       A:01 X:00 Y:00 P:24 SP:FA Cy:1281889 nvTbdIzc
CF0E:  A9  LDA #$24        A:01 X:00 Y:00 P:24 SP:FA Cy:1281891 nvTbdIzc
CF10:  8D  STA $2006       A:24 X:00 Y:00 P:24 SP:FA Cy:1281893 nvTbdIzc
CF13:  A9  LDA #$00        A:24 X:00 Y:00 P:24 SP:FA Cy:1281897 nvTbdIzc
CF15:  8D  STA $2006       A:00 X:00 Y:00 P:26 SP:FA Cy:1281899 nvTbdIZc
CF18:  A9  LDA #$83        A:00 X:00 Y:00 P:26 SP:FA Cy:1281903 nvTbdIZc
CF1A:  8D  STA $2000       A:83 X:00 Y:00 P:A4 SP:FA Cy:1281905 NvTbdIzc
CF1D:  4C  JMP $CF41       A:83 X:00 Y:00 P:A4 SP:FA Cy:1281909 NvTbdIzc
CF41:  EE  INC $02D1       A:83 X:00 Y:00 P:A4 SP:FA Cy:1281912 NvTbdIzc
CF44:  AD  LDA $02D1       A:83 X:00 Y:00 P:24 SP:FA Cy:1281918 nvTbdIzc
CF47:  C9  CMP #$5C        A:4F X:00 Y:00 P:24 SP:FA Cy:1281922 nvTbdIzc
CF49:  90  BCC $CF4F       A:4F X:00 Y:00 P:A4 SP:FA Cy:1281924 NvTbdIzc
CF4F:  A5  LDA $F7         A:4F X:00 Y:00 P:A4 SP:FA Cy:1281927 NvTbdIzc
CF51:  40  RTI             A:10 X:00 Y:00 P:24 SP:FA Cy:1281930 nvTbdIzc


The first problem I am having is that there doesn't seem to be anything to acknowledge the IRQ. Those branches in there don't lead to anything that would do so either.

Does anyone know of any other examples of IRQs being acknowledged in non-standard ways? Maybe that will point me in the right direction on how to approach emulating this ROM.


Last edited by Alyosha_TAS on Thu Jul 27, 2017 4:35 pm, edited 1 time in total.

Top
 Profile  
 
lidnariq
PostPosted: Thu Jul 27, 2017 3:54 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7661
Location: Seattle
Which specific build are you trying to get to work?
The one in GoodNES3.14 ("3D Block (Unl).nes", crc32 1c4f2651 crc32(prg) cae5382d) seems fine?
Top
 Profile  
 
Alyosha_TAS
PostPosted: Thu Jul 27, 2017 4:34 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 71
3-D Block (Asia) (Unl) (Hwang Shinwei).nes

CRC32: 5E8764F8

EDIT: Another thing I noticed is that possibly the 32k of rom is swappable 16k banks. one interrupt vector I noticed in the swapped bank set up is A800, and following through that code I get to a JMP ($53A6)

But, I have no idea what is supposed to be read from the EXP addresses. Maybe we are missing some information about this ROM that the dump doesnt provide.
Top
 Profile  
 
lidnariq
PostPosted: Fri Jul 28, 2017 11:17 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7661
Location: Seattle
(edit: remove copypasta) GoodNES3.14 has a '3D Block (Unl) [a1][!].nes' that matches the CRC that you provided. It's marked as mapper 219, but it clearly doesn't comply with our notes as to what mapper 219 should be.

Comparing a1! to ! , there are a few minor differences causing some blocks of code to move around, but the substantial difference is the insertion of an extra 4 KiB of ... something? that would be mapped at $E600.

What's really odd about that is that it implies that the plain NROM build has the same (but vestigial) IRQ handler sitting around.

Due to the similarities betweeen a1! and !, I'm not convinced there's any bankswitching here...


Last edited by lidnariq on Fri Jul 28, 2017 2:14 pm, edited 1 time in total.

Top
 Profile  
 
Alyosha_TAS
PostPosted: Fri Jul 28, 2017 2:11 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 71
Well, the main problem is that I don't see any way to control the IRQ's and have no way to interpret what the writes to $4x00 are doing.

Without bank switching, I checked the startup routines for both ROMs and they are indeeed pretty similar, but the Hwang Shinwei ROM clears the interrupt flag right before drawing the intro screen, and if the same IRQs are active there that need to be active in the games screen, the result is just a mess.

Maybe this isn't tractable without the original cart to decrypt what is supposed to be happening.
Top
 Profile  
 
lidnariq
PostPosted: Fri Jul 28, 2017 2:25 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7661
Location: Seattle
Looking a bit more closely, the game seems to switch between 4 different IRQ vectors, using a table at $CD80. One of these four IRQ handlers is just this tiny thing:
Code:
IRQvecs_4E8C
        $CE8C  E6 11:       inc $11
        $CE8E  EA:          nop
        $CE8F  EA:          nop
        $CE90  EA:          nop
        $CE91  48:          pha
        $CE92  68:          pla
        $CE93  48:          pha
        $CE94  68:          pla
        $CE95  40:          rti

(total IRQ duration: 7+3+5+2+2+2+3+4+3+4+6 = 41cy)

It's pretty clear that there's no acknowledgement here.

So ... there's only really two guesses I have for how it could possibly work:
1- it drives /IRQ low for N clocks every M clocks (where clocks maybe is PPUA13, PPUA12, PPU/RD, M2, &c)
2- it detects some bus activity during the IRQ vectoring process and uses that to acknowledge the IRQ.

The string of nops and two pairs of pha/pla implies #1.
Top
 Profile  
 
NewRisingSun
PostPosted: Fri Jul 28, 2017 4:35 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 672
"Magic Jewelry 2" writes to 4A00 and 4C00 as well. It's possible that 3D Block (1989) uses the same PCB, and if so, should be put under Mapper 216 as well.

Edit:
Alyosha_TAS wrote:
and if the same IRQs are active there that need to be active in the games screen, the result is just a mess.
During the title screen, BG and Sprites are fetched both from $0000, while they are fetched from different pattern tables during the actual gameplay. That means that IRQs will not occur on the title screen if the IRQ is clocked by A12 change.


Last edited by NewRisingSun on Fri Jul 28, 2017 4:56 pm, edited 1 time in total.

Top
 Profile  
 
Alyosha_TAS
PostPosted: Fri Jul 28, 2017 4:56 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 71
No implementation on mapper 216 I check has any IRQ behaviour associated with it, so if it is really mapper 216 then mapper 216 is underspecified. But it does seem reasonable for them to be the same (they have the same music at least.)

@lidnariq: thanks for the analysis, I tried implementing a mmc3 style IRQ that only asserts for a set number of cycles, and the IRQ behaviour is starting to look correct (it doesn't fire on the title screen because it doesn't use PPU a12.) So maybe we are on the right track here and just need to narrow down what it is measuring and how it is counting.
Top
 Profile  
 
NewRisingSun
PostPosted: Fri Jul 28, 2017 5:27 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 672
No matter how I implement IRQs, the blocks don't seem to actually fall. Either they only fall if the IRQs occur at exactly the right time, or something else is missing.
Top
 Profile  
 
Alyosha_TAS
PostPosted: Fri Jul 28, 2017 5:39 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 71
NewRisingSun wrote:
No matter how I implement IRQs, the blocks don't seem to actually fall. Either they only fall if the IRQs occur at exactly the right time, or something else is missing.


Were you able to at least get the screen and blocks to look correct?

I think there might be some bank switching going on somehow (swapping top and bottom 16k banks) but my only evidence of this is that there appears to be an IRQ vector at $3FFE (on the cart) and the code at the pointed to location appears to be a proper IRQ location (it promptly stores A,X,Y at the start of execution.)

I'm not sure what would trigger the bank swap though.
Top
 Profile  
 
NewRisingSun
PostPosted: Fri Jul 28, 2017 5:43 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 672
Quote:
I think there might be some bank switching going on somehow (swapping top and bottom 16k banks) but my only evidence of this is that there appears to be an IRQ vector at $3FFE (on the cart)
That doesn't look like a vector to me at all, as it occurs within a contiguous section of code that also crosses the 16k boundary. I don't think there are 16k swappable banks.
Top
 Profile  
 
lidnariq
PostPosted: Fri Jul 28, 2017 6:00 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7661
Location: Seattle
... Um? At $3FFE in PRG I see the bytes $0 $a8, and in its surrounding bytes that feels more like a chunk of code than a pointer.... are we talking about the same ROM after all?

I agree that I see code starting at PRG $6800, but it looks like a replacement NMI (it writes to $4014)
Top
 Profile  
 
Alyosha_TAS
PostPosted: Fri Jul 28, 2017 6:11 pm 
Offline

Joined: Wed Jun 15, 2016 11:49 am
Posts: 71
lidnariq wrote:
... Um? At $3FFE in PRG I see the bytes $0 $a8, and in its surrounding bytes that feels more like a chunk of code than a pointer.... are we talking about the same ROM after all?

I agree that I see code starting at PRG $6800, but it looks like a replacement NMI (it writes to $4014)


Yeah that's the block of code I mean, maybe it's just coincidence then.
Either way, maybe we need some way to access this code?

EDIT: Oh wait, it does run it, ok nevermind me.

EDIT2: It looks like the write to $4900 is the IRQ reload counter, setting it to 0x37 *2 + 1 gives exactly the right split in the screen.
Top
 Profile  
 
NewRisingSun
PostPosted: Fri Aug 03, 2018 10:20 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 672
The 3D Block PCB is also used by the original version of "Block Force" (called "Square Force" in GoodNES). It uses a PIC16C54 microcontroller with an embedded ROM and takes CPU A4-A14 plus M2 as an input, and provides /IRQ as an output. In other words, it watches the CPU address bus, counts M2 cycles, and fires an IRQ when it feels like it. CPU D0-D7 are not connected to the microcontroller. The microcontroller has a protection feature which prevents the embedded ROM from being read out by an EPROM programmer.

Images provided by MLX.


Attachments:
BlockForce-PCBf.jpg
BlockForce-PCBf.jpg [ 1.48 MiB | Viewed 2016 times ]
BlockForce-PCBb.jpg
BlockForce-PCBb.jpg [ 1.23 MiB | Viewed 2016 times ]


Last edited by NewRisingSun on Fri Aug 03, 2018 10:35 am, edited 1 time in total.
Top
 Profile  
 
MLX
PostPosted: Fri Aug 03, 2018 10:29 am 
Online

Joined: Tue Feb 14, 2017 9:50 am
Posts: 91
PIC16C54 pinout
Code:
PIC.01 - 27C.05
PIC.02 - 27C.06
PIC.03 - NC
PIC.04 - 4.7kΩ
PIC.05 - GND
PIC.06 - 27C.02
PIC.07 - 27C.03
PIC.08 - CPU A10
PIC.09 - 27C.23
PIC.10 - 27C.24
PIC.11 - 27C.25
PIC.12 - 27C.26
PIC.13 - 27C.27
PIC.14 - +5V
PIC.15 - NC
PIC.16 - M2
PIC.17 - /IRQ (pin 15)
PIC.18 - 27C.04
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 4
  [ 47 posts ]  Go to page 1, 2, 3, 4  Next

Board index » NES / Famicom » NESemdev

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group