MMFS Development and Support

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
Coeus
Posts: 1416
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: MMFS Development and Support

Post by Coeus » Sat Aug 10, 2019 1:53 pm

Wheel_nut wrote:
Sat Aug 10, 2019 12:18 pm
As Dave said earlier, there is a trade-off to changing the *DISK and *DISC commands because some of the games on the STH compendium use these commands. *DISK and *DISC would need to be re-directed to *MMFS rather than just dummied out.
There is a limit to what can be achieved by re-ordering the ROMs.

If the MMFS ROM is in the higher numbered and thus higher priority slot then games that have hard-code *DISC or *DISK in their loaders will probably run correctly from MMFS without trying to access the real floppy drives but the copying program COP114 won't work properly.

If the DFS is in the higher numbered and thus higher priority slot then COP114 can probably be made to work correctly by making the changes I outlined above which are, quite possibly, the change Steve made himself to his adapted MMFS versions. Any game, though, that issues *DISC will then select the real DFS and thus try to load its next file from floppy disc rather than MMFS.

Obviously one solution that could be applied if was only a person that would want to select DFS specifically would be patch one of the commands the DFS DFS ROM responds to to select itself and a filing system to something else (like *DFS). That would enable DFS to be in the lower priority slot and still selectable but obviously that isn't the command COP114 is expecting to issue. If you patched COP114 too, that arrangement would probably work.

The other way would be to provide an option on MMFS to control whether it responds to *DISC and *DISK. This option could be turned on for running games and turned off for running COP114. Again, unless patching COP114 it would be necessary to have MMFS self-select on *CARD too.

There is an issue logged for MMFS on this very thing: https://github.com/hoglet67/MMFS/issues/7
Last edited by Coeus on Sat Aug 10, 2019 1:56 pm, edited 1 time in total.

User avatar
hoglet
Posts: 8861
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Sat Aug 10, 2019 3:05 pm

Another solution would be to use a ROM Manager to disable DFS or MMFS when not required.

This is typically what I do in my own Model Bs.

Dave

User avatar
Wheel_nut
Posts: 129
Joined: Wed May 01, 2019 12:46 pm
Location: West of Scotland
Contact:

Re: MMFS Development and Support

Post by Wheel_nut » Sat Aug 10, 2019 3:36 pm

hoglet wrote:
Sat Aug 10, 2019 3:05 pm
Another solution would be to use a ROM Manager to disable DFS or MMFS when not required.

This is typically what I do in my own Model Bs.

Dave
I went back to Steve Picton's documentation on the CD that came with his TurboSPI adapter and the attached document now makes a lot of sense to me. I had read it before but didn't appreciate the intricacies of the problems and solutions.

Now, if only I could coax Steve into releasing a C.SWMMFSBL , I could blow my EPROMS and go to bed! :idea: [-o<
Attachments
MMFS+SWMMFS+MAMMFS.pdf
(243.96 KiB) Downloaded 10 times
#1 BBC Model B Issue 7 + 1770 DFS + Dual TEAC Floppy
#2 BBC Model B Issue 7 + 8271 DFS + Dual Floppy + Speech
#3 BBC Model B Issue 7 + 8271 DFS + Cumana Single Floppy

Coeus
Posts: 1416
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: MMFS Development and Support

Post by Coeus » Sat Aug 10, 2019 4:58 pm

Coeus wrote:
Sat Aug 10, 2019 1:53 pm
There is an issue logged for MMFS on this very thing: https://github.com/hoglet67/MMFS/issues/7
And see my recent update to this issue - I think this feature is now available.

User avatar
Wheel_nut
Posts: 129
Joined: Wed May 01, 2019 12:46 pm
Location: West of Scotland
Contact:

Re: MMFS Development and Support

Post by Wheel_nut » Sat Aug 10, 2019 5:52 pm

Coeus wrote:
Sat Aug 10, 2019 4:58 pm
Coeus wrote:
Sat Aug 10, 2019 1:53 pm
There is an issue logged for MMFS on this very thing: https://github.com/hoglet67/MMFS/issues/7
And see my recent update to this issue - I think this feature is now available.
YAY! I would love to see that implemented and a MMFS and Z/MMFS versions released. I have to admit that I cannot contribute to the design or implementation discussion as it is way above my level of competence. :cry:

I am happy to test any releases for any of you. ... Robin
#1 BBC Model B Issue 7 + 1770 DFS + Dual TEAC Floppy
#2 BBC Model B Issue 7 + 8271 DFS + Dual Floppy + Speech
#3 BBC Model B Issue 7 + 8271 DFS + Cumana Single Floppy

User avatar
hoglet
Posts: 8861
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Sat Aug 10, 2019 5:58 pm

Wheel_nut wrote:
Sat Aug 10, 2019 5:52 pm
YAY! I would love to see that implemented and a MMFS and Z/MMFS versions released. I have to admit that I cannot contribute to the design or implementation discussion as it is way above my level of competence. :cry:
It's already there in the verion you have (1.41), albeit untested.

User avatar
Wheel_nut
Posts: 129
Joined: Wed May 01, 2019 12:46 pm
Location: West of Scotland
Contact:

Re: MMFS Development and Support

Post by Wheel_nut » Sat Aug 10, 2019 7:31 pm

hoglet wrote:
Sat Aug 10, 2019 5:58 pm
Wheel_nut wrote:
Sat Aug 10, 2019 5:52 pm
YAY! I would love to see that implemented and a MMFS and Z/MMFS versions released. I have to admit that I cannot contribute to the design or implementation discussion as it is way above my level of competence. :cry:
It's already there in the verion you have (1.41), albeit untested.
Please explain ... Which Version (Filename) has the *DISK and *DISC dummied out and is Bootloadable into Sideways RAM? I am happy to test it. Remember that I have Turbo Hardware. - Robin
Last edited by Wheel_nut on Sat Aug 10, 2019 7:36 pm, edited 2 times in total.
#1 BBC Model B Issue 7 + 1770 DFS + Dual TEAC Floppy
#2 BBC Model B Issue 7 + 8271 DFS + Dual Floppy + Speech
#3 BBC Model B Issue 7 + 8271 DFS + Cumana Single Floppy

Coeus
Posts: 1416
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: MMFS Development and Support

Post by Coeus » Sat Aug 10, 2019 8:11 pm

Wheel_nut wrote:
Sat Aug 10, 2019 7:31 pm
Please explain ... Which Version (Filename) has the *DISK and *DISC dummied out and is Bootloadable into Sideways RAM? I am happy to test it. Remember that I have Turbo Hardware. - Robin
None of them have had the *DISC or *DISK commands patched out, instead there is an option to tell MMFS to ignore the *DISC and *DISK commands and only respond to *MMFS. To use it, you need to have MMFS as the current filing system first so if it doesn't start as the default filing system then do:

Code: Select all

*MMFS
after that:

Code: Select all

*OPT 5,1
that tells MMFS not to respond to *DISC and *DISK so these are passed on to the real DFS. This option is present in all the builds of MMFS so you need to pick the T version for the Turbo hardware.
Last edited by Coeus on Sat Aug 10, 2019 8:12 pm, edited 1 time in total.

Coeus
Posts: 1416
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: MMFS Development and Support

Post by Coeus » Sat Aug 10, 2019 8:17 pm

Wheel_nut wrote:
Sat Aug 10, 2019 7:31 pm
...and is Bootloadable into Sideways RAM?
So I forgot to respond to this bit in my previous message. I have an idea of why Steve doesn't supply patched, sideways RAM versions of MMFS to work with the disc copier. The sideways RAM-specific versions of MMFS use the end of their own sideways RAM bank as workspace so as to free up low memory for games/other programs, i.e. keep page at &0E00. The copier, COP114 checks for a signature or "magic number" at the very end of the ROM that implements the current filing system when it is invoked (i.e. probably MMFS). With the sideways ROM versions of MMFS that would be workspace so one can't rely on it having that magic number even if MMFS were to copy it there at the start.

You can, of course, load the non-sideways-RAM version into sideways RAM for testing. That won't give you page at 0E00 but it should be good enough for testing.

User avatar
Wheel_nut
Posts: 129
Joined: Wed May 01, 2019 12:46 pm
Location: West of Scotland
Contact:

Re: MMFS Development and Support

Post by Wheel_nut » Mon Aug 12, 2019 7:16 pm

Coeus and Dave,

I have tried T/MMFS, T/SWMMFS and T/ZMMFS with *OPT 5,1 and all of them give me the "MMC not active" error when I tru to use the MTOD function in COP114. In these tests, the Sideways heirarchy is MMFS, Basic2, DFS and ADT200. I should report that I can however, switch to the Floppy Drive using *DISK and back to the SD Card using *MMFS.
Coeus wrote:
Sat Aug 10, 2019 8:17 pm
Wheel_nut wrote:
Sat Aug 10, 2019 7:31 pm
...and is Bootloadable into Sideways RAM?
So I forgot to respond to this bit in my previous message. I have an idea of why Steve doesn't supply patched, sideways RAM versions of MMFS to work with the disc copier. The sideways RAM-specific versions of MMFS use the end of their own sideways RAM bank as workspace so as to free up low memory for games/other programs, i.e. keep page at &0E00. The copier, COP114 checks for a signature or "magic number" at the very end of the ROM that implements the current filing system when it is invoked (i.e. probably MMFS). With the sideways ROM versions of MMFS that would be workspace so one can't rely on it having that magic number even if MMFS were to copy it there at the start.

You can, of course, load the non-sideways-RAM version into sideways RAM for testing. That won't give you page at 0E00 but it should be good enough for testing.
Late last night, Steve Picton sent me a "Test" version of his C.SWMMFSBL (Bootloader) ROM. I have to patch the first Byte of the ROM to the address of the Sidewats RAM into which it is to be Bootloaded and then blow it into a Bank Higher than that Bank. I am using Bank B (11) for Sideways Ram so I have put the Bootloader ROM in Bank D (13).

I haven't done any rigorous testing but COP114 works when loaded in SWR Bank F(15). I can switch to the Floppy Drive using *DISK and back to the SD Card using *CARD. Shift-Break Loads the STH Menu and after a Break out of a game, I can Shift-Break back to the STH Menu. So far so good...

I realise that I may have problems loading games which require *Disk to return to the SD Card to load Data or Pages mid game. If you can give me an example of such a game, I will test it.

EDIT: Tuesday 13 August 2019: I have done some more intensive testing with the above configuration and can report that I have NOT been able to fault the operation of COP114 with Steve's C.SWMMBL Bootloader. The *MTOD and *DTOM work flawlessly as do the *FCAT and other Floppy Disc functions.

I have encountered the problem with some of the games not loading, typically the compendiums which present an initial screen with a choice of game; then loading the game seected. These do try to load the subsequent selection from the Floppy Drive. However, I have found a very simple work-around:

When playing games, instead of loading COP114 into Sideways RAM Bank F, I load the Vanilla T/MMFS into Bank F(15). Being higher than Steve's Bootloader in Bank D(13) and the Bootloaded SWMMFS in Bank B(11), a Ctrl-BreaK followed by a Shift Break boots the STH Menu using the Vanilla T/MMFS and then all of the games that I have tested load just fine.

I would call that a SUCCESS =D> =D>

Thanks to Steve Picton, Dave and Coeus for your help in solving this conundrum. :D =D> :D
Last edited by Wheel_nut on Tue Aug 13, 2019 5:06 pm, edited 2 times in total.
#1 BBC Model B Issue 7 + 1770 DFS + Dual TEAC Floppy
#2 BBC Model B Issue 7 + 8271 DFS + Dual Floppy + Speech
#3 BBC Model B Issue 7 + 8271 DFS + Cumana Single Floppy

User avatar
vanekp
Posts: 675
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands
Contact:

Re: MMFS Development and Support

Post by vanekp » Wed Aug 14, 2019 9:45 am

I am having a problem building the ROM's from github I am trying this under linuxmint in a terminal, I run it with ./build.sh it then starts running :-

Code: Select all

desktop:~/MMFS-master$ ./build.sh
Building MMFS 1.41
Blank build/U/mmfs.ssd created
build/U/mmfs.ssd updated

Building U/EMMFS...
./build.sh: line 58: tools/beebasm/beebasm: No such file or directory
build failed to create U/EMMFS
it creates a build folder with a folder U in it with EMMFS.log and mmfs.ssd in the folder, the log file contains the error message above about beebasm.
ok so i see it's looking for BEEBASM and not beebasm as its called, if i rename it or change the script to the same case i get :-
build.sh: line 58 -i: command not found
build failed to create U/EMMFS

What am I doing wrong? I am not a linux user maybe there is something I don't understand :)
Peter.

User avatar
hoglet
Posts: 8861
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Wed Aug 14, 2019 10:11 am

vanekp wrote:
Wed Aug 14, 2019 9:45 am
it creates a build folder with a folder U in it with EMMFS.log and mmfs.ssd in the folder, the log file contains the error message above about beebasm.
ok so i see it's looking for BEEBASM and not beebasm as its called, if i rename it or change the script to the same case i get :-
build.sh: line 58 -i: command not found
build failed to create U/EMMFS

What am I doing wrong? I am not a linux user maybe there is something I don't understand :)

Code: Select all

       # Assember the ROM
        $BEEBASM -i ${top} -o ${build}/${name} -v >& ${build}/${name}.log
It's not looking for BEEBASM, it's looking for $BEEBASM which is an environment variable set earlier in the script (to tools/beebasm/beebasm)

Can you try running the following commands:

Code: Select all

echo $PATH
ls -l tools/beebasm
tools/beebasm/beebasm --help
./tools/beebasm/beebasm --help
Dave

User avatar
vanekp
Posts: 675
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands
Contact:

Re: MMFS Development and Support

Post by vanekp » Wed Aug 14, 2019 10:38 am

ahhh okay I was wondering about that as I said I am not a linux user :lol:
okay echo $path shows no path and I also don't see where its setting that in the build.sh script
Peter.

User avatar
hoglet
Posts: 8861
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Wed Aug 14, 2019 10:43 am

vanekp wrote:
Wed Aug 14, 2019 10:38 am
okay echo $path shows no path and I also don't see where its setting that in the build.sh script
Linux is case sensitive, so echo $path is different to echo $PATH

Please make sure you try the commands exactly as I posted, and post the log. You can even just cut/paste them into a terminal if you like.

User avatar
vanekp
Posts: 675
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands
Contact:

Re: MMFS Development and Support

Post by vanekp » Wed Aug 14, 2019 10:57 am

lol yes I keep forgetting that, okay here is the text from all the commands :-

Code: Select all

qwerty@qwerty-desktop:~/MMFS-master$ ./build.sh
Building MMFS 1.41
Blank build/U/mmfs.ssd created
build/U/mmfs.ssd updated

Building U/EMMFS...
./build.sh: line 58: tools/beebasm/beebasm: No such file or directory
build failed to create U/EMMFS
qwerty@qwerty-desktop:~/MMFS-master$ ./build.sh
Building MMFS 1.41
Blank build/U/mmfs.ssd created
build/U/mmfs.ssd updated

Building U/EMMFS...
./build.sh: line 58: tools/beebasm/beebasm: No such file or directory
build failed to create U/EMMFS

qwerty@qwerty-desktop:~/MMFS-master$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

qwerty@qwerty-desktop:~/MMFS-master$ ls -l tools/beebasm
total 1380
-rwxr-xr-x 1 qwerty qwerty 215012 Aug 11 12:02 beebasm
-rwxr-xr-x 1 qwerty qwerty 284852 Aug 11 12:02 beebasm-darwin
-rw-rw-r-- 1 qwerty qwerty 884736 Aug 11 12:02 beebasm.exe
-rw-rw-r-- 1 qwerty qwerty  22904 Aug 11 12:02 README.txt
qwerty@qwerty-desktop:~/MMFS-master$ tools/beebasm/beebasm --help
bash: tools/beebasm/beebasm: No such file or directory
qwerty@qwerty-desktop:~/MMFS-master$ ./tools/beebasm/beebasm --help
bash: ./tools/beebasm/beebasm: No such file or directory
qwerty@qwerty-desktop:~/MMFS-master$ 
mmm it's not seeing beebasm as a program on linux mint odd, even thou it has execute permission.
Last edited by vanekp on Wed Aug 14, 2019 11:06 am, edited 1 time in total.
Peter.

User avatar
hoglet
Posts: 8861
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Wed Aug 14, 2019 11:14 am

It's possibly a shared library issue.

Can you run the following, and post the response.

Code: Select all

ldd tools/beebasm/beebasm
Dave

User avatar
vanekp
Posts: 675
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands
Contact:

Re: MMFS Development and Support

Post by vanekp » Wed Aug 14, 2019 11:22 am

says :- "not a dynamic executable"
Peter.

User avatar
hoglet
Posts: 8861
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Wed Aug 14, 2019 11:25 am

vanekp wrote:
Wed Aug 14, 2019 11:22 am
says :- "not a dynamic executable"
OK, lets just check it's not corrupt. Two more commands:

Code: Select all

md5sum tools/beebasm/beebasm
file tools/beebasm/beebasm
(and make sure you do this on beebasm, not beebasm.exe)

Edit:I think I know what this is....but do those commands anyway

Dave
Last edited by hoglet on Wed Aug 14, 2019 11:28 am, edited 3 times in total.

User avatar
vanekp
Posts: 675
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands
Contact:

Re: MMFS Development and Support

Post by vanekp » Wed Aug 14, 2019 11:43 am

was just looking on internet and its because your tying to run a 32 bit app on a 64bit OS so had to install 32-bit libraries using "sudo apt-get install ia32-libs-multiarch"

here are the results of the other commands : -
desktop:~/MMFS-master$ md5sum tools/beebasm/beebasm
abc12ad3c20ac171b1da117c6e8b0dd7 tools/beebasm/beebasm
desktop:~/MMFS-master$ file tools/beebasm/beebasm
tools/beebasm/beebasm: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-, for GNU/Linux 2.6.24, BuildID[sha1]=5659188f66a03d89c8446dddd581ae8d83b8c8f2, stripped

and now it works thank you for pointing me in the right direction :D
Peter.

User avatar
hoglet
Posts: 8861
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Wed Aug 14, 2019 11:48 am

Yes, that's what I thought. The precompiled version of beebasm was 32-bit.

I've just added both 32 and 64 bit versions of beebasm into github:
tools/beebasm/beebasm32
tools/beebasm/beebasm64

And also some checks in build.sh to select the appropriate version.

Hopefully no-one else will now trip over this.

Dave
Last edited by hoglet on Wed Aug 14, 2019 11:49 am, edited 1 time in total.

User avatar
vanekp
Posts: 675
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands
Contact:

Re: MMFS Development and Support

Post by vanekp » Wed Aug 14, 2019 11:53 am

indeed and because i am not expert on linux I was not sure where I was going wrong :)
but with a bit of help worked it out thanks again :wink:
Peter.

User avatar
tricky
Posts: 3925
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MMFS Development and Support

Post by tricky » Sat Aug 31, 2019 8:32 am

I've been having a problem with some of the 128MB cards that I have, I didn't notice at first as it was only with saving and I don't do that on the beeb (not since Carnival high-score save).
I have lots (30+) 128MB cards that I have picked up in many batches from different places and it seems that 10 of the 12 that I have tried writing to on various beebs with different interfaces don't work with MMFS or SmartSPI.
They one I am testing at the moment gives this error:
IMG_20190831_085415.png
I think that this card may have a second issue, or it may be related. One of the *DCATs showed disc 280 having a '(' or maybe ')' instead of a P for protected!
I've tried verifying and various disc test programs on windows and the card is fine (but they may not use SPI).
I can't find a doc, or the right bit in the docs I have looked at that explains the error codes, but I'll keep looking.

cmorley
Posts: 1146
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: MMFS Development and Support

Post by cmorley » Sat Aug 31, 2019 8:49 am

tricky wrote:
Sat Aug 31, 2019 8:32 am
I've been having a problem with some of the 128MB cards that I have, I didn't notice at first as it was only with saving and I don't do that on the beeb (not since Carnival high-score save).
I have lots (30+) 128MB cards that I have picked up in many batches from different places and it seems that 10 of the 12 that I have tried writing to on various beebs with different interfaces don't work with MMFS or SmartSPI.
They one I am testing at the moment gives this error:
IMG_20190831_085415.png
I think that this card may have a second issue, or it may be related. One of the *DCATs showed disc 280 having a '(' or maybe ')' instead of a P for protected!
I've tried verifying and various disc test programs on windows and the card is fine (but they may not use SPI).
I can't find a doc, or the right bit in the docs I have looked at that explains the error codes, but I'll keep looking.
I have the same problem with at least 2 of the cards I got from Tricky too. I tried on a couple of machines. Some writes commit and give an error message so I imagine it is a timeout or unexpected return value (wait/ready signal?) being treated as an error. Zero problems with these cards on PCs with a variety of adapters. I tried with MMFS and SmartSPI so whatever it is is common between both.

So for example the disc unlock gave an error but actually did commit the unlock to the card.

User avatar
tricky
Posts: 3925
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MMFS Development and Support

Post by tricky » Sat Aug 31, 2019 9:43 am

Sorry Chris, I have only realised that they have a problem in the last few days, they never fail to read and I never write to them.
... I've just realised that I do get the odd read error, maybe once a day at a show where they are used constantly.
I had put it down to poor contact in the adaptors, but maybe it isn't. I have had the same issue with other larger (1GB, 2GB), but still older cards.
I've just noticed in MMFS that waitresp_up which waits for the response bit b1 to be clear doesn't check for errors/no response but haven't got much further.

User avatar
tricky
Posts: 3925
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MMFS Development and Support

Post by tricky » Sat Aug 31, 2019 9:56 am

A little more info.
MMFS_DBG.png

User avatar
hoglet
Posts: 8861
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: MMFS Development and Support

Post by hoglet » Sat Aug 31, 2019 10:25 am

Hi Tricky,

If you have a spare card and wouldn't mind parting with it, I'd be happy to take a look.

It's possibly these cards are atypically slow, and what's actually happening is the MMFS is just giving up too soon. The write response error code of E0 supports this. Only bits 4..0 are significant, and these are all zero in this case, suggesting no response was actually received.

The current timeout is 256 clocks, which is only about 3.5ms
https://github.com/hoglet67/MMFS/blob/m ... t.asm#L160

A while back I hit a similar problem with one of the Atom file system, and increasing the timeout from 12ms to 200ms fixed the issue:
https://github.com/hoglet67/AtomFpga/co ... 929b10ed06

So it seems there are some very slow cards around.

Dave

cmorley
Posts: 1146
Joined: Sat Jul 30, 2016 7:11 pm
Location: Oxford
Contact:

Re: MMFS Development and Support

Post by cmorley » Sat Aug 31, 2019 11:21 am

The cards are pretty slow on a PC so a timeout issue sounds very plausible.

I don't see you (hoglet) on the Cambs ABUG list but I'm sure Tricky or I can post you one?

User avatar
CMcDougall
Posts: 6934
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland
Contact:

Re: MMFS Development and Support

Post by CMcDougall » Sat Aug 31, 2019 12:45 pm

what crap make are they?

11.5yr ago when I started this , I only bought SD SanDisk 2gb cards, as all other cards where utter rubbish in my HD camcorder (stutter or say file err after 4min record), sure the SanDisk where only about £3 inc post on eBlaaa, watch out for fake 32gb :twisted: (should be drowned at birth)

my electrons did not like SD Kingston or the older MMC cards, but the Atom does 8)
ImageImageImage

User avatar
tricky
Posts: 3925
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MMFS Development and Support

Post by tricky » Sat Aug 31, 2019 1:07 pm

I'm still looking through the MMFS source, but I can't see where SD Ver 1 cards are initialised with ACMD41 (0) after failing to respond to CMD8 and before deciding that they are MMC and CMD1. Maybe we have never seen an SD Ver 1 card!

If a Ver 2+ card is in block address, isn't the default 512 bytes (I guess it doesn't hurt to set it again).

Hoglet, PM me an address and I'll send you a card, or I can try extending the timeout here if you have any ideas.

I changed waitresp_up to 65536 retries, but it returns immediately after successfully doing the write!

Code: Select all

.waitresp_up
{
	ldx #0
    LDY #0
.wrup
	LDA #(1 + msbits)
    STA iorb%
    LDA #(3 + msbits)
    STA iorb%
    LDA sr%
    AND #1
    BEQ wrup_timeout
	iny : bne wrup
	inx : bne wrup
.wrup_timeout
	LDX #(1 + msbits)
    LDA #(3 + msbits)
    RTS
}

User avatar
tricky
Posts: 3925
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MMFS Development and Support

Post by tricky » Sat Aug 31, 2019 1:27 pm

PS What is the UP_ReadBits4 (read 4 bits in) for in MMC_EndWrite after the write?

Post Reply