Pi1MHz Software

[dp11]

What are you expecting on the monitor ?

[james]

Anything more than blackness ...

If that's a it should be, I'll pop it in the shifter and see what happens.

Edit: The thinking being to see if it looks happy whilst booting, with no obvious errors, before plugging it in to the Master.

[dp11]

Unless you have enabled the video there will be nothing on the Pi screen.

[james]

Ah. It helps if you take the SD card out of the 'big computer' and put it back in the Pi. With my apologies.

Is there anything I can see on the now-running Pi to confirm the 1MHz software is running happily?

[dp11]

Plug in into the beeb and do P.$&FD00

[james]

Hallelujah! Thank you!

Having built an install to test the Pi, the answer seems to have been to repartition the SD card back into 1 partition, re-format it FAT32 and then copy just the 'firmware' directory files across onto the blank card.

If you hook up a monitor, unlike a full Pi OS install which is quite chatty during boot, the 1MHz software is silent.

When working on the Master, P.$&FD00 does now return some helpful information.

"If you want a prepared ADFS Harddisc you can copy https://www.domesday86.com/wp-content/u ... UN_2_5.zip to the root of the SD-CARD"

This does not seem to have worked for me. An empty directory "BeebSCSI0" has appeared on the SDCARD. If I manually copy scsi0.dat from the zip file to BeebSCSI0, the Master can now see its hard disc. Did I misunderstand something else?

[BeebMaster]

Just to confirm, if it helps, the Raspberry Pi being used for Pi1MHz doesn't run an OS like certain of our other favourite RPi Beeb add-ons (e.g. Pi Econet Bridge). So a blank SD card is used for Pi1MHz with the firmware copied onto it. It's not necessary to install anything on the SD card apart from the Pi1MHz firmware. The firmware includes its own kernel image which would overwrite any previously installed OS's kernel image anyway.

Dragging the "BeebSCSI0" directory from the zip file to the Pi SD card root should have replicated its contents I think, ie. scsi0.dat and scsi0.dsc but maybe they need to be extracted first and then copied to the SD card?

[Ukwebb]

What have I missed?

The image isnt like a normal pi OS, there is no UI or anything. its whats known as a bare metal image.

1. Format the card as FAT32
2. copy the contents of the Firmware folder from github onto the root of the SD card
( so bootcode.bin/ config.txt etc are all in the root level )

3. copy over the blank HDD files from the domesday link

4. Plug it into your ADFS enabled BBC via the 1mhz bus

5. boot your pi with it
the boot up process takes just a second or two, and doesnt recognise USB devices or output any video signal

6. boot up the beeb
7 *MOUNT 0
8 *CAT
and you're away

[james]

I did get there in the end, thank you all.

Installing Pi OS on the card first confused things. But as this is my first Pi I wanted to see what it was like …

Having watched Linux booting up verbosely innumerable times in my last job (it’s all in the cloud), the silent boot of the 1MHz threw me.

Again, thanks all. I’m off to see if I can access the RAM disc.

[Soruk]

I did get there in the end, thank you all.

Installing Pi OS on the card first confused things. But as this is my first Pi I wanted to see what it was like …

Having watched Linux booting up verbosely innumerable times in my last job (it’s all in the cloud), the silent boot of the 1MHz threw me.

Again, thanks all. I’m off to see if I can access the RAM disc.

I previously never had much luck with the RAM disc (I had this set up really as a mass storage interface), but updating to V1.07 (as showing in P.$&FD00) which I installed from the master branch of the git repo's firmware directory, it now works.

[james]

RAM disc with Sprow’s RAMFS sideways ROM working fine!

[KenLowe]

I previously never had much luck with the RAM disc (I had this set up really as a mass storage interface), but updating to V1.07 (as showing in P.$&FD00) which I installed from the master branch of the git repo's firmware directory, it now works.

Yes, some folks were having issues with older firmware, that were resolved by upgrading to v1.07:

viewtopic.php?t=27999

[dp11]

I've pushed V1.11 to github, please give this a good try out. This support the new MMFS that has been discussed on the other thread. Also M5000 has had a number of improvements to better match real hardware.

[BeebMaster]

I will have a go with this soon, time to dust off my PiSCSI wish list for 2024 I think.

[KenLowe]

I will have a go with this soon, time to dust off my PiSCSI wish list for 2024 I think.

Be aware, there is an issue with the MMFS implementation that is currently being investigated:

viewtopic.php?p=420100#p420100

[dp11]

Latest version of the software for people to try. Don't use any important data yet just incase. Lots on under the hood improvements. Biggest new feature is in build SWR load of rom images to get people up and running without burning roms. X%= 0 ( default at power up) :Call&fc88 will display a new help screen. Both MMFS (X%=4:CALL&fc88) and MFFS2 (X%=5:CALL&FC888) should now be support ( with the standard MMFS caveats about BEEB.MMB being in the first 16 files and starting in the 1st 4Gbytes of the SDARD). Framebuffer code updated to the latest from Pitubedirect. Screen redirector can be enabled with x%=2:Call &fc88.
Let me know of any issues

[KenLowe]

Latest version of the software for people to try. Don't use any important data yet just incase. Lots on under the hood improvements. Biggest new feature is in build SWR load of rom images to get people up and running without burning roms. X%= 0 ( default at power up) :Call&fc88 will display a new help screen. Both MMFS (X%=4:CALL&fc88) and MFFS2 (X%=5:CALL&FC888) should now be support ( with the standard MMFS caveats about BEEB.MMB being in the first 16 files and starting in the 1st 4Gbytes of the SDARD). Framebuffer code updated to the latest from Pitubedirect. Screen redirector can be enabled with x%=2:Call &fc88.
Let me know of any issues

This looks awesome. A couple of quick questions, as I can't test this right now...

I notice there are two MMFS ROM images in the archive.

Firstly, the version that is called MMFS2 - is that the one that doesn't need the beeb.mmb container (sometimes also referred to as MMFSv2)? Or is it the version that is bundled with the MMFS distribution and labelled as: 'MMFS2 Model B/B+: - for a second user port at &FE80'? I'm assuming it's the former. If it is the former, then it's probably better to refer to it as MMFSv2 to avoid confusion with the &FE80 version of MMFS (which is also called MMFS2)!

Secondly, the version that is called MMFS - is that the standard user port version, or is that the new version that is designed to run via the 1MHz interface?

I guess we can put whatever version we want into the ROMS folder. I'm sure I'll get a bit more info once I view the help screen.

Thanks!

[hoglet]

If it is the former, then it's probably better to refer to it as MMFSv2 to avoid confusion with the &FE80 version of MMFS (which is also called MMFS2)!

Ken, as of early January the MMFS release structure has changed slightly to avoid this confusion.

Specifically MMFS/U/MMFS2 is now called MMFS/U2/MMFS

See the notes here:
https://github.com/hoglet67/MMFS/releas ... mfs_1_55_1

[KenLowe]

Ah, ok. My download of 1.55 is dated October '23, so I missed that change. That should eliminate any confusion. Thanks for doing that.

[KenLowe]

Hi Dominic,

This is absolutely brilliant !

Answering my own earlier question...

The MMFS and MMFS2 ROM images are both built to read beeb.mmb and .ssd / .dsd files respectively from the same SD card that is running Pi1MHz. So, all very much self contained. I've tested both lightly, and both are working flawlessly. I've also loaded up the ADFS ROM, and been able to use that to read the scsi disc images that are stored on the Pi1MHz SD card, so that's working nicely too.

A couple of quick questions / comments:

• It looks like the SWR loading software hunts for the first available free bank, starting from bank 15. Is that correct?
• When saving from the beeb back to the disc image, does this actually save back to the SD card, or does it just save back to a RAM copy of the disc image? I can perhaps test this myself tomorrow!
• On my machine, the reset which occurs after the SWR load is complete doesn't actually initialise the new ROM. I need to do a further BREAK for that to work. No major deal.
• Can this new functionality be disabled, via cmdline.txt, in the event that we have two Pi1MHz devices attached to the 1MHzbus at the same time? Similar to what we've done with the other Pi1MHz features?

Edit: Using MMFS2, and saving from the beeb back to the disc image does indeed save back to the SD card. I even tried formatting one of my .dsd files, and that blanked the disc image on my SD card, and it remained blank even after a power cycle . I'll try the equivalent with MMFS on a disc image in the beeb.mmb file shortly.

Edit2: Using MMFS, and saving from the beeb back to the disc image in the beeb.mmb does also write back to the SD card. Again, I was able to format a disc image, which blanked the disc image in the beeb.mmb file and it remained blank even after a power cycle. Oddly, though, the *FORM command on the MMFS ROM didn't work (it came back with a 'Disc already formatted' message), so I ended up using one on the ADT ROM.

Edit3: Ah. A quick look through the 6502code.asm file reveals how the SWR detection code works. Those dots that appear on the screen represent ROM bank tested, counting from 15 downwards. I was always seeing three dots, so I now understand this equates to finding SWR at bank 13, which is correct.

[KenLowe]

I've spotted what might be a minor issue. If I set X%=5 to load MMFS2, and then set X%=0, I don't then get the help screen. MMFS (X%=4) and ADFS (X%=3) both work fine:

[KenLowe]

I've just built the SWRAM versions of MMFS & MMFS2 for 1MHz, and now have PAGE at &E00. Again, all running very nicely. I renamed the two different SWMMFS.rom files to MMFS.rom and MMFS2.rom, and copied over to the ROMS folder on the SD card, so they could be loaded via the helper:

SWMMFS2 for 1MHz

SWMMFS for 1MHz

Given that these ROM images are being loaded into a SWRAM bank, the SWMMFS version should probably be the default offering here. Is there a downside to doing that?

[hoglet]

Given that these ROM images are being loaded into a SWRAM bank, the SWMMFS version should probably be the default offering here. Is there a downside to doing that?

Only that the SWMMFS build lacks the *ROMS command.

I would include both flavours, using different X% values.

Dave

[dp11]

Thanks for the comments. I have fixed the help screen now. I have also included the SW versions of MMFS as I think missing the ROMS command is a better option. The mmfs also has a tweak to support BEEB.MMB to be anywhere in the FAT and not just the file 16 files. Again please backup your data before trying.

[KenLowe]

All working nicely with both SWMMFS & SWMMFS2 from the limited testing so far (no writes yet, only reads). Being able to access beeb.mmb from anywhere in the FAT is an added bonus. Thank you!

[hoglet]

All working nicely with both SWMMFS & SWMMFS2 from the limited testing so far (no writes yet, only reads). Being able to access beeb.mmb from anywhere in the FAT is an added bonus. Thank you!

Be warned: BEEB.MMB still has to be unfragmented.

Dave

[KenLowe]

On my machine, the reset which occurs after the SWR load is complete doesn't actually initialise the new ROM. I need to do a further BREAK for that to work. No major deal.

Hi Dominic,

I was having a look at some other reset code, and noticed the following does a harder reset:

Code: Select all

LDA #&97
LDX #&4E
LDY #&7F
JSR &FFF4
LDA #&C8
LDX #&03
JSR &FFF4
JMP(&FFFC)

Would it be possible to add that extra OSBYTE command to your reset routine, to see if that helps with initialisation?

Thanks.

[dp11]

New 6502code.bin file which should add the system via wite.

[KenLowe]

That's sorted it, thanks.

[hoglet]

New 6502code.bin file which should add the system via wite.

Code: Select all

    LDA #&7F
    STA &FE4E
    LDA #200
    LDX #3
    JSR OSBYTE
    JMP (&FFFC) ; Reset

If you are short of space, I suspect the subseqent OSEBYTE (*FX 200,3) is now superfluous, as a power up BREAK always triggers a memory clear.

Dave