MiSTer FPGA Forum

I created a test branch to access a secondary SD card from the PCXT core.
The SD card can be used by setting the "MMC" option in the OSD menu to "Enable" and performing a reset.
SD card works as a secondary IDE(KFMMCIDE00000).

Note that this is a test branch.
I am testing with a 2GB SDSC and do not know if other devices will work properly.
I would recommend making a backup before testing.

https://github.com/kitune-san/PCXT_MiST ... mmc_access

kitune-san wrote: ↑Sat Feb 25, 2023 4:21 pm

I created a test branch to access a secondary SD card from the PCXT core.
The SD card can be used by setting the "MMC" option in the OSD menu to "Enable" and performing a reset.
SD card works as a secondary IDE(KFMMCIDE00000).

Note that this is a test branch.
I am testing with a 2GB SDSC and do not know if other devices will work properly.
I would recommend making a backup before testing.

https://github.com/kitune-san/PCXT_MiST ... mmc_access

PCXT_MMC_TEST.zip

2023-02-26 011723.png
2023-02-26 011457.png

Thank you! I'll definitely try it out as soon as I have some time.

kitune-san wrote: ↑Sat Feb 25, 2023 4:21 pm

I created a test branch to access a secondary SD card from the PCXT core.
The SD card can be used by setting the "MMC" option in the OSD menu to "Enable" and performing a reset.
SD card works as a secondary IDE(KFMMCIDE00000).

Note that this is a test branch.
I am testing with a 2GB SDSC and do not know if other devices will work properly.
I would recommend making a backup before testing.

https://github.com/kitune-san/PCXT_MiST ... mmc_access

PCXT_MMC_TEST.zip

2023-02-26 011723.png
2023-02-26 011457.png

Thanks, great job.

The secondary SD port of the MiSTer does not have a pull-up resistor, so the FPGA's internal pull-up resistor is enabled.
The clock of the SD card is running at 0.5 MHz because of the high resistance of the internal pull-up resistor.

If we could connect a pull-up resistor of about 10kΩ, similar to the primary SD card, secandary sd could run it a bit faster.

I've been testing it... generally speaking it works well. But I think there is some problem in the write, in relation to performance or some kind of command.

For example, I have a 16Gb card with a 512Mb partition and various content. I have observed slowness when writing or deleting a file... then I have tried with another 2Gb card, also with 512Mb partition and it works fine, apparently... because entering the FDISK and trying to do some operation from there, it has been hung in the section of creating a partition.

You will tell us something about it, at the moment, I will be doing the port of this development to the ZXUno, so that it works directly with the SD, instead of serdrive... I will tell you the results.

512 MB is cutting it quite close to being an astronomically humongous hard drive for an XT. Are you sure the BIOS handles its geometry correctly? That said, FDISK hardly does anything at all I/O wise so that should be fast to complete.

I will investigate the cause of the problem. It will take time to resolve the issue.

spark2k06 wrote: ↑Sun Feb 26, 2023 8:08 am

I will be doing the port of this development to the ZXUno, so that it works directly with the SD, instead of serdrive... I will tell you the results.

If pull-up is connected to the SD ports of the ZXUno, try the following changes.
It may improve the access speed.

kitune-san wrote: ↑Sun Feb 26, 2023 10:01 am

spark2k06 wrote: ↑Sun Feb 26, 2023 8:08 am

I will be doing the port of this development to the ZXUno, so that it works directly with the SD, instead of serdrive... I will tell you the results.

If pull-up is connected to the SD ports of the ZXUno, try the following changes.
It may improve the access speed.

2023-02-26 185822.png

When I get to the TOP file, I have seen that in ZXUno we only have the following signals available:

# SD/MMC
NET "sd_cs_n" LOC="P59" | IOSTANDARD = LVCMOS33;
NET "sd_clk"  LOC="P75" | IOSTANDARD = LVCMOS33;
NET "sd_mosi" LOC="P74" | IOSTANDARD = LVCMOS33;
NET "sd_miso" LOC="P78" | IOSTANDARD = LVCMOS33;

Would it be necessary to make an intermediate module for SPI usage?

Okay, I see that I have to use this module:

Let me see if I understand how to hook the signals to it, because the module has others as well.

sd_clk=SDIO_CLK
sd_mosi=SDIO_CMD
sd_miso=SDIO_DATA0
DAT1-3=HIGH

Sorry, I do not maintain the SPI module, so I cannot give you proper advice at this time.

kitune-san wrote: ↑Sun Feb 26, 2023 11:27 am

Sorry, I do not maintain the SPI module, so I cannot give you proper advice at this time.

All right, don't worry. Thanks

If this point is 3.3V, then the same module as the MiSTer should be available.

kitune-san wrote: ↑Sun Feb 26, 2023 11:39 am

If this point is 3.3V, then the same module as the MiSTer should be available.

2023-02-26 203820.png

In the original ZXUno project it is as you see it... in other projects I have seen, they are not connected to anything... not even to resistors.

I don't really know why.

https://zxuno.speccy.org/ficheros/zxuno_v41_sch.pdf

By the way, this synthesized fine... but now I don't have time to test if it works, I'll let you know:

   
   

   ... output reg		SD_n_CS = 1,
   

   //
   ///////////////////////   MMC     ///////////////////////
   //
   wire mmc_clk;
   wire mmc_cmd_in;
   wire mmc_cmd_out;
   wire mmc_cmd_io;
   wire mmc_dat_in;
   wire mmc_dat_out;
   wire mmc_dat_io;
	
   assign  SD_CK    = mmc_clk;
   assign  SD_DI    = (~mmc_cmd_io & ~mmc_cmd_out) ? 1'b0 : 1'bz;
   assign  mmc_cmd_in  = SD_DI;

   assign  mmc_dat_in = (~mmc_dat_io & ~mmc_dat_out) ? 1'b0 : 1'bz;
   assign  SD_DO = mmc_dat_in;

spark2k06 wrote: ↑Sun Feb 26, 2023 11:51 am

kitune-san wrote: ↑Sun Feb 26, 2023 11:39 am

If this point is 3.3V, then the same module as the MiSTer should be available.

2023-02-26 203820.png

In the original ZXUno project it is as you see it... in other projects I have seen, they are not connected to anything... not even to resistors.

I don't really know why.

https://zxuno.speccy.org/ficheros/zxuno_v41_sch.pdf

I saw the artwork.
https://zxuno.speccy.org/ficheros/zxuno_v41_pcb.pdf

It seems to be connected to 3.3V, so I don't see a problem.

not even to resistors.!?

kitune-san wrote: ↑Sun Feb 26, 2023 11:57 am

spark2k06 wrote: ↑Sun Feb 26, 2023 11:51 am

kitune-san wrote: ↑Sun Feb 26, 2023 11:39 am

If this point is 3.3V, then the same module as the MiSTer should be available.

2023-02-26 203820.png

In the original ZXUno project it is as you see it... in other projects I have seen, they are not connected to anything... not even to resistors.

I don't really know why.

https://zxuno.speccy.org/ficheros/zxuno_v41_sch.pdf

I saw the artwork.
https://zxuno.speccy.org/ficheros/zxuno_v41_pcb.pdf

It seems to be connected to 3.3V, so I don't see a problem.
2023-02-26 205418.png

ZXUno+:

Apparently, according to my research, MMC's DAT1-7 is pulled up inside the card.
Probably the same for SD cards.

spark2k06 wrote: ↑Sun Feb 26, 2023 8:08 am

... because entering the FDISK and trying to do some operation from there, it has been hung in the section of creating a partition.

ATA Command 0x40 was incorrectly implemented.
This is probably why fdisk stops.

Ok, when it's fixed I'll try it... no hurry. I have not yet been able to test in conditions the implementation of the SPI signals, it is not working for me but I have not been able to debug it yet... to make things easier, I have created a branch that starts from yours for its implementation in MiSTer:

https://github.com/MiSTer-devel/PCXT_Mi ... access_spi

To make use of the SPI signals as it is done for example in the OndraSPO186 core:

https://github.com/MiSTer-devel/OndraSPO186_MiSTer

	//SD-SPI
	output        SD_SCK,
	output        SD_MOSI,
	input         SD_MISO,
	output        SD_CS,
	input         SD_CD,

Here you can see that similar signals are used regarding to ZXUno. But I have not yet been able to check how the PULLUP, clocks and other related issues are set. If I can, I'll prepare it in a moment, and if it doesn't work I'll let you know and see if you can keep an eye on it.

I upload modified version of the Verify command.

The write speed took 17ms per 512bytes on my chip (SDSC 2GB).
512/17ms = 30kByte/s.
If clock speed could be increased, I think it could be improved a little more.

I believe that native mode (same implementation as MiSTer) can be used with ZXUno without the need to implement SPI.

I will look for ZXUno to see if I can buy it (and deliver it to Japan).

During the week I will have very little time, but later I will share the ZXUno project (well, actually I am testing with a clone of it, the UnoXT), to see if, despite being a xilinx project, I can... you see something that I don't see regarding the allocation of the SD signals nothing else....

kitune-san wrote: ↑Mon Feb 27, 2023 3:13 pm

I believe that native mode (same implementation as MiSTer) can be used with ZXUno without the need to implement SPI.

I will look for ZXUno to see if I can buy it (and deliver it to Japan).

Here would be the commit of changes related to the KFMMC implementation, so you can look only at the changes, and nothing else, to focus on them. It synthesizes, but the unit is not recognized by XTIDE, it remains to debug in depth... but maybe you can provide me some clue:

https://github.com/spark2k06/PCXT_ZXUno ... 758fa4f151

The technical features of this improved but compatible ZXUno clone:

https://gitlab.com/emax73g/unoxt-hardwa ... ain/scheme

Originally, the signals in the UCF file are defined as follows:

NET 'sd_cs0_n_o' LOC='E16' |IOSTANDARD = LVTTL;
NET 'sd_sclk_o' LOC='F16' |IOSTANDARD = LVTTL;
NET 'sd_mosi_o' LOC='F15' |IOSTANDARD = LVTTL;
NET 'sd_miso_i' LOC='G14' |IOSTANDARD = LVTTL |PULLUP;

I have also tried assigning PULLUP to the sd_mosi_o signal, but with the same result.

Thanks for the information.
The port input/output settings need to be reviewed.
In native mode change some ports to inout.
I will write down the specific changes after I finish today's work.

kitune-san wrote: ↑Mon Feb 27, 2023 11:58 pm

Thanks for the information.
The port input/output settings need to be reviewed.
In native mode change some ports to inout.
I will write down the specific changes after I finish today's work.

Okay, thank you. However, even if the SD reading does not work. XTIDE should not show at least the KFMMCIDE identifier? This is provided by the IDE module...but even that is not shown. Which leads me to think that in addition, something else I have not taken into account in the port.

By the way, I had to convert the KFMMC implementation from SystemVerilog to Verilog with an application, for compatibility with ISE Xilinx... just in case something has been converted incorrectly.

At this time, if the SD card is not recognized, the KFMMCIDE identifier will not be displayed.
I'm busy and will continue later.

kitune-san wrote: ↑Tue Feb 28, 2023 4:51 am

At this time, if the SD card is not recognized, the KFMMCIDE identifier will not be displayed.
I'm busy and will continue later.

Understood, thanks for the information.

kitune-san wrote: ↑Mon Feb 27, 2023 3:05 pm

I upload modified version of the Verify command.
PCXT_MMC_TEST_2.zip
The write speed took 17ms per 512bytes on my chip (SDSC 2GB).
512/17ms = 30kByte/s.
If clock speed could be increased, I think it could be improved a little more.

20230227-0002_01.png

Despite that performance during writing, it seems that at least there are no more problems in writing on my 16Gb card with 512Mb partition. However, in addition to continuing the hang problem in FDISK, it also seems to hang during a performance test with CheckIT3 (at 4.77MHz):

After waiting a long time, this is the result:

And now let's compare it with the IDE integrated in the Main of MiSTer:

In any case, for other FPGAs, I still think that in the current state this is already much better than dealing with serdrive, especially at the basic user level .