PCXT Core Access to Secondary SD Card

[kitune-san]

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

2023-02-26 011723.png (34.49 KiB) Viewed 17621 times

2023-02-26 011457.png (106.22 KiB) Viewed 17621 times

[spark2k06]

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.

[Mills]

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.

[kitune-san]

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.

2023-02-25 014352.png (35.1 KiB) Viewed 17359 times

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.

de0-nano-sd-socket.png (109.18 KiB) Viewed 17359 times

[spark2k06]

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.

[Bas]

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.

[kitune-san]

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

[kitune-san]

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 (30.73 KiB) Viewed 17230 times

[spark2k06]

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:

Code: Select all

# 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;

SDCard ZXUno.png (12.14 KiB) Viewed 17188 times

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

[spark2k06]

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

SPI.png (18.35 KiB) Viewed 17185 times

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

[kitune-san]

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

[kitune-san]

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

[spark2k06]

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

All right, don't worry. Thanks

[kitune-san]

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

2023-02-26 203820.png (135.8 KiB) Viewed 17138 times

[spark2k06]

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:

Code: Select all

   
   

   ... 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;

[kitune-san]

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 (88.25 KiB) Viewed 17095 times

[kitune-san]

not even to resistors.!?

[spark2k06]

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+:

ZXUno+.png (9.63 KiB) Viewed 17086 times

[kitune-san]

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

[kitune-san]

... 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.

[spark2k06]

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

Code: Select all

	//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.

[kitune-san]

I upload modified version of the Verify command.

PCXT_MMC_TEST_2.zip

(1.4 MiB) Downloaded 254 times

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 (91.72 KiB) Viewed 16697 times

[kitune-san]

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).

[spark2k06]

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....

[spark2k06]

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:

Code: Select all

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.

[kitune-san]

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.

[spark2k06]

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.

[kitune-san]

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

[spark2k06]

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.

[spark2k06]

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):

KFMMC-IDE_01.png (46.11 KiB) Viewed 17132 times

After waiting a long time, this is the result:

KFMMC-IDE_02.png (77.04 KiB) Viewed 17132 times

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

MiSter-IDE.png (78.67 KiB) Viewed 17132 times

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 .