Re: Grabbing floppy images
Simon Owen schrieb: Leszek Chmielewski wrote: You coded the fdrawcmd.sys? It should work with onboard floppy connector under Win2K. Yes, and yes :-) I changed the code from example HANDLE h = CreateFile(.\\fdraw0, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL) to PureBasic syntax: Handle.l=CreateFile_(.\\fdraw0,#GENERIC_READ|#GENERIC_WRITE,0,#Null,#OPEN_EXISTING,0,#Null) but Handle returns always -1. I guess, that's not correct. The actual path being opened is \\.\fdraw0, but the backslash characters need to be escaped in C by adding additional backslashes before each. Try changing .\\fdraw0 to \\.\fdraw0 and see if that works. If it doesn't, check GetLastError() to see what it returns. If you're still having trouble, e-mail me off the list and I'll look into it. Thanks, it now seems to work, the handle is now every time 892. I never used C before, so I did not knew that trick :-[ . Btw.: you wrote, RealSpectrum Emulator use Fdrawcmd to read discs. I tried to read +D discs under Win2K, but Sector 10 is bad on every disc (Directory sector 10 is corrupted), SimCoupe reads all directory entries correctly. I guess RealSpectrum use a older version of Fdrawcmd, because it works fine only under Windows 98SE or older. The newer RS32 has no ability to read real discs. maybe it could be easier to use a standard SAM Disc, and create a dummy file, which has a Sector bitmap that reserves all sectors nr 10 on the whole disc. That's pretty much what I had in mind, but with additional dummy entries to reserve sector 10 on the directory tracks. 2 hidden entries can be added to each, to prevent the listing stopping so the remaining entries will be searched. I though, you want to modify SimCoupe to format and write discs with 9 sectors, that means, need to change the ROM, File Bitmap layout, etc. When the image is used in the emulator, saving will not use sector 10 in the directory since it has hidden files in it. The dummy file prevents sector 10 being used across the rest of the disk. Thats what I mean too. To write to a USB floppy drive would just need the 10th sector to be dropped, and the remaining 720K written to the raw device. When opening the USB drive in SimCoupe, the emulator will need to provide suitable dummy details for every sector 10. So you automaticaly can recognise USB Drives, I guess. I never used USB drives and have no Apple here, but Mac users have no other chance to connect a floppy drive, if they got no internal floppy connector. A Image of 256 Bytes of the last directory entry, which is precalculated and could be written on any disc, reserving sectors that are not accessable from PC. Any files saved after that on this disc, would be avoid writing these sectors, so no need to change SimCoupe. If there are more than 17 files on the disk, getting a directory listing would attempt to read track 0 sector 10. A SimCoupe change is still needed to return something for that read attempt. It would also be wise to block attempts to write to sector 10, since it can't be saved. Oh, I forgot about writting dummy sectors to directory sectors 10. So 8+1 Entrys needed, so this will reduce the number of saveable files to 71. But for data transfer needs it does not matter very much. The dummy entrys did not need to have a bitmap. Si Cheers! LCD
Re: Grabbing floppy images
There are some USB to SCSI adaptors, which OS X fully supports, and SCSI floppy drives, but overwhelmingly they are of the LS-120 type, i.e. 100+mb 3.5 drives that are backwards compatible with old floppies. So probably they'd have PC geometry hard coded at a different place. What sort of floppy format were Apple using in 1997? Would obtaining one of the very original USB floppy drives that were intended for people moving to the iMac be of any advantage? On 22 Jun 2008, at 11:38, Leszek Chmielewski wrote: Simon Owen schrieb: Leszek Chmielewski wrote: You coded the fdrawcmd.sys? It should work with onboard floppy connector under Win2K. Yes, and yes :-) I changed the code from example HANDLE h = CreateFile(.\ \fdraw0, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL) to PureBasic syntax: Handle.l=CreateFile_(.\ \fdraw0,#GENERIC_READ|#GENERIC_WRITE,0,#Null,#OPEN_EXISTING, 0,#Null) but Handle returns always -1. I guess, that's not correct. The actual path being opened is \\.\fdraw0, but the backslash characters need to be escaped in C by adding additional backslashes before each. Try changing .\\fdraw0 to \\.\fdraw0 and see if that works. If it doesn't, check GetLastError() to see what it returns. If you're still having trouble, e-mail me off the list and I'll look into it. Thanks, it now seems to work, the handle is now every time 892. I never used C before, so I did not knew that trick :-[ . Btw.: you wrote, RealSpectrum Emulator use Fdrawcmd to read discs. I tried to read +D discs under Win2K, but Sector 10 is bad on every disc (Directory sector 10 is corrupted), SimCoupe reads all directory entries correctly. I guess RealSpectrum use a older version of Fdrawcmd, because it works fine only under Windows 98SE or older. The newer RS32 has no ability to read real discs. maybe it could be easier to use a standard SAM Disc, and create a dummy file, which has a Sector bitmap that reserves all sectors nr 10 on the whole disc. That's pretty much what I had in mind, but with additional dummy entries to reserve sector 10 on the directory tracks. 2 hidden entries can be added to each, to prevent the listing stopping so the remaining entries will be searched. I though, you want to modify SimCoupe to format and write discs with 9 sectors, that means, need to change the ROM, File Bitmap layout, etc. When the image is used in the emulator, saving will not use sector 10 in the directory since it has hidden files in it. The dummy file prevents sector 10 being used across the rest of the disk. Thats what I mean too. To write to a USB floppy drive would just need the 10th sector to be dropped, and the remaining 720K written to the raw device. When opening the USB drive in SimCoupe, the emulator will need to provide suitable dummy details for every sector 10. So you automaticaly can recognise USB Drives, I guess. I never used USB drives and have no Apple here, but Mac users have no other chance to connect a floppy drive, if they got no internal floppy connector. A Image of 256 Bytes of the last directory entry, which is precalculated and could be written on any disc, reserving sectors that are not accessable from PC. Any files saved after that on this disc, would be avoid writing these sectors, so no need to change SimCoupe. If there are more than 17 files on the disk, getting a directory listing would attempt to read track 0 sector 10. A SimCoupe change is still needed to return something for that read attempt. It would also be wise to block attempts to write to sector 10, since it can't be saved. Oh, I forgot about writting dummy sectors to directory sectors 10. So 8+1 Entrys needed, so this will reduce the number of saveable files to 71. But for data transfer needs it does not matter very much. The dummy entrys did not need to have a bitmap. Si Cheers! LCD
RE: Grabbing floppy images
Activision, IIRC, owns the Infocom games. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, June 17, 2008 12:17 AM To: sam-users@nvg.ntnu.no; Steve Parry-Thomas Subject: RE: Grabbing floppy images Quoting Steve Parry-Thomas [EMAIL PROTECTED]: There is around 60 new disk images on the Pro-DOS site, including a number of Infocom IF games , with HiSofts CP/M FTL Modula-2 coming later. Nice! All we need is a native player for SAM Mode - and a way to convert the data files :-) Who owns the rights on the IF games these days?
Re: Grabbing floppy images
Thomas Harte wrote: Although I'm aware that my USB drive may be hard coded somehow not to support anything other than the PC layout That's pretty much it I'm afraid! USB floppy drives are seen as simple block devices, and the linear-CHS mapping is done inside the unit. I believe DD disks will always be treated as 9-sector 720K (and HD as 18-sector 1.44M), so be missing the 10th sector of each SAM track. I have heard rumours of USB drives with an unofficial way to change the geometry mapping in the drive, but I've yet to find one myself. Until someone creates something like a USB CatWeasel, you'll be unable to access 10-sector disks on a Mac. Even if I can't image original disks, is there any way I could use this drive for some sort of data transfer? You'd be much better off with an Atom Lite board in the drive 2 slot, so you can share a Compact Flash card between SAM and SimCoupe. It's faster, easier and more reliable than dealing with floppies. Edwin can provide them if you're interested. The USB drive situation could be improved, with specially crafted disks that lock out the 10th sector on each track. SimCoupe could assist by returning matching dummy contents for the inaccessible directory and data sectors. You still wouldn't be able to use existing 10-sector SAM disks, but 90% of the space would be usable on new ones. Si
Re: Grabbing floppy images
Hmmm, so Sam DOS numbers tracks from 0, but sectors from 1? Or am I suffering a deficit of logic? Follow-on questions - does Pro-DOS use 9 or 10 sector tracks and/or is there a CP/M tool for imaging Sam format disks, I guess to multiple floppies if necessary? I guess it's best to contact Edwin directly with Atom Lite purchase questions, but it sounds like a compact flash formatted for use with the Atom is readable only by Sim Coupe? The Atom won't read disk images from a FAT32 volume on the compact flash and just make them looks like dfisks to the Sam? And I guess a Trinity Ethernet thingy from Quazar is equivalent to an Atom Lite from a storage point of view? I was actually thinking of getting a compact flash for my Nintendo DS and trying some homebrew - have you any opinion on the ease of porting Sim Coupe? The DS's native screen resolution of 256x192 is almost begging for it. On Mon, Jun 16, 2008 at 9:10 AM, Simon Owen [EMAIL PROTECTED] wrote: Thomas Harte wrote: Although I'm aware that my USB drive may be hard coded somehow not to support anything other than the PC layout That's pretty much it I'm afraid! USB floppy drives are seen as simple block devices, and the linear-CHS mapping is done inside the unit. I believe DD disks will always be treated as 9-sector 720K (and HD as 18-sector 1.44M), so be missing the 10th sector of each SAM track. I have heard rumours of USB drives with an unofficial way to change the geometry mapping in the drive, but I've yet to find one myself. Until someone creates something like a USB CatWeasel, you'll be unable to access 10-sector disks on a Mac. Even if I can't image original disks, is there any way I could use this drive for some sort of data transfer? You'd be much better off with an Atom Lite board in the drive 2 slot, so you can share a Compact Flash card between SAM and SimCoupe. It's faster, easier and more reliable than dealing with floppies. Edwin can provide them if you're interested. The USB drive situation could be improved, with specially crafted disks that lock out the 10th sector on each track. SimCoupe could assist by returning matching dummy contents for the inaccessible directory and data sectors. You still wouldn't be able to use existing 10-sector SAM disks, but 90% of the space would be usable on new ones. Si
Re: Grabbing floppy images
Thomas wrote: Hmmm, so Sam DOS numbers tracks from 0, but sectors from 1? Or am I suffering a deficit of logic? Yes, tracks 0-79, 128-207 and sectors 1 to 10. The Atom won't read disk images from a FAT32 volume on the compact flash and just make them looks like dfisks to the Sam? Atom, Atom Lite, Trinity, - anything that uses B-DOS formats and splits the mass storage into 800K chunks (called RECORDs) which each act as a floppy. It's its own type of Format - not FAT32 or such like. And I guess a Trinity Ethernet thingy from Quazar is equivalent to an Atom Lite from a storage point of view? From a storage point of view yes, a patched version of B-DOS works with it so it functions exactly the same. The Trinity currently supports MMC and SD cards up to 1GB in size. Although there's nothing to read/write the B-DOS formatted MMC/SD cards on the PC/MAC. Transfer wise, that's where the ethernet side of the Trinity will come into play. Quite a few applications on the drawing board for when Adrian's finished porting the uIP TCP/IP stack - it's tantilisingly close from what he last said - and then it should be relatively straightforward to get file transfer / FTP going to allow transfers over the network, and with that then it'll be very easy to write a chunk of code to transfer a .dsk image and write it to a RECORD on the mass storage etc. I was actually thinking of getting a compact flash for my Nintendo DS and trying some homebrew - have you any opinion on the ease of porting Sim Coupe? The DS's native screen resolution of 256x192 is almost begging for it. Simon did let me print a photo in SAM Revival 20 showing the start of his work on a port with the SAM startup screen showing on his DS. Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe 1995-2008 - Celebrating 14 Years of developing for the SAM Coupe Website: http://www.samcoupe.com/
Re: Grabbing floppy images
Thomas Harte wrote: Hmmm, so Sam DOS numbers tracks from 0, but sectors from 1? Or am I suffering a deficit of logic? Yes. sectors are 1-10. tracks are 0-79 the fun part (that used to throw many people) is the head selection. sam has: sector #C H S (cyl, head, sect) 1 0 0 1 2 0 0 2 3 0 0 3 4 0 0 4 5 0 0 5 6 0 0 6 7 0 0 7 8 0 0 8 9 0 0 9 10 0 0 10 11 1 0 1 12 1 0 2 13 1 0 3 14 1 0 4 15 1 0 5 795 79 0 5 796 79 0 6 797 79 0 7 798 79 0 8 799 79 0 9 800 79 0 10 801 0 1 1 802 0 1 2 803 0 1 3 804 0 1 4 159679 1 6 159779 1 7 159879 1 8 159979 1 9 160079 1 10 Nev
Re: Grabbing floppy images
Thomas Harte wrote: Hmmm, so Sam DOS numbers tracks from 0, but sectors from 1? Or am I suffering a deficit of logic? Most systems use 1-based sector numbers, though the BBC Micro and Opus Discovery both use 0-based. SAM track numbers are still 0-79 on both sides, and the 128-207 numbering Colin mentioned is just a SAMDOS concept to have the head number in bit 7. Follow-on questions - does Pro-DOS use 9 or 10 sector tracks and/or is there a CP/M tool for imaging Sam format disks, I guess to multiple floppies if necessary? Pro-Dos uses 9-sector disks with 1-based sector numbers. It won't work directly with some +3 and CPC disks because they use bits 6+7 of the sector number to indicate different disk types. Steve Parry-Thomas has been using a Spectrum emulator to convert CPC CP/M images to a format that Pro-Dos can read. Edwin has also been working on storing CP/M images in Atom records, so no floppies needed there either. it sounds like a compact flash formatted for use with the Atom is readable only by Sim Coupe? It's a SAM-specific format, comprising of a boot sector, record index, and an array of 800K disk-sized records filling the rest of the disk. Most of the Spectrum based IDE projects seem to go for FAT16/32 support, though often for read-only access to tape images or snapshots. Building a list of SAM disk images, then giving read/write random access to them is a bit more involved. A question for Edwin maybe ;-) And I guess a Trinity Ethernet thingy from Quazar is equivalent to an Atom Lite from a storage point of view? For basic storage I think they're fairly equivalent, though BDOS version differences might mean some feature differences. The Atom Lite has an optional DALLAS chip for file times, if you don't have a clock on a different board. I'm not sure how they compare speed-wise, though the Lite is faster than the original Atom due to a difference in byte order. I was actually thinking of getting a compact flash for my Nintendo DS and trying some homebrew - have you any opinion on the ease of porting Sim Coupe? At a basic level it was quite easy to get running, but it's far from usable yet. I'm still not even sure about running speed, though some crude benchmarks suggested it was maybe just below normal speed. Some core changes I made for the desktop version did help, but it needs further work. I've been a bit out of the loop for months with Real Life, so it's not been looked at since the end of Jan. If you get a SD adapter for your DS, you're welcome to join the fun! The DS's native screen resolution of 256x192 is almost begging for it Indeed! http://simonowen.com/images/simcoupe_ds.jpg Si
RE: Grabbing floppy images
Steve Parry-Thomas has been using a Spectrum emulator to convert CPC CP/M images to a format that Pro-Dos can read. Edwin has also been working on storing CP/M images in Atom records, so no floppies needed there either. Yep! I have tried to restore a number of HiSoft Packages that were for the cp/m 2.2 system. Some files were missing from some of the images in the Amstrad archives. Missing files were found in the cp/m MSX archives! The files were moved to MS-DOS with a MSX disk image manager, then moved to a Pro-DOS floppy with 22Disk - dos program. Other files were in the wrong disk format, so loading the image into Spectaculator 7, then I can open the B drive as a 720 image and copy the files over into the new image, which SIM Coupe with Pro-DOS can read. There is around 60 new disk images on the Pro-DOS site, including a number of Infocom IF games , with HiSofts CP/M FTL Modula-2 coming later. Steve.
Re: Grabbing floppy images
Various thoughts in response to this entire thread... I like Pro-DOS because it feels like a real operating system. But I've never seriously used it. It's a shame that CP/M didn't offer standard (albeit likely to be much-slower-than-native) graphics routines, or maybe there'd be a whole bunch of graphics adventures and 'useful' productivity software. I'll obviously need to save up for a Trinity or an Atom Lite. It's a shame neither do FAT32 + virtual images, even if it was just something like, e.g. having a read-only FAT32 partition on one part of the flash and a read/write Sam partition on the rest. Then at least only one piece of software for transferring from file system images to Sam-segment images would need to be written, for the Sam itself. And all PC OSs that can read/write cards and know FAT32 would work immediately. I'm actually not bad with low-level floppy formats and the WD177x having implemented a theoretically 'perfect' emulation of the latter for my ElectrEm project. I can't think of a reason for a normal, public domain program to go straight to the WD177x though, unless it really needed the memory that Sam DOS sits in. Maybe there's something I haven't thought of? I take it from the talk of different versions of B-DOS that the neither the Atom nor Trinity interfaces make any attempt to look like a WD177x in hardware? Re: the DS, I must remember to implement an optional 'square pixels' mode in my 3d engine. It'd be fairly easy to do as a tiny bit of dynamic reprogramming at runtime, though it'd probably mean you could see slightly further top to bottom. Or slightly less far left to right. Regarding that whole topic, some weekend work on the most critical segments has bought me a 20%+ speedup and I'm hoping to wring some more from the code overall. Next initiative: switch the face visibility tester to use a neat scalar/2d vector multiplication 'trick' that I'm sure everybody else thought of years ago — I'm loading the multiplier once to shift right and conditionally branch and simultaneously doing the multiplicand shift left and answer additions in both hl and hl' so as to multiply two multiplicands by the same multiplier for less than it would cost to do them individually. And I'm very, very proud of that. On Mon, Jun 16, 2008 at 2:45 PM, Steve Parry-Thomas [EMAIL PROTECTED] wrote: Steve Parry-Thomas has been using a Spectrum emulator to convert CPC CP/M images to a format that Pro-Dos can read. Edwin has also been working on storing CP/M images in Atom records, so no floppies needed there either. Yep! I have tried to restore a number of HiSoft Packages that were for the cp/m 2.2 system. Some files were missing from some of the images in the Amstrad archives. Missing files were found in the cp/m MSX archives! The files were moved to MS-DOS with a MSX disk image manager, then moved to a Pro-DOS floppy with 22Disk - dos program. Other files were in the wrong disk format, so loading the image into Spectaculator 7, then I can open the B drive as a 720 image and copy the files over into the new image, which SIM Coupe with Pro-DOS can read. There is around 60 new disk images on the Pro-DOS site, including a number of Infocom IF games , with HiSofts CP/M FTL Modula-2 coming later. Steve.
Re: Grabbing floppy images
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] Received: from [192.168.3.100, 82.108.154.19] via 88-96-166-22.dsl.zen.co.uk [88.96.166.22] with HTTP/1.0 (POST); Mon, 16 Jun 2008 15:29:50 +0100 User-Agent: RoundCube Webmail Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Mon, 16 Jun 2008 15:10:18 +0100, Thomas Harte [EMAIL PROTECTED] wrote: It's a shame that CP/M didn't offer standard (albeit likely to be much-slower-than-native) graphics routines, or maybe there'd be a whole bunch of graphics adventures and 'useful' productivity software. Like GSX, you mean? Geoff
Re: Grabbing floppy images
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] Received: from [192.168.3.100, 82.108.154.19] via 88-96-166-22.dsl.zen.co.uk [88.96.166.22] with HTTP/1.0 (POST); Mon, 16 Jun 2008 15:29:47 +0100 User-Agent: RoundCube Webmail Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Mon, 16 Jun 2008 15:10:18 +0100, Thomas Harte [EMAIL PROTECTED] wrote: It's a shame that CP/M didn't offer standard (albeit likely to be much-slower-than-native) graphics routines, or maybe there'd be a whole bunch of graphics adventures and 'useful' productivity software. Like GSX, you mean? Geoff
Re: Grabbing floppy images
[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] Received: from [192.168.3.100, 82.108.154.19] via 88-96-166-22.dsl.zen.co.uk [88.96.166.22] with HTTP/1.0 (POST); Mon, 16 Jun 2008 15:30:42 +0100 User-Agent: RoundCube Webmail Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Mon, 16 Jun 2008 15:10:18 +0100, Thomas Harte [EMAIL PROTECTED] wrote: It's a shame that CP/M didn't offer standard (albeit likely to be much-slower-than-native) graphics routines, or maybe there'd be a whole bunch of graphics adventures and 'useful' productivity software. Like GSX, you mean? Geoff [apologies if this arrives (tw|thr)ice - webmail playing up]
Re: Grabbing floppy images
Thomas wrote: I take it from the talk of different versions of B-DOS that the neither the Atom nor Trinity interfaces make any attempt to look like a WD177x in hardware? Correct. Having hardware that would mimic the WD1772 for mass-storage would be overkill I think, and drastically more complex than what's been made to date. It's a shame neither do FAT32 + virtual images, even if it was just something like, e.g. having a read-only FAT32 partition on one part of the flash and a read/write Sam partition on the rest. Edwin's done a great job with the B-DOS and it's a very neat solution for handling mass storage, that's why I asked him if he would mind it being patched for Trinity. With such a good DOS there, there was no need to reinvent the wheel. I know I have info somewhere for FAT reading, and I've had the odd letter asking if the likes of a SD card from a camera could be read on the SAM. I had said in reply that I might briefly look at it sometime in BASIC just for very simple file transfer and write it for an article in the magazine or something, but taking it further to a full DOS to use the likes of a .dsk as a virtual disk would be a pretty big jump and not something I'd have the time for, plus I've no real experience of writing DOS stuff on the SAM - I'm still really inclined to using the network for transferring... really itching to get on with things when the stack is ready. Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe 1995-2008 - Celebrating 14 Years of developing for the SAM Coupe Website: http://www.samcoupe.com/
RE: Grabbing floppy images
Is that a little hint hint at hte bottom of your email ;) Good news is all of the main UIp is converted, just writing a test app :D Then i need to finalise how best to allow access to it for features for other coders. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin Piggot Sent: 16 June 2008 16:00 To: Adrian Subject: Re: Grabbing floppy images Thomas wrote: I take it from the talk of different versions of B-DOS that the neither the Atom nor Trinity interfaces make any attempt to look like a WD177x in hardware? Correct. Having hardware that would mimic the WD1772 for mass-storage would be overkill I think, and drastically more complex than what's been made to date. It's a shame neither do FAT32 + virtual images, even if it was just something like, e.g. having a read-only FAT32 partition on one part of the flash and a read/write Sam partition on the rest. Edwin's done a great job with the B-DOS and it's a very neat solution for handling mass storage, that's why I asked him if he would mind it being patched for Trinity. With such a good DOS there, there was no need to reinvent the wheel. I know I have info somewhere for FAT reading, and I've had the odd letter asking if the likes of a SD card from a camera could be read on the SAM. I had said in reply that I might briefly look at it sometime in BASIC just for very simple file transfer and write it for an article in the magazine or something, but taking it further to a full DOS to use the likes of a .dsk as a virtual disk would be a pretty big jump and not something I'd have the time for, plus I've no real experience of writing DOS stuff on the SAM - I'm still really inclined to using the network for transferring... really itching to get on with things when the stack is ready. Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe 1995-2008 - Celebrating 14 Years of developing for the SAM Coupe Website: http://www.samcoupe.com/ APB Computer Services Ltd. Registered Address: 3 Springfield, Trevadlock, Congdons Shop, Launceston, Cornwall, PL15 7PW. Registration Number: 4942193. V.A.T. No: 826 0005 70 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: Grabbing floppy images
Adrian wrote: Is that a little hint hint at hte bottom of your email ;) Nah, not trying to hint, I'd just send a message saying chop chop if I wanted to be blatent about it! ;) Besides you know I've been excited about seeing the stack going from when you first said you would be looking at porting it across to the SAM, and for all of us 'Real Life' and 'Work' have to take priority over SAM stuff. Good news is all of the main UIp is converted, just writing a test app :D Then i need to finalise how best to allow access to it for features for other coders. Fantastic! Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe 1995-2008 - Celebrating 14 Years of developing for the SAM Coupe Website: http://www.samcoupe.com/
Re: Grabbing floppy images
OT - slightly! It's great to see all the recent activity on the list and in the SAM scene - both in programming and hardware! It's *almost* enough to make you want to crack open a copy of CodeWright and start knocking out some Z80! Seriously, well done chaps it's great to see the little SAM is still able to bring out the creative side in people! Chris. - Original Message - From: Adrian Brown [EMAIL PROTECTED] To: sam-users@nvg.ntnu.no; [EMAIL PROTECTED] Sent: Monday, June 16, 2008 4:54 PM Subject: RE: Grabbing floppy images Yer real life and work does get in the way - don't suppose there is a mutli-millionare on the list who wants to cough up about 3 grand to employ me for a month to work on sam stuff? ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin Piggot Sent: 16 June 2008 16:31 To: Adrian Subject: Re: Grabbing floppy images Adrian wrote: Is that a little hint hint at hte bottom of your email ;) Nah, not trying to hint, I'd just send a message saying chop chop if I wanted to be blatent about it! ;) Besides you know I've been excited about seeing the stack going from when you first said you would be looking at porting it across to the SAM, and for all of us 'Real Life' and 'Work' have to take priority over SAM stuff. Good news is all of the main UIp is converted, just writing a test app :D Then i need to finalise how best to allow access to it for features for other coders. Fantastic! Colin = Quazar : Hardware, Software, Spares and Repairs for the SAM Coupe 1995-2008 - Celebrating 14 Years of developing for the SAM Coupe Website: http://www.samcoupe.com/ APB Computer Services Ltd. Registered Address: 3 Springfield, Trevadlock, Congdons Shop, Launceston, Cornwall, PL15 7PW. Registration Number: 4942193. V.A.T. No: 826 0005 70 This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Grabbing floppy images
Hi, I have a Mac running OS X v10.5.3. I also have a USB floppy drive. Despite having previously refused to acknowledge any DOS formatted double density disks, the drive seems to have some success recognising Sam disks. But I don't seem to be able to successfully image a Sam floppy. I was hoping that somebody here who knows more about the way the Sam lays out its sectors and about the various UNIX tools might be able to help me. I'm attempting to image Arcadia Disk 3a, for no reason other than that it was first to hand and I'm confident that it is formatted in the usual Sam DOS way. Having identified my floppy drive as /dev/disk2 using Apple's Disk Utility, I tried the following at the terminal: dd if=/dev/disk2 of=floppy.dsk bs=512 count=1600 That produces the output: 1440+0 records in 1440+0 records out 737280 bytes transferred in 249.220053 secs (2958 bytes/sec) I also tried: d if=/dev/disk2 of=floppy2.dsk bs=2x80x10b And got: 0+1 records in 0+1 records out 737280 bytes transferred in 249.183222 secs (2959 bytes/sec) Both produced identical 720 kb files. When I try to boot either in Sim Coupe, I get the error 19 Loading error, 0:1. If I load Sam DOS from another disk and then try to do a dir on one of these images, I get a list of the first 18 files on the disk and the error 85 TRK- 0, SCT-10, Error 0:1. I'm aware that the number of sectors per track is different on the Sam and on the PC. This error makes me think that the drive is reading the disk per the DOS format and ignoring some of the Sam format sectors. In particular, I notice that 1600*512 = 2*80*10*512 = 800 kb, not 720 kb, which just happens to be the amount of data that MS-DOS puts on a disk. It strikes me that alternatively there is a disagreement between Sim Coupe and dd as to whether tracks should be stored in an interleaved format. But then I'd expect 800 kb images. Although I'm aware that my USB drive may be hard coded somehow not to support anything other than the PC layout, I am curious as to whether there is anything I can do about this. Anyone got any ideas? Even if I can't image original disks, is there any way I could use this drive for some sort of data transfer?
