It is currently Sun Dec 16, 2018 12:18 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Wed Aug 01, 2018 12:43 am 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 29
Location: Ukraine
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.


Top
 Profile  
 
PostPosted: Wed Aug 01, 2018 12:55 am 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
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...


Top
 Profile  
 
PostPosted: Wed Aug 01, 2018 1:12 am 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 29
Location: Ukraine
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.


Top
 Profile  
 
PostPosted: Wed Aug 01, 2018 1:27 am 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
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...


Top
 Profile  
 
PostPosted: Wed Aug 01, 2018 4:16 am 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 29
Location: Ukraine
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 105 times
mappers.rar [4.33 KiB]
Downloaded 102 times
Top
 Profile  
 
PostPosted: Wed Aug 01, 2018 10:01 pm 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
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?


Top
 Profile  
 
PostPosted: Thu Aug 02, 2018 4:45 am 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 29
Location: Ukraine
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.


Top
 Profile  
 
PostPosted: Thu Aug 02, 2018 5:38 am 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
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:
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.


Top
 Profile  
 
PostPosted: Thu Aug 02, 2018 6:41 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20883
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Thu Aug 02, 2018 6:51 am 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 29
Location: Ukraine
Can so you will understand that I mean
Attachment:
Документ1.png
Документ1.png [ 12.85 KiB | Viewed 2358 times ]


Top
 Profile  
 
PostPosted: Thu Aug 02, 2018 7:24 am 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 29
Location: Ukraine
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:
STA $00
STA $00

and
Code:
LDY $00
LDY $00


Top
 Profile  
 
PostPosted: Thu Aug 02, 2018 10:51 am 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
srg320 wrote:
Can so you will understand that I mean
Attachment:
Документ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.


Top
 Profile  
 
PostPosted: Thu Aug 02, 2018 11:15 am 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 29
Location: Ukraine
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?


Top
 Profile  
 
PostPosted: Thu Aug 02, 2018 12:06 pm 
Offline

Joined: Tue Aug 15, 2006 5:23 am
Posts: 193
Location: Spain
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.


Top
 Profile  
 
PostPosted: Thu Aug 02, 2018 12:18 pm 
Offline

Joined: Fri Feb 16, 2018 5:52 am
Posts: 29
Location: Ukraine
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 59 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 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