Home Page
Posted By: Al Kossow MAME support for writable media - 08/18/21 12:01 PM
This is the start of a discussion about how MAME should be dealing with writable media.

In the arcade game world, you had ROMs, and maybe a CD, and mostly static hard disks.

With the addition of computers with floppies and hard disks, you now have some set of base system software
and applications.

The IA has taken the approach of using MAME as "emulation as a service" with canned static containers
but this isn't really all that useful for someone who wants to emulate a Mac, Lisa or other computer with
a combination of system releases, applications, and the need to get things onto and off of a media storage
container and dealing with issues like the best way to snapshot and diff those containers.

There is also the problem of provenance of the software going into the softlists.
Posted By: exidyboy Re: MAME support for writable media - 08/18/21 10:43 PM
Originally Posted by Al Kossow
There is also the problem of provenance of the software going into the softlists.

To R.Belmont's advice in the shoutbox to just put a loose CP/M .COM file that (I happen to know) was distributed on cassette back on a "damn cassette":

Yes I can load the .COM file via the memory window of the debugger and save a "damn cassette" as a WAV consisting of a train of naive square waves.

This means making up some bytes in the Exidy Sorcerer tape header (ie the file type byte) that are not preserved when cassette software is converted to a .COM CP/M executable.

(There are also third party tools like tapetool2 that let you do this independent of real or emulated h/w).

But by inventing this intrinsic metadata you not accurately representing the bytestream of a real cassette that would have existed in the wild.

You are not fully respecting the artists intent.

When the programmer recorded their "golden master" in 1982 they made a conscious decision about what to set those values.

My concern over this is why I asked (in the shoutbox) in the first place.

Because Quickload doesn't store all the bytes in the tape header (in particular it doesn't encode the file type byte) it therefore:
- leaves no ambiguity in the archival record about what those values were.
- doesn't imply (as would a .WAV) that this is a truthful representation of all the bytes on a real cassette copy of the game.

Quickload is a way of saying (in band) that this is all we know about this game:

- bytes in the executable code path
- load address in memory (always 100H for a CP/M file on a Sorcerer)
- execute address in memory (always 100H for a CP/M file on a Sorcerer)
- filename (at least as it written to disk)

It therefore feels like a somewhat better fit for packaging up what are effectively almost loose binaries than a cassette.
Posted By: R. Belmont Re: MAME support for writable media - 08/18/21 11:07 PM
Put it on a cassette image, mark it BAD_DUMP in the software list, and you have fulfilled your obligation to history. At least the experience of loading it will be authentic then.

That said, if it was converted to a CP/M .COM file, the correct distribution method for the file as it stands would still be as a file on a CP/M formatted floppy.

Al's talking about something else entirely, as far as I can tell.
Posted By: mizapf Re: MAME support for writable media - 08/19/21 10:18 AM
Originally Posted by Al Kossow
This is the start of a discussion about how MAME should be dealing with writable media.

In the arcade game world, you had ROMs, and maybe a CD, and mostly static hard disks.

With the addition of computers with floppies and hard disks, you now have some set of base system software
and applications.

The IA has taken the approach of using MAME as "emulation as a service" with canned static containers
but this isn't really all that useful for someone who wants to emulate a Mac, Lisa or other computer with
a combination of system releases, applications, and the need to get things onto and off of a media storage
container and dealing with issues like the best way to snapshot and diff those containers.

There is also the problem of provenance of the software going into the softlists.

This sounds like a message from the past, from pre-MESS merger time (I had a look at the message timestamp). Computer systems depend on freely mutable media, which may be one of the most salient differences to arcade systems (some of which may need to save data on media as well, I am not too familiar with them).

Who/what is IA?
Posted By: Lord Nightmare Re: MAME support for writable media - 08/19/21 11:01 AM
IA is the internet archive i.e. archive.org
Posted By: exidyboy Re: MAME support for writable media - 08/19/21 10:11 PM
Originally Posted by R. Belmont
Put it on a cassette image, mark it BAD_DUMP in the software list, and you have fulfilled your obligation to history. At least the experience of loading it will be authentic then.

OK.

Originally Posted by R. Belmont
That said, if it was converted to a CP/M .COM file, the correct distribution method for the file as it stands would still be as a file on a CP/M formatted floppy.

Yes. However that presents similar question of selecting an arbitrary format where this is unknown. The situation has arisen because 22DISK was used to migrate the files to MS-DOS a decade ago. There are no sector images as would be created by ImageDisk or Teledisk, there are no CP/M system tracks (if indeed the disks were bootable) and the physical media is no longer available.

An educated guess could be made about which controller supported the original physical disks and synthetic images could be created using cpmtools against that format, but the resulting .DSK would not be a verbatim image of a disk that existed in the wild.

Such a synthetic disk image could also then presumably be marked BAD_DUMP as per your advice above.

Originally Posted by R. Belmont
Al's talking about something else entirely, as far as I can tell.

My reading is that our concerns intersect around more nuanced descriptions of file and media provenance.
Posted By: Al Kossow Re: MAME support for writable media - 08/20/21 03:23 AM
> My reading is that our concerns intersect around more nuanced descriptions of file and media provenance.

I'm concerned about the practical use case for people trying to use MAME as a tool, and the mishmash of known original distribution media that has provenance
with things someone grabbed off of the Macintosh Garden. And also adding support within a running emulation session for mass storage checkpoint-restart-rollback
that software like VMware has had forever.
Posted By: Darkstar Re: MAME support for writable media - 08/20/21 12:26 PM
(the content of this post was deleted to not come across as an "ungrateful whinger", apparently input from actual users is not appreciated at this time)
Posted By: Vas Crabb Re: MAME support for writable media - 08/20/21 02:17 PM
Look, you guys are getting way ahead of yourselves. MAME’s floppy format handlers pretend I/O errors don’t exist, and device_image_interface doesn’t make it convenient to do a defensive save to temporary/replace operation. If saving fails for whatever reason, the user gets a corrupt image and no recourse. The people doing the most talking in this thread so far strike me as the kind of people who just want to whine and hope someone else implements a perfect solution for them. Meanwhile, I’ve had no sleep at all five nights out of the previous twelve just getting a pull request ready that gets MAME to a point where it’s possible to propagate error conditions across the layers. Talk all you want, but the more you talk, the more clear you make it that you’re a bunch of ungrateful whingers who want someone else to do all the hard work for you.
Posted By: Al Kossow Re: MAME support for writable media - 08/20/21 03:00 PM
"you’re a bunch of ungrateful whingers"

I am trying to point out that no one cares about the computer simulations in MAME with either floppies or
hard disks because the UX isn't useful. This needs to be thought through if MAMEDEVs are serious about
supporting a platform and I created this thread because the only place this comes up is in the transient
shoutbox.

You're right, I don't submit pull requests, in fact, I don't use MAME at all, because it isn't useful to me as a tool.
I supply docs and software, do full builds, and try the platforms I'm interested in to see if it is ready for prime time.

They aren't.

"do it yourself" just points out that JD is right about MAMEDEVs not caring about users, or the user experience.
Posted By: R. Belmont Re: MAME support for writable media - 08/20/21 03:10 PM
The point Vas was making is that we're not yet to the level where you can start adding the glitzy enterprise features that VMWare has. Copy-on-write and that sort of thing will be important in the future, but today is not that future.
Posted By: Vas Crabb Re: MAME support for writable media - 08/20/21 03:21 PM
Originally Posted by Al Kossow
"do it yourself" just points out that JD is right about MAMEDEVs not caring about users, or the user experience.
Oh fuck off. I’ve probably done more to improve the development and user experience for MAME than anyone else in the last five years. The only “thanks” I ever get from you are whinging e-mails when you can’t build with a horribly outdated toolchain.

The trouble is, you’re getting way ahead of yourself. You’re saying we need branching snapshots when MAME can’t even gracefully deal with a floppy serialisation error. I know there’s a lot of stuff MAME needs to do better. I’ve sunk a huge amount of time into building the infrastructure to actually make that possible. MAME is so big and unwieldy that any significant architectural change is a shitload of work. It inevitably results in a pile of whining from people who don’t like change and can’t look past that to see the long-term benefits. The best outcome you can get is that nothing breaks. No-one wants to do it because it’s a thankless task, and you don’t get your name in lights as the genius who emulated whatever. Hence no-one actually wants to do it, and it inevitably falls to me.

But thanks for further confirming that you’re an ungrateful whinger.
Posted By: Al Kossow Re: MAME support for writable media - 08/20/21 03:24 PM
Don't break your arm patting yourself on the back.

Hopefully this thread will stick around to demonstrate yet again what an ass you are.

I expect to have a deliberately placed chunk of code added now to break my build, again.
Posted By: Vas Crabb Re: MAME support for writable media - 08/20/21 03:46 PM
Originally Posted by Al Kossow
I expect to have a deliberately placed chunk of code added now to break my build, again.
See, I can’t win. On one side I’ve got Olivier telling me I’m not migrating MAME to pre-standard C++20 fast enough, and on the other hand I’ve got you complaining that you can’t build MAME if you refuse to update to a toolchain that isn’t over three years old. I try to strike the middle ground, and everyone’s angry at me. I’m not intentionally breaking your build, I’m making the most of more expressive language features to make life easier for contributors. It shows in the increased number of contributors, increased quality of submissions, and the almost complete absence of whole classes of issues that used to plague MAME development. Remember the dreaded late bind errors, and devices not being found? They were a huge waste of contributors’ time before C++ machine configuration, but they’ve all but disappeared now. Do you remember the pages of MCFG_ macros that you needed to write along with a device class? They’ve been completely eliminated – stuff just works without a pile of unnecessary work.

What do you have to contribute here besides a wishlist? Anyone can wish, anyone can say a feature would be nice to have, anyone say things need to be better. You haven’t said anything in this thread that we don’t already know. What are you actually going to do to move things forward?
Posted By: Bletch Re: MAME support for writable media - 08/20/21 03:58 PM
Originally Posted by Al Kossow
I am trying to point out that no one cares about the computer simulations in MAME with either floppies or
hard disks because the UX isn't useful.

BletchMAME sheepishly raises its hand... ;-)
Posted By: R. Belmont Re: MAME support for writable media - 08/20/21 04:43 PM
Originally Posted by Bletch
Originally Posted by Al Kossow
I am trying to point out that no one cares about the computer simulations in MAME with either floppies or
hard disks because the UX isn't useful.

BletchMAME sheepishly raises its hand... ;-)

Ample's pretty good too, for the limited subset it addresses (emulating Apple II and 68K Mac on modern macOS).

Al's real grumpiness is because he won't update his Mac, and Apple made some unusual design decisions that mean the compiler version and OS version are tied a lot tighter than on Windows or Linux or *BSD.
Posted By: Happy Re: MAME support for writable media - 08/20/21 05:19 PM
So, what kind of discussion should take place?

Here are some possibilities . . .

1. Does MAME have any sort of policy for how mutable media changes are created or stored?
2. Should MAME provide any additional features to assist users in managing their own media files?
3. Should MAME provide any support for creating media images for a particular system outside of emulation?

Also adding, that for preservation purposes, the original (as distributed) media images (and representation of media) should be preferred for cataloging and archiving.
Posted By: R. Belmont Re: MAME support for writable media - 08/20/21 05:22 PM
MAME does not handle media low-level well enough to discuss higher-level features (yet). And we understand that original media, where it can be represented in digital form, is preferred. That's Firehawke's entire life right now with the Apple II software lists.
Posted By: Olivier Galibert Re: MAME support for writable media - 08/20/21 06:19 PM
Let's talk UX then. What's missing, what should be done differently?

What I *hope* to add is the capability to edit images which have filesystems (floppy, HD, CD) and create new ones interactively. In the oric case, it could be "start with a jasmin connected but no floppy, create a new floppy image, check bootable and start program z, add zorgon.bas as z.bas, mount it, press F1" and it boots on zorgon's revenge. There are three infrastructure things missing for that, but it's on the way.

What else could we have? I'm listening to suggestions, but they should be generic enough that they make sense in Mame.
Posted By: Happy Re: MAME support for writable media - 08/20/21 07:45 PM
UX, I would imagine would look like an FTP client interface. Possibly a file browser for the host system and a file browser for the emulated media. Either drag and drop or have a dedicated UI element to initiate transfers. However, I would imagine this would require something like a POSIX level uniformity of file access for each emulated file system.
Posted By: Olivier Galibert Re: MAME support for writable media - 08/20/21 07:54 PM
You don't need posix level if you only read or write whole files. And in practice we already have the interface and implementation for a couple of filesystems. Some stuff could be added still, like defrag, but there's enough to try a first UI anyway.
Posted By: Lord Nightmare Re: MAME support for writable media - 08/20/21 11:44 PM
could we get .dlt delta files holding a delta vs an actual floppy image? that way an original image isn't modified at all on disk, but the delta is applied to it on load if it exists in the same(?) directory as the image.
Posted By: R. Belmont Re: MAME support for writable media - 08/21/21 12:56 AM
We have diff files like that for CHDs. They work great for fixed-original-image (arcade games and software lists), and are a bit of a nightmare for everything else.
Posted By: Olivier Galibert Re: MAME support for writable media - 08/21/21 08:00 AM
Delta files are not really interesting for floppy images because they're too small for the delta to matter. Delta-like behaviour can be interesting (and is halfway-implemented, sorry), where mame "magically" remember the changes done to an image that is not actually changed, especially if it's in a zip.
Posted By: mizapf Re: MAME support for writable media - 08/21/21 07:54 PM
Anything that can be turned on and off as desired is good for me.
Originally Posted by exidyboy
An educated guess could be made about which controller supported the original physical disks and synthetic images could be created using cpmtools against that format, but the resulting .DSK would not be a verbatim image of a disk that existed in the wild.

Such a synthetic disk image could also then presumably be marked BAD_DUMP as per your advice above.

With diskettes there definitely needs to be a 3rd marking to distinguish "bad" from "inaccurate" dumps, because areas outside the actual files often only matter for copy protected disks or bootblock position, so the indication should make it clear if the disk image does function or not.

With downloaded content or type-in listings from magazines the binary structure does not matter anyway, so there is no "master copy" to reproduce. Other diskettes often have bad blocks outside the actual files.

My main PC is a severely modded Highscreen Colani bigtower (DFI K6BV3+/66 mainboard with AMD K6-3+@550MHz, 768MB RAM, 2 genuine ISA soundcards, DVD writer, 160GB HDD, running Win98SE) which has a 1.44MB 3.5`` and 1.2MB 5.25`` diskette drive. Nowadays I have installed at its ceiling an additional modern ITX mainboard (Ryzen 2400G, 16GB RAM, 8TB HDD, DVD writer) for Linux Mint and Win10, so I first time have enough disk space to dump some 100 of my CDR (containing e.g. tons of downloaded ancient web pages about tech stuff etc.).

I am working through some hundred of my PC diskettes to preserve their contents. Some indeed were unreadable; particularly one brandless 1.44MB sort (black with white "HD" logo and too small paper sticker with cyan lines) tends to fail, and also 5.25`` things written with 360KB drives (ancient 286 and CPM machine at school) are partially unreadable. Often I have to carefully clean the surface with cotton swab and isopropanol (let it fully evaporate, else the surface is softened and gets scratched) and insert cleaning diskette with a drop of isopropanol between read attempts. Also rhythmically pressing the thumb on the front of the diskette can help to read bad blocks on warped disks. I had taken apart the external 3.5`` diskette drive of my IBM Thinkpad 760XD to rotate the head motor into different positions, which helped to recover a few more files.

(In former times my first PC was a 286 and later 386SX bridgeboard inside my very modified Amiga workstation (A500 in huge wooden case with handsoldered adapters, internal A570 CD drive, SCSI card for Iomega 20MB sort-of diskette drive etc.). At hat time I had often manually adjusted diskette heads because school diskette drives all seemed to be misaligned or dirty and so wrote incompatible diskettes, which e.g. made it hard to use downloaded files (through DOS ftp at school, had no internet at home). Thus many of my diskettes seem even worse misadjusted than original payware or shareware ones.)

For reading, I yet have only DOS mode of Win98SE for file copy (unlike windoze it allows infinite retries), a primitive track reading program disktool.exe and procopy.exe to mage binary images and check which blocks are unreadable. Bad with these tools is that they tend to replace unreadable tracks with random copies of previous tracks (likely garbage from a ring buffer), which makes them hard to identify in a hex editor (e.g. to merge multiple bad dumps).

I e.g. still have some unreadable 360K 5.25 CPM/86 disks from my practical course, those were likely written on a Siemens PG675(?) industrial computer (resembling an Osborne PC with internal green CRT), which was used to program Simatic PLC hardware.

https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=106592

[Linked Image from i.imgur.com]

https://forum.classic-computing.de/forum/index.php?thread/15021-siemens-pg675/
https://en.wikipedia.org/wiki/Simatic
https://de.wikipedia.org/wiki/Simatic

The crazy thing is that there were some games on this computer. E.g. there was a textmode clone of "Qix", of "Centipede", of "Nibbler" and of "Ork Attack" (?, you had to move left & right to defend a castle by dropping stones on enemies those built ladders to climb up a brick wall); the latter even used a redefined charset but AFAIK none of them had sound. And I think I had copied them on my floppy.

My dump with disktool shows in HxD fragments of recognizeable words (e.g. file names) but likely nothing complete. At secondary school we also had on Commodore 286ers a CNC turning lathe and milling machine simulator (terrible DOS program that crashed with "division by zero" when moving the tool out of range), of which I still have diskettes with the code I wrote. But the disk with compiled code (for an actual Heidenhain milling machine?) is unreadable like when the disk wobbles eccentric and so only reads half of each track. But I guess it is the different head geometry that makes the Mitsumi 1.2MB drive of my Colani bigtower fail to read it.

Reading strange 5.25 floppies?

Is there a program to read 360K (or lower?) DOS or CPM floppies in an Atari XL or Commodore C64 floppy drive, to convert it into a PC readable format? Eons ago I used a DOS serial port adapter (SIO2PC) to communicate with Atari 800XL and C64 to read and write their disks. Else I likely need a 360k PC drive. In a box of old parts I somewhere had a belt-driven double-height 5.25 drive full of DIL ICs (found in fleamarket scrap in 1990th) but I doubt that it works and have no clue what connector it uses and if it ever could be connected with PC hardware. It may have been gutted out of an Apple II or such.
360K PC disks are double-sided, which Atari and Commodore drives are not.
The Commodore 1571 disk drive is technically able to read double-sided DOS or CP/M floppies (at least from what I've read, I still don't have one myself), but there is no dumping software for the C64/C128 that I know of.

Also, you might probably have better results if you dump the floppies with one of the sophisticated dumping devices like a KryoFlux, FluxEngine, SCP or similar. I have dumped dozens, if not hundreds of old 360K disks and have not come across one that at least one of my two 5.25 HD drives could read. I'm having more trouble with old 3.5'' HD floppies to be honest...
But with 360k 5.25 diskettes AFAIK a 1.2MB drive is often incompatible due to different magnetic field geometry. It may even be that I have a Commodore 1571 somewhere in my parent`s house (in another city). Kryoflux seems quite expensive. But I am still daily using my Amiga and own a lot of other homecomputer diskettes, so something like Kryoflux might be useful, if it can convert the resulting image file. (AFAIK its native format is a kind of 50MB WAV file sampled of each track that can be only written back to diskettes but not used in emulators.)
1.2MB drives can work in DD or HD mode – it’s software selectable. The disk will be ruined and need degaussing if you try to format it in the wrong mode, but the drives support both.
Nonsense. I reformatted diskettes all the time without problem into other modes. On Amiga there is only DD mode (880KB) but since 1990th diskettes could be solely bought HD formatted for MSDOS. However my drives inside the Amiga are PC drives anyway (need the diskette hole closed with adhesive film) so they likely can handle both.

On C64 I also needed to reformat any bought diskettes (coming preformatted always as 1.2MB MSDOS), which worked ok. But it may be that 360K diskettes formatted in a 1.2MB drive in 360K mode will only work in that drive and no actual 360K drive. And of course C64 needs the diskette punch to make a 2nd write hole to use both sides.

The only trouble was that some diskettes needed to be formatted twice if I remember well.

To physically adjust drive heads on the Amiga (which at that time had a PC bridgeboard with DOS compatible mode) I had modded a cheap old walkman with 3 tiny alligator clips connected to the foil cable of the head, so I could hear in the stereo headphone that both heads simultaneously reach the same track and sound bright when manually moving the worm shaft of the head motor. Do not use raw force. Be careful not to use raw force; in a Citizen 1.44MB drive I finally broke the top head screws and so could reattach it only with superglue in a fixed position, but that drive still worked. Messing with head screws also tends to scratch the diskette surface, so avoid to do that on disks with valuable data. Always first try to only rotate the head motor (loosen its screws) to tweak the read position, which is much safer. You also may manually slightly rotate the worm shaft by fingers during read if a track of a disk is unreadable.

Does the Kryoflux device only connect to the drive connector or to the head cable itself? If it samples the head signal, it would make much more sense to bypass the internal head amp (which rectifies the waveform into 1 or 0 level) to use more sophisticated software analysis to reconstruct dull or scratched recordings. (I doubt that signal processing inside a diskette drive is sophisticated enough for this. Likely there is only some primitive AGC but nothing that understands strange waveforms with non-standard level.)
What’s the point of even posting if you’re going to ignore answers and post nonsense?
I do not ignore answers but it's you who is posting nonsense. Technically any preformatted diskette needed to be reformatted to a "wrong mode" for use on Amiga (bought as 1.44MB PC HD formatted, than reformatted into DD mode). If they would get "ruined" by that, Amiga would have become unusable because DD or unformatted diskettes were not manufactured anymore since at least mid of 1990th. Only HD formatted disks were regularly sold until about 2005.

But it may be that with 5.25 a native 40 track drive (i.e. 360K or lower) gets confused with 80 track preformatted (i.e. 1.2MB) disks because the wider head of the 40 track drive so will read a mixture of 2 adjacent tracks of that only 1 contains valid data. So it is the number of tracks and not density that may mess it up. AFAIK diskette drives have no separate erase head but erase the track during write (by modulation of the signal?), thus a wider head should still be capable to reformat the narrower tracks (2 at a time) when reformatting a 1.2MB preformatted disk. I remember that with C64 there were some incompatible combinations.
Some PC 1.44MB HD disks would work on an Amiga if formatted as DD (often not very well though) while others wouldn't work at all. I don't know the technical reasoning behind that.
As far as I know, DD and HD disks have different magnetic coating, so if you use a HD disk as a DD disk, the applied magnetic field may not be enough to accurately write the data.
3.5" DD vs HD is not the same as 5.25" DD vs HD. 3.5" DD coating has coercivity of 660 Oersteds, vs 720 Oersteds for 3.5" HD – the coercivity of a 3.5" HD disck coating is only 9% different from what a DD drive expects. The biggest difference is that the thickness of the coating is about 1.9µm for 3.5" DD vs 0.9µm for 3.5" HD, and 3.5" HD has lower ratio of magnetic particles to binder in the coating. The thinner coating and lower loading of magnetic particles gives more defined magnetic zones, the trade-off being that the read signal is considerably weaker.

Required write current is a function of coercivity, not thickness – it needs to be able to saturate the medium. The write current of a 3.5" drive in DD mode usually be enough to write a 3.5" HD disk. However, due to the lower thickness and magnetic particle loading of the coating, the signal will often be too weak for it to read. However, you may get lucky with a 3.5" disk with high enough magnetic particle loading and a drive with a sensitive enough amplifier.

However, 5.25" disks have a far bigger difference in coercivity between HD disks and regular disks. A regular 5.25" disk has an iron oxide coating with a coercivity of 300 Oersteds, while a high-density (1.2MB) 5.25" disk has a cobalt coating with a coercivity of 600 Oersteds. The write current in a regular 5.25" drive simply won’t be enough to saturate the coating on HD media. If you write to a degaussed 5.25" HD disk in a regular drive, you may be able to read back a weak signal with a modified drive, but it won’t reliably read in a regular drive. If you try to reformat a formatted 5.15" HD disk as standard or double density, it won’t work at all.

You clearly have no clue what you’re talking about.
Originally Posted by =CO=Windler
I do not ignore answers but it's you who is posting nonsense. Technically any preformatted diskette needed to be reformatted to a "wrong mode" for use on Amiga (bought as 1.44MB PC HD formatted, than reformatted into DD mode). If they would get "ruined" by that, Amiga would have become unusable because DD or unformatted diskettes were not manufactured anymore since at least mid of 1990th.

That's not quite right, you could easily buy 3.5" DD disks either retail or mail-order until 1994/1995. I never had to use HD disks in my Apple's DD drives.

And you can still buy new-old-stock 3.5" DD disks today from floppydisk.com.
Posted By: =CO=Windler Re: MAME support for writable media - 08/27/21 03:40 AM
I remember that some cassette decks had a "metal" setting and that was claimed that the expensive "metal" tapes could not be recorded in cassette decks without that. (My Telefunken TC650 only has Fe,Cr and FeCr.) Manufacturers of VHS recorders also spreaded the urban legend that standard VHS tapes would be incapable to record the higher resolution of SVHS, but after disabling the contact finger (that detected a marking hole to distinguish both cassette types) revealed that it was fakenews to sell SVHS tapes much more expensive to pay additional luxury, they finally marketed a new generation of SVHS recorders those could use normal tapes for "enhanced picture technology" (or what ever they called it) by claiming that they now featured a revolutionary new tape measurement computer to make this miracle possible (which was disproved because the AGC circuit of previous SVHS recorders could do the same).

https://www.hometheaterforum.com/community/threads/is-svhs-et-overrated.82515/

That is to say, my Panasonic NV-HD625 with cast aluminium drive had almost SVHS resolution (only lacking the "required" svideo connector) despite it was only a VHS model. Later recorders with wobbly sheetmetal drives (those deformed by the varying tape tension between start and end of the cassette) made much worse picture (typically disguised by digital dishancers) and their cheap mech wore out rapidly when winding short tape sections a dozen times per day.

I clearly remember that in "Happy Computer" magazine they told that the 5.25 diskette incompatibility was because a 40 track diskette written in a 80 track drive will have half track width due to narrower head, so the intermediate tracks of a 1.2MB diskette stay in their preformatted state (empty DOS track). Thus when read in a genuine 40 track (360K or lower) drive, the broader head will read a mix of 2 adjacent tracks (the data and the untouched preformatted track) and so fail to handle them. When formatting a preformatted 1.2K disk in a 40 track drive, half of the intermediate tracks stay out of reach of the broader head (which is still a little too narrow to fully overwrite 2 tracks of the 80 track disk) and so mixing with residues of the preformatted tracks remains, causing them to fail or behave flaky. If a 40 track 5.25 drive really can not magnetize 1.2MB diskettes, this would be easily testable if unformatted ones exist. I have a tape head degausser (looks like a small black soldering iron with red painted soft iron tip, containing a solenoid coil with mains cord) but never came in mind to erase a diskette with it. (Naturally I keep this out of reach of any magnetic disks and tapes; there were warnings that it even may destroy colour CRTs because it may permanently bent the shadow mask or melt the aperture grill wires by induction, or erase the static convergence magnets.)

My Amiga was modded to use 1.44MB PC drives because of my Commodore 2386SX bridgeboard (hardware PC "emulator" with 1.44MB mode) and the original DD drive later found its place in my homemade external disk drive for Atari 260ST. Nowadays the bridgeboard is long time gone (it finally broke, and anyway caused fuzzy picture by overloading the unbuffered bus of Amiga 500) but the drives are still PC models. Their only disadvantage is that in 1.44 diskettes the HD marking hole needs to be shut with adhesive film to make the drive handle DD mode properly. This may be fixed by permanently disabling the HD hole switch, but I didn't do that in expectation that somewhen real HD compatible hardware may get installed again. (The Amiga floppy controller is too slow to handle HD data rates, thus original Amiga HD drives rotated at half speed (having 2 position magnets at the motor turntable) when HD disks inserted. But they were uncommon and not used to distribute payware disks anyway.)

I still have a briefcase full of a few hundred used 1.44MB diskettes where once my MAME roms (downloaded at the university) were stored on before there were proper CDR drives. Occasionally I reformat some when I need a disk, but diskettes those went through those public drives (initially only one per computer room) often became unreliable (likely by the foreign dirt in that drive).
© Forums