OSWORD &7F on DFS vs MMFS

discuss both original and modern hardware for the bbc micro/electron
Post Reply
User avatar
0xC0DE
Posts: 630
Joined: Tue Mar 19, 2019 7:52 pm
Location: The Netherlands
Contact:

OSWORD &7F on DFS vs MMFS

Post by 0xC0DE » Sun Nov 10, 2019 9:17 pm

I'm trying some test code doing raw sector reads (OSWORD &7F) on my Acorn Electron on DFS (in an emulator, btw) and on MMFS 1.4x (on a real Electron).

My first question: I know MMFS is based on DFS but the underlying medium (SD-card) is much faster. Is MMFS artificially kept at the same speed as DFS? Because I am getting similar throughput speeds. Max 5.5Kb/s. I thought MMFS would be much faster than that.

Second question: is there a fundamental difference between doing raw sector reads with OSWORD &7F on DFS vs MMFS? My test code is working fine on DFS but producing MMC Read Faults on MMFS 1.4x at random places during testing. My assumption was that code for DFS should work unmodified on MMFS.
0xC0DE
"I program my home computer / Beam myself into the future"
:arrow: Follow me on Twitter
:arrow: Visit my YouTube channel featuring my demos for Acorn Electron and BBC Micro

User avatar
kieranhj
Posts: 896
Joined: Sat Sep 19, 2015 11:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by kieranhj » Sun Nov 10, 2019 10:22 pm

I can’t answer your questions #-o but I do have some to add of my own. The Teletext Bad Apple demo uses OSWORD &7F for multi-sector reads and used to work fine on MMFS (in fact I recall I had to make some changes to the way the streaming worked to accommodate) but I haven’t been able to get it running recently - it just hangs. :(

I haven’t had chance to debug yet, or write a repro test, but have there been any changes to the implementation that might affect it? This was using a very recent version of the ROM that Tricky burnt for me at the last ABUG.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: OSWORD &7F on DFS vs MMFS

Post by hoglet » Mon Nov 11, 2019 7:42 am

0xC0DE wrote:
Sun Nov 10, 2019 9:17 pm
My first question: I know MMFS is based on DFS but the underlying medium (SD-card) is much faster. Is MMFS artificially kept at the same speed as DFS? Because I am getting similar throughput speeds. Max 5.5Kb/s. I thought MMFS would be much faster than that.
MMFS does not deliberately slow it's self down.
0xC0DE wrote:
Sun Nov 10, 2019 9:17 pm
Second question: is there a fundamental difference between doing raw sector reads with OSWORD &7F on DFS vs MMFS? My test code is working fine on DFS but producing MMC Read Faults on MMFS 1.4x at random places during testing. My assumption was that code for DFS should work unmodified on MMFS.
MMC Read Faults are likely to be a bug in MMFS, or possibly a very slow SD Card.

How is the MMC interface connected to the Electron? (i.e. what build of MMFS are you using)

Dave

User avatar
0xC0DE
Posts: 630
Joined: Tue Mar 19, 2019 7:52 pm
Location: The Netherlands
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by 0xC0DE » Mon Nov 11, 2019 8:04 am

I have tested on 2 products by Ramtop. The ElkSD64 connected to the Elk expansion port. And the ElkSD-Plus1 which plugs into a cartridge slot of the Plus 1.

What is the expected speed of MMFS on such a setup?
0xC0DE
"I program my home computer / Beam myself into the future"
:arrow: Follow me on Twitter
:arrow: Visit my YouTube channel featuring my demos for Acorn Electron and BBC Micro

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

Re: OSWORD &7F on DFS vs MMFS

Post by hoglet » Mon Nov 11, 2019 8:56 am

kieranhj wrote:
Sun Nov 10, 2019 10:22 pm
I can’t answer your questions #-o but I do have some to add of my own. The Teletext Bad Apple demo uses OSWORD &7F for multi-sector reads and used to work fine on MMFS (in fact I recall I had to make some changes to the way the streaming worked to accommodate) but I haven’t been able to get it running recently - it just hangs. :(

I haven’t had chance to debug yet, or write a repro test, but have there been any changes to the implementation that might affect it? This was using a very recent version of the ROM that Tricky burnt for me at the last ABUG.
Sounds like a bug/regession in MMFS/

Can you provide a few more details please, so I can try to replicate:
- version of MMFS that doesn't work
- version of MMFS that does work (if you can remember)
- hardware configuration (Beeb, Master, etc)
- brand of SD card
- link to the version of the Bad Apple Demo being used

Dave

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

Re: OSWORD &7F on DFS vs MMFS

Post by hoglet » Mon Nov 11, 2019 9:01 am

0xC0DE wrote:
Mon Nov 11, 2019 8:04 am
What is the expected speed of MMFS on such a setup?
Absolutely no idea, but significantly slower than the user port version, because the SPI interface is being bit-banged.

I would guess about half the speed.

(I'm assuming this is using the Electron Printer Port build of MMFS)

Dave

User avatar
daveejhitchins
Posts: 5754
Joined: Wed Jun 13, 2012 6:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by daveejhitchins » Mon Nov 11, 2019 9:08 am

hoglet wrote:
Mon Nov 11, 2019 9:01 am
(I'm assuming this is using the Electron Printer Port build of MMFS)
I wouldn't have thought so, as it's in a cartridge!

Dave H :D

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

Re: OSWORD &7F on DFS vs MMFS

Post by hoglet » Mon Nov 11, 2019 9:32 am

daveejhitchins wrote:
Mon Nov 11, 2019 9:08 am
hoglet wrote:
Mon Nov 11, 2019 9:01 am
(I'm assuming this is using the Electron Printer Port build of MMFS)
I wouldn't have thought so, as it's in a cartridge!
Ah, but I believe all of Ramtop's interfaces re-implement a Electron Printer Port (EPP) interface in the CPLD for driving the SD Card, even the cartridge port one.

Dave

User avatar
daveejhitchins
Posts: 5754
Joined: Wed Jun 13, 2012 6:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by daveejhitchins » Mon Nov 11, 2019 9:55 am

hoglet wrote:
Mon Nov 11, 2019 9:32 am
daveejhitchins wrote:
Mon Nov 11, 2019 9:08 am
hoglet wrote:
Mon Nov 11, 2019 9:01 am
(I'm assuming this is using the Electron Printer Port build of MMFS)
I wouldn't have thought so, as it's in a cartridge!
Ah, but I believe all of Ramtop's interfaces re-implement a Electron Printer Port (EPP) interface in the CPLD for driving the SD Card, even the cartridge port one.

Dave
Ah! OK . . .

Dave H :D

Ramtop
Posts: 226
Joined: Tue Oct 23, 2018 1:40 pm
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by Ramtop » Mon Nov 11, 2019 11:02 am

hoglet wrote:
Mon Nov 11, 2019 9:32 am
Ah, but I believe all of Ramtop's interfaces re-implement a Electron Printer Port (EPP) interface in the CPLD for driving the SD Card, even the cartridge port one.
Spot on, Dave. They all implement just enough of the EPP for MMFS to work. The ElkSD-Plus 1 merely changes the addresses used so as not to clash with the actual EPP.

I've never actually tested the speed, games load in a few seconds which qualifies as 'quick enough' in my book, but 5-6K/sec sounds quite likely.
Gary

User avatar
kieranhj
Posts: 896
Joined: Sat Sep 19, 2015 11:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by kieranhj » Mon Nov 11, 2019 8:45 pm

hoglet wrote:
Mon Nov 11, 2019 8:56 am
Sounds like a bug/regession in MMFS/

Can you provide a few more details please, so I can try to replicate:
- version of MMFS that doesn't work
- version of MMFS that does work (if you can remember)
- hardware configuration (Beeb, Master, etc)
- brand of SD card
- link to the version of the Bad Apple Demo being used

Dave
Hi Dave - yes, I will file a proper bug report as soon as I can - at the very latest it’ll be ABUG. Apologies for the vague wafting statement to the effect of “my thing used to work and now it doesn’t”.

Would you prefer this to be filed as an issue on GitHub?
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: OSWORD &7F on DFS vs MMFS

Post by hoglet » Mon Nov 11, 2019 9:11 pm

kieranhj wrote:
Mon Nov 11, 2019 8:45 pm
Would you prefer this to be filed as an issue on GitHub?
Yes please, then I won't forget about it.

Dave

User avatar
0xC0DE
Posts: 630
Joined: Tue Mar 19, 2019 7:52 pm
Location: The Netherlands
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by 0xC0DE » Sat Nov 16, 2019 9:06 pm

Just to add: my problems with MMFS are solved. My code is now running on DFS as well as on MMFS. Turns out that I made a small mistake in my interrupt driven screen drawing code that wasn't giving any problems on DFS but messed things up on MMFS. Solved!
0xC0DE
"I program my home computer / Beam myself into the future"
:arrow: Follow me on Twitter
:arrow: Visit my YouTube channel featuring my demos for Acorn Electron and BBC Micro

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

Re: OSWORD &7F on DFS vs MMFS

Post by hoglet » Sat Nov 16, 2019 10:51 pm

0xC0DE wrote:
Sat Nov 16, 2019 9:06 pm
Just to add: my problems with MMFS are solved. My code is now running on DFS as well as on MMFS. Turns out that I made a small mistake in my interrupt driven screen drawing code that wasn't giving any problems on DFS but messed things up on MMFS. Solved!
Glad you have got it sorted.

Out of interest, what was the mistake?

I'm curious about what would break with MMFS but not DFS.

Dave

User avatar
0xC0DE
Posts: 630
Joined: Tue Mar 19, 2019 7:52 pm
Location: The Netherlands
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by 0xC0DE » Sat Nov 16, 2019 11:14 pm

My interrupt handler wasn't saving the Y register, only A and X because I didn't use Y in a previous version of the code :oops:
Apparently DFS didn't care about that but MMFS does.

I have a follow up question for you though: does MMFS enable interrupts (CLI) regardless of the fact that they were disabled (SEI) by me? Especially after a call to OSWORD &7F?
0xC0DE
"I program my home computer / Beam myself into the future"
:arrow: Follow me on Twitter
:arrow: Visit my YouTube channel featuring my demos for Acorn Electron and BBC Micro

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

Re: OSWORD &7F on DFS vs MMFS

Post by hoglet » Sun Nov 17, 2019 7:38 am

0xC0DE wrote:
Sat Nov 16, 2019 11:14 pm
My interrupt handler wasn't saving the Y register, only A and X because I didn't use Y in a previous version of the code :oops:
Apparently DFS didn't care about that but MMFS does.

I have a follow up question for you though: does MMFS enable interrupts (CLI) regardless of the fact that they were disabled (SEI) by me? Especially after a call to OSWORD &7F?
You might find this post relevant:
viewtopic.php?f=3&t=10621&p=168287#p168287

Based on that, it looks like I did enable interrupts in OSWORD 7F in MMFS 1.37:
https://github.com/hoglet67/MMFS/commit ... b93df84d13

Do you have a view as to whether it is right or wrong to do this?

Dave

User avatar
0xC0DE
Posts: 630
Joined: Tue Mar 19, 2019 7:52 pm
Location: The Netherlands
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by 0xC0DE » Sun Nov 17, 2019 11:43 am

hoglet wrote:
Sun Nov 17, 2019 7:38 am
Based on that, it looks like I did enable interrupts in OSWORD 7F in MMFS 1.37:
https://github.com/hoglet67/MMFS/commit ... b93df84d13

Do you have a view as to whether it is right or wrong to do this?
Well, I don't have a strong opinion either way but it certainly took me by surprise that MMFS enables interrupts. And it is something that should be known/documented I think (if it isn't already).

In my case it gave undesirable side-effects in my code where interrupts are deliberately disabled. My interrupt handler was called prematurely because a prior call to OSWORD &7F re-enabled interrupts without me knowing that it did at the time. Don't know if it really matters but this is also diffferent behaviour than OSWORD &7F on DFS.
0xC0DE
"I program my home computer / Beam myself into the future"
:arrow: Follow me on Twitter
:arrow: Visit my YouTube channel featuring my demos for Acorn Electron and BBC Micro

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

Re: OSWORD &7F on DFS vs MMFS

Post by hoglet » Sun Nov 17, 2019 1:12 pm

0xC0DE wrote:
Sun Nov 17, 2019 11:43 am
And it is something that should be known/documented I think (if it isn't already).
What the documentation for most of the MOS API calls (e.g. in the Advanced User Guide) says is along the lines of "The interrupt status is preserved, but may be enabled during the call". All of the OSFILE calls say this.

I'm not sure where to look for the OSWORD A=&7F documentation, but I would tend to assume the same, otherwise this would prevent any file system from ever making use of IRQ interrupts.

I still need to close the loop with Kieran on the Bad Apple / MMFS issues, so this may end up changing back again.

Dave
Last edited by hoglet on Sun Nov 17, 2019 8:55 pm, edited 1 time in total.

User avatar
tricky
Posts: 4455
Joined: Tue Jun 21, 2011 9:25 am
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by tricky » Sun Nov 17, 2019 1:30 pm

Just my 2p:
- You can call OSWORD from an interrupt routine.
+ All the other file routines document that they may enable interrupts.
+ You shouldn't keep interrupts disabled for "too long" and some MMC routines can take a while!
Conclusions:
If any other DFS does, then you might as well!
Documenting that you may SEI/CLI saves a PHP:PLP when you need to disable them.

EDIT: cross-posted

User avatar
kieranhj
Posts: 896
Joined: Sat Sep 19, 2015 11:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by kieranhj » Sun Nov 17, 2019 2:12 pm

hoglet wrote:
Sun Nov 17, 2019 1:12 pm
I still need to close the loop with Kieron on the Bad Apple / MMFS issues, so this may end up changing back again.
Happy to do this at ABUG next weekend, a good opportunity to get to the bottom of it with the right people in the room! I also have a sneak peak of a new streaming demo so quite timely to check it works across as many devices as possible.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: OSWORD &7F on DFS vs MMFS

Post by hoglet » Sun Nov 17, 2019 7:57 pm

Hi Kieran,
kieranhj wrote:
Sun Nov 17, 2019 2:12 pm
Happy to do this at ABUG next weekend, a good opportunity to get to the bottom of it with the right people in the room! I also have a sneak peak of a new streaming demo so quite timely to check it works across as many devices as possible.
I had a quick look at Teletext Bad Apple this afternoon (as I wanted to test the ICE-6502 in anger).

On a Model B with the latest MMFS (1.44) it crashes consistently at 00:54 due to the ring buffer underflowing.

Looking at why this might be, I noticed for "fast" devices the player is dynamically patched so that OSWORD 7F reads one 256-byte sector at a time (compared with the default of 10). This is actually quite inefficient for MMFS (and other SD card file systems), because the native sector size on the SD card is 512 bytes. The result is that each physical sector ends up being read twice, effectively halving the throughput.

I tweaked things so that OSWORD 7F reads two 256-byte sectors at a time, and with this the underflow doesn't occur and everything seems to work fine on a Model B. The audio seems to stay in sync (though I'm not an expert in this).

Anyway, give this a try and see if it cures the problem for you.

Dave

User avatar
kieranhj
Posts: 896
Joined: Sat Sep 19, 2015 11:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by kieranhj » Mon Nov 18, 2019 8:09 am

hoglet wrote:
Sun Nov 17, 2019 7:57 pm
I had a quick look at Teletext Bad Apple this afternoon (as I wanted to test the ICE-6502 in anger).

On a Model B with the latest MMFS (1.44) it crashes consistently at 00:54 due to the ring buffer underflowing.

Looking at why this might be, I noticed for "fast" devices the player is dynamically patched so that OSWORD 7F reads one 256-byte sector at a time (compared with the default of 10). This is actually quite inefficient for MMFS (and other SD card file systems), because the native sector size on the SD card is 512 bytes. The result is that each physical sector ends up being read twice, effectively halving the throughput.

I tweaked things so that OSWORD 7F reads two 256-byte sectors at a time, and with this the underflow doesn't occur and everything seems to work fine on a Model B. The audio seems to stay in sync (though I'm not an expert in this).

Anyway, give this a try and see if it cures the problem for you.
Great sleuthing Dave! Thank you.

Some of the hazy details are coming back to me from two years ago. I seem to recall we deduced that DFS reenables interrupts during multiple sector reads as they can take a long time, whilst originally MMFS didn’t as it was ‘fast enough’. However with Bad Apple being quite timing critical I was getting slowdowns in the music because the vsync interrupt was being missed during the track loads. In the end we took a belt & braces approach - you added the interrupt change to MMFS whilst I changed the demo to read a smaller number of sectors at a time for ‘fast’ devices, for those folks who had an old ROM or non-MMFS SD systems.

I didn’t realise about the undying 512-byte sector size for SD cards. I will make that change and update the Bad Apple disc image on our website. Hopefully this should cure my issues with the new streaming demo as well. I’m still curious that this used to work with MMFS v1.36 (or whichever it was when you made the original change). At least I think it did!?
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: OSWORD &7F on DFS vs MMFS

Post by hoglet » Mon Nov 18, 2019 10:57 am

kieranhj wrote:
Mon Nov 18, 2019 8:09 am
I’m still curious that this used to work with MMFS v1.36 (or whichever it was when you made the original change). At least I think it did!?
Actually, it seems it didn't, at least not on the Model B.

Here's yesterday's results on the Model B.

With MMFS 1.36 (the last version that had interrupts disabled during OSWORD &7F)
- 1 sector reads: play time 3:31.40 (audio finishes ~7s before video)
- 2 sector reads: play time 3:20.27 (audio stays in sync)
- 10 sector reads: play time 3:28.10 (auto finishes ~2s before video)

With MMFS 1.37 (the first version that has interrupts enabled during OSWORD &7F)
- 1 sector reads: crashes @ ~55s
- 2 sector reads: play time 3:20.56 (audio stays in sync)
- 10 sector reads: play time 3:20:42 (audio stays in sync)

With MMFS 1.44 (the latest)
- 1 sector reads: crashes @ ~55s
- 2 sector reads: play time 3:20.15 (audio stays in sync)
- 10 sector reads: play time 3:20.00 (audio stays in sync)

Don't read too much into the fractions of a second, I was timing with a manual stop watch.

Dave

User avatar
kieranhj
Posts: 896
Joined: Sat Sep 19, 2015 11:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by kieranhj » Mon Nov 18, 2019 7:04 pm

hoglet wrote:
Mon Nov 18, 2019 10:57 am
Actually, it seems it didn't, at least not on the Model B.
Oops, oh dear, that's definitely my bad, as they say. :oops: I'm slightly disappointed that no-one complained about it for the last two years. #-o Looks like 2 sectors reads is the way to go, at least for 'fast' devices (will need to test on my DataCentre but sure it'll be fine).

Thanks again for doing such comprehensive tests with the different versions, this is much appreciated.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

Coeus
Posts: 1650
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by Coeus » Wed Nov 20, 2019 10:26 pm

0xC0DE wrote:
Sat Nov 16, 2019 11:14 pm
My interrupt handler wasn't saving the Y register, only A and X because I didn't use Y in a previous version of the code :oops:
Apparently DFS didn't care about that but MMFS does.

I have a follow up question for you though: does MMFS enable interrupts (CLI) regardless of the fact that they were disabled (SEI) by me? Especially after a call to OSWORD &7F?
I can take a guess at why DFS didn't care. AFAIK it sets up the sector transfer, which happens via a sequence of NMIs, then polls a memory location which will change when the NMI has completed the transfer. As most of the time during a sector transfer will be spent in that loop and therefore when your interrupt occurs it will usually be that loop being interrupted, then the corruption of Y didn't cause a problem.

Now the system involving the NMI seems a little complicated. If the foreground task is just going to wait for the transfer happening via NMIs, why not just write a tight polling loop to do the transfer? The problem with doing the transfer as the foreground task is that it is time critical and therefore could not be interrupted, i.e. interrupts would need to be disabled. I think the whole reason for doing that transfer with an NMI is so normal interrupts can be enabled. As implemented the usual IRQ can interrupt the foreground polling then the NMI can interrupt the IRQ handler. So normal IRQ interrupts can be a little slower to process but not late by the whole of a sector transfer.

User avatar
0xC0DE
Posts: 630
Joined: Tue Mar 19, 2019 7:52 pm
Location: The Netherlands
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by 0xC0DE » Thu Nov 21, 2019 4:03 pm

Interesting information, thank you!
0xC0DE
"I program my home computer / Beam myself into the future"
:arrow: Follow me on Twitter
:arrow: Visit my YouTube channel featuring my demos for Acorn Electron and BBC Micro

Chuckie
Posts: 13
Joined: Thu Jun 20, 2019 1:21 pm
Contact:

Re: OSWORD &7F on DFS vs MMFS

Post by Chuckie » Fri Nov 29, 2019 4:29 pm

For ramtop

interested in electron sd interface please contact me

Post Reply

Return to “8-bit acorn hardware”