The CPLD bitstream configures SD card as unit 1

[oO-cozy-Oo]

The CPLD bitstream configures SD card as unit 1, which is unusual. Typically single drive is configured as unit 0 and existing configuration breaks a few things here and there. I've traced the relevant code in the verilog source, so I think the required change may be as simple as altering one character, file divmmc_mcleod.v line #233:

--- divtiesus_maple-master/cpld/divmmc_mcleod.v 2025-09-24 23:55:13.000000000 +0100
+++ divtiesus_maple-fix/cpld/divmmc_mcleod.v 2026-01-20 19:05:12.000000000 +0000
@@ -230,7 +230,7 @@
DIVSPI = 8'hEB; // Puertos del DIVMMC

reg [1:0] sdpincs = 2'b11;
- assign sd_cs0_n = sdpincs[1];
+ assign sd_cs0_n = sdpincs[0];
//assign sd_cs1_n = sdpincs[1];

// Control del pin CS de la SD

 A quick way to verify: launch `.dskprobe` under esxdos. You normally should see sda, sda1 (and other partitions, if you have them), but right now you see sdb, sdb1 and so on


Cheers

Rich

[player-one-ready]

I've done some additional analysis and here is what I think after examining the source tree and experimenting.

Commit 19d2a5b "Bad SD workaround" mapped card's CS signal to the bit controlling unit 1 (the second one) -- sd_cs0_n = sdpincs[1]. While esxdos can handle it more or less transparently because it adds translation layer and re-maps physical devices (sdX) to logical volumes (hdN), +3e struggles with such unusual assignment. To clarify, +3e itself does not really care, but most of the applications hardcode unit 0, which is expressed as the lack of unit at all. Therefore, the code mapping partitions breaks as +3e syntax has no provisions for "the current unit" because "no unit specified" means "unit 0, implicitly" and virtually everyone has only unit 0 attached. Potentially, programmes accessing DivMMC registers directly may be affected, too.

NOTE: do not confuse it with "Soft +3e" implemented in the original DivTiesus, it has nothing to do with that and technically not limited in scope to +3e at all, +3e is just the most badly affected environment.

Since there was a separate commit introducing this breaking change, I assume there was a reason. Could you please let us know, why such unusual arrangement was added? It does not seem to be always required¹, could you please share when it is necessary? When is it safe to map SD card back to unit 0?

I would suggest re-mapping card back to unit 0, if possible, or at least clearly describe such unusual behaviour in the README.md. This is the one of rare DivXXX units that is actually available and potentially compatible with +3e. But unless it exposes unit 0 by default it is mostly useless in +3e environment. If, for whatever reason, that limitation cannot be removed, I think we have to document it.

Footnotes

1. I've managed to compile and program the code with original assign sd_cs0_n = sdpincs[0]; (single line change, divmmc_mcleod.v line 233). It seems to be working fine on original +3 with +3e ROMs, so far esxdos, +3e and programmes accessing DivMMC ports directly are working as expected (obviously, I only managed to test a few). It also works with original toastrack. However, my DivTiesus device has no WiFi module and I have no plans on adding one. ↩

[anarsoul]

I did it on purpose to unbreak my microSDs from Aliexpress that have an issue with SPI mode - they seem to react on some commands even if CS is not asserted, and as a result they end up broken when esxDOS probes CS1 with no card on it. They work fine as CS1 though

[player-one-ready]

@anarsoul, when replying, could you please let us know if you see my comments or you reply to @oO-cozy-Oo 's comments. And thank you for additional context. For clarity I am going to quote the message I am replying to.

I did it on purpose to unbreak my microSDs from Aliexpress that have an issue with SPI mode - they seem to react on some commands even if CS is not asserted, and as a result they end up broken when esxDOS probes CS1 with no card on it. They work fine as CS1 though

I think if it's a workaround for a specific (and known to be broken) SD card, I would say it's definitely worth reverting it back to the default behaviour. Perhaps, making a build with unusual setup, for those who need to use those broken card (most of us would simply throw them in the bin). It's probably safe to say it was an exceptional situation, not a lot of Speccy/DivMMC users encountered. Not to mention that those cards won't work with other devices for those rare owners of two physical card slots.

But.. Isn't not driving SPI data when card 0 is not selected be a better solution? I think we can have the original logic and the workaround you had to use. Of course, I do not have any broken cards, so I cannot test if it actually resolves the issue. It surely does not break anything and restores +3e compatibility. Tested on +3, toastrack, Grey +2 and original 48k.

So I would suggest:

1. reverting "Bad SD Card workaround" or even applying the following patch to highlight the fact that only bit 0 is used (note: still both input bits analysed din[1:0] != 2'b00). I think compiler optimises "out" the unused bits anyway, but IMHO it's better to spell it out in the code:

 cpld/divmmc_mcleod.v | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/cpld/divmmc_mcleod.v b/cpld/divmmc_mcleod.v
index 2c1347f..6bd4bb2 100644
--- a/cpld/divmmc_mcleod.v
+++ b/cpld/divmmc_mcleod.v
@@ -229,17 +229,17 @@ module sd_card_control (
    DIVCS   = 8'hE7,   //
    DIVSPI  = 8'hEB;   // Puertos del DIVMMC

-  reg [1:0] sdpincs = 2'b11;
-  assign sd_cs0_n = sdpincs[1];
+  reg sdpincs = 1'b1;
+  assign sd_cs0_n = sdpincs;
   //assign sd_cs1_n = sdpincs[1];

   // Control del pin CS de la SD
   wire iorq_wr = iorq_n | wr_n;
   always @(posedge iorq_wr or negedge rst_n) begin
     if (rst_n == 1'b0)
-      sdpincs <= 2'b11;
+      sdpincs <= 1'b1;
     else if (a == DIVCS && din[1:0] != 2'b00)
-      sdpincs <= din[1:0];
+      sdpincs <= din[0]; // we only use the first card
   end

   // Control del modulo SPI
--

2. Suppress chatter on the SPI lines unless SEL is asserted:

 cpld/divmmc_mcleod.v | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/cpld/divmmc_mcleod.v b/cpld/divmmc_mcleod.v
index fc0d329..47c2c5e 100644
--- a/cpld/divmmc_mcleod.v
+++ b/cpld/divmmc_mcleod.v
@@ -246,9 +246,10 @@ module sd_card_control (
   reg recibir_dato;
   reg enviar_dato;

+  wire spi_io = (a==DIVSPI && !sd_cs0_n && !iorq_n);
   always @* begin
-    recibir_dato = (a==DIVSPI && !rd_n && !iorq_n);
-    enviar_dato  = (a==DIVSPI && !wr_n && !iorq_n);
+    recibir_dato = (!rd_n && spi_io);
+    enviar_dato  = (!wr_n && spi_io);
   end

   // Instanciacion del modulo SPI
--

[player-one-ready]

FYI, here is the full set of proposed changes: https://github.com/player-one-ready/divtiesus_maple/tree/fix/latest (working copy and pre-compiled binaries here: https://codeberg.org/player-one/divtiesus_maple)