From sam-users-owner@nvg.unit.no Tue Nov 1 07:20:31 1994 From: Johnathan Taylor Date: 01 Nov 94 04:09:00 +0000 Subject: Re: Hard Disc Message-Id: <98d_9411010659@centron.com> Organization: Centronics BBS To: Sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1484 Lines: 41 On <27 Oct 94 19:19> Briang@Bgserv.Demon.Co.Uk wrote: Br> What about something like ZCPR uses. Br> Jonathan, you out there? Br> Its been a while since I read up on it. Early ZCPR just used the standard CP/M2 format with easier access to the user areas, the later versions used the same logical layout but also had a lookup file that was used to convert the user numbers to more meaningfull text names. So really it's no better than cp/m filing system... MSX-DOS2 uses the FAT method with directories and 'handles' as opposed to cp/m fcb's and a pseudo cp/m like fcb interface to allow very well behaved generic cp/m1 & 2 utils to function eg the pmarc/ext suite or M80 etc... I've no idea if MSX-DOS2 was ever applied to an HD filesystem but it could be worth a look! Br> Are you thinking of partitions? Initially on the cp/m+ bios I'm not worrying about it to start with, BUT assuming Si can arrange a file system for sam-native mode and gets the drive partition table defined for that, then it'll be relativly simple to ask the hd-bios to reference that structure and not overwrite the native or unix partitions and reserve it's own partition or two... CP/M+ isn't fussy about sizes as it *can* handle multiple drives upto 512Meg each or smaller partitions if required:-) CYL. Johnathan ___ Olms 1.60 [Evaluation] -- |Fidonet: Johnathan Taylor 2:2501/307 |Internet: jet@centron.com | | Standard disclaimer: The views of this user are strictly his own. From sam-users-owner@nvg.unit.no Tue Nov 1 07:21:12 1994 From: Johnathan Taylor Date: 01 Nov 94 04:09:00 +0000 Subject: Re: Hard Disc Message-Id: <98f_9411010659@centron.com> Organization: Centronics BBS To: Sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2448 Lines: 66 On <31 Oct 94 10:32> Csl@Fs2.Ee.Umist.Ac.Uk wrote: >> What about something like ZCPR uses. >> Jonathan, you out there? >> Its been a while since I read up on it. >> >> Are you thinking of partitions? Cs> Yep, there will be a partitioning Cs> system set aside. I've got to talk Cs> to Jonathan or look up on CP/M Cs> partitioning, but it will use the Cs> standard MSDOS partition table to Cs> allocate space for CP/M partitions, Cs> MSDOS partitions, UNIX style Cs> partitions and E-DOS partitions (the new Cs> DOS I'm working on). CP/M does NOT define a partition table on the drive surface for public access like the MS-DOS definition BUT;-) CP/M+ sets a flag on the first bios disk select call to signal a clever bios to auto format detect. This feature can be used to cause a scan of the HD partition table to find its allocated dimensions and the appropriate DPB built and passed back to CP/M+ bdos as that drives spec and from then onwards it'll access JUST that allocation for that drive:-) Some cp/m HD systems partition the HD transparently to the bdos but that is the wrong way to do it as the 16bit reserved track field in the dpb is the official way to do it and the bdos respects that value and alters its track values accoridingly. The UZI file-system isn't quite so intelligent, well it's pd so what do you expect! But it can be MADE to abide by a readable map and translate it's requirments to a given physical partition:-) Cs> Current indications suggest that I Cs> should do a mixture of Unix and Cs> MSDOS, with a FAT Table and delocalised file information. You could *allow* say the last char of the file-name dir allocation to be used internally to signify the special file type to save accessing a file header to get the type in a dir or load attempt, much of the sam/mgt directory guff is to speed the dir/cat process and isn't used when actually LOAD'ing the file! It's a very wasteful way of managing drive space IMHO. Once you finalise the partition table Si please send me details so I can code around it to suit. At the moment I know nothing about the contents and location on the drive of the table, as yet I've no manuals at all on ms-dos and have built up this pc from common sense! Regards Johnathan. ___ Olms 1.60 [Evaluation] -- |Fidonet: Johnathan Taylor 2:2501/307 |Internet: jet@centron.com | | Standard disclaimer: The views of this user are strictly his own. From sam-users-owner@nvg.unit.no Tue Nov 1 07:21:13 1994 From: Johnathan Taylor Date: 01 Nov 94 04:09:00 +0000 Subject: @2:2501/102 Message-Id: <990_9411010659@centron.com> Organization: Centronics BBS To: Sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1182 Lines: 43 Subject: Re: big or small capacitors On <30 Oct 94 13:19> Ian.Collier@Comlab.Ox.Ac. wrote: Was Re: New SAM Coupe technical manual Ia> On Sat, 29 Oct 1994 11:02:47 +0100 Ia> (MET), Frode Tennebo said: >> ok.....220 000 mf then.... ;) Ia> Do you mean 220 000 mF or 220 000 uF? Ia> (i.e. 220 F or .220 F?) Ia> I think I once saw a 470 000 uF one, Ia> but the biggest I have at the moment is Ia> 4700 uF. Ia> imc I've got a pair of 210,000uF -10 +100% 10VDC a 15VDC 100,000MFD and a pair of 25VDC 75,000MFD which should really read uF but that's USA manufacturers for you, they all make a nice big *BANG* when shorted after a charge I did try using the 210,000uF one to maintain my sam during a short powerloss but any longer than about 0.5 second was too long for it... I eventually settled for 4 x 5AH cyclon sealed lead-acid cells;-) The largest value I've seen was 1Farad but that's just a cmos memory backup capacitor so it doesn't have the same umph of normal electrolytics. jet ___ Olms 1.60 [Evaluation] -- |Fidonet: Johnathan Taylor 2:2501/307 |Internet: jet@centron.com | | Standard disclaimer: The views of this user are strictly his own. From imc Tue Nov 1 11:59:15 1994 Subject: Re: Hard Drive standard file structure... To: sam-users@nvg.unit.no Date: Tue, 1 Nov 94 11:59:15 GMT In-Reply-To: <972_9410311918@centron.com>; from "Johnathan Taylor" at Oct 29, 94 9:18 pm X-Mailer: ELM [version 2.3 PL11] Status: RO Content-Length: 2286 Lines: 48 On 29 Oct 94 21:18:00 +0000, Johnathan Taylor said: > I've mentioned this elsewhere before... a small unix style pd filesystem is > available in C source form inside the UZI package on oak.oakland.edu It > doesn't use 32bit values just 16bit for speed and ease of z80 implementation > so each mounted logical drive is restricted to 32Meg in size. That is way too small. For a start, a lot of filing systems allocate disk space in blocks (usually of 1K, i.e. two sectors) which would raise the maximum size to 64M. For a second, some filing systems further combine several blocks into a zone. With 4K zones, the disk can be 256M in size. Using zones has the advantage that (a) larger disks can be addressed in 16 bits, and (b) files are recorded on the disk with more blocks close to each other for faster access. Of course it has a disadvantage too - the amount of space reserved for each file is a multiple of the zone size so that a few K can be wasted for each file (on the other hand, if the disk has size 256M, do we care about an average 2K per file waste?). > As we're dealing with a fixed drive we can theoretically do what ever we like > as it doesn't need to be compatable with ANY other platforms physical format.. It is easier, however, if you can re-use someone else's code... > partition large HD's it > smaller logical units, after all who needs to process more than 32Meg items on > a z80? It's not the size of one file that counts - it's the extra trouble of having to mess around with partitions. Not having to remember the drive letter for each file is a big plus for Unix IMHO. Also it would be silly to run out of space on one partition and have to start moving files here there and everywhere even though the disk is only 1/3 full. > Si> I'm currently thinking of 64 chars per > Si> directory entry, allowing 20 > Si> character (or so) filenames, with > Si> possibly a quick-to-access file system > Si> (ie one that is a combination of FAT and > Si> sector/head/track at the end of each > Si> logical sector (ala SAM)). Why have a limit on the length of a directory entry anyway? > 510byte sectors again Si!?! Makes for crappy random-access file performance! I agree with that. :-) imc From sam-users-owner@nvg.unit.no Tue Nov 1 12:00:08 1994 Message-Id: From: gaw-a@minster.york.ac.uk (Mars Bar) Date: Tue, 1 Nov 1994 09:00:14 +0000 In-Reply-To: briang -- "Re: Sam repairs test tools" (Oct 31, 6:22pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92 (ORBIT)) To: sam-users@nvg.unit.no Subject: Re: Sam repairs test tools Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 479 Lines: 13 On Oct 31, 6:22pm in "Re: Sam repairs test tools", you warbled: ] How about a Samplifier with internal Video only modulator? How about a bullet in the cranium? Instead, get Bob to modify the _original_. Either that, or buy a monitor :) :) BassKeepsThumpingPumpingJumpingBassKeepsThumpingPumpingJumpingBassKeepsThumping PumpingJumpingBassKeepsPumpingBassKeepsPumpingGimmeASmileForTheFutureAndIHeard ItOnTheRadioAndISawItOnTheTelevisionBackIn1988... gaw-a@minster.york.ac.uk From imc Tue Nov 1 12:04:36 1994 Subject: Re: Bob's amazing hard-drive plans... To: sam-users@nvg.unit.no Date: Tue, 1 Nov 94 12:04:36 GMT In-Reply-To: <975_9410311918@centron.com>; from "Johnathan Taylor" at Oct 29, 94 9:18 pm X-Mailer: ELM [version 2.3 PL11] Content-Length: 662 Lines: 16 On 29 Oct 94 21:18:00 +0000, Johnathan Taylor said: > N.> Umm, I think gzip will work on any > N.> file of any kind at all - to gzip it's > N.> all just bits and bytes, it doesn't > N.> care what it all means. > Spot on:-)That's its problem! IT is also its strength. There is nothing to stop you from adding a 16-byte header to each file before you compress it so that its file type and so on can be put back correctly when it is decompressed. Or you could completely ignore that and just compress an area of memory. For all I know, gzip could have an OS-dependent header in it anyway - it's some time since I read the file format documentation... imc From imc Tue Nov 1 12:23:51 1994 Subject: Compression To: sam-users@nvg.unit.no Date: Tue, 1 Nov 94 12:23:51 GMT In-Reply-To: <973_9410311918@centron.com>; from "Johnathan Taylor" at Oct 29, 94 9:18 pm X-Mailer: ELM [version 2.3 PL11] Content-Length: 2923 Lines: 61 On 29 Oct 94 21:18:00 +0000, Johnathan Taylor said: > You reckon? IF I were to want an archiver for Sam-native files I'd want it to > retain date-stamp, type, start address, load-page, true length, plus directory ^^^^^^^^^^ > info too like auto-run address and the various protection flags. Since when did a Sam-native file have a date stamp?... > Plus I'd want > to be able combine assosiated files into a single archive not a seperate > lose-able bunch of seperatly compressed files! Which is why you tar them up first (and there's no reason why it shouldn't be done in one go. But there is a reason why it should be done first rather than second, which is that doing it first gives better compression). Anyway, why is a single compressed file any more lose-able than any other kind of file? > LHarc format is a generic PD archive envelope definition that is supported > from CP/M, BBC-B, IBM-CLONE, QL, and generic unix! That still doesn't tell me what kind of compression it uses. > And the C source > is freely available if you bothered to look! I did bother to look, and all I found was some extremely poorly commented and undocumented source which was half in C and half in 8086 assembler. > Ia> there such a large variety of file > Ia> formats around > The reason is simple, copyright restrictions and ego:-( As for the former, gzip is not copyright and neither does it use any algorithm which has been patented. As for the latter, well I would consider it an achievement to write a useable compression program whose files are easily decoded using a common utility on a variety of different systems and which achieves an extremely high compression ratio. :-) > NO LHarc method beats the ZIP deflate alogarithm on achieved ratios. BUT they > ALL require much LESS working ram space to compress and de-compress The thing about gzip is that it uses very little RAM to decompress (apart from having to store each block of the file, which I would have thought was a necessity for most systems to be reasonably efficient). It is rather resource-consuming during compression, but then I probably don't care that much because it's the decompression that matters most. > Do you program in machine-code at the lowest level on the sam? Have you seen > and understood unix C source enough to port it to the SAM under any of the > current operating systems? Have you seen the source and understood the > functions&requirments of a minimal UNIX system? Yes to the first and the last one (depending on precisely what you mean by "the lowest level on the Sam"). You would have great difficulty in convincing me that it is possible to "port Unix C source to the Sam". Write a severely-cut-down version from scratch, maybe, but I'm not convinced of the benefits. imc From imc Tue Nov 1 12:28:01 1994 Subject: Re: big or small capacitors To: sam-users@nvg.unit.no Date: Tue, 1 Nov 94 12:28:01 GMT In-Reply-To: <990_9411010659@centron.com>; from "Johnathan Taylor" at Nov 1, 94 4:09 am X-Mailer: ELM [version 2.3 PL11] Content-Length: 528 Lines: 13 On 01 Nov 94 04:09:00 +0000, Johnathan Taylor said: > I did try using the 210,000uF one to maintain my sam during a short powerloss > but any longer than about 0.5 second was too long for it... I eventually > settled for 4 x 5AH cyclon sealed lead-acid cells;-) So how do you power the TV? :-) > The largest value I've seen was 1Farad but that's just a cmos memory backup > capacitor so it doesn't have the same umph of normal electrolytics. Oh yes, I've seen that in the Maplin catalogue. It's really rather small. imc From Frode.Tennebo@hiMolde.no Tue Nov 1 15:57:34 1994 From: Frode Tennebo Message-Id: <199411011555.AA10165@ulke.hiMolde.no> Subject: Re: New SAM Coupe technical manual To: Ian.Collier@uk.ac.oxford.comlab Date: Tue, 1 Nov 1994 16:55:20 +0100 (MET) Cc: sam-users@nvg.unit.no In-Reply-To: <9410301219.AA05871@boothp1.ecs.ox.ac.uk> from "Ian.Collier@comlab.ox.ac.uk" at Oct 30, 94 01:19:15 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Status: RO Content-Length: 608 Lines: 25 > > On Sat, 29 Oct 1994 11:02:47 +0100 (MET), Frode Tennebo said: > > > ok.....220 000 mf then.... ;) > > Do you mean 220 000 mF or 220 000 uF? (i.e. 220 F or .220 F?) mF - like in milli! > > I think I once saw a 470 000 uF one, but the biggest I have at the moment is > 4700 uF. I have here right in my very hand a 4700 mF. > > imc > -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Tue Nov 1 16:03:13 1994 From: Frode Tennebo Message-Id: <199411011558.AA10231@ulke.hiMolde.no> Subject: Re: Re: Bob's amazing hard-drive plans... To: Ian.Collier@uk.ac.oxford.comlab Date: Tue, 1 Nov 1994 16:58:52 +0100 (MET) Cc: sam-users@nvg.unit.no In-Reply-To: <9410301214.AA05853@boothp1.ecs.ox.ac.uk> from "Ian.Collier@comlab.ox.ac.uk" at Oct 30, 94 01:14:55 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1048 Lines: 32 > > On Sat, 29 Oct 1994 10:59:05 +0100 (MET), Frode Tennebo said: > > I was working on a gzip-like (using LWZ compression) compressor/decompressor, > > but due to lack of time I never finished them. > > Just a small question... isn't the LZW algorithm (as used in Unix > "compress") patented? The documentation for gzip says so. Actually the gzip uses LZ77. Whether the LZW is patented or not, I really don't know. If it is, so what? ;) > > > > Sorry, but if I want a useable Unix system I'll buy a 486 or a 68040... > > > I think I'd buy a Pentium or a DEC AIX/OSF........... > > I'm talking about things I could afford. Otherwise I'd have a sparc or an > SGI... Yeah yeah....a Pentium isn't all that expenive. You just need a lot of RAM and THAT's ekspensive. > > imc > -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Tue Nov 1 16:09:50 1994 From: Frode Tennebo Message-Id: <199411011604.AA10346@ulke.hiMolde.no> Subject: Re: Re: Bob's amazing hard-drive plans... To: Ian.Collier@uk.ac.oxford.comlab Date: Tue, 1 Nov 1994 17:04:54 +0100 (MET) Cc: sam-users@nvg.unit.no In-Reply-To: <9410301221.AA05887@boothp1.ecs.ox.ac.uk> from "Ian.Collier@comlab.ox.ac.uk" at Oct 30, 94 01:21:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 755 Lines: 27 > > On Sat, 29 Oct 1994 11:08:08 +0100 (MET), Frode Tennebo said: > > tar has the option -z witch makes it much more useable.... > > Would you care to describe what that does for those of us for which tar -z > says > > tar: z: unknown option > tar: usage: tar -{ctxru}[vfblmhopwBiX] [tapefile] [blocksize] file1 file2... -Z, --compress, --uncompress filter the archive through compress -z, --gzip, --ungzip filter the archive through gzip > > ? > > imc > -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Tue Nov 1 16:38:29 1994 From: Frode Tennebo Message-Id: <199411011633.AA10829@ulke.hiMolde.no> Subject: Re: Sam repairs test tools To: sam-users@nvg.unit.no Date: Tue, 1 Nov 1994 17:33:08 +0100 (MET) In-Reply-To: <2EB57297@courier.lmu.ac.uk> from "Doore, Daniel [MIS]" at Oct 31, 94 01:39:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1373 Lines: 47 > > > > ---------- > > From: sam-users-owner > > To: sam-users > > Subject: Re: Sam repairs test tools > > Date: 31 October 1994 14:32 What is this doing there???? > > > > On Mon, 31 Oct 94 11:10:00 PST, Doore, Daniel [MIS] said: > > > > I thought the Speccy's TR4/TR5 (or whatever) circuit had already shown > > > > what a wonderful idea this is, and it was a shame that Amstrad thought > > > > better of it and released a +3 with the 12V coming from the power > supply > > > > instead... :-J > > > > > How many speccys had two drives, a comms and mouse I/F running off > > > that? I don't like the sound of all that coming of a single 5V supply. > > > > Let me just get this straight... you didn't think I was being serious, > did > > you? > > 'Fraid so, irony and satire do not translate well without certain qualifiers > (like the infamous ) and since I have not met the ' :-J ' - for all > I know it could be a quote from Jeramy Beadle..... > > Being your average nerk, how am I supposed to know? I did...and I don't even have it as my mothers tounge! :) > > Dan. > > > imc > > > -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Tue Nov 1 16:59:33 1994 From: "Doore, Daniel [MIS]" To: Sam Users Subject: Re: Sam repairs test tools Date: Tue, 01 Nov 94 16:43:00 PST Message-Id: <2EB6E07A@courier.lmu.ac.uk> Encoding: 52 TEXT X-Mailer: Microsoft Mail V3.0 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1368 Lines: 52 -- > > ---------- > > > From: sam-users-owner > > > To: sam-users > > > Subject: Re: Sam repairs test tools > > > Date: 31 October 1994 14:32 > > What is this doing there???? This is the crap that Microsoft Mail (in its wisdom) sticks on the front of mail when it is replied to. It's got to the stage that I cannot be bothered to strip it off . > > > > > > On Mon, 31 Oct 94 11:10:00 PST, Doore, Daniel [MIS] said: > > > > > I thought the Speccy's TR4/TR5 (or whatever) circuit had already shown > > > > > what a wonderful idea this is, and it was a shame that Amstrad thought > > > > > better of it and released a +3 with the 12V coming from the power > > supply > > > > > instead... :-J > > > > > > > How many speccys had two drives, a comms and mouse I/F running off > > > > that? I don't like the sound of all that coming of a single 5V supply. > > > > > > Let me just get this straight... you didn't think I was being serious, > > did > > > you? > > > > 'Fraid so, irony and satire do not translate well without certain qualifiers > > (like the infamous ) and since I have not met the ' :-J ' - for all > > I know it could be a quote from Jeramy Beadle..... > > > > Being your average nerk, how am I supposed to know? > > I did...and I don't even have it as my mothers tounge! :) I'm still green to the net business. Lay off :-( Dan. > From sam-users-owner@nvg.unit.no Tue Nov 1 17:05:04 1994 From: Frode Tennebo Message-Id: <199411011654.AA11123@ulke.hiMolde.no> Subject: Re: Sam repairs test tools To: sam-users@nvg.unit.no Date: Tue, 1 Nov 1994 17:54:54 +0100 (MET) In-Reply-To: <4459@bgserv.demon.co.uk> from "briang@bgserv.demon.co.uk" at Oct 31, 94 06:20:01 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 592 Lines: 23 > > I THINK I have talked Bob out of the 5V supply only thing. > Fingers crossed... Mine too! Perhaps ramp up them amp to? Good work there! > > Brian > > -- > briang@bgserv.demon.co.uk - Email for Speccy membranes > Brian Gaff is B G Services - UK support for 'Z80' > The Spectrum Emulator > -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Tue Nov 1 17:10:59 1994 Date: Tue, 01 Nov 1994 16:42:58 GMT From: briang@bgserv.demon.co.uk (briang@bgserv.demon.co.uk) Message-Id: <4523@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: Sam repairs test tools X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1053 Lines: 29 In message Mars Bar writes: > On Oct 31, 6:22pm in "Re: Sam repairs test tools", you warbled: > ] How about a Samplifier with internal Video only modulator? > > How about a bullet in the cranium? Do you know what the SAM PSU REALLY is? Its an Amstrad CPC cast off. I KNOW this. I was in at the start, its several grand of my money, so don't be so rude! :-) > > Instead, get Bob to modify the _original_. > Ha ha ha.... > Either that, or buy a monitor :) :) > Good udea, got some going ceap? > BassKeepsThumpingPumpingJumpingBassKeepsThumpingPumpingJumpingBassKeepsThumping > PumpingJumpingBassKeepsPumpingBassKeepsPumpingGimmeASmileForTheFutureAndIHeard > ItOnTheRadioAndISawItOnTheTelevisionBackIn1988... gaw-a@minster.york.ac.uk > Cut the key crap, a waste of bandwidth Brian (please do not flame via the list) -- briang@bgserv.demon.co.uk - Email for Speccy membranes Brian Gaff is B G Services - UK support for 'Z80' The Spectrum Emulator From sam-users-owner@nvg.unit.no Tue Nov 1 17:11:46 1994 Date: Tue, 01 Nov 1994 16:48:34 GMT From: briang@bgserv.demon.co.uk (briang@bgserv.demon.co.uk) Message-Id: <4525@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: Compression X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 551 Lines: 15 In message <9411011223.AA16635@boothp1.ecs.ox.ac.uk> Ian.Collier@comlab.ox.ac.uk writes: > On 29 Oct 94 21:18:00 +0000, Johnathan Taylor said: > > You reckon? IF I were to want an archiver for Sam-native files I'd want it to > > retain date-stamp, type, start address, load-page, true length, plus directory > ^^^^^^^^^^ > > info too like auto-run address and the various protection flags. > > Since when did a Sam-native file have a date stamp?... Nine datestamps fine via Masterdos. There is a real time clock in the Sambus. > Brian From sam-users-owner@nvg.unit.no Tue Nov 1 18:57:49 1994 Message-Id: From: simonc@jumper.mcc.ac.uk (Simon Cooke) Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Tue, 1 Nov 1994 18:51:30 +0000 (GMT) Cc: simonc@jumper.mcc.ac.uk (Simon Cooke) In-Reply-To: <973_9410311918@centron.com> from "Johnathan Taylor" at Oct 29, 94 09:18:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2193 Lines: 54 > I dunno this UNIX on a SAM part of this thread smacks of those readers letters > in format where a READER says that somthing should be done for the SAM and Bob > then goes on to trash the feasable request as invalid or stupid.... eg HD's, > Archivers, COMMS etc etc... > > Or when I suggested that Interupt driven RS232 is possible on the sam everyone > I spoke to in the SAM scene said it couldn't be done! Now I've been using it > RELIABLY for over a year daily! ALL my OWN work! Heheheheh... I know what you mean. When I published how to do it (found out using my own poke-arounds inside the interface) in Your Sinclair, Andy Wright and Simon Goodwin insisted that I was wrong.. Then I told them exactly what to do and they conceded :) Yep, it works. Damn well too -- except when the screen scrolls, it takes *ages* but a 2k ring buffer sorts that out and keeps things flowing nicely at 38400 baud :) > Hmmm has Bob joined this group using Ians FQDN as an alias? *rotfls* > Ian just WHAT do you use (or want to use) your sam for? > > Do you program in machine-code at the lowest level on the sam? Have you seen > and understood unix C source enough to port it to the SAM under any of the > current operating systems? Have you seen the source and understood the > functions&requirments of a minimal UNIX system? > > If no then to at least 2 out of 3 of those last questions then please stop > saying that it can't be done as your not qualified to judge its viability, > sorry. *ouch ouch!* Ian doesn't have a SAM actually, if what I've been told is correct... > To be honest when I do eventually write any multi-tasking operating systems > for MY sam (either unix based or a cp/m+ extension), it'll be for my needs not > yours and as I've said before I doubt it'll ever be run on anyone elses SAM > mainly because, currently NO other sam can run everything mine can due to lack > of data-bus buffering, I don't do user manuals and it'll require more > inteligence than the average home-computer user to use it as with any non-gui > unix system! It'd work on my and Martin Rookyard's systems.... but then, we're just obtuse :) > CYL. > Johnathan. Si Cooke From sam-users-owner@nvg.unit.no Tue Nov 1 19:18:09 1994 From: Frode Tennebo Message-Id: <199411011912.AA14551@ulke.hiMolde.no> Subject: Re: Hard Drive standard file structure... To: sam-users@nvg.unit.no Date: Tue, 1 Nov 1994 20:12:39 +0100 (MET) In-Reply-To: <9411011159.AA15840@boothp1.ecs.ox.ac.uk> from "Ian.Collier@comlab.ox.ac.uk" at Nov 1, 94 12:59:15 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 983 Lines: 22 > It is easier, however, if you can re-use someone else's code... > > > partition large HD's it > > smaller logical units, after all who needs to process more than 32Meg items on > > a z80? > > It's not the size of one file that counts - it's the extra trouble of > having to mess around with partitions. Not having to remember the drive > letter for each file is a big plus for Unix IMHO. Also it would be silly > to run out of space on one partition and have to start moving files here > there and everywhere even though the disk is only 1/3 full. UNIX also has partitions too you know, so does VMS, but they have handled those in completely different ways. > imc -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Tue Nov 1 19:37:57 1994 From: Frode Tennebo Message-Id: <199411011932.AA14724@ulke.hiMolde.no> Subject: Re: Compression To: sam-users@nvg.unit.no Date: Tue, 1 Nov 1994 20:32:55 +0100 (MET) In-Reply-To: <9411011223.AA16635@boothp1.ecs.ox.ac.uk> from "Ian.Collier@comlab.ox.ac.uk" at Nov 1, 94 01:23:52 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1491 Lines: 35 > Which is why you tar them up first (and there's no reason why it shouldn't > be done in one go. But there is a reason why it should be done first > rather than second, which is that doing it first gives better compression). > Anyway, why is a single compressed file any more lose-able than any other > kind of file? > > > LHarc format is a generic PD archive envelope definition that is supported > > from CP/M, BBC-B, IBM-CLONE, QL, and generic unix! > > That still doesn't tell me what kind of compression it uses. LZH.... > > NO LHarc method beats the ZIP deflate alogarithm on achieved ratios. BUT they > > ALL require much LESS working ram space to compress and de-compress > > The thing about gzip is that it uses very little RAM to decompress (apart > from having to store each block of the file, which I would have thought > was a necessity for most systems to be reasonably efficient). It is rather > resource-consuming during compression, but then I probably don't care that > much because it's the decompression that matters most. It does? It produces exactly the same table for decompression as for compression, otherwise it wouldn't be able to decompress...or?! Hmm... can't remember much now. > imc > -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From imc Wed Nov 2 10:45:23 1994 Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Wed, 2 Nov 94 10:45:23 GMT In-Reply-To: ; from "Simon Cooke" at Nov 1, 94 6:51 pm X-Mailer: ELM [version 2.3 PL11] Content-Length: 227 Lines: 8 On Tue, 1 Nov 1994 18:51:30 +0000 (GMT), Simon Cooke said: > Ian doesn't have a SAM actually, if what I've been told is correct... Shhh... I was keeping that quiet. ;-) Anyway, I do now. It arrived this morning. :-) imc From imc Wed Nov 2 10:47:56 1994 Subject: Re: Hard Drive standard file structure... To: sam-users@nvg.unit.no Date: Wed, 2 Nov 94 10:47:56 GMT In-Reply-To: <199411011912.AA14551@ulke.hiMolde.no>; from "Frode Tennebo" at Nov 1, 94 8:12 pm X-Mailer: ELM [version 2.3 PL11] Content-Length: 245 Lines: 7 On Tue, 1 Nov 1994 20:12:39 +0100 (MET), Frode Tennebo said: > UNIX also has partitions too you know, so does VMS, but they have > handled those in completely different ways. Yes I know, but have you seen the size of a Unix partition? :-) imc From imc Wed Nov 2 10:54:02 1994 Subject: Re: Compression To: sam-users@nvg.unit.no Date: Wed, 2 Nov 94 10:54:02 GMT In-Reply-To: <199411011932.AA14724@ulke.hiMolde.no>; from "Frode Tennebo" at Nov 1, 94 8:32 pm X-Mailer: ELM [version 2.3 PL11] Content-Length: 992 Lines: 23 On Tue, 1 Nov 1994 20:32:55 +0100 (MET), Frode Tennebo said: > > That still doesn't tell me what kind of compression it uses. > LZH.... I just know you are going to tell me to look it up in a library, but LZH means almost nothing to me. > > The thing about gzip is that it uses very little RAM to decompress > It does? It produces exactly the same table for decompression as for > compression, otherwise it wouldn't be able to decompress...or?! Hmm... > can't remember much now. I think you are thinking of LZW (which seems to require massive amounts of RAM both to compress and to decompresS). gzip uses LZ77, which only requires a Huffman table (which is quite small actually) to decompress, apart from the fact that it needs to be able to copy strings from earlier in the decompressed file and therefore needs to be able to store the decompressed file in memory (or at least each compressed block of it). imc (see, I can use random sequences of characters starting with LZ too...) From sam-users-owner@nvg.unit.no Wed Nov 2 11:02:52 1994 From: Simon Cooke To: Johnathan Taylor , sam-users@nvg.unit.no Date: Wed, 2 Nov 1994 11:58:21 GMT Subject: Re: Hard Disc Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <37584657E25@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1229 Lines: 26 > You could *allow* say the last char of the file-name dir allocation to be used > internally to signify the special file type to save accessing a file header to > get the type in a dir or load attempt, much of the sam/mgt directory guff is > to speed the dir/cat process and isn't used when actually LOAD'ing the file! > It's a very wasteful way of managing drive space IMHO. Well, the info I'm thinking of storing in the directory (there will be 64 characters per file per entry btw) is a 32 character max filename, filetype byte (0 = msdos style, others as SAM up to 23, then the new EDOS ones come into play, such as SAM Disk images etc), file status byte (system, hidden, read only, directory etc), then the file start address, file length, file execute address. This is for Directory purposes only -- no more information is needed. > Once you finalise the partition table Si please send me details so I can code > around it to suit. Okeydokey :) > At the moment I know nothing about the contents and location on the drive of > the table, as yet I've no manuals at all on ms-dos and have built up this pc > from common sense! Will do -- I'll try and get it down on paper today and post it here. Si Cooke From sam-users-owner@nvg.unit.no Wed Nov 2 11:09:05 1994 From: Simon Cooke To: Johnathan Taylor , sam-users@nvg.unit.no Date: Wed, 2 Nov 1994 12:03:14 GMT Subject: Re: @2:2501/102 Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <37599870B6E@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2577 Lines: 52 > The ONLY thing I'd like to see on ALL the various file-systems is the facility > to Partition a BIG HD so we can run the several different types of file system > on the same HD, eg. CP/M defines in it,s DPB a reserved number of tracks as a > 16bit value so it can be placed virtually anywhere on a large HD and take up > as much space as defined in the dsm field... Any unix style system should also > be made to do this as well IMHO:-) > I've mentioned this elsewhere before... a small unix style pd filesystem is > available in C source form inside the UZI package on oak.oakland.edu It > doesn't use 32bit values just 16bit for speed and ease of z80 implementation > so each mounted logical drive is restricted to 32Meg in size. > > With some extensive editing it'll probably even compile under small-C v2! > though I think the resultant assembler source would need extensive > hand-optimisation as Small-C is not a very clever code generator;-) Brilliant! Should be good :) > As we're dealing with a fixed drive we can theoretically do what ever we like > as it doesn't need to be compatable with ANY other platforms physical format.. > So just use the good features of the various systems, make the nesesary > comporimises needed to allow acceptable performance on a z80 machine ie if > 32bit values slow it down use 16bit pointers and partition large HD's it > smaller logical units, after all who needs to process more than 32Meg items on > a z80? Hmmmmm... not sure. The 32bit values will perform pretty much no slow down if done right -- the drive itself will take the most time. > Si> I'm currently thinking of 64 chars per > Si> directory entry, allowing 20 > Si> character (or so) filenames, with > Si> possibly a quick-to-access file system > Si> (ie one that is a combination of FAT and > Si> sector/head/track at the end of each > Si> logical sector (ala SAM)). > > 510byte sectors again Si!?! Makes for crappy random-access file performance! > ProDos random access is much better than master-dos, not that I'd suggest > doing a CP/M style directory structure... I've noticed on this pc1512 running > pcrr1.60a olr that it is damned sloooow at random-reading the prior message > don't know if that's an MS-DOS problem or somthing to do with the MS-DOS TP > runtime package... > > Plus 510 byte isn't binary maths friendly but 512 is, obviously;-) Okay, agreed -- I won't use 510 byte sectors, 512 it is. Now the question is: In our FAT do we want a way of searching along the chain as well as forwards? Si Cooke From sam-users-owner@nvg.unit.no Wed Nov 2 11:09:31 1994 From: Simon Cooke To: Ian.Collier@uk.ac.oxford.comlab, sam-users@nvg.unit.no Date: Wed, 2 Nov 1994 12:08:14 GMT Subject: Re: Hard Drive standard file structure... Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <375AEA3252B@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3337 Lines: 74 > That is way too small. For a start, a lot of filing systems allocate disk > space in blocks (usually of 1K, i.e. two sectors) which would raise the > maximum size to 64M. For a second, some filing systems further combine > several blocks into a zone. With 4K zones, the disk can be 256M in size. > Using zones has the advantage that (a) larger disks can be addressed in 16 > bits, and (b) files are recorded on the disk with more blocks close to each > other for faster access. Of course it has a disadvantage too - the amount > of space reserved for each file is a multiple of the zone size so that a > few K can be wasted for each file (on the other hand, if the disk has size > 256M, do we care about an average 2K per file waste?). Better not tell Bob then -- he wants drives less than 40Mb, or so it appears :) > > As we're dealing with a fixed drive we can theoretically do what ever we like > > as it doesn't need to be compatable with ANY other platforms physical format.. > > It is easier, however, if you can re-use someone else's code... Nope - not really. DOS evolved and evolved and it's so clunky it's unbelievable. And have *you* tried to get the Docs on the low level side of the HPFS used in OS/2? It's unbloodybelievably hard. I spent a good few months tracking down the ATA standard actually (IDE design specifications). For those who want it, btw, it's in ftp.dec.com, pub/standards/ata :) They've also got ata2, scsi1,2 and3 and a few more... > > partition large HD's it > > smaller logical units, after all who needs to process more than 32Meg items on > > a z80? > > It's not the size of one file that counts - it's the extra trouble of > having to mess around with partitions. Not having to remember the drive > letter for each file is a big plus for Unix IMHO. Also it would be silly > to run out of space on one partition and have to start moving files here > there and everywhere even though the disk is only 1/3 full. I'm considering allowing a linked-partition system, but not sure about how it'd perform speed-wise. Basically you can define two E-DOS partitions and link the data space together to form one big partition. It *may* work -- gotta look into it more. > > Si> I'm currently thinking of 64 chars per > > Si> directory entry, allowing 20 > > Si> character (or so) filenames, with > > Si> possibly a quick-to-access file system > > Si> (ie one that is a combination of FAT and > > Si> sector/head/track at the end of each > > Si> logical sector (ala SAM)). > > Why have a limit on the length of a directory entry anyway? Because it makes for easy and quick directory access without having to resort to a round-robin linked node structure, which I hate because it fragments the data area something rotten. > > 510byte sectors again Si!?! Makes for crappy random-access file performance! > > I agree with that. :-) Okay, that idea is now ditched. I'm considering using the logical-sector access mode of the IDE drive to store all stuff -- other people for other partitions can use the sector/cylinder/head method if they want :) This should speed up access -- you just take the sector number in the partition, add it to the logical start of the partition and read / write... quick 'n' easy :) Si From sam-users-owner@nvg.unit.no Wed Nov 2 11:11:01 1994 From: Simon Cooke To: sam-users@nvg.unit.no Date: Wed, 2 Nov 1994 12:12:49 GMT Subject: Current SAM Coupe port allocations, etc. Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <375C25A1B12@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 30995 Lines: 783 This will also be posted as a UUENCODED file, as it should be displayed on an 80character wide screen! Notice: Due to the inaction of the current developers of the SAM Coupe, Entropy are now the official port allocators for SAM hardware. Or so it seems :) (We've had enough people ask us which ports we can use, anyway :) ) Email: simonc@jumper.mcc.ac.uk (simon cooke) entropy@jumper.mcc.ac.uk (Entropy) rooksoft@jumper.mcc.ac.uk (Rooksoft) Phone: 01942 886084 Snailmail: 1 Dovey Close, Astley, Tyldesley, Manchester, M29 7NP, UK 18 Braemar Drive, Sale, Cheshire, M33 4NJ, UK General port map - Read ----------------------- +---------------------------------------------------------------- --+ |PORT (RD)|128--7| 64--6| 32--5| 16--4| 8--3| 4--2| 2--1| 1- -0| +----+----------+------+------+------+------+------+------+------+---- --+---+ | FF|ATTRIBUTES|FLASH |BRIGHT|G PAPR|R PAPR|B PAPR|G INK|R INK|B INK|255| |----+----------+------+------+------+------+------+------+------+---- --+---| | FE|KEYBOARD |SOFF |EAR |SPEN |KEY 5|KEY 4|KEY 3|KEY 2|KEY 1|254| |----+----------+------+------+------+------+------+------+------+---- --+---| |FFFE|RDMSEL |SOFF |EAR |SPEN |RIGHT |LEFT |DOWN |UP |CNTRL |254| |----+----------+----------------------------------------------------- --+---| | FD|MIDI-IN | 8 BITS DATA |253| |----+----------+----------------------------------------------------- --+---| | FC|VMPR |RXMIDI|MODE 1|MODE 0|PAGE 4|PAGE 3|PAGE 2|PAGE 1|PAGE 0|252| |----+----------+------+------+------+------+------+------+------+---- --+---| | FB|HMPR |MCNTRL|MD3 S1|MD3 S0|PAGE 4|PAGE 3|PAGE 2|PAGE 1|PAGE 0|251| |----+----------+------+------+------+------+------+------+------+---- --+---| | FA|LMPR |WPROT |ROM 1|RAM 0|PAGE 4|PAGE 3|PAGE 2|PAGE 1|PAGE 0|250| |----+----------+------+------+------+------+------+------+------+---- --+---| | F9|STATUS |KEY 8|KEY 7|KEY 6|MIDI O|FRAME |MIDI I|COMMS |LINE |249| |----+----------+----------------------------------------------------- --+---| |01F8|HPEN | CURRENT YSCAN VALUE |248| |----+----------+----------------------------------------------------- --| | |00F8|LPEN | CURRENT XSCAN VALUE DIV 4 |TXFMST|BLUE 0| | |----+----------+----------------------------------------------------- --+---| | F0|DISC 2 | DRIVE 2 BASE PORT - SEE BELOW |240| |----+----------+----------------------------------------------------- --+---| | EF|SAMBUS CLK| BATTERY BACKED REALTIME CLOCK - SEE BELOW |239| |----+----------+----------------------------------------------------- --+---| | EC|COMMS IFC | COMMS I/FACE SERIAL CHIP (IM26C91) -- SEE BELOW |236| |----+----------+----------------------------------------------------- --+---| | E9|PTR STATUS| | | | | | | |BUSY |233| |----+----------+----------------------------------------------------- --+---| | E0|DISC 1 | DRIVE 1 BASE PORT - SEE BELOW |224| |----+----------+----------------------------------------------------- --+---| | DF|MULTIROM D|MR_OFF|MR_RAM|PAGE 5|PAGE 4|PAGE 3|PAGE 2|PAGE 1|PAGE 0|223| |----+----------+------+------+------+------+------+------+------+---- --+---| | DE|MULTIROM A|MR_OFF|MR_RAM|PAGE 5|PAGE 4|PAGE 3|PAGE 2|PAGE 1|PAGE 0|222| |----+----------+----------------------------------------------------- --+---| | D0|ENTROPY | ENTROPY PORTS ALLOCATED -- PORTS &xxD0 TO &xxDF |208| |----+----------+----------------------------------------------------- --+---| | 7F|BLUE ALPHA| BLUE ALPHA PORTS ALLOCATED -- PORTS &007F TO &FF7F |127| +--------------------------------------------------------------------- ------+ General port map - Write ------------------------ +---------------------------------------------------------------- --+ |PORT (WR)|128--7| 64--6| 32--5| 16--4| 8--3| 4--2| 2--1| 1- -0| +----+----------+------+------+------+------+------+------+------+---- --+---+ |01FF|SOUND ADDR| | | |ADDR 4|ADDR 3|ADDR 2|ADDR 1|ADDR 0|255| |----+----------+----------------------------------------------------- --| | |00FF|SOUND DATA| 8 BITS DATA | | |----+----------+----------------------------------------------------- --+---| | FE|BORDER |SOFF |THROM |VID&08|BEEP |MIC |VID&04|VID&02|VID&01|254| |----+----------+----------------------------------------------------- --+---| | FD|MIDI-OUT | 8 BITS DATA |253| |----+----------+----------------------------------------------------- --+---| | FC|VMPR |TXMIDI|MODE 1|MODE 0|PAGE 4|PAGE 3|PAGE 2|PAGE 1|PAGE 0|252| |----+----------+------+------+------+------+------+------+------+---- --+---| | FB|HMPR |MCNTRL|MD3 S1|MD3 S0|PAGE 4|PAGE 3|PAGE 2|PAGE 1|PAGE 0|251| |----+----------+------+------+------+------+------+------+------+---- --+---| | FA|LMPR |WPROT |ROM 1|RAM 0|PAGE 4|PAGE 3|PAGE 2|PAGE 1|PAGE 0|250| |----+----------+----------------------------------------------------- --+---| | F9|LINE INT | YSCAN LINE TO INTERRUPT ON |249| |----+----------+----------------------------------------------------- --+---| | F8|CLUT | |GRN 1|RED 1|BLU 1|HALFBR|GRN 0|RED 0|BLU 0|248| |----+----------+----------------------------------------------------- --+---| | F0|DISC 2 | DRIVE 2 BASE PORT - SEE BELOW |240| |----+----------+----------------------------------------------------- --+---| | EF|SAMBUS CLK| BATTERY BACKED REALTIME CLOCK - SEE BELOW |239| |----+----------+----------------------------------------------------- --+---| | EE|ACCELERATR| |CLKSPD|IORQW |ASWAIT|BANK D|BANK C|BANK B|BANK A|238| |----+----------+----------------------------------------------------- --+---| | EC|COMMS IFC | COMMS I/FACE SERIAL CHIP (IM26C91) -- SEE BELOW |236| |----+----------+----------------------------------------------------- --+---| | E9|PTR CTRL | | | | | | | |STROBE|233| |----+----------+----------------------------------------------------- --+---| | E8|PTR DATA | 8 BITS DATA |233| |----+----------+----------------------------------------------------- --+---| | E0|DISC 1 | DRIVE 1 BASE PORT - SEE BELOW |224| |----+----------+----------------------------------------------------- --+---| | DF|MULTIROM D|MR_OFF|MR_RAM|PAGE 5|PAGE 4|PAGE 3|PAGE 2|PAGE 1|PAGE 0|223| |----+----------+------+------+------+------+------+------+------+---- --+---| | DE|MULTIROM A|MR_OFF|MR_RAM|PAGE 5|PAGE 4|PAGE 3|PAGE 2|PAGE 1|PAGE 0|222| |----+----------+----------------------------------------------------- --+---| | D0|ENTROPY | ENTROPY PORTS ALLOCATED -- PORTS &xxD0 TO &xxDF |208| |----+----------+----------------------------------------------------- --+---| | 83|MEGHIGH D|PAGE15|PAGE14|PAGE13|PAGE12|PAGE11|PAGE10|PAGE 9|PAGE 8|131| |----+----------+------+------+------+------+------+------+------+---- --+---| | 82|MEGHIGH C|PAGE15|PAGE14|PAGE13|PAGE12|PAGE11|PAGE10|PAGE 9|PAGE 8|130| |----+----------+------+------+------+------+------+------+------+---- --+---| | 81|MEGLOW D|PAGE 7|PAGE 6|PAGE 5|PAGE 4|PAGE 3|PAGE 2|PAGE 1|PAGE 0|129| |----+----------+------+------+------+------+------+------+------+---- --+---| | 80|MEGLOW C|PAGE 7|PAGE 6|PAGE 5|PAGE 4|PAGE 3|PAGE 2|PAGE 1|PAGE 0|128| |----+----------+----------------------------------------------------- --+---| | 7F|BLUE ALPHA| BLUE ALPHA PORTS ALLOCATED -- PORTS &007F TO &FF7F |127| +--------------------------------------------------------------------- ------+ Keyboard matrix / port allocations ---------------------------------- +-----------------------------------------------+ | 7 | 6 | 5 | BASE PORT &F9/249 | +-----------+-----------------+-----------------------------| |ADRSELECTOR|BASE PORT &FE/254| 4 | 3 | 2 | 1 | 0 | |-----------+-----------------+-----+-----+-----+-----+-----| |11111110|FE| F 3 | F 2 | F 1 | V | C | X | Z |SHIFT| |--------+--+-----+-----+-----+-----+-----+-----+-----+-----| |11111101|FD| F 6 | F 5 | F 4 | G | F | D | S | A | |--------+--+-----+-----+-----+-----+-----+-----+-----+-----| |11111011|FB| F 9 | F 8 | F 7 | T | R | E | W | Q | |--------+--+-----+-----+-----+-----+-----+-----+-----+-----| |11110111|F7| CAPS| TAB | ESC | 5 | 4 | 3 | 2 | 1 | |--------+--+-----+-----+-----+-----+-----+-----+-----+-----| |11101111|EF|DELET| + | - | 6 | 7 | 8 | 9 | 0 | |--------+--+-----+-----+-----+-----+-----+-----+-----+-----| |11011111|DF| F 0 | " | = | Y | U | I | O | P | |--------+--+-----+-----+-----+-----+-----+-----+-----+-----| |10111111|C0| EDIT| : | ; | H | J | K | L |RETRN| |--------+--+-----+-----+-----+-----+-----+-----+-----+-----| |01111111|7F| INV | . | , | B | N | M | SYM |SPACE| |--------+--+-----+-----+-----+-----+-----+-----+-----+-----| |11111111|FF| | | |RIGHT| LEFT| UP| DOWN|CNTRL| +-----------------------------------------------------------+ Disc controller port allocations -------------------------------- +-----------------------------------------------+ | SIDE1 | DISC CONTROLLER | SIDE2 | |-------------+-------------------+-------------| |DISC 1|DISC 2| READ | WRITE |DISC 1|DISC 2| |------+------+---------+---------+------+------| | E0 | F0 | STATUS | COMMAND | E4 | F4 | |------+------+---------+---------+------+------| | E1 | F1 | TRACK | TRACK | E5 | F5 | |------+------+---------+---------+------+------| | E2 | F2 | SECTOR | SECTOR | E6 | F6 | |------+------+---------+---------+------+------| | E3 | F3 | DATA | DATA | E7 | F7 | +-----------------------------------------------+ SAMbus Realtime clock port allocations -------------------------------------- +-------------------------------------+ |PORT (R/W)| Bits 3-0 |RANGE| +----+-----------+-------------------+-----+-----+ |00EF|SECONDS LSD|S 8|S 4|S 2|S 1| 0-9 | 239| |----+-----------+----+----+----+----+-----+-----| |10EF|SECONDS MSD| |S 40|S 20|S 10| 0-5 | 4335| |----+-----------+----+----+----+----+-----+-----| |20EF|MINUTES LSD|M 8|M 4|M 2|M 1| 0-9 | 8431| |----+-----------+----+----+----+----+-----+-----| |30EF|MINUTES MS | |M 40|M 20|M 10| 0-5 |12527| |----+-----------+----+----+----+----+-----+-----| |40EF|HOURS LSD|H 8|H 4|H 2|H 1| 0-9 |16623| |----+-----------+----+----+----+----+-----+-----| |50EF|HOURS MSD| | |H 20|H 10| 0-2 |20719| |----+-----------+----+----+----+----+-----+-----| |60EF|DAY LSD|D 8|D 4|D 2|D 1| 0-9 |24815| |----+-----------+----+----+----+----+-----+-----| |70EF|DAY MSD| | |D 20|D 10| 0-3 |28911| |----+-----------+----+----+----+----+-----+-----| |80EF|MONTH LSD|MO 8|MO 4|MO 2|MO 1| 0-9 |33007| |----+-----------+----+----+----+----+-----+-----| |90EF|MONTH LSD| | | |MO10| 0-1 |37103| |----+-----------+----+----+----+----+-----+-----| |A0EF|YEAR LSD|Y 8|Y 4|Y 2|Y 1| 0-9 |41199| |----+-----------+----+----+----+----+-----+-----| |B0EF|YEAR MSD|Y 80|Y 40|Y 20|Y 10| 0-9 |45295| |----+-----------+----+----+----+----+-----+-----| |C0EF|WEEK DAY *| |W 4|W 2|W 1| 0-6 |49391| |----+-----------+----+----+----+----+-----+-----| |D0EF|CONTROL D| | |BUSY|HOLD| |53487| |----+-----------+----+----+----+----| |-----| |E0EF|CONTROL E| | | | | N/A |57583| |----+-----------+----+----+----+----| |-----| |F0EF|CONTROL F| | | | | |61679| +------------------------------------------------+ * Week day: 0 = Sunday, 1 = Monday, ... 6 = Saturday LSD -- Least Significant Digit MSD -- Most Significant Digit Bits 7-4: don't care. Serial Communications Interface ports (IM26C91 UART) ---------------------------------------------------- +---------------------------------------------------------------- -+ |PORT (WR)|128--7| 64--6| 32--5| 16--4| 8--3| 4--2| 2--1| 1-- 0| +----+---------+------+------+------+-------------+------+------------ -+----+ |00EC| MR1 |RXRTS |R/INT |ERRORM|PARITY MODE|PARTYP|BITS PER CHAR| 236| | |---------+-------------+------+--------------------------------- -| | | | MR2 |CHANNEL MODE|TXRTS |CTSETX| STOP BIT LENGTH | | |----+---------+-------------+------+------+-------------------------- -+----| |01EC| SR |RBREAK|FRAERR|PARERR|OVRERR|TXEMT |TXRDY |FFULL |RXRDY | 492| |----+---------+------------------------------------------------------ -+----| |02EC|RESERVED*| DO NOT READ | 748| |----+---------+------------------------------------------------------ -+----| |03EC| RHR | RECEIVER HOLDING REGISTER (8 BITS DATA) |1004| |----+---------+------------------------------------------------------ -+----| |04EC|RESERVED*| DO NOT READ |1260| |----+---------+------------------------------------------------------ -+----| |05EC| ISR |MP1PCH|MP1PCS| |CNTRDY|DBREAK|RXRDYF|TXEMT |TXRDY |1516| |----+---------+------+------+------+------+------+------+------+----- -+----| |06EC| CTU |C/T 15|C/T 14|C/T 13|C/T 12|C/T 11|C/T 10|C/T 9|C/T 8|1772| |----+---------+------+------+------+------+------+------+------+----- -+----| |07EC| (CTL) |C/T 7|C/T 6|C/T 5|C/T 4|C/T 3|C/T 2|C/T 1|C/T 0|2028| +--------------------------------------------------------------------- ------+ * Reserved registers should never be read during normal operation since they are reserved for internal diagnostics. +---------------------------------------------------------------- -+ |PORT (WR)|128--7| 64--6| 32--5| 16--4| 8--3| 4--2| 2--1| 1-- 0| +----+---------+------+------+------+-------------+------+------------ -+----+ |00EC| MR1 |RXRTS |R/INT |ERRORM|PARITY MODE|PARTYP|BITS PER CHAR| 236| | |---------+-------------+------+--------------------------------- -| | | | MR2 |CHANNEL MODE|TXRTS |CTSETX| STOP BIT LENGTH | | |----+---------+---------------------------+-------------------------- -+----| |01EC| CSR | RECEIVER CLOCK SELECT | TRANSMITTER CLOCK SELECT | 492| |----+---------+---------------------------+-------------------------- -+----| |02EC| CR | MISCELLANEOUS COMMANDS |DIS TX|ENA TX|DIS RX|ENA TX| 748| |----+---------+------------------------------------------------------ -+----| |03EC| THR | TRANSMITTER HOLDING REGISTER (8 BITS DATA) |1004| |----+---------+------------------------------------------------------ -+----| |04EC| ACR |BRGSET|CNTR/TIMER MODE/SRCE|POWERD|MP0 PIN FUNCTION SEL|1260| |----+---------+------+--------------------+------+------------------- -+----| |05EC| IMR |MP1CI |MP1CL | |CNTRDY|DBREAK|RXRDYF|TXEMTI|TXRDYI|1516| |----+---------+------+------+------+------+------+------+------+----- -+----| |06EC| CTUR |C/T 15|C/T 14|C/T 13|C/T 12|C/T 11|C/T 10|C/T 9|C/T 8|1772| |----+---------+------+------+------+------+------+------+------+----- -+----| |07EC| CTLR |C/T 7|C/T 6|C/T 5|C/T 4|C/T 3|C/T 2|C/T 1|C/T 0|2028| +--------------------------------------------------------------------- ------+ Third Party vendor port allocation ---------------------------------- ENTROPY ------- &xxEE Accelerator WRITE ONLY &xxDF &xxDE MultiROM WRITE ONLY &xx82 &xx83 Gig Memory Expansion WRITE ONLY &xxD0 -> &xxDF Reserved for future expansion BLUE ALPHA ---------- &FF7F Voicebox UNKNOWN &7C7F -> &7F7F Sampler UNKNOWN Kaleidoscope WRITE ONLY Hardware Kit READ/WRITE &xx7F Reserved for future expansion Back Panel Help Sheet --------------------- +--------------------------------------------------------------------- ------- | NMI MIDI OUT MIDI IN JOYSTICK MOUSE RESET EXPANSION CONNECTOR | | | 7. .6 7. .6 1 2 3 4 5 7. .6 | . . . . . 8 +------------ ------- | +-+ 3. .1 3. .1 3. . .1 +-+ |.. 1C | +-+ . . . . +-+ |.. 1A | 5. .4 5. .4 6 7 8 9 5. .4 +------------ ------- | . . . | 2 2 2 +--------------------------------------------------------------------- ------- ---------------------------------------------------------------------- ------+ EXPANSION CONNECTOR EAR/MIC LIGHT ON/OFF SAM SCART POWER | PEN | +--------------+ | 20|.. 4..|2 | --------------------+ | | | 32C..| ++ 3. .1 +--+ | | 3. 6 .1 | 32A..| ++ +--+ ++.. 3..|1 . | --------------------+ 5. .4 21++19 | . .4 | . +------------+ 5 . | 2 2 | ---------------------------------------------------------------------- ------+ MIDI IN MIDI OUT ATARI JOYSTICK MOUSE ------- -------- -------------- ----- 1 Net - Loop 1 Net - Loop 1 Up 1 Down 2 NC 2 GND 2 Down 2 Up 3 Net + Loop 3 Net + Loop 3 Left 3 CTRL 4 Midi + In 4 Midi + Out 4 Right 4 Left 5 Midi - In 5 Midi - Out 5 0v 5 Right 6 Net - Loop 6 Net - Loop 6 Fire 6 Interrupt 7 Net + Loop 7 Net + Loop 7 +5v 7 RDMSEL 8 STROBE1 (active high) 8 +5v 9 STROBE2 (active high) Screen - Ground LIGHT PEN SAM SCART POWER INPUT --------- --------- ----------- 1 +5v 1 Audio RH out 13 Red Earth 1 +5v 2 Audio LH O/P 2 SPEN in 14 CSYNC Earth 2 0v (Signal GND) 3 0v 3 Audio LH out 15 Red Lin out 3 0v (Digital GND) 4 SPEN input 4 Audio Earth 16 CSYNC 4 Composite Vid O/P 5 Audio RH O/P 5 Blue Earth 17 Comp. Video Earth 5 +12v 6 Blue TTL out 18 +12v Power in 6 Sound Ouput (Mono) 7 Blue Lin out 19 Comp. Video out 8 Red TTL out 20 Bright TTL out 9 Green Earth 21 GND 10 Green TTL out 11 Green Lin out 12 +5v Power in EXPANSION CONNECTOR DETAILS --------------------------- +-------------------------------------------------------------+ Pin 1C |++ ++|Pin 32C |++ ++| |++ ++| Pin 1A |++ ++|Pin 32A +-------------------------------------------------------------+ Standard 64 pin Euroconnector socket with rows A-C fitted. All identifiers ending with L are active low. PIN SIGNAL PIN SIGNAL --- ------ --- ------ 1A DBDIRL 1C IORQL 2A RDL 2C MREQL 3A WRL 3C HALTL 4A BUSACKL 4C NMIL 5A WAITL 5C INTLL 6A BUSREQL 6C CD1 7A RESETL 7C CD0 8A CM1L 8C CD7 9A REFRESHL 9C CD2 10A 0 VOLTS* 10C +5 VOLTS* 11A A0 11C CD6 12A A1 12C CD5 13A A2 13C CD3 14A A3 14C CD4 15A A4 15C CPU CLK 16A A5 16C A15 17A A6 17C A14 18A A7 18C A13 19A A8 19C A12 20A A9 20C A11 21A A10 21C DISC 2L 22A EXTINTL 22C ROMCSL 23A XMEML 23C EARMIC 24A 8 MHz 24C DISC 1L 25A RED 1 25C PRINTL 26A GREEN 1 26C BLUE 1 27A CSYNCL 27C ROMCSRL 28A SPEN 28C AUDIO RIGHT OUTPUT 29A BLUE 0 29C AUDIO LEFT OUTPUT 30A RED 0 30C COMPOSITE VIDEO 31A BRIGHT 31C GREEN 0 32A +5 VOLTS 32C 0 VOLTS *Not to be used as a supply rail - reference only MEMORY MAPPING -------------- +-------------------------------------------------------+ |<------------ 64k ADDRESSING SPACE OF CPU ------------>| | | |0000 3FFF|4000 7FFF|8000 BFFF|C000 FFFF| +-------------+-------------+-------------+-------------| | | | | | RAM 0 = 0| | SECTION B | SECTION C | SECTION D | ROM 1 = 0 | ROM 0 | | | | | | LMPR +1 | HMPR | HMPR +1 | MCNTRL = 0 | | | | | +-------------------------------------------------------+ | | | | | | | | | | +-------------+ +-------------+ | | | | | RAM 0 = 1| SECTION A | | | ROM 1 | | | | ROM 1 | = 1 (LMPR) | LMPR | | | (LMPR) | | | | | +-------------+ +-------------+ | | | | | | +---------------------------+ | | | | EXTERNAL | EXTERNAL | MCNTRL | | | = 1 | MEMORY C | MEMORY D | (HMPR) | | | +---------------------------+ If the ENTROPY MultiROM expansion is connected, then ROM 0 and ROM 1 may be replaced with other data. These are controlled by ports &DE and &DF; &DE handles ROM 0, &DF handles ROM 1. MR_OFF = 1 MR_OFF = 0 +-------------+ +-------------+ | | | | | ORIGINAL | | MULTI-ROM | | |---| | MR_RAM = 0 | ROM 0/1 | | | ROM PAGE | | | | | | +-------------+ | +-------------+ | | +-------------+ | | | | | MULTI-ROM | +-| | MR_RAM = 1 | RAM PAGE | | | +-------------+ ENTROPY MULTI-ROM ----------------- The Entropy Multi-ROM (M-R) expansion board has been designed as a multi-function programmer's toolkit. Its 128k-512k ROM contains a fast Macro/Conditional Assembler, Monitor & Debugger, Systems Utilities, Disc Toolkit and other programs. The Entropy Multi-ROM is accessed by two ports, &DE and &DF. When ROM is paged into sections A or D, it may be overlayed with the M-R's RAM orROM. On reset, registers &DE and &DF are reset to contain zero. This pages in the M-R's initialisation code. On power-up, the SAM's memory is tested and initialised; on reset, the full initialisation procedure is not followed, allowing the memory to be examined or debugged. MultiROM Specifications ----------------------- ROM: between 128k and 512k system ROM, including BIOS, initialisation routines, modified SAM Basic ROM v3.0, SAMDOS, toolkit, Assembler etc. RAM: Either 32k or 128k of battery-backed static RAM. Multi-ROM Memory Map << THIS INFORMATION MAY NOW BE -------------------- << INCORRECT! MultiROM system variables begin in RAM page 1 at &2000. They should not be overwritten, as the M-R uses them as part of its configuration. MultiROM pages 0 and 1 are also used as a temporary 24k buffer. This is so that the M-R may display a screen without destroying data. On a 512k machine, page 30 of the SAM's internal RAM is copied to page 0 of the M-R's RAM. Page 31 (&0000-&1FFF) is copied into the corresponding area of page 1 of the M-R RAM. On a 256k machine, page 14 is copied to page 0 of the M-R, and page 15 is copied to page 1. +-------------------------+ | | | BUFFER/SCRATCHPAD AREA | PAGE 0 | | +-------------------------| | BUFFER/SCRATCHPAD AREA | | - - - - - - - - - - - - | PAGE 1 | Multi-ROM SYSTEM VARS | +-------------------------| | | Multi-ROM Application PAGES | | (IF PRESENT) | Space | 2-->7 +-------------------------+ Multi-ROM Systems Variables < To: sam-users@nvg.unit.no Date: Wed, 2 Nov 1994 12:19:50 GMT Subject: MultiROM documentation / preamble for developers Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <375DFD5383C@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 10924 Lines: 274 MultiROM Technical Data v 1.0 -=-=-=-=-=-=-=-=-=-=-=-=-=-=- Copyright (c) 1994 Rooksoft and Entropy. The MultiROM is a trademark of Rooksoft. HARDWARE: This data sheet is a pre-release document for the new MultiROM with hardware from ROOKSOFT and software from ENTROPY. This document is intended to provide programmers with sufficient information to enable them to write software that will operate within the MultiROM. The MultiROM is an add-on unit which plugs into the SAM Coupe expansion socket and can override the SAM's internal ROM. It will provide an environment external from the normal SAM operating area from which programmers toolkits can function, such as assemblers, debuggers, disc repair/recovery toolkits etc. The MultiROM will have either a 128K, 256K or 512K byte ROM (depending upon the amount of software to be included), and a user choice of either 32K or 128K battery backed static RAM. Both the RAM and ROM are sectioned into 16K pages which are selected by writing to either port DE or DF hex. Port DE controls which RAM/ROM page is paged in inplace of ROM0, while DF does the same for ROM1. Each port is identical except that they each control ROM0 or ROM1; the bits are as follows: bit 0 Page select bit 0 bit 1 " " bit 1 bit 2 " " bit 2 bit 3 " " bit 3 Bit 4 " " bit 4 bit 5 " " bit 5 (only used if ROM> 512K) bit 6 ROM/RAM select (set= RAM) bit 7 Internal/external ROM select (set= internal ROM) On power up or RESET the MultiROM's registers are set to zero, which causes the MultiROM to take control of the SAM by paging in page zero of its ROM. This page holds the Entropy software which initialises the SAM and presents the main options menu. In order to ensure that the MultiROM is totally software compatible the MultiROM can be switched out enabling the internal ROM to operate undisturbed (ie as if the MultiROM was not plugged in). This is done by setting bit 7 of both ports and calling address 0000; this will cause the SAM to boot up as normal. The MultiROM can be re-entered by either switching off (all data lost), pressing reset or clearing both ports to zero and calling address zero again. When the MultiROM's ROM is selected it will only respond when ROM0 or ROM1 (as appropriate) is selected within the ASIC. The MultiROM RAM, however, will respond whenever it is selected within the MultiROM and regardless of whether the SAM's internal ROM or RAM is selected in the ASIC. This can cause contention between the two sets of RAM. To prevent this it is essential that when RAM is selected in port DE that ROM0 is selected in the ASIC, and accordingly when RAM is selected in port &DF that ROM1 is selected in the ASIC. This is due the fact that we would not normally want to replace the ROMs with RAMs which we can write to. Hence, the programmers are required to ensure that the ROM0 or ROM1 are selected when accessing the MultiROMs RAM. SOFTWARE: Currently the software specifications of the MultiROM remain fluid; we have not formally defined any of the system details. However, the following information IS important. Systems Variable data In page 0 of the RAM of the MultiROM, the MultiROM systems variables are kept. These are as follows: &0000 MRALLOCT MultiROM memory allocation table. As for the BASIC ALLOCT table, but keeps track of the MultiROM's memory usage. Ends with an &FF terminator. &0009 SYSINFO Systems info. Bits correspond to the following data: 0 - If BASIC is valid, set, if not, reset. 1 - External memory present if set. 2 - Two disc drives if set, one if reset. 3 - Hard-drive present if set. 4 - Comms interface present if set. 5 - SAM Mouse interface present if set. 6 - Real-time clock present if set. 7 - 128k MultiROM memory if set, 32k if reset. &000A CLKPRT Clock base port - usually &E9 &000B CLKTYP Clock type - usually 0 (OKI chip) &000C DOSINF DOS type: 0 - No DOS 1 - SAMDOS 2 - MasterDOS 3 - EDOS 4 - Other Bit 3 set if MasterBASIC installed. &000D EXMEM Number of 16k pages, external memory. &000F HDBIOS If 0, uses MultiROM as the hard-drive DOS/BIOS (if present). If NZ, uses currently loaded DOS. &0010 INITSTAT DM "MultiROM System Page" - Loaded on first switch on - if this is corrupted, then the system will re-initialise the defaults. &0024 LINEFEED As with MasterBASIC and SAM BASIC - whether or not linefeeds follow carriage returns on print-out. &0025 BOOTUP Decides what to do on boot up (drop into BASIC). Bitwise: 0 - Install DOS 1 - Install Mouse driver 2 - Install DUMP driver 3 - Install Comms driver 4 - Boot disc in drive Bit 5 decides whether or not a disc in the drive at switch on / RESET will be booted, before dropping into the main MultiROM menu. Bit 6-15 Undefined as of yet. &0027-&00FF RESERVED for MultiROM systems. &0100-&3FFF RESERVED for third-party sys variables. The systems variables are held in battery-backed RAM. It will be necessary for software writers to provide the following information: Configuration restart address -- this will be called if the battery backed memory has to be reconfigured. NB: if your program does not need its own configuration details to be kept, then this address is not needed. Entry point -- where to call the program if it has to be started. Any other information which you think may be necessary to integrate your software with the MultiROM. NB: Programs *MUST* use the memory allocation tables, unless BASIC has been corrupted, in which case pretty much anything goes. This information is available as one of the MultiROM system bytes. If BASIC has been corrupted, then some programs may be denied access. Programs should *always* use the MultiROM and External Memory allocation tables to avoid contention with other programs memory space. The rest of the system has yet to be defined. Programs may use the following as guidelines: All programs should scan for the CNTRL+CAPS+EDIT key combination, and if it is found, set port &DE to 0, page ROM into section A and then do an RST 0. This is the quick reset combination. New Allocation Table Guidelines There are three memory page allocation tables in the SAM system. These are: ALLOCT: This holds the internal memory allocation data. MRALLOCT: This holds the multiROM memory page allocation data. XMALLOCT: This holds the external memory page allocation data, and is in the first page of Meg 0. (&80 and &82 both set to zero). The XMALLOCT is new; previously this was handled by MasterDOS, however, the MasterDOS allocation was deemed to be a little "empty", as it was bitwise instead of byte per page. It is specified as: &0000 "XMALLOCT" 8 bytes memory page header &0008 "MROMv1.2" Name of program which initialised it (max 8 bytes). &0010 XMSIZE 2 bytes, size of external memory. &0012-&00FF Reserved for later expansion. &0100-&08FF XMALLOCT 2048 byte page allocation table. Allows for up to 32Mb of external memory. XMSIZE is given by the MultiROM on initialisation; it gives the last page present of external memory in the system. This enables quicker page allocation on systems with large memory. These new guidelines are needed because of the introduction of a new piece of SAM hardware which allows up to potentially 1 gigabyte of external memory. This memory is paged in using ports &82 and &83. They work in conjunction with the existing external memory ports (&80 and &81) by providing the most-significant byte of a 16-bit page number. Thus, there are now 65536 possible external memory pages. For speed, and due to costs of memory, it is assumed that the maximum that can be present on the system is 32Mb. To recap, external memory control ports are now: &80,&82 - LSB and MSB respectively of section C external memory page. &81,&83 - LSB and MSB respectively of section D external memory page. Proposal for page identification system I would like to propose a system for handling page addresses; this is a 16-bit number which holds the current page to be paged into UPPER memory. Its values are thus: 0-31 Normal internal memory page. 32-2079 External memory page. 2080-2087 MultiROM RAM page. This is the system used internally in the MultiROM by the assembler. Important Note: Software details in this document are very definitely subject to change. If you are interested in providing software for inclusion in the MultiROM then please let us know your program memory details so that we can allocate an area exclusive for your use both in ROM and RAM. We can then, also, keep you up to date with any changes to the details listed above. Please Note that the target date for the first MultiROM release is late November 1994 (in time for Xmas). Hence we would like any third party software to be provided in early to mid November. *********************************************** This development target has been ditched due to current other hardware developments which we hope to integrate in the MultiROM design; these include an IDE/SCSI hard drive BIOS and DOS, as well as other utility software. We also hope to include support for the proposed PC keyboard interface and the invisible drive upgrade system to allow 1.44Mb drives to run on the SAM. If anyone has information regarding the AJAX drive controller chip, or wishes to develop software for the MultiROM, please contact us at: Entropy@jumper.mcc.ac.uk or Rooksoft@jumper.mcc.ac.uk Or alternatively phone: 01942 886084 Snailmail: 1 Dovey Close, Astley, Tyldesley, Manchester, M29 7NP. ************************************************ Ps we are working on a two-SAM development system for the MultiROM -- keep ya posted! From imc Wed Nov 2 11:23:04 1994 Subject: Re: Current SAM Coupe port allocations, etc. To: sam-users@nvg.unit.no Date: Wed, 2 Nov 94 11:23:04 GMT In-Reply-To: <375C25A1B12@fs2.ee.umist.ac.uk>; from "Simon Cooke" at Nov 2, 94 12:12 pm X-Mailer: ELM [version 2.3 PL11] Content-Length: 220 Lines: 7 On Wed, 2 Nov 1994 12:12:49 GMT, Simon Cooke said: > This will also be posted as a UUENCODED file, as it should be > displayed on an 80character wide screen! Yeuch - that was line-broken at 70 chars. What gives? imc From sam-users-owner@nvg.unit.no Wed Nov 2 12:37:54 1994 Date: Wed, 02 Nov 1994 12:26:16 GMT From: briang@bgserv.demon.co.uk (briang@bgserv.demon.co.uk) Message-Id: <4569@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: Current SAM Coupe port allocations, etc. X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 357 Lines: 11 Any PORT in a storm? Bob does know of this list, but as far as I know, is not on line at all, though it may change soon. Knowing Bob he would not have the time for all the messing about! Brian -- briang@bgserv.demon.co.uk - Email for Speccy membranes Brian Gaff is B G Services - UK support for 'Z80' The Spectrum Emulator From sam-users-owner@nvg.unit.no Wed Nov 2 13:26:05 1994 From: Simon Cooke To: briang@bgserv.demon.co.uk (briang@bgserv.demon.co.uk), sam-users@nvg.unit.no Date: Wed, 2 Nov 1994 14:13:02 GMT Subject: Re: Current SAM Coupe port allocations, etc. Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <377C2BF08CC@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 412 Lines: 16 > Any PORT in a storm? > > Bob does know of this list, but as far as I know, is not on line > at all, though it may change soon. Knowing Bob he would not have > the time for all the messing about! Yeah... but does he accept that Martin and I are now the official port allocators? Methinks not. Port &xxD0 has just been allocated to Colin Piggot for a potential sound board, so there you go :) Si Cooke From imc Wed Nov 2 13:30:28 1994 Subject: Re: Current SAM Coupe port allocations, etc. To: sam-users@nvg.unit.no Date: Wed, 2 Nov 94 13:30:28 GMT In-Reply-To: <377C2BF08CC@fs2.ee.umist.ac.uk>; from "Simon Cooke" at Nov 2, 94 2:13 pm X-Mailer: ELM [version 2.3 PL11] Content-Length: 218 Lines: 8 On Wed, 2 Nov 1994 14:13:02 GMT, Simon Cooke said: > Yeah... but does he accept that Martin and I are now the official > port allocators? Hmmm, I can just see BoB phoning you up to ask what ports he can use... imc From sam-users-owner@nvg.unit.no Wed Nov 2 18:13:32 1994 Date: Wed, 02 Nov 1994 17:49:44 GMT From: briang@bgserv.demon.co.uk (briang@bgserv.demon.co.uk) Message-Id: <4583@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: Current SAM Coupe port allocations, etc. X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 233 Lines: 8 I will pass on what Bob thinks. ... at least recently anyway... Brian -- briang@bgserv.demon.co.uk - Email for Speccy membranes Brian Gaff is B G Services - UK support for 'Z80' The Spectrum Emulator From sam-users-owner@nvg.unit.no Wed Nov 2 18:13:35 1994 Message-Id: From: gaw-a@minster.york.ac.uk (Mars Bar) Date: Wed, 2 Nov 1994 17:42:07 +0000 In-Reply-To: Ian.Collier -- "Re: Current SAM Coupe port allocations, etc." (Nov 2, 2:30pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92 (ORBIT)) To: sam-users@nvg.unit.no Subject: Re: Current SAM Coupe port allocations, etc. Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 465 Lines: 11 On Nov 2, 2:30pm in "Re: Current SAM Coupe port allocations, etc.", you warbled: ] Hmmm, I can just see BoB phoning you up to ask what ports he can use... I won't tell you which of _my_ ports is the only one Bob can use... :) BassKeepsThumpingPumpingJumpingBassKeepsThumpingPumpingJumpingBassKeepsThumping PumpingJumpingBassKeepsPumpingBassKeepsPumpingGimmeASmileForTheFutureAndIHeard ItOnTheRadioAndISawItOnTheTelevisionBackIn1988... gaw-a@minster.york.ac.uk From sam-users-owner@nvg.unit.no Wed Nov 2 18:14:07 1994 Date: Wed, 02 Nov 1994 17:59:38 GMT From: briang@bgserv.demon.co.uk (briang@bgserv.demon.co.uk) Message-Id: <4586@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: @2:2501/102 X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 200 Lines: 7 This new SAM, has it got colour? :-) -- briang@bgserv.demon.co.uk - Email for Speccy membranes Brian Gaff is B G Services - UK support for 'Z80' The Spectrum Emulator From sam-users-owner@nvg.unit.no Wed Nov 2 18:41:39 1994 From: Frode Tennebo Message-Id: <199411021836.AA25595@ulke.hiMolde.no> Subject: Re: Hard Drive standard file structure... To: sam-users@nvg.unit.no Date: Wed, 2 Nov 1994 19:36:09 +0100 (MET) In-Reply-To: <9411021048.AA26267@boothp1.ecs.ox.ac.uk> from "Ian.Collier@comlab.ox.ac.uk" at Nov 2, 94 11:47:56 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 674 Lines: 16 > > On Tue, 1 Nov 1994 20:12:39 +0100 (MET), Frode Tennebo said: > > UNIX also has partitions too you know, so does VMS, but they have > > handled those in completely different ways. > > Yes I know, but have you seen the size of a Unix partition? :-) We have unix partitions less than 32M that is a part of the xGb filesystem. I personally use small partitions (<32Mb) for /tmp and swap-space (say on linux). -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Wed Nov 2 18:48:32 1994 From: Frode Tennebo Message-Id: <199411021836.AA25606@ulke.hiMolde.no> Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Wed, 2 Nov 1994 19:36:36 +0100 (MET) In-Reply-To: <9411021045.AA26243@boothp1.ecs.ox.ac.uk> from "Ian.Collier@comlab.ox.ac.uk" at Nov 2, 94 11:45:23 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 529 Lines: 19 > > On Tue, 1 Nov 1994 18:51:30 +0000 (GMT), Simon Cooke said: > > Ian doesn't have a SAM actually, if what I've been told is correct... > > Shhh... I was keeping that quiet. ;-) > > Anyway, I do now. It arrived this morning. :-) Congratualtions! > > imc > -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Wed Nov 2 19:52:44 1994 From: Frode Tennebo Message-Id: <199411021946.AA26155@ulke.hiMolde.no> Subject: Re: Current SAM Coupe port allocations, etc. To: sam-users@nvg.unit.no Date: Wed, 2 Nov 1994 20:46:37 +0100 (MET) In-Reply-To: <9411021330.AA26634@boothp1.ecs.ox.ac.uk> from "Ian.Collier@comlab.ox.ac.uk" at Nov 2, 94 02:30:29 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 558 Lines: 20 > > On Wed, 2 Nov 1994 14:13:02 GMT, Simon Cooke said: > > > Yeah... but does he accept that Martin and I are now the official > > port allocators? > > Hmmm, I can just see BoB phoning you up to ask what ports he can use... Does he actually design anything that uses any ports? > > imc > -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Thu Nov 3 07:00:32 1994 From: "Doore, Daniel [MIS]" To: Sam Users Subject: Re: Current SAM Coupe port allocations, etc. Date: Wed, 02 Nov 94 16:35:00 PST Message-Id: <2EB8F9FC@courier.lmu.ac.uk> Encoding: 14 TEXT X-Mailer: Microsoft Mail V3.0 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 294 Lines: 14 > On Wed, 2 Nov 1994 12:12:49 GMT, Simon Cooke said: > > This will also be posted as a UUENCODED file, as it should be > > displayed on an 80character wide screen! > > Yeuch - that was line-broken at 70 chars. What gives? Too right, took me bloody ages to sort it out. pah. Dan. > imc > From sam-users-owner@nvg.unit.no Thu Nov 3 07:18:20 1994 From: Johnathan Taylor Date: 03 Nov 94 04:35:00 +0000 Subject: @2:2501/102 Message-Id: <37f_9411030703@centron.com> Organization: Centronics BBS To: Sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2196 Lines: 60 Subject: Sam-Hard disk filesystem In a message to Johnathan Taylor <02 Nov 94 12:03> Csl@Fs2.Ee.Umist.Ac.Uk wrote: >> So just use the good features of the >> various systems, make the nesesary >> comporimises needed to allow acceptable >> performance on a z80 machine ie if >> 32bit values slow it down use 16bit >> pointers and partition large HD's it >> smaller logical units, after all who >> needs to process more than 32Meg items on >> a z80? Cs> Hmmmmm... not sure. The 32bit values Cs> will perform pretty much no slow Cs> down if done right -- the drive itself Cs> will take the most time. True, depends if we hard-code the file-system using assembler and re-assemble drive parameter changes but addressing 32bit pointers using layered access to the file-system... can cause it to only ever manage one sector access per rotation rather than however many the interleve factor allows.. After all the z80 is an 8/16bit chip 32bit operations can be done but require a lot of organisation to be both bugless AND fast IMHO whilst 16bit ops can be done quite easily and rapidly using right but non-standard methods:-) Cs> Okay, agreed -- I won't use 510 byte sectors, 512 it is. Great! that'll improve the random access calculating:-) Cs> Now the question is: In our FAT do we Cs> want a way of searching Cs> along the chain as well as forwards? Hmm, that's a tricky one! On ProDos due to extensive cache'n ALL random-access positioning is calculated from scratch each time its required... If Cache'n of the FAT and directory is going to be done, then random positioning on a file can be done in a similar fashion othrwise, PASS! I've not gone into NON-cpm low-level stuff so I don't know how it *can* be done:-( Or is the searching along a chain to do with deleted file recovery? If so then I guess some form of recovery procedure should be considered, (I hadn't even thought of looking into UZI to see if that offers anything in that department, whoops ) Johnathan. ___ Olms 1.60 [Evaluation] -- |Fidonet: Johnathan Taylor 2:2501/307 |Internet: jet@centron.com | | Standard disclaimer: The views of this user are strictly his own. From sam-users-owner@nvg.unit.no Thu Nov 3 07:18:38 1994 From: Johnathan Taylor Date: 03 Nov 94 04:35:00 +0000 Subject: Re: Compression Message-Id: <380_9411030703@centron.com> Organization: Centronics BBS To: Sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 5106 Lines: 122 On <01 Nov 94 20:32> Frode.Tennebo@Himolde.No wrote: >> Which is why you tar them up first (and >> there's no reason why it shouldn't >> be done in one go. But there is a reason why it should be done first >> rather than second, which is that doing >> it first gives better compression). A gzip'd tar archive requires complete decompression BEFORE you can even examine it's directory to see if what you want is inside it! Real archivers allow random-access to individual members ie updating, deletion, extraction require minimal work! >> Anyway, why is a single compressed file any more lose-able than any other >> kind of file? I presume that's a serious question! So I'll explain... A gzip'd tar must first be decompressed in its entirety. So a fault anywhere in the bitstream will corrupt the output tar which will normally be deleted when the crc error is detected by gzip before tar gets a look at it! Even if the bad tar is not deleted then ALL data after the coruption will be invalid as a product of the decompression technique! BUT using a normal archiver each compressed member contains its own data in a local header which also points to the next members header so if one members compressed data is corrupted it doesn't affect the surounding members, in most cases even member header corruption *could* be recoverable enough to extract the other good members! At best a bad tar.gz could be recovered upto the corruption at worst it'd be lost forever without a good backup copy! At best with lha(rc), zip, arc etc all but the corrupt members can be recovered at worst just the corrupted members will be lost;-) >> >> > LHarc format is a generic PD archive >> > envelope definition that is supported >> > from CP/M, BBC-B, IBM-CLONE, QL, and generic unix! >> >> That still doesn't tell me what kind of >> compression it uses. Fr> LZH.... Or to expand upon that a bit it's based on LZ repeated string encoding but Huffman encodes the length & position as well as unique data using either dynamic or static Huffman coding depending on the the particular method. These ARE ALL Documented in various places on the nets, so those with direct access to all those net tools should be able to locate them themselves! >> > NO LHarc method beats the ZIP deflate >> > alogarithm on achieved ratios. BUT they >> > ALL require much LESS working ram >> > space to compress and de-compress >> >> The thing about gzip is that it uses >> very little RAM to decompress (apart >> from having to store each block of the >> file, which I would have thought >> was a necessity for most systems to be >> reasonably efficient). It is rather >> resource-consuming during compression, >> but then I probably don't care that >> much because it's the decompression that matters most. I don't know WHO wrote the above paragraph imc maybe... but GET REAL! gzip and PKUNZIP2.04g etc are required to keep a running 32K ring-buffer OR rely on flawless random file access of the output stream in order to get at the 32k sliding dictionary! On a sam in Native-mode Random-access to a write file is a Kludge, so a 32k ring-buffer IS required as well as the rest of the decoding tables.... Simple way for those that believe that gzip is perfect for the SAM is WRITE IT! Don't sit there making unfounded claims about it! *PROVE US WRONG!* Fr> It does? It produces exactly the same Fr> table for decompression as for Fr> compression, otherwise it wouldn't be Fr> able to decompress...or?! Hmm... Fr> can't remember much now. Spot on Frode! It is *possible* to decompress a deflated file on a z80 using a few tricks but the compression would be more impractical than the unix system I've considered implementing! There's no point in making a system that can't create archives, using only a sam, the sam archiver standard! I have the unix C source to LHA1.0 for unix, it's in a pma archive but if the sam-owner has ProDos and the PMArc/ext suit they can extract it with that and xfer it to their unix workstation and compile it and get almost uptodate in their archivng methods! After all gzip is just a stop-gap until the full unix info-zip becomes widely accepted and obsoletes both tar and gzip for archival backups! >> imc >> As if deflate was the BEST lossless compression method... Ever heard of RAR? That uses a 64K sliding window and can produce *solid* archives ala gzip'd tars that lock the elements together.... RAR beats deflate BUT AFAIK it's not available on unix. Oh btw LZHuff can compress some LZW encoded stuff a bit further! The use of JPEG doesn't compress the actual GIF file but the decoded graphics data within it, so of course it'll outdo the portable GIF compression or a LZHuffed GIF LZW file. Don't forget though that JPEG is a lossy method and as a result is only any good for non-critical data types eg graphics. NOT program data. Johnathan. ___ Olms 1.60 [Evaluation] -- |Fidonet: Johnathan Taylor 2:2501/307 |Internet: jet@centron.com | | Standard disclaimer: The views of this user are strictly his own. From sam-users-owner@nvg.unit.no Thu Nov 3 07:18:42 1994 From: Johnathan Taylor Date: 03 Nov 94 04:35:00 +0000 Subject: @2:2501/102 Message-Id: <381_9411030703@centron.com> Organization: Centronics BBS To: Sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3029 Lines: 89 Subject: Re: Hard Drive standard file structure... On <02 Nov 94 12:08> Csl@Fs2.Ee.Umist.Ac.Uk wrote: Cs> Nope - not really. DOS evolved and Cs> evolved and it's so clunky it's Cs> unbelievable. And have *you* tried to I believe it after having one for only a couple of weeks! Good enough as somthing to just get a job done, but doesn't inspire the soul like a z80 good based machine:-) Cs> get the Docs on the low level Cs> side of the HPFS used in OS/2? It's Cs> unbloodybelievably hard. I spent Cs> a good few months tracking down the Cs> ATA standard actually (IDE design Cs> specifications). Cs> For those who want it, btw, it's in Cs> ftp.dec.com, pub/standards/ata :) Good you found it then:-) Cs> They've also got ata2, scsi1,2 and3 and a few more... Oooh, could be worth a look! >> >> It's not the size of one file that >> counts - it's the extra trouble of >> having to mess around with partitions. >> Not having to remember the drive >> letter for each file is a big plus for >> Unix IMHO. Also it would be silly >> to run out of space on one partition >> and have to start moving files here >> there and everywhere even though the disk is only 1/3 full. I know most cp/m utils write to a drive blind and generaly abort if the drive fills up but the OS does allow apps to tell the drive-space/size just apps don't bother looking! Plus cp/m flat directory structure allows files to traverse many drives, again apps just don't bother using the facility due to the extra coding needed to configure such apps to the different drive characteristics of the thousands of different drive setups. Cs> I'm considering allowing a Cs> linked-partition system, but not sure Cs> about how it'd perform speed-wise. Cs> Basically you can define two E-DOS Cs> partitions and link the data space Cs> together to form one big Cs> partition. It *may* work -- gotta look into it more. Sounds complicated! Are you designing the EDOS or whatever to be a system thats designed for the user to have consious knowledge of what the thing is doing or more a virtualised system that isolates the user from everything involved? Cs> I'm considering using the Cs> logical-sector access mode of the IDE drive Cs> to store all stuff -- other people for Cs> other partitions can use the Cs> sector/cylinder/head method if they Cs> want :) This should speed up Cs> access -- you just take the sector Cs> number in the partition, add it to Cs> the logical start of the partition and Cs> read / write... quick 'n' easy :) Hey, I missed that! Is that a logical translation feature of the low-level ATA-HD protocol or an interface layer in the host driver software? If it's the former it'll simplify the banked-uzi port I have in mind as that's designed around logical sector-sized blocks on a scsi HD:-) Johnathan. ___ Olms 1.60 [Evaluation] -- |Fidonet: Johnathan Taylor 2:2501/307 |Internet: jet@centron.com | | Standard disclaimer: The views of this user are strictly his own. From sam-users-owner@nvg.unit.no Thu Nov 3 09:27:46 1994 From: "Doore, Daniel [MIS]" To: Simon Cooke Cc: Sam Users Subject: Ne: Any aort allocation in a storm Date: Thu, 03 Nov 94 09:24:00 PST Message-Id: <2EB91C96@courier.lmu.ac.uk> Encoding: 34 TEXT X-Mailer: Microsoft Mail V3.0 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 880 Lines: 34 > From: Simon Cooke > To: Doore, Daniel [MIS]; sam-users > Subject: Re: Current SAM Coupe port allocations, etc. > Date: 03 November 1994 10:26 > > > > On Wed, 2 Nov 1994 12:12:49 GMT, Simon Cooke said: > > > > This will also be posted as a UUENCODED file, as it should be > > > > displayed on an 80character wide screen! Are you sure it was UUencoded? 'cos my mailer said it wasn't. > > > > > > Yeuch - that was line-broken at 70 chars. What gives? > > > > Too right, took me bloody ages to sort it out. pah. > > > > Dan. > > > > > imc > > It's this mailer software... I'll see if I can send it as a file > instead of as an email, but in ASCII. What I usually do is send it as an UUencoded attachment (UUencoded is not from choice, this mailer does it for any attachments- even ASCII ones...) as this prevents the mailer screwing it up. Dan. > Hmmm... could work > Si > From sam-users-owner@nvg.unit.no Thu Nov 3 09:31:48 1994 From: Simon Cooke To: Johnathan Taylor , sam-users@nvg.unit.no Date: Thu, 3 Nov 1994 10:38:11 GMT Subject: Re: @2:2501/102 Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <38C2F484073@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2643 Lines: 56 > I know most cp/m utils write to a drive blind and generaly abort if the drive > fills up but the OS does allow apps to tell the drive-space/size just apps > don't bother looking! Plus cp/m flat directory structure allows files to > traverse many drives, again apps just don't bother using the facility due to > the extra coding needed to configure such apps to the different drive > characteristics of the thousands of different drive setups. Yeah - I hate the way MS-DOS does that. It's not hard to look at the contents of the FAT to work out the number of free clusters, and *then* start to write the file, not the other way around. Some people, eh? > Cs> I'm considering allowing a > Cs> linked-partition system, but not sure > Cs> about how it'd perform speed-wise. > Cs> Basically you can define two E-DOS > Cs> partitions and link the data space > Cs> together to form one big > Cs> partition. It *may* work -- gotta look into it more. > > Sounds complicated! Are you designing the EDOS or whatever to be a system > thats designed for the user to have consious knowledge of what the thing is > doing or more a virtualised system that isolates the user from everything > involved? It'll be more virtualised -- if you link paritions (in the final DOS), then they will appear to be the same -- you will be able to allocate partitions as subdirectories and vice versa. I'm thinking of implementing disk images -- you copy a SAM disk in, and tell the DOS to map it to drive 1 or drive 2 -- then you can do all the sector access as normal :) > Cs> I'm considering using the > Cs> logical-sector access mode of the IDE drive > Cs> to store all stuff -- other people for > Cs> other partitions can use the > Cs> sector/cylinder/head method if they > Cs> want :) This should speed up > Cs> access -- you just take the sector > Cs> number in the partition, add it to > Cs> the logical start of the partition and > Cs> read / write... quick 'n' easy :) > > Hey, I missed that! Is that a logical translation feature of the low-level > ATA-HD protocol or an interface layer in the host driver software? > > If it's the former it'll simplify the banked-uzi port I have in mind as that's > designed around logical sector-sized blocks on a scsi HD:-) It's the former -- LBA mode, set as part of the features register, allows you to use 24bit (I think -- not got the specs in front of me) logical sector numbers to address the hard disk. Will make it a *LOT* easier, and also will make it a piece of cake to convert to SCSI or even to an IDE CD Rom drive using its seconds based address scheme. Si Cooke From sam-users-owner@nvg.unit.no Thu Nov 3 09:36:23 1994 From: Simon Cooke To: Johnathan Taylor , sam-users@nvg.unit.no Date: Thu, 3 Nov 1994 10:42:50 GMT Subject: Re: @2:2501/102 Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <38C4303504F@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2575 Lines: 55 > True, depends if we hard-code the file-system using assembler and re-assemble > drive parameter changes but addressing 32bit pointers using layered access to > the file-system... can cause it to only ever manage one sector access per > rotation rather than however many the interleve factor allows.. > After all the z80 is an 8/16bit chip 32bit operations can be done but require > a lot of organisation to be both bugless AND fast IMHO whilst 16bit ops can be > done quite easily and rapidly using right but non-standard methods:-) I'm still not sure... How about zoning to 16 bits? That way it will *appear* to have 16-bit partitions... I've got to sit down and work out how the MultiROM's BIOS is going to handle this... We've got a drive up and running atm (just connecting it to the SAM's bus), so we'll know more on Saturday. I think, if you use the BIOS to handle stuff it'll be nicer, but as long as accesses follow a few basic ground rules (no treading on other people's partitions, use the MultiROM's RAM to check the config or work it out from the configuration partition (sector 1 of the disk, after the partition table in sector 2)), then it should all be okay. > Cs> Okay, agreed -- I won't use 510 byte sectors, 512 it is. > > Great! that'll improve the random access calculating:-) Heheheh > Cs> Now the question is: In our FAT do we > Cs> want a way of searching > Cs> along the chain as well as forwards? > > Hmm, that's a tricky one! On ProDos due to extensive cache'n ALL random-access > positioning is calculated from scratch each time its required... > If Cache'n of the FAT and directory is going to be done, then random > positioning on a file can be done in a similar fashion othrwise, PASS! I'm planning to allow large caches -- probably not on floppies until the invisible upgrade occurs, which should allow us to autosense the drive change and basically treat the floppy drives like IDE! > I've not gone into NON-cpm low-level stuff so I don't know how it *can* be > done:-( > > Or is the searching along a chain to do with deleted file recovery? > If so then I guess some form of recovery procedure should be considered, (I > hadn't even thought of looking into UZI to see if that offers anything in that > department, whoops ) It's to do with both -- for quick backwards random access and for file recovery. Out of interest, does *anyone* have any idea how MSDOS undeletes files? I can't see how it's able to do it, unless the second FAT is only updated on a new-file-write... Si Cooke From sam-users-owner@nvg.unit.no Thu Nov 3 09:41:20 1994 From: Simon Cooke To: "Doore, Daniel [MIS]" , Sam Users Date: Thu, 3 Nov 1994 10:47:23 GMT Subject: Re: Ne: Any aort allocation in a storm Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <38C560A68E1@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 471 Lines: 15 > Are you sure it was UUencoded? 'cos my mailer said it wasn't. That one wasn't, but the one I sent after it was... maybe it got ditched somewhere along the line :( > What I usually do is send it as an UUencoded attachment (UUencoded is > not from choice, this mailer does it for any attachments- even ASCII > ones...) > as this prevents the mailer screwing it up. Uhuh... that's what I do normally. I'll see if I get time to send it again tomorrow :) Cheers, Si From sam-users-owner@nvg.unit.no Thu Nov 3 10:01:25 1994 From: Simon Cooke To: "Doore, Daniel [MIS]" , sam-users@nvg.unit.no Date: Thu, 3 Nov 1994 10:26:58 GMT Subject: Re: Current SAM Coupe port allocations, etc. Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <38BFF4E6B95@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 439 Lines: 17 > > On Wed, 2 Nov 1994 12:12:49 GMT, Simon Cooke said: > > > This will also be posted as a UUENCODED file, as it should be > > > displayed on an 80character wide screen! > > > > Yeuch - that was line-broken at 70 chars. What gives? > > Too right, took me bloody ages to sort it out. pah. > > Dan. > > > imc It's this mailer software... I'll see if I can send it as a file instead of as an email, but in ASCII. Hmmm... could work Si From sam-users-owner@nvg.unit.no Thu Nov 3 10:06:22 1994 From: "Doore, Daniel [MIS]" To: Sam Users Subject: Re: Current SAM Coupe port allocations, etc. Date: Thu, 03 Nov 94 10:02:00 PST Message-Id: <2EB925B4@courier.lmu.ac.uk> Encoding: 28 TEXT X-Mailer: Microsoft Mail V3.0 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 644 Lines: 28 > From: sam-users-owner > To: Doore, Daniel [MIS]; sam-users > Subject: Re: Current SAM Coupe port allocations, etc. > Date: 03 November 1994 10:26 WOOAAHH!! Deja Vu! D. > > > On Wed, 2 Nov 1994 12:12:49 GMT, Simon Cooke said: > > > > This will also be posted as a UUENCODED file, as it should be > > > > displayed on an 80character wide screen! > > > > > > Yeuch - that was line-broken at 70 chars. What gives? > > > > Too right, took me bloody ages to sort it out. pah. > > > > Dan. > > > > > imc > > It's this mailer software... I'll see if I can send it as a file > instead of as an email, but in ASCII. > > Hmmm... could work > Si > From sam-users-owner@nvg.unit.no Thu Nov 3 10:10:12 1994 From: Frode Tennebo Message-Id: <199411031007.AA02161@ulke.hiMolde.no> Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Thu, 3 Nov 1994 11:07:45 +0100 (MET) In-Reply-To: <38C4303504F@fs2.ee.umist.ac.uk> from "Simon Cooke" at Nov 3, 94 10:42:50 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 843 Lines: 21 > Out of interest, does *anyone* have any idea how MSDOS undeletes > files? I can't see how it's able to do it, unless the second FAT is > only updated on a new-file-write... MessDos deletes files by marking the first letter in the filename is marked '?'. The DOS recognizes the allocations in the FAT related to all files marked '?' as free and uses them as at will. To undelete all you have to replace the '?' with some legal character. Then IF you'r lucky and MS/DOS have not used any of the sectors related to that file, voila, you have an undeleted file. > > Si Cooke > -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Thu Nov 3 10:54:30 1994 Message-Id: From: gaw-a@minster.york.ac.uk (Mars Bar) Date: Thu, 3 Nov 1994 10:31:56 +0000 In-Reply-To: jet -- "Re: Compression" (Nov 3, 4:35am) X-Mailer: Mail User's Shell (7.2.5 10/14/92 (ORBIT)) To: sam-users@nvg.unit.no Subject: Re: Compression Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1041 Lines: 24 On Nov 3, 4:35am in "Re: Compression", you warbled: ] Oh btw LZHuff can compress some LZW encoded stuff a bit further! ] The use of JPEG doesn't compress the actual GIF file but the decoded graphics ] data within it, so of course it'll outdo the portable GIF compression or a ] LZHuffed GIF LZW file. Don't forget though that JPEG is a lossy method and as ] a result is only any good for non-critical data types eg graphics. NOT program ] data. I think that little shard was aimed at me... I know jpg isn't useful for anything but picture compression -- but that was entirely the point I was trying to get across - that people invent new compression techniques often simply to improve the compression of one type of data. ] ___ Olms 1.60 [Evaluation] Can someone explain this ^^ to me please??? BassKeepsThumpingPumpingJumpingBassKeepsThumpingPumpingJumpingBassKeepsThumping PumpingJumpingBassKeepsPumpingBassKeepsPumpingGimmeASmileForTheFutureAndIHeard ItOnTheRadioAndISawItOnTheTelevisionBackIn1988... gaw-a@minster.york.ac.uk From imc Thu Nov 3 11:30:10 1994 Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Thu, 3 Nov 94 11:30:10 GMT In-Reply-To: <37f_9411030703@centron.com>; from "Johnathan Taylor" at Nov 3, 94 4:35 am X-Mailer: ELM [version 2.3 PL11] Content-Length: 643 Lines: 15 On 03 Nov 94 04:35:00 +0000, Johnathan Taylor said: > Hmm, that's a tricky one! On ProDos due to extensive cache'n ALL random-access > positioning is calculated from scratch each time its required... I thought ProDos wrote CP/M format disks, so why does it need to cache anything? > If Cache'n of the FAT and directory is going to be done, then random > positioning on a file can be done in a similar fashion othrwise, PASS! If my calculations are correct, an entire FAT would require 128K so caching it would be rather expensive and therefore random access would be rather slow. I'm definitely not in favour of a FAT-based system. imc From sam-users-owner@nvg.unit.no Thu Nov 3 11:46:18 1994 From: Simon Cooke To: Ian.Collier@uk.ac.oxford.comlab, sam-users@nvg.unit.no Date: Thu, 3 Nov 1994 12:47:43 GMT Subject: Re: @2:2501/102 Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <38E57DB0A16@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 803 Lines: 21 > I thought ProDos wrote CP/M format disks, so why does it need to cache > anything? It's done for speed -- there's a 64k cache (I think) so that disk access is faster. > > If Cache'n of the FAT and directory is going to be done, then random > > positioning on a file can be done in a similar fashion othrwise, PASS! > > If my calculations are correct, an entire FAT would require 128K so caching > it would be rather expensive and therefore random access would be rather > slow. I'm definitely not in favour of a FAT-based system. Yeah, but how else are we supposed to thread the files? I must say though, that I will be putting support for an as-large-as- you-like disk cache in E-DOS -- up to 16Mb, I think... I don't think anyone will ever use one that big, but it's worth supporting. Si From imc Thu Nov 3 12:02:06 1994 Subject: Re: Compression To: sam-users@nvg.unit.no Date: Thu, 3 Nov 94 12:02:06 GMT In-Reply-To: <380_9411030703@centron.com>; from "Johnathan Taylor" at Nov 3, 94 4:35 am X-Mailer: ELM [version 2.3 PL11] Content-Length: 2626 Lines: 68 On 03 Nov 94 04:35:00 +0000, Johnathan Taylor said: > A gzip'd tar archive requires complete decompression BEFORE you can even > examine it's directory That's true. It all depends on what you want it for. > >> Anyway, why is a single compressed file any more lose-able than any other > >> kind of file? > A gzip'd tar must first be decompressed in its entirety. Your answer is quite correct, but it is to a different question... It is true that if a gzip file gets corrupted then that's it. However I think specially catering for corrupted files is not the main aim of a compression/archive system. Anyway, the explanation that I actually wanted was of the following sentence: jet> Plus I'd want jet> to be able combine assosiated files into a single archive not a seperate jet> lose-able bunch of seperatly compressed files! So why is a single compressed file any more lose-able than any other kind of file? > Fr> LZH.... > Or to expand upon that a bit it's based on LZ repeated string encoding but > Huffman encodes the length & position as well as unique data using either > dynamic or static Huffman coding depending on the the particular method. How is this different from LZ77? > These > ARE ALL Documented in various places on the nets, so those with direct access > to all those net tools should be able to locate them themselves! There are quite a lot of things on the net actually, so you will have to narrow down the search a little more than that. > >> The thing about gzip is that it uses > >> very little RAM to decompress (apart > >> from having to store each block of the > >> file > I don't know WHO wrote the above paragraph imc maybe... but GET REAL! gzip and > PKUNZIP2.04g etc are required to keep a running 32K ring-buffer OR rely on > flawless random file access of the output stream in order to get at the 32k > sliding dictionary! Which is implied by "storing each block of the file" (if the blocks are 32K. Note: I did _not_ mean disk blocks. > Simple way for those that believe that gzip is perfect for the SAM is WRITE > IT! Don't sit there making unfounded claims about it! *PROVE US WRONG!* Do you remember how this started? By me saying I might write one. > As if deflate was the BEST lossless compression method... Ever heard of RAR? No I haven't. > Oh btw LZHuff can compress some LZW encoded stuff a bit further! Perhaps, but you are better off uncompressing the LZW first before trying another compression method. imc From imc Thu Nov 3 12:11:25 1994 Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Thu, 3 Nov 94 12:11:25 GMT In-Reply-To: <38E57DB0A16@fs2.ee.umist.ac.uk>; from "Simon Cooke" at Nov 3, 94 12:47 pm X-Mailer: ELM [version 2.3 PL11] Content-Length: 671 Lines: 17 On Thu, 3 Nov 1994 12:47:43 GMT, Simon Cooke said: > > I thought ProDos wrote CP/M format disks, so why does it need to cache > > anything? Let me clarify that question. Why would calculating a random access on this system depend on caching, apart from storing the 32-byte directory entry(ies)? ... Oh never mind, I probably misunderstood the remark. > > If my calculations are correct, an entire FAT would require 128K so caching > > it would be rather expensive and therefore random access would be rather > > slow. I'm definitely not in favour of a FAT-based system. > Yeah, but how else are we supposed to thread the files? What is "threading the files"? imc From imc Thu Nov 3 12:25:16 1994 Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Thu, 3 Nov 94 12:25:16 GMT In-Reply-To: <199411031007.AA02161@ulke.hiMolde.no>; from "Frode Tennebo" at Nov 3, 94 11:07 am X-Mailer: ELM [version 2.3 PL11] Content-Length: 711 Lines: 17 On Thu, 3 Nov 1994 11:07:45 +0100 (MET), Frode Tennebo said: > MessDos deletes files by marking the first letter in the filename > is marked '?'. Indeed, so does the Sam and so does CP/M (although the ? is probably a zero character). > To undelete > all you have to replace the '?' with some legal character. Then IF you'r > lucky and MS/DOS have not used any of the sectors related to that > file, voila, you have an undeleted file. Of course, a good undelete utility checks all the sectors to make sure they are not used by any other file. If they are not, then you have a good chance of getting a good copy, and otherwise you are stuffed... imc From sam-users-owner@nvg.unit.no Thu Nov 3 12:56:57 1994 From: Frode Tennebo Message-Id: <199411031249.AA06715@ulke.hiMolde.no> Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Thu, 3 Nov 1994 13:49:50 +0100 (MET) In-Reply-To: <9411031225.AA27777@boothp1.ecs.ox.ac.uk> from "Ian.Collier@comlab.ox.ac.uk" at Nov 3, 94 01:25:18 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1097 Lines: 31 > > On Thu, 3 Nov 1994 11:07:45 +0100 (MET), Frode Tennebo said: > > MessDos deletes files by marking the first letter in the filename > > is marked '?'. > > Indeed, so does the Sam and so does CP/M (although the ? is probably a > zero character). On the SAM it is NULL, but I seem to remember it's a '?' on MS/DOS. > > > To undelete > > all you have to replace the '?' with some legal character. Then IF you'r > > lucky and MS/DOS have not used any of the sectors related to that > > file, voila, you have an undeleted file. > > Of course, a good undelete utility checks all the sectors to make sure > they are not used by any other file. If they are not, then you have a > good chance of getting a good copy, and otherwise you are stuffed... Of course... > > imc > -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Thu Nov 3 13:21:54 1994 Date: Thu, 3 Nov 1994 14:05:59 +0100 X400-Originator: cgp@st-andrews.ac.uk X400-Recipients: sam-users@nvg.unit.no X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<22435.9411031305@pasta.st-andre] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: (l)a(r)2:250 From: Colin G Piggot Message-Id: <22435.9411031305@pasta.st-andrews.ac.uk> To: sam-users@nvg.unit.no Subject: Re: @2:2501/102 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 997 Lines: 21 > > > MessDos deletes files by marking the first letter in the filename > > > is marked '?'. > > > > Indeed, so does the Sam and so does CP/M (although the ? is probably a > > zero character). > > On the SAM it is NULL, but I seem to remember it's a '?' on MS/DOS. On the Sam, a deleted file has it's filetype changed to 'NULL'. To mark the end of the directory, both the filetype AND the first character of the file name is 'NULL'. Colin Piggot. ============================================================================ | | RECOVER-E : Sam disk repair / file recovery utility | | Colin G. Piggot | (C) 1994 Colin Piggot / Phoenix Software Systems | | --------------- | What the magazines said: | | cgp@st-and.ac.uk | 'Recover-E... without which this issue would not be | | ---------------- | here - Buy it NOW' Issue 6 Zodiac Magazine | ============================================================================ From sam-users-owner@nvg.unit.no Thu Nov 3 13:27:11 1994 From: Simon Cooke To: Ian.Collier@uk.ac.oxford.comlab, sam-users@nvg.unit.no Date: Thu, 3 Nov 1994 14:10:12 GMT Subject: Re: @2:2501/102 Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <38FB7C405D7@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1345 Lines: 30 > Indeed, so does the Sam and so does CP/M (although the ? is probably a > zero character). Yes, but....... In MSDOS, the FAT table is cleared -- space the file used to take up is filled with zeroes to mark those clusters as free... so how does it work out which belonged to which file. (NB: THis is what every book I've looked in so far, from Norton to the PC Low Level Programmer's Handbook (or whatever it was called) says happens -- there's no mention of keeping the FAT "as-is") > > To undelete > > all you have to replace the '?' with some legal character. Then IF you'r > > lucky and MS/DOS have not used any of the sectors related to that > > file, voila, you have an undeleted file. > > Of course, a good undelete utility checks all the sectors to make sure > they are not used by any other file. If they are not, then you have a > good chance of getting a good copy, and otherwise you are stuffed... I've got a really groovy directory cleaner (would have evolved to a defragmenter if I'd had the time) for the SAM -- it takes the directory, sorts it into alphabetical order, moves all erased files to the end of the directory and deletes any erased files which can't be unerased (from the current status of the directory) totally from the directory. Si Cooke From sam-users-owner@nvg.unit.no Thu Nov 3 13:27:40 1994 From: Simon Cooke To: Frode Tennebo , sam-users@nvg.unit.no Date: Thu, 3 Nov 1994 14:12:55 GMT Subject: Re: File undeleting Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <38FC3390224@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 417 Lines: 16 > On the SAM it is NULL, but I seem to remember it's a '?' on MS/DOS. Ah... I know where that confusion lies... The first byte of the filename is replaced with 0xE5, which is the sigma character. THis shows it has been erased. It comes up on undelete as an "?" because it could be anything, so the undelete routine replaces it with the "anything" character to get you to type in a replacement for it. Si From sam-users-owner@nvg.unit.no Thu Nov 3 13:27:52 1994 From: Simon Cooke To: Ian.Collier@uk.ac.oxford.comlab, sam-users@nvg.unit.no Date: Thu, 3 Nov 1994 14:06:40 GMT Subject: Re: @2:2501/102 Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <38FA8C63446@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 826 Lines: 21 > Let me clarify that question. Why would calculating a random access on > this system depend on caching, apart from storing the 32-byte directory > entry(ies)? ... Oh never mind, I probably misunderstood the remark. Just for speed -- if you can keep the FAT in memory, then it's a lot faster than having to chug through the file links on disk when you have to jump to another point in the file... > > > If my calculations are correct, an entire FAT would require 128K so caching > > > it would be rather expensive and therefore random access would be rather > > > slow. I'm definitely not in favour of a FAT-based system. > > > Yeah, but how else are we supposed to thread the files? > > What is "threading the files"? Chaining the sectors together to make up the actual file itself (well, that's what I mean) Si From sam-users-owner@nvg.unit.no Thu Nov 3 13:32:24 1994 From: Nigel J Kettlewell Message-Id: <28230.199411031329@stone> Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Thu, 3 Nov 1994 13:29:24 +0000 (GMT) In-Reply-To: <199411031249.AA06715@ulke.hiMolde.no> from "Frode Tennebo" at Nov 3, 94 13:49:50 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 339 Lines: 15 > > > MessDos deletes files by marking the first letter in the filename > > > is marked '?'. > > > > Indeed, so does the Sam and so does CP/M (although the ? is probably a > > zero character). > > On the SAM it is NULL, but I seem to remember it's a '?' on MS/DOS. Hmm, I thought it was zero byte on DOS disks... Anybody else? Nige From imc Thu Nov 3 13:46:16 1994 Subject: @2:2501/102 To: sam-users@nvg.unit.no Date: Thu, 3 Nov 94 13:46:16 GMT X-Mailer: ELM [version 2.3 PL11] Content-Length: 2023 Lines: 43 On Thu, 3 Nov 1994 14:06:40 GMT, Simon Cooke said: > > Let me clarify that question. Why would calculating a random access on > > this system depend on caching > Just for speed -- if you can keep the FAT in memory, then it's a lot > faster But CP/M doesn't have a FAT - hence my question. > > > > I'm definitely not in favour of a FAT-based system. > > > > > Yeah, but how else are we supposed to thread the files? > > > > What is "threading the files"? > > Chaining the sectors together to make up the actual file itself Simple. Associate with each individual file the list of disk blocks which it occupies. Hence the concept of a Unix i-node. The information doesn't have to be in the i-node; it can be in the directory or in a header at the start of the file. Now, for a 20K long file you only have to cache 20 bytes (or possibly 40 bytes) of data. CP/M stores the list of blocks in the directory entry. Unless you already knew this and were just humouring me, you are probably asking what happens if the file is so long that the list of blocks doesn't fit in the directory (or the i-node, or the file header). CP/M cures this in a not-spectacularly-satisfactory way by allocating another directory entry to the file. Unix is more clever; the last block number in the list does not point to a block of the file - it points to a block of block numbers. There's enough space there to list all the blocks in a 512K file. Unix actually goes two steps further than this, though you would only need one on any reasonable filing system: after the block of block numbers it has a block of blocks of block numbers. This is sufficient for files up to 256M in length. For completeness' sake, what about the free block list? Store a pointer to the first free block somewhere, and then write at the start of each free block the number of the next free block. Since the space isn't being used for anything else and you are not likely to want to do random access on the free list, this scheme works well. imc From sam-users-owner@nvg.unit.no Thu Nov 3 14:04:13 1994 Message-Id: From: simonc@jumper.mcc.ac.uk (Simon Cooke) Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Thu, 3 Nov 1994 13:58:06 +0000 (GMT) Cc: simonc@jumper.mcc.ac.uk (Simon Cooke) In-Reply-To: <9411031346.AA29436@boothp1.ecs.ox.ac.uk> from "Ian.Collier@comlab.ox.ac.uk" at Nov 3, 94 02:46:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2211 Lines: 45 > > Just for speed -- if you can keep the FAT in memory, then it's a lot > > faster > > But CP/M doesn't have a FAT - hence my question. Hmmmm... I thought it did, to an extent. Time for me to read up on it again. > Simple. Associate with each individual file the list of disk blocks which > it occupies. Hence the concept of a Unix i-node. The information doesn't > have to be in the i-node; it can be in the directory or in a header at the > start of the file. Now, for a 20K long file you only have to cache 20 > bytes (or possibly 40 bytes) of data. CP/M stores the list of blocks > in the directory entry. Ahhhh.... I see. > Unless you already knew this and were just humouring me, you are probably > asking what happens if the file is so long that the list of blocks doesn't > fit in the directory (or the i-node, or the file header). CP/M cures this > in a not-spectacularly-satisfactory way by allocating another directory > entry to the file. Unix is more clever; the last block number in the > list does not point to a block of the file - it points to a block of block > numbers. There's enough space there to list all the blocks in a 512K file. > Unix actually goes two steps further than this, though you would only need > one on any reasonable filing system: after the block of block numbers it > has a block of blocks of block numbers. This is sufficient for files up > to 256M in length. > > For completeness' sake, what about the free block list? Store a pointer to > the first free block somewhere, and then write at the start of each free > block the number of the next free block. Since the space isn't being used > for anything else and you are not likely to want to do random access on the > free list, this scheme works well. Nope, I wasn't just humouring you -- I didn't know. Okay... the main problem that I can see with that is it's not going to be much fun to play with -- the block lists are extremely delocalised, or so it seems... Also, they seem much more wasteful than the FAT system in MSDOS due to the minium size of sector limit... (Ie small files require 512 bytes whatever their size to store their links) Hmmm.. I'll think about it some more soon. Si From imc Thu Nov 3 14:12:17 1994 Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Thu, 3 Nov 94 14:12:17 GMT In-Reply-To: ; from "Simon Cooke" at Nov 3, 94 1:58 pm X-Mailer: ELM [version 2.3 PL11] Content-Length: 908 Lines: 16 On Thu, 3 Nov 1994 13:58:06 +0000 (GMT), Simon Cooke said: > Okay... the main problem that I can see with that is it's not going to be > much fun to play with -- the block lists are extremely delocalised, or so it > seems... Also, they seem much more wasteful than the FAT system in MSDOS due > to the minium size of sector limit... (Ie small files require 512 bytes whatever > their size to store their links) The block lists are delocalised (to a certain extent), but I don't quite see what disadvantage that is. A small file does not require 512 bytes to store its block list. In +3DOS up to 16 block numbers can be stored in the directory entry (the directory entry being 32 bytes in size), whereas in Unix up to 10 block numbers can be stored in the i-node (the i-node being 64 bytes in size, or 32 for Minix). It is only files larger than that which need a whole disk block to store the list. imc From sam-users-owner@nvg.unit.no Thu Nov 3 14:52:46 1994 Date: Thu, 03 Nov 94 15:41:06 MET From: Milan Salajka Subject: RX & TX To: sam-users@nvg.unit.no Message-Id: <"alfie.uib..015:03.10.94.14.49.03"@uib.no> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 247 Lines: 9 Hello, what makes these bits (rxmidi and txmidi - bit 7/vmpr) ? i assume, that rxmidi reads serial info from midi port and txmidi turns on/off midi out port. Is it true ? i thought, that txmidi is for sending serial info... :( Milan From sam-users-owner@nvg.unit.no Thu Nov 3 15:09:02 1994 From: "Doore, Daniel [MIS]" To: Sam Users Subject: Undeletion. Date: Thu, 03 Nov 94 12:40:00 PST Message-Id: <2EB96C67@courier.lmu.ac.uk> Encoding: 28 TEXT X-Mailer: Microsoft Mail V3.0 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 991 Lines: 28 > On Thu, 3 Nov 1994 11:07:45 +0100 (MET), Frode Tennebo said: > > MessDos deletes files by marking the first letter in the filename > > is marked '?'. > > Indeed, so does the Sam and so does CP/M (although the ? is probably a > zero character). > > > To undelete > > all you have to replace the '?' with some legal character. Then IF you'r > > lucky and MS/DOS have not used any of the sectors related to that > > file, voila, you have an undeleted file. > > Of course, a good undelete utility checks all the sectors to make sure > they are not used by any other file. If they are not, then you have a > good chance of getting a good copy, and otherwise you are stuffed... Undelete in windows gives you a 'condition' of the file ranging from excellent to piss poor, depending on how many sectors have been overwritten, and you can recover the file even if it has lost some info. Just thought I'd tell you that. Dan. > imc > From sam-users-owner@nvg.unit.no Thu Nov 3 17:10:22 1994 From: Simon Cooke To: Ian.Collier@uk.ac.oxford.comlab, sam-users@nvg.unit.no Date: Thu, 3 Nov 1994 18:13:09 GMT Subject: Re: @2:2501/102 Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <393C4A44008@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 809 Lines: 21 > The block lists are delocalised (to a certain extent), but I don't quite > see what disadvantage that is. A small file does not require 512 bytes > to store its block list. In +3DOS up to 16 block numbers can be stored in > the directory entry (the directory entry being 32 bytes in size), whereas > in Unix up to 10 block numbers can be stored in the i-node (the i-node > being 64 bytes in size, or 32 for Minix). It is only files larger than > that which need a whole disk block to store the list. > > imc I'm still not sure about it -- I'll sit down and work it out over the next few nights when I get chance. In some ways I like the idea of storing file data location in the directory (or i-node), in others I prefer the FAT system... Lemme get some words on paper and work this out :) Si From sam-users-owner@nvg.unit.no Thu Nov 3 21:21:35 1994 Date: Thu, 03 Nov 1994 21:10:58 GMT From: Briansam@bgserv.demon.co.uk (Brian Gaff Sam Dept.) Message-Id: <4655@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: @2:2501/102 X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 294 Lines: 14 Keeping FATs in memory is fine... til the machine xrashes and you aint written it yet! Or you use it on Floppies and swap them... Different tack. Bob (THE Bob) asked me if there is a CHEAP Z80 assembler that works on a PC. Not on an emulator... Any ideas? Brian -- Brian Gaff Sam Dept. From sam-users-owner@nvg.unit.no Thu Nov 3 22:06:25 1994 Message-Id: From: simonc@jumper.mcc.ac.uk (Simon Cooke) Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Thu, 3 Nov 1994 22:03:56 +0000 (GMT) Cc: simonc@jumper.mcc.ac.uk (Simon Cooke) In-Reply-To: <4655@bgserv.demon.co.uk> from "Brian Gaff Sam Dept." at Nov 3, 94 09:10:58 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 828 Lines: 23 > > Keeping FATs in memory is fine... til the machine xrashes and > you aint written it yet! Or you use it on Floppies and swap > them... Well... We'll see. I'm definitiely going to have a read cache for the hard drive -- caching the floppies is being considered -- but it will read track 0 sector 1 to check if it's the right disk for the FAT in memory before it uses it. > Different tack. Bob (THE Bob) asked me if there is a CHEAP Z80 > assembler that works on a PC. Not on an emulator... Any ideas? Yes, there are billions of them -- but the best I've used is PDS and even then there are only a few things about it which makes it rate above comet -- and even then, comet wipes the floor with it on most things. Look in SRC.DOC.IC.AC.UK, under pub/packages/simtel/crossassemblers (or something like that). Next?:) Si From imc Fri Nov 4 10:57:57 1994 Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Fri, 4 Nov 94 10:57:57 GMT In-Reply-To: <4655@bgserv.demon.co.uk>; from "Brian Gaff Sam Dept." at Nov 3, 94 9:10 pm X-Mailer: ELM [version 2.3 PL11] Content-Length: 1001 Lines: 23 On Thu, 03 Nov 1994 21:10:58 GMT, Brian Gaff Sam Dept. said: > Keeping FATs in memory is fine... til the machine xrashes and > you aint written it yet! I imagine that the idea is that changes to the FAT will be written immediately; the copy in memory is only to avoid extra read accesses. > Or you use it on Floppies and swap > them... Now that is a problem. The +3 has a similar problem (and I once accidentally wiped a disk because of it and had to examine each sector to reconstruct the files), but it copes by invalidating the cache after about 3 seconds of inactivity (my problem was caused by typing NEW within 48KDB because that resets the frame counter and fools the timer). Fortunately the FAT of a floppy disk is small enough to read quite quickly on startup. > Different tack. Bob (THE Bob) asked me if there is a CHEAP Z80 > assembler that works on a PC. Not on an emulator... Any ideas? No (wouldn't be that hard to write one though surely... :-) ). imc From sam-users-owner@nvg.unit.no Fri Nov 4 11:46:00 1994 Message-Id: From: gaw-a@minster.york.ac.uk (Mars Bar) Date: Fri, 4 Nov 1994 11:21:10 +0000 In-Reply-To: simonc -- "Re: @2:2501/102" (Nov 3, 10:03pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92 (ORBIT)) To: sam-users@nvg.unit.no Subject: Re: @2:2501/102 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 759 Lines: 15 On Nov 3, 10:03pm in "Re: @2:2501/102", you warbled: ] Yes, there are billions of them -- but the best I've used is PDS and even ] then there are only a few things about it which makes it rate above comet -- ] and even then, comet wipes the floor with it on most things. Except that Comet won't let you add constants to a number in an IX instruction (I think that's what it was... something like) ie ld (ix+const+2) won't work even though it does on Lerm... sigh. Or has that been fixed in a later version? I doubt it... BassKeepsThumpingPumpingJumpingBassKeepsThumpingPumpingJumpingBassKeepsThumping PumpingJumpingBassKeepsPumpingBassKeepsPumpingGimmeASmileForTheFutureAndIHeard ItOnTheRadioAndISawItOnTheTelevisionBackIn1988... gaw-a@minster.york.ac.uk From imc Fri Nov 4 11:55:39 1994 Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Fri, 4 Nov 94 11:55:39 GMT In-Reply-To: ; from "Mars Bar" at Nov 4, 94 11:21 am X-Mailer: ELM [version 2.3 PL11] Content-Length: 403 Lines: 9 On Fri, 4 Nov 1994 11:21:10 +0000, Mars Bar said: > Except that Comet won't let you add constants to a number in an IX instruction > (I think that's what it was... something like) ie ld (ix+const+2) won't work > even though it does on Lerm... sigh. What about ld a,(ix-ix+foo)? I occasionally use that trick (where "ix" is a label placed at the location where IX will be set to, obviously). :-) imc From sam-users-owner@nvg.unit.no Fri Nov 4 12:09:32 1994 From: Simon Cooke To: sam-users@nvg.unit.no Date: Fri, 4 Nov 1994 13:09:09 GMT Subject: Re: @2:2501/102 Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <3A6B3FB2E41@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 581 Lines: 17 > ] Yes, there are billions of them -- but the best I've used is PDS and even > ] then there are only a few things about it which makes it rate above comet -- > ] and even then, comet wipes the floor with it on most things. > > Except that Comet won't let you add constants to a number in an IX instruction > (I think that's what it was... something like) ie ld (ix+const+2) won't work > even though it does on Lerm... sigh. > > Or has that been fixed in a later version? I doubt it... I don't think so... If you want, I can put it in Meteor (if I get around to it). :) Si From sam-users-owner@nvg.unit.no Fri Nov 4 14:07:49 1994 From: Nigel J Kettlewell Message-Id: <14620.199411041404@stone> Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Fri, 4 Nov 1994 14:04:18 +0000 (GMT) In-Reply-To: <4655@bgserv.demon.co.uk> from "Brian Gaff Sam Dept." at Nov 3, 94 21:10:58 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 510 Lines: 23 > > Keeping FATs in memory is fine... til the machine xrashes and > you aint written it yet! Or you use it on Floppies and swap > them... and you get messages like "You _MUST_ replace disk xxxxx in drive 1" every now and then.. > > Different tack. Bob (THE Bob) asked me if there is a CHEAP Z80 > assembler that works on a PC. Not on an emulator... Any ideas? > > Brian > Absolutely bound to be a PD one, there is for the Amiga. Check out ftp sites, and I'm certain you'll find at least one. Nige From sam-users-owner@nvg.unit.no Sun Nov 6 08:40:38 1994 From: Johnathan Taylor Date: 04 Nov 94 08:05:28 +0000 Subject: Re: Hard-Disk on sam Message-Id: <71b_9411041538@centron.com> Organization: Centronics BBS To: sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2704 Lines: 63 On <03 Nov 94 12:30> Ian.Collier@Comlab.Ox.Ac. wrote: Ia> On 03 Nov 94 04:35:00 +0000, Johnathan Taylor said: >> Hmm, that's a tricky one! On ProDos due >> to extensive cache'n ALL random-access >> positioning is calculated from scratch >> each time its required... Ia> I thought ProDos wrote CP/M format Ia> disks, so why does it need to cache Ia> anything? Ever heard of banked cp/m+? That was the next general upgrade that allowed Least Recently Used (LRU) cache'n of both directory and data sectors seperatly. ProDos share them and only upto 16k worth but one benifit is if you are dealing with multiple open files some read and some write it makes sense to cache part read sectors before flush to get a different one for a different file access which save seeking back and forth as 128 byte records are read from each file at a time. Also as all sector reads go via the 16k LRU cache then a random-read to an earlier positon within the cache is Well fast as it involves no drive activity:-) Also with some programs which use multiple small files, apart from the intermediate dir checksumming to make sure the floppy hadn't changed since last access the actual data can be read straight from the cache! Ia> If my calculations are correct, an Ia> entire FAT would require 128K so caching Ia> it would be rather expensive and Ia> therefore random access would be rather Ia> slow. I'm definitely not in favour of a FAT-based system. Hmm, well at a minimum I guess one doesn't have to cache the entire FAT maybe a bit-map of it when first logged in which is maintained during file operations and a FAT only LRU cache page.... I'd need tech docs on the FAT system to propose a half-decent access method soooo.... I'll leave that upto the person who's writing it:-) If it turns out to be unacceptably poor in performance and Si's willing to do more to improve it then all well and good but if it functions correctly, just slow compared to other machines HD systems then AFAIC Si's quite at liberty to say "it works! what more do you want!" As I don't see anybody else taking the production of a HD system on a sam under the native system at all seriously esp Bob! A working system is a working system after all, if you despise FATs that badly develope your own filesystem and get Si to incorperate it if it fits the specs! Johnathan ___ Olms 1.60 [Evaluation] +-------------------------------------------------------------------+ | Standard disclaimer: The views of this user are strictly his own | | ===> Gated @ Centronics BBS [centron.com] +44-1473-273246] <=== | +-------------------------------------------------------------------+ From sam-users-owner@nvg.unit.no Sun Nov 6 08:41:08 1994 From: Johnathan Taylor Date: 04 Nov 94 08:05:28 +0000 Subject: Re: @2:2501/102 Message-Id: <71c_9411041538@centron.com> Organization: Centronics BBS To: sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1607 Lines: 42 On <03 Nov 94 11:07> Frode.Tennebo@Himolde.No in response to Si' wrote: >> Out of interest, does *anyone* have any >> idea how MSDOS undeletes >> files? I can't see how it's able to do >> it, unless the second FAT is >> only updated on a new-file-write... Fr> MessDos deletes files by marking the Fr> first letter in the filename Fr> is marked '?'. The DOS recognizes the Fr> allocations in the FAT related Fr> to all files marked '?' as free and Fr> uses them as at will. To undelete Fr> all you have to replace the '?' with Fr> some legal character. Then IF you'r Fr> lucky and MS/DOS have not used any of Fr> the sectors related to that Fr> file, voila, you have an undeleted file. I presume that appart from swapping the char over you'd also have to force a re-logging of the drive if it's a fixed disk? Really! shades of stolen ideas from CP/M file handling! That just marks erased files with an 0E5h in the user area directory field and frees the allocated blocks bit-map of allocated blocks (aka clusters) Just one question.... Why then do the 2 MS-DOS undelete utils I've used NOT restore atleast the remaining unchanged chars in the name instead of the junk that they do? Probably somthing to do with Microsofts brilliant programmers.... NOT! Cheers Johnathan. ___ Olms 1.60 [Evaluation] +-------------------------------------------------------------------+ | Standard disclaimer: The views of this user are strictly his own | | ===> Gated @ Centronics BBS [centron.com] +44-1473-273246] <=== | +-------------------------------------------------------------------+ From sam-users-owner@nvg.unit.no Sun Nov 6 08:41:26 1994 From: Johnathan Taylor Date: 04 Nov 94 08:05:29 +0000 Subject: Re: Why cache CP/M? Message-Id: <720_9411041538@centron.com> Organization: Centronics BBS To: sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1462 Lines: 34 On <03 Nov 94 13:11> Ian.Collier@Comlab.Ox.Ac. wrote: >> > I thought ProDos wrote CP/M format >> > disks, so why does it need to cache >> > anything? Ia> Let me clarify that question. Why Ia> would calculating a random access on Ia> this system depend on caching, apart Ia> from storing the 32-byte directory Ia> entry(ies)? ... Oh never mind, I Ia> probably misunderstood the remark. Well when the cache contains the entire directory in which each extent contains its own allocation data one can calculate from the random record position to which physical extent to open and to find that extents allocation data one needs to pysically See the block allocation data and if its all in the cache then the only floppy access will be to seek the actual data on the disc, assuming it's not still in the cache from a prior read, in which case NO drive access at all would be required and hence very fast seeks are possible. If the cache only contains one or two directory sectors and they happen to be the ones we're after then fine as well! Does that explain it? If not don't worry, it works that's all that's important:-) Johnathan. ___ Olms 1.60 [Evaluation] +-------------------------------------------------------------------+ | Standard disclaimer: The views of this user are strictly his own | | ===> Gated @ Centronics BBS [centron.com] +44-1473-273246] <=== | +-------------------------------------------------------------------+ From sam-users-owner@nvg.unit.no Sun Nov 6 08:41:28 1994 From: Johnathan Taylor Date: 04 Nov 94 08:05:29 +0000 Subject: Re: Compression Message-Id: <71e_9411041538@centron.com> Organization: Centronics BBS To: sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2248 Lines: 50 On <03 Nov 94 10:31> Gaw-A@Minster.York.Ac.Uk wrote: Ga> I think that little shard was aimed at me... No idea, I just recolected that someone did an unfair comparison of an early lossless compression method with one thats well known to be lossy and therfore not relevent to general data compression techniques we were discussing;-) Ga> I know jpg isn't useful for anything Ga> but picture compression -- but that Ga> was entirely the point I was trying to Ga> get across - that people invent new Ga> compression techniques often simply to Ga> improve the compression of one type of data. Oh was that what you intended! Sorry I mis-understood. As the Sams graphics isn't so well developed that missing pixels wouldn't show I doubt we'd need to bother with jpg or fif format files anyway;-) AFAIK lossless archives which is what we were discussing are all designed to do the same job using the same data types ARC stolen into PKARC to PKPAK then to PKZIP because the law made him give up his theft of the ARC format... ZOO a seperate paralell development on another platform... LHArc .LZH designed as a portable definiton for PD compression development ARJ a comercial rival to PK without AFAIK the sordid past. PMArc is the LHArc envelope format with a custom PD method designed to run under Z80-CP/M only. LBR pre-date all the above and almost virtualises the exact cpm1.xx disc structure in a single file but using 128byte blocks instead of the usual 1k etc. designed to reduce losses assosiated with big allocation blocks etc. It even has utils that can set a .LBR file as a virtual disc-drive under cp/m2 and 3! Long before the PeeCee ever did it with stacker etc! Ga> ] ___ Olms 1.60 [Evaluation] Ga> Can someone explain this ^^ to me please??? Simple:- Off line mail system version 1.60 non-registerd shareware version It's the BBS QWK format mail-door that I've been using for ages:-) Regards. Johnathan. ___ Olms 1.60 [Evaluation] +-------------------------------------------------------------------+ | Standard disclaimer: The views of this user are strictly his own | | ===> Gated @ Centronics BBS [centron.com] +44-1473-273246] <=== | +-------------------------------------------------------------------+ From sam-users-owner@nvg.unit.no Sun Nov 6 08:41:29 1994 From: Johnathan Taylor Date: 04 Nov 94 08:05:28 +0000 Subject: Re: Sam Hard-Disk ideas Message-Id: <71d_9411041538@centron.com> Organization: Centronics BBS To: sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 4285 Lines: 97 On <03 Nov 94 10:42> Csl@Fs2.Ee.Umist.Ac.Uk wrote: >> After all the z80 is an 8/16bit chip >> 32bit operations can be done but require >> a lot of organisation to be both >> bugless AND fast IMHO whilst 16bit ops can be >> done quite easily and rapidly using >> right but non-standard methods:-) Cs> I'm still not sure... How about zoning Cs> to 16 bits? That way it will Cs> *appear* to have 16-bit partitions... Not sure about the terminology, so I daren't comment;-) 24bit maths using A and HL can be pretty simple and Fast would that be an acceptable compromise ie pretend were using 32bit pointers but really only use the 24bits that should allow more blocks than the current HD's allow:-) ADC, SBC and the various rotates and shift via carry flag can link them quite well without all the hassle of usin the alternate regs or too many other regs. Cs> I've got to sit down and work out how Cs> the MultiROM's BIOS is going to Cs> handle this... We've got a drive up Cs> and running atm (just connecting Cs> it to the SAM's bus), so we'll know Cs> more on Saturday. I think, if you Cs> use the BIOS to handle stuff it'll be Hmm. regarding CP/M+ sector access to be simple and not concered about stacks and sam<->cp/m+ page number translations I'd prefer to keep my own low-level sector routines in its designed place within the common portion of the bios, at least for now anyway. Also becuase although I'll want to be compatable with your system, for some time I'll not have one to use the bios in it;-) Cs> nicer, but as long as accesses Cs> follow a few basic ground rules (no Cs> treading on other people's Cs> partitions, use the MultiROM's RAM to Cs> check the config or work it out Cs> from the configuration partition Cs> (sector 1 of the disk, after the Cs> partition table in sector 2)), then it should all be okay. >From my cp/m+ bios point of view as long as the partition table is in a fixed location on the drive that'll be constant regardless of drive geometry or translated translation in progress ie the first side of the first cylinder then and the multi-rom knows to recognise the first pre-defined cp/m partition as the cp/m boot partition and simply loads the first sector into ram-bank zero and then jump to location zero with that cylinder number in say IXreg then I can write a boot loader that can load the system loader-proper directly from the remaining sectors on that cylinder and setup which can then read the partition table proper and decide how big and how many drives to give itself without stepping upon other filesystems:-) If all the data structures of the partition table are well defined and publicised and Assured to be constant by the time I get to putting the BOOT'able version on a HD then even though the Multi-ROM may not be in production it'll be quite easy to write a small AUTO run code file that'll perform the partition friendly cold boot for me until I get the real thing;-) As long as I write a native util to create the table and save my boot stuff in the right places.... oooo-heck! Cs> I'm planning to allow large caches -- Cs> probably not on floppies until Cs> the invisible upgrade occurs, which Cs> should allow us to autosense the Cs> drive change and basically treat the Cs> floppy drives like IDE! See my posting badly explaining prodos cache'n and a uninformed guess at a possible mechanism of dealing with FAT cache'n.... probably totally wrong but as you probably have the details to hand and I know next to nowt on FAT I'll leave it totally upto your judgment:-) Cs> It's to do with both -- for quick Cs> backwards random access and for Cs> file recovery. Hmm, I think trying to trace backwards could be more problem than its worth just for faster backwards relative positioning, but as I'm no expert.... feel free to ignore:-) Regards. Johnathan. PS Does this posting look better than the old method with the dodgy subject:? ___ Olms 1.60 [Evaluation] +-------------------------------------------------------------------+ | Standard disclaimer: The views of this user are strictly his own | | ===> Gated @ Centronics BBS [centron.com] +44-1473-273246] <=== | +-------------------------------------------------------------------+ From sam-users-owner@nvg.unit.no Sun Nov 6 08:41:47 1994 From: Johnathan Taylor Date: 04 Nov 94 08:05:29 +0000 Subject: File and Hard disk alloca Message-Id: <71f_9411041538@centron.com> Organization: Centronics BBS To: sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2917 Lines: 67 On <03 Nov 94 10:38> Csl@Fs2.Ee.Umist.Ac.Uk wrote: Cs> Yeah - I hate the way MS-DOS does Cs> that. It's not hard to look at the Cs> contents of the FAT to work out the Cs> number of free clusters, and Cs> *then* start to write the file, not Cs> the other way around. Some Cs> people, eh? That's right! Or in the situation when an app Knows the final size of its output file, WHY don't people do a random-write with zero-fill of previously unallocated sectors the entire output file... If an error ocours then just prompt for a new drive spec etc before true output starts... plus by creating the file as a blank sheet it'll be properly allocated and can be read whilst still being written to later on (For ZIP204 and RAR decompression without a massive dictionary buffer) Cs> It'll be more virtualised -- if you Cs> link paritions (in the final Cs> DOS), then they will appear to be the Cs> same -- you will be able to Cs> allocate partitions as subdirectories Cs> and vice versa. I'm thinking of Cs> implementing disk images -- you copy a Cs> SAM disk in, and tell the DOS Cs> to map it to drive 1 or drive 2 -- Cs> then you can do all the sector Cs> access as normal :) Is there a team of coders laying down the code or are you to be churning this all out on your own? If it works I'll be very impressed! Be prepared though to compromise, it's better than being forced to give-up due to overwhelming complexity part way through just to avoid admitting that some luxuries arn't worth the coding involved, remember that most modern OS's that do the things you envisage are either written in a HLL compiled language (NT,unix) or have teams of specialist well paid coders working exclusivly on them or both! Cs> It's the former -- LBA mode, set as Cs> part of the features register, Cs> allows you to use 24bit (I think -- Cs> not got the specs in front of me) Cs> logical sector numbers to address the Cs> hard disk. Will make it a *LOT* Cs> easier, and also will make it a piece Cs> of cake to convert to SCSI or Cs> even to an IDE CD Rom drive using its Cs> seconds based address scheme. I'll have get that ATA doc over on this machine and give it bloody good read.. Plus there's a posibility that some early PeeCee oriented drives might not implement that feature! Also it is reported that not all IDE drives support free format tanslated translates, some only do the ones required to get a peecee-clone talking to it and ignore all other translate requests:-( Partition table will be in cylinders though, won't it? I hope so anyway:-) Cheers. Johnathan. ___ Olms 1.60 [Evaluation] +-------------------------------------------------------------------+ | Standard disclaimer: The views of this user are strictly his own | | ===> Gated @ Centronics BBS [centron.com] +44-1473-273246] <=== | +-------------------------------------------------------------------+ From sam-users-owner@nvg.unit.no Sun Nov 6 08:41:49 1994 From: Johnathan Taylor Date: 04 Nov 94 08:05:29 +0000 Subject: Re: Compression Message-Id: <721_9411041538@centron.com> Organization: Centronics BBS To: sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 7743 Lines: 171 In a message to All <03 Nov 94 13:02> Ian.Collier@Comlab.Ox.Ac. wrote: Ia> On 03 Nov 94 04:35:00 +0000, Johnathan Taylor said: .. >> A gzip'd tar must first be decompressed in its entirety. Ia> Your answer is quite correct, but it Ia> is to a different question... It Ia> is true that if a gzip file gets Ia> corrupted then that's it. However I I didn't understand the question as it didn't apear relevent to what I said/meant in the text you quoted prior to it, so I guessed at what you wanted and got it wrong, obviously;-) Ia> think specially catering for corrupted Ia> files is not the main aim of a Ia> compression/archive system. It's not, it's just a valuable advantage:-) Ia> Anyway, the explanation that I Ia> actually wanted was of the following Ia> sentence: >jet> Plus I'd want >jet> to be able combine assosiated files >jet> into a single archive not a seperate >jet> lose-able bunch of seperatly compressed files! Ia> So why is a single compressed file any Ia> more lose-able than any other kind of Ia> file? What I meant by a bunch of lose-able sperate files is when you have 1000 readme files for a 1000 different programs or whats.new etc. Keeping all files related to a particular program in one archive with random access to individual members allows easy access to locate a single programs assosiated files without having to resort to sticking each bunch of files in their own directory or resorting to obtuse 32bit HEX digit names to uniquly ID individual compressed files requiring some form of data-base to re-create human readable named access to individual files... Does that explain what I meant? If not don't worry about it! Ia> How is this different from LZ77? AFAIK LZ77 is a distinct 2-stage process and requires the addition of the encoding tree prior to starting of the actual encoded bit-stream, Whilst LZHUF does it on the fly so to speak, this also means that LZHUFF can actually even compress small files of less than 100bytes but LZ77 cannot! Plus dictionary size for dictionary size LZHUF generally produces better compression than LZ77 it's only problem is that the encode alogerithm is a bit more processor intensive which is probably why LZHUF -lh5- only uses an 8k dictionary whilst LZ77 has HAD to grow to 32k(ZIP) or 64k(RAR) to beat it on 99% of file types. >> These ARE ALL Documented in various places on >> the nets, so those with direct access >> to all those net tools should be able >> to locate them themselves! Ia> There are quite a lot of things on the Ia> net actually, so you will have to Ia> narrow down the search a little more than that. Heck I duno what the facility of the online tools are! Isn't it called archie or somthing... ask it to look for LHA or LZHUF that's one reason I capitalise those words..... >> >> The thing about gzip is that it uses >> >> very little RAM to decompress (apart >> >> from having to store each block of the >> >> file >> I don't know WHO wrote the above >> paragraph imc maybe... but GET REAL! gzip and >> PKUNZIP2.04g etc are required to keep a >> running 32K ring-buffer OR rely on >> flawless random file access of the >> output stream in order to get at the 32k >> sliding dictionary! Ia> Which is implied by "storing each Ia> block of the file" (if the blocks are 32K. Didn't you know that it uses a 32k sliding window? Ia> Note: I did _not_ mean disk blocks. So? does this mean that it uses any less ram just because you chose not to name that 'block' size? 32k is half the available address space! then you need to add the program code size, main tables size input and output file handling interface into Sam-Dos.... I know decompression *CAN* be done with a z80 but why bother when the Sam cannot compress the archives and probably never will be able to do DeflatX compression! The only use I'd see for such a util is to inflate tar.z file from a unix box... If that was the requirement then I'd do what I do now and inflate them on the unix box and LHA re-compress them and use PMEXT.COM under prodos or port LHA to sam-dos which should be much easier than gzip! Ia> Do you remember how this started? By Ia> me saying I might write one. I do remeber but have you started yet? Well assuming you were serious may I suggest that you don't *AIM* for gzip as its only a partial product! Which is one reason why I am so against the waste of effort in writing it for the SAM. The full product is a ZIP and UNZIP! Actually IF you did that then yould only need to make the UNZIP portion handle deflated files as the ZIP portion could still achieve reasonable ratios using the older implode alogerithm which is the same as deflate but uses a 4 or 8k sliding dictionary and IS supported by the latest PKUNZIP and the latest portable UNZIP50p? infozip project.. And is more likely to fit reasonably into the sam scheme of things:-) And I'm sure Si'll be very glad to hear of a ZIP/UNZIP for sam native mode if you can write it:-) >> As if deflate was the BEST lossless >> compression method... Ever heard of RAR? Ia> No I haven't. Well there's loads of stuff you seem to be missing info on.. If you've got live net access I suggest you go digging through some of those internet sites and have a read about what the real alternatives are for yourself, after all if you don't believe me go get the tech docs and read for your self:) >> Oh btw LZHuff can compress some LZW >> encoded stuff a bit further! Ia> Perhaps, but you are better off Ia> uncompressing the LZW first before trying Ia> another compression method. Of course, but it proves that LZHuff is more robust when compressing awkward data than LZW. LZ77 gets around the stuation of uncompressable stuff by resorting to temporarily giving up and simply storing the awkward 32k section, LZHUFF generally speaking doesn't come across this sort of situation often enough to warrent such a drastic change in format as was done when PKZIP204 was released. A reason I feel LHARC format is better for the SAM than the ZIP format is that although both forms can hold all the sam-specific file attribute info, the LHARC format can also be implemented on the humble 48k speccy with disks and could contain speccy file info too! It just seems more logical to use a format that's free from license restrictions and easy to implement as a non-rambound utility file serialization utility that works without needing vast amount of ram to function in. Oh btw even the old -lh1- LZHUF method is amazingly more effective than the old 16-bit unix.Z compress method at compression and resource requirements. When I receive tar.Z archives on my SAM I always zcat 'em and re-compress them straight away with PMARC (the z80 LZHUFF derivative). That reduces the overal size of the compressed tar by at least another 3rd smaller than the unix-compressed tar size. Until I can sort out a clean floppy to detar it and archive the tar members properly so they're useable but still much smaller than the original tar.Z archive! Would you imc mind if we let this thread taper off please as I've got other things I need to be doing rather than aurguing the toss about somthing as trivial as this to save you wasted effort when I want to get on with other more pressing stuff and you've got to re-aquaint yourself with your recently obtained SAM;-) Cheers Johnathan. ___ Olms 1.60 [Evaluation] +-------------------------------------------------------------------+ | Standard disclaimer: The views of this user are strictly his own | | ===> Gated @ Centronics BBS [centron.com] +44-1473-273246] <=== | +-------------------------------------------------------------------+ From sam-users-owner@nvg.unit.no Sun Nov 6 08:42:15 1994 From: Johnathan Taylor Date: 06 Nov 94 02:18:56 +0000 Subject: Re: z80 cross assemblers for peecees Message-Id: Organization: Centronics BBS To: sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1080 Lines: 36 On (04 Nov 94) Ian.Collier@comlab.ox.ac. wrote... > Date: Fri, 4 Nov 1994 11:57:58 +0100 > From: Ian.Collier@comlab.ox.ac.uk > > On Thu, 03 Nov 1994 21:10:58 GMT, Brian Gaff Sam Dept. said: Hmm I missed BGs' original! anyway... snip... > > Different tack. Bob (THE Bob) asked me if there is a CHEAP Z80 > > assembler that works on a PC. Not on an emulator... Any ideas? There's at least 2! TASM which is a table driven jobby that'll accept different tables for different target cpu's. Or UASM which is similar but the op code table is a compile time option but the archive I've seen comes with a few pre-compiled versions for various 8-bit cpu's Facilities offered by these things are rather simple compared to native z80 relocating macro assemblers but they work well enough for simple routines:) Both are non-comercial AFAIK. Does this mean Bobs actually going to try some MC programming, oo-eck CYL Johnathan.  -- |Fidonet: Johnathan Taylor 2:2501/307.9 |Internet: jet@centron.com | | Standard disclaimer: The views of this user are strictly his own. From imc Sun Nov 6 13:03:54 1994 Subject: Re: @2:2501/102 To: sam-users@nvg.unit.no Date: Sun, 6 Nov 94 13:03:54 GMT In-Reply-To: <71c_9411041538@centron.com>; from "Johnathan Taylor" at Nov 4, 94 8:05 am X-Mailer: ELM [version 2.3 PL11] Content-Length: 637 Lines: 16 On 04 Nov 94 08:05:28 +0000, Johnathan Taylor said: > Really! shades of stolen ideas from CP/M file handling! That just marks erased > files with an 0E5h in the user area directory field and frees the allocated > blocks bit-map of allocated blocks (aka clusters) +3DOS doesn't have an allocated blocks bitmap, as far as I know (it just calculates the list of free blocks by reading all the directory entries). > Just one question.... Why then do the 2 MS-DOS undelete utils I've used NOT > restore atleast the remaining unchanged chars in the name instead of the junk > that they do? Why are you not using Norton utilities? imc From imc Sun Nov 6 13:29:03 1994 Subject: Re: Compression To: sam-users@nvg.unit.no Date: Sun, 6 Nov 94 13:29:03 GMT In-Reply-To: <721_9411041538@centron.com>; from "Johnathan Taylor" at Nov 4, 94 8:05 am X-Mailer: ELM [version 2.3 PL11] Content-Length: 1846 Lines: 43 On 04 Nov 94 08:05:29 +0000, Johnathan Taylor said: > What I meant by a bunch of lose-able sperate files is when you have 1000 > readme files for a 1000 different programs or whats.new etc. Keeping all files > related to a particular program in one archive with random access to > individual members allows easy access That's what directories are for. It's no use complaining about how to store loads of separately compressed files when you will have exactly the same problem just after you extract the files even if they are in a library. > AFAIK LZ77 is a distinct 2-stage process and requires the addition of the > encoding tree prior to starting of the actual encoded bit-stream, Whilst LZHUF > does it on the fly so to speak, I still don't see the difference. As far as I know it's not possible to generate Huffman tables without doing them in advance; besides which, if a pre-defined Huffman tree is used then this doesn't need to be either calculated or stored in the file. > does it on the fly so to speak, this also means that LZHUFF can actually even > compress small files of less than 100bytes but LZ77 cannot! Oh yes it can... -rw-r--r-- 1 imc 77 Nov 6 13:24 /tmp/test -rw-r--r-- 1 imc 95 Nov 6 13:24 /tmp/test.gz Since gzip adds a header of approcimately 25 bytes, that represents an improvement. > Heck I duno what the facility of the online tools are! Isn't it called archie > or somthing... ask it to look for LHA or LZHUF that's one reason I capitalise > those words..... OK, I've found some C source for lharc. However there are absolutely no docs (except for the usage notes which are written in Japanese) and the source is more or less uncommented. Archie can be useful for searching the net, but you need to know what you are looking for with a moderate amount of detail. imc From imc Sun Nov 6 13:31:01 1994 Subject: Re: Sam Hard-Disk ideas To: sam-users@nvg.unit.no Date: Sun, 6 Nov 94 13:31:01 GMT In-Reply-To: <71d_9411041538@centron.com>; from "Johnathan Taylor" at Nov 4, 94 8:05 am X-Mailer: ELM [version 2.3 PL11] Content-Length: 286 Lines: 9 On 04 Nov 94 08:05:28 +0000, Johnathan Taylor said: > PS Does this posting look better than the old method with the dodgy subject:? Yes, but could you possibly keep the lengths of your sentences down and use more full stops, because it would then be easier to read... Thanks :-) imc From sam-users-owner@nvg.unit.no Mon Nov 7 09:49:00 1994 From: Simon Cooke To: sam-users@nvg.unit.no Date: Mon, 7 Nov 1994 10:54:57 GMT Subject: Re: Hard-Disk on sam Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <3EC794E6DDB@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 932 Lines: 26 > If it turns out to be unacceptably poor in performance and Si's willing to do > more to improve it then all well and good but if it functions correctly, just > slow compared to other machines HD systems then AFAIC Si's quite at liberty to > say "it works! what more do you want!" As I don't see anybody else taking the > production of a HD system on a sam under the native system at all seriously > esp Bob! > > A working system is a working system after all, if you despise FATs that badly > develope your own filesystem and get Si to incorperate it if it fits the > specs! Well, it'll be possible to roll your own o/s and sit it in the hd -- no problem with that, I'm designing so that you can even boot from the CP/M partition if you want :) Oh, and the access is slow, but still at least 25% faster than the disk drive. And you don't have to disable interrupts. And it's easier to program too. :) Si Cooke From sam-users-owner@nvg.unit.no Mon Nov 7 09:59:53 1994 From: Simon Cooke To: sam-users@nvg.unit.no Date: Mon, 7 Nov 1994 11:05:47 GMT Subject: Re: File and Hard disk alloca Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <3ECA7B73086@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2427 Lines: 91 > That's right! Or in the situation when an app Knows the final size of its > output file, WHY don't people do a random-write with zero-fill of previously > unallocated sectors the entire output file... If an error ocours then just > prompt for a new drive spec etc before true output starts... plus by creating > the file as a blank sheet it'll be properly allocated and can be read whilst > still being written to later on (For ZIP204 and RAR decompression without a > massive dictionary buffer) Yeah, really crappy isn't it :) > Is there a team of coders laying down the code or are you to be churning this > all out on your own? If it works I'll be very impressed! Be prepared though to > compromise, it's better than being forced to give-up due to overwhelming > complexity part way through just to avoid admitting that some luxuries arn't > worth the coding involved, remember that most modern OS's that do the things > you envisage are either written in a HLL compiled language (NT,unix) or have > teams of specialist well paid coders working exclusivly on them or both! It's just me, myself and I ... although I could definitely do with some help on the network side of things *grins* Btw: the network will work with the drive running, so that will help I suppose :) > Cs> It's the former -- LBA mode, set as > Cs> part of the features register, > Cs> allows you to use 24bit (I think -- > Cs> not got the specs in front of me) > Cs> logical sector numbers to address the > Cs> hard disk. Will make it a *LOT* > Cs> easier, and also will make it a piece > Cs> of cake to convert to SCSI or > Cs> even to an IDE CD Rom drive using its > Cs> seconds based address scheme. > > I'll have get that ATA doc over on this machine and give it bloody good read.. > Plus there's a posibility that some early PeeCee oriented drives might not > implement that feature! > Also it is reported that not all IDE drives support free format tanslated > translates, some only do the ones required to get a peecee-clone talking to it > and ignore all other translate requests:-( Afraid so... the BIOS will contain some conversion routines anyway for drives which don't support it direct. > Partition table will be in cylinders though, won't it? I hope so anyway:-) It can be if you want (probably have to be now though :( ) > Cheers. > Johnathan. No probs Si From sam-users-owner@nvg.unit.no Mon Nov 7 10:01:33 1994 Date: Mon, 07 Nov 94 10:51:01 MET From: Milan Salajka Subject: Sam > Multisync SVGA To: sam-users@nvg.unit.no Message-Id: <"alfie.uib..415:07.10.94.09.57.40"@uib.no> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 62 Lines: 2 What about connecting sam to svga monitor ? Is it possible ? From sam-users-owner@nvg.unit.no Mon Nov 7 10:02:22 1994 Message-Id: From: simonc@jumper.mcc.ac.uk (Simon Cooke) Subject: Births & Anniversaries To: sam-users@nvg.unit.no Date: Mon, 7 Nov 1994 09:59:39 +0000 (GMT) Cc: simonc@jumper.mcc.ac.uk (Simon Cooke) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 656 Lines: 21 Simon Cooke and Martin Rookyard would like to announce the birth of their brand new bouncing baby girl. She was conceived on Tuesday last week, and was born on Friday night; after a few complications on Sunday by 3pm she was doing her first I/O and gurgling (or was she drive stepping? But I digress). Anyway, she loaded her first screen at 6pm on Sunday, and MasterDOS was accessing her as a drive by 1am last night, although we had to throw a bucket of water over it to get it to leave the poor baby alone. Anyway, that's all the news that's fit to print... WELCOME TO YOUR SAM HARD-DRIVE FOLKS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! PARTY! Si From sam-users-owner@nvg.unit.no Mon Nov 7 10:12:09 1994 From: Robert Partington Message-Id: <9411071006.AA00832@n4e.cs.man.ac.uk> Subject: Re: Sam > Multisync SVGA To: sam-users@nvg.unit.no Date: Mon, 7 Nov 1994 10:06:28 +0000 (GMT) In-Reply-To: <"alfie.uib..415:07.10.94.09.57.40"@uib.no> from "Milan Salajka" at Nov 7, 94 10:51:01 am Risc-Header: ARMed X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 226 Lines: 5 I had a cable from the SCART on the back of the SAM to my Acorn AKF17 Multisync monitor. It worked fine for me. Shame I lost the power supply and the cable got cannibalised for the Amiga (blame SensiSoccer and Settlers!). :) From sam-users-owner@nvg.unit.no Mon Nov 7 10:25:29 1994 Message-Id: From: gaw-a@minster.york.ac.uk (Mars Bar) Date: Mon, 7 Nov 1994 10:10:22 +0000 In-Reply-To: CSL -- "Re: Hard-Disk on sam" (Nov 7, 10:54am) X-Mailer: Mail User's Shell (7.2.5 10/14/92 (ORBIT)) To: sam-users@nvg.unit.no Subject: Re: Hard-Disk on sam Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 850 Lines: 23 On Nov 7, 10:54am in "Re: Hard-Disk on sam", you warbled: ] Oh, and the access is slow, but still at least 25% faster than the ] disk drive. And you don't have to disable interrupts. And it's easier ] to program too. WHA?????? 25%? You are kidding, right? Are we talking Amiga A590 upgrade here or what? I want a Hard Drive with a decent access time or not one at all. I'm not buying one at that speed. If it's the processor, get a DMA chip, for Chrissakes. They're really easy to program, fast (ish) and cheap too. ] :) I'm surprised you can smile, Si... Oh yeah... how's the processor upgrade coming on? BassKeepsThumpingPumpingJumpingBassKeepsThumpingPumpingJumpingBassKeepsThumping PumpingJumpingBassKeepsPumpingBassKeepsPumpingGimmeASmileForTheFutureAndIHeard ItOnTheRadioAndISawItOnTheTelevisionBackIn1988... gaw-a@minster.york.ac.uk From sam-users-owner@nvg.unit.no Mon Nov 7 10:34:08 1994 Date: Mon, 7 Nov 1994 10:37:44 GMT Message-Id: <9411071037.AA00296@bsps2.staffs.ac.uk> From: cm3hdlt%3.6.dnet.ac.uk@bsps2.staffs.ac.uk \(\) (Last exit for the lost \(a.k.a goth.black.soc\)) To: sam@bsps2.staffs.ac.uk Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 701 Lines: 22 >Simon Cooke and Martin Rookyard would like to announce the birth of their >brand new bouncing baby girl. Congratulations :) >She was conceived on Tuesday last week, and was born on Friday night; after >a few complications on Sunday by 3pm she was doing her first I/O and >gurgling (or was she drive stepping? But I digress). > >Anyway, she loaded her first screen at 6pm on Sunday, and MasterDOS was >accessing her as a drive by 1am last night, although we had to throw a >bucket of water over it to get it to leave the poor baby alone. Gimmie, Gimmie >WELCOME TO YOUR SAM HARD-DRIVE >FOLKS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Bet this will piss Bob of - yerrsse! :) The Black Vegetable! From sam-users-owner@nvg.unit.no Mon Nov 7 12:04:47 1994 From: Simon Cooke To: sam-users@nvg.unit.no Date: Mon, 7 Nov 1994 13:10:32 GMT Subject: Re: Sam > Multisync SVGA Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <3EEBBED1FF1@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 339 Lines: 14 > > What about connecting sam to svga monitor ? Is it possible ? Martin Rookyard offered to build interfaces to do it for 15 quid a shot to Format; they never printed anything about it, so the idea was ditched. If you want one, have a moan at Bob Brenchley and as him why he didn't print the offer of one made by Rooksoft :) Si From sam-users-owner@nvg.unit.no Mon Nov 7 12:05:54 1994 From: Simon Cooke To: sam-users@nvg.unit.no Date: Mon, 7 Nov 1994 13:13:03 GMT Subject: Re: Hard-Disk on sam Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <3EEC68356DF@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 954 Lines: 33 > ] Oh, and the access is slow, but still at least 25% faster than the > ] disk drive. And you don't have to disable interrupts. And it's easier > ] to program too. > > WHA?????? 25%? You are kidding, right? > > Are we talking Amiga A590 upgrade here or what? Can't be helped -- It's a WD Caviar 280 hd, and I'm polling it as fast as I can. If you want DMA, it'll be another 15 quid on the price -- and I'm not joking about that. > I want a Hard Drive with a decent access time or not one at all. I'm not > buying one at that speed. If it's the processor, get a DMA chip, for > Chrissakes. They're really easy to program, fast (ish) and cheap too. I know, I know, but they *cost*. > ] :) > > I'm surprised you can smile, Si... > > Oh yeah... how's the processor upgrade coming on? Give us a month -- Martin's put his and my ideas into a schematic over the past week, just got to prototype it now. :) Things are going quite well :) Si From sam-users-owner@nvg.unit.no Mon Nov 7 12:45:57 1994 From: Frode Tennebo Message-Id: <199411071242.AA07729@ulke.hiMolde.no> Subject: Re: Births & Anniversaries To: sam-users@nvg.unit.no Date: Mon, 7 Nov 1994 13:42:36 +0100 (MET) In-Reply-To: from "Simon Cooke" at Nov 7, 94 09:59:39 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1104 Lines: 39 > > Simon Cooke and Martin Rookyard would like to announce the birth of their > brand new bouncing baby girl. Congrats! > > She was conceived on Tuesday last week, and was born on Friday night; after > a few complications on Sunday by 3pm she was doing her first I/O and > gurgling (or was she drive stepping? But I digress). > > Anyway, she loaded her first screen at 6pm on Sunday, and MasterDOS was > accessing her as a drive by 1am last night, although we had to throw a > bucket of water over it to get it to leave the poor baby alone. > > Anyway, that's all the news that's fit to print... > > > WELCOME TO YOUR SAM HARD-DRIVE > FOLKS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! What about inviting Bob over to see the little offspring? > > > PARTY! I'll salute you with a glass of juice when I get home toonight! > > Si > -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Mon Nov 7 12:49:14 1994 From: Frode Tennebo Message-Id: <199411071245.AA07780@ulke.hiMolde.no> Subject: Re: Hard-Disk on sam To: sam-users@nvg.unit.no Date: Mon, 7 Nov 1994 13:45:04 +0100 (MET) In-Reply-To: <3EEC68356DF@fs2.ee.umist.ac.uk> from "Simon Cooke" at Nov 7, 94 01:13:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 350 Lines: 18 > > :) > > Things are going quite well :) What about school??? *grin* > > Si > > -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Mon Nov 7 13:05:27 1994 From: Simon Cooke To: sam-users@nvg.unit.no Date: Mon, 7 Nov 1994 14:06:09 GMT Subject: Re: Hard-Disk on sam Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Message-Id: <3EFA8F22206@fs2.ee.umist.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 94 Lines: 8 > > Things are going quite well :) > > What about school??? *grin* Heheheheheheheh :) Si From sam-users-owner@nvg.unit.no Mon Nov 7 13:27:08 1994 Message-Id: From: gaw-a@minster.york.ac.uk (Mars Bar) Date: Mon, 7 Nov 1994 13:02:23 +0000 In-Reply-To: CSL -- "Re: Hard-Disk on sam" (Nov 7, 1:13pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92 (ORBIT)) To: sam-users@nvg.unit.no Subject: Re: Hard-Disk on sam Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 994 Lines: 24 On Nov 7, 1:13pm in "Re: Hard-Disk on sam", you warbled: ] Can't be helped -- It's a WD Caviar 280 hd, and I'm polling it as ] fast as I can. If you want DMA, it'll be another 15 quid on the price ] -- and I'm not joking about that. Come on... a hard drive that goes at a speed even of the same _order_ as a disk drive is going to be shite. ] I know, I know, but they *cost*. 15 quid? I don't care a **** about 15 quid. It's when you get to talking about paying 20 quid or whatever for a two-face that I start getting irritated. ] Give us a month -- Martin's put his and my ideas into a schematic ] over the past week, just got to prototype it now. Now if you could stick that on the same board as the IDE iface it would really be worth buying... BassKeepsThumpingPumpingJumpingBassKeepsThumpingPumpingJumpingBassKeepsThumping PumpingJumpingBassKeepsPumpingBassKeepsPumpingGimmeASmileForTheFutureAndIHeard ItOnTheRadioAndISawItOnTheTelevisionBackIn1988... gaw-a@minster.york.ac.uk From sam-users-owner@nvg.unit.no Mon Nov 7 13:38:05 1994 From: "Doore, Daniel [MIS]" To: Sam Users Subject: Dead monitor or knacked SAM? Date: Mon, 07 Nov 94 13:04:00 PST Message-Id: <2EBE963D@courier.lmu.ac.uk> Encoding: 17 TEXT X-Mailer: Microsoft Mail V3.0 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 614 Lines: 17 Just as a sideline to detract from the hard-core typing involving FATS, allocation tables and yer basic my-caching-algorithms-better-than-yours type debate... I have a Sony Triniton 14" TV with a fully-featured SCART socket connected via liner RGB lines to my SAM. I have begun to notice that at the top left of the screen (mostly in the border) the reds are all washed out. I know it is NOT tube burn cos the SNES and video work fine, any suggestions people? It could be the pin out on one of my SCART sockets is wrong, but they are wired as the Tech. Manual says (perhaps that's what's wrong..) Dan Doore. From imc Mon Nov 7 13:44:12 1994 Subject: Re: Dead monitor or knacked SAM? To: sam-users@nvg.unit.no Date: Mon, 7 Nov 94 13:44:12 GMT In-Reply-To: <2EBE963D@courier.lmu.ac.uk>; from "Doore, Daniel [MIS]" at Nov 7, 94 1:04 pm X-Mailer: ELM [version 2.3 PL11] Content-Length: 588 Lines: 16 On Mon, 07 Nov 94 13:04:00 PST, Doore, Daniel [MIS] said: > I know it is NOT tube burn cos the SNES and video work fine, > any suggestions people? This may be a silly question, but have you tried connecting the Sam to the TV via the UHF output ot see whether the same thing occurs? It could be a temporary phosphor overload-type thing. I remember when I used to connect my speccy to the TV one corner would slowly turn pink and another would slowly turn green, but the effect was not visible while watching normal TV programmes. Not that I know anything about TVs, of course... imc From sam-users-owner@nvg.unit.no Mon Nov 7 14:03:35 1994 Date: Mon, 07 Nov 94 14:51:04 MET From: Milan Salajka Subject: Re: Sam > Multisync SVGA To: Sam Users In-Reply-To: Message of Mon, 7 Nov 1994 10:06:28 +0000 (GMT) from Message-Id: <"alfie.uib..201:07.10.94.13.55.25"@uib.no> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 189 Lines: 7 > I had a cable from the SCART on the back of the SAM to my Acorn > AKF17 Multisync monitor. It worked fine for me. It was only a cable ? Or it was a cable plus an interface ? Milan From sam-users-owner@nvg.unit.no Mon Nov 7 14:04:04 1994 From: Robert Partington Message-Id: <9411071401.AA01529@n4e.cs.man.ac.uk> Subject: Re: Sam > Multisync SVGA To: sam-users@nvg.unit.no Date: Mon, 7 Nov 1994 14:01:19 +0000 (GMT) In-Reply-To: <"alfie.uib..201:07.10.94.13.55.25"@uib.no> from "Milan Salajka" at Nov 7, 94 02:51:04 pm Risc-Header: ARMed X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 230 Lines: 6 All I had was a cable with 6 or 7 wires connected from the SCART on the SAM to a 15 pin socket to attach the monitor cable to. SCART outputs RGB and syncs so you just wire these to the appropriate place on your monitor AFAIK. :) From sam-users-owner@nvg.unit.no Mon Nov 7 14:16:57 1994 Date: Mon, 07 Nov 94 15:05:47 MET From: Milan Salajka Subject: Re: Sam > Multisync SVGA To: Sam Users In-Reply-To: Message of Mon, 7 Nov 1994 14:01:19 +0000 (GMT) from Message-Id: <"alfie.uib..644:07.10.94.14.09.04"@uib.no> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 333 Lines: 13 > All I had was a cable with 6 or 7 wires connected from the SCART on > the SAM to a 15 pin socket to attach the monitor cable to. SCART > outputs RGB and syncs so you just wire these to the appropriate place > on your monitor AFAIK. > :) Mhhh, but SVGA monitor hasn't got CSYNC signal, it has VSYNC and HSYNC... :( Milan From sam-users-owner@nvg.unit.no Mon Nov 7 16:22:12 1994 Date: Mon, 07 Nov 94 15:39:37 MET From: Milan Salajka Subject: Re: Sam > Multisync SVGA To: Sam Users In-Reply-To: Message of Mon, 7 Nov 1994 13:10:32 GMT from Message-Id: <"alfie.uib..558:07.10.94.14.45.58"@uib.no> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 390 Lines: 15 >> What about connecting sam to svga monitor ? Is it possible ? > Martin Rookyard offered to build interfaces to do it for 15 quid a > shot to Format; they never printed anything about it, so the idea was > ditched. And does is the scheme available ? > If you want one, have a moan at Bob Brenchley and as him why he > didn't print the offer of one made by Rooksoft :) :( Milan From sam-users-owner@nvg.unit.no Mon Nov 7 16:23:36 1994 Message-Id: From: simonc@jumper.mcc.ac.uk (Simon Cooke) Subject: Re: Hard-Disk on sam To: sam-users@nvg.unit.no Date: Mon, 7 Nov 1994 16:05:11 +0000 (GMT) Cc: simonc@jumper.mcc.ac.uk (Simon Cooke) In-Reply-To: from "Mars Bar" at Nov 7, 94 01:02:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 948 Lines: 31 > Come on... a hard drive that goes at a speed even of the same _order_ as a > disk drive is going to be shite. Okay... point taken... > ] I know, I know, but they *cost*. > > 15 quid? I don't care a **** about 15 quid. It's when you get to talking > about paying 20 quid or whatever for a two-face that I start getting > irritated. Alright then, I'll get Martin to work on it. There will be three versions: One with just the boot ROM and one with DMA -- the DMA one will be cheaper... *sighs*... hassles eh? ;) Some people just ain't happy :) > ] Give us a month -- Martin's put his and my ideas into a schematic > ] over the past week, just got to prototype it now. > > Now if you could stick that on the same board as the IDE iface it would > really be worth buying... *grins*, but it'd cost over 100 quid!!!!!!!!! Si :) ps Geoff.. you sound... well, disheartened ... gotta remember, we've only had it up and running for 3 days... From sam-users-owner@nvg.unit.no Mon Nov 7 16:51:22 1994 From: "Doore, Daniel [MIS]" To: Sam Users Subject: Re: Dead monitor or knacked SAM? Date: Mon, 07 Nov 94 16:40:00 PST Message-Id: <2EBEC8E2@courier.lmu.ac.uk> Encoding: 31 TEXT X-Mailer: Microsoft Mail V3.0 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 848 Lines: 31 > From: sam-users-owner > To: sam-users > Subject: Re: Dead monitor or knacked SAM? > Date: 07 November 1994 14:44 > > On Mon, 07 Nov 94 13:04:00 PST, Doore, Daniel [MIS] said: > > > I know it is NOT tube burn cos the SNES and video work fine, > > any suggestions people? > > This may be a silly question, but have you tried connecting the Sam to > the TV via the UHF output ot see whether the same thing occurs? I can't - my modulator died long ago ;) > It could be a temporary phosphor overload-type thing. I remember when I > used to connect my speccy to the TV one corner would slowly turn pink and > another would slowly turn green, but the effect was not visible while > watching normal TV programmes. That sounds like the fella, can it be prevented though.... > Not that I know anything about TVs, of course... Natch. Dan. > imc > From sam-users-owner@nvg.unit.no Mon Nov 7 17:13:51 1994 Message-Id: From: gaw-a@minster.york.ac.uk (Mars Bar) Date: Mon, 7 Nov 1994 16:44:30 +0000 In-Reply-To: simonc -- "Re: Hard-Disk on sam" (Nov 7, 4:05pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92 (ORBIT)) To: sam-users@nvg.unit.no Subject: Re: Hard-Disk on sam Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2187 Lines: 54 On Nov 7, 4:05pm in "Re: Hard-Disk on sam", Cookie warbled: ] Okay... point taken... :) ] Alright then, I'll get Martin to work on it. There will be three versions: ] One with just the boot ROM and one with DMA -- the DMA one will be ] cheaper... Do you mean that? Or t'other way round? ] *sighs*... hassles eh? ;) Some people just ain't happy :) Mmmmmmm.... I'd be happy if I could have a DMA that was programmable (the standard z8040 or whatever it's called would be nice, but the ZILOG version, not the SGS Thompson crap, which misses out on the nicest mode !) so that I could get it to do _just_ what I wanted... ] > Now if you could stick that on the same board as the IDE iface it would ] > really be worth buying... ] ] *grins*, but it'd cost over 100 quid!!!!!!!!! But most people would want both... if you want to speed up your sam, the best way to do it is with a processor upgrade. And if you speed up the processor, you're not going to want to sit around waiting while you change disks all the while, are you.... :) ] ps Geoff.. you sound... well, disheartened ... gotta remember, we've only ] had it up and running for 3 days... Mmmmmm.... I'm disheartened. It's the way we were told to write the music for Stryker's Run 3 on the Arch (remember Strykers Run and Droid on the Beeb?) by last friday so we spent most of last week writing it and then they came back and said `oh actually we don't need it til about Christmas'.... Watch out for that game, btw, it's got some truly amazing 3-channel music on it. As to being disheartened about the Sam... I am. I still haven't connected it up since I got back from Holidays, and that was 4 weeks ago it's just sitting in my room... I really am just waiting til your little upgrade board comes out - I can't stand programming on a machine that feels like it needs a good kick up the arse. Did you say colin was working on a sound card? Hope it's got more than 4 channels... :) BassKeepsThumpingPumpingJumpingBassKeepsThumpingPumpingJumpingBassKeepsThumping PumpingJumpingBassKeepsPumpingBassKeepsPumpingGimmeASmileForTheFutureAndIHeard ItOnTheRadioAndISawItOnTheTelevisionBackIn1988... gaw-a@minster.york.ac.uk From sam-users-owner@nvg.unit.no Mon Nov 7 18:04:17 1994 From: Frode Tennebo Message-Id: <199411071800.AA12357@ulke.hiMolde.no> Subject: Mysterious fault.... To: sam-users@nvg.unit.no Date: Mon, 7 Nov 1994 19:00:04 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1074 Lines: 22 Perhaps some of you remember my mysterious error with my SAM. It worked (aprantly) OK, until it started scrolling things on the screen and moving sprites etc. Either it didn't scroll propperly or it left a trail of the sprite, etc. I also mentioned that I had checked everything; ASIC, RAM, surrounding logic, THE WORKS. My only theory was that it could be that one or more instrucions inside the Z80B was corrupted. So (after 4 months of nagging) I got a replacement (I was a bit surprised here as it came together with my copy of Format and absolutely free of charge) the other day, and yesterday, I finally found the time to solder on a socket and try it out. AND...it worked! Horray! Has anyone got any ideas how a defect Z80 could come out from production, or how it could have been corrupted on board? -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Mon Nov 7 19:34:53 1994 Message-Id: From: gaw-a@minster.york.ac.uk (Mars Bar) Date: Mon, 7 Nov 1994 18:22:03 +0000 In-Reply-To: Frode.Tennebo -- "Mysterious fault...." (Nov 7, 7:00pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92 (ORBIT)) To: sam-users@nvg.unit.no Subject: Re: Mysterious fault.... Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1125 Lines: 24 On Nov 7, 7:00pm in "Mysterious fault....", frodders warbled: ] I also mentioned that I had checked everything; ASIC, RAM, ] surrounding logic, THE WORKS. My only theory was that it could be ] that one or more instrucions inside the Z80B was corrupted. So ] (after 4 months of nagging) I got a replacement (I was a bit ] surprised here as it came together with my copy of Format and ] absolutely free of charge) the other day, and yesterday, I finally ] found the time to solder on a socket and try it out. ] ] AND...it worked! Horray! ] ] Has anyone got any ideas how a defect Z80 could come out from ] production, or how it could have been corrupted on board? Had you tried resoldering the z80? It's quite likely that it was just a circuit placement fault, and your soldering a decent socket on it might have done the trick. Have you tried putting the old z80 back in your sam? BassKeepsThumpingPumpingJumpingBassKeepsThumpingPumpingJumpingBassKeepsThumping PumpingJumpingBassKeepsPumpingBassKeepsPumpingGimmeASmileForTheFutureAndIHeard ItOnTheRadioAndISawItOnTheTelevisionBackIn1988... gaw-a@minster.york.ac.uk From sam-users-owner@nvg.unit.no Mon Nov 7 23:30:10 1994 To: sam-users@nvg.unit.no Subject: Sam Date: Tue, 8 Nov 94 0:27:48 CET From: Arne Di Russo Message-Id: <9411080027.aa01360@ax433.mclink.it> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1120 Lines: 37 Hello Robert, > From: Robert Partington > Subject: Re: Sam > Multisync SVGA > Date: Mon, 7 Nov 1994 14:01:19 +0000 (GMT) > > All I had was a cable with 6 or 7 wires connected from the SCART on > the SAM to a 15 pin socket to attach the monitor cable to. SCART > outputs RGB and syncs so you just wire these to the appropriate place > on your monitor AFAIK. How did you mange to get separate Vsync and Hsync? Or do you have one of those rare multisyncs that have also a Csync input? I would be very happy if I could connect my SAM to my SVGA monitor instead of using the standard Philips 8833, so please could you give as much details as possible about how you made the connections? Thanks, Bye, Arne +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Arne Di Russo Internet..: mc8189@mclink.it (up to 14. Jan. 1995) | | Rome,Italy Fidonet...: 2:335/311.55 and 2:335/21.55 | | Voice.....: ++39/6/56338158 after 9pm CET | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ From sam-users-owner@nvg.unit.no Mon Nov 7 23:31:05 1994 To: sam-users@nvg.unit.no Subject: Sam Date: Tue, 8 Nov 94 0:28:47 CET From: Arne Di Russo Message-Id: <9411080028.aa01411@ax433.mclink.it> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1443 Lines: 46 Hello Simon, >Simon Cooke and Martin Rookyard would like to announce the birth of their >brand new bouncing baby girl. > >She was conceived on Tuesday last week, and was born on Friday night; after >a few complications on Sunday by 3pm she was doing her first I/O and >gurgling (or was she drive stepping? But I digress). > >Anyway, she loaded her first screen at 6pm on Sunday, and MasterDOS was >accessing her as a drive by 1am last night, although we had to throw a >bucket of water over it to get it to leave the poor baby alone. > >Anyway, that's all the news that's fit to print... > >WELCOME TO YOUR SAM HARD-DRIVE >FOLKS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WWWWWWWWWWWWWWWWHHHHHHHHHHOOOOOOOOOOOWWWWWWWWWWWW!!!!!!!!!!!!!!!!! I haven't tould it to my SAM yet, as otherwise he would refuse to work until he actually gets the HD... ;-))))) > >PARTY! Better not now but after the DOS is completed! ;-) By the way, can you please tell me when the nest Gloucester show is, I don't think that I will be able to go there but noone knows ... Bye, Arne +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Arne Di Russo Internet..: mc8189@mclink.it (up to 14. Jan. 1995) | | Rome,Italy Fidonet...: 2:335/311.55 and 2:335/21.55 | | Voice.....: ++39/6/56338158 after 9pm CET | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ From sam-users-owner@nvg.unit.no Mon Nov 7 23:32:15 1994 To: sam-users@nvg.unit.no Subject: Sam Date: Tue, 8 Nov 94 0:29:34 CET From: Arne Di Russo Message-Id: <9411080029.aa01458@ax433.mclink.it> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1277 Lines: 38 Hello Simon, >From: Simon Cooke >Date: Mon, 7 Nov 1994 13:10:32 GMT >Subject: Re: Sam > Multisync SVGA >> >> What about connecting sam to svga monitor ? Is it possible ? > >Martin Rookyard offered to build interfaces to do it for 15 quid a >shot to Format; they never printed anything about it, so the idea was >ditched. >If you want one, have a moan at Bob Brenchley and as him why he >didn't print the offer of one made by Rooksoft :) I don't understand why BB behaves this way??? It seems like he wants the SAM to die as soon as possible, at least I haven't found any other explanation for this crazy behaviour... He seems so narrow-minded, he doesn't want no HD, no COMMS, no GRAPHICS board, no CPU improvements, no SOUNDCARD, and now ... he even doesn't like a SAM connected to an SVGA monitor???!! Buuuhuhu, poor little SAMMY, what an ugly destiny... Bye, Arne +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Arne Di Russo Internet..: mc8189@mclink.it (up to 14. Jan. 1995) | | Rome,Italy Fidonet...: 2:335/311.55 and 2:335/21.55 | | Voice.....: ++39/6/56338158 after 9pm CET | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ From sam-users-owner@nvg.unit.no Tue Nov 8 05:17:00 1994 Date: Mon, 07 Nov 1994 18:10:40 GMT From: Briansam@bgserv.demon.co.uk (Brian Gaff Sam Dept.) Message-Id: <4786@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: Births & Anniversaries X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 111 Lines: 7 I take it there is one person you do not want that annpimcement to reach? :-) Brian -- Brian Gaff Sam Dept. From sam-users-owner@nvg.unit.no Tue Nov 8 05:17:58 1994 Date: Mon, 07 Nov 1994 18:16:30 GMT From: Briansam@bgserv.demon.co.uk (Brian Gaff Sam Dept.) Message-Id: <4788@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: Hard-Disk on sam X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 101 Lines: 7 Whay about the interleave and skew? Is that a way to get it faster? Brian -- Brian Gaff Sam Dept. From sam-users-owner@nvg.unit.no Tue Nov 8 05:17:59 1994 Date: Mon, 07 Nov 1994 18:14:30 GMT From: Briansam@bgserv.demon.co.uk (Brian Gaff Sam Dept.) Message-Id: <4787@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: Sam > Multisync SVGA X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 197 Lines: 8 First I heard of it. I could do with one. Thing that worries me is what monitors WONT it work with. If I sell something, I have got to know any potential problems. Brian -- Brian Gaff Sam Dept. From sam-users-owner@nvg.unit.no Tue Nov 8 05:18:00 1994 Date: Mon, 07 Nov 1994 18:18:59 GMT From: Briansam@bgserv.demon.co.uk (Brian Gaff Sam Dept.) Message-Id: <4789@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: Hard-Disk on sam X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 268 Lines: 9 Could I chip in about costs? You are complaining about 20 pound for a two port? Its the set up cost for the PCB, the small run, its only cheap if A) people work for fre, or B) if the market is big enough to spread the costs over time. Brian -- Brian Gaff Sam Dept. From sam-users-owner@nvg.unit.no Tue Nov 8 05:18:02 1994 Date: Mon, 07 Nov 1994 18:22:40 GMT From: Briansam@bgserv.demon.co.uk (Brian Gaff Sam Dept.) Message-Id: <4790@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: Dead monitor or knacked SAM? X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 656 Lines: 25 In message <2EBE963D@courier.lmu.ac.uk> "Doore, Daniel [MIS]" writes: > > > I have a Sony Triniton 14" TV with a fully-featured SCART > socket connected via liner RGB lines to my SAM. I have begun > to notice that at the top left of the screen (mostly in the border) > the reds are all washed out. > > I know it is NOT tube burn cos the SNES and video work fine, > any suggestions people? > > It could be the pin out on one of my SCART sockets is wrong, but > they are wired as the Tech. Manual says (perhaps that's what's wrong..) > > Dan Doore. > > OK, hum on the SAM PSU? Does it show on the TV output as well? Brian -- Brian Gaff Sam Dept. From sam-users-owner@nvg.unit.no Tue Nov 8 05:18:03 1994 Date: Mon, 07 Nov 1994 18:25:37 GMT From: Briansam@bgserv.demon.co.uk (Brian Gaff Sam Dept.) Message-Id: <4791@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: Sam > Multisync SVGA X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 514 Lines: 21 In message <"alfie.uib..644:07.10.94.14.09.04"@uib.no> Milan Salajka writes: > > > All I had was a cable with 6 or 7 wires connected from the SCART on > > the SAM to a 15 pin socket to attach the monitor cable to. SCART > > outputs RGB and syncs so you just wire these to the appropriate place > > on your monitor AFAIK. > > > :) > > Mhhh, but SVGA monitor hasn't got CSYNC signal, it has VSYNC and HSYNC... > > :( > > Milan > > 2 diodes? What polarity are the pulses? Brian -- Brian Gaff Sam Dept. From sam-users-owner@nvg.unit.no Tue Nov 8 05:18:04 1994 Date: Mon, 07 Nov 1994 18:33:30 GMT From: Briansam@bgserv.demon.co.uk (Brian Gaff Sam Dept.) Message-Id: <4792@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: Hard-Disk on sam X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 452 Lines: 17 In message Simon Cooke writes: > > Come on... a hard drive that goes at a speed even of the same _order_ as a > > disk drive is going to be shite. > > > > Now if you could stick that on the same board as the IDE iface it would > > really be worth buying... > > *grins*, but it'd cost over 100 quid!!!!!!!!! > > Si > :) Call it SAM 2 and make the SAM a peripheral of the drive! :-) Brian -- Brian Gaff Sam Dept. From sam-users-owner@nvg.unit.no Tue Nov 8 08:14:47 1994 Date: Tue, 08 Nov 1994 05:45:23 GMT From: Briansam@bgserv.demon.co.uk (Brian Gaff Sam Dept.) Message-Id: <4819@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: Mysterious fault.... X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 450 Lines: 16 In message <199411071800.AA12357@ulke.hiMolde.no> Frode Tennebo writes: > > AND...it worked! Horray! > > Has anyone got any ideas how a defect Z80 could come out from > production, or how it could have been corrupted on board? > -- > * Frode Tennebo * It's better to live life in * My suspicion is that its been damaged slightly by static at assembly time. Either that or its just slow and cannot keep up. Brian -- Brian Gaff Sam Dept. From sam-users-owner@nvg.unit.no Tue Nov 8 08:51:44 1994 From: Frode Tennebo Message-Id: <199411080849.AA15943@ulke.hiMolde.no> Subject: Re: Mysterious fault.... To: sam-users@nvg.unit.no Date: Tue, 8 Nov 1994 09:49:15 +0100 (MET) In-Reply-To: from "Mars Bar" at Nov 7, 94 06:22:03 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 586 Lines: 16 > > On Nov 7, 7:00pm in "Mysterious fault....", frodders warbled: > Had you tried resoldering the z80? It's quite likely that it was just a > circuit placement fault, and your soldering a decent socket on it might have > done the trick. > > Have you tried putting the old z80 back in your sam? Yes! Says it all, eh? :) -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Tue Nov 8 08:56:27 1994 From: Robert Partington Message-Id: <9411080854.AA00424@n6a.cs.man.ac.uk> Subject: Re: Sam To: sam-users@nvg.unit.no Date: Tue, 8 Nov 1994 08:54:33 +0000 (GMT) In-Reply-To: <9411080027.aa01360@ax433.mclink.it> from "Arne Di Russo" at Nov 8, 94 00:27:48 am Risc-Header: ARMed X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 596 Lines: 19 Arne Di Russo wrote : > >I would be very happy if I could connect my SAM to my SVGA monitor instead >of >using the standard Philips 8833, so please could you give as much details >as >possible about how you made the >connections? > I think the Acorn AKF17 does take CSYNC as input. I'm not sure tho', I'll have to enquire tonight. It didn't make much difference when I put the SAM through the monitor tho' except that the picture was smaller and there was no sound... I only did it because the monitor's upstairs and the TV's downstairs and I'm too lazy to carry the SAM up and down... :) Rob From sam-users-owner@nvg.unit.no Tue Nov 8 10:10:18 1994 From: "Doore, Daniel [MIS]" To: Sam Users Subject: Re: Dead monitor or knacked SAM? Date: Tue, 08 Nov 94 09:02:00 PST Message-Id: <2EBFBD6F@courier.lmu.ac.uk> Encoding: 38 TEXT X-Mailer: Microsoft Mail V3.0 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 927 Lines: 38 > From: sam-users-owner > To: sam-users > Subject: Re: Dead monitor or knacked SAM? > Date: 07 November 1994 18:22 > > In message <2EBE963D@courier.lmu.ac.uk> "Doore, Daniel [MIS]" writes: > > > > > > I have a Sony Triniton 14" TV with a fully-featured SCART > > socket connected via liner RGB lines to my SAM. I have begun > > to notice that at the top left of the screen (mostly in the border) > > the reds are all washed out. > > > > I know it is NOT tube burn cos the SNES and video work fine, > > any suggestions people? > > > > It could be the pin out on one of my SCART sockets is wrong, but > > they are wired as the Tech. Manual says (perhaps that's what's wrong..) > > > > Dan Doore. > > > > > OK, hum on the SAM PSU? It has always hummed a lot, but nothing excessive. > Does it show on the TV output as well? Not for about a year since the modulator blew up.... Dan. > Brian > > -- > Brian Gaff Sam Dept. > From sam-users-owner@nvg.unit.no Tue Nov 8 11:15:29 1994 Message-Id: From: gaw-a@minster.york.ac.uk (Mars Bar) Date: Tue, 8 Nov 1994 08:53:19 +0000 In-Reply-To: Briansam -- "Re: Hard-Disk on sam" (Nov 7, 6:18pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92 (ORBIT)) To: sam-users@nvg.unit.no Subject: Re: Hard-Disk on sam Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 897 Lines: 24 On Nov 7, 6:18pm in "Re: Hard-Disk on sam", Brian warbled: ] Could I chip in about costs? You are complaining about 20 pound ] for a two port? Its the set up cost for the PCB, the small run, ] its only cheap if A) people work for fre, or B) if the market is ] big enough to spread the costs over time. This I know... but when you look at what it _is_... jeeezus. Let's face it, it's time people _started_ working close to for free: the best things in the Sam world are done by enthiusiasts (sp?). What have West Coast produced for us in the last 2 years? Sweet F.A., apart from a crap `upgrade' that halves the capabilities of the computer. Thanks, Bob. BassKeepsThumpingPumpingJumpingBassKeepsThumpingPumpingJumpingBassKeepsThumping PumpingJumpingBassKeepsPumpingBassKeepsPumpingGimmeASmileForTheFutureAndIHeard ItOnTheRadioAndISawItOnTheTelevisionBackIn1988... gaw-a@minster.york.ac.uk From sam-users-owner@nvg.unit.no Tue Nov 8 11:41:12 1994 Message-Id: From: gaw-a@minster.york.ac.uk (Mars Bar) Date: Tue, 8 Nov 1994 09:48:53 +0000 In-Reply-To: Frode.Tennebo -- "Re: Mysterious fault...." (Nov 8, 9:49am) X-Mailer: Mail User's Shell (7.2.5 10/14/92 (ORBIT)) To: sam-users@nvg.unit.no Subject: Re: Mysterious fault.... Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 570 Lines: 16 >From Frode: ] > Had you tried resoldering the z80? It's quite likely that it was just a ] > circuit placement fault, and your soldering a decent socket on it might have ] > done the trick. ] > ] > Have you tried putting the old z80 back in your sam? ] ] Yes! Says it all, eh? :) Ummm.... no it doesn't. Did it work or not??? :) BassKeepsThumpingPumpingJumpingBassKeepsThumpingPumpingJumpingBassKeepsThumping PumpingJumpingBassKeepsPumpingBassKeepsPumpingGimmeASmileForTheFutureAndIHeard ItOnTheRadioAndISawItOnTheTelevisionBackIn1988... gaw-a@minster.york.ac.uk From sam-users-owner@nvg.unit.no Tue Nov 8 11:41:17 1994 From: Frode Tennebo Message-Id: <199411081133.AA18020@ulke.hiMolde.no> Subject: Re: Mysterious fault.... To: sam-users@nvg.unit.no Date: Tue, 8 Nov 1994 12:33:25 +0100 (MET) In-Reply-To: from "Mars Bar" at Nov 8, 94 09:48:53 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 999 Lines: 28 > > >From Frode: > > ] > Had you tried resoldering the z80? It's quite likely that it was just a > ] > circuit placement fault, and your soldering a decent socket on it might have > ] > done the trick. > ] > > ] > Have you tried putting the old z80 back in your sam? > ] > ] Yes! Says it all, eh? :) > > Ummm.... no it doesn't. Did it work or not??? :) *grin* Well, I soldered in the socket (after soldering out the initial Z80, and burnt a couple of wires), tried the OLD Z80 first and the result was the same. THEN I tried the NEW Z80 (which was sent from Dear Bob) and it worked..... How a CPU can be damaged (statically or in any other way) in such a way that it operates perfectly except a (couple of) command(s), beats me. -- * Frode Tennebo * It's better to live life in * * email: frodet@himolde.no * wealth and die poor, than live * * phone: +47 712 57716 * life in poverty and die rich. * * snail: Parkv. 31, 6400 Molde, NORWAY * -Frode Tennebo* From sam-users-owner@nvg.unit.no Tue Nov 8 14:21:22 1994 Date: Tue, 08 Nov 94 15:02:40 MET From: Milan Salajka Subject: Re: Sam > Multisync SVGA To: Sam Users In-Reply-To: Message of Mon, 07 Nov 1994 18:14:30 GMT from Message-Id: <"alfie.uib..557:08.10.94.14.13.36"@uib.no> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 431 Lines: 15 > First I heard of it. I could do with one. Thing that worries me > is what monitors WONT it work with. If I sell something, I have > ot to know any potential problems. My friend told me, that i have to separate csynt to hsync and vsync. It isn't hard, only some resistors and capacitors... The problem is, that hsync (from sam's csync) is about 15kHz and SVGA monitors works from 30kHz to 100kHz... Any ideas ? > Brian Milan From sam-users-owner@nvg.unit.no Tue Nov 8 15:44:49 1994 To: sam-users@nvg.unit.no Subject: Sam-Vga Date: Tue, 8 Nov 94 16:21:47 CET From: Arne Di Russo Message-Id: <9411081621.aa07946@ax433.mclink.it> Original-Sender: owner-sam-users@no.unit.nvg Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1185 Lines: 32 Hello Robert, > From: Robert Partington > Subject: Re: Sam > Date: Tue, 8 Nov 1994 08:54:33 +0000 (GMT) > > I think the Acorn AKF17 does take CSYNC as input. :-((( > I'm not sure tho', I'll have to enquire tonight. I'm waiting anxiously ... > It didn't make much difference when I > put the SAM through the monitor tho' except that the picture was smaller > and there was no sound... I only did it because the monitor's upstairs > and the TV's downstairs and I'm too lazy to carry the SAM up and down... Well it should make quite some difference as the Philips has 0.42 mm dot pitch while a normal SVGA has 0.28 mm, so the picture should be much sharper and crisper on an SVGA, the absence of sound doesn't make any difference for me as I use the HiFI for the sound of the SAM. :-) Bye, Arne +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Arne Di Russo Internet..: mc8189@mclink.it (up to 14. Jan. 1995) | | Rome, Italy Fidonet...: 2:335/311.55 and 2:335/21.55 | | Voice.....: ++39/6/56338158 after 9pm CET | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ From sam-users-owner@nvg.unit.no Wed Nov 9 06:03:48 1994 Date: Tue, 08 Nov 1994 20:27:06 GMT From: Briansam@bgserv.demon.co.uk (Brian Gaff Sam Dept.) Message-Id: <4841@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: ftp deaded! X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 256 Lines: 9 For two dats now I have been unable to ftp to the Sam site in Norway. Seems to be a timeout before I get a prompt. Can someone Email me the Small Sam terminal that is up there? I need it to do some tests with an Organiser. Brian -- Brian Gaff Sam Dept. From sam-users-owner@nvg.unit.no Wed Nov 9 06:55:16 1994 Date: Wed, 09 Nov 1994 06:05:36 GMT From: Briansam@bgserv.demon.co.uk (Brian Gaff Sam Dept.) Message-Id: <4844@bgserv.demon.co.uk> To: sam-users@nvg.unit.no Subject: Re: Hard-Disk on sam X-Mailer: PCElm 1.10 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 329 Lines: 12 Unfortunately, I and I suspect Bob, need to eat and pay bills. I would like nothing better than to be in a position to do things for free, but I cannot afford to. I have a guy who is prepared to do most electronic stuff, but he is out of work and needs money. Its fine being an idealist, but... Brian -- Brian Gaff Sam Dept. From sam-users-owner@nvg.unit.no Wed Nov 9 09:49:42 1994 Message-Id: From: gaw-a@minster.york.ac.uk (Mars Bar) Date: Wed, 9 Nov 1994 09:29:14 +0000 In-Reply-To: Briansam -- "Re: Hard-Disk on sam" (Nov 9, 6:05am) X-Mailer: Mail User's Shell (7.2.5 10/14/92 (ORBIT)) To: sam-users@nvg.unit.no Subject: Re: Hard-Disk on sam Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2250 Lines: 54 On Nov 9, 6:05am in "Re: Hard-Disk on sam", Brian warbled: ] Unfortunately, I and I suspect Bob, need to eat and pay bills. I ] would like nothing better than to be in a position to do things ] for free, but I cannot afford to. ] I have a guy who is prepared to do most electronic stuff, but he ] is out of work and needs money. Its fine being an idealist, ] but... While I have the greatest of respect for what you do, Brian, I have to disagree. The whole of the Sam world is now based around idealists - people like Si and Martin Rookyard. The very nature of the Sam as it is demands that people do keep an Idealist view - otherwise it simply becomes a computer that is too slow, too unsupported and - let's face it, too expensive. We (I count myself in this happy bunch although I admit that my idealism is fast fading) _do_ work for nothing. I need to eat and pay bills too. We try and make a minimal profit from what we do, but - in my case at least - we understand that we are unlikely to break even if we cost our hours at a rate anywhere _near_ what we should expect to be paid. My current expertise would demand a salary of around L15,000 (starting). Who in the Sam world is going to make that sort of money by writing software and making periperals? That's the difference between an enthiusiast and a businessman. And which would I prefer to do business with? Let's see, on the business side, we have: You, Bob, Adrian Parker, the Format `team' on the enthiusiasts side, we have Dave L (just about, he has another job anyway :), Si, Entropy, ESI, all of the Sam _users_... I have to admit that you lose out. As I said, I have great respect for you because you provide services that people need and want, and I respect you because I know how hard you work. But Bob and his "I won't work until I'm sure I'll break even" brigade should be making PC peripherals, and the only reason they're not is because there's a big enough market for them and their crap not to survive. Enough, I think... BassKeepsThumpingPumpingJumpingBassKeepsThumpingPumpingJumpingBassKeepsThumping PumpingJumpingBassKeepsPumpingBassKeepsPumpingGimmeASmileForTheFutureAndIHeard ItOnTheRadioAndISawItOnTheTelevisionBackIn1988... gaw-a@minster.york.ac.uk From sam-users-owner@nvg.unit.no Wed Nov 9 09:54:02 1994 Message-Id: From: gaw-a@minster.york.ac.uk (Mars Bar) Date: Wed, 9 Nov 1994 09:35:49 +0000 In-Reply-To: Briansam -- "ftp deaded!" (Nov 8, 8:27pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92 (ORBIT)) To: sam-users@nvg.unit.no Subject: Re: ftp deaded! Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 692 Lines: 15 On Nov 8, 8:27pm in "ftp deaded!", Brian warbled: ] For two days now I have been unable to ftp to the Sam site in ] Norway. Seems to be a timeout before I get a prompt. Can someone ] Email me the Small Sam terminal that is up there? I need it to ] do some tests with an Organiser. I've sent this to Brian, so unless it went wrong (in which case he'll request again) don't send him any more! I'm sure he doesn't want his mailbox bombed with 20 copies... BassKeepsThumpingPumpingJumpingBassKeepsThumpingPumpingJumpingBassKeepsThumping PumpingJumpingBassKeepsPumpingBassKeepsPumpingGimmeASmileForTheFutureAndIHeard ItOnTheRadioAndISawItOnTheTelevisionBackIn1988... gaw-a@minster.york.ac.uk From imc Wed Nov 9 10:56:19 1994 Subject: Re: Hard-Disk on sam To: sam-users@nvg.unit.no Date: Wed, 9 Nov 94 10:56:19 GMT In-Reply-To: ; from "Mars Bar" at Nov 9, 94 9:29 am X-Mailer: ELM [version 2.3 PL11] Content-Length: 417 Lines: 9 On Wed, 9 Nov 1994 09:29:14 +0000, Mars Bar said: > But Bob and his "I won't work until > I'm sure I'll break even" brigade should be making PC peripherals, and the > only reason they're not is because there's a big enough market for them > and their crap not to survive. ^^^^^^^^^^^^^^ Is this what you meant to say? If so, I don't quite understand it... imc From sam-users-owner@nvg.unit.no Wed Nov 9 11:15:45 1994 Message-Id: From: simonc@jumper.mcc.ac.uk (Simon Cooke) Subject: Re: Hard-Disk on sam To: sam-users@nvg.unit.no Date: Wed, 9 Nov 1994 11:12:04 +0000 (GMT) Cc: simonc@jumper.mcc.ac.uk (Simon Cooke) In-Reply-To: <9411091056.AA00302@boothp1.ecs.ox.ac.uk> from "Ian.Collier@comlab.ox.ac.uk" at Nov 9, 94 11:56:20 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 737 Lines: 19 > > But Bob and his "I won't work until > > I'm sure I'll break even" brigade should be making PC peripherals, and the > > only reason they're not is because there's a big enough market for them > > and their crap not to survive. > ^^^^^^^^^^^^^^ > Is this what you meant to say? If so, I don't quite understand it... > > imc > What he means is that there's a big enough market for people to just buy from others if they don't want the crap that Bob's putting out -- they wouldn't have to put up with rubbish, as there'd be another supplier just around the corner. BTW: sorry for not posting here recently... have been ill the last two days... pretty scary too at times :( Si From sam-users-owner@nvg.unit.no Wed Nov 9 11:20:36 1994 Message-Id: From: simonc@jumper.mcc.ac.uk (Simon Cooke) Subject: Re: Sam To: sam-users@nvg.unit.no Date: Wed, 9 Nov 1994 11:17:53 +0000 (GMT) Cc: simonc@jumper.mcc.ac.uk (Simon Cooke) In-Reply-To: <9411080028.aa01411@ax433.mclink.it> from "Arne Di Russo" at Nov 8, 94 00:28:47 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 672 Lines: 29 > WWWWWWWWWWWWWWWWHHHHHHHHHHOOOOOOOOOOOWWWWWWWWWWWW!!!!!!!!!!!!!!!!! > I haven't tould it to my SAM yet, as otherwise he would refuse to work > until > he actually gets the HD... ;-))))) *grins* > > > >PARTY! > > Better not now but after the DOS is completed! ;-) Welll.... we've nearly got MasterDOS patched... but it is a bit wasteful using an 80Mb hard drive as a 1Mb second drive :) > By the way, can you please tell me when the nest Gloucester show is, > I don't think that I will be able to go there but noone knows > ... Not a clue... probably April... But, of course, there *may* be the Entropy show in Macclesfield in February > Bye, > > Arne Seeya Si From sam-users-owner@nvg.unit.no Wed Nov 9 11:24:02 1994 Message-Id: From: simonc@jumper.mcc.ac.uk (Simon Cooke) Subject: Re: Hard-Disk on sam To: sam-users@nvg.unit.no Date: Wed, 9 Nov 1994 11:19:19 +0000 (GMT) Cc: simonc@jumper.mcc.ac.uk (Simon Cooke) In-Reply-To: <4792@bgserv.demon.co.uk> from "Brian Gaff Sam Dept." at Nov 7, 94 06:33:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 173 Lines: 7 > Call it SAM 2 and make the SAM a peripheral of the drive! :-) He who speaks in jest *could* be speaking truth without realising it... Now, I *am* getting cryptic ;) Si