Coolboy cart programmer

[BennVenn]

That makes sense, GHI never really worked the way it was documented when dumping the carts contents.

If I could get FCEUX booting my ROM's that would be great! I'm not sure how to build the correct header to get it to boot, or how to compile the source for the one or two versions that have the coolboy mapper added.

I might just reverse engineer the whole thing from scratch. I'll write a 2mbyte ROM to the cart with keywords scattered in all the important places, 128k boundaries, 8kbyte boundaries, 1kbyte boundaries then brute all the mapping combinations that I think are important.

I think there is more going on inside this chip than FCEUX's source lets on. There must be a way to tell the mapper the ROM size. I can't think how MMC3 would work otherwise for more than 1 ROM size.

[tepples]

I haven't understood a lot of the preceding discussion about how a particular cart arranges the bits that control each particular address line. But here's the general outline of how any multicart would select game size.

• 128K: A17 and above come from the outer mapper, and A16 and below come from the MMC3
• 256K: A18 and above come from the outer mapper, and A17 and below come from the MMC3
• 512K: A19 and above come from the outer mapper, and A18 and below come from the MMC3

This might be implemented several ways:

1. A pair of muxes controls the A17 and A18 select lines, choosing between A18-A17 from the MMC3 and the corresponding bits in the outer mapper
2. The bits from the MMC3 are ANDed with the select bits, and then the corresponding bits in the outer mapper is ORed onto it
3. The bits from the MMC3 are ORed with the select bits, and then the corresponding bits in the outer mapper is ANDed onto it
4. The bits from the MMC3 are ANDed with the select bits, and then the corresponding bits in the outer mapper is XORed onto it
5. The bits from the MMC3 are ORed with the select bits, and then the corresponding bits in the outer mapper is XORed onto it

The "game size" bits in the Action 53 mapper behave similarly to option a above, where bits 5-4 of register $80-$81 control how many of A15 through A17 are replaced with outer bank bits 0 through 2 when the CPU is reading outside the game's fixed bank.

[BennVenn]

Thanks for the info Tepples, I think the coolboy mapper is also similar to a) on your list.

Here is what I have found, this confirms the information on the wiki is incorrect.

Cool($6000,$6001,$6002,$6003)

Code: Select all

Cool(0x00,0x00,0,0)
Maps 512kbyte ROM 

Cool(0x00,0x80,0,0)
Maps 256kbyte ROM 

Cool(0x40,0x80,0,0)
Maps 128kbyte ROM 


128kbyte mapping

Cool(0x41,0x80,0,0)
Maps second 128kbyte ROM, Offset A17 in bit0 of $6000

Cool(0x42,0x80,0,0)
Maps third 128kbyte ROM, Offset A17 in bit0, A18 in bit1 of $6000

Cool(0x43,0x80,0,0)
Maps fourth 128kbyte ROM, Offset A17 in bit0, A18 in bit1 of $6000


256kbyte mapping

Cool(0x01,0x80,0,0)
Maps 256kbyte ROM. Bit0 (A17) in $6000 not responsive

Cool(0x02,0x80,0,0)
Maps second 256kbyte ROM. Bit0 (A17) in $6000 not responsive, Bit1=A18

Cool(0x04,0x80,0,0)
Maps Third 256kbyte ROM. Bit0 (A17) in $6000 not responsive, Bit1=A18, bit2=A19


512kbyte mapping
Cool(0x04,0x00,0,0)
Maps second 512kbyte ROM. Bit0&1 not responsive, Bit 2=A19 

The remainder of the upper address bytes seem to be valid as seen on the Flash IC's address bus. The exception is the most significant bit A24 is inverted but that really doesn't make any difference as it doesn't affect flash commands so we can leave it alone.

This should be enough to get a majority of the ROM's working on this cart. This doesn't explain how I could boot mario (32k) using mm3 without padding the ROM to 128k using 32k mirrors. I'll need to look into GNROM mode for 32k ROM's. I'm dumping and flashing these carts in GNROM mode, just need to work out the fixed address mapping.

Also interesting to note is the wiki states the mmc3 can address up to 2mbyte ROM's. So far I've been unable to move the fixed bank up past 512kbytes.

[lidnariq]

If I could get FCEUX booting my ROM's that would be great! I'm not sure how to build the correct header to get it to boot

The simplest way I can think of to do this is to use a program that will pack/unpack UNIF files ... like this program I created a while ago:

unif_packer_unpacker.7z

(32.18 KiB) Downloaded 149 times

You should only need a MAPR chunk and a PRG0 chunk, I think.

[BennVenn]

There is a russian gaming site that has dumped almost all the coolboy carts and included a UNIF header to boot them in an emulator. Problem is I get the 'mapper not supported' error as the coolboy mapper needs to be included at build time?

[lidnariq]

COOLBOY support only began as of January this year, but 2.2.2 dates to September 2013. You'll need a build from svn.

[BennVenn]

Found 2.2.3 and it works fine with coolboy ROM's.

Now i've found I'm having trouble booting 128k ROM's. The PRG data is fine, but the CHR data is a bit screwed up.

It must be in my CHR RAM copying routine, or maybe mapping... I've taken the chr routine from the coolboy cart so I don't think its that.

Anyone care to take a look to see if there is anything obvious?

I have been stepping through in fceux and sometimes a mapper write to $06>$8000 and say, $02>$8001 shows $8001 as $07????

Code: Select all

;----------------------------------------------------------------
; constants
;----------------------------------------------------------------

PRG_COUNT = 32 ;1 = 16KB, 2 = 32KB
MIRRORING = %0001 ;%0000 = horizontal, %0001 = vertical, %1000 = four-screen

;----------------------------------------------------------------
; variables
;----------------------------------------------------------------

   .enum $0000
   .ende
;----------------------------------------------------------------
; iNES header
;----------------------------------------------------------------

   .db "NES", $1a ;identification of the iNES header
   .db PRG_COUNT ;number of 16KB PRG-ROM pages
   .db $00 ;number of 8KB CHR-ROM pages
   .db $00|MIRRORING ;mapper 0 and mirroring
   .dsb 9, $00 ;clear the remaining bytes

;----------------------------------------------------------------
; program bank(s)
;----------------------------------------------------------------


	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000
	
	BASE $8000
	;Bank Data here:
	ORG $C000
	
	BASE $8000
	;Bank Data here:
	ORG $C000
	
	BASE $8000
	;Bank Data here:
	ORG $C000
	
	BASE $8000
	;Bank Data here:
	ORG $C000
	
	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $8000
	;Bank Data here:
	ORG $C000

	BASE $C000
	
	
Reset:
   sei
   cld
   
   lda $2000
   and #$FB
   sta $2000 ;set up auto incrment vram
 
  ;SET UP CHR RAM, LOCATION $A0000 
 LDA #$45
 STA $0114
 LDA #$80
 STA $0115
 LDA #%00000000
 STA $0116
 LDA #%00000000
 STA $0117

;SET UP PRG ROM, LOCATION $80000
 LDA #$44
 STA $0118
 LDA #$80
 STA $0119
 LDA #%00000000
 STA $011A
 LDA #%10000000
 STA $011B

 LDA #$10
 STA $011D ;NUMBER OF 8KBYTE BLOCKS TO COPY
 
 LDA #$00
 STA $011C ;BANK OFFSET OF CHR ROM
 
  
Copy2Ram:

   ldx #$00
   
C2R:
   lda #Program , x
   sta #$0200 , x
   inx
   bne C2R
   jmp #$0200
   


 

Program:
 LDA $0114 ;CHR ROM LOCATION IN FLASH
 STA $6000
 LDA $0115
 STA $6001
 LDA $0116
 STA $6002
 LDA $0117
 STA $6003
 LDA #$00
 STA $0111 ; COUNTER OF 8K CHR BLOCKS TO COPY TO RAM   
LOOP0:
 LDA #$06
 STA $8000
 LDA $011C ;WHASSS SSSISSSSS?
 CLC
 ADC $0111
 STA $8001
 LDA $0111
 ASL
 ASL
 ASL
 TAX
 LDY #$00
 STY $8000
 STX $8001
 INX
 INX
 INY
 STY $8000
 STX $8001
 INX
 INX
 INY
 STY $8000
 STX $8001
 INX
 INY
 STY $8000
 STX $8001
 INX
 INY
 STY $8000
 STX $8001
 INX
 INY
 STY $8000
 STX $8001
 LDA #$00
 STA $2006 ;SET VRAM ADDRESS TO $0000
 STA $2006
 STA $00C3
 LDA #$80
 STA $00C4
 LDX #$20
 LDY #$00
LOOP1:
 LDA ($C3),Y
 STA $2007
 INY
 BNE LOOP1
 INC $00C4
 DEX
 BNE LOOP1
 INC $0111
 LDA $0111
 CMP $011D
 BCC LOOP0
 LDA #$00
 STA $2006
 STA $2006
 SEI
 CLD
 LDA #$C0
 STA $4017
 LDX #$08
LOOP2:
 BIT $2002
 BPL LOOP2
LOOP3:
 BIT $2002
 BMI LOOP3
 DEX
 BPL LOOP2
 TXS
 LDX #$06
 LDY #$0C
 STX $8000
 STY $8001
 INX
 INY
 STX $8000
 STY $8001
 
 LDA $0118
 STA $6000
 LDA $0119
 STA $6001
 LDA $011A
 STA $6002
 LDA $011b
 STA $6003
 JMP ($FFFC)

NMI:

IRQ:

	
   .org $fffa

   .dw NMI
   .dw Reset
   .dw IRQ

[lidnariq]

Any chance that the default menu uses a different order of 8KiB slices, or 256-byte pages within an 8KiB slice, than the original CHR-ROMs?

[BennVenn]

I've pulled Contra 2 out of the coolboy cart and it matches byte for byte with a downloaded version so I don't think that is it.

I read somewhere the PPU takes 80,000clk cycles to initialise? Do you think that is why?

Also, I'm having the same issue with Mario2, except this time I can partially re-create the issue in the emulator if I don't specify mirroring in the Unif header. If I specify then it boots and plays fine in the emulator.

I've tried setting the mmc to vertical or horizontal before jumping to its reset vector address but it didn't make a change.

Very confused...

[lidnariq]

The front-loader's PPU takes a full field of video (262 scanlines NTSC, 312 scanlines PAL) before it accepts writes to $2006, but that should only cause a subset of the game's CHR to be lost, if that's what's to blame.

Waiting for the PPU to warm up is really easy, though: nesdevwiki:PPU power up state

[BennVenn]

Tried this:

Code: Select all

 LDX #$08
LOOP12:
 BIT $2002
 BPL LOOP12
LOOP13:
 BIT $2002
 BMI LOOP13
 DEX
 BPL LOOP12

This was taken from the cart's menu.
Still not working....

With Bugs Bunny's Birthday Blowout, all the CHR is fine up until the game begins where it is a mess. This hints at a partial transfer?

[Zonomi]

There is a russian gaming site that has dumped almost all the coolboy carts and included a UNIF header to boot them in an emulator. Problem is I get the 'mapper not supported' error as the coolboy mapper needs to be included at build time?

Why not ask more informations from Cluster ?
He's the owner of the «russian gaming site».

[BennVenn]

I'll do that.

I've also started coding a test program to confirm the data read back from cHr ram is the data written. this should help identify the problem

[BennVenn]

I think I need some graphical feedback. Is there a reference to the minimum needed setup to display a limited ascii set?

From the GB world, I'd copy a bunch of tiles, set up a pallete, then set the OAM to draw up some sprites. Is it as simple as that on the NES?

Edit: I've just found Dwedit's HelloWorld.asm I've relocated the Font table to bank0, and modified the code. Looks good. I'll set up different font tables in each bank then have them cycled through one at a time to see if I can catch out something going wrong.

If I don't see anything I'll do a full CHR RAM copy and read back the checksums to find any corruption.

At least I'm learning some NES ASM!

[lidnariq]

That's basically it. Wait for the PPU to be ready, write a palette (to PPU $3F00-$3F1F instead of GBCPU's 0xFF47,8,9), write some tiles (to PPU $0000-$1FFF instead of GBCPU's 0x8000-0x97FF), write a nametable (to PPU $2000-$2FFF instead of GBCPU 0x9800-0x9FFF), and enable video (via writes to CPU $2000,1 instead of GBCPU $FF40)