Stuart Brady wrote:
BTW, what needs to be done to convert a sad file to a dsk and vice-versa?
Use Aley's 2SAD program, which can convert to DSK or SAD (versions 1 and 2)
ftp://ftp.nvg.ntnu.no/pub/sam-coupe/utils/disk/2sad.zip
Alternatively, create a new DSK file in SimCoupe, mount both images
Aley Keprt wrote:
Could we made also music database? I mean music from games, demos etc.
I have ripped tens of music modules from several games and demos (for
my player SamPlay distributed together with SAAemu), but I haven't
released many of them because of copyright issues.
Is the copyright
Aley Keprt wrote:
What to say?
Excellent! If the listed features really work, it's excellent. Excellent!
:-) Hopefully everything accessible should work fine - any other partial
implementations (ATOM, SDF, etc.) are hidden for now, but will appear when
they're finished.
I have two
Dave Laundon wrote:
Dave
Dave (who had/s some part in programming SimCoupe/Win32 (albeit small in
comparison...))
Not that small really! You made major changes to the memory access timings
used by all the CPU code, which has simplified it a lot, and has been
essential in getting many timing
Do you want me to remove them images ?
Cw
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Simon Owen
Sent: 08 March 2001 10:15
To: sam-users@nvg.ntnu.no
Subject: RE: Disk image formats
Stuart Brady wrote:
BTW, what needs to be done to convert a sad file
Chris White wrote:
Do you want me to remove them images ?
Nah - they're the only versions of those titles available at the moment, and
they're too good to remove while I sort things out! I'll probably get back
to you about updating them when SimCoupe has new SDF support in it. :-)
The old
On Thu, 8 Mar 2001, Simon Owen wrote:
SAD files have a 22 bytes header, which contains a rather large text
signature and some geometry information. You can specify the number of
sides, number of tracks per side, number of sectors per track and the bytes
per sector.
So Aley's disk backup, char
Stuart Brady wrote:
So Aley's disk backup, char sides (2), char tracks (80), char sectors
(10)... and then what? All of my disks seem to have 8 as the last byte in
the header, so is this just multiplied by 64?
It is indeed! I've always thought it a bit odd that it seems to save a byte
on the
Storing generated register data is not better than the current state,
because it is like recording a TV show on a VCR, and distributing video
casettes with it.
It is illegal.
The current format used in SamPlay is:
1. Put the file at 32768.
2. Do Samadeus/Amadeus check. If passed use
You can download sad to dsk and dsk to sad converter source code from
ftp.nvg, and use it if you want to.
Or you can just look there for more information on handling sad files and
what is next in the header ;-)
8 in last byte of header means 512 bytes per sector. It's 64*8=512. All
values from
Stuart Brady wrote:
So Aley's disk backup, char sides (2), char tracks (80), char sectors
(10)... and then what? All of my disks seem to have 8 as the last byte
in
the header, so is this just multiplied by 64?
It is indeed! I've always thought it a bit odd that it seems to save a
byte
Aley Keprt wrote:
[...]
I don't know AZX. How you can use it? For AY data, or SAA data. If you would
like to use it for SAA data, there's no reason of using it. AZX is not for
Sam.
Really ? Why ? You've just told you do not know what is AZX, didn't you ?
Sure, AZX files are LARGE
12 matches
Mail list logo
