Single density version of "SD HxC Floppy Emulator Direct Access mode" #179
Comments
|
Yes sorry I had totally forgotten about this. I will work on it and post progress (and firmware to test) here on this ticket. |
|
Question: I assume a 512-byte sector size would be okay? 256-byte is more normal for FM formats, but I don't think 512-byte is precluded. It makes things simpler if the logical sector format and overall protocol is identical to MFM (except for essential track-framing differences between FM and MFM). Only difference will be defaults to 5x512-bytes sectors (FM) vs 9x512-byte sectors (MFM). |
|
I think Direct Access Mode is already in "single density" if you intend MFM DD (250 kBit/s), on track 255 or I'm wrong? |
|
Okay here is a firmware for you to test. The source is in Github branch |
|
I think the beeb OS only supports 256 byte sectors without driving all the different controllers directly, but I see how far I get. |
|
If you need changes just let me know. It's mostly easy to switch to 256b sectors. What were you planning to use the Direct Access mode for by the way? I don't think you're writing an image selector, right? |
|
The primary use is to select disk images. |
|
That may require me to implement a new command. But get the protocol going on BBC first. |
|
Well, I can read the status, which gives the "HxCFEDA" string and "FF-v0.1". |
|
Command 4 isn't implemented! Why not try a set lba command? You could check it worked by seeing if contents of sector 2 changes (that's part of the window into lba space)? Ps I can implement command 4. Or a variant with semantics of our choice. |
|
seems to read different sectors, got to go now, but I'll try setting a new LBA base tomorrow. |
|
Cmd 1 set LBA base seems to return a consistent set of sectors, so it looks like we have two way comms. |
Identical to the original DD/MFM layout except for data rate, FM framing, and default # sectors (5 vs 9). Refs #179
|
Okay the single-density FM access is now in master branch. I will implement CMD_SELECT_IMAGE (cmd 4) and notify you here when that's done. That simply takes a 16-bit slot number/index. Very simple. |
|
Thanks |
|
Will this work with indexed mode? |
|
DSKA9999.ssd won't work because only slots 000-999 are supported. However that means that DSKA0000.ssd up to DSKA0999.ssd will work. |
|
I will get on with CMD_SELECT_IMAGE soon but I wanted to rework some FF internals at the same time to give more flexibility to direct-access mode. |
|
No problem, I think I am ready at my end, 2897 games/apps over 792 single sided disk (ssd) images indexed in 25KB with a menu system, just need to test with CMD_SELECT_IMAGE. |
|
CMD_SELECT_IMAGE is implemented in the latest FF version (v0.12). What mode are you running FF in for your tool, is it indexed mode (DSKA0000 etc)? I have supported CMD_SELECT_IMAGE for all navigation modes, but I might restrict it to Indexed and Autoboot-Selector modes as it doesn't make a great deal of sense for direct-navigation mode. |
|
Thanks, Indexed mode as it made the most sense, but I was thinking of supporting the other modes so as not to rename the files although this would be very fragile. |
|
Perhaps for Direct-Navigation mode it will make more sense to provide a different command, eg allow you to specify a full filename (or even full path, perhaps via a sequence of chdir() type invocations). Could provide a FS-type interface... opendir, getnext, chdir, openfile, etc |
|
Assuming you don't want to go straight at the block layer and do FAT munging yourself. I'm thinking... not ;) |
|
Anyway let me know how CMD_SELECT_IMAGE goes for you at the mo. I didn't really actually test it... |
|
It's not going well, I can't update to 0.12 instead of UPD, I get EJE followed by rdo. |
|
Noone else has reported this so it's probably you, and doubly so if you did not update the bootloader to 0.11 (if you're not sure, then you didn't). Are you definitely holding both buttons at power on? |
|
I didn't update the bootloader to 0.11, I'll go and RTM! |
|
I can't program the boot loader or firmware for 0.11 or 0.12
I'll try another GOTEK.
…On 28/11/2018, Keir Fraser ***@***.***> wrote:
Noone else has reported this so it's probably you, and doubly so if you did
not update the bootloader to 0.11 (if you're not sure, then you didn't). Are
you definitely holding both buttons at power on?
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#179 (comment)
|
|
You don't need to update the bootloader. But it is the bootloader that runs first, checks buttons, and displays UPD. So that should behave just as before as the bootloader hasnt changed. It must be user error. Be sure buttons are pressed during power on. |
|
That is correct. I have had the Zero USB Gadget running successfully previously as I have mentioned. It works very effectively for remotely adding image files etc. to my Amiga without having to physically swap USB devices. I pretty much followed this: https://www.raspberrypi.org/magpi/pi-zero-w-smart-usb-flash-drive/
I neglected the watcher configuration as the Amiga is almost always hard-reset and I wanted to avoid thrashing the SD card.
I spoke to JF De Nero about this too and they had embarked on a similar project: http://hxc2001.free.fr/floppy_drive_emulator/
It is pretty useful (when it worked!). I would be happy to share my approach with you and the community if I can resolve this issue. There are some physical modifications required to the USB cable to remove the power supply.
… On 11 Dec 2018, at 00:13, Keir Fraser ***@***.***> wrote:
This is with your Pi Zero as USB stick?
If the LCD displays F-F then it has lost connectivity to the USB stick -- it thinks it has been pulled out.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
You'd probably find it useful to make a debug build of FlashFloppy and find out in the serial log what happens when the USB disconnects. You may also need to add extra logging to the USB stack. |
|
Absolutely - you suggested this once before. I am in the process of working out how to do this. Any clues?
Thanks again for your help.
… On 11 Dec 2018, at 07:04, Keir Fraser ***@***.***> wrote:
You'd probably find it useful to make a debug build of FlashFloppy and find out in the serial log what happens when the USB disconnects. You may also need to add extra logging to the USB stack.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
“debug=y make -j8“ will leave debug hex file in the root build dir. Adjust baud rate at the top of src/console.c Connect a serial ttl adapter just as you would for serial firmware programming. Actually I have one permanently connected and Gotek jumpered in programming mode. I then "make flash start serial" to program my new firmware, start it running, and connect a dumb serial terminal. |
|
A consideration when creating the filesystem with 42GB of space: sudo dd bs=1M if=/dev/zero of=/piusb.bin count=43008 The file system Samba share shows as NTFS on Windoze. Perhaps there is a problem with drives over 32GB? Reference: |
|
So, frustratingly, the following setting needed to be reordered and appended on the Pi: sudo modprobe g_mass_storage file=/piusb.bin removable=1 ro=0 stall=0 I have no idea when or why this was required to change but was the cause of the write problems. In other news, I got FlashFloppy firmware to debug build but I encountered a problem building HxC_FF_File_Selector: m68k-amigaos-strip -s FFManager |
|
I will try upgrading to latest tool chain and see if I can repro the build failure. |
|
Did you have any luck with this?
Are you suggesting that the amiga-gcc version is too recent? That its
dependencies are too recent too? Do you know which versions work?
Warm regards.
|
|
I didn't have time, and then I forgot. Could you please open a new ticket for this amiga-gcc build issue? |
|
FYI I just implemented CMD_SELECT_NAME which allows to select a new image by name. |
|
I'm sorry, I'm being a bit lazy here, but has something changed with this option in recent FW? |
|
Which recent firmware version are you testing? |
|
To be honest, I have forgotten as it wasn't in my PC, but I believe they downloaded the new version in January. I think that the problem has been around for quite a while though - maybe even a year. |
|
Yes I'm interested if I get more details especially if this is on latest 3.x stable firmware. |
|
I finally got some hardware out and can confirm that this feature works correctly on my old first ge GOTEK with v3.39 loader and firmware with and without logging. I don't have any new HW, so will have to wait until someone with new HW can check what is going on, assuming that logging is fairly detailed for error conditions :) |
Did this end up as 256 byte sectors? |
|
No, it is 5 * 512-byte sectors. That is 1 * command/response sector (sector ID 0) + 4 * "LBA window" sectors (sector IDs 1-4). |
|
Thanks, I released my menu program for the BBC Micro on the day you added the SD option on track 254, sending a single sector of 256 bytes with only the first 11 set and whatever bytes were in code memory for the CRC and other params and it has worked on everything! |
|
Yes that's a couple of things that don't make sense. If you are only writing a 256-byte sector then it's unlikely you would write enough bytes following the sync pattern to satisfy the check here, let alone the CRC check: https://github.com/keirf/flashfloppy/blob/master/src/image/da.c#L372 Is it possible that the FDC interprets the IDAM as reported by FlashFloppy, and does "sane" things to read/write a 256-byte prefix of a 512-byte sector? FlashFloppy doesn't generally care about motor on/off. Even if configured to emulate motor, only the READY signal line is affected. Not read/write of data. |
|
The call that I am using doesn't care about READY iirc. |
|
The easiest way to see what is happening will be to connect a Gotek running debug firmware, and gather serial logs via a USB-TTL adapter. Then FlashFloppy can be modified to show what it receives on writes, and is serving up on reads. For the latter, actually I can probably take a dump of the track using Greaseweazle... Really it's impossible though to see how FlashFloppy could be serving up CRC-qualified 256-byte sectors, or accepting same for writes. So the question is what happens between your code and what "hits the wire". |
|
Here is a dump of track 254.0 from FlashFloppy v3.42. If you look at it in HxC tools (for example) you will see 5 512-byte sectors as expected. The only complaint I have of the layout is that a bit more gap post-index would be nice (and perhaps an Index Address Mark). |
|
For comparison, an SCP with both the FM and MFM direct-access tracks. |
|
By the way, on digging into this some more for another issue, on Greaseweazle, it seems to me that the sector size issued in say a READ DATA command is not checked against the sector header's N field off disk. Hence mismatches between those sector sizes don't stop READ/WRITE operations. It seems to me that in the command-requested size is smaller, reads would be truncated and writes would be nul-padded. Which is probably what you're seeing. I'm not sure this behaviour is documented though! Or necessarily consistent across FDC clones. |
|
That sounds right, including the not working on the odd piece of new HW. |
|
FF could choose a smaller sector size, however 512 bytes is natural for LBA addressing the Flash drive. It's also the usual MFM sector size. I could allow the sector size to be adjusted, but that would probably require at least one command to be transferred at the default 512-byte sector size. |
What do you mean by command hash? Do you mean CRC? That is not usually calculated by the host. It resides outside the sector data/payload, and gets automatically generated/verified by the FDC. |
|
Sorry, haven't been well. |
|
Oh yes, the original HxC spec does have a checksum byte. FlashFloppy never implemented it; the contents of that byte are not checked. You don't need to write 5 sectors. You only need to write sector 0 to issue a command. Which is what you're already doing, and successfully (most of the time!). It might be interesting to know the model and configuration of the GOTEK which needs to be "spun up". Is it one which can be configured to respect motor signal w.r.t. generating the READY signal? It could be in that case that no spin up means no READY and the FDC is aware of this and fails the write. Just a theory. Apart from this FF really doesn't care about spinning up., |
|
I mean the eighth command parameter or whatever number it is that you said was ignored :) |
Please add a single density version of "SD HxC Floppy Emulator Direct Access mode".
I think you suggested using track 254 and leaving the rest the same.
The text was updated successfully, but these errors were encountered: