Simple Electon MMC Interface

[sixxdog_uk]

Nice Work. Very Nice.

[CMcDougall]

Which flavour MMFS were you using, and how/where was it installed?

Evening Dave,
it does not matter if in slot 0/1 or 2/3
when I do a *. / *MMFS / *DIN 0 it just moves down a few lines then >_
sometimes get GETFORNEXTbla bla ,but not as often as the above.

setup as per pic, no plus3 (back in loft where it can rot )
using the new E/EMMFS1.30 from a few post up with SAVE fix you found.

[CMcDougall]

just had another go with ATI/ABR & same thing...
But, when MMFS rom image is not on the ATI/ABR, it works perfectly fine
ie I always have Hopper & Snapper images loaded onto it, & it's happy , even when in slot 01 or 23

done a speed test with Save /Load, saving is faster

[hoglet]

just had another go with ATI/ABR & same thing...
But, when MMFS rom image is not on the ATI/ABR, it works perfectly fine
ie I always have Hopper & Snapper images loaded onto it, & it's happy , even when in slot 01 or 23

No idea what's going on here.

Can you try write protecting the ATI/ABR?

done a speed test with Save /Load, saving is faster

That very interesting. How much faster?

The User Port code to write a bit is:

Code: Select all

2    ROL A
2    AND #&FD
6    STA iorb% ;; VIA &FE62
2    ORA #2
6    STA iorb%

The Elk Printer Port is pretty similar, just using a different address

Code: Select all

2    ROL A
2    AND #&FD
4    STA data% ;; Printer Port &FC71
2    ORA #2
4    STA data%

If it's faster, it must mean the ELK printer port is running at 2MHz (i.e. no 1MHz slow down).

This would save 16us/byte, so a 20KB file would be ~330ms faster.

TurboMMC would be faster though (:ducks)

Dave

[daveejhitchins]

Dave, I'll get the latest schematics posted so soon as I get home.

Dave H

[CMcDougall]

With *SA. dummy 1900 8000 & using T=TIME , time-T, load =465 & save =312

the AT I/ABR was always write protected....

[CMcDougall]

here is all the elk MMB .SSDs I have made on my card:

DCAT

elkCAT.jpg (41.82 KiB) Viewed 5635 times

they all each have a !BOOT &/or a menu for the game/s on each disc.
not all work, unless you are using the ESWMMFS which leaves page@E00
If you have ADT rom in another cart/socket, then most do work with *MRUN mainbit

[hoglet]

Dave, I'll get the latest schematics posted so soon as I get home.

Are you back home yet Dave?

[daveejhitchins]

Yup! Back home . . .

Dave H

And working on getting the schematics out

[daveejhitchins]

Schematics updated - and can be found on the first page of the following threads:

I've also added the abbreviations e.g. ABR, to make searching easier.

ATI - here.
ARA MkII - here.
ABR - here.
AP6 - here.
MGC - here.

Dave H

[Elk Towers]

could someone give me a link to the sd interface please.

[roland]

What about this link: http://www.stardot.org.uk/forums/viewto ... =8&t=12689

[Elk Towers]

I was actually after a 99p like the one Dave showed in the first post but thanks anyway.

[CMcDougall]

I was actually after a 99p

99p, rip off!

buy them for about 33p each, and free post from China, about a 2-3 weeks to come, just search about on eBay
http://www.ebay.co.uk/sch/i.html?_from= ... e&_sacat=0
Arduino SD Card interface

don't you read this forum, it's 3 years old these things!

[rharper]

I made the printer port modification on a Plus1 and with the multi-coloured cable got it running fine.
This is OK for a permanent setup but not easy to move to another machine - having to write down/memorise the connections.
So having some unused printer cables I have made a printer to MMC card cable.
Ray

[myelin]

I just got this to work using a hacked-up Elk PiTubeDirect cartridge with an SD socket taped to the top and jumper wires everywhere, attached to the Minus One -- VHDL and details here

Next step: implement the memory-mapped SD interface!

[hoglet]

Nice work!

I look forward to the next instalment.

Dave

[myelin]

Nice work!

I look forward to the next instalment.

Thanks! Here's as far as I managed to get it last night. Seen this error before? I suspect that SCK is out of spec (SD cards need 100-400 kHz during initialization, and I'm using 1/2 PHI0, so either 500 kHz or 1 MHz, depending what's going on in the background). I also realized that I'm supposed to have a pull-up resistor on MISO, although the ElkPlus1 code worked fine without one, so I guess that's not a hard requirement.

[hoglet]

Seen this error before?

The command that's failing is GET_CID (read's the card identifier).

That's a fair way through the initialization.

This card definitely works with the "Elk printer port" interface?

Can you post a link to your HDL for the MM interface?

[myelin]

The command that's failing is GET_CID (read's the card identifier).

That's a fair way through the initialization.

This card definitely works with the "Elk printer port" interface?

Can you post a link to your HDL for the MM interface?

Yes, it definitely works with the ElkPlus1 interface (build/E/EMMFS.rom and build/E/EMMFSDB.rom); with a BEEB.MMB file found somewhere else on here, Shift-BREAK does nothing, but CHAIN "MENU" brings up the menu, and I can load Arcadians and Elite just fine.

I've pushed the latest HDL up to the GitHub repo -- thanks for taking a look!

One other thing -- I added a bunch more JSR donothing calls into MMC_MemoryMapped.asm, because it was expecting each byte transfer to finish in 12 clock cycles, and my HDL takes 16-17 because it divides PHI0 in half (toggling SCK on the falling edge of PHI0).

[hoglet]

I've pushed the latest HDL up to the GitHub repo -- thanks for taking a look!

I've a vague idea why it might be breaking at READ_CID

That's the first command that returns a data block following the response, so the response timing might be different.

The protocol is the same as "Single Block Read" here.
http://elm-chan.org/docs/mmc/mmc_e.html

What's interesting is that the command response is shown as FF:
0xFF4A00000000FF : FF

Which generally means the card has not responded, and MMFS has waited long enough.

I wonder if you are just not waiting long enough?

The timeout occurs in MMC_DoCommand, where Y manages to decrement to zero:
https://github.com/hoglet67/MMFS/blob/m ... ed.asm#L63

Do you get any further if you remove that DEY?

The other thought I had is that the memory mapped SPI driver works 8-bits at a time. What happens if the first bit of the command response (D7, always a zero) is not on the correct 8-bit boundary? I don't know if that can happen or not, but the other drivers deal with this by working 1-bit at a time when waiting for the response:
https://github.com/hoglet67/MMFS/blob/m ... s1.asm#L58

I don't think you are hitting this second issue yet. As an 0xFF is definitely a timeout. But remember, to my knowledge, this driver has never been used on read hardware (only in BeebEm)!

Dave

[myelin]

I wonder if you are just not waiting long enough?

The timeout occurs in MMC_DoCommand, where Y manages to decrement to zero:
https://github.com/hoglet67/MMFS/blob/m ... ed.asm#L63

It it just me, or is that code repeatedly reading mmc% without pushing &FF to it to trigger a new transfer each time? Looks like maybe the STA mmc% needs to move below .wR1mm (and have an LDA #&FF added), if the intention of this code is to poll the card until it returns something without bit 7 set.

[hoglet]

It it just me, or is that code repeatedly reading mmc% without pushing &FF to it to trigger a new transfer each time? Looks like maybe the STA mmc% needs to move below .wR1mm (and have an LDA #&FF added), if the intention of this code is to poll the card until it returns something without bit 7 set.

Agreed.

I assume this works in BeebEm because it replies instantly.

Try changing it and see if that helps.

[myelin]

Try changing it and see if that helps.

Perfect; will give that a go when I get home.

Re the other issue, it looks like the Arduino Sd2Card library, which also uses 8-bit SPI for everything, just looks at bit 7 of the response byte when waiting, so I guess that's okay.

[myelin]

OK! That got it a bit further. It can now get as far as mostly loading a BASIC file from a disk image, although it looks like it must have truncated the file. Continuing to debug

Update: The memory-mapped interface kept being flaky, so I tried converting the code in MMC_ElkPlus1.asm bit by bit. I've now got *that* code working using the memory-mapped interface, and it seems fairly reliable. It fails randomly when the SPI clock is PHI0/2, but seems okay with PHI0/4, and is still a bit quicker than the parallel port version (it loads Codename: Droid in ~8.5s, and the parallel port code takes about 21s). There seem to be some odd timing issues, and if the card loses sync, it needs a power cycle to recover, but it feels like it's mostly there.

Is there an MMFS test suite / stress test of some kind that I can run to smoke out any more bugs?

[daveejhitchins]

(it loads Codename: Droid in ~8.5s, and the parallel port code takes about 21s).

To the "press Space to Start" screen, MGC does it in 3s

Dave H

[hoglet]

Is there an MMFS test suite / stress test of some kind that I can run to smoke out any more bugs?

Not that I am aware of.

This would be a very useful addition, if anyone feels like a little project.

It wouldn't need to be MMFS specific, as it just needs to exercise the standard MOS file systems APIs.

Jonathan (jgharston) might have something like this?

Dave

[flaxcottage]

Having re-entered the wonderful world of the Electron with a Plus 1 interface I was looking to add MMFS functionality to it.

Thanks to this thread and Dave's efforts (Hoglet) I have managed the task quite nicely.

This is my set up

Showing the Heath-Robinson prototype

Spares from my 'junk box'

Connected together and working

The finished accessory.

The SD card adapter works really well albeit somewhat slowly. However, the Elk is not a pacey machine so that is OK.

Using MMBImager I can add software in the form of SSD disk images on my PC. A Datacentre equipped Master lets me easily create SSD images of software I want to transfer.

So the cute, little Electron can now 'play with the big boys'.

PS: Yes, I have used Blu-Tack as a third hand. I even used it to 'glue' the SD PCB onto the lid of the black box.

[Ramtop]

After acquiring my first Electron less than a month ago I set out to design a bit of hardware to bung in the back of it. Working on the old principle of walking before you run, I decided on a very simple one-socket sideways ROM card. At the weekend I got the board up and running and was pleased to be able to declare 'mission accomplished'!

But I remembered reading this thread and thought... hmm, would an SD reader work? I had run the four spare I/O pins I had left on the CPLD out to a header for testing purposes. If I mapped those pins to simulate the Plus 1 printer port, would it work?

Yes, indeedy, it does

A few lines of verilog and a ribbon cable later and it works just fine.

Big, big thanks to Dave for his work. Being able to attach an SD reader with so little work is very, very cool.

[hoglet]

Very nice indeed!