Re: buggy KEYIN; MasterBASIC's tokenized format; buggy RENUM
On 15 Nov 2012, at 22:57, Marcos Cruz wrote: What do you mean auto-typed? Text spooling? Yep, that's it! It's currently a Windows-only feature at the moment, but I'll extend it to support other platforms. AFAIK SimCoupe lacks a file spooling option (in fact it is what I need: SimCoupe to type the content of a text file of the host machine). I'll add file spooling for non-Windows platforms, and clipboard paste once SDL 2.0 is supported. The Windows version will likely remain clipboard only, since sniffing the encoding from text files is just too unreliable. there are many labels in the imported KEYIN-ed code. I'll remove them too --just to see what happens. I'll be interested to hear how you get on with this. If it does fix it, labels are definitely to be avoided until the ROM issue is tracked down and (hopefully) fixed. Si
Re: buggy KEYIN; MasterBASIC's tokenized format; buggy RENUM
My guess is that the final label might be at some kind of page boundary, which trips up the code building the table. I haven't tried to look into it -- any volunteers...? So this may or may not be related but I've memories of long basic programs getting corrupted, and the corruption would happen around a page boundary. I'd end up putting long REM statements around the area affected. I've found an example in the fortress code on the sad snail collection. There are a bunch of REMS around line 40250. I'm pretty certain if I could remember how to check this will be at a page boundary. HTH, Tim
Re: buggy KEYIN; MasterBASIC's tokenized format; buggy RENUM
Quoting Tim Paveley u...@samcoupescrapbook.co.uk: My guess is that the final label might be at some kind of page boundary, which trips up the code building the table. I haven't tried to look into it -- any volunteers...? So this may or may not be related but I've memories of long basic programs getting corrupted, and the corruption would happen around a page boundary. I'd end up putting long REM statements around the area affected. I'm sure I had this issue with the Newsdisk Basic text viewer a few times... and very sure I had the same problem when I used similar code for the Blitz diskzine. (SAM Prime used a special text editor from Nigel Kettlewell so it didn't have that issue)
buggy KEYIN; MasterBASIC's tokenized format; buggy RENUM
Hi all, Some time ago I wrote a toolkit to write MasterBASIC programs with the Vim editor (http://vim.org) and import them into SimCoupe (see http://programandala.net/en.program.mbim). It didn't work because the KEYIN command has bugs (in SAM BASIC, but MasterBASIC didn't fix them). In fact, a similar tool for ZX Spectrum's Beta BASIC (see, in Spanish: http://programandala.net/es.programa.bbim) works like a charm: I can write Beta BASIC code (in an improved format with new features) with Vim, and then, with a keypress, convert it to real Beta BASIC and create a fake disk image ready to be imported into the Beta BASIC interpreter. It would be nice to work the same way with the more powerful MasterBASIC... Is there any patch to fix SAM Coupé's KEYIN? I'm afraid not. I thought an alternative: I could write a program to convert the source code into tokenized MasterBASIC and copy it into a SAM disk image. But the tokenized format is not fully described in the Technical Manual or the MasterBASIC User Manual (though many details can be found there and others are similar to the ZX Spectrum format). In theory this approach is feasible, but much more complex. Any other idea? I'd like to develop some project in MasterBASIC, but its own editor would be a pain compared with the features of a modern editor. Beside, also the RENUM command is buggy, what is a serious limitation. Marcos -- http://programandala.net
Re: buggy KEYIN; MasterBASIC's tokenized format; buggy RENUM
This sounds like a problem I was looking at with Josef a few months back, where long ported programs failed on SAM. As far as I could tell it was a bug with LABEL management -- his problem listing used many labels (no use of KEYIN). I was able to narrow it down to a boundary case, as demonstrated with this test program: 1 PRINT Running... 2 FOR x=1 TO 111 3 PRINT at 1,0;x 4 KEYIN STR$ (x*2+100)+ LABEL l+STR$ x+: PRINT +STR$ x+: STOP 5 KEYIN STR$ (x*2+101)+ REM x 6 NEXT x 7 CLS : STOP 8 REM -X 1) Type that into a freshly booted SAM, run it, then wait for the counter to reach 111. If you then type CLEAR it gets stuck and never returns. 2) Next, do the same again but remove the 'X' from the end of line 8. This time the CLEAR command will finish after about 30 seconds, which I believe is the time taken to rebuild the LABEL table from scratch. To rule out a problem with KEYIN, I used LLIST to write the program to a text file using the SimCoupe printer option. I then auto-typed the contents back in to a freshly reset SimCoupe, so KEYIN was never actually executed, even though it was still part of the listing. I was still able to demonstrate the same issue, with the single character difference. My guess is that the final label might be at some kind of page boundary, which trips up the code building the table. I haven't tried to look into it -- any volunteers...? I noticed your program also uses labels, though not as many. It might be worth trying to remove the labels, to see if that magically fixes it? Si On 15/11/2012 18:17, Marcos Cruz wrote: Hi all, Some time ago I wrote a toolkit to write MasterBASIC programs with the Vim editor (http://vim.org) and import them into SimCoupe (see http://programandala.net/en.program.mbim). It didn't work because the KEYIN command has bugs (in SAM BASIC, but MasterBASIC didn't fix them). In fact, a similar tool for ZX Spectrum's Beta BASIC (see, in Spanish: http://programandala.net/es.programa.bbim) works like a charm: I can write Beta BASIC code (in an improved format with new features) with Vim, and then, with a keypress, convert it to real Beta BASIC and create a fake disk image ready to be imported into the Beta BASIC interpreter. It would be nice to work the same way with the more powerful MasterBASIC... Is there any patch to fix SAM Coupé's KEYIN? I'm afraid not. I thought an alternative: I could write a program to convert the source code into tokenized MasterBASIC and copy it into a SAM disk image. But the tokenized format is not fully described in the Technical Manual or the MasterBASIC User Manual (though many details can be found there and others are similar to the ZX Spectrum format). In theory this approach is feasible, but much more complex. Any other idea? I'd like to develop some project in MasterBASIC, but its own editor would be a pain compared with the features of a modern editor. Beside, also the RENUM command is buggy, what is a serious limitation. Marcos
Re: buggy KEYIN; MasterBASIC's tokenized format; buggy RENUM
En/Je/On 2012-11-15 20:37, Simon Owen escribió / skribis / wrote : To rule out a problem with KEYIN, I used LLIST to write the program to a text file using the SimCoupe printer option. I then auto-typed the contents back in to a freshly reset SimCoupe, What do you mean auto-typed? Text spooling? AFAIK SimCoupe lacks a file spooling option (in fact it is what I need: SimCoupe to type the content of a text file of the host machine). I noticed your program also uses labels, though not as many. It might be worth trying to remove the labels, to see if that magically fixes it? I think I tried everything I could imagine when I developed the several versions of MBimport one year ago. Nevertheless I've just written a new label-less version of MBimport. It's easy to remove the two or three labels of the importer, but it makes no difference because there are many labels in the imported KEYIN-ed code. I'll remove them too --just to see what happens. Thank you Marcos -- http://programandala.net
SCS snapshot file format documentation
If anyone of you interested in new file format, please visit this page: http://www.keprt.cz/sam/scs.php (I also found a bug in emulator when documenting the file format. A minor bug, I will fix it in next version.) - Mgr. Aleš Keprt, Ph.D. private: a...@keprt.cz, www.keprt.cz office: Moravian College / Moravská vysoká škola Olomouc, ales.ke...@mvso.cz
Re: Format Vol 10 No 10 [1-32].pdf sample pdf issue
On Sat, 15 Jan 2005 18:41:18 EST, [EMAIL PROTECTED] wrote: I have had a few positive comments about it so I will start the rest. Working backwards from Vol 12 No2 as if you have . Working backwards means we get the Sam bits. If you have Vol 12 No 3 on wards and would like to help - please email me atmorriagcp @ aol . com . Dose anyone know at which issue is stopped? . [Nev- you should know?] Hi, had a look through my loft today. The last issue I can find is vol 12 #1 so you have more than me. I also found I have about 5 missing issues in vols 1011 :( and I am sure I used to have them all. But I do appear to have a complete set from the free issue to the start of vol 10. Nev -- Nev - please note that mail to address nevilley@ and anything containing HTML will now go into a spam bucket because of excessive email abuse. Please use one of my new addresses.
Format Vo12 No02 pdf - upload
Hi Folks, Format Vo12 No 02 has been upload to the ftp.nvg.ntn.no , also if you have given me your incoming on your web site you will find it there. Someone emailed me and asked why start at the end and work backwards? Well it’s where the Sam stuff is. The pdf is searchable – happy reading. Steve
Re: Format Vol 10 No 10 [1-32].pdf sample pdf issue
Ok, all errors that I have been told about have been fix! a new upload has been made to ftp.nvg.ntnu.no /incoming If Frode couldmove it and delete the old version - please! I have had a few positive comments about it so I will start the rest. Working backwards from Vol 12 No2 as if you have. Working backwards means we get the Sam bits. If you have Vol 12 No 3 on wards and would like to help - please email me at morriagcp @ aol . com . Dose anyone know at which issue is stopped? . [Nev- you should know?] I will be using this new software just for the formats the other pdfs I did use other software. If you have sent me a list of errors in the Sam Basic Users Guide they have bee corrected, But I am not going to compile a new pdf which will be version 2 yet, I want to finish adding the hyper jumps, like the ones in MasterDos MasterBASIC pdf version 2. Thanks for your kind comments, Steve(spt)
Format Vol 10 No 10 [1-32].pdf sample pdf issue
Hi all, Format Vol 10 No 10 [1-32].pdf sample pdf issue has been upload to ftp://ftp.nvg.ntnu.no/pub/sam-coupe/ Frode will move it to the Docs as its in the incoming at the moment I think. The [1-32] = number of pages. best to get A-Reader version 7 to read it, you can search the text, copy paste. Some of the headings are as a graphic scan . The new software I have been testing looks at its up to the job So What do you think? Do you want more? Steve(spt)
Re: Format Vol 10 No 10 [1-32].pdf sample pdf issue
Is it because of my Reader vs 6 or generell? There are some faults in the listing on page 13. However, a very well done job, Steve. Wolfgang [EMAIL PROTECTED] wrote: Hi all, Format Vol 10 No 10 [1-32].pdf sample pdf issue has been upload to ftp://ftp.nvg.ntnu.no/pub/sam-coupe/ Frode will move it to the Docs as its in the incoming at the moment I think. The [1-32] = number of pages. best to get A-Reader version 7 to read it, you can search the text, copy paste. Some of the headings are as a graphic scan . The new software I have been testing looks at its up to the job So What do you think? Do you want more? Steve(spt)
Re: Format Vol 10 No 10 [1-32].pdf sample pdf issue
On Fri, 14 Jan 2005 07:14:37 EST [EMAIL PROTECTED] wrote: Hi all, Format Vol 10 No 10 [1-32].pdf sample pdf issue has been upload to ftp://ftp.nvg.ntnu.no/pub/sam-coupe/ Frode will move it to the Docs as its in the incoming at the moment I think. I have actually created a new directory: ./magazines/format and put it there. The [1-32] = number of pages. Not sure if this is interesting information...? :) best to get A-Reader version 7 to read it, you can search the text, copy paste. I'm using 5.0.9 for Solaris. Some of the headings are as a graphic scan . The new software I have been testing looks at its up to the job Just a few questions: - Page 2 - is it supposed to be like that? - Page 10 - a few artifacts on the left-hand column? - Page 11 - line 25 on the right-hand column? - Page 13 - some artifacts on the right-hand side? - Page 16 - not the same font for line numbers But these are minor issues. It brought back the 'old days. So What do you think? Do you want more? Yes! Excellent stuff! -Frode -- ^ Frode Tennebø | email: [EMAIL PROTECTED] ^ | Ericsson AS | Isebakkeveien 49 | | N-1788 Halden | Phone: +47 45 24 99 39| | with Standard.Disclaimer; use Standard.Disclaimer;|
Re: Format Vol 10 No 10 [1-32].pdf sample pdf issue
On Fri, 14 Jan 2005 16:26:20 +0100 (MET), Frode Tenneboe [EMAIL PROTECTED] wrote: Just a few questions: - Page 2 - is it supposed to be like that? Yes. It was a mad idea of mine to have a landscape advert. So What do you think? Do you want more? Yes! Excellent stuff! Almost brought a tear to my eyes. I would say yes do more. If you have time, are able etc. I'm sure we can all proof read them and get the few errors fixed. Nev -- Nev - please note that mail to address nevilley@ and anything containing HTML will now go into a spam bucket because of excessive email abuse. Please use one of my new addresses.
Re: Another example why I dislike .DSK format
On Sun, Jan 09, 2005 at 12:53:33PM +, Andrew Collier wrote: .dsk is very convenient for simple images. But there have been discussions here of a more expandable disk format which we can adopt as standard, and we can call it what we like. Does .sam mean anything yet? Yes. Samna Ami Pro, aka Lotus AmiPro (which was basically the first decent Word Processor for Windows). Unfortunately, some people have since decided that it's signed 8-bit sample data. *sigh* -- Stuart Brady
Re: Another example why I dislike .DSK format
What some people have since decided...??? .SAM files are sample data! Of course, Ami Pro uses .SAM as well, I don't complain. But I used .SAM for sample data for years in several programs years before AmiPro came into public knowledge. -- Mgr.(MSc.) Ales Keprt (also known as Aley) [EMAIL PROTECTED] *** www.keprt.cz *** ICQ: 82357182 Dept. of Computer Science, VSB Technical University Ostrava, CZ - [EMAIL PROTECTED] - www.cs.vsb.cz -- - Original Message - From: Stuart Brady [EMAIL PROTECTED] To: sam-users@nvg.ntnu.no Sent: Sunday, January 09, 2005 3:39 PM Subject: Re: Another example why I dislike .DSK format On Sun, Jan 09, 2005 at 12:53:33PM +, Andrew Collier wrote: .dsk is very convenient for simple images. But there have been discussions here of a more expandable disk format which we can adopt as standard, and we can call it what we like. Does .sam mean anything yet? Yes. Samna Ami Pro, aka Lotus AmiPro (which was basically the first decent Word Processor for Windows). Unfortunately, some people have since decided that it's signed 8-bit sample data. *sigh* -- Stuart Brady
Re: Another example why I dislike .DSK format
On Mon, Jan 10, 2005 at 12:32:22AM +0100, Aley Keprt wrote: What some people have since decided...??? .SAM files are sample data! Of course, Ami Pro uses .SAM as well, I don't complain. Yes, you do -- you complain all the time! ;-) But I used .SAM for sample data for years in several programs years before AmiPro came into public knowledge. Fine. The since was a mistake. It was Samna's fault. Big deal. -- Stuart Brady
Can you Help With Indugs Format Fonts ID?
Hi all, I`m testing some new OCR Software which can Font match. In a test of Format to convert to PDF has worked very well, but would be better if I knew all the fonts used. Can you help in the names or even point me to where they are? regards Steve(spt)
Re: Another example why I dislike .DSK format
On Jan 9, 2005, at 10:30 am, Aley Keprt wrote: No, that's a reason why you don't like certain operating systems' assumption that a three letter extension can uniquely identify a file type. We know, for example, that a file 819200 bytes long doesn't represent a +3 disk. .dsk is very convenient for simple images. But there have been discussions here of a more expandable disk format which we can adopt as standard, and we can call it what we like. Does .sam mean anything yet? Andrew -- --- Andrew Collier http://www.intensity.org.uk/ --- -- Have you lost your Marbles? http://www.marillion.com/
Re: Another example why I dislike .DSK format
Oh yeah, 819200 bytes certainly is Sam disk, but neither Total Commander, nor Windows Explorer knows it. So when you click on a DSK file, it opens the associated program. This problem is also realted to often used ZIP for everything. Sometimes I think we'd need a tiny universal loader, which will be associated with the particular extension, load the file, examine the contents and/or file size and start the right program. Does an utility like this already exist? And of course, .SAM means sample, it's used for years for sound samples. :-) Don't we have SDF or something, which is a generic Sam disk format? -- Mgr.(MSc.) Ales Keprt (also known as Aley) [EMAIL PROTECTED] *** www.keprt.cz *** ICQ: 82357182 Dept. of Computer Science, VSB Technical University Ostrava, CZ - [EMAIL PROTECTED] - www.cs.vsb.cz -- - Original Message - From: Andrew Collier [EMAIL PROTECTED] To: sam-users@nvg.ntnu.no Sent: Sunday, January 09, 2005 1:53 PM Subject: Re: Another example why I dislike .DSK format On Jan 9, 2005, at 10:30 am, Aley Keprt wrote: No, that's a reason why you don't like certain operating systems' assumption that a three letter extension can uniquely identify a file type. We know, for example, that a file 819200 bytes long doesn't represent a +3 disk. .dsk is very convenient for simple images. But there have been discussions here of a more expandable disk format which we can adopt as standard, and we can call it what we like. Does .sam mean anything yet? Andrew -- --- Andrew Collier http://www.intensity.org.uk/ --- -- Have you lost your Marbles? http://www.marillion.com/
Re: Another example why I dislike .DSK format
On Jan 9, 2005, at 2:16 pm, Dan Dooré wrote: Aley Keprt wrote: Don't we have SDF or something, which is a generic Sam disk format? From what I understand SDF is a discontinued format and this spawned the discussion on a generic format for representing all sam disk geometrys with headers for containing information and such like. But the new über-format could inherit the name .SDF it that helps. Andrew -- --- Andrew Collier http://www.intensity.org.uk/ --- -- Have you lost your Marbles? http://www.marillion.com/
Re: Another example why I dislike .DSK format
Aley Keprt wrote: And of course, .SAM means sample, it's used for years for sound samples. :-) And AMIPro Word docs and a myriad of others :-) Don't we have SDF or something, which is a generic Sam disk format? From what I understand SDF is a discontinued format and this spawned the discussion on a generic format for representing all sam disk geometrys with headers for containing information and such like. The reason for persevering with the DSK format is for simplicity but as I have said in the NVG re-org mails but as soon as a format is available they will all get moved into this format and hopefully the complications of dealing with the mish-mash of DSK/TD0/SADv1/SADv2/MGT/PAK/LIB/SBT formats will be over. Dan.
Re: Another example why I dislike .DSK format
But simple the support of DSK (or SAD) should be preserved too, since it's good for its simplicity and so many utils can work with it (them). -- Mgr.(MSc.) Ales Keprt (also known as Aley) [EMAIL PROTECTED] *** www.keprt.cz *** ICQ: 82357182 Dept. of Computer Science, VSB Technical University Ostrava, CZ - [EMAIL PROTECTED] - www.cs.vsb.cz -- - Original Message - From: Dan Dooré [EMAIL PROTECTED] To: sam-users@nvg.ntnu.no Sent: Sunday, January 09, 2005 3:16 PM Subject: Re: Another example why I dislike .DSK format Aley Keprt wrote: And of course, .SAM means sample, it's used for years for sound samples. :-) And AMIPro Word docs and a myriad of others :-) Don't we have SDF or something, which is a generic Sam disk format? From what I understand SDF is a discontinued format and this spawned the discussion on a generic format for representing all sam disk geometrys with headers for containing information and such like. The reason for persevering with the DSK format is for simplicity but as I have said in the NVG re-org mails but as soon as a format is available they will all get moved into this format and hopefully the complications of dealing with the mish-mash of DSK/TD0/SADv1/SADv2/MGT/PAK/LIB/SBT formats will be over. Dan.
Re: Another example why I dislike .DSK format
Andrew Collier wrote: But the new über-format could inherit the name .SDF it that helps. Indeed - IIRC there's only two SDF files in the wild anyway Lemmings and PoP. Sam Disk Format does have a nice ring to it to boot :-) Dan.
Re: SDI a nef diskimage format ?
On Fri, Dec 10, 2004 at 04:11:58PM -, Geoff Winkless wrote: attempted to format a track I knew would fail - if it formatted correctly it would know the disk had been copied... Wouldn't this be defeated by write-protecting the disk? Andrew -- ---Andrew Collier http://www.intensity.org.uk/ --- -- r2+ T4* cSEL dMS hEn/CBBL A4 S+*++ C$++L/mP W- a-- Vh+seT+ (Cantab) 1.1.4
Re: SDI a nef diskimage format ?
On Fri, Dec 10, 2004 at 04:11:58PM -, Geoff Winkless wrote: One of the ways I was going to do protection (if I'd ever got round to it) was buying a load of really crappy disks and writing code specific for each disk that attempted to format a track I knew would fail - if it formatted correctly it would know the disk had been copied... not usable on high-volume items, but for the low-volume Sam market, it would have been perfectly do-able :) It doesn't seem a good idea because if they are that crappy then who's to say they won't start losing real data? (I suppose there might be a market for time-limited software...) Better to buy good disks and scratch them with a pin, or something. imc
Re: SDI a nef diskimage format ?
On Fri, Dec 10, 2004 at 04:11:58PM -, Geoff Winkless wrote: attempted to format a track I knew would fail - if it formatted correctly it would know the disk had been copied... Wouldn't this be defeated by write-protecting the disk? Andrew -- ---Andrew Collier http://www.intensity.org.uk/ --- -- r2+ T4* cSEL dMS hEn/CBBL A4 S+*++ C$++L/mP W- a-- Vh+seT+ (Cantab) 1.1.4
RE: SDI a nef diskimage format ?
Geoff Winkless wrote: Why not a tagged format and tools which can handle both types? I've been fleshing out the details of a potential new format to efficiently represent any SAM disk type. It uses your suggested tagged structure, some of the tag types I mentioned recently, and Edwin's fragment idea for sparse non-empty sectors. Rather than wrapping existing image formats, it's a separate format in its own right (perhaps to replace the existing unfinished SDF?). I've written enough code to write images out to a file in the new format, to see how it handles various existing files. Writing valid images is fairly simple, but writing efficient/compact files requires a bit more analysis of what is being written. Normal disks are stored very compactly by recognising patterns in the disk format, and custom disk formats also store only non-empty tracks. Each file starts with a 4-byte header: an ASCII signature (currently XXX for testing) and a version byte (0x10 = version 1.0). The rest of the file is formed from tagged blocks, each with a 2-byte ASCII type and 2-byte length (all values are stored in little-endian format), followed by the specified length of data. I've currently got the following types: TX - null-terminated ASCII text block PF - pre-format details, for regular format disks SD - sector data to fill pre-formatted areas TK - custom track format+data RT - raw track data EN - file end marker TX : an optional field with no fixed format, most likely used for disk descriptions, copyrights, etc. PF : the data is an 11-byte block containing the following 8-bit values: Sides - number of sides in the pre-format block (normal=2) Tracks - number of tracks in the pre-format block (normal=80) Sectors - sectors per track for all sectors (normal=10) Size - sector size code (0=128, 1=256, 2=512 (normal), 3=1024) for all sectors Fill - fill byte to use for data areas (normal=0x00) Base - lowest sector number in track (normal=1) Start - first sector number on track 0 of side 0 (normal=1) Step - step value between ordered sector numbers (normal=1) Interleave - number of sectors to advance between consecutive sectors on a track (normal=1) TrackSkew - sector gap to the same sector number on the following track (MasterDOS=1,SAMDOS=2) SideSkew - sector gap to the same sector number on the same track of the next side (SAM=0,CP/M=1) The pre-format block is a rectangular region of tracks spanning out from track 0 of side 0 to whatever disk extent is needed. It provides a convenient way to prepare a region using a regular format pattern, without having to list each track individually. Custom data can then be filled in with SD tags, or tracks can be completely reformatted with TK tracks. The 6 parameters controlling the sector order allow almost any regular format to be efficiently represented, including regular skewed SAM formats and the Pro-Dos CP/M format. SD : the data begins with a single byte containing the physical location for the track. The lower 7 bits contain the track number, with bit 7 set if the data is for side 2 (this could use separate side and track bytes, but my thought is that 2 sides and 128 tracks is enough for any real-world disk). The location byte is followed by a 1-byte packing code for each sector present on the track, and for this reason, the track must already exist from an earlier PF or TK tag. After the packing bytes comes the sector data, stored in the order the sectors are found on the track. The meaning of the data depends on the packing code for the each sector, which are as follows: 0 = sector is filled with the default fill byte found in the PF header. This is the default for sectors in pre-formatted tracks, but when overriding the sector data in an existing track it must be supplied again explicitly. 1 = sector is filled with a single byte, taken from the sector data block 2 = sector is a fragment, using 5 bytes in the data block. The first data byte is the default fill byte for the sector, the next two bytes give an offset into the sector for the start of the fragment, and the two bytes after that are the block length. 3 = the full sector data is supplied, and taken from the sector block Additional codes and compression methods could be added quite easily, but I've left out anything more complicated to keep the format simple. It would be better to store and supply the image in a zip/gzip file, which will have compression superior to anything I could add. Zip files are probably preferred for familiarity, and have the added benefit of a built-in CRC. TK : the data begins with a byte for the physical location of the track (as with SD) and a byte holding the number of sectors in the track. This is followed by a block of 6-byte sector headers, and then the data block for the sectors. Each sector header holds: Track - id field track value (may be faked) Side - id field side value (may be faked) Sector - sector number
RE: SDI a nef diskimage format ?
Frans van Egmond wrote: If one of you programming people need a Catweasel, I have a spare Catweasel MK3 lying around that I'd be happy to loan It's probably best to avoid too much reliance on unusual hardware to create images, as it's unlikely all disks we'd want scanning would be owned by someone with a Catweasel (or access to one). Having Windows 2000/XP as a requirement doesn't seem too extreme, and the scans should contain enough detail for what we need. I can adapt the MakeSDF project for scanning on the SAM too, so users with DOS/Linux access can write transfer the normal format images of the protected disks for unpacking on the PC side. Thanks for the offer though - we might find a need for it yet :-) Si
RE: Format returns
[EMAIL PROTECTED] wrote: Yer - I was asking about this - If needed I could contact bob as I have several old format issues I could turn into pdf. I have the full set in my attic. Probably being eaten by spiders we you read. Nev
RE: SDI a nef diskimage format ?
Andy Chandler wrote: will cope with all but one SAM disk I've seen so far :-) I'm betting that was another Mr Owen creation ;-) It's actually Chris Pile's original Defender disk, which does some gap-level checking as part of the copy protection. The gap information isn't stored as part of the disk image, as it's almost never needed, and would more than double the image size. SimCoupe actually fakes the raw track data from information it knows about the sectors on the current track, so it looks pretty authentic in programs like SAM DICE. Using a tagged disk format it would be possible to include a READ_TRACK dump for just the one track needed, to hold the information Defender expects. Due to the controller bug, it wouldn't be easy to write back to a real disk using a generic image writer (unless another tag held formatting hints!). The track data would also be enough for SimCoupe to run the protected Defender image too, which would be an added bonus ;-) Si
RE: SDI a nef diskimage format ?
Hi, is there a format for SimCoupe similar to Sinclair Spectrum Z80/Sna format ? Regards, Dumitru Florin Gabriel ( Zecut0r ).
RE: SDI a nef diskimage format ?
Nev Young wrote: why not create an image that is a full track image from index hole to index hole including all the inter sector guff. That should cover just about everything. It would indeed, if there was a reliable way to dump them! You'd really need all the sync marks as well as the raw track data, but even reading the raw track data is a problem... Unfortunately, the WD1772-02 controller leaves the address mark detector enabled during the diagnostic tracks reads, meaning certain patterns in the data can cause a false sync. If this happens the controller returns MFM bits instead of data bits from that point on in the track, making what you read essentially useless. I tried this method when writing the original MakeSDF scanner, before spotting the problem and working out what the heck it was doing. The PC controller allows you to read ID field headers and data, but doesn't give access to anything in the gap areas. There is a Disk2FDI program that can do it, but is a commercial program and requires 2 floppy drives. It spins both drives up and starts the read of a high-density disk in drive 1, then switches the drive-select to drive 2, with the controller then returning MFM _and_ data bits for the disk in drive 2. Very clever, but it's DOS-only and wasn't particularly reliable when I tried it a while ago. Another option is to use a Catweasel controller card, which can read just about any disk at very low level. They're not cheap though, and it's not really something most people will have access to for dumping. For now the header/sector-level scanning seems to be about the best solution, and will cope with all but one SAM disk I've seen so far :-) Si
Re[2]: SDI a nef diskimage format ?
On a side track (hah), has anyone else found that all their old Sam disks are completely unreadable? Is it likely that I had a drive that, while being in-spec of the other Sam drives, is out of spec enough so that the average PC drive can't read floppies created by it? Or is it more likely that almost every single one of my disks have simply degraded over time? I've found that all my bought Disks seem to have faired very well and were still readable. Some of my blank disks I had written files on, were sometimes readable in drive 1 or sometimes in drive 2, but then my two drives always seemed to be a opposite ends of calibration to each other.
Re: SDI a nef diskimage format ?
Geoff Winkless wrote: On a side track (hah), has anyone else found that all their old Sam disks are completely unreadable? None comepletly unreadable, many with errors which ment I couldn't make a DSK of them at the time. Unless SamDisk2 can skip errors (I haven't got the URL to hand) they will have to stay in the old box for evermore :-( Dan.
Re: SDI a nef diskimage format ?
Simon Owen wrote: Does the archive need to be a single format for all disks? Or could the 95% of normal format disks be kept in a simple dumped image format, with only protected disks using a different format needed to describe them correctly? I think yes, the idea of tagging extra data into a header appeals but as Geoff pointed out we could have a standard header and then store the payload as a straight DSK or an SDF image (or SDF V1.1 with Freaky Cookie Malarky mode enabled). Dan.
Re: SDI a nef diskimage format ?
My two penneth of the disk format discussion: I like the idea of a new, all-encompassing disk format for the samcoupe.org archive (SCOA anyone?) as it will bring together many disparate formats DSK/SDF/SAD etc. into one, but it has to be able to hold the full geometry of the disk. After all, the idea is that the images in the archive should be true to the original format and IMHO there is no point implementing a new format if it cannot handle all disks, after all we might as well stick to DSK and SAD and the odd SDF for that. What we need to say is that this is the format for the archive and if anybody prefers to have it in DSK then they should be able to make it that way for their own needs, I am thinking of a parallel to getting a speccy .TAP file and converting it to a .Z80 because that's what you prefer to deal with but the .TAP file is the 'original format' that you take that from. Also, I think the idea of including data in the header of the format is vital - I have too may ARSE.DSK files knocking about and it will be a good method of preserving the information if authors, dates etc. in a standard and manageable way like it ID tags in MP3 files. In short: One site to store them all, One place to find them, One format to store them all and on the Internet bind them. :- Dan.
Re: SDI a nef diskimage format ?
Simon: Good, bad or ugly? Sounds OK. Some things I thought up for 'PC' minded format: Have a format that consists only of track fragments (sectors). Each fragment had a 6 byte header folowed by at least 4 bytes data. So the smallest fragment was 10 bytes and largers 1024 (length/4-4 in one byte). Depending on the fragments type it contains all gap types, address marks, sector data. Besides the diskinfo there are types for file formats ID , end of image marker and discription. As with the other idea, only the used or required fragments are included and each of these track fragment could be anywhere in the image.(emulator should build a ordered offset table) Standard images can have just the sector fragments and protected disks can add extra fragments to rebuild a whole track. Ugly ? As for a encapsulating format: zip dsk,sad,sdf,fdi and rename the extension. Shoot me for this one ! Edwin
Re: SDI a nef diskimage format ?
If one of you programming people need a Catweasel, I have a spare Catweasel MK3 lying around that I'd be happy to loan to you for the duration of this project if it does the community any good :-) Frans Simon Owen wrote: Nev Young wrote: why not create an image that is a full track image from index hole to index hole including all the inter sector guff. That should cover just about everything. It would indeed, if there was a reliable way to dump them! You'd really need all the sync marks as well as the raw track data, but even reading the raw track data is a problem... Unfortunately, the WD1772-02 controller leaves the address mark detector enabled during the diagnostic tracks reads, meaning certain patterns in the data can cause a false sync. If this happens the controller returns MFM bits instead of data bits from that point on in the track, making what you read essentially useless. I tried this method when writing the original MakeSDF scanner, before spotting the problem and working out what the heck it was doing. The PC controller allows you to read ID field headers and data, but doesn't give access to anything in the gap areas. There is a Disk2FDI program that can do it, but is a commercial program and requires 2 floppy drives. It spins both drives up and starts the read of a high-density disk in drive 1, then switches the drive-select to drive 2, with the controller then returning MFM _and_ data bits for the disk in drive 2. Very clever, but it's DOS-only and wasn't particularly reliable when I tried it a while ago. Another option is to use a Catweasel controller card, which can read just about any disk at very low level. They're not cheap though, and it's not really something most people will have access to for dumping. For now the header/sector-level scanning seems to be about the best solution, and will cope with all but one SAM disk I've seen so far :-) Si
RE: SDI a nef diskimage format ?
Dan Dooré wrote: I like the idea of a new, all-encompassing disk format for the samcoupe.org archive (SCOA anyone?) as it will bring together many disparate formats DSK/SDF/SAD etc. into one, but it has to be able to hold the full geometry of the disk. One thing to remember though is that some games (eg. Parallax or Lemmings) use different formats invented by *cough* yours truly, which the suggested format won't actually be able to support. This includes: Sector addresses which do not directly correspond to their real location on disk - eg. on track 4 you'd have a sector which had a sector ID of 10, and a track id of 255. (This happens in the Parallax copy protection). Lemmings includes large storage disks (again, one of mine) with (IIRC) a similar scheme for sector address munging. The trick is that it used 5 x 1024 byte sectors followed by 1 x 512 byte sector to fit 11k per track, instead of the usual 10k. I think it may also have written 82 tracks. Not sure though. Any truly generic archive format would have to support such disks. Simon
Re: SDI a nef diskimage format ?
On Dec 9, 2004, at 11:13 pm, Simon Cooke wrote: Sector addresses which do not directly correspond to their real location on disk - eg. on track 4 you'd have a sector which had a sector ID of 10, and a track id of 255. (This happens in the Parallax copy protection). ooh, sneaky! Any truly generic archive format would have to support such disks. Agreed. I think the only good reason to invent a new diskimage format would be to hold disk geometries which the previous ones couldn't - and I think Simon just identified it. Cheers, Andrew -- --- Andrew Collier http://www.intensity.org.uk/ --- -- Have you lost your Marbles? http://www.marillion.com/
RE: SDI a nef diskimage format ?
--- Z80 [EMAIL PROTECTED] wrote: Hi, is there a format for SimCoupe similar to Sinclair Spectrum Z80/Sna format ? Regards, Dumitru Florin Gabriel ( Zecut0r ). Not that I`ve seen... if there was it`d have to be either 256K or in a lot of cases 512K big, plus seen as most software was disk based you`d have to have a copy of whatever disk was in drive 1 too (780K) (in case of extra loading) so snaps could/would be up to nearly 1.3 Megabytes each... Might have it`s uses though, occasionally :) (CKay) in fact mosta the time you probably wouldn`t need a copy of the disk also (but you might not know which software will reload data, or load new data, or need to write to disk...) :) It would be nice... ___ Win a castle for NYE with your mates and Yahoo! Messenger http://uk.messenger.yahoo.com
RE: SDI a nef diskimage format ?
Simon Cooke wrote: Sector addresses which do not directly correspond to their real location on disk SDF stores the ID fields for each sector, so faked track/head values and non-standard sector numbers are no problem. it used 5 x 1024 byte sectors followed by 1 x 512 byte sector to fit 11k per track, instead of the usual 10k. Mixed sector sizes are covered as part of storing the ID header+data for each sector on the track. It also preserves the sector order from the index hole, which is something Sophistry needs to run in full rather than demo mode. On W2K/XP you can use the new: SamDisk.exe /scan a: to display a sector-level dump of protected disks, including sector order and any mismatched track/head values. It won't let you image those disks just yet, but it's in the pipeline... I think it may also have written 82 tracks. My Lemmings _appears_ to have 83 tracks formatted, but with track 82 an exact copy of track 81 (including headers). It could just be that the drive I used to image it couldn't seek to track 82, but I've got a feeling viewing it on the PC also showed the same. Any truly generic archive format would have to support such disks. Does the archive need to be a single format for all disks? Or could the 95% of normal format disks be kept in a simple dumped image format, with only protected disks using a different format needed to describe them correctly? Si
RE: SDI a nef diskimage format ?
Simon Owen wrote: Does the archive need to be a single format for all disks? Or could the 95% of normal format disks be kept in a simple dumped image format, with only protected disks using a different format needed to describe them correctly? Why not a tagged format and tools which can handle both types? As a user I would certainly rather have an archive with a single type of disk. Geoff __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Re: Format returns
Nev Young wrote: [EMAIL PROTECTED] wrote: The best thing would be, if it is possible to reach Mr. Bob, was to see if it was possible to have the original files he used for his typesetting and convert from them. I have no idea what tool he used, but it should be possible to do a bulk conversion some way or the other= . He did it all on a SAM or a BBC Nev I think he used Lotus Amipro in later years. -- Tarquin Mills (Chairman) ACCUS (Anglia Classic Computer Users Society) http://www.speccyverse.me.uk/comp/accus/
Re: SDI a nef diskimage format ?
Simon: Does the archive need to be a single format for all disks? Or could the 95% of normal format disks be kept in a simple dumped image format, with only protected disks using a different format needed to describe them correctly? Just Like speccy has TAP for regular format and TZX for the fancy one that preserves the original. Edwin
Re: SDI a nef diskimage format ?
[EMAIL PROTECTED] wrote: Simon: Does the archive need to be a single format for all disks? Or could the 95% of normal format disks be kept in a simple dumped image format, with only protected disks using a different format needed to describe them correctly? Just Like speccy has TAP for regular format and TZX for the fancy one that preserves the original. I too have used disks with odd formats mainly track 5 having an extra short sector between sector 10 and the index hole. I'll probably get shot down for suggesting this but why not create an image that is a full track image from index hole to index hole including all the inter sector guff. That should cover just about everything. Nev
RE: SDI a nef diskimage format ?
Dan Dooré wrote: (or SDF V1.1 with Freaky Cookie Malarky mode enabled). SDF has always handled the Freaky Cookie Malarky, so no need for an update! Here's a dump of the first 2 tracks of my Parallax.sdf file, showing the faked track=128 and mixed sector sizes that Cookie mentioned: 0:01 4[s=1024,t=128] 2[s=1024,t=128] 5[s=1024,t=128] 3[s=1024,t=128] 0:11[s=1024,t=128] 4[s=1024,t=128] 2[s=1024,t=128] 5[s=1024,t=128] 3[s=1024,t=128] SDF also being killed off as a format as soon as we can all decide what to replace it with (falling back on the Russian FDI if there's nothing better). Si
Re[2]: SDI a nef diskimage format ?
For now the header/sector-level scanning seems to be about the best solution, and will cope with all but one SAM disk I've seen so far :-) I'm betting that was another Mr Owen creation ;-) Friday, December 10, 2004, 2:41:26 PM, you wrote: Simon Nev Young wrote: why not create an image that is a full track image from index hole to index hole including all the inter sector guff. That should cover just about everything. Simon It would indeed, if there was a reliable way to dump them! You'd really Simon need all the sync marks as well as the raw track data, but even reading the Simon raw track data is a problem... Simon Unfortunately, the WD1772-02 controller leaves the address mark detector Simon enabled during the diagnostic tracks reads, meaning certain patterns in the Simon data can cause a false sync. If this happens the controller returns MFM Simon bits instead of data bits from that point on in the track, making what you Simon read essentially useless. I tried this method when writing the original Simon MakeSDF scanner, before spotting the problem and working out what the heck Simon it was doing. Simon The PC controller allows you to read ID field headers and data, but doesn't Simon give access to anything in the gap areas. There is a Disk2FDI program that Simon can do it, but is a commercial program and requires 2 floppy drives. It Simon spins both drives up and starts the read of a high-density disk in drive 1, Simon then switches the drive-select to drive 2, with the controller then Simon returning MFM _and_ data bits for the disk in drive 2. Very clever, but Simon it's DOS-only and wasn't particularly reliable when I tried it a while ago. Simon Another option is to use a Catweasel controller card, which can read just Simon about any disk at very low level. They're not cheap though, and it's not Simon really something most people will have access to for dumping. Simon For now the header/sector-level scanning seems to be about the best Simon solution, and will cope with all but one SAM disk I've seen so far :-) Simon Si
RE: SDI a nef diskimage format ?
Simon Owen wrote: It's actually Chris Pile's original Defender disk, which does some gap-level checking as part of the copy protection. The gap information isn't stored as part of the disk image, as it's almost never needed, and would more than double the image size. SimCoupe actually fakes the raw track data from information it knows about the sectors on the current track, so it looks pretty authentic in programs like SAM DICE. One of the ways I was going to do protection (if I'd ever got round to it) was buying a load of really crappy disks and writing code specific for each disk that attempted to format a track I knew would fail - if it formatted correctly it would know the disk had been copied... not usable on high-volume items, but for the low-volume Sam market, it would have been perfectly do-able :) I do remember reading about one company which used to laser holes in their disks at a specific point to do much the same thing, although I don't think this was on the Sam. On a side track (hah), has anyone else found that all their old Sam disks are completely unreadable? Is it likely that I had a drive that, while being in-spec of the other Sam drives, is out of spec enough so that the average PC drive can't read floppies created by it? Or is it more likely that almost every single one of my disks have simply degraded over time? I spent many many hours trying to get Linux to read my Sam floppies using different FDD parameters before giving up and deciding that it must simply be the disks :( G __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: SDI a nef diskimage format ?
Dan Dooré wrote: None comepletly unreadable, many with errors which ment I couldn't make a DSK of them at the time. I only found the odd error too, and sometimes they'd be readable in a different drive. The only problems I've had recently is when I made the mistake of using high-density disks with the hole covered - they seemed to work at first, but go bad very quickly. Unless SamDisk2 can skip errors (I haven't got the URL to hand) they will have to stay in the old box for evermore :-( Just add a /e to ignore read errors: SamDisk.exe a: MyImage.dsk /e Or for SAMDOS-compatible disks, do a minimal copy of only the used areas, in the hope the bad sector was not part of an allocated file: SamDisk.exe a: MyImage.dsk /m If the image you made did have one or more bad sectors, open the DSK in Edwin's Diskimage Manager and it'll show you which files were affected (marked as broken IIRC). Btw, the SamDisk URL is: http://www.simonowen.com/sam/samdisk/ Si
Format returns
Well not quite, but I was reading the latest issue of ZXF there (http://www.woodcock88.freeserve.co.uk/zxf/zxf.html) and there is news of WorldOfSpectrum gaining permission from our old friend Bob Brenchley to scan and distribute Formats! As the article points out, this is something of a surprise that Bob has allowed this. I wonder if he'd speak to us lot? :) I won't even mention my SAM_Clock and other money he owes me this time ;) As for our own archive, please don't try and email me at [EMAIL PROTECTED] yet, as the password they supplied me with to login and set addresses etc up isn't working. I've been able to login and put up a plain index.html to stop the naked directories of the webspage being browsed, and I've typed up a little history of the project so far. Assuming I get the email addresses sorted tomorrow, we can get cracking on tracking people down etc - I'll email again tomorrow. Night chaps, Gavin
RE: Format returns
Yer - I was asking about this - If needed I could contact bob as I have several old format issues I could turn into pdf. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gavin Smith Sent: 09 December 2004 01:01 To: sam-users@nvg.ntnu.no Subject: Format returns Well not quite, but I was reading the latest issue of ZXF there (http://www.woodcock88.freeserve.co.uk/zxf/zxf.html) and there is news of WorldOfSpectrum gaining permission from our old friend Bob Brenchley to scan and distribute Formats! As the article points out, this is something of a surprise that Bob has allowed this. I wonder if he'd speak to us lot? :) I won't even mention my SAM_Clock and other money he owes me this time ;) As for our own archive, please don't try and email me at [EMAIL PROTECTED] yet, as the password they supplied me with to login and set addresses etc up isn't working. I've been able to login and put up a plain index.html to stop the naked directories of the webspage being browsed, and I've typed up a little history of the project so far. Assuming I get the email addresses sorted tomorrow, we can get cracking on tracking people down etc - I'll email again tomorrow. Night chaps, Gavin
Re: Format returns
I would just like to point out that the WoS Formats are not a proper pdf, just scans placed in a word doc and then compiled into a pdf. You cannot search copy, paste any thing from them. You just as might as well have the scans. I see no point in make pfds that are just scans what do you think? Formats as pdfs - now that would be a big job , different fonts, scans for adverts I did do a proper pdf of a format of issue 10 , to see if it was worth it. but the file got lost on one of my machines. BTY: MasterDos pdf 50% complete. regards, Steve(Spt) www.samcoupe-pro-dos.co.uk
Re: Format returns
On Thu, 9 Dec 2004 06:44:44 EST [EMAIL PROTECTED] wrote: I would just like to point out that the WoS Formats are not a proper pdf, just scans placed in a word doc and then compiled into a pdf. You cannot search copy, paste any thing from them. You just as might as well have the scans. I see no point in make pfds that are just scans what do you think? I agree. And I must add that you did a impressive job with the SAM User Manual. Formats as pdfs - now that would be a big job , different fonts, scans for adverts I did do a proper pdf of a format of issue 10 , to see if it was worth it. but the file got lost on one of my machines. The best thing would be, if it is possible to reach Mr. Bob, was to see if it was possible to have the original files he used for his typesetting and convert from them. I have no idea what tool he used, but it should be possible to do a bulk conversion some way or the other. -Frode -- ^ Frode Tennebø | email: [EMAIL PROTECTED] ^ | Ericsson AS | Isebakkeveien 49 | | N-1788 Halden | Phone: +47 45 24 99 39| | with Standard.Disclaimer; use Standard.Disclaimer;|
Re: Format returns
WorldOfSpectrum gaining permission from our old friend Bob Brenchley to scan and distribute Formats! Personally I like scans more than pdf. Other magazines on wos are scans also. But It's nice to have them available to the public in any form. something of a surprise that Bob has allowed this. I wonder if he'd speak to us lot? :) We'll if some on the list promise to behave Who Nows ;-) I won't even mention my SAM_Clock and other money he owes me this time ;) Now you already did ... Edwin
Re: Format returns
WorldOfSpectrum gaining permission from our old friend Bob Brenchley to scan and distribute Formats! Personally I like scans more than pdf. Other magazines on wos are scans also. But It's nice to have them available to the public in any form. Personally I prefer PDF as what it is, a "portable document format" for PC, Apple computers and as far as I know Amiga and Atari too. It includes pictures and fonts and can be used independent to the sort of computer and compresses the file size. The best thing is, you can make printable booklets with it (as ZXF), so when the new website stands I would like to add "manuals" (as PDF files) of B-DOS 1.7n, Comet assembler 1.3 and the instruction for Spectrum emulator 3.3. Maybe more to come... Wolfgang
SDI a nef diskimage format ?
I gave it some thoughts and here's what I've come up with. The Idea is to make it possible to handle it on a real SAM using CD-ROM and CF in the future. -- SDI or Sam DiskImage is a new diskimage format to replace the .DSK .MGT and .SAD diskimages. Key features are crc protection, a flexible format and smaller diskimages. Diskimage sizes are reduced by not including unused or empty sectors on a disk. Information to keep track of the sectors that are used is achieved with a minimum of overhead. A SDI diskimage can be seen as just an array of sectors where the first sector (header) tells where the other (used data) sectors belong. The diskimage has following structure: +- header sector ---+ | 16 byte diskimage info| | sectormap | | discription | | [zero filed gap] | +---+ +---+ | First used sector | +---+ ... +---+ | last used sector | +---+ 16 byte diskimage info --- bytes Discription [3] 'SDI' magic number in capitals. [4] 32-bit crc. calculated from next byte onward to the last byte of the header. This crc should be used to validate the header. [4] 32-bit crc. calculated over all the data sectors in the image excluding the header. 32-bit crc are calculated in the same way as ZMODEM,ZLIB and PKZIP [2] disk geometry: bit 7 = sides: 0 for single sided 1 for double sided bits 6-0 = tracks 1 to 127 tracks bit 15= start sector: 0 start with 0, 1 start with 1 bits 14,13 = sector size: 00 128 byte sectors 01 256 byte sectors 10 512 byte sectors 11 1024 byte sectors bits 12-8 = sectors per track 1..31 sectors DEFAULT: value is D0CAh [1] empty sector value. A sector completely filled with this value is considered empty and are not included in the sector data. DEFAULT = 00h [1] image flags: bit 7 = Write Protect: When set no changes are allowed to data sectors in the image. Header info can be edited regardless of the state of this bit. To protect the header. The read only file attribute of the image file should be set. DEFAULT = 0 bit 6 = Dynamic Image: When set, disk geometry may be dynamically resized to minimum geometry or expanded depending of the changes made. For example when this bit is set and the image is formatted the a geometry is changed to a single sided disk with just one track contain one sector. when writing a non empty sector outside the images geometry then the geometry will be extended if the sector allocation map can also be extended. When this bit is clear then the geometry will not change and any sector access outside the geometry will produce an error. DEFAULT = 0 bit 5 = emulator boot preference. When this bit is set then it is prefered to always do a cold boot when F9 is pressed or BOOT is executed. DEFAULT = 0 bit 4 = reserved and should be 0 bits 3-0 = dos emulator. On the real hardware this flag can be used to decide which diskimage emulator is loaded to emulate the diskimage. 0 = no preference 1 = SAMDOS 2 = MasterDOS 3 = MASTERDOS+MasterBASIC 4 = Pro-DOS 6 = B-DOS DEFAULT = 0 no preference [1] Reserved and should be 00h [xx] sector adress map or SAM. Like in a directory slot the SAM represents which sectors are used and the position in the map determines which track and sector status it reflects. A '0' bit means that the sectors data is not included in the diskimage a '1'bit means the sectors data is included. the SAM has the same makeup as in a directory slot. starting with bit 0 for the first track and sector up on side one. Side two follows after the last sector on the last track starting with bit 0. In case of odd track or sector numbering each side may have some gap bits which should always be 0. So incase of a standard disk layout of 2 sides 80 tracks 10 sectors starting with sector 1. Track 0, sector 1 starts at bit 0,byte 0 and track 128, sector 1 starts at bit 0,byte 100 The sector allocation maps size can be calculated by the following formula: size = sides *int((tracks * sectors-per-track + 7)/8) any unused bits should be set to 0. DEFAULT SIZE = 200 (double sided 80 track 10 sector disk) [xx] diskimage discription. The diskimage
Re: SDI a nef diskimage format ?
On 9 Dec 2004, at 1:24 pm, Edwin Blink wrote: I gave it some thoughts and here's what I've come up with. The Idea is to make it possible to handle it on a real SAM using CD-ROM and CF in the future. -- SDI or Sam DiskImage is a new diskimage format to replace the .DSK .MGT and .SAD diskimages. Key features are crc protection, a flexible format and smaller diskimages. Diskimage sizes are reduced by not including unused or empty sectors on a disk. Information to keep track of the sectors that are used is achieved with a minimum of overhead. I don't quite understand it all but I did read through it and it does sound like it meets all our needs - looking forward to the more techy people discussing this. Gavin
Re: SDI a nef diskimage format ?
On Thu, 2004-12-09 at 13:24, Edwin Blink wrote: [2] disk geometry: bit 7 = sides: 0 for single sided 1 for double sided bits 6-0 = tracks 1 to 127 tracks bit 15= start sector: 0 start with 0, 1 start with 1 bits 14,13 = sector size: 00 128 byte sectors 01 256 byte sectors 10 512 byte sectors 11 1024 byte sectors bits 12-8 = sectors per track 1..31 sectors DEFAULT: value is D0CAh I only read this quickly, so I may have misunderstood what you're doing. But surely this geometry information needs to be changable on a per-track basis? Protected disks could have different geometries on each track, indeed not all the sectors in one track will necessarily be the same size. The sectore number doesn't need to start with 0 or 1, either. This scheme also doesn't seem to support sectors with CRC errors, which are used in some schemes (the Enigma ones for a start, I think). I must confess I don't necessarily see the advantage of defining a new image format over a implementing an existing standard format... Andrew -- ---Andrew Collier http://www.intensity.org.uk/ --- -- r2+ T4* cSEL dMS hEn/CBBL A4 S+*++ C$++L/mP W- a-- Vh+seT+ (Cantab) 1.1.4
Re: SDI a nef diskimage format ?
From: Andrew Collier [EMAIL PROTECTED] But surely this geometry information needs to be changable on a per-track basis? Protected disks could have different geometries on each track, This format is not for protected disks. I think SDF and FDI cover that quite well. Besides that it is Also impossible for a real sam to emulate protected disks. Edwin
Re: SDI a nef diskimage format ?
On Thu, 2004-12-09 at 15:15, Edwin Blink wrote: From: Andrew Collier [EMAIL PROTECTED] But surely this geometry information needs to be changable on a per-track basis? Protected disks could have different geometries on each track, This format is not for protected disks. I think SDF and FDI cover that quite well. Besides that it is Also impossible for a real sam to emulate protected disks. Then, why not just use a .dsk file? For use with the CF or HD, you'll almost certainly just uncompress the image into a record anyway, so the reduction in file size would seem inconsequential. Andrew -- ---Andrew Collier http://www.intensity.org.uk/ --- -- r2+ T4* cSEL dMS hEn/CBBL A4 S+*++ C$++L/mP W- a-- Vh+seT+ (Cantab) 1.1.4
Re: SDI a nef diskimage format ?
almost certainly just uncompress the image into a record anyway, so the reduction in file size would seem inconsequential. Thats gonna change :-) Edwin
Re: Format returns
[EMAIL PROTECTED] wrote: Well not quite, but I was reading the latest issue of ZXF there (http://www.woodcock88.freeserve.co.uk/zxf/zxf.html) and there is news of WorldOfSpectrum gaining permission from our old friend Bob Brenchley to scan and distribute Formats! As the article points out, this is something of a surprise that Bob has allowed this. I wonder if he'd speak to us lot? :) Well he still speaks to me. whether I listen or not is quite another story. I won't even mention my SAM_Clock and other money he owes me this time ;) neither will I. Nev
Re: Format returns
[EMAIL PROTECTED] wrote: The best thing would be, if it is possible to reach Mr. Bob, was to see if it was possible to have the original files he used for his typesetting and convert from them. I have no idea what tool he used, but it should be possible to do a bulk conversion some way or the other= . He did it all on a SAM or a BBC Nev
Format is Back ;-)
This evening I was just walking to the railway station (to get a train to Ipswich to give a talk to the Iceni Computer Club about the Inclusive Web) when I saw some new builds. Several of the builds where already sold and had a name plate for new tenants, including one for a business called Format Publications. While on the subject there is company in Scotland called West Coast Computers. -- Tarquin Mills Norwich Sinclair and Clones Show (ORSAM 2004) http://www.speccyverse.me.uk/orsam/ http://www.PetitionOnline.com/Sinclair/petition.html (Bring Back YS)
Re: Format is Back ;-)
While on the subject there is company in Scotland called West Coast Computers. That'll be the PC shop that's in Irvine... Hearing about other companies called Format Publications or W.C.C. isn't surprising, I've had about five emails about manuals and remote controls for 'Quazar' branded TV's in the last year! I think it's an american make.. not too sure... Colin = Quazar : Hardware, Software, Spares and Repairs for the Sam Coupe Website: http://www.quazar.clara.net/sam/ Issue Ten of Sam Revival Magazine Out Now - with Coverdisk!
Re: Format is Back ;-)
Sue them! They're clearly trying to profit from your success in the SAM market ;) I really do wonder why they email me as the only place they could get the email from is my website... and there's no tellies or vcr's there! Colin = Quazar : Hardware, Software, Spares and Repairs for the Sam Coupe Website: http://www.quazar.clara.net/sam/ Issue Ten of Sam Revival Magazine Out Now - with Coverdisk!
Re: Format is Back ;-)
Quoting Colin Piggot [EMAIL PROTECTED]: While on the subject there is company in Scotland called West Coast Computers. That'll be the PC shop that's in Irvine... Hearing about other companies called Format Publications or W.C.C. isn't surprising, I've had about five emails about manuals and remote controls for 'Quazar' branded TV's in the last year! I think it's an american make.. not too sure... Sue them! They're clearly trying to profit from your success in the SAM market ;)
Re[2]: Format is Back ;-)
We get the same problem where I work. We have requests for lasers and scientific equipment and our website is clearly nothing to do with anything even remotely like that! Thursday, October 7, 2004, 12:23:27 PM, you wrote: Sue them! They're clearly trying to profit from your success in the SAM market ;) Colin I really do wonder why they email me as the only place they could get the Colin email from is my website... and there's no tellies or vcr's there! Colin Colin Colin = Colin Quazar : Hardware, Software, Spares and Repairs for the Sam Coupe Colin Website: http://www.quazar.clara.net/sam/ Colin Issue Ten of Sam Revival Magazine Out Now - with Coverdisk!
Re: Format is Back ;-)
Quoting Colin Piggot [EMAIL PROTECTED]: Sue them! They're clearly trying to profit from your success in the SAM market ;) I really do wonder why they email me as the only place they could get the email from is my website... and there's no tellies or vcr's there! You could start though? Buy a load of cheap crap tellies from Tesco or Argos, rebrand them and resell them. Tunnel profits into a new SAM and rebrand SR as YS. That would cheer me up today *nods*
Re: TurboMON (was RE: Linux Format)
On Mon, 19 Aug 2002 17:11:50 +0200 Frans [EMAIL PROTECTED] wrote: I couldn't find it, but I may have overlooked it ... The copy which was uploaded was included with SC Monitor Pro and hence could not be redistributed. PS: Turn off HTML! -Frode
Re: TurboMON (was RE: Linux Format)
I wasn't aware HTML was on. I thought I always posted plain text. Is is off now? Frans Frode Tenneboe wrote: On Mon, 19 Aug 2002 17:11:50 +0200 Frans [EMAIL PROTECTED] wrote: I couldn't find it, but I may have overlooked it ... The copy which was uploaded was included with SC Monitor Pro and hence could not be redistributed. PS: Turn off HTML! -Frode
Re: TurboMON (was RE: Linux Format)
Am Die, 2002-08-20 um 19.05 schrieb Frans: I wasn't aware HTML was on. I thought I always posted plain text. Is is off now? Yes. Frans Frode Tenneboe wrote: On Mon, 19 Aug 2002 17:11:50 +0200 Frans [EMAIL PROTECTED] wrote: I couldn't find it, but I may have overlooked it ... The copy which was uploaded was included with SC Monitor Pro and hence could not be redistributed. PS: Turn off HTML! -Frode
RE: Linux Format
snipped link to TurboMON docs in RTF format Here's a more convenient PDF version, which also prevents the table formatting breaking on printers with larger margins. I've correced a few typos and removed my old snail address, but the rest of the cheese is the same: http://homepage.ntlworld.com/simon.owen/sam/TurboMON.pdf Si
Re: Linux Format
Can TurboMON be downloaded somewhere? Frans Simon Owen wrote: snipped link to TurboMON docs in RTF format Here's a more convenient PDF version, which also prevents the table formatting breaking on printers with larger margins. I've correced a few typos and removed my old snail address, but the rest of the cheese is the same: http://homepage.ntlworld.com/simon.owen/sam/TurboMON.pdf Si
Re: Linux Format
Can TurboMON be downloaded somewhere? Should be in NVG? --Matt.
Re: Linux Format
Ofcourse that should've been the first place I should've checked before asking! Sorry! Frans Matthew J. Craven wrote: Can TurboMON be downloaded somewhere? Should be in NVG? --Matt.
TurboMON (was RE: Linux Format)
Frans wrote: Can TurboMON be downloaded somewhere? I'll upload an image of it when I get home (in about an hour). I'm surprised it's not somewhere on NVG already! Si
Re: TurboMON (was RE: Linux Format)
I couldn't find it, but I may have overlooked it ... Thanks Si, Frans Simon Owen wrote: Frans wrote: Can TurboMON be downloaded somewhere? I'll upload an image of it when I get home (in about an hour). I'm surprised it's not somewhere on NVG already! Si
RE: TurboMON (was RE: Linux Format)
Earlier I wrote: I'll upload an image of it when I get home Oh, and after I've been to the shops too ;-) Here's an updated image (with source code): http://homepage.ntlworld.com/simon.owen/sam/TurboMON.zip I've also found some design notes for it from mid-1993, which I'll put online soon (for a laugh). There was no emulator back then, so I just typed ideas and code fragments into text files, to prepare for coding when I finished Uni. Si
Linux Format
For those who don't read it, this months Linux Format includes SimCoupe in the feature on Emulators, giving it almost a full page and some good press. Huzzah! Tim
RE: Linux Format
What i bet it doesnt say is, if you really want to enjoy this machine - try and locate one on ebay :D Nothing beats the real thing. A. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tim P Sent: 15 August 2002 22:51 To: [EMAIL PROTECTED] Users Subject: Linux Format For those who don't read it, this months Linux Format includes SimCoupe in the feature on Emulators, giving it almost a full page and some good press. Huzzah! Tim
RE: Linux Format
What i bet it doesnt say is, if you really want to enjoy this machine - try and locate one on ebay :D Nothing beats the real thing. Actually I disagree. The emulator is now fast, accurate and featured enough that it's far easier to code than using the sam ever was. Using Comet in fast mode (at 300% or so) is absolutely marvellous. Once Si gets his real-time hardware debugger sorted things would become even easier. No searching for (or switching!) floppies, no problems with dodgy cables (I guess that was my fault rather than Sam's :) and in a window too, so I can have the z80 timing reference (it's been a while, ok? :) right next to the code screen. Geoff
RE: Linux Format
Nahhh, your missing the point. I know the emulator is basically perfect, but its just not like having the real thing sitting there (I trust you have got the real thing as the rom is still copyrighted and hence the emulator is only legal to those with a sam). Dont have the floppies problem with an Atom HD, screen display is fine, especially if you do the shadow fix - Get issue 1 of Sam Revival for full details on that. Quazar surround sound, gotta love things like stratosphere (even if it is a touch hard :D ). Its like, I can play all the arcade games I want on MAME, so why have i built a full size cabinet in my garage so i can buy the Arcade PCB's? Am I just mad, probably. But still emulators just dont have the same appeal to me. On the point of a debugger, ive already got one for the actual sam, TurboMon, now who wrote that? :) (And yes its an original) A. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Winkless, Geoff Sent: 16 August 2002 09:37 To: 'sam-users@nvg.ntnu.no' Subject: RE: Linux Format What i bet it doesnt say is, if you really want to enjoy this machine - try and locate one on ebay :D Nothing beats the real thing. Actually I disagree. The emulator is now fast, accurate and featured enough that it's far easier to code than using the sam ever was. Using Comet in fast mode (at 300% or so) is absolutely marvellous. Once Si gets his real-time hardware debugger sorted things would become even easier. No searching for (or switching!) floppies, no problems with dodgy cables (I guess that was my fault rather than Sam's :) and in a window too, so I can have the z80 timing reference (it's been a while, ok? :) right next to the code screen. Geoff
RE: Linux Format
Sorry, the roms have been given permission to be distributed with the emulator although the rights still remain with Dr A.Wright. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Adrian Brown Sent: 16 August 2002 10:26 To: sam-users@nvg.ntnu.no Subject: RE: Linux Format Nahhh, your missing the point. I know the emulator is basically perfect, but its just not like having the real thing sitting there (I trust you have got the real thing as the rom is still copyrighted and hence the emulator is only legal to those with a sam). Dont have the floppies problem with an Atom HD, screen display is fine, especially if you do the shadow fix - Get issue 1 of Sam Revival for full details on that. Quazar surround sound, gotta love things like stratosphere (even if it is a touch hard :D ). Its like, I can play all the arcade games I want on MAME, so why have i built a full size cabinet in my garage so i can buy the Arcade PCB's? Am I just mad, probably. But still emulators just dont have the same appeal to me. On the point of a debugger, ive already got one for the actual sam, TurboMon, now who wrote that? :) (And yes its an original) A. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Winkless, Geoff Sent: 16 August 2002 09:37 To: 'sam-users@nvg.ntnu.no' Subject: RE: Linux Format What i bet it doesnt say is, if you really want to enjoy this machine - try and locate one on ebay :D Nothing beats the real thing. Actually I disagree. The emulator is now fast, accurate and featured enough that it's far easier to code than using the sam ever was. Using Comet in fast mode (at 300% or so) is absolutely marvellous. Once Si gets his real-time hardware debugger sorted things would become even easier. No searching for (or switching!) floppies, no problems with dodgy cables (I guess that was my fault rather than Sam's :) and in a window too, so I can have the z80 timing reference (it's been a while, ok? :) right next to the code screen. Geoff
RE: Linux Format
Adrian Brown wrote: I trust you have got the real thing as the rom is still copyrighted and hence the emulator is only legal to those with a sam). Not so - Andy Wright has given permission for the ROMs to be freely distributed with the emulator. I've also got a bunch of older ROMs (from Andy Wright via Simon Goodwin), and have permission to make those publically available. They're really just for historic interest/value, as the early ROMs are meant to be quite buggy. The very earliest also lack the BC bootup delay, which means they probably won't work on most SAMs (didn't on mine anyway, which is one pre-ordered before the release in 1989). On the point of a debugger, ive already got one for the actual sam, TurboMon, now who wrote that? :) That'll be me ;-D (And yes its an original) I made it freely available many years ago anyway, along with the source code and a Word document containing the docs. I did have it available on my old ISP homepage, but haven't got round to adding it to the new one yet... Si
RE: Linux Format
Nahhh, your missing the point. I know the emulator is basically perfect, but its just not like having the real thing sitting there (I trust you have got the real thing as the rom is still copyrighted and hence the emulator is only legal to those with a sam). IIRC Andy Wright has said the ROMs can be distributed. But yes, I was one of the first batch of Sam owners. Am I just mad, probably. Hehhh. Yep. On the point of a debugger, ive already got one for the actual sam, TurboMon, now who wrote that? :) (And yes its an original) *chuckles* there's nothing like a hardware debugger though. Some things just don't behave the same way when you have a debugger running. The overwhelming advantage of emualation for me is that I can have my spectrum, my Sam, my ST, my Amiga, my BBC and Archimedes, all of which I've owned at some point in time (although the Amiga and the ST were sold on) without needing the space or the acres worth of floppies/tapes. If I were single I'd probably have the house full of the originals. But I only have one room to set aside for tech stuff, which (when I have three PCs and a laptop (running as a 'net router) in about 8' by 5'), isn't really possible :) Geoff Need to buy a bigger house.
RE: Linux Format
Not so - Andy Wright has given permission for the ROMs to be freely distributed with the emulator. Yer, forgot about that - your reply bet mine :) I've also got a bunch of older ROMs (from Andy Wright via Simon Goodwin), and have permission to make those publically available. They're really just for historic interest/value, as the early ROMs are meant to be quite buggy. The very earliest also lack the BC bootup delay, which means they probably won't work on most SAMs (didn't on mine anyway, which is one pre-ordered before the release in 1989). Nice, these on a home page? That'll be me ;-D Yep, I know is freely downloadable, but its just not as fun as having the real thing now is it :) A.
Re: Linux Format
I made it freely available many years ago anyway, along with the source code and a Word document containing the docs. I did have it available on my old ISP homepage, but haven't got round to adding it to the new one yet... Si I'd been meaning to ask you about that Simon ... the docs that is, as I did remember you had them for download once - I could do with printing a new manual as the one I have here from when I bought it in 1994 from Steves Software is somewhat well thumbed and very tatty now! (Turbomon's been invaluable over the years!) Colin Quazar : Hardware, Software, Spares and Repairs for the Sam Out Now: Sam Revival magazine - Issue 1 Website: http://www.quazar.clara.net/sam/
RE: Linux Format
I know the need for a bigger house, im not single so my wife nags me about the number of old computers. Ive got Amigas, Sts (with mono monitor - that was hard to find), just about all the spectrums ever made, c64, PCs, megadrives, N64's, Snes, 2600's etc.etc.etc. But my Sam is still my favourite :) A. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Winkless, Geoff Sent: 16 August 2002 10:42 To: 'sam-users@nvg.ntnu.no' Subject: RE: Linux Format Nahhh, your missing the point. I know the emulator is basically perfect, but its just not like having the real thing sitting there (I trust you have got the real thing as the rom is still copyrighted and hence the emulator is only legal to those with a sam). IIRC Andy Wright has said the ROMs can be distributed. But yes, I was one of the first batch of Sam owners. Am I just mad, probably. Hehhh. Yep. On the point of a debugger, ive already got one for the actual sam, TurboMon, now who wrote that? :) (And yes its an original) *chuckles* there's nothing like a hardware debugger though. Some things just don't behave the same way when you have a debugger running. The overwhelming advantage of emualation for me is that I can have my spectrum, my Sam, my ST, my Amiga, my BBC and Archimedes, all of which I've owned at some point in time (although the Amiga and the ST were sold on) without needing the space or the acres worth of floppies/tapes. If I were single I'd probably have the house full of the originals. But I only have one room to set aside for tech stuff, which (when I have three PCs and a laptop (running as a 'net router) in about 8' by 5'), isn't really possible :) Geoff Need to buy a bigger house.
RE: Linux Format
The overwhelming advantage of emualation for me is that I can have my spectrum, my Sam, my ST, my Amiga, my BBC and Archimedes, all of which I've owned at some point in time (although the Amiga and the ST were sold on) without needing the space or the acres worth of floppies/tapes. Wow - you've found a decent Archimedes emulator? Where?
OT: Arch emulators (was RE: Linux Format)
Matthew Craven wrote: Wow - you've found a decent Archimedes emulator? Where? Red Squirrel ( http://www.redsquirrel.fsnet.co.uk ) works ok for me. It's not perfect, but it runs most things OK. Things it doesn't manage generally run with Archie (http://www.geocities.com/SiliconValley/Campus/5427/) but I have to get to DOS to run that. Geoff
Re: OT: Arch emulators (was RE: Linux Format)
If we're heading off topic anyway, I don't suppose if someone with the magazine could check quickly whether my small emulator, ElectrEm (it does the Acorn Electron) is in there? They don't seem to stock it at local newsagents, so I'm curious. -Thomas __ Check out all the latest outrageous email attachments on the Outrageous Email Chart! - http://viral.lycos.co.uk
RE: OT: Arch emulators (was RE: Linux Format)
Thomas Harte wrote: I don't suppose if someone with the magazine could check quickly whether my small emulator, ElectrEm (it does the Acorn Electron) is in there? The emulator articles (by Simon N Goodwin) have been running for around year I think, with the latest (and last?) covering more Z80-based machines. I'd imagine ElectrEm will be in one of the previous issues, along with BBC emulators, though I don't know exactly which issue (Tim?). The SAM piece started with a brief history, and had some kind words at the end, but mainly covered basic usage of the emulator - nothing fancy, but it was nice to have a mention. It was Simon N Goodwin's reminder about the up-coming article that prompted me to finish off the new GUI too! They don't seem to stock it at local newsagents, so I'm curious. Yeah, most newsagents I tried didn't have it, but I did find it in W.H.Smiths. I've wangled a subscription now, which certainly makes things easier! Si
Re: Linux Format
On Fri, 16 Aug 2002 10:56:14 +0100, Adrian Brown [EMAIL PROTECTED] wrote: I know the need for a bigger house, im not single so my wife nags me about the number of old computers. You could always get a smaller / more tolerant wife. :-)
Re: OT: Arch emulators (was RE: Linux Format)
- Original Message - From: Simon Owen [EMAIL PROTECTED] Thomas Harte wrote: I don't suppose if someone with the magazine could check quickly whether my small emulator, ElectrEm (it does the Acorn Electron) is in there? The emulator articles (by Simon N Goodwin) have been running for around year I think, with the latest (and last?) covering more Z80-based machines. I'd imagine ElectrEm will be in one of the previous issues, along with BBC emulators, though I don't know exactly which issue (Tim?). Acorns were covered in the March 2002 issue. ElectrEm got a mention, about a 1/6th ogf a page worht, although I can't spot it on the cover disk (unless it has a non-obvious name). The home page for it was included in the links sections at the end of the article though. Tim
RE: Linux Format
Colin Piggot wrote: I did remember you had them for download once - I could do with printing a new manual Here it is in RTF format: http://homepage.ntlworld.com/simon.owen/sam/TurboDOC.zip (62K) I could also do with converting the original .TD0 disk image of TurboMON (which also contains the source) to a more normal format for distribution. TurboMON has been freely distributable since about 1996, though the rights for the rest of the SC_Monitor Pro pack (which TurboMON was part of) remain with Steve's Software. Si
Re: Power Supply Pinout, Format, Floppy
Dnia 00-06-23 Jorge Canelhas pisze: thanks a lot for the awnser, made it work , pins 2 and 3 (purple and whit are connected togethe so my multimeter tells too These pins are connected together inside SAM. Hi, i tried to make a disk with fdformat and samdisk, it formats ok, and copies the image to the drive, but it returns an error No DOS when i try to boot !!! Try to run CPM22QED. 1. Go to http://nautilus.torch.net.pl/zxland/;. 2. Download file CPM22SAM.LHA. 3. Also pctools/LHA.EXE if you don't have one. 4. Unpack the CPM22SAM.LHA. - When LHA.EXE displays special attribute - use -a switch. - Unpacked file can be hidden. 5. Copy file CPM22SAM.108 to a recently formatted 720kB PC disk (this file _must_ be the first file on the disk). Stick the hole without slider at bottom side for HD floppy disk! 6. Boot your SAM Coupe from the PC disk. More details you can find in files archived in: http://nautilus.torch.net.pl/zxland/ZXVGSfaq.lha http://nautilus.torch.net.pl/zxland/ZXVGSdoc.lha You can format a SAMDOS similar disk under CPM22QED using: QFORMAT 0:SAMDOS /PCW82T If you own a Timex Floppy Disk Drive System, I have some stuff for you. I Got another question, a friend of mine has a sam without diskdrive , where can he get one or adapt a pcfloppy to the sam? You can take the controller from a Timex FDD 3000, that were produced in Portugal. The FDC 1770 has different hardware head step rates than FDC 1772-02, but this will work - SAMDOS uses software step rates and probably other systems, too. The FDD interface needs still 6 inverse OC gates (7406 or 7416, also LS or ALS will do) and a D latch (usually 74LS74). (Some more when as external must work with SAMBUS.) Plus 4 resistors 470om to 2kom. BTW I'm wonder if SAMDOS and MasterDOS would work correctly when two drives are connected to one controller with A4 address line as drive select and both /DISCn lines redirected to one chip... -- Yarek.
Re: Format
What about Sam Disk Image Manager, isn't it better now ? Yes it Loads and Saves SAM disks with Windows95/98. But as with SAMDISK.EXE you need a FORMATTED SAM disk (I didn't get my format code to work yet) Edwin Blink [EMAIL PROTECTED] http://www.designing.myweb.nl/samcoupe/index.htm
