MMFS and Pi1Mhz JIM ram disk

[BigEd]

Maybe use the SD Card Association low-level formatter on the card? And then put things into a fresh FAT filesystem?

Perhaps a screenshot of the card contents as a listing? I'm wondering if there's a typo that you just can't see!

[KenLowe]

Maybe use the SD Card Association low-level formatter on the card? And then put things into a fresh FAT filesystem?

Yeah, I might try that this evening.

Perhaps a screenshot of the card contents as a listing? I'm wondering if there's a typo that you just can't see!

This is what I took yesterday from one of my cards. I think it's of the same disk as I posted yesterday:

Command Prompt listing

[hoglet]

I can reproduce this issue and it looks like a Pi 1MHz firmware bug.

What I found is the FatFS f_open() call to open Jim_Init.bin is failing. So I added some debugging code:

Code: Select all

bool filesystemReadFile(const char * filename, unsigned char * address, unsigned int max_size)
{
   UINT byteCounter;
   FRESULT fsResult;
   FIL fileObject;
   printf("Mount State = %d\r\n",filesystemState.fsMountState);   
   if (filesystemState.fsMountState == false) {
         fsResult = f_mount(&filesystemState.fsObject, "", 1);
         if (fsResult != FR_OK) {
            printf("Mount failed: %d\r\n", fsResult);
            return false;
         }
   }
   fsResult = f_open(&fileObject, filename, FA_READ); //// <<<<<<<< this is failing
   if (fsResult != FR_OK) {
      printf("Open failed: %d\r\n", fsResult);
      return false;
   }
   f_read(&fileObject, address, max_size, &byteCounter);
   f_close(&fileObject);
   return true;
}

What I'm seeing is:

Code: Select all

Mount State = 21
Open failed: 12

I think the problem is Pi1MHz init_JIM() is relying on filesystemState.fsMountState to be 0 on power up, rather than explicitly calling filesystemInitialize().

(filesystemState is marked with NOINIT_SECTION so it won't be cleared)

If the value happens to be non-zero, then f_mount() is skipped, which then causes f_open() to return an error response code of 12:

Code: Select all

 	FR_NOT_ENABLED,			/* (12) The volume has no work area */

If I add the following to init_JIM() before filesystemRead() then everything works:

Code: Select all

 filesystemInitialise(0);

I'm not sure why it's working for James, I guess it's just luck that on his Pi the memory happens to be zero. Or maybe it's a very old version?

The NOINIT_SECTION has been present since June 2022:
https://github.com/dp111/Pi1MHz/commit/ ... e5e763e762

Dave

[dudleysoft71]

You could try this version of the Pi1Mhz software, you'll need to copy the JIM_Init.bin file back into it (otherwise the file is too big to attach)

I noticed that your image has more start up files and the executables are different sizes, I can't remember which version I'm running, but I know it was working on my beeb.

[dudleysoft71]

Okay, that sounds like a definite cause, I did look at the code and was looking for the file system initialisation, I didn't look too hard, but it definitely looks like that change has broken it and it only worked by pure luck before.

[hoglet]

I can't remember which version I'm running, but I know it was working on my beeb.

It was compiled June 2020, so I think pre-dates the NOINIT_SECTION change.

We should probably just wait for Dominic to fix this, and push a new official version of the firmware.

[KenLowe]

I can reproduce this issue and it looks like a Pi 1MHz firmware bug.

Ok, so I wasn't doing anything wrong. That's a relief!

If I add the following to init_JIM() before filesystemRead() then everything works:

Code: Select all

 filesystemInitialise(0);

Sounds like a fairly straight forward fix, but the non initialisation does seem a bit deliberate given it's part of the NOINIT_SECTION.

We should probably just wait for Dominic to fix this, and push a new official version of the firmware.

Agreed. I'll stand by!

[james]

I've had a go with MOS 3.50 and your MAMMFS and $&FD00 gives

Code: Select all

>P.$&FD00
 
 Pi1MHz v1.07
 Commit ID: 9200659?
 Date : Sep 29 2023 18:26:29
 Pi :9000c1 1000/400MHz 31.5C

And then *DCAT gives some error that *SPOOL didn't capture because I'd changed filing systems (*MMFS) and now my Gotek's playing up and ...

But the *DCAT error was something like 'Bad disc number' </forgetful>

Edit: And *ROMS, for reference:

Code: Select all

>*FX0

MOS 3.50
>*ROMS
ROM F TERMINAL 01
ROM E VIEW 07
ROM D Acorn ADFS 03
ROM C BASIC 07
ROM B EDIT 0A
ROM A ViewSheet 03
ROM 9 DFS 95
ROM 8 ?
RAM 7 ?
RAM 6 ?
RAM 5 ?
RAM 4 Master MMFS 7B
ROM 3 ?
ROM 2 ?
ROM 1 ?

And the SD card:

Code: Select all

% ls -l
total 125120
drwx------  1 james  staff     16384 11 Jan 15:31 BeebSCSI0
-rwx------@ 1 james  staff    641717  5 Jan 13:59 BeebSCSI_Quickstart_LUN_2_5.zip
-rwx------@ 1 james  staff  61448192 13 Mar 13:15 JIM_Init.bin
-rwx------@ 1 james  staff      1594 30 Sep 10:05 LICENCE.broadcom.txt
drwx------  1 james  staff     16384 11 Jan 15:01 System Volume Information
-rwx------@ 1 james  staff     52456 30 Sep 10:05 bootcode.bin
-rwx------@ 1 james  staff         2 30 Sep 10:05 cmdline.txt
-rwx------@ 1 james  staff       358 30 Sep 10:05 config.txt
drwx------@ 1 james  staff     16384 30 Sep 10:05 debug
-rwx------@ 1 james  staff      3213 30 Sep 10:05 fixup4cd.dat
-rwx------@ 1 james  staff      3213 30 Sep 10:05 fixup_cd.dat
-rwx------@ 1 james  staff     71216 30 Sep 10:05 kernel.img
-rwx------@ 1 james  staff     64464 30 Sep 10:05 kernel7.img
-rwx------@ 1 james  staff    801564 30 Sep 10:05 start4cd.elf
-rwx------@ 1 james  staff    801564 30 Sep 10:05 start_cd.elf

[dp11]

Thanks for the testing, I'll fix it

[dp11]

Attached are some kernels this should fix the filesystem not being initialised. This is very much a test build.
NB M5000 is broken in this build .

This also adds a feature of loading a file beeb.mmc if it exists to JIM+16Mbytes.

[dudleysoft71]

Thanks, currently it won't know to look for it at 16mbytes, does it leave the info at fd00 if it loads an MMB file at 16mbytes? If so then I can repurpose the reset command to check for Pi: in the first 3 bytes and switch to reading from 16MBytes in.

[KenLowe]

Ok, I'm getting a bit further now, but it's still not working quite right for me. I can now do a *DCAT and it lists all the discs. However, if I try to *DIN a disc I'm getting corrupt disc images. I'm using the Retroclinic beeb.mmb file, and have renamed it to JIM_Init.bin. I've tried both the MMFS and SWMMFS ROMs, and both give the same results.

[dp11]

Thanks, currently it won't know to look for it at 16mbytes, does it leave the info at fd00 if it loads an MMB file at 16mbytes? If so then I can repurpose the reset command to check for Pi: in the first 3 bytes and switch to reading from 16MBytes in.

It does leave FD00 alone. I think I'd prefer if mmfs always looked at +16Mbytes. That way M5000 and FD00 are safe. I can return a status byte it a load occurred.

[dudleysoft71]

Yeah, would it be possible to add to the message at fd00 to say that the mmb file has been loaded? I could check for it in the rom so we can fail gracefully if it's not loaded

[KenLowe]

Yeah, would it be possible to add to the message at fd00 to say that the mmb file has been loaded? I could check for it in the rom so we can fail gracefully if it's not loaded

I'm not sure that would work in all cases. Would it not be possible for other things (eg ADFS or M5000) to overwrite the message so you'd lose the status flag, if written to that area?

[dudleysoft71]

Very true, how's this sound for a initialisation sequence:

1. Set JIM page bank to 0x010000 (16 MBytes)
2. Check at FD0C-FD0F for signature BMMB, if found file is loaded skip to the end
3. Set JIM page bank to 0x000000
4. Check for MMB file loaded in message, if not found error out
5. Switch back to bank 0x010000 and write BMMB to FD0C-FD0F

This should allow us to detect the MMB file on subsequent resets, and also allow it's detection from the default state on initial boot.

[KenLowe]

It sounds like @dp11 will update the Pi1MHz firmware to give you a status register to read if beeb.mmb has loaded at +16MB.

Personally, I would just read that status register, and perhaps do some sanity check to ensure the loaded beeb.mmb file is the correct file. I wouldn't bother looking at the &FD00 message and I'd do away with the requirement to rename your beeb.mmb to JIM_Init.bin. That said, I'm not totally familiar with how the paging works, so that maybe is what you're actually suggesting!

[hoglet]

Ok, I'm getting a bit further now, but it's still not working quite right for me. I can now do a *DCAT and it lists all the discs. However, if I try to *DIN a disc I'm getting corrupt disc images. I'm using the Retroclinic beeb.mmb file, and have renamed it to JIM_Init.bin. I've tried both the MMFS and SWMMFS ROMs, and both give the same results.

I'm also seeing this.

Edit: Rest of post removed while I try to better understand this.

Dave

[hoglet]

I'm also seeing this.

OK, after getting myself a bit confused with page addresses, I think I understand the issue here.

I wrote a small test program to mimic the way James is writing to the Jim page registers:

What I found was a delay of approx 40 cycles (20us) is needed between writes of the page registers. Without this delay, the subsequent write is lost. In James's MMFS driver, the three page register writes are pretty much back-to-back.

I think the reason for this is when ever a page register is written, the Pi1MHz firmware copies the 256 byte page from DRAM into a block of IO registers.

Code: Select all

void ram_emulator_page_addr(unsigned int gpio)
{
   uint8_t  data = GET_DATA(gpio);
   uint32_t addr = GET_ADDR(gpio);

   if ( addr == 0xfd)
   {  if (data > (JIM_ram_size))
         data = JIM_ram_size;
      page_ram_addr = (page_ram_addr & 0x00FFFFFF) | data<<24;
   } else {
   if ( addr == 0xfe)
      page_ram_addr = (page_ram_addr & 0xFF00FFFF) | data<<16;
   else
      page_ram_addr = (page_ram_addr & 0xFFFF00FF) | data<<8;
   }
   Pi1MHz_MemoryWrite(addr,data); // enable the address register to be read back
   // setup new data now the address has changed
   for( uint32_t i = 0; i < PAGE_SIZE ; i++)
      Pi1MHz_MemoryWrite(Pi1MHz_MEM_PAGE + i, JIM_ram[page_ram_addr+i]);
}

The copy is the for loop at the end of the ram_emulator_page_addr() callback function. The time this takes will depend on the Pi model.

I think the problem actually only happens when there are three page register writes closely spaced:
- the first write will trigger the ram_emulator_page_addr() callback function which takes some time
- the second write will be buffered in the GPU->ARM mailbox and eventually processed correctly
- the third write will be dropped (*) if it happens before the second write is read from the GPU->ARM mailbox

(*) Or maybe it will overwrite the second write ???

So James I would try adding a short delay after each of the &FCFD/E/F writes.

I would also suggest testing with a Pi Zero rather than a faster Pi.

Dave

[dp11]

A good bit of debugging. I'll think about speeding this up.

[dudleysoft71]

Okay, I will take a look into this, I will grab the new kernel image and get it working from there, adding the delay shouldnt be too difficult, and won't affect loading speed much.

I would need to check, but if the kernel set the value back on the page register after it had finished processing then it should be possible to keep reading until it matches the new value, this would also allow writeback if the data has changed since we could just wait for the paging register to change, and know the operation had finished

[dp11]

I'll work on this tonight as well

[hoglet]

I would need to check, but if the kernel set the value back on the page register after it had finished processing then it should be possible to keep reading until it matches the new value, this would also allow writeback if the data has changed since we could just wait for the paging register to change, and know the operation had finished

That should work, but only if Dominic moves this line to the end of the ram_emulator_page_addr() function.

That would be better than a hard coded delay.

Better still would be to make the 256b copy so fast the problem goes away, but I don't see how that is possible.

Dave

[dp11]

Better still would be to make the 256b copy so fast the problem goes away, but I don't see how that is possible.

Dave

Let me see what the complier has generated. Another option is to setup DMA to do the copy.

[BigEd]

A bit of MMU twiddling might help??

[dp11]

A bit of MMU twiddling might help??

Would be lovely if MMU pages could be 256bytes, it would make something in the 6502 core faster, but sadly 4K minimum.

[hoglet]

A bit of MMU twiddling might help??

Pi1MHz "borrows" a 512b block of I/O registers to cache the current read state of addresses FC00-FDFF. This allows the GPU to service 1MHz bus reads with something approximating fixed latency. It's the top half of this cache that's being re-loaded (by the for loop) whenever a page register is updated.

So I'm not sure there are any MMU tricks that can directly help with this. Also, I think the minimum ARM page size is 4KB, whereas we are working with 256b Jim pages.

That said, given the 1MHz bus is half the speed of the 2MHz tube, I wonder whether this use of I/O registers is really necessary. An alternative would be to use a single page of normal memory, locked into L2 cache. That would be much faster to update, and might avoid the page ever needing to be in DRAM.

Edit: We're also not trying to make this work with 700MHz Pi Ones; the slowest supported Pi is the 1000MHz Pi Zero.

Dave

[hoglet]

James,

I noticed you have published your MMFS changes here:
https://github.com/dudleysoft/MMFS/comm ... z-jim-ram/

That's an impressively clean implementation, with everything done in the driver.

I see no issues in merging this upstream when you are ready.

My only suggestion is to add a unique (J) suffix to the DEVICE_NAME macro here:
https://github.com/dudleysoft/MMFS/blob ... ERSION.asm

That will make sure the MOS sees the J and U builds as different, allowing both to be present (with a suitable ROM manager). I think if the first 1K of two ROMs is identical, the MOS assumes the lower one is an alias and disables it.

Dave

[dudleysoft71]

Thanks dave,
I deliberately tried to keep all the changes in the driver file, except where it needs to glue into the build.

I'll make the changes for the new Pi1mhz tonight, and add a delay between page changes for now, delaying the sector value change until after processing would be my preferred method of syncing because we can't guarantee the speed of the Pi, especially if its doing framebuffer or M5000 processing as well, and if writeback is added that will need awaiting.

[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.