Aley Keprt wrote: > I really don't understand you. <snip> Heh, well the feeling's mutual! }:->
> So you admit there're no pubilc utils, and you even not finised > SDF yet. So why you say we don't need any other format (SAD)? The new SimCoupe itself hasn't even been officially released, so it only really needs to be finalised before that version goes out. I think SDF as a format should be able to describe anything that's needed, but I want to make it a little more extensible first. > I hope all existing "floating around" images will be supported > (or converted by some util). Of course - it flags any old-style (and writable) images as modified so they get written back out to disk in the new format when they're closed. The updated version still has the same core disk format (so it's not drastically different), but has a header and allows other tagged sections. > You admit there're no pubilc utils, and you even not finised SDF > yet. So why you say we don't need any other format (SAD)? I was only thinking of the future... DSK remains the original format and is fine for the vast majority of images, so it'll live on I expect. SAD does offer more, but it still falls short of what's needed by some things, which seems a shame for a new format that could have been more comprehensive. SimCoupe remains the only real emulator for the SAM, and as long as it supports reading and writing of the various image formats then I suppose there isn't a problem what people use (well, once the various ports catch up to gain the functionality). In that case I suppose we're arguing over nothing - I'll continue creating and using SDF images, and you can stick with SAD, or whatever. :-) > You write that you have your SDF-make util for Sam. But can other > people use it? I can't. I do have a BASIC program and some Z80 that does most of the work, but it needs a UI and some more (maybe SimCoupe) work on the PC side to create the image from what the SAM side has extracted. I offered to give this to anyone who wanted to do something with it but had no takers. As I mentioned before, the only time you really need to use the util on the SAM is for copy protected stuff, as regular format disks can be accessed directly by SimCoupe under NT4/W2K (with Win9x and Linux needing doing). Instead of running SBK/SMD to generate the image, you can just create a new image in SimCoupe drive 2 and do a normal disk copy between drives 1 and 2 like you would do copy a disk on the real SAM. Being able to do that, and being able to write files directly to real disks has meant the image utils aren't really as important anymore. > Instead of simply clicking on the file, I must right-click and select > the operation "open with zx spectrum emulator" in the menu. I hope > you understand that I can't set this as a default action, since I > much often work with ZIPs normally than opening them with an emulator. Yeah, I understand the problem, tho that'll be a problem for any program that can handle common format like zip files. The only way around that I can think of is to re-register zip (etc,) to SimCoupe, and have it store the previous association for chaining on. If the CDisk::Open rejects the zip because it doesn't contain a recognised image, it'll run the next association. That'll work ok, but things'll get into a mess if archiver apps like WinZip spot they're no longer the default association and clobber the SimCoupe settings, etc. SimCoupe does support drag and drop on the main window as quick way of inserting files into drive 1, tho it doesn't use the autoboot setting on them (maybe it should). > If you say you did SDF to handle all diskettes, so I want a converter > for it. I can forsee the SAM version being done, but the PC version (probably what you'd want most) is still a real unknown. I've never tried accessing unusual formats with the PC controller, though the standard drivers for most OSes don't make it easy to test out. > Any converter of regulatr diskettes to SDF is a shit, since we > have DSK and SAD already, so you haven't need to develop SDF. Converting regular disks to SDF does take more space, but it means you can forget about what type of image it is and use it as you would a real disk. If you want to reformat it to 83 tracks then fine; if you want to reformat it to a strange game format then that's also fine. I've added the disk formatting support to the disks now, so it'll let you use the regular FORMAT command, and should also support programs that can create other formats. There's limited support for DSK and SAD images, so it'll only let you format images to the same format, naturally. It still gives a convenient way of erasing the data in each sector for those formats. > I don't understand you. On one side you trully say SDF is better, it can > handle all diskettes. On other size you say: "Let's use it only > for regular diskettes." Well, personally I've tended to use SDF for copy protected stuff and some general purpose images, but that's only because I've not finished changing it and don't want more than 2 versions of the images on my disk. SDF images are still bigger than DSK images, so for stuff that I won't change (like the Fred disks) I leave them as DSK images (inside the zip files too). > Aren't regular diskettes the ones which can be read directly to emulator? Yes, sorta. With a SAMDISK.SYS in the main directory on Windows 2000 (and running as an Administrator user) it'll install and use that for direct disk access if you want it to. The same driver can be recompiled for Windows NT4 by taking out the WDM functions the Windows 2000 driver needs for power management - it's a shame it's not possible to have a single binary that works for both. I did some work on the Win9x class but found it was a lot slower than the NT4/W2K version, and I had problems with disk change detection or something like that (can't really remember). The way floppy access has to be done on Win9x is a disgusting hack anyway, and I can't imagine it being anything but trouble! Since I've moved to using Windows 2000 at home I've not touched it, so it's sitting in fragments waiting for someone to sort it out. For a Linux port it just needs a new derived class to implement the necessary functions to do it, and since the kernel supports what's needed anyway it should be trivial. > (I'd like to know what version of emulator do I need to try this, > since I'm affraid my PC BIOS is not able to handle 10 sectors per track DD > diskettes. Neither way.) If you're using Win9x it won't work, but if you're using NT4/W2K you can probably just drop an appropriate SAMDISK.SYS into the directory to get it working. Maybe it's a BIOS problem for Win9x, but I seemed to think the NT4/W2K versions just talk directly to the floppy controller, so it may not be a problem under that. If you use Windows 2000 I'd be interested in seeing whether my SAMDISK.SYS has any success reading them. How do you transfer stuff over from the SAM now? (or don't you?) > @ is switched with " Shift-2 on my UK keyboard gives ", but if I switch to the US keyboard layout I get '@'. I'll have to get a friend in the US to check it when he gets into work (sometime soonish). What input language and keyboard layout have you got set up? > That's probably all. > I may have an old version. But I haven't seen an official > announcement of a new version on sam-users for years. True... as usual the 'tying up loose ends' has dragged on. I've been busy sorting things out to move house in the last couple of weeks so I've done very little on it. :-/ > Yes, this is how Microsoft works. Enhancements. Enhancements. > Don't look to people. Just enhance. I think of 'enhancement' in this context as any expansion of the functionality of the program - why's that a bad thing? Anyway, I do look to people, and have added _many_ things on request! Personally, I had a goal of it being able to do certain things in a certain way, so I've been aiming for that since I started (and I'm getting a lot closer to completing those aims). One of the reasons I've not been as public with it along the way is that I've wanted to reach that goal first. Another reason is that so much was being changed in the way it was structured that it'd be a nightmare for people to try and make enhancements to such a volatile code-base. Things have settled down a lot and that tends not to happen so much. By deriving a new GPL project from the existing one, strictly don't I get to decide what I want to do with it anyway? (as long as I stick to GPL) I'm probably still a little overprotective of it, but it's been open for modification/enhancement by other people for the last few months at least. > Actually, you started this one. Even if I did, you're one heck of an catalyst... always willing to 'help out' in any 'discussion' on the list! Si
