Search results

What's the recommended way for changing the user code of a file? There isn't a BDOS API for it (which I can find), and as the user code isn't exposed in the user-visible FCB, the alternative approach of walking through the file extent by extent and updating the FCB won't work. I know it's...

...oh god, it uses <bsd/sgtty.h>...

Oops, yeah, I mean ProDOS. I'm not an Apple user --- can you tell? I'll check that out; thanks.

I want something that will emulate AppleDOS at the user program level --- that is, not the entire machine, but instead emulating the AppleDOS environment and its system calls. This is for running automated tests in a command line environment. For example, there are several tools for doing this...

It's all been pushed into the main release. Re filenames: the code is supposed to check for that. It's possible the version you have doesn't have that in it yet. Try again with the latest release? https://github.com/davidgiven/fluxengine/releases/tag/dev Also, that disk image with the deleted...

That's good news. Thanks for the flux image --- it's been added to my test suite. I'm not surprised the deleted file isn't been handled properly; if you have a hex editor, could you read an image and let me know the contents of the sector at 0x1d400? That's got the directory in it.

BTW: if your D20 is currently working, could you try writing a disk and seeing if it works? Also, I'd really like a flux file from a blank D20 disk formatted on the machine, to add to my test corpus and help prevent accidental regressions in the future. Thanks! Also, would you like a credit in...

Excellent! I'm encouraged to know how straightforward the recalibration was. The invalid filesystem error is because the track numbers do wrap round, but oddly. Luckily, the way that each file starts with its own filename means I can correlate directory entries with files. Disk #10's...

Mac floppy drives are special --- they can spin at variable speeds and there's extra pins for controlling this. I've never worked with one and have no idea what's involved in driving one. (Neither the Greaseweazle nor the FluxEngine need variable speed control to access these disks.) I have not...

Ah, I completely forgot you posted that! That looks very plausible for wiring up to something which is expecting an Apple II drive. You'd need to experiment as to how the phases map, but it should be doable. Unfortunately I don't actually have an Apple II drive or one of the adapters, so I can't...

Oh, an addendum, as it will probably show up: the file browser code currently ignores disk errors! I will need to fix that.

I have actually just added write support, so go ahead!. You can format disks and do basic file management. Assuming the build works, it'll be here: https://github.com/davidgiven/fluxengine/actions/runs/5685745221 To format a disk: fire up the GUI, select the drive and the rolandd20 profile...

BTW, re extensions: I think you're right. AMBIENT___222 and ANALOG_PAD333 have completely different structures, with the 222 file having a bigger file header with a lot of extra data in it. I'll need to think about how to map filenames. It's kind out of FluxEngine's scope to read the display...

The client doesn't change the dump format at all --- if you're using the GUI you can just load an existing .flux file and reread it with 'Read Disk' or 'Browse Disk'. Disk 1: about 50% bad sectors. Disk 2: almost (but not quite) clean. Disk 3: the first half is fine, the second garbage...

I have it working --- see screenshot. Some notes: I am not convinced the filename is right. There's clearly a machine-readable filename in the directory and a human-readable one in the file header, but I am unsure whether the 333 is part of the filename or represents something else. The maximum...

Those are much better dumps! I can actually make out some kind of filesystem on them. On track 39, i.e. half way up the disk, there's this: 0001D400 00 52 4F 4C 41 4E 44 2D 47 43 52 44 4F 53 4E 00 .ROLAND-GCRDOSN. 0001D410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00...

I don't have enough floppy drives to dare risk changing the alignment. As a not-very ept hobbiest I know that while I'm quite capable of misaligning a drive, putting the alignment back again afterwards is a lot harder... I have actually wrecked a difficult-to-source Amstrad NC200 drive by...

Yes, that would be me you shared it with! But here we're trying to figure out the Roland D20, about which very little is known --- if you know anything about this, that would be awesome... The story is that while doing the Brother work I found a blog article which mentioned the same FDC chip...

So, those Brother drives have poor alignment. The quarter-stepping feature is to allow them to adjust to match the alignment of the tracks on the disk. However, when you format a disk with them, they just start at a fixed offset from the beginning of the disk, and this doesn't always line up...

Damn, I was worried about that. Clearly the timing of the real thing isn't the same as the timing of the emulators I was using (MAME and AppleWin). Although, I'd expect problems to show up in writes rather than reads, given that reads are self-clocking from the data on the disk. See...