Famicom/Dendy SRAM cartrige

[im-pulze]

Will there be a NES-Version of the cartridge, or do you sell a kit? (cart & adaptor)
Do they fit in a normal famicom cart case, or do they need some work to hold your invitnes?

[HardWareMan]

Will there be a NES-Version of the cartridge, or do you sell a kit? (cart & adaptor)
Do they fit in a normal famicom cart case, or do they need some work to hold your invitnes?

Further work is required only in terms of adding holes for SD/MMC card and USB. You can see it here. Using with this adator it fits in standard NES cartrige shell.

[Drakon]

Whoa a custom made famicom to nes adapter cool. You should offer to sell your flash cart pre-assembled in a nes case with the adapter for people who don't realize the superiority of the famicom.

[im-pulze]

Whoa a custom made famicom to nes adapter cool. You should offer to sell your flash cart pre-assembled in a nes case with the adapter for people who don't realize the superiority of the famicom.

yea - something like that. But I'm cool with the solution HardWareMan suggested also. (It would be a selling point, I guess, if you sell an adapter with the cart as a kit)

[Drakon]

Whoa a custom made famicom to nes adapter cool. You should offer to sell your flash cart pre-assembled in a nes case with the adapter for people who don't realize the superiority of the famicom.

yea - something like that. But I'm cool with the solution HardWareMan suggested also. (It would be a selling point, I guess, if you sell an adapter with the cart as a kit)

I build custom console stuff for people. I know how important it is to a lot of people to be able to buy something that they can just "plug it in and play". People are more than willing to pay the extra money to get something like that.

[HardWareMan]

OK, I found some sad error in MMC3 and eliminated it. Now it works perfectly.

[HardWareMan]

We start to tie the debugger to this cartridge. The first sketches.

Soon I'll make new WIP video, sorry for delay.

[byemu]

We start to tie the debugger to this cartridge. The first sketches.

Soon I'll make new WIP video, sorry for delay.

What disassembly (decompiler) did you use?

[HardWareMan]

What disassembly (decompiler) did you use?

We don't use any 3'rd party software, only self made.

[infiniteneslives]

That looks like a pretty legit debugger. Is it just PC software bundled with the flash cart? Or is it actively getting input from the cartridge? If so I'd be curious how it works exactly and what features it has since you can't really single step the NES/FC.

[HardWareMan]

...since you can't really single step the NES/FC.

Certainly not in the traditional sense. But look at CopyNes. Wait! OH SHI-- :3

[infiniteneslives]

...since you can't really single step the NES/FC.

Certainly not in the traditional sense. But look at CopyNes. Wait! OH SHI-- :3

Not sure what you may be trying to say here... I was speaking from the perspective of the cartridge you can't control the CPU's clock (which is the traditional sense). The copyNES doesn't have the restriction of only connecting via the cart slot. Are you getting around this restriction somehow?

[hyarion]

you can't control the CPU's clock (which is the traditional sense). The copyNES doesn't have the restriction of only connecting via the cart slot.

but you can feed arbitary instructions to the cpu such as jump-0-bytes-forward to halt the CPU, or if you want to inspect a ppu register you cab feed the cpu with instructions for extracting and sending back ppu registers etc over the cartridge bus.only the sky is the limit when you plug an fpga on the cart slot

[tokumaru]

if you want to inspect a ppu register you cab feed the cpu with instructions for extracting and sending back ppu registers etc over the cartridge bus.

Except most PPU registers aren't readable at all, and even if the CPU is "halted" the PPU will keep running.

[HardWareMan]

if you want to inspect a ppu register you cab feed the cpu with instructions for extracting and sending back ppu registers etc over the cartridge bus.

Except most PPU registers aren't readable at all, and even if the CPU is "halted" the PPU will keep running.

That's true. But we can spy any CPU writes to PPU and we've got CHR side, so we have almost full info about PPU state (making listening PPU register part inside FPGA can hadle even DMA transfers, because for PPU it is still regular write cycle). Also we have full mapper state. And at last, depend on mapper, we must track which PPU render position is now by watching CHR RAM access (you know about it: 4 cycles to every background tile). So you just need to lock stop position and release CPU near this position. Only VBLANK hardware signal is missing and unavailable (available only indirectly by tracking fetching NMI vector).
Yes, it can produce some unexpected behavior, such game crash, but still quite powerfull, doesn't it? Full control possible only on emulator (dosen't matter hardware or software). I hope this is a comprehensive answer.