Fuse - the Free Unix Spectrum Emulator / Feature Requests / #107 DivMMC support

Description has changed:

Diff:

--- old
+++ new
@@ -1 +1,3 @@
 From Andrew Owen on Facebook: "Right now the feature I'd really like is divMMC support. I just can't get on with the debugger in ZEsarUX."
+
+More details are in the thread at http://board.esxdos.org/viewtopic.php?id=18, of which the crucial comment is probably "I can't help you much with the hardware side of things, but the DivMMC is basically a DivIDE with MMC replacing the IDE bits, and with access to 128k->512k of SRAM instead of 32k."

Sergio Baldoví - 2017-02-27

Original DivMMC schematics:
http://aticatac.altervista.org/portale/?q=node/13

Manual of DivMMC EnJoy! enhaced interface:
http://benophetinternet.nl/hobby/vanmezelf/DivMMC%20EnJOY!%202014.1%20+%20ESXDOS%200.8.5%20Manual.pdf

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philip Kendall - 2017-07-21

Cribbing from the ZEsarUX source (mostly operaciones.c):

Port 0xe3 (mask 0xff, write-only): control port, exactly as DivIDE

Port 0xe7 (mask 0xff, write-only): MMC card select

Port 0xeb (mask 0xff, read/write): read/write MMC data
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philip Kendall - 2017-08-03

Good progress on this: with the latest changes, we can now boot ESXDOS on DivMMC and load in TAP files.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sergio Baldoví - 2017-08-06

Looks brilliant! I've digged into the MMC/SDC internals [1] and found out that some cards use byte addressing (SDSC) while others use block addressing (SDHC). As esxdos supports MMC/SD/SDHC, it tests the card capabilities in the initialisation, maybe something similar to [2]. CMD8 success return determines SD spec v2 and bit 30 (CSS) of CMD58 determines a high-capacity card (SDHC) with block addressing and fixed 512 bytes per block.

I'm not sure if the implementation aims to insert a SDHC card as the SCD command returns 12 bits for C_SIZE (1.0). IMHO READ_OCR should not set the CSS bit.

[1] http://elm-chan.org/docs/mmc/mmc_e.html
[2] http://elm-chan.org/docs/mmc/pic/sdinit.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philip Kendall - 2017-08-08

Thanks Sergio - been reading a lot of MMC and SD docs myself recently ;-)

Big thanks for pointing out the block addressing thing - explains my very confused TODO at mmc.c:232!

Was sort of aiming for pretending to be an SDHC card, but you're right in that case we should consider more than 12 bits of C_SIZE - from my reading of the spec, we should go for 16 bits (22 bits minus the 6 bits at the top which are specified as always being zero for SDHC cards). Do you think that would make everything consistent?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Sergio Baldoví - 2017-08-08
  
  Do you think that would make everything consistent?
  
  Yes, we should stick to CSD Version 2.0 if we emulate SDHC cards, specially with more than 2 Gb:
  
  "High Capacity SD Memory Card is newly defined from the Physical Layer Specification Version 2.00"
  
  "Only hosts that are compliant to the Physical Layer Specification version 2.00 or higher and the SD File System Specification Ver2.00 can access High Capacity SD Memory Cards. Other hosts fail to initialize High Capacity SD Memory Cards"
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
  - Philip Kendall - 2017-08-08
    
    Thanks Sergio, added to the todo list on the wiki just as it's time for me to go to bed :-)
    
    If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philip Kendall - 2017-08-08

If anybody is at a loose end and wants some small tasks to help out with this, there's a collected list of TODOs in the release plan. Please edit to note if you're working on a particular point to avoid duplicated effort!

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philip Kendall - 2017-08-10

OK, I've done a lot of code tidy up in the past few days. A couple of bits where I'd appreciate some guidance on the way forwards:

At the moment, the DivMMC is under the Media/IDE menu branch. This is wrong, but should we a) rename "IDE" to "Mass Storage" or something similar b) Create a new "Media/MMC" menu item? c) Something else?

For snapshot support, what we save for the DivMMC will be exactly identical to what we save for the DivIDE, apart from with a few more RAM pages. Should we create a new SZX block type for the DivMMC or add a flag to the current DivIDE block?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sergio Baldoví - 2017-08-13

At the moment, the DivMMC is under the Media/IDE menu branch. This is wrong, but should we a) rename "IDE" to "Mass Storage" or something similar b) Create a new "Media/MMC" menu item? c) Something else?

a) Looks good to me.
b) IMO "Memory card" would be the equivalent to tape/disk, not attached to any standard.

For snapshot support, what we save for the DivMMC will be exactly identical to what we save for the DivIDE, apart from with a few more RAM pages. Should we create a new SZX block type for the DivMMC or add a flag to the current DivIDE block?

Not sure about of this. The SZX format aims for hardware description. There are several variants of DivMMC: one/two cards, without EEPROM, etc. and the block should not be tied to the Fuse implementation. Selected card is a new register that worth to be stored. IMO supporting snaspshots in the middle of a command execution is to much hassle, a warning could prompt out if the card is not waiting for a command. Idle card state is likely a status to be flagged. No sure about the type of memory card (SD/SDHC/MMC), block size and alike.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sergio Baldoví - 2017-08-14

I partially know why write operations don't work with 128 Kb of RAM. At some point D3 is written to the control port register. That means CONMEM + MAPRAM + page 19. There are only 16 pages so page 3 is mapped as writeable and gets corrupted. With 256 Kb of RAM page 19 exists and (I guess) is unused, so no corruption happpens.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Sergio Baldoví - 2017-08-16
  
  I've been debugging the write error with 128 Kb of RAM. My steps are:
  
  Flash the EPROM via ESXDOS 0.85 tape.
  
  Enable write protection of EPROM.
  
  Do a soft reset.
  
  At stage 1, MAPRAM is set and firmware is copied to DivMMC RAM 3 and EPROM. Both pages have the same data (checked).
  
  The soft reset (stage 3) doesn't reset the control register and esxdos initializes with DivMMC RAM 3 mapped in the lower bank. During the boot a lot of paging happens, ESXDOS.SYS and NMI.SYS modules are loaded OK but BETADISK.SYS send 0xd3 to the control register (checked with "break 0x9ab if A>15") and CONMEM + MAPRAM + DivMMC RAM page 3 is set. Some data/variable is saved and loaded from offset 3df9/3dfa upper DivMMC RAM page (3 in this case).
  
  IMO this may be a betadisk module bug because the boot sequence should not modify the firmware. If I delete BETADISK.SYS from the card image, I can do a soft reset at stage 3 and write operations work. Also, the DivMMC Enjoy! manual states: "TR-DOS emulation is not available in MapRAM mode (BETADISK.SYS will not be loaded)".
  
  If I do hard reset at stage 3, esxdos initializes with EPROM mapped in the lower bank (no MAPRAM) and write operations work. That's the usual use case, MAPRAM should be used only for flashing. I suspect most interfaces come with the EPROM flashed and other emulators fill the EPROM with the binary supplied without the need to flash it from tape, so this problem is less visible.
  
  ESXDOS 0.86 beta 4 doesn't suffer this issue as I can do a soft reset after flashing and all works.
  
  Any opinions about switching back to 128 Kb? IMO doing a hard reset after flashing is necessary.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sergio Baldoví - 2017-08-16

After resetting there are DivMMC ram pages flagged with contention. Doesn't look right.

divmmc_memory_contention.png

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philip Kendall - 2017-09-16

status: open --> closed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philip Kendall - 2017-09-16

All finished now, and released in v1.4.0.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Fredrick Meunier - 2017-09-16

Group: future --> NextRelease
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Fredrick Meunier - 2017-10-11

Group: v1.4.1 --> v1.4.0
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

DivMMC support

Group

Searches

Help

#107 DivMMC support

Related

Discussion