Research Machines 380Z/480Z disk support

[z80micro-mc]

I am running into problems trying to get FlashFloppy to operate with various RM formats. I am failing to persuade FF to pick up the disk geometry correctly.

Most RM formats are characterised by being single sided with fm track 0. Double sided drives are treated as if they were 2 separate single sided drives, tracks on side 0 are all labeled as side 0 as are tracks on side 1.

example trimmed out

At present it would appear to be treating all disk images created with CPMtools in .img format as if they were 346k drives. If I create an image that is a copy of a real drive it can readily read / write the files via CP/M 2.2 fine. However, any attempt to use track 0 seems to fail. I cannot write to it nor format track 0! Hence it is not possible to boot from an image nor to use SYSGEN to copy an image to track 0. I would be greatfull for any ideas.

RM kit formally supports 5.25" and 8" drives but can be persuaded to operate with 3.5" drives.

Thanks

Peter

Full set of IMG.CFG definitions below.

Trimmed, so I can grok this post without migraine!

[keirf]

Ok, that's a lot of formats! Can you pick one that isn't working, and we can dive into it. Perhaps zip the trimmed IMG.CFG, and an example IMG file, and attach to the ticket. If we can fix one or two, hopefully that will extend to the umpteen others.

[z80micro-mc]

Keirf,

Thanks for the prompt reply. I have done some further investigation. I believe that there are 2 main aspects to be looked at:

1) RM Kit uses different pin outs for the floppy drive for 8" drives and for 5.25" drives, this is not an issue for real drives as both can be connected to the same 34 W Drive interface, in fact that is one of the factors used by the disk controller to determine which physical drive type is in use. Hybrid systems exist with both 8" and 5.25" drives attached.

In the case of FF I am looking to emulate both drive types by a single Gotek, holding different images on the USB Stick and was expecting to auto-sense the drive type from the file size and the img.cfg profiles. However, as I understand it the physical connections are controlled by FF.cfg of which there is only support for a single drive type. It also looks at the Index pulse timing (300RPM 5.25" and 360 RPM for 8") to further determine drive type. So for multi drive systems it would require FF to support drive connections on a per img profile rather than a single connection to the Gotek. Which would need to emulate both a 5.25" and an 8" drive.

2) There seem to be issues in the operation of RM DD formats with track 0 having 16 x 128 byte fm sectors or 26 x 128 byte fm secctors. All other tracks are dd -having 9 x 512 byte mfm sectors (5.25") or 26 x 256 bytes mfm (8")

Disk interface variants:

pin 8" 5.25" 2 HeadLD nc 4 Index HeadLD 6 Ready DS3 (DS0 .. 3) 8 nc Index 16 DS3 Motor-on 18 Dir/Side-sel Dir 8" uses pin for both side select and direction of step. 32 nc Side-sel 34 nc Ready

Drive timings:

Drive Head-ld step settle write pre-comp mfm

8" 50 ms 3 ms 35 ms 125 ns 5.25" 50 ms 6 ms 15 ms 125 ns 5.25slow 50 ms 20 ms 48 ms 0

BTW I have 7-segment display - How do I obtain the version number of FF is there a key combination / pwr up that I can use to get it or do I need the OLED display?

Peter

[z80micro-mc]

Single drive but supporting auto detect of drive physical and format profile.

Just to be clear I am not looking to support multiple drive units ie DS0, DS1 on a single Gotek. However, I am hoping to use a single Gotek to autoconfigure its drive characteristics according to which .IMG file is selected as the current drive from a number of possible images on the USB sick.

Peter

[z80micro-mc]

For example I have say 5 different .IMG files on the USB stick.

1) 5.25" 1SQD 360 kb nom DSKA0001.RM5-1SQD.IMG 2) 5.25" 1SDD 160 kb nom. DSKA0002.RM5-1SDD.IMG 3) 5.25" 1SSD 80 kb nom. DSKA0003.RM5-1SSD.IMG 4) 8" 1SSD 250 kb nom DSKA0004.RM8-1SSD.IMG 5) 8" 1SDD 500 kb nom DSKA0005.RM8-1SDD.IMG

As I select a different file I was hoping for FF on the Gotek (DS2) to autoconfigure from IMG.cfg file.

Peter

Peter

[keirf]

You can get the firmware version by pressing the right button with no USB stick inserted. The dotted components of the version number will then be flashed up in turn.

Physical connections: The floppy header pins are hardwired to MCU pins which are hardcoded to have specific purposes (eg, DIR, STEP, INDEX, etc). So you can make a physical interface board for 5.25", or for 8", drives but there's no way to dynamically reconfigure the physical pinning in firmware. You will need a switch, or you will need two Goteks.

The mixed-format FM/MFM issue: Ok, then I need an IMG file and I need the IMG.CFG stanza you are trying to use. I need to know info about the IMG file (is it pre-existing; is it one you created/formatted; etc). And then we can proceed.

[hharte]

Hello Peter,

For the 34 to 50 pin adapter for 8” drives, I used these boards and with FlashFloppy and they work well:

https://gitlab.com/NF6X_Retrocomputing/fd50to34

8” floppy drives also have a 2SIDE# output, which FlashFloppy doesn’t have. The adapter board has a jumper for that purpose, but it would be better if FlashFloppy could control that pin to select between single and double sided disks.

I made an img.cfg for CompuPro 8” floppies and IIRC, the first track being single density did work, but I haven’t tested it recently.

https://github.com/keirf/FlashFloppy/blob/master/examples/Host/CompuPro/IMG.CFG

Take care, Howard

[z80micro-mc]

Howard,

Thanks for the links.

RM Vintage z80 kit 380Z & 480Z use a 34 pin (2x17) IDC connector to go to the physical drives (supporting up to 4 physical drives). The system already has suitable cabling to go from the IDC to the relevant drives. However, as it is an intelligent controller that detects the physical drive type and the media inside the drive, it uses certain signals to distinguish between 8" and 5.25" drives including checking that track 0 is SD and stepping in and out checking for 96 TPI vs 48 TPI drives. It can also detect psuedo 40T media written on a 96TPI drive using double stepping.

The issue is that I was hoping to add a Gotek running FF to the system and be able to emulate any of the drives by changing the .IMG file. I had interpreted the FF.cfg information to mean that the Gotek with FF would emulate any of the physical drives by changinging a couple of config parameters in particular the Shuggart vs IBM-PC, together with the pin_02, and pin_34 config parameters. I wrongly assumed that it could map any of the even pins in the 34 pin header to any function. Which Keirf has now corrected me on.

I am interested in your Compupro 8" configs. How did you create your .IMG files? A block by block copy from a physical disk or using a tool like CPMTools?

I will rewire my Gotek to emulate the 8" drive and see how I get on. With the 446k 5.25" 1SQD, I can access the directory and files ok but the system is not happy with the fm single density track 0. nor will it correctly reformat the disk.

Peter

[hharte]

Hello Peter,

To create the .img files, I used various methods. Mostly, I converted .imd files to .img using the HxC software. I've also created images using dd. I would like to be able to use CPMTools, but it seems there is a deficiency in CPMtools where the it cannot properly handle an 8" disk with only a single track/single head being single-density. I believe this is because it tries to assume that the "offset" must be on a sector boundary. If you have 26128 on one track/head, that works out to 3328 bytes, not divisible by 1024 (the CompuPro sector size.) I think if the disk format was 26128 on one track/head, followed by tracks of 256-byte sectors, it would work.

When I've really needed to use CPMtools to manipulate disks for the CompuPro or another system I have with 8" drives, I use it with "standard" 8" SSSD (1282677) 256,256 byte disk images, and then copy the contents to a FlashFloppy DSDD disk using the real system.

It really doesn't matter how you create the .img file as long as the length is correct. You should be able to boot your system with a real disk and then format the .img file in the FlashFloppy.

You may want to check the GAP3 values. I do recall having an issue with the single-density track at one point, but I don't remember how I fixed it now. It may have been the GAP3 value. A good way to test is just to format the disk in the drive and then examine the .img file in a hex editor. If you have a known good floppy that you also have .img data from, you can copy the disk in your machine from the real floppy to the flashfloppy, and then compare the .img files to see if they match.

You may want to put the .img files aside for now and get raw .hfe working with your system. The nice thing about .hfe is that you can visualize the disk using the HxC tools, and check that the sectors are laid out properly, with proper gaps, bitrate, etc. Once your .hfe images look good and work reliably, then you can work on getting the .img files to work. You can use the HxC tools to convert from .hfe to many other formats, including .img, for verification.

Do you have any documentation on the controller in your system?

Take care, Howard

[z80micro-mc]

Howard,

Thanks for the input.

I had assumed that .IMG format was a file of bytes whose total size = sum of all the sectors in the disk image with no further restrictions other than the disk geometry must exactly fit into it.

8" 1SSD 77 tracks x 26 sectors x 128 bytes = 256256.

I therefor assumed that as a binary file of this size matched an img.cfg stanza that FF would interpret it correctly as an 8" 1SSD disk. I was not aware of any restrictions of the total size needing to be an integral number of 1024 byte or 512 byte blocks. Which would seem to suggest that there is an issue with the IBM-3740 stanza on the distribution. The only ambiguous parameter being the need or otherwise to explicitly specify the data rate as 250 kbps for SD and 500 kbps for DD.

Indeed this is what I interpreted from your 8" 1SSD parameters for .IMG files of length 256256. Did you get the 8" SD config actually working or is there a problem?

Ditto 8" 1SDD with fm trk 0.

26 x 128 bytes    (track 0) 3328 bytes
76 x 26 x 256 bytes (tracks 1-76)  505856 bytes

Giving a total 8" 1SDD file size of 509184 bytes.

As you say these are not integral multiples of either 512 byte blocks nor of 1024 byte blocks. Is this an issue for FF?

I created a file of 256256 bytes of 0xE5 then used CPMTools Gui to add CP/M files to it using RM DPB, DPH CP/M 2.2 values.

As far as I am aware FF is agnostic to operating system overlay, beeing an emulation of a configurable sector based drive emulation the only key configuration information is the physical pin out of the drive and the drive timing parameters (RPM, head load time, step time) FF is emulating and the media format of the psuedo media mounted, ie Trks, BPS, sector size, gap timings, mode.

I was using 3-15 FF, I have now upgraded to 3-23 but am still having problems.

I was treating the Gotek exactly the same as I would for any drive that I was connecting: physical pin out, drive options, timings.

BASF 5.25" are closer to 8" drive configurations than newer Japanese drives (YD274, YD480 96TPI, YD580 48TPI). RM mainly fitted BASF drives 6106/6108 5.25", and BASF 6104 8". Later systems were fitted with YE-Data drives.

I presume from what Kierf has said about physical connectivity, the Gotek is not like an industrial Floppy drive with links (config file parameters) to redesignate the function of the pins on the 34 pin i/f so I will need to think about a pin out bender board.

I will take a look at hfe format. From my perspective I am use to dealing with drives being arrays of logical blocks so .IMG being a RAW format appealed as more straight forwards.

At present I am getting E31 errors for my 8" .IMG files not sure why. The stanza is for 256256 byte files, the file is 256256.

Peter

[z80micro-mc]

Kierf,

If I am reading your img.c sources correctly, support for 8" disks would appear to be missing?

There do not appear to be entries for: 250k, 500k, nor 1m images. So it is not surprising that 1SSD 250K and 1SDD 500k formats are not understood.

Have I miss understood the code or at present am I wasting my time trying to experiment with 8" disk formats and should switch my attention to the 5.25" formats pending new code?

Thanks

Peter

[hharte]

Hello Peter,

I was referring to a limitation in CPMtools, not FlashFloppy’s .img support.

For FlashFloppy, you are correct that the .img has to be exactly the sum of all bytes in each sector.

For a standard SSSD 8” floppy, that is 1282677 = 256,256

For a DSDD CompuPro disk, it is 12826 + 10248*153 = 1,256,704 bytes

Take care, Howard

[z80micro-mc]

Howard,

So I only need a 256256 byte file, which is what I currently have. From your earlier post I was considering if I needed to pad it up by an additional 256 bytes to make it divisible by 512. I don't see any rate setting entries for of 250 for fm nor 500 for mfm, do you know if this is defaulted?

I interpret your last comment that CPMTools needs the file to be an integral number of 512 byte blocks ie is padded up.

Peter

[keirf]

Placing default geometries in img.c is pretty much obsoleted going forward. New geometries are expected to use IMG.CFG, with example configurations being contributed under examples/Hosts folder.

[keirf]

Also note that FlashFloppy expects its IMG files to have no padding: padding short FM tracks up to MFM track size in the IMG file for example is not supported.

[z80micro-mc]

Keirf,

Latest experiments: 1) 346kb blank file (366080 full of 00h) is recognised as a 1SQD drive and my intelligent disk controller allows me to format it Quad (80T @96TPI, trk 0 SD 16x128 fm, trk1-79 QD 9x512 mfm). Having formatted it I can copy files to it including a block by block disk copy. The copy is bootable. However, having formatted it I can not reformat it as the controller detects the fact that it is already formated but that the 2 sides have different densities and refuses to reformat it.

2) 715k (732160 full of 00h) is recognised as 2 of 1SQD drives (B: DS1 side 0, and D: DS1 side 1) and my intelligent disk controller allows me to format it either a side at a time or both sides together as Quad (80T @96TPI, trk 0 SD 16x128 fm, trk1-79 QD 9x512 mfm). Having formatted it I can copy files to it including a block by block disk copy. The copy is bootable.
I can reformat it but only as Quad. Any attempt to reformat it as psuedo 40T 1SDD fails, it always comes up as an 80T drive. Having formatted it again I can reformat it as Quad, copy files to it or block copy an entire disk. The resulting disk is bootable.

On a real Physical 80T drive I can format media as Quad, pseudo 40T DD, pseudo 40T SD quite happily. So it looks as though there is a compatibility issue with double stepping & how the intelligent controller detects the Drive and inserted media characteristics.

All other supported formats have failed miserably!

In particular: 8" emulation neither SD 3740 fm, nor DD system/34. The Gotek still seems to think that it has 80T not 77T and does not seem to accept a Track with 26 Sectors! 5.25" double step media.

I am now running 3-23 FF.

Any thoughts?

Thanks

Peter

I'll generate a handful of files for you to look at. a) Working 2 x 1SQD (346+ 346k), b) working 1SQD, c) failed 2 x 1SDD psuedo 40T, d) failed 8" IBM-3740

[z80micro-mc]

Kierf,

It seems to me that there are 5 aspects to drive emulation:

1) Physical drive parameters including link options: eg IU, HL,HM,AD... such as number of tracks, rpm(s), various delays, and limits to cylinder no and max sector id. Though for some copy protection systems sectors are often labeled with out of range sector labels. 2) Interface pin out mainly determined by (1) 3) Media inserted - standard / HD (that switches speed on some drives) 4) How the Media is formatted geometry: tracks, double step, SPT, Sector size, gaps, c0s0,c0s1 vs c0-nS0,c0-nS1 etc 5) Organisation of the blocks into a filing system: CP/M, MSDOS, etc

Clearly one connects a particular physical drive, but one may insert different media STD vs HD then one organises the disk format onto that media, if I insert suitable media into an 80T drive I can format it to DD 80T, DD 40T (double stepped DS), SD 40T (DS). If one were emulating an HD capable drive it could also be formatted as HD 80T.

Drive has 80T, 77T, 40T support and in the case of 80T may be double stepped to generate psuedo 40T.

Track can be fm 128,256,512,1024 byte sector: mfm 256,512,1024 byte sector supporting 8,9,15,16,18,26 spt.

On a physical 80T (96tpi) drive I can read 40T media but in this case it is the controller + drive that knows that it needs to double step. Some systems have a physical switch to change the drive from 80T to pseudo 40T, others like the RM systems auto sense both the drive and the media. So a 40T drive returns an error for attempts to seek beyond track 40. 8" drives have 360 RPM index pulses and will accept 77T steps. 80T drives are 300 rpm and seek 80T. Unless they are HD in which case some are 360 RPM.

Having determined the physical drive parameters it then decides if the media will support the request format.

Just a few thoughts.

Peter

[z80micro-mc]

BTW

How do I turn on the error logging?

[keirf]

Error logging is in a separate firmware: https://github.com/keirf/FlashFloppy/wiki/Logging-To-USB-Drive

[keirf]

Possibly the implicit fixed geometry of IMG files is confusing matters here. Would you be better with one or more HFE image files? Say, an 80-cyl double-sided 360rpm image with a double-density bitrate (250kbps) might match your 8-inch disks?

The benefit of HFE is it's a raw bitstream -- the sector layout is entirely up to the host system, so there's less "in the way" to go wrong.

[z80micro-mc]

Sounds interesting I'll take a look at it. That still leaves the issue of track limits on the drive and single vs double stepping.

Peter

[keirf]

HFE images have a double-step flag where stepping cylinder to cylinder in such an image requires two step pulses.

Track limits... HFE has a specifiable number of cylinders, any writes beyond which are discarded, and reads will return garbage.

[z80micro-mc]

Kierf,

Might I suggest when you are next looking at upgrades that you consider adding an FF.CFG entry for drive-type = 80THD, 80T, 77T, 40T.

It would then be possible to double step 40T media when in an 80T drive but not to double step 40T media in a 40T drive. I think would solve many issues with older 5.25" drive emulation on vintage systems. I had looked further into the issue with RM kit and concluded that at present FF will only support 80T with 2SDQD media in IMG mode. The lack of double step recognition prevents it from working in any of RMs pseudo 40T media modes.

Peter

[z80micro-mc]

Kierf,

I have looked at the RM intelligent floppy controller. As far as I can ascertain it does the following:

1) uses different pins & timing for Index to identify 8" vs 5.25" drives. 2) Initialisation sequence is: If not 8" drive a) Seek home trk0 b) Stepin 6 tracks c) Stepout 5 tracks d) Check Sector address headers.

   e) Seek home trk 0
   f) attempt to Stepin 45 tracks
  g) attempt to Stepout 44 tracks, Check sector address header for trk 0.
  h) if Stepin 45 failed or read trk 0, it is a 40T drive.
  i) else its an 80T drive (we are on trk1).

Having established the drive characteristics it then goes on to establish the current media format characteristics.

If 8" or 40T is it fm or mfm on trk4? fm => SD mfm => DD else if 80T Check if address is correct on trk4 => 80T media else use double step and home trk0 then recheck trk4 if correct then pseudo 40T media then determine fm or mfm mode as previously.

Peter

[keirf]

If you use a 40-track HFE image with the double step flag in the HFE header, it will do want you want. For example, like these ones:

40t_double_step.zip

(These are double-density 40-track 5.25" disk images, and because byte at offset 21 = 0, require a double step from the host to move the virtual drive heads by one cylinder. One image is single-sided, the other is double-sided).

[keirf]

Having established the drive characteristics it then goes on to establish the current media format characteristics.

If 8" or 40T is it fm or mfm on trk4? fm => SD mfm => DD else if 80T Check if address is correct on trk4 => 80T media else use double step and home trk0 then recheck trk4 if correct then pseudo 40T media then determine fm or mfm mode as previously.

What does it do if the media is unformatted? Is there a way to skip this and say "I want to format FM or MFM"?

[keirf]

g) attempt to Stepout 44 tracks, Check sector address header for trk 0. h) if Stepin 45 failed or read trk 0, it is a 40T drive. i) else its an 80T drive (we are on trk1).

Unfortunately the FlashFloppy drive is always 256-cylinder (it has special cylinders 254 and 255 for "direct access" to the USB drive). Limiting the cylinder by FF.CFG or perhaps using special fields in HFE could work?

[z80micro-mc]

AFAIK if the media is unformatted it relies on failed CRC in either the header or the sector to set the media as unformatted. It then relies on whether or not the Stepin 45 fails (40T drive) or the Stepout 44 returns Trk0 signal (40T) else it assumes an 80T drive.

Once it knows 40T drive or 80T drive type the format utility can offer the user 40T SD, 40T DD on 40T drive or 80T DD, pseudo 40T DD, or pseudo 40T SD.

Stepping is single unless it is a pseudo 40T format.

Read_info function returns bits to determine: drive size followed by 48/96 tpi, and media properties 8" vs 5.25", 80T vs 40T drive, 80T v pseudo 40T media, fm vs mfm, formatted vs unformatted.

Limiting the cylinder by FF would be good, folowed by double step support for 40T media.

Peter

[z80micro-mc]

The unformatted detection seems to work ok for 2SQD (80T 2 heads). However, the lack of double step support / always detecting an 80T drive is causing the issues withother formats.

I'll take a look at the Hfe files later when I go out t the workshop.

Peter

[z80micro-mc]

BTW are there any restrictions on sector ids?

RM IDC will allow any sector number labelling in the format trk function which is used by some copy protection systems.

[keirf]

BTW are there any restrictions on sector ids?

RM IDC will allow any sector number labelling in the format trk function which is used by some copy protection systems.

If you use HFE, you are recording and playing back a raw bitstream. Sector framing, including IDs, sits logically above the bistream layer, so yes you can record what you like.

[keirf]

Any update?

[z80micro-mc]

Kier,

Any news on adding max_cylinder field to ff.cfg?

Ditto adding double_step parameter to img.cfg disk specifications?

From my investigations with Greaseweazle RM uses head=0 in sector headers on both side 0 and side 1 of floppy disks. This applies to 5.25" SD, DD, QD, PSD, PDD, PHD and to CP/M 3.5" disks (720k) for Nimbus PC.

MSDOS Nimbus disks have more usual head=0 side 0, and head=1 side1.

It may be necessary for 2S 5.25" disks to suppoort this for .img format. Any chance?

Hope you had a Merry Christmas

Peter

[z80micro-mc]

Kier,

RM 380ZD also has intelligent disk controller (IDC). This is a variant of the 480Z IDC with slightly different on board firmware.

As far as I am aware 380ZD IDC only supported 8" SD, DD; 5.25" 40T SD, DD. So does not exhibit the same issues with need for double step option in img.cfg under the disk parameters. But due to the lack of Double Step option in img.cfg 380ZD 1SDD FF .img files can not be used on a 480Z nor can 480Z 1SQD (80T, DD) be used on a 380ZD. This is not the case for physical media which can be freely transferred with the proviso that pseudo 40T media written on a 96 tpi drive should only be read on a 48 tpi drive and 40T media written on a 48 TPI drive should only ever be read on a 96 TPI drive. As normal with floppy media attempting to write 40T using both 48 and 96 tpi drives causes issues.

Theoretically there is a similar variant to 480Z IDC firmware supporting 80T 96 TPI drives, though as far as I am aware there are very few if any copies in the wild, it was proposed to produce a 96 tpi server at one point but this was in the main superceeded by Nimbus based server.

Peter

[keirf]

See here for a build artifact (from branch img-changes) which adds step= parameter to IMG.CFG. You would set this to step=2 for double stepping: https://github.com/keirf/flashfloppy/actions/runs/1634383021

You can already specify that sectors on side 1 have Head=0 in their headers. See the complex example in examples/Host/TSC_Flex/IMG.CFG: https://github.com/keirf/flashfloppy/blob/stable-v3/examples/Host/TSC_Flex/IMG.CFG

EDIT: max_cyl option is still TODO. If you have per-img step=, do you still need max_cyl?

[z80micro-mc]

Kier,

img.cfg step= option allows 96tpi drive emulation to support Psuedo 40T media.

ff.cfg max-cyl = would allow selection of 96 or 48 tpi drive emulation. without it IDC 3.1 firmware as fitted to most 480Zs would only emulate 96 tpi drives not 48. Most 380ZD IDCs should be fine as their IDC firmware does not look for 96 tpi drives only 40T 5.25" and 77T 8" drives.

So yes please I would still like a ff.cfg max-cyl option.

BTW which features is the test firmware missing as I see it would appear to be based upon a 2.x branch rather than a 3.29 branch?

Peter

[keirf]

It's definitely based on 3.29

[keirf]

Did you get a chance to try the step=2 feature?

[z80micro-mc]

Kier,

The lastest firmaware I can find is 3.29 which doesn't appear to suppor the step= command.

Please provide a link to firmware with the step= function in it and I'll give it another go.

Thanks

Peter

------ Original Message ------ From: "Keir Fraser" @.> To: "keirf/flashfloppy" @.> Cc: "z80micro-mc" @.>; "Author" @.> Sent: Sunday, 2 Jan, 22 At 17:17 Subject: Re: [keirf/flashfloppy] Research Machines 380Z/480Z disk support (#441)

Did you get a chance to try the step=2 feature? — Reply to this email directly, view it on GitHub https://github.com/keirf/flashfloppy/issues/441#issuecomment-1003747712 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64ET5UKXKA45EHOXENLUUCCBLANCNFSM4YR4VVBA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Message ID: @.***>

[z80micro-mc]

Kier,

Found it1

I hadn't realised that I needed to login to Github to get the step= version.

I'll give it a try.

Peter

------ Original Message ------ From: "Keir Fraser" @.> To: "keirf/flashfloppy" @.> Cc: "z80micro-mc" @.>; "Author" @.> Sent: Sunday, 2 Jan, 22 At 17:17 Subject: Re: [keirf/flashfloppy] Research Machines 380Z/480Z disk support (#441)

Did you get a chance to try the step=2 feature? — Reply to this email directly, view it on GitHub https://github.com/keirf/flashfloppy/issues/441#issuecomment-1003747712 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64ET5UKXKA45EHOXENLUUCCBLANCNFSM4YR4VVBA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Message ID: @.***>

[z80micro-mc]

Kier,

Just tried it - it gets as far as track 20 in the format utility then complains of seek error. Gotek is showing track 40.

Looks like it is double stepping through the .img file rather than single step .img file index and when FDC sends 2 pulses to the Gotek.

I will also try a Pseudo .img file with 2x number of blocks. But this is problematic as it will stop interchange of .img files between 380z (40T 48 tpi drive assumed) and 480z (either 40T 48 tpi drive or 80T 96 tpi drive but due to issue with always stepping beyond track 40 it always assumes 80T drive).

Peter

------ Original Message ------ From: "Keir Fraser" @.> To: "keirf/flashfloppy" @.> Cc: "z80micro-mc" @.>; "Author" @.> Sent: Sunday, 2 Jan, 22 At 17:17 Subject: Re: [keirf/flashfloppy] Research Machines 380Z/480Z disk support (#441)

Did you get a chance to try the step=2 feature? — Reply to this email directly, view it on GitHub https://github.com/keirf/flashfloppy/issues/441#issuecomment-1003747712 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64ET5UKXKA45EHOXENLUUCCBLANCNFSM4YR4VVBA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Message ID: @.***>

[keirf]

That was a bug, I needed to adjust 'nr_cyls' to account for the double stepping. Try this one: https://github.com/keirf/flashfloppy/actions/runs/1646810448

[z80micro-mc]

Kier,

When I try to select an image this version seems to just reset back to the firmware prompt.

This is on Simulant variant with STM32F105RBT6

Peter

------ Original Message ------ From: "Keir Fraser" @.> To: "keirf/flashfloppy" @.> Cc: "z80micro-mc" @.>; "Author" @.> Sent: Sunday, 2 Jan, 22 At 18:46 Subject: Re: [keirf/flashfloppy] Research Machines 380Z/480Z disk support (#441)

That was a bug, I needed to adjust 'nr_cyls' to account for the double stepping. Try this one: https://github.com/keirf/flashfloppy/actions/runs/1646810448 https://github.com/keirf/flashfloppy/actions/runs/1646810448 — Reply to this email directly, view it on GitHub https://github.com/keirf/flashfloppy/issues/441#issuecomment-1003758426 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64DCN5ZNUOZ23QB3QHLUUCMRXANCNFSM4YR4VVBA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Message ID: @.***>

[keirf]

That's a bit weird. I can probably try this build on a Gotek myself tomorrow, connected to a Greaseweazle.

[keirf]

I have just tested on a STM-based Gotek and it works for me. I included the following files (zipped) on my USB drive. I read part of the 720k image using gw read --format=ibm.720 --tracks=c=0-4 a.img, and part of the 360k image using gw read --format=ibm.720 --tracks=c=0-4:step=2 a.img. No problems, and no crashes. test.zip

So can you please try again, or report more precisely the problem.

[keirf]

Any time to try it again?

[z80micro-mc]

Kier,

Tried a few experiments using new USB stick = mixed results.

Please look at my files: RM-1S1D-74k.img, RM-1SDD-166k.img

attempting to select single sided images appears to work except in the case of quad density 80T, 96tpi (my file RM-1SQD-346k.img). There is an issue with attempts to select the 2nd head succeed rather than fail as offline and appear as if they were a copy of side0.

Attempting to select any of the 2x images (2 logical disks in 1 file) => crash and reset.

Please look at my files: RM-2x1S1D-74k.img, RM-2x1SDD-166k.img, and RM-2x1SQD-346k.img

Peter

------ Original Message ------ From: "Keir Fraser" @.> To: "keirf/flashfloppy" @.> Cc: "z80micro-mc" @.>; "Author" @.> Sent: Monday, 3 Jan, 22 At 20:52 Subject: Re: [keirf/flashfloppy] Research Machines 380Z/480Z disk support (#441)

Any time to try it again? — Reply to this email directly, view it on GitHub https://github.com/keirf/flashfloppy/issues/441#issuecomment-1004351184 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64DNKXFRX4XUX2CPL2TUUIEALANCNFSM4YR4VVBA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Message ID: @.***>

[z80micro-mc]

Kier,

Not fure if I attached the files to my last post.

Herewith

Peter

------ Original Message ------ From: "Keir Fraser" @.> To: "keirf/flashfloppy" @.> Cc: "z80micro-mc" @.>; "Author" @.> Sent: Monday, 3 Jan, 22 At 20:52 Subject: Re: [keirf/flashfloppy] Research Machines 380Z/480Z disk support (#441)

Any time to try it again? — Reply to this email directly, view it on GitHub https://github.com/keirf/flashfloppy/issues/441#issuecomment-1004351184 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64DNKXFRX4XUX2CPL2TUUIEALANCNFSM4YR4VVBA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Message ID: @.***>

[keirf]

GitHub strips attachments from emails I'm afraid. Please zip up the image files with your CFG files and use the GitHub website to attach the zip file here. Then I can try to reproduce what you describe. Also let me know the Gotek board type and MCU. Thanks!

[z80micro-mc]

ff.zip files as requested.

Peter

[z80micro-mc]

Kier,

Have attached ff.zip - the files to the issue. I tried to create a branch but github complained that I did not have 'push' attribute.

Hope you can download the files ok.

I am currently testing on a Simulant Gotek with STM32F105RBT6 as per my previous message.

Peter

------ Original Message ------ From: "Keir Fraser" @.> To: "keirf/flashfloppy" @.> Cc: "z80micro-mc" @.>; "Author" @.> Sent: Tuesday, 4 Jan, 22 At 06:23 Subject: Re: [keirf/flashfloppy] Research Machines 380Z/480Z disk support (#441)

GitHub strips attachments from emails I'm afraid. Please zip up the image files with your CFG files and use the GitHub website to attach the zip file here. Then I can try to reproduce what you describe. Also let me know the Gotek board type and MCU. Thanks! — Reply to this email directly, view it on GitHub https://github.com/keirf/flashfloppy/issues/441#issuecomment-1004556443 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ATCK64BII27ZOLV2HQPYBYTUUKG6LANCNFSM4YR4VVBA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub . You are receiving this because you authored the thread.Message ID: @.***>