MMFS Development and Support

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
kieranhj
Posts: 530
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: MMFS Development and Support

Postby kieranhj » Sun Apr 30, 2017 2:34 pm

hoglet wrote:I don't think it can be this, as none of the SD card solutions make any use of NMI.

Just goes to show how little I know about how the Acorn filing systems work then!

The source is all on GitHub: https://github.com/bitshifters/bad-apple/blob/master/6502/m7vplay.6502. I'm just using the standard OSWORD &7F "read data multi-sector" command to load (see function load_next_track.) If you have any ideas I'm happy to try rebuilding with different params etc. to test. I'll also be at ABUG in May for live debugging!
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: MMFS Development and Support

Postby Coeus » Sun Apr 30, 2017 3:48 pm

When reading from a floppy disc there is on NMI per byte and I think the conclusion of the discussion on adding 3.5 discs was that there not a lot of time spare between bytes but there is a gap between sectors which is probably when other things that have been waiting can be processed.

Accessing an SD card would presumably not have an equivalent sector gap and would proceed with the next sector as soon as the current one has loaded. I have not dug that far into the source code for MMFS but on the assumption it is bit banging it would make sense that it has interrupts disabled to avoid upsetting the timing. If so, is the answer for MMFS to do a CLI/SEI at an appropriate point between sector reads?

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

Re: MMFS Development and Support

Postby hoglet » Sun Apr 30, 2017 5:36 pm

Hi Kieran,
kieranhj wrote:Thanks to my new EEPROM board from Chris I swapped over from using the ancient Turbo MMC DFS to shiny new MMFS version 1.36. Unfortunately when testing our Bad Apple demo I get hideous slowdown which isn't present using the old DFS. :(

I've just tried this build with MMFS 1.36 on my Model B and it looks pretty good to me.
viewtopic.php?p=163146#p163146

But I'm at a slight disadvantage here having never seen how this is meant to look....

How obvious is the slowdown?

For example, should the clock on the teletext header be running in exactly real time?

Dave

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

Re: MMFS Development and Support

Postby hoglet » Sun Apr 30, 2017 5:45 pm

Coeus wrote:Accessing an SD card would presumably not have an equivalent sector gap and would proceed with the next sector as soon as the current one has loaded. I have not dug that far into the source code for MMFS but on the assumption it is bit banging it would make sense that it has interrupts disabled to avoid upsetting the timing. If so, is the answer for MMFS to do a CLI/SEI at an appropriate point between sector reads?

Unfortunately, MMFS doesn't disable interrupts at any point.

(It doesn't matter if the SPI clock stalls for a while as an interrupt is serviced).

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

Re: MMFS Development and Support

Postby kieranhj » Sun Apr 30, 2017 8:41 pm

hoglet wrote:I've just tried this build with MMFS 1.36 on my Model B and it looks pretty good to me.
viewtopic.php?p=163146#p163146

But I'm at a slight disadvantage here having never seen how this is meant to look....

How obvious is the slowdown?

For example, should the clock on the teletext header be running in exactly real time?

Dave

Hi Dave,

Thanks for taking a look. The easiest way to check A/V sync is right at the beginning - after the apple is thrown in the air, when it is caught the screen inverts and turns to separated graphics at the same time. This should happen just before the real time clock hits 14 seconds (technically frame 343 so 13.72 seconds) and be accompanied by a very obvious "snap" and pause in the music.

After that any slowdown in the music should be fairly obvious but I can do a debug build that displays the side/track/sector currently being loaded in the header. This showed me previously that I was getting slowdown during load on the Turbo MMC system when doing 10 sectors at a time.

The Teletext header should be "just about" real-time, it might lose a second or so over the full 3 minutes but anything more than that is definitely a bug.

Cheers,
Kieran
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: MMFS Development and Support

Postby hoglet » Sun Apr 30, 2017 9:47 pm

kieranhj wrote:After that any slowdown in the music should be fairly obvious but I can do a debug build that displays the side/track/sector currently being loaded in the header. This showed me previously that I was getting slowdown during load on the Turbo MMC system when doing 10 sectors at a time.

Thanks Kieran, that debug build would be useful.

Am I right in thinking that the critical interface to the storage system is OSWORD A=&7F, and that each call is returning exactly one track?

Do you have a feel for what sustained performance is required? i.e. how long is the OSWORD call permitted to take before things will go wrong. Even a ballpark figure would be useful.

Dave

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

Re: MMFS Development and Support

Postby Coeus » Wed May 03, 2017 8:56 pm

Going back slighly to the question of initialisation behaviour I am currently finding that upon switchon MMFS Bootstrap, so running in sideways RAM, often hangs when issuing a *. command, however after a ctrl-break it works fine. Does this sound like it might be related to the earlier issue? This is with the current GIT master from hoglet's repository.

steve3000
Posts: 1711
Joined: Sun Nov 25, 2012 12:43 am

Re: MMFS Development and Support

Postby steve3000 » Wed May 03, 2017 11:15 pm

hoglet wrote:Am I right in thinking that the critical interface to the storage system is OSWORD A=&7F, and that each call is returning exactly one track?

Do you have a feel for what sustained performance is required? i.e. how long is the OSWORD call permitted to take before things will go wrong. Even a ballpark figure would be useful.

Hi Dave, just some background to this as I've been mulling over the issue too (and just spotted this conversation). Both my version of Bad Apple and Kieran's use OSWORD &7F to load compressed data into a circular buffer, and on DFS using 5.25" discs, the next track (10x256 bytes) of data is loaded as soon as enough space is available. Interrupt driven code (VSync event) is used to decode and display the data on screen, then update available space in buffer.

This works fine under DFS, but fails on the mmbeeb MMC and SmartSPI SD implementations because the VSync event isn't serviced correctly while OSWORD &7F is in progress. I can't comment on MMFS as I've not yet had the chance to try (although just downloaded - so will do this weekend).

The solution we've used when running from MMC and SmartSPI was to load individual sectors each time 256 bytes is free, rather than whole track when 10x256 bytes is free. This approach doesn't work on real DFS with 5.25" discs because the load time for 10 individually loaded sectors is longer than loading 1 full track, due to a full disc rotation required for each sector when loaded individually (leads to buffer under-run) - but on SD there is no such delay, so loading sectors worked fine, but it sounds like Kieran's experience with MMFS suggests a difference here.

The SD interface is clearly much faster than DFS, so even loading a full track should be possible, but there must be something in these implementations causing a clash with the interrupt driven code.

I need to look back at my notes, but I had narrowed it down to interrupts being disabled during OSWORD &7F on MMC and SmartSPI. DFS also disables interrupts during OSWORD &7F, but re-enables (CLI/SEI) between sectors, which is enough to keep the VSync event serviced for the video playback.

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

Re: MMFS Development and Support

Postby hoglet » Thu May 04, 2017 6:12 am

steve3000 wrote:I need to look back at my notes, but I had narrowed it down to interrupts being disabled during OSWORD &7F on MMC and SmartSPI. DFS also disables interrupts during OSWORD &7F, but re-enables (CLI/SEI) between sectors, which is enough to keep the VSync event serviced for the video playback.

I've just double checked, and the only place in MMFS where there is an SEI instruction is in the TubeHost code.

Does the current version of Bad Apple detect MMFS vs DFS and choose the 1-sector or 10-sector behaviour accordingly?

Or are there two different builds?

dp11
Posts: 708
Joined: Sun Aug 12, 2012 8:47 pm

Re: MMFS Development and Support

Postby dp11 » Thu May 04, 2017 7:14 am

Does the os do SEI before handing over to mmfs?

dp11
Posts: 708
Joined: Sun Aug 12, 2012 8:47 pm

Re: MMFS Development and Support

Postby dp11 » Thu May 04, 2017 7:21 am

Yes it does

Code: Select all


**************************************************************************
**************************************************************************
**                                                                      **
**      OSWORD  DEFAULT ENTRY POINT                                     **
**                                                                      **
**      pointed to by default WORDV                                     **
**                                                                      **
**************************************************************************
**************************************************************************

E7EB   PHA         ;Push A
E7EC   PHP         ;Push flags
E7ED   SEI         ;disable interrupts
E7EE   STA &EF     ;store A,X,Y
E7F0   STX &F0     ;
E7F2   STY &F1     ;
E7F4   LDX #&08    ;X=8
E7F6   CMP #&E0    ;if A=>224
E7F8   BCS &E78A   ;then E78A with carry set

E7FA   CMP #&0E    ;else if A=>14
E7FC   BCS &E7C8   ;else E7C8 with carry set pass to ROMS & exit

E7FE   ADC #&44    ;add to form pointer to table
E800   ASL         ;double it
E801   BCC &E793   ;goto E793 ALWAYS!! (carry clear E7F8)

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

Re: MMFS Development and Support

Postby hoglet » Thu May 04, 2017 8:06 am

Excellent find Dominic, I'll try a fix this morning.

Dave

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

Re: MMFS Development and Support

Postby hoglet » Thu May 04, 2017 10:46 am

Hi Guys,

Here are some slightly mixed results....

For the record, I'm testing with this image:
https://bitshifters.github.io/content/bs-badappl.dsd

With the existing version of MMFS (1.36) on a Master, Bad Apple seems to work correctly.
- &800 frames takes ~82 seconds, and at the end the music and video both seem to stop in sync.

With the existing version of MMFS (1.36) on a Model B, there is some slowdown:
- &800 frames takes ~92 seconds, and at the end the music stops several seconds before the video.

I then updated MMFS to re-enable interrupts in OSWORD &7F (and restore the original state afterwards):

Code: Select all

       PHP
       CLI
       JSR Osword7F_8271_Emulation     ; OSWORD &7F 8271 emulation
       PLP
       RTS

On the Model B this does seem seem to eliminate the slow-down, but at about &550 frames there is now a crash.

As a sanity check, I tried running the same image from DFS (2.26), and somewhat surprisingly that crashes consistently at &A1D frames. I've made two separate disk images, and they both crash at the same point.

So I'm a bit confused as to what's going on here.

If anyone else wants to try, here's a build of MMFS with interrupts enabled in OSWORD &7F:
mmfs_1_37_20170504_1144.zip
(2.27 MiB) Downloaded 15 times

Dave

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

Re: MMFS Development and Support

Postby kieranhj » Thu May 04, 2017 10:12 pm

Hi Dave, thanks for testing this out. I've been away all this week and nowhere near a Beeb so not able to take a look at this on my machine.

Your DFS crash at &A1D could be the speed of your floppy drive when flipping between side 0 & 2 (from memory that looks roughly halfway through the total number of frames.). Because of memory constraints I cut the size of the ring buffer to the bare minimum so it "works on my machine" (that is both the emulators and my dual floppy drives on real Master hardware.) If the buffer runs out of data before it's loaded then the decompressor just produces garbage and Bad Things Happen.

As an aside, I never realised back in the day that there are dip switches available to control the speed & timings of floppy drives, I guess the technology improved over the years and the mechanics got better.

As for your earlier crash in MMFS, I will download and take a look to repro on my Beeb setup, unfortunately not until after the weekend. When I get chance to do that I'll also cut a debug build that displays exactly which drive/track/sector is being loaded.

In terms of deciding whether to load 10 tracks at a time or 1, I just time the initial buffer load (3 tracks worth) and if this is less than 1/2 second I assume a "fast device" (I.e. MMC or DC) otherwise a "slow device" (I.e. floppy.) There's no explicit check for the filing system.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

steve3000
Posts: 1711
Joined: Sun Nov 25, 2012 12:43 am

Re: MMFS Development and Support

Postby steve3000 » Thu May 04, 2017 11:46 pm

kieranhj wrote:Your DFS crash at &A1D could be the speed of your floppy drive when flipping between side 0 & 2 (from memory that looks roughly halfway through the total number of frames.).

Kieran, did you not use the same trick I used when swapping from side 0 to 2? My side 2 data is stored backwards from track 79 to 0, so there's no head-seek required...just a little reordering of data :)

By doing this I kept well within my frame buffer, but without this trick it was right on the limit.

...However this shouldn't cause the crash on MMFS...as no heads to seek!

User avatar
geraldholdsworth
Posts: 303
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: MMFS Development and Support

Postby geraldholdsworth » Fri May 05, 2017 8:49 am

A quickie question...I've said before about the problem of having *DISC and *DISK in this ROM - removing these, is this a simple case of changing

Code: Select all

.cmdtable22
   EQUB (cmdaddr22-cmdaddr1)/2-1
   EQUS "DISC"
   EQUB &80
   EQUS "DISK"
   EQUB &80
   EQUS "MMFS"
   EQUB &80
   BRK

to

Code: Select all

.cmdtable22
   EQUB (cmdaddr22-cmdaddr1)/2-1
   EQUS "MMFS"
   EQUB &80
   BRK
?
In addition, I've knocked up a quick guide for those like me, who wish to run this on a Mac:
Find the lines in build.sh:

Code: Select all

# Set the BEEBASM executable for the platform
BEEBASM=tools/beebasm/beebasm.exe
if [ "$(expr substr $(uname -s) 1 5)" == "Linux" ]; then
    BEEBASM=tools/beebasm/beebasm
fi

and delete all but

Code: Select all

    BEEBASM=tools/beebasm/beebasm

then find a MacOS copy of beebasm and copy this into the tools/beebasm folder, overwriting the existing file.

I'm having to build the binary from source, as I need to change the 6522VIA base address for my internal User Port (not that I've got around to fitting it yet!!!).
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

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

Re: MMFS Development and Support

Postby hoglet » Fri May 05, 2017 9:08 am

geraldholdsworth wrote:A quickie question...I've said before about the problem of having *DISC and *DISK in this ROM - removing these, is this a simple case of changing...

You should also remove the corresponding entries from the address table (cmdaddr22):
https://github.com/hoglet67/MMFS/blob/m ... .asm#L1418

What's the address of your 6522?

Dave

User avatar
geraldholdsworth
Posts: 303
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: MMFS Development and Support

Postby geraldholdsworth » Fri May 05, 2017 9:10 am

Just been reading https://github.com/hoglet67/MMFS/wiki/Release-structure and found that I don't need to change the base address - it's done for me...thank you Dave.
I just use the T/MAMMFS3.rom for my TurboMMC connected to the User Port on the Econet header.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

User avatar
geraldholdsworth
Posts: 303
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: MMFS Development and Support

Postby geraldholdsworth » Fri May 05, 2017 9:11 am

hoglet wrote:You should also remove the corresponding entries from the address table (cmdaddr22):
https://github.com/hoglet67/MMFS/blob/m ... .asm#L1418

Thank you Dave.
hoglet wrote:What's the address of your 6522?

Errr...&FEA0, I think.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

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

Re: MMFS Development and Support

Postby Coeus » Fri May 05, 2017 9:17 am

geraldholdsworth wrote:A quickie question...I've said before about the problem of having *DISC and *DISK in this ROM...


Assuming this is a case of MMFS wanting to pretend to be DFS for the body of software than has *DISC included in it somewhere, VDFS has addressed the same issue by having an option, controlled by the command FSCLAIM, i.e. you can turn on and off and run-time whether VDFS selects itself in response to *DISC |(and *DISK and *ADFS IIRC) or levaes those command for their real filing systems.

User avatar
geraldholdsworth
Posts: 303
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: MMFS Development and Support

Postby geraldholdsworth » Fri May 05, 2017 9:52 am

Coeus wrote:Assuming this is a case of MMFS wanting to pretend to be DFS for the body of software than has *DISC included in it somewhere

Seems like a good idea - never thought of it that way. Problem is, I mostly use the MMC for transferring data to/from SSD and floppy. I've never really played games using it.
VDFS has addressed the same issue by having an option

That would be nice, but it's a low priority thing and I'm the only one with an issue...and I have a workaround.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

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

Re: MMFS Development and Support

Postby kieranhj » Fri May 05, 2017 10:07 am

steve3000 wrote:Kieran, did you not use the same trick I used when swapping from side 0 to 2? My side 2 data is stored backwards from track 79 to 0, so there's no head-seek required...just a little reordering of data :)

By doing this I kept well within my frame buffer, but without this trick it was right on the limit.

...However this shouldn't cause the crash on MMFS...as no heads to seek!

Hey Steve, no this only occurred to me very late on in development when everything was working plus I had zero spare RAM to even think about code changes. But yes, should definitely have done that!
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
fordp
Posts: 923
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: MMFS Development and Support

Postby fordp » Fri May 05, 2017 10:16 am

hoglet wrote:
geraldholdsworth wrote:A quickie question...I've said before about the problem of having *DISC and *DISK in this ROM - removing these, is this a simple case of changing...

You should also remove the corresponding entries from the address table (cmdaddr22):
https://github.com/hoglet67/MMFS/blob/m ... .asm#L1418

What's the address of your 6522?

Dave

Would be nice to at least have a build option to remove the *DISC and *DISK :D
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: MMFS Development and Support

Postby hoglet » Fri May 05, 2017 3:04 pm

geraldholdsworth wrote:Seems like a good idea - never thought of it that way. Problem is, I mostly use the MMC for transferring data to/from SSD and floppy. I've never really played games using it.

Have you tried the IDTOM and IMTOD utilities that are included with MMFS?

They are Basic programs that allow disks to be imaged between MMFS and DFS.

Looking at the MMFS code, there does seem to be a *OPT 5,1 implemented that causes *DISK and *DISC to do nothing. But what I think is needed here is for them to be ignored and passed down to a lower priority ROM.

I've create an issue to do this:
https://github.com/hoglet67/MMFS/issues/7

Dave

User avatar
geraldholdsworth
Posts: 303
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: MMFS Development and Support

Postby geraldholdsworth » Fri May 05, 2017 3:27 pm

hoglet wrote:Have you tried the IDTOM and IMTOD utilities that are included with MMFS?

Yep, and the ROM utils supplied by IFEL. I've never really got on well with them.
I found that the disc copier utility never really worked very well.
hoglet wrote:I've create an issue to do this:
https://github.com/hoglet67/MMFS/issues/7

Much appreciated - although don't spend too much time on it on my account...only if more folk request it. I'm happy modifying the code as above.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

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

Re: MMFS Development and Support

Postby hoglet » Fri May 05, 2017 3:44 pm

geraldholdsworth wrote:
hoglet wrote:Have you tried the IDTOM and IMTOD utilities that are included with MMFS?

Yep, and the ROM utils supplied by IFEL. I've never really got on well with them.
I found that the disc copier utility never really worked very well.

Are you saying MMFS's version of IDTOM and/or IMTOD didn't work for you?

Which version of DFS were you using?

Please do feel free to report any bugs. I'm happy to try to fix them.

Dave

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

Re: MMFS Development and Support

Postby CMcDougall » Fri May 05, 2017 8:42 pm

^ he probably means IFEL TURBO LOL transfer 'rom' is crap, as needs SWRAM :roll:

for changing MMFS commands from DISC/DISK, I change them to DMMC/CARD so can run both MMC & DFS at same time :D
ImageImageImage

User avatar
geraldholdsworth
Posts: 303
Joined: Tue Nov 04, 2014 9:42 pm
Location: Inverness, Scotland
Contact:

Re: MMFS Development and Support

Postby geraldholdsworth » Fri May 05, 2017 10:10 pm

CMcDougall wrote:^ he probably means IFEL TURBO LOL transfer 'rom' is crap, as needs SWRAM :roll:

Nailed it.
Gerald Holdsworth
Repton Resource Page
www.reptonresourcepage.co.uk

User avatar
fordp
Posts: 923
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: MMFS Development and Support

Postby fordp » Sat Jun 17, 2017 4:42 pm

Hi All,

I finally got back to some Acorn hacking. I seem to have a problem with MMFS (MAMMFS.rom 1.36) on both my old and my new Masters.

I am getting the dreaded Card? message this is with only the above ROM as the only Filing system ROM.

I use a Steve Picton interface and have been using MMFS with it with the "Steve Picton" ROM "unplugged" but still in my old Master. The MMFS image was until today in RAM on an IFEL Master ROM/RAM board in a RAM slot.

I left the old ROM in the machine as I used it to change the MMFS RAM image in the cartridge.

The strange thing is if do the following.

(Unplugging/ Inserting below are using commands not physically doing it)
1) Unplug MMFS and Insert the Steve Picton ROM, it likes the card.
2) Unplug the Steve PIcton ROM an Insert MMFS it still liked the card and works!
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

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

Re: MMFS Development and Support

Postby hoglet » Sat Jun 17, 2017 5:42 pm

Ford,

It's possible this is a regression of MMFS against the TurboMMC interface, as I don't have one of these to test with.

Can I just confirm a few things:
1. Your Turbo MMC is plugged into the normal userport (&FE60)?
2. You are using the T/MAMMFS build (the T folder is for TurboMMC, this is relatively new)
3. You have done *FX 200 2 after UNPLUG/INSERTing

Could you try an older version of MMFS: MMFS 1.29?

Dave


Return to “hardware”

Who is online

Users browsing this forum: No registered users and 13 guests