gmane.comp.systems.sam-coupe

Thomas Harte | 16 Jun 00:13

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:

(Continue reading)

Simon Owen | 16 Jun 10:10

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

(Continue reading)

Thomas Harte | 16 Jun 12:29

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 <simon.owen@...> 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.
>

(Continue reading)

Colin Piggot | 16 Jun 12:58

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

(Continue reading)

nev young | 16 Jun 13:09

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

(Continue reading)

Simon Owen | 16 Jun 15:19

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

(Continue reading)

Steve Parry-Thomas | 16 Jun 15:45

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.

Thomas Harte | 16 Jun 16:10

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

(Continue reading)

Colin Piggot | 16 Jun 16:54

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.

(Continue reading)

Simon Cooke | 18 Jun 07:15

RE: Grabbing floppy images

BTW... love the Vector multiply trick. That's freakin' awesome. Never
thought of that one :D

-----Original Message-----
From: owner-sam-users@...
[mailto:owner-sam-users@...] On
Behalf Of Thomas Harte
Sent: Monday, June 16, 2008 7:10 AM
To: sam-users@...
Subject: Re: Grabbing floppy images

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.

david | 17 Jun 09:17

RE: Grabbing floppy images

Quoting Steve Parry-Thomas <morrigancp@...>:

>
>

> 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?

Simon Cooke | 18 Jun 07:16

RE: Grabbing floppy images

Activision, IIRC, owns the Infocom games. 

-----Original Message-----
From: owner-sam-users@...
[mailto:owner-sam-users@...] On
Behalf Of david@...
Sent: Tuesday, June 17, 2008 12:17 AM
To: sam-users@...; Steve Parry-Thomas
Subject: RE: Grabbing floppy images

Quoting Steve Parry-Thomas <morrigancp@...>:

>
>

> 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?

Leszek Chmielewski | 18 Jun 19:10

Re: Grabbing floppy images

Simon Owen schrieb:
> 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.
>
>
If I remember correctly, RealSpectrum Emulator was working with my disc 
Drive on Parallel port (under Win98), so USB is a step backward.

You coded the fdrawcmd.sys? It should work with onboard floppy connector 
under Win2K. I currently try to build RealDisc support into the disc 
manager of Retro-X (The picture converter PC->ZX, SAM, QL, MSX, CPC, 
C64, ...). 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. SimCoupe on 
the other side works fine with real Discs.
Any idea what -1 means (long is signed in PureBasic, so it returns

(Continue reading)

Simon Owen | 22 Jun 02:25

Re: Grabbing floppy images

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.

> 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.

When the image is used in the emulator, saving will not use sector 10 in

(Continue reading)

Leszek Chmielewski | 22 Jun 12:38

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

(Continue reading)

Thomas Harte | 22 Jun 14:05

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

(Continue reading)

Geoff Winkless | 16 Jun 16:29

Re: Grabbing floppy images

<48562007.7050007@...>
<a08f95720806160329u2aca6ba9u5dbd5a357f80aef2@...>
<48566863.6060700@...>
<1648148C4D594D12ACB449B560737C67 <at> stevepc1> <a08f95720806160710s375a4110udbf179b545f0435f@...>
Message-ID: <5bfe4f9d17482c50a4dc1dce39fed5c2 <at> localhost>
X-Sender: sam-users@...
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"
<tomh.retrospec@...> 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

Geoff Winkless | 16 Jun 16:29

Re: Grabbing floppy images

<48562007.7050007@...>
<a08f95720806160329u2aca6ba9u5dbd5a357f80aef2@...>
<48566863.6060700@...>
<1648148C4D594D12ACB449B560737C67 <at> stevepc1> <a08f95720806160710s375a4110udbf179b545f0435f@...>
Message-ID: <298056bb0c8eac75ced9d0735007cf08 <at> localhost>
X-Sender: sam-users@...
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"
<tomh.retrospec@...> 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

Geoff Winkless | 16 Jun 16:30

Re: Grabbing floppy images

<48562007.7050007@...>
<a08f95720806160329u2aca6ba9u5dbd5a357f80aef2@...>
<48566863.6060700@...>
<1648148C4D594D12ACB449B560737C67 <at> stevepc1> <a08f95720806160710s375a4110udbf179b545f0435f@...>
Message-ID: <960bd387c3c05a2d7b4ccd80b179b8e0 <at> localhost>
X-Sender: sam-users@...
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"
<tomh.retrospec@...> 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]

Return

Return to gmane.comp.systems.sam-coupe.

Advertisement

Project Web Page

The mailing list for everything SAM Coupé

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane