A new MENU system for MMC/Gotek

[Rfairman]

More problems
If to put my ssds on a usb stick (no tricky menu) I can chain a program on my 5.25 I can copy from the 5.25 to to ssd and I can chain it ok
If I use trickies menu system I can boot a disk ok.if I save a chain able program from my 5.25 disk to that ssd it wont chain
. I just get bad program

Is trickies menu grabbing some memory and not releasing it. I originally thought it was a ff problem but problem is not there when I use my own ssds on a non menu disk I have *unplugged adt but problem persists

[tricky]

It might be that the size of the .SSD is trimmed to the size of the files on it.
If the game is marked as save or something like that, it will leave some extra blank space, or if is it marked in the comments the same as Prince of Persia, it will copy the whole disc as is.

[Papalapa]

I'm newbie with Acorn Electron, I'm sorry if something that I ask is obvious.

I downloaded the BEEB.MMB file from tricky's post and as Elkulator cannot load MMB files I extracted the SSD files using MMB Explorer.

When I try to run any SSD file on Elkulator I always get the "Disc error 50 at :0/000000". What I do is to I load the file on "drive 0" and later press SHIFT+F12. The screen shows "Acorn ADFS" and the error message yet mentioned.

My intention is to check the games into the BEEB.MMB file in order to make my own selection. I want to keep the SSD files instead of only one MMB file. Soon I'll receive the ElkSD64 for my Acorn Electron and I prefer to have all the SSD files in separate way because in this way is easiest to add some individual new file.

How can I do this?

[rmbrowngr]

There are two different file systems available for the Electron\Elkulator, ADFS and DFS. Tricky’s collection of disk images are for the Beeb and are DFS. The hint is the file extension e.g. .ssd -single sided disk,

The Elkulator can be configured for both. You can download disk images from https://www.stairwaytohell.com/ or you can go to the website http://www.acornelectron.co.uk/ And purchase a massive collection of disk and tape images, with lots of additional material.

[Papalapa]

There are two different file systems available for the Electron\Elkulator, ADFS and DFS. Tricky’s collection of disk images are for the Beeb and are DFS. The hint is the file extension e.g. .ssd -single sided disk,

The Elkulator can be configured for both. You can download disk images from https://www.stairwaytohell.com/ or you can go to the website http://www.acornelectron.co.uk/ And purchase a massive collection of disk and tape images, with lots of additional material.

On the Elkulator disc menu I have checked the three options (Plus 3 enable, ADFS enable and DFS enable) so, it should load DFS files from Tricky compilation without problem isn't it?

[rmbrowngr]

On the Elkulator disc menu I have checked the three options (Plus 3 enable, ADFS enable and DFS enable) so, it should load DFS files from Tricky compilation without problem isn't it?

With all of these enabled you’ll need to use the command *DISK to select DFS, or *ADFS for ADFS. If you don’t want ADFS at all unselect it from the menu and it’ll default to DFS.

[danielj]

On the Elkulator disc menu I have checked the three options (Plus 3 enable, ADFS enable and DFS enable) so, it should load DFS files from Tricky compilation without problem isn't it?

Most of the Tricky menu disk images won't work on the electron, even if you can read them. Those that do will be far too slow - the BBC's hardware is quite different to the Electron's even though most devices appear at the same addresses, those devices are implemented by the ULA and consequently only perform a subset of the functions provided by the hardware in a BBC Micro.

d.

[Wheel_nut]

GOTEK.zip/GOTEKmenu.ssd contains some GOTEK utilities:
*DIN (drive) image_number, is for inserting a disc image into a drive.
*DBOOT image_number, should insert the disc image and then try to boot it like SHIFT-BREAK.
*DBOOT0, is a shortcut for *DBOOT 0 and is what is used as !BOOT on all the discs in the menu except the first.

I am trying to use your utilities to control access to my own compilation of SSDs on a separate USB Drive and am obviously doing something wrong ... but what?

My Drive is in nav-mode = default and your Gotekmenu utilities are in SSD #33. I start with SSD #33 as the current Disk. DFS is Acorn v1.2 with 8271 Controller and MMFS Disabled. Page is at &1900.

• If I type *DIN 29, the Gotek whirrs for several seconds and I then get a Command Prompt but SSD #33 is still the current Disk.
  EDIT: CORRECTION: The current SSD DOES change to SSD #29 but the OLED display doesn't update until I do a *CAT
• If I type *boot0, The Gotek whirrs and SSD #0 is selected; Since there is no !BOOT file on this SSD, it hangs until I press Break; SSD #0 is now the current Disk. I think this is working as designed ...
• Again with SSD #33 as the Current Disk, If I type *DBOOT 29, the Gotek whirrs for several seconds and I then get a Command Prompt but SSD #33 is still the current Disk.

I have tried disabling ADT but it makes no difference.

Robin

[tricky]

It will only work correctly with the supplied FF.CFG, specifically nav-mode.
AFAIK, this is still a restriction of the firmware, but I don't think I will be updating the core system even if this restriction is lifted.

I would use one stick for TrickyMenu and add disc with the exe I posted and a separate one for human access.

[Wheel_nut]

It will only work correctly with the supplied FF.CFG, specifically nav-mode.
AFAIK, this is still a restriction of the firmware, but I don't think I will be updating the core system even if this restriction is lifted.

Hi Tricky,

I don't understand the restriction of the firmware ... but are you saying that your GOTEKMenu.ssd utilities will only work with nav-mode = indexed and the SSDs named DSKAnnnn.SSD in sequence?

I would use one stick for TrickyMenu and add disc with the exe I posted and a separate one for human access.

I use your Menu system and Games unmodified on its own USB Drive. That seems to work perfectly for me.

I am using a separate USB Drive for my own SSDs with your GOTEKMenu.ssd added and appearing in the order as #29. Since these SSDs are not named using the DSKAnnnn.SSD, I am using nav-mode = default on this Drive. Should I give up on this?

Robin

[tricky]

The firmware allows you to select disc N, where N is identified in indexed mode by the number part of the disc name. In default, it is the Nth directory entry afaik, but I don't know how directories affect this, nor how you know which the Nth entry is.
Until the firmware adds a different way of addressing discs, I wouldn't bother pursuing your method, although in theory it can work.
In theory, you could*load din and then select the discs in turn and build a table which you could then present as a menu, but I don't know what operations would cause the disc numbers to change.

[Wheel_nut]

The firmware allows you to select disc N, where N is identified in indexed mode by the number part of the disc name. In default, it is the Nth directory entry afaik, but I don't know how directories affect this, nor how you know which the Nth entry is.
Until the firmware adds a different way of addressing discs, I wouldn't bother pursuing your method, although in theory it can work.
In theory, you could*load din and then select the discs in turn and build a table which you could then present as a menu, but I don't know what operations would cause the disc numbers to change.

Hi again Tricky, I queried the numerical ordering of the SSDs by Flashfloppy with Keirf and he stated that in nav-mode = default, the SSDs are numbered in alphanumerical order starting with the lowest (say AAAcornsoft) being Zero and then in ascending alphanumerical order by number.

I can confirm that this is the case because I have listed the SSDs in alphanumerical order on the PC to a file using the command "E:\>dir *.ssd/b > ssdlist.txt " which creates a file called ssdlist.txt, listing the SSDs in alphanumerical order. Also. The Rotary Encoder steps through the SSDs in this order and your *DIN utility acceses the SSDs in the order as listed.

Both *DIN n and *BOOT0 access the correct SSD by this convention. The only one that doesn't seem to work for me is *DBOOT n which whirrs and then returns a command prompt but the Selected SSD doesn't change.

I really believe that this is feasible ... I just don't know how!

Robin

[tricky]

I don't know why dboot wouldn't work as it is the same code as din apart from parsing the drive, unless your !boot is like mine, a copy of dboot0, in which case it will boot back to 0 again.
The problem you will have is adding a disc will renumber all existing discs after it. You could try renaming the menu discs _N.ssd assuming that _ will confer first, or even just the number, assuming that custom discs will have names not starting with a digit.

[Wheel_nut]

I don't know why dboot wouldn't work as it is the same code as din apart from parsing the drive, unless your !boot is like mine, a copy of dboot0, in which case it will boot back to 0 again.

OK, I give up on this. I don't understand what you are saying above and I don't have the ability to diagnose what is happening any further.

The problem you will have is adding a disc will renumber all existing discs after it. You could try renaming the menu discs _N.ssd assuming that _ will confer first, or even just the number, assuming that custom discs will have names not starting with a digit.

This is not a problem for me. As I described earlier, I have created a pseudo DCAT file which I *TYPE to the screen using a preset FKey. It is not a big deal to edit this file if I add/ delete/ rename any SSDs. Keirf's Firmware is very predictable and reliable in its behaviour and enables me to access the SSDs in alphanumerical order.

It would be nice to have a *DCAT and *DRECAT for the Gotek but I can get by for now.

[KenLowe]

I don't know why dboot wouldn't work as it is the same code as din apart from parsing the drive

I just downloaded the GotekMenu.zip file from further back in this thread. The dboot file doesn't have anything in it. I suspect that might have something to do with it!

GotekMenu directory listing

Memory dump of dboot

• Again with SSD #33 as the Current Disk, If I type *DBOOT 29, the Gotek whirrs for several seconds and I then get a Command Prompt but SSD #33 is still the current Disk.

Try using this version of dboot instead. That should get it working.

[Wheel_nut]

• Again with SSD #33 as the Current Disk, If I type *DBOOT 29, the Gotek whirrs for several seconds and I then get a Command Prompt but SSD #33 is still the current Disk.

Try using this version of dboot instead. That should get it working.

Hi Ken, Thank you for spotting that ... and yes indeed it does work! YAY!!! It's going to be a busy day...

Tricky, I believe that *DBOOT n is hard coded to *RUN the !BOOT file in the selected disk after switching to it. Would it be a big job to change it to query the *OPT4 of the selected disk and *EXEC or *RUN as appropriate?

Thanks to both of you, - Robin

[KenLowe]

I believe that *DBOOT n is hard coded to *RUN the !BOOT file in the selected disk after switching to it.

I don't think that's right.

Here is *DBOOT (drive) image

It hasn't had much testing and is as *DIN, except that it reads half of the catalogue into &A00..&AFF to read the two bits to determine how to handle !BOOT.

I was expecting an OSBYTE command to read the current value, but I can't find it. As long as you don't need the cassette/serial buffer until after the new disc has started to !BOOT, it should work.

If anyone has a simple legal way to do this I will take a look.

I've just tested with disk images of Exile (*OPT4,3) and Time & Magik (*OPT4,2) and both boot when using the *DBOOT xx command. Also worth noting that Exile is a single sided disk, and Time & Magik is a double sided disk, and these are both handled just fine.

[tricky]

Thanks for spotting the Ken, I don't know how that happened.
I have written the code to do the right thing for EXEC, RUN and LOAD, but can't remember what for.
I was going to add code to check the run address for *LOAD and run as a BASIC program for &801F or &8023, but never got around to it.
I'm not feeling too well, so probably won't be getting mucch coding done over the weekend.
I made a joystick though as I have enough concentration for that

[Wheel_nut]

Hi Tricky,

I am sorry that you are not feeling well and must apologise for any distraction or pressure I have caused you. I hope that it is nothing serious and that you will soon be well again.

I have had many hours of stimulation and entertainment with your work on the Gotek to make it usable for me and I thank you for your creativity and skil in its inplementation.

Stay safe and get well soon.

Robin

[tricky]

Thanks, I love questions and answering where I can. I'm just not 100%.

[Wheel_nut]

I've just tested with disk images of Exile (*OPT4,3) and Time & Magik (*OPT4,2) and both boot when using the *DBOOT xx command. Also worth noting that Exile is a single sided disk, and Time & Magik is a double sided disk, and these are both handled just fine.

Hi Ken, I tried this again and it still isn't EXECing the !BOOT file on the target disk. It is switching to the target disk but seems to be trying to run the !BOOT file rather than the *OPT 4,3 (EXEC) is expecting. The screen flashes strange characters and then Beeps and clears the Screen and hangs. a Break and then Shift-Break EXECutes the !BOOT file correctly.

I will do some more testing in daylight tomorrow with different SSDs and will report here.

Robin

[KenLowe]

I've just tried another disk here. Asteroids, which is disk 21 on my Gotek. This disk is configured *OPT4,3, and if I *EXEC !BOOT it loads fine. If I *TYPE !BOOT, this is what I get:

Code: Select all

>*TYPE !BOOT
CH."LOADER"

>

If I then mount the Gotek-DBOOT disk, and type '*DBOOT 21' the disk switches to Asteroids, and it loads up fine again.

What version of DFS are you trying this on? I'm using DFS2.26 for 1770 controller.

[Wheel_nut]

What version of DFS are you trying this on? I'm using DFS2.26 for 1770 controller.

The disk I was using was very similar to yours with a !BOOT file simply Chaining a Basic Program but it doesn't work. I am using DFS 1.20 on the 8271 Controller.

I have another Beeb with a 1770 Controller and DFS 2.26 which I can try tomorrow.

[KenLowe]

Ok, when I try with 8271 controller and DFS1.20, I get a 'File not found' error after it switches to the new disk. Tried switching to DFS0.98, but get the same error. This is on a disk set to *OPT4,3. Trying to *DBOOT to a disk set to *OPT4,2 gives me a 'Bad command' error. Both disks boot fine on this machine if I shift / break. Needs further investigation...

[tricky]

I can't remember how I detect the setting, but if I do, it is probably by loading the catalog, but I thought that I uploaded the source. I haven't checked as I haven't been on the pic since this morning.

[KenLowe]

I can't remember how I detect the setting, but if I do, it is probably by loading the catalog, but I thought that I uploaded the source. I haven't checked as I haven't been on the pic since this morning.

Indeed, that's exactly what you do:

Here is *DBOOT (drive) image

It hasn't had much testing and is as *DIN, except that it reads half of the catalogue into &A00..&AFF to read the two bits to determine how to handle !BOOT.

I was expecting an OSBYTE command to read the current value, but I can't find it. As long as you don't need the cassette/serial buffer until after the new disc has started to !BOOT, it should work.

If anyone has a simple legal way to do this I will take a look.

I think the official way to do this is via a OSGBPB call with A=&05 - Read Disk Title + Boot Up Option. It's detailed on page 168 of the Advanced Disk User Guide.

The disk I was using was very similar to yours with a !BOOT file simply Chaining a Basic Program but it doesn't work. I am using DFS 1.20 on the 8271 Controller.

Ok, try this version of dboot. It works with both my 1770 and 8271 controllers. I've hacked in an extra *D. command before running the *E. *R. *L. commands, which seems to do the trick. I've also included source files for *DIN and *DBOOT. It's been a bit rushed, so there may be errors!

Edit: Disk image removed. Updated image available here:

viewtopic.php?p=292503#p292470

[tricky]

I just had a quick look and OSGBPB would less code and I do read the catalogue to get the *OPT 4,X.

[Wheel_nut]

Ok, try this version of dboot. It works with both my 1770 and 8271 controllers. I've hacked in an extra *D. command before running the *E. *D. *L. commands, which seems to do the trick. I've also included source files for *DIN and *DBOOT. It's been a bit rushed, so there may be errors!

GOTEK-DBOOT-V2.ssd

Hi Ken,

I can confirm that your DBOOT-V2 is working with my 8271 Controller and DFS 1.2 and I have tested it with several SSDs with *OPT 4,3 and the !BOOT execs correctly every time. I have also tested it wit !BOOT files which simply Chain a Basic Program and that works too.

I now need to add DBOOT to all of the SSDs on my USB Drive which will allow me to navigate directly from one SSD to another without going back to mu Menu SSD. That should keep me entertained for a while and I will report my experience here.

Thank you for picking up and fixing my problem with this. It has made the Gotek usable for me.

Tricky, I hope you feel better soon and thank you for these excellent utilities. Stay safe and get well ...

Robin

[tricky]

Thanks Wheel_nut, and thanks Ken for the work-a-round.
Wheel_nut, there are some .ssd scripts, you could probably automate the process, although depending on the number of discs, the manual approach might prove faster

[Wheel_nut]

*DBOOT0, is a shortcut for *DBOOT 0 and is what is used as !BOOT on all the discs in the menu except the first.

Hi Tricky and Ken,

I am confused as to what *DBOOT0 is and what it is meant to do. The GOTEKMenu.ssd contains DBOOT, BOOT0 and DIN but no DBOOT0 so I am I correct in assuming that BOOT0 is what you refer to as DBOOT0 in the rest of the thread?

Now, If *BOOT0 is meant to do the same thing as *DBOOT 0, then I suspect that it also needs the @KenLowe tweak as it doesn't execute the !BOOT file on my 8271 Controller equipped Beeb.

Ok, try this version of dboot. It works with both my 1770 and 8271 controllers. I've hacked in an extra *D. command before running the *E. *D. *L. commands, which seems to do the trick. I've also included source files for *DIN and *DBOOT. It's been a bit rushed, so there may be errors!

Ken, I have given your tweaked *DBOOT a good workout and everything seems to be working as designed. I'm afraid that the technicalities of what you did are way above my pay grade and I would appreciate your help if *BOOT0 needs the same tweak.

Robin