MMFS Development and Support

discuss both original and modern hardware for the bbc micro/electron
User avatar
sweh
Posts: 2177
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: MMFS Development and Support

Post by sweh » Tue Oct 01, 2019 3:30 am

Coeus wrote:
Mon Sep 30, 2019 10:28 pm
OK, this is all a little intriguing. Was the 2M128 board sideways RAM only by any chance and the 4M256 added the shadow screen
The 2m128 and 4m256 were totaly different boards. I have a 2m128 (and wrote a manager ROM to fix all the bugs in the STL version), and the 4m256 is... different.

With the 2M128 ACCCON (FE34) determined shadow/buffer modes
Last edited by sweh on Tue Oct 01, 2019 3:33 am, edited 1 time in total.
Rgds
Stephen

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

Re: MMFS Development and Support

Post by Coeus » Tue Oct 01, 2019 2:04 pm

sweh wrote:
Tue Oct 01, 2019 3:30 am
The 2m128 and 4m256 were totaly different boards. I have a 2m128 (and wrote a manager ROM to fix all the bugs in the STL version), and the 4m256 is... different.

With the 2M128 ACCCON (FE34) determined shadow/buffer modes
So do they use different manager ROMs, then? Boydie, perhaps you could check which manager ROM you have.

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

Re: MMFS Development and Support

Post by hoglet » Tue Oct 01, 2019 2:22 pm

Coeus wrote:
Tue Oct 01, 2019 2:04 pm
So do they use different manager ROMs, then? Boydie, perhaps you could check which manager ROM you have.
There are quite a few different versions:

Code: Select all

MANAGER                         	?         	00	(C) K.T.Acres 10.6.86         	82	4000	e389cd75b665842d8f72831b4bbad133
MANAGER                         	?         	00	(C) K.T.Acres 10.7.85         	82	4000	75587e7014c3818fbf44b78588d598fa
MANAGER                         	?         	00	(C) K.T.Acres 10.7.85         	82	4000	8c7016a3da5418ebdfbd3e2d792e5218
MANAGER                         	?         	00	(C) K.T.Acres 13JUL86         	82	4000	749d7dcebf3cf06027c082ed0e330b15
MANAGER                         	?         	00	(C) K.T.Acres 16.6.86         	82	4000	5b51afa423e0f007abc643d6a962bc6a
MANAGER                         	?         	00	(C) K.T.Acres 16.6.86         	82	4000	7a3c65c082e57ae2320bec363b57f6d1
MANAGER                         	?         	00	(C) STL 03/12/86              	82	4000	734638f9843ce108a6b8c310bbbc13a9
MANAGER 128                     	?         	00	(C) SOLIDISK 06.04.87         	82	102a	19b43bec2f4a98a915748c9c0896bdc5
MANAGER 128                     	?         	00	(C) SOLIDISK 06.04.87         	82	2000	ff83bf273411ea5483d94318041216e6

Boydie
Posts: 440
Joined: Sat Oct 24, 2015 9:25 am
Location: Sunny Wigan
Contact:

Re: MMFS Development and Support

Post by Boydie » Tue Oct 01, 2019 3:54 pm

IIRC it’s version 3.01, (c) KTAcres in 1986. I’ll upload an image whenever I get home from work (may be tomorrow morning :( ).
It took a considerable amount of searching to find which of the many versions actually worked with my board.
Last edited by Boydie on Tue Oct 01, 2019 3:55 pm, edited 1 time in total.

Boydie
Posts: 440
Joined: Sat Oct 24, 2015 9:25 am
Location: Sunny Wigan
Contact:

Re: MMFS Development and Support

Post by Boydie » Wed Oct 02, 2019 5:58 pm

It's this one...
Attachments
Manager.zip
(11.57 KiB) Downloaded 18 times

Boydie
Posts: 440
Joined: Sat Oct 24, 2015 9:25 am
Location: Sunny Wigan
Contact:

Re: MMFS Development and Support

Post by Boydie » Wed Oct 02, 2019 7:41 pm

Okay, I have a "solution", for want of a better word...

Having SWMMFS in the backup ROM store and copying it into SRAM from there via *Select just doesn't work, no matter what. Always gives a "Bad Sum" error.
The only way to get it to work properly is:

Boot with SmartSPI (or other FS)
*RLOAD SWMMFS from that FS
Unplug other FS ROMs (otherwise PAGE doesn't drop)
?&FE32=<SRAM bank that swmmfs is in>
*MMFS to reset

After hard/soft reset, ?&FE32 needs to be set again before MMFS will work

So, yes it'll work but it's a bit of a faff to get it to do so. It's very odd that whether it works is dependent upon how it gets into sideways ram. I suspect that when you *Select an image from the backup rom store, it doesn't actually copy it into sideways ram (despite what the manual claims), but just maps that bit of rom into a slot usually allocated to ram and pretends to have copied it. This would explain why it can never find workspace - what it thinks is sideways ram is actually still sitting in rom...

In a related development, I've been looking in the forum regarding Exile and sideways ram. Now I've downloaded the version patched for user port devices, Exile can find and use the sideways ram.
This does of course mean that the sideways ram does exist on startup and can be discovered, which should mean that ZMMFS ought to be able to find it as well...

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

Re: MMFS Development and Support

Post by Coeus » Wed Oct 02, 2019 7:44 pm

Boydie,

Thanks for posting that. I thought I had a look at some of the service calls and see what I could learn and this ROM seems to be doing some very weird things. The first thing to note is that this appears to be two logical ROMs glued together into the one actual ROM as the service entries are daisy chained. That makes sense given that the user manual splits the commands into two sets, MANAGER and TOOLKIT.

Then in the code for service call 01 - claim shared workspace the first bit of weirdness is:

Code: Select all

807A: A9 80       LDA #80     >s
807C: 3C F0 0D    NOP 0DF0,X  >s
807F: F0 03       BEQ 8084    >s
Opcode 3C is one of the ones MOS didn't document. Later people gave it a name. The B-Em debugger is calling it NOP. It is also known as SKW (skip word). Essentially, it goes through the motions and fetches the next two bytes from memory, probably even adds X, but then does nothing with the effective address thus obtained. Given what is going on here, an AND instruction would have made more sense, i.e. opcode 3D, only one bit different.

Then, later on, in the same service call there is this:

Code: Select all

90FE: 78          SEI         >s
90FF: 48          PHA         >s
9100: 5A          NOP         >s
9101: DA          NOP         >s
9102: A5 AE       LDA AE      >s
9104: 48          PHA         >s
9105: A5 AF       LDA AF      >s
9107: 48          PHA         >s
9108: A9 30       LDA #30     >s
910A: 85 AF       STA AF      >s
910C: 64 AE       NOP AE      >s
910E: A6 F4       LDX F4      >s
9110: BD F0 0D    LDA 0DF0,X  >s
9113: 30 30       BMI 9145    >s
9115: 29 0F       AND #0F     >s
9117: 09 80       ORA #80     >s
9119: AA          TAX         >s
911A: 9C 34 FE    SHY FE34,X  >s
911D: B2          HLT         >s
911D: B2          HLT         >s
Note the first two NOPs have different opcodes - more unofficial instuctions. Apart from wondering why a programmer would put a no-op at this point at all, it seems even odder to choose two different undocumented ones rather than the official opcode of EA. It would make much more sense if these two opcodes were TXA PHA.

Then at the end we have another undocumented code SHY but the showstopper is the last one. This is essentially "halt until reset". Not even an interrupt or NMI would cause execution to continue as this instruction locks up the 6502s instruction decoder.

This was tracing the cold boot path, i.e. immediately the machine was turned on so does your machine lock up on power on and then recover when the break key is hit?

Or is there a possibility the ROM image has become corrupted?

Or finally, I had assumed that, as this board sits in the CPU socket, they had you put the NMOS 6502 you removed into a socket on the board. Did they, perhaps, include a 65C02 on the board? That may make these well-defined instructions.

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

Re: MMFS Development and Support

Post by Coeus » Wed Oct 02, 2019 7:52 pm

Coeus wrote:
Wed Oct 02, 2019 7:44 pm
Or finally, I had assumed that, as this board sits in the CPU socket, they had you put the NMOS 6502 you removed into a socket on the board. Did they, perhaps, include a 65C02 on the board? That may make these well-defined instructions.
I am now thinking it is probably this one. If I have B-Em emulate a 65C02 the first odity turns into:

Code: Select all

807A: A9 80       LDA #80     >s
807C: 3C F0 0D    BIT 0DF0,X  >s
807F: F0 03       BEQ 8084    >s
which makes much more sense. Then the second example becomes:

Code: Select all

    90FE: 78          SEI         
    90FF: 48          PHA         
    9100: 5A          PHY         
    9101: DA          PHX         
    9102: A5 AE       LDA AE      
    9104: 48          PHA         
    9105: A5 AF       LDA AF      
    9107: 48          PHA         
    9108: A9 30       LDA #30     
    910A: 85 AF       STA AF      
    910C: 64 AE       STZ AE      
    910E: A6 F4       LDX F4      
    9110: BD F0 0D    LDA 0DF0,X  
    9113: 30 30       BMI 9145    
    9115: 29 0F       AND #0F     
    9117: 09 80       ORA #80     
    9119: AA          TAX         
    911A: 9C 34 FE    STZ FE34    
    911D: B2 AE       LDA (AE)    
    911F: 8E 34 FE    STX FE34    
    9122: 92 AE       STA (AE)    

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

Re: MMFS Development and Support

Post by hoglet » Wed Oct 02, 2019 8:01 pm

Coeus wrote:
Wed Oct 02, 2019 7:44 pm
Or is there a possibility the ROM image has become corrupted?
I have two identical copies in my ROM archives:

Code: Select all

./roms/roms-2009.01.28/roms/kopie_van_eprom/Solidisk/Solidisk__MANAGER_4Meg_256K__3.01__3.12.86
./roms/roms-2009.01.28/roms/origineel/Solidisk/4MHz_256K__3.01-H
The md5sum matches the one Boydie uploaded: 734638f9843ce108a6b8c310bbbc13a9

Edit: As you say, it's definitely 65C02 code.
Last edited by hoglet on Wed Oct 02, 2019 8:22 pm, edited 1 time in total.

Boydie
Posts: 440
Joined: Sat Oct 24, 2015 9:25 am
Location: Sunny Wigan
Contact:

Re: MMFS Development and Support

Post by Boydie » Wed Oct 02, 2019 8:19 pm

It's the 4MHz board, so they did indeed supply a 4MHz 65C02.

I've now done some more playing. The patched ZMMFS that Coeus supplied won't work if it's burnt into eprom, but will work if it's loaded into sideways ram, and then hard-reset. Soft reset always makes it complain about a ROM/RAM mismatch and it dies.
Sadly, that's a limited definition of "work". It'll access the SD card okay, it'll boot the STH menu, it'll load a game up to its first loading screen. Then it hangs. I've tried unplugging all other roms, just in case, but it still does it. This happens with multiple games. Then the computer hangs on hard reset, with just a cursor and I have to power-cycle to get it back to life.

Does the fact that the eprom version reports that it can't find any sideways ram suggest that it's looking too early in the startup cycle, before the board has actually allocated any? Whereas the same rom running from sideways ram must, by definition, be waiting until the sideways ram is available before it can run? The error message that it can't find any sideways ram is always the first thing displayed, as a brief flash before the main boot messages for Solidisk, BBC, FS, etc etc.

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

Re: MMFS Development and Support

Post by Coeus » Wed Oct 02, 2019 8:44 pm

Boydie wrote:
Wed Oct 02, 2019 8:19 pm
Does the fact that the eprom version reports that it can't find any sideways ram suggest that it's looking too early in the startup cycle, before the board has actually allocated any? Whereas the same rom running from sideways ram must, by definition, be waiting until the sideways ram is available before it can run? The error message that it can't find any sideways ram is always the first thing displayed, as a brief flash before the main boot messages for Solidisk, BBC, FS, etc etc.
Remember the routine I posted earlier that runs from the NMI workspace and where I said there was a bug because it has the wrong value for X throughout. That routine runs reasonably early in the start up sequence, from ROM service call 2 and seems to be counting available RAM banks and it assumes each RAM bank is mapped to the addresses 3000-B000. Later in the same service call it prints the "Solidisk 256K expansion (4 Mhz)" message, which is the first thing to appear on screen. As it goes, it writes the bank number to &FE30, &FE32 and &FE34.

Service call 1 doesn't seem to do anything interesting with the hardware from within the manager ROM. ZMMFS does use service call 1 to search for sideways RAM, Before adding a write to &FE32 it would not have found any but adding that write in means it should then have found a bank but then, when it copied SWMMFS into it, that bank would only have been 12K long as the bottom part of that 32K bank is in the screen/shadow area, not in the sideways RAM area.

So I think what needs to happen is to also write to &FE36 to move the mapping of that 32K bank up so it goes from &4000 to &C000. Again this has to happen before SWMMFS tries to initialise. Finally, SWMMFS would have to modified to write it's own bank number into &FE32 before it tries to use its own workspace area at the end of that RAM bank. It may be simpler to have it do this whenever it is entered, i.e from a ROM service call and from each of the fling system vectors.

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

Re: MMFS Development and Support

Post by Coeus » Wed Oct 02, 2019 8:53 pm

Coeus wrote:
Wed Oct 02, 2019 8:44 pm
So I think what needs to happen is to also write to &FE36 to move the mapping of that 32K bank up so it goes from &4000 to &C000.
I suspect this is what you mean by enabling the sideways RAM. Before doing that the RAM bank is there, but too short.

Boydie
Posts: 440
Joined: Sat Oct 24, 2015 9:25 am
Location: Sunny Wigan
Contact:

Re: MMFS Development and Support

Post by Boydie » Wed Oct 02, 2019 9:34 pm

So, if I understand you correctly, you’re saying that ZMMFS isn’t giving the “No sideways ram banks available” error because it can’t find any at all, but because it does find one but it’s too small and the error message is actually because the first bank it finds is too small and its copy fails?
Could the solution be, in that case, when it encounters that error it should then carry on inspecting the other ram banks (only one can be shadow afaik) until it finds one it can fit into?

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

Re: MMFS Development and Support

Post by Coeus » Wed Oct 02, 2019 11:46 pm

Boydie wrote:
Wed Oct 02, 2019 9:34 pm
So, if I understand you correctly, you’re saying that ZMMFS isn’t giving the “No sideways ram banks available” error because it can’t find any at all, but because it does find one but it’s too small and the error message is actually because the first bank it finds is too small and its copy fails?
Could the solution be, in that case, when it encounters that error it should then carry on inspecting the other ram banks (only one can be shadow afaik) until it finds one it can fit into?
From earlier in the discussion, I attached a patched version of ZMMS that adds the write to &FE32 to select the bank for writing. You said that crashed the machine instead. That change was needed for ZMMS to find a usable RAM bank. The reason I think the machine crashed with that patched version is because the bank it did find was too small. The version that has not been patched won't find the banks because it never enables them for writing.

On the point that only one bank can be used for the shadow screen, it is true only one can be the active shadow screen at any one time but other banks can be configured to use the same range of addresses and it looks like the active shadow screen can be flipped by writing to &FE34. Looking at the way the ROM was doing the initial RAM count it would appear you can select any bank as the active shadow by writing to &FE34 with the bank number in the lower 4 bits and the upper 4 bits set to enable shadow mode.

So when the machine is first turned on all the banks seem to be mapped from &3000 to &B000 even though only one would be active as a shadow screen which is not particularly useful. To run SWMMFS we need to get one bank mapped to the correct region, i.e. it occupies all of &8000 to &C000. We only have to do that once each time the board is reset - if we did it on a service call that follows a break that would suffice.

But we still need to get SWMMFS to enable writing to its own sideways RAM bank before it would work with this board.

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

Re: MMFS Development and Support

Post by Coeus » Thu Oct 03, 2019 12:21 am

Coeus wrote:
Wed Oct 02, 2019 11:46 pm
But we still need to get SWMMFS to enable writing to its own sideways RAM bank before it would work with this board.
Dave, Just looking at the code, do you think the subroutine PageIn12K for the Bplus would be the key to this, i.e. for a Solidisk version, everywhere the B+ version would need to page in the 12K, the Solidisk version would need to enable writing to it's own RAM bank?

Boydie
Posts: 440
Joined: Sat Oct 24, 2015 9:25 am
Location: Sunny Wigan
Contact:

Re: MMFS Development and Support

Post by Boydie » Thu Oct 03, 2019 11:57 am

Coeus wrote:
Thu Oct 03, 2019 12:21 am

Dave, Just looking at the code, do you think the subroutine PageIn12K for the Bplus would be the key to this, i.e. for a Solidisk version, everywhere the B+ version would need to page in the 12K, the Solidisk version would need to enable writing to it's own RAM bank?
Apologies if this is what you’re already saying, but thinking laterally from this, if the first thing MMFS finds on startup is the 12k spare ram, left over from setting up shadow ram, does this happen in a consistent, reliable manner (ie same ram area every time)? If so, and that location can be known, could the B+ version be amended to use that 12k as its workspace like the B+’s 12k?

Boydie
Posts: 440
Joined: Sat Oct 24, 2015 9:25 am
Location: Sunny Wigan
Contact:

Re: MMFS Development and Support

Post by Boydie » Thu Oct 03, 2019 3:22 pm

I’ve done a bit more exploring with the patched ZMMFS in eprom. It doesn’t seem to be locking up, so much as printing squares for ever more.
It does respond to (CTRL) Break, and if I’m quick with CTRL-SHIFT, I can see glimpses of the usual startup banners as they flash by on the screen, as in

Lines of squares
Line of banner
More lines of squares
Next line of banner
Etc etc until all banner has passed by and all that’s left are squares

Boydie
Posts: 440
Joined: Sat Oct 24, 2015 9:25 am
Location: Sunny Wigan
Contact:

Re: MMFS Development and Support

Post by Boydie » Thu Oct 03, 2019 4:14 pm

A possible solution?

On the Solidisk, we know where the sideways ram banks are - banks 8 through F (although according to the manual banks 8 & 9 are typically used for shadow, if active). Hence bank F should always be present and available.

Rather than have ZMMFS looking for spare ram, and finding the wrong slot, would it be possible just to tell it to use bank F, and set that up accordingly? Then it knows exactly which bank to activate every time.

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

Re: MMFS Development and Support

Post by Coeus » Thu Oct 03, 2019 4:23 pm

Boydie wrote:
Thu Oct 03, 2019 11:57 am
Apologies if this is what you’re already saying, but thinking laterally from this, if the first thing MMFS finds on startup is the 12k spare ram, left over from setting up shadow ram, does this happen in a consistent, reliable manner (ie same ram area every time)? If so, and that location can be known, could the B+ version be amended to use that 12k as its workspace like the B+’s 12k?
That did sound like a brilliant piece of lateral thinking but looking into it in more detail I am now not so sure. The top 12K of a Solidisk RAM bank when in its initial position is in the same place in the memory map as the 12K on the B+. What could be the spanner in the works the the top 4K.

With the B+ the selection of the 12K workspace is separate from the selection of the sideways ROM bank. The switching in/out of the 12K is done by code in the top 4K of the B+ MMFS ROM and relies on the fact that the top 4K of that ROM remain in the memory map from B000 to C000 while the bottom 12K get switched between ROM and RAM.

We could easily change that switch to select the 12K bank on the Solidisk for writing by putting the write to FE32 in that subroutine but we also need to select that RAM bank for reading. As far as I know that means we would need to write to the normal rom select latch at &FE30. That would also have the effect of switching the top 4K which would amlost certainly cause a crash, depending on what is in that 4K space.

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

Re: MMFS Development and Support

Post by Wheel_nut » Thu Oct 03, 2019 4:52 pm

Instead of making ZMMFS find a vacant Sideways RAM slot on the Solidisk Board, would it be easier to nominate the Bank for ZMMFS to use?

Steve Picton, in his variant of MMFS on his TurboMMC support CD, uses this method to use the first Byte of the SWMMBL Rom Image to contain the Hex identity of the Bank into which SWMMFS is loaded at boot up.

Just a thought ..... :idea:
#1 BBC Model B Issue 7 + 1770 DFS + Dual TEAC Floppy
#2 BBC Model B Issue 7 + 8271 DFS + Dual Floppy + Speech + PiTubeDirect on KenLowe's Tube Level Shifter
#3 BBC Model B Issue 7 + 8271 DFS + Cumana Single Floppy

User avatar
DaveLecky
Posts: 173
Joined: Mon Jul 08, 2019 7:52 am
Location: Airdrie, Scotland
Contact:

Re: MMFS Development and Support

Post by DaveLecky » Sat Oct 19, 2019 3:06 pm

Hi there, I’ve just built a simple electron MMC interface via the Plus 1 printer port, and tested it ok.

However....when I start up the computer for the first time and input *DCAT OR *CAT it hangs until escape is pressed.
E2289912-848C-40CA-A1C5-8DAA309B9209.jpeg
When escape is pressed on a *CAT, it continues ok to *cat disc 0 and displays, >escape , after the *cat info is loaded.
2A5B45E4-B80E-485B-AE31-CE1CD18FD67F.jpeg
When escape is pressed after a *DCAT, it displays only the first disc info, then shows the escape you just pressed.
03CBEC6B-F147-467C-A9D8-1AF0DB6D8C9F.jpeg

Is this normal, I have a plus 3 and a plus 1 with AP6 connected.

After the initial failure of these commands it all works a treat....till I switch off/on again.

I am using EMMFS 1.44

Dave
Electron Plus 3 and plus 1, AP6 and Home made MMFS PP SD interface
Electron Plus 1 Pres AP3/4 with drive
Beeb issue 7 with IFEL 16 socket Rom/Ram board, IFEL SD card, Floppy interface
Master 128, BooBip multi OS,IFEL SD card
Cumana drives,Adder Programmer

rharper
Posts: 471
Joined: Sat Sep 01, 2012 6:19 pm
Location: Dunstable
Contact:

Re: MMFS Development and Support

Post by rharper » Sat Oct 19, 2019 5:22 pm

I have been using the printer port version of MMFS 1.30 since its inception without any problems.
I have updated this to 1.44 and setup another Plus 1 + AP 6 with power to its printer port and modified a printer port cable to connect to a MMC interface. So this is the same as your system but without the Plus 3 and it works fine.
You might try your system without the Plus 3 to see if that is generating the problems.
Always a good idea to clean the contacts on the Electron & Plus 3 connectors with a soft rubber, then IPA.
Ray :)
Raycomp

User avatar
DaveLecky
Posts: 173
Joined: Mon Jul 08, 2019 7:52 am
Location: Airdrie, Scotland
Contact:

Re: MMFS Development and Support

Post by DaveLecky » Sat Oct 19, 2019 6:51 pm

Thanks for the reply,

I’ve removed the Plus 3 and cleaned the connections.i also used another interface.

Still the same for the first use of *dcat and *cat....then ok.

This is my interface..

85404A12-0C41-4262-8CED-BAA5864CCDF8.jpeg

I have another type of interface coming from China, I’ll try that when it arrives on the slow boat.......

Thanks

Dave
Electron Plus 3 and plus 1, AP6 and Home made MMFS PP SD interface
Electron Plus 1 Pres AP3/4 with drive
Beeb issue 7 with IFEL 16 socket Rom/Ram board, IFEL SD card, Floppy interface
Master 128, BooBip multi OS,IFEL SD card
Cumana drives,Adder Programmer

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

Re: MMFS Development and Support

Post by hoglet » Sat Oct 19, 2019 9:24 pm

It's always possible a bug has crept into MMFS that affects just the Elk Printer Port version.

I don't test every release against all supported targets.

I'll see if I can reproduce the issue you are seeing over the next couple of days.

In the mean time, if you have the time, you might want to try:
- a different SD card
- an earlier release of MMFS (e.g. 1.40)

Dave

User avatar
DaveLecky
Posts: 173
Joined: Mon Jul 08, 2019 7:52 am
Location: Airdrie, Scotland
Contact:

Re: MMFS Development and Support

Post by DaveLecky » Sun Oct 20, 2019 8:17 am

Thanks for the suggestions,

I’ll dig about for another sd card, the one I used was a 32gb that I partitioned down to 8gb, I’ll try to re-partition too with different software.

I’ll also try different versions of mmfs.

Thanks
Dave
Electron Plus 3 and plus 1, AP6 and Home made MMFS PP SD interface
Electron Plus 1 Pres AP3/4 with drive
Beeb issue 7 with IFEL 16 socket Rom/Ram board, IFEL SD card, Floppy interface
Master 128, BooBip multi OS,IFEL SD card
Cumana drives,Adder Programmer

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

Re: MMFS Development and Support

Post by hoglet » Sun Oct 20, 2019 12:02 pm

DaveLecky wrote:
Sun Oct 20, 2019 8:17 am
Thanks for the suggestions,

I’ll dig about for another sd card, the one I used was a 32gb that I partitioned down to 8gb, I’ll try to re-partition too with different software.

I’ll also try different versions of mmfs.
A couple more questions:

1. How are you powering the SD Card interface? i.e. Did you make the mod to the Plus One to connect 5V to a spare pin on the printer port connector, or are you powering it in some other way?

2. Can you do *ROMS and let me know what ROMs are fitted in what slots?

Unfortunately, I've not been able to reproduce this yet, but I only have a 8GB SDHC Card.

My current thinking is that it is probably a compatibility issue with the 32GB SDHC Card. There is a debug version for MMFS included in the release zip file called EMMFSDB that would give some useful data on where it's hanging. It logs each request/response to the SD card on the screen.

Dave

User avatar
DaveLecky
Posts: 173
Joined: Mon Jul 08, 2019 7:52 am
Location: Airdrie, Scotland
Contact:

Re: MMFS Development and Support

Post by DaveLecky » Sun Oct 20, 2019 12:53 pm

Thanks for the help

It is the sd card, I had an identical one which works ok....weird.

Both cards were for the raspberry pi, and were working ok .


Thanks again

Dave
Electron Plus 3 and plus 1, AP6 and Home made MMFS PP SD interface
Electron Plus 1 Pres AP3/4 with drive
Beeb issue 7 with IFEL 16 socket Rom/Ram board, IFEL SD card, Floppy interface
Master 128, BooBip multi OS,IFEL SD card
Cumana drives,Adder Programmer

User avatar
DaveLecky
Posts: 173
Joined: Mon Jul 08, 2019 7:52 am
Location: Airdrie, Scotland
Contact:

Re: MMFS Development and Support

Post by DaveLecky » Sun Oct 20, 2019 4:34 pm

Just a thought.....

Is it possible to boot directly into the Beeb file on the sd card.....

Say to the first slot for instance, you could set up a boot file and make yourself a wee menu of sorts.

Just a thought.....

Dave
Electron Plus 3 and plus 1, AP6 and Home made MMFS PP SD interface
Electron Plus 1 Pres AP3/4 with drive
Beeb issue 7 with IFEL 16 socket Rom/Ram board, IFEL SD card, Floppy interface
Master 128, BooBip multi OS,IFEL SD card
Cumana drives,Adder Programmer

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

Re: MMFS Development and Support

Post by hoglet » Sun Oct 20, 2019 4:39 pm

DaveLecky wrote:
Sun Oct 20, 2019 4:34 pm
Is it possible to boot directly into the Beeb file on the sd card.....
Shift break will boot the first disk image in BEEB.MMB

Which BEEB.MMB image are you using?

Dave

User avatar
DaveLecky
Posts: 173
Joined: Mon Jul 08, 2019 7:52 am
Location: Airdrie, Scotland
Contact:

Re: MMFS Development and Support

Post by DaveLecky » Sun Oct 20, 2019 6:09 pm

Hi there

One from the forum with electron stuff on it...ELKBEEB...there is an ssd with a menu in it but it won’t boot.

I’ll try with the working sd card tomorrow, this may have been caused by the dud one too..

Dave
Electron Plus 3 and plus 1, AP6 and Home made MMFS PP SD interface
Electron Plus 1 Pres AP3/4 with drive
Beeb issue 7 with IFEL 16 socket Rom/Ram board, IFEL SD card, Floppy interface
Master 128, BooBip multi OS,IFEL SD card
Cumana drives,Adder Programmer

Post Reply

Return to “8-bit acorn hardware”