A new MENU system for MMC/Gotek

[mikeh_nz]

Got a bit side tracked this evening, but I have now updated the three utilities *din *dboot and *dboot0

…I've included the BASIC source code … The BASIC files are saved to the 'S' directory.

All credits go to Tricky for the original utilities. I've just tweaked them a little bit!

GOTEK-DirectAccess.ssd

More testing and I can get din, dboot, dboot0 to work if I use these versions. Even some of the older ones worked too (except for the one where the dboot was accidentally a file of 0x00s)

[mikeh_nz]

A quick look at the two dboot0’s

The initial call to OSWORD &FFF1 contains the real difference.

Not working dboot 0 passes:
0x0070: 80,84,00,FF,FF,03,4B,FE,
0x0078: 00,21,00,00,00,00,00,00,
0x0080: 00,00,00,00,48,78,43,46,
0x0088: 45,44,41,00,04,00,00,??(not intialized)

Working dboot 0 passes:
0x0070: 80,84,00,00,00,03,4B,FE,
0x0078: 00,41,00,00,00,00,00,00,
0x0080: 00,00,00,00,48,78,43,46,
0x0088: 45,44,41,00,04,00,00,00,

The passing of address 0xFFFF0080 verses 0x00000080 doesn’t make any difference, the key difference is the byte &41 at 0x0079.
Searching through the advanced disk user guide - i see that this is saying write a single 512 byte sector instead of a single 256 byte one.

The dboot0 that doesn’t work (for me) then does the two commands
*DISC
*/:0.$.!BOOT

And the dboot0 that does work, does a
*D.
(A call to OSGBPB &FFD1 with A=5 to get the *opt 4,x)
*R.!BOOT
(Where depending on the *opt 4,x result returned, it will use *L., *R., *E.)

Richard - Would you please consider flipping over your gotek build to use the dboot, din, dboot0 in Ken’s disk image (ie incorporate his source code assembly into your build)?

GOTEK-DirectAccess.ssd

[mikeh_nz]

Edit - I was wrong that the &4B should be a &B - is says later the advanced user guide - that you always add &40 to the command and the OSWORD fixes up the command number using the drive number specified in the first byte of the OSWORD block

It also has examples of drive numbers of 0-3
It talks about negative drive numbers 7f-ff not checking drive status

I wonder what 0x80 equates to -80 in 2s compliment

[tricky]

Still going through it, but &4B should be the command which is "write data multi-sector".
https://archive.org/details/the-advance ... 1/mode/2up
I'm not sure about the multi-sector bit but there doesn't seem to be a single sector!!

I'm just checking the &80 for the drive, where ever I got the original info, this mean, current drive, but it looks like it might mean current drive ignoring status check!

Sector size &21 isn't listed as a real size, but it says that for DFS, it means 256B sectors which is what we want.

I originally got my info from the BBC Micro Disk Filing System User Guide.
https://archive.org/details/bbc-micro-d ... 0/mode/2up

[mikeh_nz]

I tested it out. When I recompiled Ken’s dboot0 with a sector size of &21 - it stops working on my gotek. So I’m confident that it’s the difference that will make it work on my gotek

I can probably poke your dboot0 to use a &41 and get it to work.

I’m guessing that the gotek needs a larger write. Either a bigger buffer on its end, or maybe it’s a timing thing and it needs the write activity to last for longer.

Pages 57-58 have the write multi sector parameters
Later in the book there’s a section of OSWORD that explains that it should be &4B and that -ve drive numbers don’t check drive status. Page 210

[tricky]

If you are running in Double Density mode, it uses track 255 and 512 byte sectors.

I wonder if something has changed in the FW, but it does work on all but two drive-beeb combinations afaik. Maybe yous is a third.
I thought that you were taking about drive number before, which if I had read to the end of the sentence, I would have seen that I chose &80 as it then uses the current drive, which is because by this time, the menu has forgotten which drive to use!

If it is a 512 byte sector thing, that would give us a clue as to what has changed in FF.
I'm sorry, but I don't have a GOTEK that I can use at the moment.

[mikeh_nz]

Thanks for your help on this - I appreciate you’re unable to do much without a gotek.

Recapping my set up:
My setup is just a single gotek attached to a bbc b with DFS 0.9E and a 8271 controller - no other drives.
The gotek is the SFRKC30.AT4.35 model with oled and rotary switch, running FlashFloppy+ 3.42

Is the curated gotek set, meant to be operating in single or double density mode? It appears that your code always writes to track 254 (256 byte sector) and doesn’t have any logic to check between single/double density. Is that correct?

Reading this makes me think I’m running single density as I only have a 8271. If I read it correctly, you need ADFS and a 1770 to get double density.

The dboot0 !BOOTs on DSKA0001-DSKA0430 - all write to track 254 (single 256 byte sector). I’ve found it doesn’t work with my Gotek/FlashFloppy firmware unless it writes a 512 byte sector - I think you’re saying this is a flash floppy bug. Can you point me to their documentation that says it should be a 256 byte sector?

Unlike the dboot0 !BOOTs on DSKA0001-DSKA0430 (which all show the gotek seeking to track 254 and failing to change disks), the menu on DSKA0000 wouldn’t trigger the seek to 254 at all. It just brings the gotek head back from track 8 (where the loading to the DSKA0000 !BOOT menu finished) to track 0

Another observation: *LOADing the working Dboot0 (that writes a 512 byte sector to track 254) into memory (it’s at &1100), waiting for the disk drive to stop “spinning” (ie gotek light goes out), and CALL &1100 - results in no track seeking and changing of disk.

Typing *. and CALL &1100 in quick succession will result in the code working

So another part of the problem is that FF now requires the drive to be at least spinning before it will accept the write to track 254.

Is there any pointer to flash floppy documentation on this index mode track 254 and what’s required?

[KenLowe]

The dboot0 !BOOTs on DSKA0001-DSKA0430 - all write to track 254 (single 256 byte sector). I’ve found it doesn’t work with my Gotek/FlashFloppy firmware unless it writes a 512 byte sector - I think you’re saying this is a flash floppy bug. Can you point me to their documentation that says it should be a 256 byte sector?

Keirf has confirmed that it's 512 byte sectors:

As someone else pointed out, you should be writing a 512-byte sector. Because you write a 256-byte sector the CRC will be wrong and FlashFloppy rejects your write.

No, it is 5 * 512-byte sectors. That is 1 * command/response sector (sector ID 0) + 4 * "LBA window" sectors (sector IDs 1-4).

[tricky]

Thanks, if you check the thread, I thought he had changed it to 256 byte sectors because I thought that was all one of the controllers could do. https://github.com/keirf/flashfloppy/is ... 1913643030
I'll update my code to 512 bye sectors, but not sure about "spinning" the drive up. This was the first disc code that I have written past *load and *save and seeing the addresses to be on the beeb, not a copro.
I'm not saying it is a ff bug, it was my mistake for not asking for it to be changed to 256 when I asked for the track 254 single density option in the first place.

It is a bit annoying that it has been working on nearly all setups all this time!

[KenLowe]

Thanks, if you check the thread, I thought he had changed it to 256 byte sectors

Yeah, it's definitely a bit unclear!

[mikeh_nz]

I’ll have a poke through the advanced disk user guide and see if I can figure out the command to spin up the disk - I have the Gotek and also a physical drive - so I can easily test

[tricky]

Thanks.
I also don't write 5 sectors, but I'm sure that didn't used to be required.
I updated the fw on one of my drivers a couple of months back and it still worked fine, so maybe it depends on the HW too.
My utils run anyway and are kept as small as possible to allow them to be used by other apps without changing them. They use 16 byes of ram iirc for the command and don't calculate a checksum, so I don't think that was ever a requirement either but can't remember if 0 is always a valid checksum, like with adfs.

PS None of these issues came up in the debug log either, which was why I updated the fw (and loader).

[mikeh_nz]

Yeah - we’re only writing a single 512 byte sector and it’s taking the magic string at 0x0080 and I assume any other garbage in memory after that. Hey - it works though!

So I found two ways to spin the disk (and confirmed with an updated dboot0 that it starts the spinning and changes the disk)

• instead of setting the first byte (drive number) to &80, you set it to the drive number (&00-&03). The drive number (well at least the drive 0, drive 1 part), can be found from the Segment0, Segment1 signals of “ OSWORD Read Drive Control Output Register” (command &7D)
• just make a call to “OSGBPB Read Disk Title + Boot Up Option” immediately before making the call to “OSWORD write multi sector”

The second one is much simpler.

Dumb question: how do I get a file out of a .ssd to my pc/phone so I can share it here? (It’s basically just Ken’s dboot0 with his OSGBPB call repeated at the beginning.)

I like how Ken’s OSGBPB call figures out the Opt 4,x setting. If you’re not doing it that way already, you might want to steal that - as it’s a tidy way to do it.

Thanks again for all your help on this. Im looking forward to being able to play a gazillion games!

[tricky]

DFSImager, beebem or probably any emulatoror there are some cmdline utils but I don't use them.

boot method selection:

Code: Select all

	lda #5   : ldx #cmd_line : jsr OSGBPB ; read title, boot option etc

	ldx &70  : ldy &71,x ;; 0:ignore 1:*LOAD 2:*RUN 3:*EXEC
	ldx #'L' : dey : beq boot
	ldx #'R' : dey : beq boot
	ldx #'E' : dey : beq boot
	RTS

.boot

	           stx cmd_line
	lda #'.' : sta cmd_line+1
	lda #'!' : sta cmd_line+2
	lda #'B' : sta cmd_line+3
	lda #'O' : sta cmd_line+4
	           sta cmd_line+5
	lda #'T' : sta cmd_line+6
	lda #13  : sta cmd_line+7

So, it sets the letter before the dot.
Iirc, Ken's dboot is a fixed version of mine, done slightly differently

The strange thing is that on the only system I could try where the menu fails to swap to a disc, changing to a disc manually, waiting and then doing *dboot0 works!

[tricky]

I'm confused, how does it work on any system?
It looks like this check has always been there and I've never had a CRC, only random data/code!
https://github.com/keirf/flashfloppy/bl ... /da.c#L508

Code: Select all

static void process_wdata(struct image *im, unsigned int sect, uint16_t crc)
{
    struct da_status_sector *dass = &im->da.dass;
    uint8_t *wrbuf = im->bufs.write_data.p;
    unsigned int i;
    time_t t;

    crc = crc16_ccitt(wrbuf, SEC_SZ + 2, crc);
    if ((crc != 0) || (sect > dass->nr_sec)) {
        printk("D-A Bad Sector: CRC %04x, ID %u\n", crc, sect);
        return;
    }

...

It should always fail the CRC, except possibly for a single disc!

[mikeh_nz]

I would assume that the DFS code is doing the CRC for us. We just call OSWORD and say "I want to write 512 bytes" and the DFS is doing all the heavy lifting of spinning disks, stepping heads, CRC, pumping the bytes to the 8271, etc.

I totally appreciate that Ken's version is just an extension of yours and I see from your code snippet that you're doing the *Opt 4,x the same way already. I had incorrectly latched onto comments way earlier in this thread where I think you hadn't figured out the OSGBPB call at that stage.
(I certainly didnt know OSGBPB existed - Im new to this stuff).

Id ask that the following changes be made

1. Change the &21 (single sector of 256 bytes) to &41 (single sector of 512 bytes) in the OSWORD call
2. put a "lda #5 : ldx #cmd_line : ldy #0 : jsr OSGBPB" immediately before you assemble & make the OSWORD call.
   (Where cmd_line is somewhere you're fine trashing with the (max 15) returned bytes from OSGBPB.)
3. Low pri feature request: Can the disk number be output to the screen. Eg "Instead of saying "GOTEK din", could it print "GOTEK din 139"?

The second change only really needs to go into the DSKA0000 !BOOT menu codebase. Normally the disk is spinning already as you've Shift-Break-ed the DSKA0001-0500 !BOOT (dboot0). But it might be nice to put it everywhere in case someone *Loads in code and calls it later.

In my "spinning up" testing, I had put the OSGBPB call before the "initialize 0x0070-0x008F to 0x00" loop. Some of the code below it relied on the memory being zeroed (and not containing OSGBPB output).

Somewhat ironically, I see that the OSGBPB call actually returns the drive number as well. (the next byte after the startup option byte). So that could be read and pumped into the first byte of the OSWORD structure (replacing the &80). But I havent tested this. If you're interested in this approach and want me to test it - let me know and I'll happily test that the OSGBPB does indeed return a 00-03 in that byte. (Certainly the code would then make more sense to the reader).

Cheers
Mike

[mikeh_nz]

Side question: What algorithm did you use for the text compression?
Do you recall the approx before/after sizes?

[KenLowe]

They use 16 byes of ram iirc for the command and don't calculate a checksum, so I don't think that was ever a requirement either but can't remember if 0 is always a valid checksum, like with adfs.

It should always fail the CRC, except possibly for a single disc!

Does this code not indicate that a CRC value of 0 is good?

Code: Select all

    if ((crc != 0) || (sect > dass->nr_sec)) {
        printk("D-A Bad Sector: CRC %04x, ID %u\n", crc, sect);
        return;
    }

Edit: I also notice that a new DA command was added, that wasn't present in the original spec. This allows a disk to be selected by name instead of using the index number:

Define CMDs:

Code: Select all

#define CMD_NOP          0
#define CMD_SET_LBA      1 /* p[0-3] = LBA (little endian) */
#define CMD_SET_CYL      2 /* p[0] = drive A cyl, p[1] = drive B cyl */
#define CMD_SET_RPM      3 /* p[0] = 0x00 -> default, 0xFF -> 300 RPM */
#define CMD_SELECT_IMAGE 4 /* p[0-1] = slot # (little endian) */
#define CMD_SELECT_NAME 10 /* p[] = name (c string) */

CMD_SELECT_NAME:

Code: Select all

        case CMD_SELECT_NAME: {
            char *name = (char *)dac->param;
            name[FF_MAX_LFN] = '\0';
            set_slot_name(name);
            printk("D-A Img By Name \"%s\"\n", name);
            dass->last_cmd_status = 0;
            break;
        }

[mikeh_nz]

Code: Select all

#define SEC_SZ 512
#define FM_DAM_CRC 0xbf84

// process_wdata is called with crc=FM_DAM_CRC
//
static void process_wdata(struct image *im, unsigned int sect, uint16_t crc)
{
    struct da_status_sector *dass = &im->da.dass;
    uint8_t *wrbuf = im->bufs.write_data.p;
    unsigned int i;
    time_t t;

    crc = crc16_ccitt(wrbuf, SEC_SZ + 2, crc);
    if ((crc != 0) || (sect > dass->nr_sec)) {
        printk("D-A Bad Sector: CRC %04x, ID %u\n", crc, sect);
        return;
    }
...
}

// crc is computing a crc 16 (see crc.c)
//
uint16_t crc16_ccitt(const void *buf, size_t len, uint16_t crc)
{
    unsigned int i;
    const uint8_t *b = buf;
    for (i = 0; i < len; i++)
        crc = crc16tab[(crc>>8)^*b++] ^ (crc<<8);
    return crc;
}

I think the only way crc is getting to 0 is if the crc (in the two bytes following the 512 bytes) is correct.
The crc check code using SEC_SZ kind of shows that its assuming 512 byte sectors are in use.

[KenLowe]

I think the only way crc is getting to 0 is if the crc (in the two bytes following the 512 bytes) is correct.
The crc check code using SEC_SZ kind of shows that its assuming 512 bytes sectors are in use.

Agreed. I was getting a bit confused with the checksum (parameter 8 ) in the command spec. I don't think that is being used:

Code: Select all

typedef struct direct_access_cmd_sector_
{
 char DAHEADERSIGNATURE[8]; // Must be set to “HxCFEDA\0”
 unsigned char cmd_code; // Command code
 unsigned char parameter_0; // Parameter 0
 unsigned char parameter_1; // Parameter 1
 unsigned char parameter_2; // Parameter 2
 unsigned char parameter_3; // Parameter 3
 unsigned char parameter_4; // Parameter 4
 unsigned char parameter_5; // Parameter 5
 unsigned char parameter_6; // Parameter 6
 unsigned char parameter_7; // Parameter 7
unsigned char cmd_checksum; // Parameters checksum
}direct_access_cmd_sector;
The remaining bytes of the sector must be set to 0x00. 

Code: Select all

CMD_SELECT_IMAGE_INDEX : 0x04
(Note : Firmware v1.8.2.16 or up needed)
When the floppy emulator is in indexed mode or file selector mode this command allows to select the image number to load.

parameter_0 = Image number to load (LSB)
parameter_1 = Image number to load (MSB)

The last selected/loaded image can be read in the current_index field of the status sector.

[mikeh_nz]

Given the CRC is computed from "512 bytes + 2 bytes for the crc", I think is also a strong suggestion that the OSWORD call actually writes the 512 byte sector, plus an additional 2 bytes for the CRC. (ie the CRC is outside of the 512 byte sector payload)

I had a quick look to see if I could find the Intel 8271 datasheet to see if it was the 8271 computing & writing the CRC. But of the limited documentation I could find - my guess is its the DFS code doing it.

[KenLowe]

Given the CRC is computed from "512 bytes + 2 bytes for the crc", I think is also a strong suggestion that the OSWORD call actually writes the 512 byte sector, plus an additional 2 bytes for the CRC. (ie the CRC is outside of the 512 byte sector payload)

I had a quick look to see if I could find the Intel 8271 datasheet to see if it was the 8271 computing & writing the CRC. But of the limited documentation I could find - my guess is its the DFS code doing it.

Hmmm. I'm not sure about that. There's a bit of discussion about the 2 byte CRC in this 177x controller datasheet:

https://info-coach.fr/atari/documents/_ ... 72-JLG.pdf

[mikeh_nz]

hmm - yeah, I think its still a strong suggestion that the crc is contained outside of the 512 byte payload.

With the referenced 1770 pdf doc talking about "built in CRC computation logic", I could believe that the extra CRC bytes are computed and written by the 1770 chip (rather than the ADFS code).

Either way, I dont think the caller of OSWORD needs to compute the CRC and shove it inside the 512 byte payload - its handled by the DFS code, or the 8271 chip (and they compute it from the 512 byte payload).

At least, that's my uneducated guess

[KenLowe]

hmm - yeah, I think its still a strong suggestion that the crc is contained outside of the 512 byte payload.

With the referenced 1770 pdf doc talking about "built in CRC computation logic", I could believe that the extra CRC bytes are computed and written by the 1770 chip (rather than the ADFS code).

Either way, I dont think the caller of OSWORD needs to compute the CRC and shove it inside the 512 byte payload - its handled by the DFS code, or the 8271 chip (and they compute it from the 512 byte payload).

At least, that's my uneducated guess

Yup. That would also be my interpretation.

[mikeh_nz]

The passing of address 0xFFFF0080 verses 0x00000080 doesn’t make any difference,

Just realized that the 0xFFFF0080 is there for Tube purposes - Eg what’s written at the top of page 66

Does the menu now work with the Tube? I remember seeing somewhere in this thread that it didn’t.

I’m not familiar with the Tube - but it seems that if the top two bits of the disk address aren’t set, then the file will be loaded into the Tubes memory address space and execute from there. It makes me think that the !BOOT files (both the menu program and the dboot0’s) would want to be saved with the top two bits set.

Or maybe I have it backwards and the top two bits should be be cleared on the disk, the menu !BOOT should be loaded into the Tubes memory address space, and then OSWORD block should use the 0x00000080 address instead of the 0xFFFF0080 address.

I don’t really know what I’m talking about though

[tricky]

I don't see how anything would be calculating a correct 512 byte CRC as all the DFS and disc controller know it's that I asked for a 256 byte sector to be written.
Looks like Kier doesn't know why it works currently on nearly all systems either!
I will make versions with those changes, but want to understand why things are working and why they are not.

PS I can't remember if I put up the tribe compatible version, but it works locally, at least of an old mmfs.

[mikeh_nz]

The DFS and 8271 know that it’s been asked to write a single 512 byte sector - that what the &41 OSWORD parameter byte does - the top three bits indicate the sector size, the rest indicate the number of sectors.

I’m not sure who (the DfS rom or the 8271) is actually computing the crc16, but the dfs & 8271 does handle 512 byte sectors.

My vector2 BBC disc coping software (by Chalice software) also displays that it handles 512 byte sectors.

[tricky]

Yes, I'm confident that all the beeb controller do, I just didn't know when I wrote it as I thought all the disc formats were 256.
I've got a gotek out of storage, but haven't had time out energy to find a beeb with a disc interface and hook up serial Comms to get the full story from flash floppy.
There are some more comments on the ff thread suggesting that it will depend on the gotek model, and at least they seem to confirm that the params hash isn't used.

[tricky]

Test versions with 512 byte sectors for GOTEK and drive selection instead of &80 (current drive, no checking). https://www.dropbox.com/scl/fo/q2o58ox8 ... 7fsy1&dl=0
Top post updated, only the GOTEK versions should have changed.

These should be "correct", although there is still a question mark about whether the disc needs to be spun up for the menu itself!

If the menu doesn't select the correct disc, try pressing RETURN as soon as it displays to see if that game runs.
if that game is on disc 0, try crsr right and press return before the disc stops "spinning".
If this last test works, but giving it a few seconds and the same game doesn't, it will be the spin-up thing and I'll need to add the hack.

Nearly all GOTEKs seem happy with the old 256 byte sectors, even though they are expecting 512 byte writes as well as just using the current drive, no checking or spinning up but some of the newer ones seem to be getting more picky, wanting things to be correct

As before experimental should be tube co-pro compatible, well, unless the game didn't work before in which case it has a better chance than before!
The experimental should be fine on non-tube co-pro machines too

[mikeh_nz]

Thanks so much for producing this

I’ll give it a try. I had found that the “drive only needs to be spinning” for the &80. If you’ve changed that to a &00, then it will spin up and change disks fine on my gotek.

But I will try it out and confirm.

FYI: I have been using your menu over the last couple of weeks and it’s excellent. I had patched your menu (changing the &21->&41 and the &80->&00) and updated the dboot0 on the other 500 or so disks.

The only minor problem I’ve found is that I occasionally try to load a bbc master game on my model b.

Not that you want a feature request… but if you’re ever playing around with it in the future - I wonder if you have the input data to include a flag in the compressed data to indicate “bbc master only” games? (Eg using two other reserved characters 253,252 to indicate master only games). If so, then you could show a * at the end of the line for menu items that are “bbc master only”

Any chance you’d discuss what compression algorithm you’re using? I was wondering…

I did see this post in the thread that explains the efficient data structures you use - neat!

I mark the end of each title with a reserved character (254 for end of title or 255 for end of title and disc)…

Cheers
Mike