MMFS and Pi1Mhz JIM ram disk

[dudleysoft71]

Okay, I've built a new version that should have fixed the issues, I had to just a delay after writing each page register, reading them back returns 0 for every one so it just locks up waiting for a response, is there an issue with reading addresses that have a write function attached to them?

I've changed the name to have JR in the name (for JIM RAM)

This requires the kernel build posted above, there are all the usual builds included.

mmfs.ssd

(200 KiB) Downloaded 5 times

Let me know if this fixes the issues, oh and remember to call the file beeb.mmb, not beeb.mmc as Dominic put in his post, I was scratching my head why it wasn't working when it was not reading the file because I'd used the wrong name.

[KenLowe]

Yes! That's working a treat now. Tested with SWMMFS, so PAGE is sitting at a nice &E00 (with ADFS ROM *UNPLUGged).

What an excellent addition to Pi1MHz! Well done guys . This effectively makes my User port and Printer port SD card readers obsolete & frees up the ports for other stuff. Certainly on my systems where I've already got the Pi1MHz board. It seems faster on the 1MHz bus too!

Is the M5000 emulation still broken with this latest firmware build?

[hoglet]

What an excellent addition to Pi1MHz! Well done guys . This effectively makes the User port and Printer port SD card readers obsolete. Certainly on my systems where I've already got the Pi1MHz board. It seems faster on the 1MHz bus too!

You do realize that this is effectively read-only? i.e. nothing is currently written back to Jim_Init.bin. So anything you save is lost across a power cycle.

[KenLowe]

Ah, good point. I hadn't tested that. I did read earlier in the thread about a possible dirty flag / write back feature, so hopefully that's coming at some point!

...but, regardless, it's still an excellent addition to Pi1MHz - even if it doesn't write back to the beeb.mmb file.

Another nice feature for the future would be the ability to select different beeb.mmb files that are saved on the SD card. Possibly something similar to the jukebox feature in BeebSCSI.

[hoglet]

I've made the copy faster. It was 38.2uS worse case. It is now 6.8uS worst case (PiZero ). I've also made the readback happen after the copy so that you can test for the copy to be complete.

Good stuff!

This is now fast enough that it resolves the issue with James's original MMFS release on my Pi Zero.

I'm looking forward to seeing how you did this.

Dave

[hoglet]

I've changed the name to have JR in the name (for JIM RAM)

Any chance you could push the latest changes back to your github fork?

Dave

[dudleysoft71]

I've pushed my changes back to my fork, I've tidied up the code a bit, but seem to be having a few issues with stability. It should reject commands it doesn't understand, I just tried running a random game from Tricky's menu and the game hung with a black screen and then after CTRL-Break I ended up with no disks visible in MMFS, I didn't have time to look into what was happening, I imagine NFS is causing some issues with games since it uses an extra page. I will have to investigate further.

I've attached an new SSD of the latest build version which matches the code in github.

mmfs.ssd

(200 KiB) Downloaded 6 times

[hoglet]

I've pushed my changes back to my fork, I've tidied up the code a bit, but seem to be having a few issues with stability.

It seems pretty stable for me.

Which version of Tricky's Games Menus are you using? There are several linked in the thread.

If you can fix a specific game that crashes, let me know and I'll try to reproduce.

Dave

[dudleysoft71]

I just downloaded the MMB version for MMFS, it was the latest version available on the first post on the last Thursday ABUG dev night.

I think I tried Thunderstruck today, the instructions loaded, then got a black screen and after Ctrl-Break the whole MMB file had vanished. I guess I should try disabling NFS, since it's probably not compatible with some of the games, so it might be causing issues of its own.

[dp11]

I've made the copy faster. It was 38.2uS worse case. It is now 6.8uS worst case (PiZero ). I've also made the readback happen after the copy so that you can test for the copy to be complete.

Good stuff!

This is now fast enough that it resolves the issue with James's original MMFS release on my Pi Zero.

I'm looking forward to seeing how you did this.

Dave

Originally there was a right modify write for each byte. But as we know there is a page going to be written we can optimise the reads out.

I've pushed the latest version to github for people to play with.

[KenLowe]

This latest version of Pi1MHz doesn't seem to be working with the latest (or earlier) 1MHz based MMFS. I'm getting corruption when I *DCAT or if I try to *DIN.

[dudleysoft71]

I won't be able to take a look until Thursday now, in the office the next 3 days, the latest Pi1mhz was released too late to test with this build, but I can take a look and see what is happening,

I wonder if something broke in loading the mmb file into memory, does the first disk *CAT alright?

[dp11]

There is corruption bug. Let me investigate

[hoglet]

There is corruption bug. Let me investigate

This has given me an excuse to look at the new Pi1MHz_MemoryWritePage() implementation.

It took me a while to understand things, but the new assembler code looks correct to me.

Looking at the pattern of corruption when you change pages, it looks like only bytes 0,1,4 and 5 in each 8-byte block are updated. Bytes 2,3,6 and 7 remain unchanged from their previous values.

Now. if I replace:

Code: Select all

strd r0, [r6], #8

with:

Code: Select all

str r0, [r6], #4
str r1, [r6], #4

Then it starts working correctly.

So it looks like when you do an STRD to an I/O address, the write of the second word is ignored.

Do we know whether 64-bit writes to I/O addresses are meant to work?

BTW, I'm using a Pi Zero.

Dave

[dp11]

Thanks for looking at this. Some IO does support 64bit writes others don't.

[dp11]

I'm not going to be home for a while, but stmia r6!,{r0,R1} might work

[hoglet]

I'm not going to be home for a while, but stmia r6!,{r0,R1} might work

It seems to fail in the same way.

Dave

[dp11]

Okay the writes are getting combined to do 64 bit AXI transfer and receiving device only supports 32bit accesses so two stores is the way to go.

[dp11]

It's got late. I have push my latest version ( V1.12), but haven't fully tested it.

[KenLowe]

Tested very lightly, but everything seems to be working nicely. Specifically:

• ADFS
• M5000
• MMFS
• RAMFS

Are RamFS & MMFS images both able to exist in Pi1MHz at the same time? It looks like that's the case, and I can just switch between RamFS and MMFS without any corruption occurring, which is awesome!

[Mince]

Just to add to this, I've given ESWMMFS a test in my Electron with the Pi1MHz connected to the AP5 and that all seems to work well, and very snappy, too! This is a great alternative to a separate MMFS (not least because takes a bit of height out of my AP5 stack!).

The two things you lose are the ability to take the card out easily and get files on and off (my fault, really, as I put the Pi1MHz in a box!) and that nothing is written back to the SD card to keep. The former I can solve in various ways (Econet, Gotek, or even temporarily swap to the ElkSD Plus 1), but the write back is probably the main issue, although I mainly write files to the ADFS hard disc.

Thanks all for the work on this!

[dudleysoft71]

I've had to take down the git repository because of an issue with git hub and my work email address getting accidentally used for a commit, and git's habit of keeping everything around forever.

I've attached the modified source here so it can be re-integrated into the build.