SDD1 FGPA implementation

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
srg320
Posts: 32
Joined: Fri Feb 16, 2018 5:52 am
Location: Ukraine

Re: SDD1 FGPA implementation

Post by srg320 »

magno wrote:don't know if your implementation will work on hardware, so... which hardware did you run SFA2 and SO?
I run its on my FPGA SNES, my board with LCD 5" 800x480 RGB. I've never seen a real console :(

magno wrote:As for ROM access, 3 master cycles is the miminum for FastROM, since that means 139ns time access. FastROM is slower than 120ns, so 3 master cycles is the proper time access for SDD1 core.
For ROM I use two SRAM 4Mx8 55ns, therefore it works on 2 cycles.
magno
Posts: 193
Joined: Tue Aug 15, 2006 5:23 am
Location: Spain
Contact:

Re: SDD1 FGPA implementation

Post by magno »

srg320 wrote: I run its on my FPGA SNES, my board with LCD 5" 800x480 RGB. I've never seen a real console :( .
Oh, do you mean SuperNT maybe? Or did you implement full SNES in an FPGA? That would be great then!

srg320 wrote:For ROM I use two SRAM 4Mx8 55ns, therefore it works on 2 cycles.
But you don't enable the ROM from your SDD1 implementation, there is no ROM_CS nor ROM_OE, which are necessary even if you use SRAM as ROM...
And anyway, you need SRAM for Star Ocean. Some variables used by the audio engine are stored in SRAM, so if no SRAM is present, the game hungs. In your S-DD1 implementation, there isn't any SRAM_CS, so... how do you enable SRAM? If SRAM is not enabled, then those variables can't be read by the audio engine and StarOcean wouldn't work...
srg320
Posts: 32
Joined: Fri Feb 16, 2018 5:52 am
Location: Ukraine

Re: SDD1 FGPA implementation

Post by srg320 »

magno wrote: Or did you implement full SNES in an FPGA? That would be great then!
Yes.
magno wrote:But you don't enable the ROM from your SDD1 implementation, there is no ROM_CS nor ROM_OE, which are necessary even if you use SRAM as ROM...
And anyway, you need SRAM for Star Ocean. Some variables used by the audio engine are stored in SRAM, so if no SRAM is present, the game hungs. In your S-DD1 implementation, there isn't any SRAM_CS, so... how do you enable SRAM? If SRAM is not enabled, then those variables can't be read by the audio engine and StarOcean wouldn't work...
Of course SRAM is present, 8 Mbyte split by 6 Mbyte for ROM and 2 Mbyte (used 8Kbyte) for backup SRAM. When I'm home, I'll post its source.
magno
Posts: 193
Joined: Tue Aug 15, 2006 5:23 am
Location: Spain
Contact:

Re: SDD1 FGPA implementation

Post by magno »

srg320 wrote:
magno wrote: Or did you implement full SNES in an FPGA? That would be great then!
Yes.
Great!! It would be nice there were some open-sorce projects for SNES FPGA implementation. It could be use for homebrew, getting the most of SNES system, adding features...

magno wrote:Of course SRAM is present, 8 Mbyte split by 6 Mbyte for ROM and 2 Mbyte (used 8Kbyte) for backup SRAM. When I'm home, I'll post its source.
Maybe there is something I missed or you don't understand what I mean :)
S-DD1 chip is the address decoder for ROM and backup SRAM in the real cartridge, and so it should be in your FPGA design (there can't be 2 address decoders driving the same signals), so anytime CPU accesses ROM or backup SRAM, S-DD1 decodes the address and then reads ROM or backup SRAM.
In your SDD1 implementation, there isn't any output signal for enabling ROM access, even if you implement ROM in SRAM chips, so if SNES reads from $C0:8001... how do you enable ROM to read from it? There isn't such signal in your design.
As for backup SRAM, the same happens... But in this case, if CPU reads from backup SRAM to get some data needed by audio engine, your S-DD1 implementation won't decode the backup SRAM address, so the CPU won't get the proper data. Then, the audio engine will stall, and Star Ocean will freeze. In your videos, Star Ocean runs fine, so there is something weird on that...
srg320
Posts: 32
Joined: Fri Feb 16, 2018 5:52 am
Location: Ukraine

Re: SDD1 FGPA implementation

Post by srg320 »

magno wrote:Great!! It would be nice there were some open-sorce projects for SNES FPGA implementation. It could be use for homebrew, getting the most of SNES system, adding features...
In the future I want to do something like hardware debugger via USB. Scheme of my board is applied.
magno wrote:Maybe there is something I missed or you don't understand what I mean :)
S-DD1 chip is the address decoder for ROM and backup SRAM in the real cartridge, and so it should be in your FPGA design (there can't be 2 address decoders driving the same signals), so anytime CPU accesses ROM or backup SRAM, S-DD1 decodes the address and then reads ROM or backup SRAM.
In your SDD1 implementation, there isn't any output signal for enabling ROM access, even if you implement ROM in SRAM chips, so if SNES reads from $C0:8001... how do you enable ROM to read from it? There isn't such signal in your design.
As for backup SRAM, the same happens... But in this case, if CPU reads from backup SRAM to get some data needed by audio engine, your S-DD1 implementation won't decode the backup SRAM address, so the CPU won't get the proper data. Then, the audio engine will stall, and Star Ocean will freeze. In your videos, Star Ocean runs fine, so there is something weird on that...
xxxmap.vhdl files implement cartridge interface.
Attachments
sch.pdf
(1.6 MiB) Downloaded 363 times
mappers.rar
(4.33 KiB) Downloaded 368 times
magno
Posts: 193
Joined: Tue Aug 15, 2006 5:23 am
Location: Spain
Contact:

Re: SDD1 FGPA implementation

Post by magno »

srg320 wrote:xxxmap.vhdl files implement cartridge interface.
Ahh, ok, ok. You see? I missed something! :mrgreen: In the first files you shared, there wasn't any interface for controlling ROM or SRAM, so that implementation could never work, whatever the implementation of the SNES (real hardware or FPGA). I see your mapper is the top wrapper for SDD1 core, now it makes more sense.
How did you resolve finally SNES CPU / SDD1 core collision after writing to $4801?
srg320
Posts: 32
Joined: Fri Feb 16, 2018 5:52 am
Location: Ukraine

Re: SDD1 FGPA implementation

Post by srg320 »

magno wrote:How did you resolve finally SNES CPU / SDD1 core collision after writing to $4801?
SDD1 accesses ROM when both CPURD and CPUWR in high level, it takes 3 master cycles always. Thus, one CPU cycle is one ROM reading for SDD1. After writing to $4801 and before starting DMA are 9-10 CPU cycles. I use first 6 for loading compressed data: 1 for header and current data, 1 for next data, 4 to fifo.

If I say something wrong, please correct me.
magno
Posts: 193
Joined: Tue Aug 15, 2006 5:23 am
Location: Spain
Contact:

Re: SDD1 FGPA implementation

Post by magno »

srg320 wrote: Thus, one CPU cycle is one ROM reading for SDD1.
Nop, a CPU cycle is 6 master clocks in FastROM, or 8 master clocks in SlowROM (not the case). The read cycle is just a portion of 1 CPU cycle.
srg320 wrote:
After writing to $4801 and before starting DMA are 9-10 CPU cycles. I use first 6 for loading compressed data: 1 for header and current data, 1 for next data, 4 to fifo.
Nop, after writing to $4801, there are several CPU cycles before starting DMA. In Star Ocean, the sequence is:

Code: Select all

1) STA $4801 -> 4 CPU cycles
2) PHA -> 3 CPU cycles
3) PLA  -> 4 CPU cycles
4) STA $420B  -> 4 CPU cycles
5) DMA triggers now after some master cycles
In steps 2 to 4, there could be collision when CPU fetches the instruction and SDD1 reads compressed data.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: SDD1 FGPA implementation

Post by tepples »

Could the S-DD1 be prefetching the PHA during the $4801 write cycle and the PLA during the "internal operation" cycles of PHA?

Or could the S-DD1 be accessing memory during the half-cycle when the 65816 isn't accessing memory? I know the Apple II and Commodore 64 access RAM at 2.04 MHz even though the 6502 in those computers is only 1.02 MHz, as the video circuit gets priority during M2 low phase.
srg320
Posts: 32
Joined: Fri Feb 16, 2018 5:52 am
Location: Ukraine

Re: SDD1 FGPA implementation

Post by srg320 »

Can so you will understand that I mean
Документ1.png
srg320
Posts: 32
Joined: Fri Feb 16, 2018 5:52 am
Location: Ukraine

Re: SDD1 FGPA implementation

Post by srg320 »

tepples wrote:Could the S-DD1 be prefetching the PHA during the $4801 write cycle and the PLA during the "internal operation" cycles of PHA?
SFA2 instead PHA PLA uses:

Code: Select all

STA $00
STA $00
and

Code: Select all

LDY $00
LDY $00
magno
Posts: 193
Joined: Tue Aug 15, 2006 5:23 am
Location: Spain
Contact:

Re: SDD1 FGPA implementation

Post by magno »

srg320 wrote:Can so you will understand that I mean
Документ1.png
I understand what you say, but that timing diagram is not correct. Address bank appears on data bus at most 33ns after PHI2 falling edge (your signals are rising-edge-aligned, but I think the correct is falling-edge as in PHI2). This byte is latched and after latching, it is decoded to generate CPU_RD and CPU_WR. Latch's propagation time is at most 36 ns (assuming 74LS573 as latch, although this logic is implemented inside 5A22, so probably is less), so that makes 69 ns after PHI2 falling edge; 69 ns is 3 master cycles. But read data hold (tDHR) is 10 ns, so CPU_RD will be '1' at most 3 master cycles. Assuming CPU_RD will be always 3 cycles long in '1' state could be dangerous.

Of course, all this applies to real hardware, not FPGA SNES implementation.
srg320
Posts: 32
Joined: Fri Feb 16, 2018 5:52 am
Location: Ukraine

Re: SDD1 FGPA implementation

Post by srg320 »

Thanks magno, you are the only one who gives very useful information. I have little experience in this.
magno wrote:Address bank appears on data bus at most 33ns after PHI2 falling edge (your signals are rising-edge-aligned, but I think the correct is falling-edge as in PHI2). This byte is latched and after latching, it is decoded to generate CPU_RD and CPU_WR. Latch's propagation time is at most 36 ns (assuming 74LS573 as latch, although this logic is implemented inside 5A22, so probably is less), so that makes 69 ns after PHI2 falling edge; 69 ns is 3 master cycles. But read data hold (tDHR) is 10 ns, so CPU_RD will be '1' at most 3 master cycles. Assuming CPU_RD will be always 3 cycles long in '1' state could be dangerous.
You can point me where I can find out more about it, links or books?
magno
Posts: 193
Joined: Tue Aug 15, 2006 5:23 am
Location: Spain
Contact:

Re: SDD1 FGPA implementation

Post by magno »

srg320 wrote:Thanks magno, you are the only one who gives very useful information. I have little experience in this.
Thanks to you! It is really nice to have such technical conversation with people who know what they are talking about.
I read all this information in the W65C816S datasheet from Western Digital (year 2010); table 4-2 has the timings for 5Vcc (even if the column say "14MHz", those timings apply because they are related to Vcc, not the maximum frequency). Figure 5-1 shows the bank latching circuit, the one I think SNES is based in too.
srg320
Posts: 32
Joined: Fri Feb 16, 2018 5:52 am
Location: Ukraine

Re: SDD1 FGPA implementation

Post by srg320 »

magno wrote:I read all this information in the W65C816S datasheet from Western Digital (year 2010); table 4-2 has the timings for 5Vcc (even if the column say "14MHz", those timings apply because they are related to Vcc, not the maximum frequency). Figure 5-1 shows the bank latching circuit, the one I think SNES is based in too.
Found, I will study.

In the near future I plan to solder the cartridge slot and I will try to connect a real cartridge.
Post Reply