From owner-sam-users@nvg.ntnu.no Sun Mar 1 11:26:03 1998 From: BrenchleyR Message-ID: Date: Sun, 1 Mar 1998 06:20:06 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1177 Lines: 30 In a message dated 28/02/98 15:14:00, you write: >o > >On Thu, 26 Feb 1998 12:06:49 -0500, Simon Cooke said: >> Well, apart from not knowing the parallel-port transfer spec for it -- and >> that would probably require an ECP parallel port at the very least -- I do >> know that it acts generally as an ATAPI device (ie. it uses the SCSI >> command set) -- and that's how it's accessed internally in Windows NT. > >I thought ATAPI was an IDE thing. > >Anyway, Zip is available in IDE, SCSI and parallel formats, and the parallel >one is a SCSI one with a SCSI-parallel interface. As far as I know it >doesn't support ECP ports, but it does support standard parallel ports >(where four of the error return lines are used for data input, half a >byte at a time), bi-directional ports (like it says) and EPP (in which >the hardware does the strobe flipping when the data is output using a >single OUT instruction, and presumably using some similar scheme for >input). How hard would it be to impliment such a bi-directional port for SAM? > >I guess the PPA driver for Linux would be a good source of information >for how to drive the parallel-SCSI interface. > >imc -- Bob. From owner-sam-users@nvg.ntnu.no Sun Mar 1 11:26:03 1998 From: BrenchleyR Message-ID: <60b9258.34f94503@aol.com> Date: Sun, 1 Mar 1998 06:22:41 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 588 Lines: 20 In a message dated 28/02/98 23:10:40, you write: >Sorry Bob but you just happen to be wrong (yet again) > >Andrew did say that a Bootstrap program could be written in a quite >short space of time allowing some software to work straight away >(Keeping a large majority of people happy). The O/S could then be >written over a longer period of time > >Makes sense to me > > >Neil So I exagerated a bit, the point still stands that his claims have always exceeded what he actually does. If he spent less time arguing and actually did something I would take him more seriously. -- Bob. From owner-sam-users@nvg.ntnu.no Sun Mar 1 11:26:04 1998 From: BrenchleyR Message-ID: Date: Sun, 1 Mar 1998 06:18:02 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1055 Lines: 30 In a message dated 28/02/98 13:26:25, you write: >On Sat, 28 Feb 1998 07:26:44 EST, BrenchleyR said: >> >Is that FAT as in what the rest of the world thinks of as FAT (i.e., the >> >MSDOS filing system) or some special non-FAT FAT? > >> FAT. File Allocation Table. In the case of HDOS a table of 32 bit words >used >> to control the allocation of disc space to files. > >That didn't answer the question. Is this a version of the MSDOS filing >system (yes or no)? If not then calling it "FAT" is misleading. Yes I >do know what it stands for, but the fact remains that in the last ten >years it has only ever been used to describe the MSDOS filing system and >you are only going to confuse people by trying to make it mean something >else. I disagree, Microsloth may have hi-jacked the word FAT but it has been around for a lot longer than they have. They have one implimentation of a FAT system, HDOS has its own. But a FAT is a FAT is a FAT. -- Bob. > >Either way it isn't a particularly efficient way of storing things on >disks... > >imc > > From owner-sam-users@nvg.ntnu.no Sun Mar 1 12:14:29 1998 From: SparkY To: sam-users Subject: Re: Floppy Disks Date: Sun, 1 Mar 1998 12:10:13 -0000 Message-Id: <01bd450a$fd114980$1d14a8c2@sparky> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 719 Lines: 17 >So I exagerated a bit, the point still stands that his claims have always >exceeded what he actually does. If he spent less time arguing and actually did >something I would take him more seriously. > >-- >Bob. HAHAHA! Are you serious?! The above applies to you more than to anyone else!! I, and I believe, the majority on this list, have *much* more respect for Andrew than for you. And Bob, your pathetic attempts to be the big "authority" on this list, by insulting the people who actually *have* the talent on this list, isn't going to work - neither is a reply from your clone, saying "ooh but Bob is just great, I love him, I'm going to have his babies, and I read Format as it's just the best blah blah" Gavin From owner-sam-users@nvg.ntnu.no Sun Mar 1 13:03:01 1998 X-Sender: asc25@pop.hermes.cam.ac.uk Message-Id: In-Reply-To: <60b9258.34f94503@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 1 Mar 1998 12:57:31 +0000 To: sam-users@nvg.unit.no From: Andrew Collier Subject: Re: Floppy Disks X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by mail.comlab.ox.ac.uk id NAA27589 Status: RO Content-Length: 1558 Lines: 39 At 11:22 am +0000 1/3/98, BrenchleyR wrote: >So I exagerated a bit, A bit! AKA you made it up as you went along. > the point still stands that his claims have always >exceeded what he actually does. If he spent less time arguing and actually did >something I would take him more seriously. So what you're saying, is that if everybody changed their mind and decided to agree with you instead, then everything will work out fine and the world would be a better place. That's rich. When you've actually got some Sam machine-code programming to show for your "30 years in the business" then I might let you join MNEMOtech. Until then, stop telling us all "how coders code" because it just irritates those of us who actually do know. And I'm not looking for the Fortran you wrote 20 years ago, or an old 8-bit games programming system you say you helped design; I'm looking for genuine, relevant Sam-Coupé machine-code experience and I won't let you patronise me until I see decent source code with your name written all over it. Andrew --- +-----------------+----------------------------+--------------------+ | Andrew Collier | email asc25@cam.ac.uk | " | | 1B NatSci | http://carou.sel.cam.ac.uk | Get your kicks | +-----------------+----------------------------+ on 8.124038405 | | Selwyn College Student Computer Support Team | " | | email support@sel.cam.ac.uk | anon | +----------------------------------------------+--------------------+ From imc Sun Mar 1 14:23:19 1998 Subject: Re: Floppy Disks To: sam-users@nvg.unit.no Date: Sun, 1 Mar 1998 14:23:19 +0000 (GMT) In-Reply-To: from "BrenchleyR" at Mar 1, 98 06:18:02 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 475 Lines: 12 On Sun, 1 Mar 1998 06:18:02 EST, BrenchleyR said: > I disagree, Microsloth may have hi-jacked the word FAT but it has been around > for a lot longer than they have. That may or may not be true, but it is immaterial. I'm afraid DOS *has* hijacked the term and to pretend otherwise would be silly. [BTW, I don't know what the HDOS format is, but the SamDOS format can't be described as FAT since there is no one table which describes how all the files are allocated.] imc From imc Sun Mar 1 14:49:52 1998 Subject: Re: Floppy Disks To: sam-users@nvg.unit.no Date: Sun, 1 Mar 1998 14:49:52 +0000 (GMT) In-Reply-To: from "BrenchleyR" at Mar 1, 98 06:20:06 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1748 Lines: 35 On Sun, 1 Mar 1998 06:20:06 EST, BrenchleyR said: > How hard would it be to impliment such a bi-directional port for SAM? Output wouldn't be too hard. You need an 8-bit latch which tristates its output when the strobe is active. The OUT instruction will trigger the latch to input from the data lines and also set off a timer to pulse the strobe output. [In the mid-80s I built a simple parallel port which merely buffered the data lines to the printer all the time and pulsed the strobe output when the OUT instruction was executed. It drove the printer at about 2000 bytes per second (as fast as the printer would take it) but must have generated a fair bit of EM interference...] I don't know how the input part of it works, but assuming it works in a symmetric manner with a separate input strobe signal you can connect the data lines to a latch whose input is activated by this strobe and whose output can be read by an IN instruction. You will need another 1-bit latch which can be set by the input strobe signal and reset by the IN instruction. A second IN instruction (with a different address) will read this latch so that the Sam knows the data has arrived. There may have to be some hardware handshaking to ensure that data is not lost by being written too fast. I don't know the EPP specs (but I suspect they will be on the net somewhere) but assuming it is something simple like a busy signal it wouldn't be too hard to route the input busy signal to the Sam and input it with the second IN instruction, and to supply the 1-bit latch as the output busy signal. It might be possible to get a peak transfer rate of 100K per second with this hardware. [Note that the EDDAC won't work properly on such a parallel port] imc From owner-sam-users@nvg.ntnu.no Sun Mar 1 17:46:11 1998 From: BillRitman Message-ID: <899f40cf.34f99e31@aol.com> Date: Sun, 1 Mar 1998 12:43:11 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0.i for Windows sub 178 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 627 Lines: 17 In a message dated 01/03/98 12:51:41, you write: > > HAHAHA! Are you serious?! The above applies to you more than to anyone > else!! I, and I believe, the majority on this list, have *much* more respect > for Andrew than for you. And Bob, your pathetic attempts to be the big > "authority" on this list, by insulting the people who actually *have* the > talent on this list, isn't going to work - neither is a reply from your > clone, saying "ooh but Bob is just great, I love him, I'm going to have his > babies, and I read Format as it's just the best blah blah" > > Gavin > This guy need locking up!!! Bill. From owner-sam-users@nvg.ntnu.no Sun Mar 1 18:51:42 1998 Message-Id: <199803011835.TAA05434@mailserv.caiw.nl> From: Robert van der Veeke To: sam-users Subject: Re: Floppy Disks Date: Sun, 1 Mar 1998 19:36:11 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1157 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1006 Lines: 33 > Van: BillRitman > Aan: sam-users@nvg.unit.no > Onderwerp: Re: Floppy Disks > Datum: Sunday, March 01, 1998 6:43 > > In a message dated 01/03/98 12:51:41, you write: > > > > > HAHAHA! Are you serious?! The above applies to you more than to anyone > > else!! I, and I believe, the majority on this list, have *much* more > respect > > for Andrew than for you. And Bob, your pathetic attempts to be the big > > "authority" on this list, by insulting the people who actually *have* the > > talent on this list, isn't going to work - neither is a reply from your > > clone, saying "ooh but Bob is just great, I love him, I'm going to have his > > babies, and I read Format as it's just the best blah blah" > > > > Gavin > > > This guy need locking up!!! Nah, just killfilter him (yeah stick your head in the sand ED), you know how they work. Bai Bai -- Robert van der Veeke, aka RJV Graphics [rjvveeke@caiw.nl] The borderline Express will terminate at this station :) From owner-sam-users@nvg.ntnu.no Sun Mar 1 22:32:38 1998 X-Authentication-Warning: lily.csv.warwick.ac.uk: pyumi owned process doing -bs Date: Sun, 1 Mar 1998 22:28:36 +0000 (GMT) From: Mark Sturdy X-Sender: pyumi@lily To: sam-users@nvg.unit.no Subject: Re: Floppy Disks In-Reply-To: <01bd450a$fd114980$1d14a8c2@sparky> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1485 Lines: 31 On Sun, 1 Mar 1998, SparkY wrote: > HAHAHA! Are you serious?! The above applies to you more than to anyone > else!! I, and I believe, the majority on this list, have *much* more respect > for Andrew than for you. And Bob, your pathetic attempts to be the big > "authority" on this list, by insulting the people who actually *have* the > talent on this list, isn't going to work - neither is a reply from your > clone, saying "ooh but Bob is just great, I love him, I'm going to have his > babies, and I read Format as it's just the best blah blah" I don't think that's very fair. Looking solely at their position in the SAM world, I personally don't respect Bob (organizes the shows, runs West Coast and Revelation [no matter how well/badly he runs them they wouldn't exist without him], publishes a SAM and Spectrum magazine) any less than Andrew (programmed some good stuff, but nothing much lately). I mean, like a lot of people I do find certain things that Bob does (the vendetta against David Ledbury being the main example) pretty low, but that doesn't mean that nothing he ever does is of any worth whatsoever, and it doesn't mean that anyone who disagrees with him has just floated down from heaven. If anything's making Bob look bigger than he really is (no jokes please) (on second thoughts, rip the piss!) then it's the daft ongoing debate about how evil he may or may not be. Get things into perspective, people. Take care, Mark "Hello Tony." "Hello, Control." From owner-sam-users@nvg.ntnu.no Sun Mar 1 22:53:44 1998 Subject: Re: Floppy Disks To: sam-users@nvg.unit.no Date: Sun, 1 Mar 1998 22:48:11 +0000 (GMT) Cc: Simon.Cooke@nessie.mcc.ac.uk (Simon Cooke) In-Reply-To: <199802281513.PAA21222@chalca.comlab.ox.ac.uk> from "Ian Collier" at Feb 28, 98 03:13:20 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Simon Cooke Message-Id: X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 396 Lines: 10 > I thought ATAPI was an IDE thing. Yep, it is, but more accurately, it's a subset of the SCSI command set, transferred in IDE style packets rather than directly to a SCSI controller. Each command packet is something like 46 bytes long. I'd be surprised if the parallel port zip drives didn't use sometyhing like this. Even though it's taking the layering of protocols to an extreme! Simon From owner-sam-users@nvg.ntnu.no Sun Mar 1 22:53:45 1998 Subject: Re: Floppy Disks To: sam-users@nvg.unit.no Date: Sun, 1 Mar 1998 22:49:53 +0000 (GMT) Cc: Simon.Cooke@nessie.mcc.ac.uk (Simon Cooke) In-Reply-To: from "BillRitman" at Feb 28, 98 11:58:26 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit From: Simon Cooke Message-Id: X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 653 Lines: 19 > > Zip and Jazz, however, look like the newest de facto standard. It's getting > > to the point where you can't buy a machine without a built in Zip Drive. > > Don't know where you get that idea from, looking through Computer Shopper > there are some machines with zip drives, but not that many. Oh, sorry, I forgot that the rest of you lived in a technological backwater of the world which is at least a year behind the current trends. >ahem< > > Therefore... I'd go straight for Zip or Jazz rather than trying out an > > option that doesn't currently have the computer market's favour. > > Where should I send my order? Excuse me? Simon From owner-sam-users@nvg.ntnu.no Mon Mar 2 01:07:47 1998 Message-ID: <87+VsAAREg+0IwFv@idalziel.demon.co.uk> Date: Mon, 2 Mar 1998 00:45:05 +0000 To: sam-users@nvg.ntnu.no From: Ian Dalziel Subject: Re: Floppy Disks In-Reply-To: <3.0.1.32.19980227160634.006c66fc@nessie.mcc.ac.uk> MIME-Version: 1.0 X-Mailer: Turnpike Version 3.04 X-Orcpt: rfc822;sam-users@nvg.ntnu.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 721 Lines: 16 In article <3.0.1.32.19980227160634.006c66fc@nessie.mcc.ac.uk>, Simon Cooke writes >You know... I don't remember anyone actually saying "Anybody want to help >write the DOS?" > >Maybe it's just me, but I don't think so. Look - who cares? If we're ever going to do any more than stir cold poo around, how about getting something done instead of working out whose fault it was that someone didn't do what they thought they hadn't been asked to do some time before Adam were a lad? It must be eighteen years since I programmed any flavour of Z80, so I don't fancy attempting HDOS, but I'll do what I can to help any project - if there really is one around which ain't vapourware. -- Ian Dalziel From owner-sam-users@nvg.ntnu.no Mon Mar 2 02:09:46 1998 Message-ID: Date: Mon, 2 Mar 1998 02:04:30 +0000 To: sam-users@nvg.unit.no From: Graham Goring Subject: Re: Floppy Disks In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Trial Version 3.03a <8OHKkEUpoELRXgFKFsA4hwDBr8> X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1147 Lines: 26 In message , Simon Cooke writes >> > Zip and Jazz, however, look like the newest de facto standard. It's getting >> > to the point where you can't buy a machine without a built in Zip Drive. >> >> Don't know where you get that idea from, looking through Computer Shopper >> there are some machines with zip drives, but not that many. > >Oh, sorry, I forgot that the rest of you lived in a technological >backwater of the world which is at least a year behind the current trends. Woo-hoo! Well, I'd hate to back up my hard-drive using zip-disks. Nope, I'd have to buy a re-recordable CD ROM Drive. 'Spensive, but nice... Graham -- /====================================================\ +--------------+ | My proverb for this week: | |This Space For| | "The less bits, the less can go wrong... | | Hire - Ideal | | Unless you wobble something important at the back" | |For Weddings &| \==Graham Goring - graham@duketastrophy.demon.co.uk==/ | Bahmitzvas | My Website, coming to a server near you - SOON +--------------+ From owner-sam-users@nvg.ntnu.no Mon Mar 2 11:17:41 1998 From: Paul Walker Message-Id: <199803021109.LAA27916@crocus.csv.warwick.ac.uk> Subject: Re: In-Reply-To: <199802281518.PAA21266@chalca.comlab.ox.ac.uk> from Ian Collier at "Feb 28, 98 03:18:59 pm" To: sam-users@nvg.unit.no Date: Mon, 2 Mar 1998 11:09:20 +0000 (GMT) X-Approved: bill@whitehouse.gov X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 239 Lines: 9 > > Travelling to the moon. By means of a very very big gun. > I remember it. Now what about it? This thread started with people wanting to send Gates somewhere. I suggest we don't put the padding in the big bullet that he used. Paul From imc Mon Mar 2 11:27:36 1998 Subject: Re: To: sam-users@nvg.unit.no Date: Mon, 2 Mar 1998 11:27:36 +0000 (GMT) In-Reply-To: <199803021109.LAA27916@crocus.csv.warwick.ac.uk> from "Paul Walker" at Mar 2, 98 11:09:20 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 459 Lines: 14 On Mon, 2 Mar 1998 11:09:20 +0000 (GMT), Paul Walker said: > > > Travelling to the moon. By means of a very very big gun. > > I remember it. Now what about it? > This thread started with people wanting to send Gates somewhere. To Mars, rather than the moon. But remember that in Jules Verne's story they actually missed and the travellers came back... > I suggest we don't put the padding in the big bullet that he used. That might be better. :-) imc From owner-sam-users@nvg.ntnu.no Mon Mar 2 11:32:32 1998 X-Lotus-FromDomain: CASE TECHNOLOGY From: Justin_Skists@case.co.uk To: sam-users@nvg.unit.no Message-ID: <002565BB.003C53F2.00@notes_a.case.co.uk> Date: Mon, 2 Mar 1998 11:26:08 +0000 Subject: Re: Floppy Disks Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 810 Lines: 25 Bob Br. wrote in response to someone:- >>The second is the ATOM, which as far as I >>know hasn't been officially released, and I am lead to believe, has a >>good working DOS, but it doesn't work in the same way as the first. >> >>If I were looking for a hard disk system for SAM, I think I'd go for >>the second one, > > Well I think that would be a mistake, but of course your choice. SD's hard > drive allows you to connect any IDE hard drive and use it to its full. It is a > full 32 bit FAT and it only needs a little work on the ROM+MasterDOS to get an > integrated system that would be very fast and very powerful. Bob, is this truth or anti-Persona slander? I'm just curious since I haven't even been allowed to see the details of ATOM and BDOS, never mind actually comparing the two... Justin.... From owner-sam-users@nvg.ntnu.no Mon Mar 2 15:01:21 1998 From: BrenchleyR Message-ID: <64b8fec2.34fac475@aol.com> Date: Mon, 2 Mar 1998 09:38:43 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: The Plan for SAM. Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO X-Status: A Content-Length: 3246 Lines: 79 In answer to a couple of direct emails received last week, here is the current plan I am trying to work to for the future development of SAM. If anyone is interested in helping with aspects of the project then please send a direct email to me at the Formatpub@aol.com address saying where you think you would like to help. Progress. At the moment items 1a and 1b are in progress (although going a lot slower than I would like. Item 1c can go ahead at any time. Item 1d could start as soon as we like. Item 1f really needs a C expert to manage it and at the moment the only C expert with enough experience (Nev Young) does not have the time. the only item looked at beyond section 1 so far is item 2A, but this is still in a very early stage. I hope this satisfies the curious and prompts a few others to start doing something. Bob. Plan. 1. To provide on SAM a stable development platform for software required both for the existing SAM and for anything that is to follow. a) Produce definitive list of bugs in both ROM and MasterDOS+MasterBasic. b) Look at existing Basic/DOS and define areas where closer specification of syntax will reduce the amount of coding (more space is needed) and/or increase the speed of interpreting (always handy). c) Produce some form of SRAM card (even if it is only the same as that designed by Bruce Gordon. This is to allow people to load and run new ROM versions without the need to distribute EPROMs or the like. d) Using information from a and b above, and distributing the source code in Comet form, start to re-work the ROM/DOS into its new form (this may well be an open-ended project). e) Extend and integrate HDOS into new ROM/DOS. f) As platform becomes more stable develop more extensive form of C with possibly both Z80 and Z380 object versions. g) Produce hardware and software for FTP site access from SAM (I think necessary to allow for quick distribution of new working code, but only if a fair number of people become involved in the project.) 2. To extend the hardware abilities of the existing SAM. a) Define new 'extended' bus for SAM, taking into account the possibility of 2nd processor (Z380 or something else yet to be looked at (Z380 looks best at the moment, but who can tell six months from now)). We know we will need at least a 16bit data-bus and a much wider address-bus. b) Work on new memory expansion (1 to 16Mb ??). c) Look at new graphics card. d) Decide on new floppy disc interface standard. e) Produce interface for PC type keyboard and mouse b,c,d & e will take place in parallel. f) Select first of the 2nd processors to implement. 3. Look at bringing together all developments into a new single board machine possibly to be called Samson. (c) Copyright 1997/98 Format Publications. Released 02/03/1998. No part of this information may be distributed in any form or by any media without this copyright message being appended. Not for publication in paper or disc based magazines without the express permission in writing of Format Publications. The copyright owner releases this document for discussion purposes only to the Sam Users Mailing List and to Comp.sys.sinclair. Provided that all discussions take place under the original thread title. From imc Mon Mar 2 15:08:18 1998 Subject: Re: The Plan for SAM. In-Reply-To: <64b8fec2.34fac475@aol.com> from BrenchleyR at "Mar 2, 98 09:38:43 am" To: sam-users@nvg.unit.no Date: Mon, 2 Mar 1998 15:08:18 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Content-Length: 354 Lines: 9 On Mon, 2 Mar 1998 09:38:43 EST, BrenchleyR said: > b) Look at existing Basic/DOS and define areas where closer specification of > syntax will reduce the amount of coding Not good if you want existing programs to be able to run with the new ROM. Besides, I'm not sure how much you expect to save or indeed what bits of syntax you are thinking of. imc From owner-sam-users@nvg.ntnu.no Mon Mar 2 17:14:12 1998 From: jwalton1@ibm.net Message-Id: <199803021709.RAA80814@out4.ibm.net> To: sam-users Subject: Re: Floppy Disks Date: Mon, 2 Mar 1998 12:07:23 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2608 Lines: 56 >He needed help because he was constantly coming up against problems in the >ROM/MasterDOS. One of the major problems being that Andy does not have a >consistent return path from syntax checking/command interpretation. > >The only way round this is to rework parts of the ROM and MasterDOS. Hence the >requirement to develop the SRAM card to make life easier for those doing the >testing. Ummmmm... actually, if that were the case, then how on earth would MasterDOS or MasterBASIC be able to do any of the O/S patching that they do? I mean, yes, you're right, it isn't always consistent. Partly that is because the command parsing and handling structure for BASIC isn't documented, so you can't see the underlying structure. *thinks about getting the SAM ROM and MasterDOS source code and breaking it down into chunks* Bob... how about we publish the ROM and DOS code on the list for people to work with? That might get things done. -Criteria for a DOS- 1. Must have clearly defined layers in its structure -- eg. disk controller -> record handling -> file handling -> etc. This is so that we can swap in and out file systems and controllers at will. Also, it will mean that we need to write a specific API for the job, and will have to divorce the DOS completely from BASIC (barring some glue to get the BASIC commands working). This is a Good Thing. 2. It must provide the programmer with C/Unix style file handling. This will enable future programmers to convert programs from other platforms easily. At the moment, file handling is a nightmare if you want to do thing the "traditional" way. 3. The new DOS must be, as far as possible, a free upgrade. Cost price only. The source code must be GNU'd. The DOS must come with programming documentation and example source code on the disk -- preferably with a money-off discount for COMET assembler (which is what the source will be in). 4. It must include memory management functionality, including the ability to reserve any size chunk from 1 byte to 1Mb. Preferably it'd run the gamut. Ideally, it would be frugal about its memory usage for placeholder information too. 5. It should handle optional disk read-cacheing. This could work on the early MSDOS principle that if there isn't a disk access for 2 seconds, check that you're still using the same disk. 6. Even if it doesn't actually read MSDOS/PRODOS disks, we should check the format of the disk and inform the user that they've put one in the machine. The check can be made by looking at bytes 510/511 of sector 1, track 0, side 0. MSDOS = &55AA 7. Come on people, add to the list! Simon From owner-sam-users@nvg.ntnu.no Mon Mar 2 17:59:47 1998 From: jwalton1@ibm.net Message-Id: <199803021730.RAA60478@out4.ibm.net> To: sam-users Subject: Re: The Plan for SAM. Date: Mon, 2 Mar 1998 12:27:56 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1430 Lines: 36 >c) Produce some form of SRAM card (even if it is only the same as that >designed by Bruce Gordon. This is to allow people to load and run new ROM >versions without the need to distribute EPROMs or the like. SIM Coupe anyone? >f) As platform becomes more stable develop more extensive form of C with >possibly both Z80 and Z380 object versions. Your item 1f comment is all well and good, but it needs a SAM architecture expert rather than a C expert to manage it. The problem isn't understanding the C language, it's mapping it into the SAM paging and filing structure. >g) Produce hardware and software for FTP site access from SAM (I think >necessary to allow for quick distribution of new working code, but only if a >fair number of people become involved in the project.) Not necessary for the project; we just use SIM Coupe to do it from PC's. Besides, do you know how much work converting the TCP/IP stack for the SAM to achieve this small project would be? If you're going to go that far, then coming up with a fully-fledged BSD compatible TCP/IP stack would be better, and useful in the long term. >The copyright owner releases this document for discussion purposes only to the >Sam Users Mailing List and to Comp.sys.sinclair. Provided that all >discussions take place under the original thread title. An interesting way of starting a discussion; presumably this is so that peoples hopes aren't got up. Simon From owner-sam-users@nvg.ntnu.no Mon Mar 2 18:53:44 1998 From: BillRitman Message-ID: <397a8e09.34fafb43@aol.com> Date: Mon, 2 Mar 1998 13:32:33 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0.i for Windows sub 178 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 697 Lines: 23 In a message dated 01/03/98 23:02:00, you write: > > Don't know where you get that idea from, looking through Computer Shopper > > there are some machines with zip drives, but not that many. > > Oh, sorry, I forgot that the rest of you lived in a technological > backwater of the world which is at least a year behind the current trends. > > >ahem< > > > > Therefore... I'd go straight for Zip or Jazz rather than trying out an > > > option that doesn't currently have the computer market's favour. > > > > Where should I send my order? > > Excuse me? > > Simon > Oh! I thought from your posts that you were going to develop a quick Zip interface or something. Bill. From owner-sam-users@nvg.ntnu.no Mon Mar 2 18:53:49 1998 From: BrenchleyR Message-ID: <24ad91f0.34fafd4e@aol.com> Date: Mon, 2 Mar 1998 13:41:16 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1270 Lines: 40 In a message dated 02/03/98 12:07:02, you write: > >Bob Br. wrote in response to someone:- > >>>The second is the ATOM, which as far as I >>>know hasn't been officially released, and I am lead to believe, has a >>>good working DOS, but it doesn't work in the same way as the first. >>> >>>If I were looking for a hard disk system for SAM, I think I'd go for >>>the second one, >> >> Well I think that would be a mistake, but of course your choice. SD's >hard >> drive allows you to connect any IDE hard drive and use it to its full. It >is a >> full 32 bit FAT and it only needs a little work on the ROM+MasterDOS to >get an >> integrated system that would be very fast and very powerful. > > >Bob, is this truth or anti-Persona slander? I'm just curious since I >haven't even been >allowed to see the details of ATOM and BDOS, never mind actually comparing >the two... > >Justin.... Sorry Justin? Anti-persona slander? I just gave a factual report on the SD interface. The only details I have of the Dutch system is that it /mounts/ a 800k section of the hard drive as a floppy drive which makes life much easier for the DOS but seems rather a waste of a 6Gb hard drive (which, by the way, Nev had working on his SAM just a couple of weekends ago). HTH. -- Bob. From owner-sam-users@nvg.ntnu.no Mon Mar 2 19:02:32 1998 From: BrenchleyR Message-ID: <802fd4c8.34fb0003@aol.com> Date: Mon, 2 Mar 1998 13:52:48 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM. Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 935 Lines: 26 In a message dated 02/03/98 18:46:41, you write: >On Mon, 2 Mar 1998 09:38:43 EST, BrenchleyR said: >> b) Look at existing Basic/DOS and define areas where closer specification >of >> syntax will reduce the amount of coding > >Not good if you want existing programs to be able to run with the new ROM. >Besides, I'm not sure how much you expect to save or indeed what bits of >syntax you are thinking of. > >imc Still not clear myself. One of the problems with SAM basic is that there are too many rules and exceptions to rules. As any new system will to a large extent be soft for a while there will be plenty of time to sort out any problems. My idea would be to say "write your new Basic programs to these rules and we will make sure they run on SAM and any later Z380 based Basic. I know there are some exceptions that I'm keen to get rid of but I'm not prepared to be too drawn on that this early in the work. HTH. -- Bob. From owner-sam-users@nvg.ntnu.no Mon Mar 2 20:00:19 1998 From: BrenchleyR Message-ID: <5a975fdc.34fb0d50@aol.com> Date: Mon, 2 Mar 1998 14:49:33 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 4648 Lines: 108 In a message dated 02/03/98 18:46:38, you write: >>He needed help because he was constantly coming up against problems in the >>ROM/MasterDOS. One of the major problems being that Andy does not have a >>consistent return path from syntax checking/command interpretation. >> >>The only way round this is to rework parts of the ROM and MasterDOS. Hence >the >>requirement to develop the SRAM card to make life easier for those doing >the >>testing. > > >Ummmmm... actually, if that were the case, then how on earth would MasterDOS >or MasterBASIC be able to do any of the O/S patching that they do? That I think should be one of the first targets. MasterDOS is actually self modifying in order that is can do some modes and then get rid of the extra code. So, it the ROM did not need patching, there would be some space in MasterDOS. OK, at first it may well be necessary to allocate an extra page to hold relocated code, but that can be looked at. > >I mean, yes, you're right, it isn't always consistent. Partly that is >because the command parsing and handling structure for BASIC isn't >documented, so you can't see the underlying structure. A real part of the problem is that Bruce kept going to Andy saying "look, can you do this bit here cos my brain herts at the moment". Andy, being a very nice man, did as he was asked. Problem was that a lot of that directly related to SAMDOS, so when MasterDOS came along he was stuck with Bruces way of doing things (like only having one set of drive registers so you are stuck with needing two 1772 disc conrollers in most cases). > >*thinks about getting the SAM ROM and MasterDOS source code and breaking it >down into chunks* Good idea. > >Bob... how about we publish the ROM and DOS code on the list for people to >work with? That might get things done. What I would like to see happen is that source code files for Comet are made available to those that agree that any part of the code they can document or improve upon is shared with all. I think a simple "I agree not to use the code to make profit, and that I will share my findings/developments with others" will be good enough. > >-Criteria for a DOS- > >1. Must have clearly defined layers in its structure -- eg. disk >controller -> record handling -> file handling -> etc. This is so that we >can swap in and out file systems and controllers at will. Also, it will mean >that we need to write a specific API for the job, and will have to divorce >the DOS completely from BASIC (barring some glue to get the BASIC commands >working). This is a Good Thing. Fine by me (with some minor reservations which can be looked at later) >2. It must provide the programmer with C/Unix style file handling. This will >enable future programmers to convert programs from other platforms easily. >At the moment, file handling is a nightmare if you want to do thing the >"traditional" way. >3. The new DOS must be, as far as possible, a free upgrade. Cost price only. >The source code must be GNU'd. The DOS must come with programming >documentation and example source code on the disk -- preferably with a >money-off discount for COMET assembler (which is what the source will be >in). Certainly to existing users I think that the replacement ROM and DOS should be cheap - but not quite free. However, any profit (that is taking out cost of programmed ROM, disc for DOS, printed paperwork, and P&P) should be used to fund other items. >4. It must include memory management functionality, including the ability to >reserve any size chunk from 1 byte to 1Mb. Preferably it'd run the gamut. >Ideally, it would be frugal about its memory usage for placeholder >information too. Don't think I would go down to 1 byte, but I see your point. >5. It should handle optional disk read-cacheing. This could work on the >early MSDOS principle that if there isn't a disk access for 2 seconds, check >that you're still using the same disk. Got some ideas there, will reveal all later. >6. Even if it doesn't actually read MSDOS/PRODOS disks, we should check the >format of the disk and inform the user that they've put one in the machine. >The check can be made by looking at bytes 510/511 of sector 1, track 0, side >0. MSDOS = &55AA Good idea. If the DOS is resident on Hard Drive then it can overlay routines to read/write text or code files to other disc formats. >7. Come on people, add to the list! > >Simon Machine must have stand-alone Basic, that is you switch on and type a prog if you need to. F9 boots from floppy, F7 from Hard Drive, F8 from network (would be nice). Booting procedure must be quick (unlike MSDOS machines). -- Bob. From owner-sam-users@nvg.ntnu.no Mon Mar 2 20:00:19 1998 From: BrenchleyR Message-ID: Date: Mon, 2 Mar 1998 14:49:37 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM. Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2041 Lines: 53 In a message dated 02/03/98 18:52:19, you write: > >>c) Produce some form of SRAM card (even if it is only the same as that >>designed by Bruce Gordon. This is to allow people to load and run new ROM >>versions without the need to distribute EPROMs or the like. > > >SIM Coupe anyone? I think that for those with PCs then SIM Coupe may be one way to go. Especially if we can order SIM Coupe to single step and give us access to the registers and RAM area. Any comments from the author? > >>f) As platform becomes more stable develop more extensive form of C with >>possibly both Z80 and Z380 object versions. > >Your item 1f comment is all well and good, but it needs a SAM architecture >expert rather than a C expert to manage it. The problem isn't understanding >the C language, it's mapping it into the SAM paging and filing structure. > >>g) Produce hardware and software for FTP site access from SAM (I think >>necessary to allow for quick distribution of new working code, but only if >a >>fair number of people become involved in the project.) > >Not necessary for the project; we just use SIM Coupe to do it from PC's. >Besides, do you know how much work converting the TCP/IP stack for the SAM >to achieve this small project would be? A valid point, but I still think that non-PC people must be encourage to work on the project. SIM Coupe may help, but nothing really beats the real SAM. > >If you're going to go that far, then coming up with a fully-fledged BSD >compatible TCP/IP stack would be better, and useful in the long term. > >>The copyright owner releases this document for discussion purposes only to >the >>Sam Users Mailing List and to Comp.sys.sinclair. Provided that all >>discussions take place under the original thread title. > >An interesting way of starting a discussion; presumably this is so that >peoples hopes aren't got up. > >Simon a) Very True. b) It allows for achiving of everything that is written on either this list of Comp.sys.sinclair by an automated bot, when I get it working :) -- Bob. From owner-sam-users@nvg.ntnu.no Tue Mar 3 13:55:55 1998 From: The Mad Goose Organization: University of Central Lancashire To: sam-users@nvg.unit.no Date: Tue, 3 Mar 1998 13:34:20 GMT+0 Subject: another 'great' argument... X-mailer: Pegasus Mail for Windows (v2.33) Message-ID: <71153C1875@mail-gw.uclan.ac.uk> X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 982 Lines: 32 > >Andrew did say that a Bootstrap program could be written in a quite > > short space of time allowing some software to work straight away > >(Keeping a large majority of people happy). The O/S could then be > >written over a longer period of time > > > >Makes sense to me > > > > > >Neil > > So I exagerated a bit, the point still stands that his claims have > always exceeded what he actually does. If he spent less time arguing > and actually did something I would take him more seriously. What would you like him to do? Andrew was proposing working on the bootstrap for the system you didn't want, and the SRAM idea doesn't seem to be going very far as far as I can see. If we'd perhaps gone down the route which this list suggested last year, then SamSon would be a little closer to realisty than it is today. just my 2p > > -- > Bob. Peace, Love, Kisses... Johnna Pig Teare JPOL: http://www.yi.com/home/TeareJohnna "I just want my future to live up to my past..." From owner-sam-users@nvg.ntnu.no Tue Mar 3 15:43:33 1998 From: BrenchleyR Message-ID: Date: Tue, 3 Mar 1998 10:12:39 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: another 'great' argument... Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 777 Lines: 28 In a message dated 03/03/98 14:16:25, you write: >> and actually did something I would take him more seriously. > >What would you like him to do? Andrew was proposing working on the >bootstrap for the system you didn't want, and the SRAM idea doesn't >seem to be going very far as far as I can see. > >If we'd perhaps gone down the route which this list suggested last >year, then SamSon would be a little closer to realisty than it is >today. > >just my 2p >> >> -- >> Bob. > >Peace, Love, Kisses... >Johnna Pig Teare And if you had read and understood the arguments last year, or if you refer to the latest thread entitled 'The Plan for SAM.' you will see why the SRAM was important at the time, and still is for those without the ability to run SIM Coupe. -- Bob. From owner-sam-users@nvg.ntnu.no Tue Mar 3 15:43:33 1998 From: BrenchleyR Message-ID: <30acd937.34fc1deb@aol.com> Date: Tue, 3 Mar 1998 10:12:40 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM. Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 999 Lines: 27 Just a note on SRAM in reply to question from Johnna under another heading. Two options exist for the SRAM board. Bruce Gordon's original version which just replaces the ROM, and Nev's design which goes a whole lot further. Another option would be to replace the existing ROM with a small board that used either Static RAM or Flash-ROM to allow alteration. At the moment the options are still open - at least until the next batch of boards of any type need to be run. HTH. -- Bob. (c) Copyright 1997/98 Format Publications. Released 03/03/1998. No part of this information may be distributed in any form or by any media without this copyright message being appended. Not for publication in paper or disc based magazines without the express permission in writing of Format Publications. The copyright owner releases this document for discussion purposes only to the Sam Users Mailing List and to Comp.sys.sinclair. Provided that all discussions take place under the original thread title. From owner-sam-users@nvg.ntnu.no Tue Mar 3 15:43:42 1998 X-Lotus-FromDomain: CASE TECHNOLOGY From: Justin_Skists@case.co.uk To: sam-users@nvg.unit.no Message-ID: <002565BC.005180E6.00@notes_a.case.co.uk> Date: Tue, 3 Mar 1998 15:25:17 +0000 Subject: Re: Floppy Disks Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 182 Lines: 8 > Sorry Justin? Anti-persona slander? It was just the way you said that you thought getting the BDOS + ATOM was a bad idea. I just wanted to know why you thought that... Justin. From owner-sam-users@nvg.ntnu.no Tue Mar 3 16:46:36 1998 From: Dean Liversidge To: sam-users@nvg.unit.no Date: Tue, 3 Mar 1998 16:24:12 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Floppy Disks In-reply-to: Message-Id: X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1106 Lines: 31 > In a message dated 28/02/98 13:26:25, you write: > > >On Sat, 28 Feb 1998 07:26:44 EST, BrenchleyR said: > >> >Is that FAT as in what the rest of the world thinks of as FAT (i.e., the > >> >MSDOS filing system) or some special non-FAT FAT? > > > >> FAT. File Allocation Table. In the case of HDOS a table of 32 bit words > >used > >> to control the allocation of disc space to files. > I disagree, Microsloth may have hi-jacked the word FAT but it has > been around for a lot longer than they have. They have one > implimentation of a FAT system, HDOS has its own. But a FAT is a FAT > is a FAT. Well, FAT the acronym is the same all over, but FAT12, FAT16, and FAT32 are comonly associated with MS-DOS compatable file systems, and should be kept that way, any reference to any type of file system should had a qualifier with it to explain what type of FAT system it is, as FAT on its own is a generic term. > >Either way it isn't a particularly efficient way of storing things on > >disks... No, but it would be nice to read and write MS-DOS disks, hard and floppy! -- Dean Liversidge From owner-sam-users@nvg.ntnu.no Wed Mar 4 12:36:20 1998 X-Lotus-FromDomain: CASE TECHNOLOGY From: Justin_Skists@case.co.uk To: sam-users@nvg.unit.no Message-ID: <002565BD.0036C307.00@notes_a.case.co.uk> Date: Wed, 4 Mar 1998 11:43:01 +0000 Subject: Malloc - Ummm.... Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 776 Lines: 20 A while ago, Simon asked for malloc algolrithms... I, very nicely, put in my version that I'm working on. Somehow, either people ignored it or they forgot to mention one vital peice of information: It was, to put it politely, crap. It took me a good proportion of the weekend to implement the design only for it to take AGES to run. I filled in squares on a bit of paper faster than my malloc took to run! I have designed and I'm now fixing bugs in a new one which should be lightning fast. Unfortunately, it's fairly memory unfriendly in that it still uses a 32K block to map the memory but now you can only allocate in multiples of 32bytes rather than 16. Oh well, at least it should be quick. It was quicker (and simpler) to implement aswell, it looks like... Justin. From imc Wed Mar 4 13:38:49 1998 Subject: Re: Malloc - Ummm.... To: sam-users@nvg.unit.no Date: Wed, 4 Mar 1998 13:38:49 +0000 (GMT) In-Reply-To: <002565BD.0036C307.00@notes_a.case.co.uk> from "Justin_Skists@case.co.uk" at Mar 4, 98 11:43:01 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 5082 Lines: 90 On Wed, 4 Mar 1998 11:43:01 +0000, Justin_Skists@case.co.uk said: > I, very nicely, put in my version that I'm working on. Somehow, > either people ignored it or they forgot to mention one vital > peice of information: It was, to put it politely, crap. Well, we weren't going to say that to your face... :-) Whatever you do, you probably want to obey the Sam page allocation map and fill it in to reflect pages you have used. (I suppose you might fill in the whole map to prevent other programs from stealing pages you thought were free, though that does prevent you from doing things like opening screens). A moderately standard malloc algorithm would probably be something like this. All free memory is stored in a free list. The first two words of each block of free memory store the size of the free block and the address of the next block in the list (there is therefore never any block of free memory smaller than two words). Using this method you don't actually need to eat up any storage to mark which bits of memory are reserved. When storage is requested you look at each free block in turn to discover whether it is large enough. You might stop at the first one which is large enough, or you might continue and find the best fit. After finding a free block which is large enough you either allocate it completely or split it into a used chunk and a free chunk. The used part is removed from the free list. The first word of the used block is not given to the application but used to hold the total length of the used block so that it can be added back to the free list when it is freed. When memory is freed it is added to the free list. It might be put on the beginning, on the end or in the middle. You might try to defragment the free list immediately or wait until a request arrives which cannot be satisfied. Defragmenting consists of gluing together free blocks which are adjacent in memory. Realloc is a bit of a pain. You know the actual size of the block (stored in the first word of the block) and the size of the new request. If you are lucky then the block is already large enough. You might want to split the block and add the rest to the free list if the request is much smaller than the current size. If the request is larger than the current size then you either allocate a fresh block and copy it across or you search the free list for the block of memory which comes immediately after this one. If you don't find it then you will still have to allocate a fresh block. Now the standard Unix malloc routine has to deal with the process "break". That is, it starts off with a minimal block of free memory, and when this runs out it grabs some more from the operating system. This is where you could use the page allocation table. Start off with just one page, and when this runs out try to grab one or more extra pages and mark them as reserved in the allocation table. You might want to treat requests for multiples of 16384 specially. Give them a whole page or number of pages straight from the page allocation table and record the number of pages given in a separate table. When they free it, you notice that the block address is on a page boundary so you look at your separate table to see whether it was one of these whole-page requests. If it was you just clear the appropriate bytes in the page allocation table. Now I don't know what strategies there are for ordering the free list (I suppose looking at the code for malloc in the GNU C library would give some hints). One possibility is to keep it unordered. Then "free" is quick but "malloc" and "realloc" potentially have to search the whole free list. You could keep it in size order. Then "free" and "malloc" have to look down the free list just as far as the first block which is too small; if malloc is going to split the free block it then has to travel a bit further down the list to find out where to put the free part of the block. [For this reason you might choose not to split blocks unless they are, say, more than twice the required size - this also reduces the amount of reallocing and defregmenting you have to do.] Or you could keep the blocks in order of address. All the functions then have to look down the whole free list but defragmenting a freed block is trivial. You might also reserve some special cases. For instance, if you reserve 16 blocks of 128, 8 blocks of 256, 4 blocks of 512 and 2 blocks of 1024 and give them separate free lists then whenever you receive a request for less than 1024 bytes you can instantly check whether there are any pre-allocated blocks of the appropriate size available and return one if so. No free-list searching because you know that the first free block is going to be the right size. When the block is freed you can tell by its address that it is a pre-allocated block. From the address you can also tell its size and therefore which free list to add it to. There is no need to reserve the first word of the block in these cases. imc From owner-sam-users@nvg.ntnu.no Wed Mar 4 15:39:58 1998 X-Lotus-FromDomain: CASE TECHNOLOGY From: Justin_Skists@case.co.uk To: sam-users@nvg.unit.no Message-ID: <002565BD.004FAB0F.00@notes_a.case.co.uk> Date: Wed, 4 Mar 1998 15:29:48 +0000 Subject: Re: Malloc - Ummm.... Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2345 Lines: 53 >> I, very nicely, put in my version that I'm working on. Somehow, >> either people ignored it or they forgot to mention one vital >> peice of information: It was, to put it politely, crap. > >Well, we weren't going to say that to your face... :-) That was very nice of you! :) But you could've saved me cooking egg on my face before I coded the damn thing! :) I just looked at it afterwards and thought: "Oh my God, this is about as efficient as a fart in a trance!" (Slow, complicated and annoying) > Whatever you do, you probably want to obey the Sam page allocation map and >fill it in to reflect pages you have used. (I suppose you might fill in >the whole map to prevent other programs from stealing pages you thought >were free, though that does prevent you from doing things like opening >screens). Actually, I wasn't going to bother with compatability with other programs; I didn't fancy the hassle. But that is a good point since you will be able to access stuff like ROM and BASIC with it. As you may see, I'm not exactly working for the SamSon project; This is my own personal project. It's an application platform to start from a clean boot. Something to do in my own spare time (of which I don't have enough of, these days). It will end up taking advantage of the hardware I'm going to build for it so that malloc and task stuff will be held externally. The malloc routine I'm making at the moment is a variation of the first one I had. Like I said before, I'm heading to keep the map on an external card so I'm going for speed, rather than size. (And I won't get RAM contention with the screen hardware!) The map is a 32K block of memory. Each location in the map represents a real address of (map_addr * 16). A pointer is positioned at the start of the allocated/free memory block pointing to the next one (start of the next / end of the current block). Bit 15 is set if the block is filled or no if it's empty. A couple of 16bit subractions, a few ld's and an addition is all that's really required for the actual allocating of memory. (Ok, slight exaggeration there.) It was already planned to have the option of searching the memory for allocations that are allowed to straddle page boundaries or not. But simply allocating pages is a good idea aswell. And thanks for reminding me of realloc; I forgot that! Justin. From owner-sam-users@nvg.ntnu.no Wed Mar 4 17:14:11 1998 From: BrenchleyR Message-ID: <36665db8.34fd8a44@aol.com> Date: Wed, 4 Mar 1998 12:07:14 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 527 Lines: 21 In a message dated 03/03/98 15:56:21, you write: > >> Sorry Justin? Anti-persona slander? > >It was just the way you said that you thought getting the BDOS + >ATOM was a bad idea. I just wanted to know why you thought that... > >Justin. > > Two point there, one was that he was dismissing the SD system because he had been told that there would be no new development. And two, the SD system allows you to access the hard drive - rather than keep floppy drive images on it. Not anti anything, just pro something :) -- bob. From owner-sam-users@nvg.ntnu.no Wed Mar 4 17:14:11 1998 From: BrenchleyR Message-ID: Date: Wed, 4 Mar 1998 12:07:17 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 376 Lines: 16 In a message dated 03/03/98 16:47:50, you write: >> >Either way it isn't a particularly efficient way of storing things on >> >disks... > >No, but it would be nice to read and write MS-DOS disks, hard and >floppy! > >-- >Dean Liversidge To read MS-DOS floppy discs it would be much easier to provide extensions rather than make it part of any operating system. -- Bob. From owner-sam-users@nvg.ntnu.no Wed Mar 4 19:42:51 1998 From: Gouranga Message-ID: <8da53d4b.34fdade3@aol.com> Date: Wed, 4 Mar 1998 14:39:13 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Gloucester!!! Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: Windows AOL sub 168 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 638 Lines: 21 OK, now that the drunken debauchery has taken place at Leeds - hey, I managed to get to the show for almost 90 minutes - I feel it is my duty to start organisation for Gloucester. The date's April 4th, which means any/all of the following should report for duty at a Gloucester hostelry early evening April 3rd :- Colin Anderton Dan Doore Stefan Drissen Chris White Simon Cooke Ian Slavin my good self and anyone else with smart trousers suitable for entry into the bad taste experience that is Gloucester's nightlife. B&B booking service on hand as usual - mail me at DigAdd@aol.com to get yourself kitted out for service... Colin M From owner-sam-users@nvg.ntnu.no Wed Mar 4 20:22:04 1998 Message-Id: <3.0.1.32.19980304151031.006c74b0@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 04 Mar 1998 15:10:31 -0500 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Gloucester!!! In-Reply-To: <8da53d4b.34fdade3@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1588 Lines: 36 >The date's April 4th, which means any/all of the following should report for >duty at a Gloucester hostelry early evening April 3rd :- > >Colin Anderton >Dan Doore >Stefan Drissen >Chris White >Simon Cooke Unfortunately, due to circumstances beyond my control [1], I won't be able to make it. Have a pint for me, guys! I may / may not make it to the next one too -- at the moment, while I'm coming back to the UK on April 22nd, I may be going back to America around October time (possibly later/earlier) to work for the big M S. Wahey! Subvert the evil ogliopoly from the inside! Power to the user! Simon [1] Namely an unchangeable plane ticket, and an American boss who wants to wring me for all the work he can get before I go back to the UK. Not only that, but it's an American boss who reckons he can get another developer for $40,000[2] in this town. (I didn't have the heart to tell him that he was underpaying me by somewhere between $25K-$55K according to the figures I've been looking at and the job offers I've been getting). [2] In DC, that's enough to buy you a hamburger, and not much else. Honest. My rent is currently 600 quid a month, for a place about a quarter the size of the one I was renting in Tyldesley for half that. And even then, I'm 50 miles out of the city centre.[3] [3] Which isn't much, by american standards. *********************************************************** *Product Development Specialist/WebMaster/Graphic Designer* *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* *********************************************************** From owner-sam-users@nvg.ntnu.no Wed Mar 4 23:14:49 1998 Message-Id: <3.0.1.32.19980304152645.006c93e8@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 04 Mar 1998 15:26:45 -0500 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Floppy Disks In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 685 Lines: 20 At 12:07 PM 3/4/98 EST, you wrote: >To read MS-DOS floppy discs it would be much easier to provide extensions >rather than make it part of any operating system. Well.. maybe. To be honest, I'd prefer to switch to the MSDOS system; it's well understood, it's portable to almost any machine in the world... The only problem then is the file attributes. HPFS anyone? (but that's not much cop for floppy systems -- too intensive) (rats) Simon *********************************************************** *Product Development Specialist/WebMaster/Graphic Designer* *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* *********************************************************** From imc Thu Mar 5 00:00:46 1998 Subject: Re: Floppy Disks To: sam-users@nvg.unit.no Date: Thu, 5 Mar 1998 00:00:46 +0000 (GMT) In-Reply-To: <3.0.1.32.19980304152645.006c93e8@nessie.mcc.ac.uk> from "Simon Cooke" at Mar 4, 98 03:26:45 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 577 Lines: 17 On Wed, 04 Mar 1998 15:26:45 -0500, Simon Cooke said: > To be honest, I'd prefer to switch to the MSDOS system; it's well > understood, it's portable to almost any machine in the world... > The only problem then is the file attributes. What problem? > HPFS anyone? (but that's not much cop for floppy systems -- too intensive) OS/2 doesn't support it for removable drives, which might indicate that it's not suitable for a floppy. Also, Linux only has read-only support for HPFS, which might indicate that IBM doesn't publish enough specs to get r/w access working. imc From owner-sam-users@nvg.ntnu.no Thu Mar 5 00:04:39 1998 Message-Id: <3.0.1.32.19980304185516.006bedfc@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 04 Mar 1998 18:55:16 -0500 To: sam-users@nvg.ntnu.no From: Simon Cooke Subject: Technical Manual Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;sam-users@nvg.ntnu.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 456 Lines: 13 Just out of interest, who owns the copyright on the Tech Manual? I mean, would anyone have any objections on me scanning it in and publishing it on the net? Otherwise, I can start writing my own one again. Simon *********************************************************** *Product Development Specialist/WebMaster/Graphic Designer* *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* *********************************************************** From owner-sam-users@nvg.ntnu.no Thu Mar 5 01:22:41 1998 Message-Id: <3.0.1.32.19980304201205.006beec8@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 04 Mar 1998 20:12:05 -0500 To: sam-users@nvg.ntnu.no From: Simon Cooke Subject: C Compiler Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;sam-users@nvg.ntnu.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 501 Lines: 17 http://www.cs.princeton.edu/software/lcc/ A retargetable C compiler. Someone's come up with a backend for it which will output Z80 code -- ints are 8 bit and longs are 16 bit though. (http://lsewww.epfl.ch/~felber/GBDK/#Compiler) Anyone interested? Simon *********************************************************** *Product Development Specialist/WebMaster/Graphic Designer* *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* *********************************************************** From owner-sam-users@nvg.ntnu.no Thu Mar 5 01:22:42 1998 Message-Id: <3.0.1.32.19980304201330.006beec8@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 04 Mar 1998 20:13:30 -0500 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Floppy Disks In-Reply-To: <199803050000.AAA00998@chalca.comlab.ox.ac.uk> References: <3.0.1.32.19980304152645.006c93e8@nessie.mcc.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 892 Lines: 26 >> The only problem then is the file attributes. > >What problem? Well... program type, snapshot registers, etc. Sure, it's not insurmountable, but it's not (I reckon) a simple bodge. >> HPFS anyone? (but that's not much cop for floppy systems -- too intensive) > >OS/2 doesn't support it for removable drives, which might indicate that >it's not suitable for a floppy. > >Also, Linux only has read-only support for HPFS, which might indicate that >IBM doesn't publish enough specs to get r/w access working. Yeah... which is why I was giving up on it for floppies. Though... *thinks*... a file which contained those attributes... hmmm... Simon *********************************************************** *Product Development Specialist/WebMaster/Graphic Designer* *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* *********************************************************** From owner-sam-users@nvg.ntnu.no Thu Mar 5 01:51:10 1998 X-Sender: asc25@pop.hermes.cam.ac.uk Message-Id: In-Reply-To: <3.0.1.32.19980304201330.006beec8@nessie.mcc.ac.uk> References: <199803050000.AAA00998@chalca.comlab.ox.ac.uk> <3.0.1.32.19980304152645.006c93e8@nessie.mcc.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 5 Mar 1998 01:40:12 +0000 To: sam-users@nvg.unit.no From: Andrew Collier Subject: Re: Floppy Disks X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1724 Lines: 43 At 1:13 am +0000 5/3/98, Simon Cooke wrote: >>> The only problem then is the file attributes. >> >>What problem? > >Well... program type, snapshot registers, etc. > >Sure, it's not insurmountable, but it's not (I reckon) a simple bodge. ... >Though... *thinks*... a file which contained those attributes... hmmm... Would each individual disk file have a corresponding attributes file - probably inefficient - or would you have one file holding information for all other files on the disk - less wasteful of space but liable to get fragmented perhaps? Sounds a bit like the Mac's system of storing Mac-specific things (like long filenames, icon, creator codes etc) on an MS-DOS formatted disk. What exactly will happen when you save a file onto this disk in your PC which takes no notice of your attributes file? On similar lines, it would probably be possible to allow the use of 8.3 filenames and Sam's 10-character filenames on such a disk without too much hassle.... Use 8.3 if there's a dot in the right place already; if not, automatically put some underused character in the first byte of the extension and use the remaining 10 characters for the filename. The user doen't need to know about any of this..? Andrew --- +-----------------+----------------------------+--------------------+ | Andrew Collier | email asc25@cam.ac.uk | " | | 1B NatSci | http://carou.sel.cam.ac.uk | Get your kicks | +-----------------+----------------------------+ on 8.124038405 | | Selwyn College Student Computer Support Team | " | | email support@sel.cam.ac.uk | anon | +----------------------------------------------+--------------------+ From owner-sam-users@nvg.ntnu.no Thu Mar 5 03:09:01 1998 Date: Thu, 5 Mar 98 02:52:04 GMT Message-ID: <1032_OASIS_@lhutz.demon.co.uk> From: James@lhutz.demon.co.uk (James R Curry) To: sam-users@nvg.unit.no X-Mailer: OASIS Post Box (Atari) v1.31E Subject: Re: Floppy Disks X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 742 Lines: 24 >To be honest, I'd prefer to switch to the MSDOS system; it's well >understood, it's portable to almost any machine in the world... Herein lies my problem... we've mentioned this a lot. Let's use PC this and PC that, for the reasons that they're easily available/portable - but are we going to end up at a point where we may as well just be building a PC? It's 3am. If that didn't make any sense, you know why. __ James R Curry - James@lhutz.demon.co.uk "You're missing the point! The individual doesn't matter. It was a team effort, and I was the one who came up with the whole team idea...me!" - Homer Simpson, The Simpsons. Please insert meaningless promise about The Official James R Curry web page here... From owner-sam-users@nvg.ntnu.no Thu Mar 5 07:31:16 1998 Date: Thu, 5 Mar 1998 08:27:09 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9803050727.AA16359@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: Floppy Disks X-Sun-Charset: US-ASCII X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 206 Lines: 7 > > To read MS-DOS floppy discs it would be much easier to provide extensions > rather than make it part of any operating system. Indeed, but make 'extendability' a part of the operating system! -Frode From owner-sam-users@nvg.ntnu.no Thu Mar 5 08:45:58 1998 Message-ID: <00b801bd4812$5d74f880$f03ca8c0@DavesPC.DOMAIN_ORCHID> From: David Zambonini To: sam-users Subject: Back again. Date: Thu, 5 Mar 1998 08:40:04 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 267 Lines: 9 Oooops. I've been off with a virussy thingy that's gone right through the entire development team in work the last three days. Now I'm back, so I'm just going to wade through all you Emails and I should post **something** this afternoon with any luck..... DMZ --- From owner-sam-users@nvg.ntnu.no Thu Mar 5 09:14:32 1998 Message-ID: <01c301bd4816$2e32bf40$f03ca8c0@DavesPC.DOMAIN_ORCHID> From: David Zambonini To: sam-users Subject: Final curtain prices Date: Thu, 5 Mar 1998 09:07:23 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 442 Lines: 20 Current offers on equiptment is as follows:- (you know who you are). Looks like I may have to wait and see if anyone wants any of the rest of it, and just sell on these bits initially.... Any more offers? 1 Meg RAM 50.00 Mouse I/F (+mouse) 10.00 Comms I/F 25.00 MasterDOS 2.00 Tech manual 4.00 Prince of Persia 3.00 Batz n Balls 2.00 Pipemania 2.00 Vegetable Vacation 2.00 DMZ --- From owner-sam-users@nvg.ntnu.no Thu Mar 5 09:52:54 1998 Message-ID: <024401bd481b$8ac7aae0$f03ca8c0@DavesPC.DOMAIN_ORCHID> From: David Zambonini To: sam-users Subject: Hardware List Revisited Date: Thu, 5 Mar 1998 09:45:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 953 Lines: 44 Now, some people have said 'I've lost the original list. Can I have it again?' So.... I've decided to repost the list **with some revisions** -- look carefully! >**** FOR SALE **** > >* SAM Coupe 512K > * upgraded v2 ROM > * 1 original citizen ultra slimline floppy drive > * original power supply (with one new capacitor, slightly melted case!) > * dog eared users manual (that is, the manual is scruffy, not a manual > for dog eared users) >* 1 Meg RAM >* Comms interface >* SAM Mouse interface (and mouse) >* SAMDAC >* Joystick splitter >* MasterDOS >* MasterBASIC >* SAM Technical manual >* Wop gamma >* SAM Strikes out / Futureball >* Defenders of the Earth >* Prince of Persia >* Batz n Balls >* Escape from the planet of the robot monsters >* Five on a treasure island >* Sphera >* Pipemania >* Vegetable Vacation >* E-Tracker >* Star Atlas >* Outwrite >* The Sound machine >* Assorted issues of FRED >* SC Assembler DMZ --- From imc Thu Mar 5 12:34:20 1998 Subject: Re: Floppy Disks To: sam-users@nvg.unit.no Date: Thu, 5 Mar 1998 12:34:20 +0000 (GMT) In-Reply-To: <9803050727.AA16359@asmal.edh-net> from "Frode Tenneboe" at Mar 5, 98 08:27:09 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 578 Lines: 14 On Thu, 5 Mar 1998 08:27:09 +0100, Frode Tenneboe said: > > To read MS-DOS floppy discs it would be much easier to provide extensions > > rather than make it part of any operating system. > Indeed, but make 'extendability' a part of the operating system! Sort of like the Linux "virtual file system" scheme... In fact you could copy Linux's loadable modules. Simply load the module for the VFS you desire and bingo. Or create a customised version of DOS using a special program which adds together the base OS and the loadable modules for the specified file systems. imc From owner-sam-users@nvg.ntnu.no Thu Mar 5 14:14:23 1998 From: Paul Walker Message-Id: <199803051355.NAA18735@crocus.csv.warwick.ac.uk> Subject: Re: Gloucester!!! In-Reply-To: <8da53d4b.34fdade3@aol.com> from Gouranga at "Mar 4, 98 02:39:13 pm" To: sam-users@nvg.unit.no Date: Thu, 5 Mar 1998 13:55:46 +0000 (GMT) X-Approved: bill@whitehouse.gov X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 226 Lines: 7 > and anyone else with smart trousers suitable for entry into the bad taste > experience that is Gloucester's nightlife. You mean Gloucester has nightlife? (Other than the sort that you ask not to break *both* your legs?) From owner-sam-users@nvg.ntnu.no Thu Mar 5 14:14:23 1998 From: Paul Walker Message-Id: <199803051359.NAA19458@crocus.csv.warwick.ac.uk> Subject: Re: Floppy Disks In-Reply-To: <199803051234.MAA02022@chalca.comlab.ox.ac.uk> from Ian Collier at "Mar 5, 98 12:34:20 pm" To: sam-users@nvg.unit.no Date: Thu, 5 Mar 1998 13:59:19 +0000 (GMT) X-Approved: bill@whitehouse.gov X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 148 Lines: 4 > In fact you could copy Linux's loadable modules. Simply load the module Now that's the most sensible idea for this that I'd heard for a while. From owner-sam-users@nvg.ntnu.no Thu Mar 5 14:52:17 1998 Date: Thu, 5 Mar 1998 15:39:13 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9803051439.AA17115@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: C Compiler X-Sun-Charset: US-ASCII X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 603 Lines: 22 > http://www.cs.princeton.edu/software/lcc/ > > A retargetable C compiler. > > Someone's come up with a backend for it which will output Z80 code -- ints > are 8 bit and longs are 16 bit though. > > (http://lsewww.epfl.ch/~felber/GBDK/#Compiler) > > Anyone interested? Very tempting....indeed...very tempting.... -Frode > *********************************************************** > *Product Development Specialist/WebMaster/Graphic Designer* > *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* > *********************************************************** The modest Brit..... ;) From owner-sam-users@nvg.ntnu.no Thu Mar 5 16:06:51 1998 Date: Thu, 5 Mar 1998 16:05:22 +0000 (GMT) From: Allan Skillman To: sam-users@nvg.unit.no Subject: Mostly 'ARMless Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1953 Lines: 46 Hello All, Well, I'm back, actually to be honest I've been reading the mailing list for a week or so. Its nice to see a proper Sam related discussion. I now have my new PC set up with Linux and Windows (spit) 95, and yesterday I downloaded and installed DJGPP, and my SimCoupe sources from my old notebook. The code built clean and runs great (100% speed on this Pentium 166). I'm just coming out from under a heap of work, so I should be able to put together a developement binary release over the weekend. Highlights include : o SAM speaker emulation using the PC speaker o Improved GUI controls (more like Windows) o File selector filter can now be lists (ie *.dsk,*.sad) o New SVGA mode 640x240 rather than 640x480, less pixels to address so much faster o Audio TSR is disabled during GUI o Disk change bug fixed To answer a question from Bob regarding SimCoupe and single stepping; there is a simple debugger in the code, but it is turned off in the DOS version, as the program runs in a graphics mode, and so has no console to use for the debugger. On the UNIX version the program uses X11 and so there is usually an xterm window to use as the console. This port of lcc pointed out by Simon sounds very interesting. This should be quite easy to adapt to cross building Sam executable files. Sorry you can't come to Gloucester Simon. We (all Sam mailing list people) should meet up for a pint some time when you are in the UK. Right back ARM 9 cache emulation..... Allan +--------------------------------------------------------------------------+ | Allan Skillman | "There are five flavours of resons, the | | EDA Group | elementary particles of magic : up, down, | | Advanced RISC Machines | sideways, sex-appeal and peppermint." | | allan.skillman@arm.com | - Terry Pratchett (Lords and Ladies) | +------------------------------+-------------------------------------------+ From imc Thu Mar 5 16:12:43 1998 Subject: Re: Mostly 'ARMless To: sam-users@nvg.unit.no Date: Thu, 5 Mar 1998 16:12:43 +0000 (GMT) In-Reply-To: from "Allan Skillman" at Mar 5, 98 04:05:22 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 330 Lines: 10 On Thu, 5 Mar 1998 16:05:22 +0000 (GMT), Allan Skillman said: > o New SVGA mode 640x240 rather than 640x480, less pixels to address so > much faster That sounds like an unusual mode. Do many computers support it? Mine doesn't (that I know of anyway). imc (why does netscape go dead when I accidentally press shift-insert?) From owner-sam-users@nvg.ntnu.no Thu Mar 5 16:12:46 1998 X-Lotus-FromDomain: CASE TECHNOLOGY From: Justin_Skists@case.co.uk To: sam-users@nvg.unit.no Message-ID: <002565BE.004D33B5.00@notes_a.case.co.uk> Date: Thu, 5 Mar 1998 15:37:54 +0000 Subject: SamSon - The aim??? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1537 Lines: 40 Hi Gang, Just a small question: What on earth is the aim of the SamSon project, anyway? The impression I get is that it is to end up creating a computer that we can be proud of as computer enthusiasts that is easy to use/play-about- with without all the higglety-pigglety crap that the PC gives us. Chatting to a work-mate of mine yesterday (as he was overlooking my email writing as I wrote the word SamSon) he thought the idea of a Z380 based new computer was rather pointless. He suggested that as long as it has a decent operating system, that you can directly play with the registers (both software and hardware) and some-such, and that it had a decent processor to play with (ie, not Z80 based but ARM or something). Do we really need something that's SAM compatible? When we already have a SAM? (If we really want, we could compile SimCoupe for it!) There are plenty of 8bit computers in the world. But a MIPS R3000 (like as used in the PlayStation) will attract some attention in the computer enthusiats world. As long as we include the SAMs character (which, speaking to my work-mate, is basically the same as the Amiga's), we should be able to get not only us lot, but maybe a vast majority of other ex-decent computer users (That's users of old decent computers, not old decent users of computers) . If something like that came on the market, he'd certainly buy one. In fact, so would I! The only reason why I kept my SAM (and why my work-mate kept his Amiga) was because we can "play" with them! Take care, Justin From owner-sam-users@nvg.ntnu.no Thu Mar 5 16:30:38 1998 From: BrenchleyR Message-ID: <41c6a705.34fecea7@aol.com> Date: Thu, 5 Mar 1998 11:11:16 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Technical Manual Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 380 Lines: 22 In a message dated 05/03/98 00:05:49, you write: >o > >Just out of interest, who owns the copyright on the Tech Manual? Format Publications. > >I mean, would anyone have any objections on me scanning it in and >publishing it on the net? Yes I would, we still sell them. > >Otherwise, I can start writing my own one again. Good luck, rather you than me :) > >Simon -- Bob. From owner-sam-users@nvg.ntnu.no Thu Mar 5 16:30:38 1998 From: BrenchleyR Message-ID: <87a08705.34feceab@aol.com> Date: Thu, 5 Mar 1998 11:11:20 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 416 Lines: 15 In a message dated 05/03/98 07:28:09, you write: >> >> To read MS-DOS floppy discs it would be much easier to provide extensions >> rather than make it part of any operating system. > >Indeed, but make 'extendability' a part of the operating system! > > -Frode Quite right. I though of using the device letter so D1 is disc drive 1, M1 would be MS-DOS disc in drive 1. We have 26 letters to go for.... -- Bob. From owner-sam-users@nvg.ntnu.no Thu Mar 5 16:30:40 1998 From: BrenchleyR Message-ID: <4e018a84.34feceab@aol.com> Date: Thu, 5 Mar 1998 11:11:21 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 674 Lines: 22 In a message dated 05/03/98 13:18:00, you write: > >On Thu, 5 Mar 1998 08:27:09 +0100, Frode Tenneboe said: >> > To read MS-DOS floppy discs it would be much easier to provide extensions >> > rather than make it part of any operating system. > >> Indeed, but make 'extendability' a part of the operating system! > >Sort of like the Linux "virtual file system" scheme... > >In fact you could copy Linux's loadable modules. Simply load the module >for the VFS you desire and bingo. Or create a customised version of DOS >using a special program which adds together the base OS and the loadable >modules for the specified file systems. > >imc Sounds good to me. -- Bob. From owner-sam-users@nvg.ntnu.no Thu Mar 5 16:30:54 1998 From: BrenchleyR Message-ID: <6edfc485.34fecea9@aol.com> Date: Thu, 5 Mar 1998 11:11:19 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 522 Lines: 21 In a message dated 05/03/98 03:09:19, you write: >o > > > >>To be honest, I'd prefer to switch to the MSDOS system; it's well >>understood, it's portable to almost any machine in the world... > >Herein lies my problem... we've mentioned this a lot. Let's use PC >this and PC that, for the reasons that they're easily >available/portable - but are we going to end up at a point where we >may as well just be building a PC? > >It's 3am. If that didn't make any sense, you know why. > It did, and I agree. -- Bob. From owner-sam-users@nvg.ntnu.no Thu Mar 5 16:30:56 1998 From: BrenchleyR Message-ID: <12341c84.34feceac@aol.com> Date: Thu, 5 Mar 1998 11:11:22 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Gloucester!!! Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 453 Lines: 18 In a message dated 05/03/98 14:18:07, you write: >o > > >> and anyone else with smart trousers suitable for entry into the bad taste >> experience that is Gloucester's nightlife. > >You mean Gloucester has nightlife? > >(Other than the sort that you ask not to break *both* your legs?) Oh yes, Gloucester has nightlife - you should see the state of Colin the following day.... (on second thoughts, no, you shouldn't see the state of him). -- Bob. From owner-sam-users@nvg.ntnu.no Thu Mar 5 16:30:57 1998 Message-Id: <3.0.1.32.19980305111105.006c88c8@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 05 Mar 1998 11:11:05 -0500 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: C Compiler In-Reply-To: <9803051439.AA17115@asmal.edh-net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1311 Lines: 36 At 03:39 PM 3/5/98 +0100, you wrote: >> Someone's come up with a backend for it which will output Z80 code -- ints >> are 8 bit and longs are 16 bit though. >> >> (http://lsewww.epfl.ch/~felber/GBDK/#Compiler) >> >> Anyone interested? > >Very tempting....indeed...very tempting.... Ooops - forgot to mention -- it's a Gameboy compiler, so it'll need a slight bit of modification to get it to make use of the full Z80 instruction set. (Gameboys, for the uninitiated, use a cut-down version of the Z80 set, lacking all of the IO instructions, but with some indexing-with-HL instructions added. Presumably they also don't have IX/IY, which is why the indexed HL set is there). >> *********************************************************** >> *Product Development Specialist/WebMaster/Graphic Designer* >> *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* >> *********************************************************** > >The modest Brit..... ;) Well, no-one else is going to blow my trumpet for me. Erm. Maybe I should have put that another way ;) Simon *********************************************************** *Product Development Specialist/WebMaster/Graphic Designer* *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* *********************************************************** From imc Thu Mar 5 16:43:18 1998 Subject: Re: Floppy Disks To: sam-users@nvg.unit.no Date: Thu, 5 Mar 1998 16:43:18 +0000 (GMT) In-Reply-To: <87a08705.34feceab@aol.com> from "BrenchleyR" at Mar 5, 98 11:11:20 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 512 Lines: 12 On Thu, 5 Mar 1998 11:11:20 EST, BrenchleyR said: > Quite right. I though of using the device letter so D1 is disc drive 1, M1 > would be MS-DOS disc in drive 1. We have 26 letters to go for.... 1. There are not 26 spare letters, since t and n are already used. 2. Drive letters should specify the device, not the filing system. D1 and M1 is a horrid idea. The filing system should be auto-detected, or depend on which module is loaded, or else be set with a command (DEVICE FORMAT "MSDOS" anyone?). imc From owner-sam-users@nvg.ntnu.no Thu Mar 5 17:06:26 1998 Illegal-Object: Syntax error in Message-Id: value found on sabre-wulf.nvg.ntnu.no: Message-Id: ^-Extraneous program text From: Dan Doore Date: Thu, 5 Mar 1998 16:38:45 +0000 To: sam-users@nvg.ntnu.no Subject: RE: Mostly 'ARMless MIME-version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: TFS Gateway /310000000/310102093/310102123/310460310/ X-Orcpt: rfc822;sam-users@nvg.ntnu.no Reply-To: sam-users@nvg.unit.no Message-Id: <19980305163853Z49515-17529+368@sabre-wulf.nvg.ntnu.no> Status: RO Content-Length: 679 Lines: 27 > Well, I'm back, actually to be honest I've been reading the mailing > list for a week or so. Its nice to see a proper Sam related discussion. Welcome back! > o SAM speaker emulation using the PC speaker Groovy. > o File selector filter can now be lists (ie *.dsk,*.sad) What's a SAD file? > o Audio TSR is disabled during GUI I had big problems with the last PC 'snapshot' binary and running the TSR, it crashes in Win95 and completely halts the PC in DOS mode when the TSR is running - can't the SAA source be included in the distribution? - or does Aley not want that? Dan. Work: dan@bacg.com Shirk: dan@podboy.demon.co.uk VVeb: http://www.podboy.demon.co.uk/ From owner-sam-users@nvg.ntnu.no Thu Mar 5 17:06:28 1998 Message-Id: <3.0.1.32.19980305115325.006c0e00@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 05 Mar 1998 11:53:25 -0500 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Floppy Disks In-Reply-To: <199803051643.QAA03167@chalca.comlab.ox.ac.uk> References: <87a08705.34feceab@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1087 Lines: 28 At 04:43 PM 3/5/98 +0000, you wrote: >Status: > >On Thu, 5 Mar 1998 11:11:20 EST, BrenchleyR said: >> Quite right. I though of using the device letter so D1 is disc drive 1, M1 >> would be MS-DOS disc in drive 1. We have 26 letters to go for.... > >1. There are not 26 spare letters, since t and n are already used. >2. Drive letters should specify the device, not the filing system. D1 and M1 > is a horrid idea. > >The filing system should be auto-detected, or depend on which module is >loaded, or else be set with a command (DEVICE FORMAT "MSDOS" anyone?). Hmmm... not bad. But auto-detection is easy enough; and should be used to get disk-ID info for MasterDOS disks to enable disk cacheing. Speaking of which... we need a good random number generator for the purpose; MasterDOS appears to use the refresh register, AFAICR. Simon *********************************************************** *Product Development Specialist/WebMaster/Graphic Designer* *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* *********************************************************** From owner-sam-users@nvg.ntnu.no Thu Mar 5 17:11:53 1998 Date: Thu, 5 Mar 1998 16:44:54 +0000 (GMT) From: Allan Skillman To: sam-users@nvg.unit.no Subject: Re: Mostly 'ARMless In-Reply-To: <199803051612.QAA03065@chalca.comlab.ox.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 919 Lines: 19 > On Thu, 5 Mar 1998 16:05:22 +0000 (GMT), Allan Skillman said: > > o New SVGA mode 640x240 rather than 640x480, less pixels to address so > > much faster > > That sounds like an unusual mode. Do many computers support it? > Mine doesn't (that I know of anyway). Its a VGA (standard VGA that is) trick pointed out to me by Aley (he or the SAA TSR). You can halve the number of displayed lines in any VGAlike mode ie 640x240 is 640x480 halved. Allan +--------------------------------------------------------------------------+ | Allan Skillman | "There are five flavours of resons, the | | EDA Group | elementary particles of magic : up, down, | | Advanced RISC Machines | sideways, sex-appeal and peppermint." | | allan.skillman@arm.com | - Terry Pratchett (Lords and Ladies) | +------------------------------+-------------------------------------------+ From owner-sam-users@nvg.ntnu.no Thu Mar 5 18:26:23 1998 X-Sender: asc25@pop.hermes.cam.ac.uk Message-Id: In-Reply-To: <64b8fec2.34fac475@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 5 Mar 1998 17:48:21 +0000 To: sam-users@nvg.unit.no From: Andrew Collier Subject: Re: The Plan for SAM. X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1972 Lines: 41 At 2:38 pm +0000 2/3/98, BrenchleyR wrote: >1. To provide on SAM a stable development platform for software required both >for the existing SAM and for anything that is to follow. Please confirm what exactly is "unstable" about the current Sam firmware; the tools used for development - assemblers and compilers - don't rely on ROM routines. Comet already seems pretty stable to me. ... >f) As platform becomes more stable develop more extensive form of C with >possibly both Z80 and Z380 object versions. Z80 and Z380 compilers will be almost totally independent, due to the fundamentally different architecture. The Z80 back-end will (for all but the smallest and simplest projects) need to know about things like memory paging which (particularly in terms of splitting your executable into 32K blocks and switching between them whilst keeping track of the stack, data structures etc) will be very difficult for a compiler to code automatically. That's not to say I think the C compiler is a bad idea - but IMO the eventual SamSon goal would be reached more quickly if the extra processor board is designed first, and the compiler is written to produce Z380 object code. However I still think core of the operating system would be better written in assembly. The low-level language is better suited to the task in hand, and will produce more efficient code. The code may well be more reliable too, since it will not have to rely on C libraries being bug free. Andrew --- +-----------------+----------------------------+--------------------+ | Andrew Collier | email asc25@cam.ac.uk | " | | 1B NatSci | http://carou.sel.cam.ac.uk | Get your kicks | +-----------------+----------------------------+ on 8.124038405 | | Selwyn College Student Computer Support Team | " | | email support@sel.cam.ac.uk | anon | +----------------------------------------------+--------------------+ From owner-sam-users@nvg.ntnu.no Thu Mar 5 19:09:17 1998 MIME-Version: 1.0 From: sskardon@argonet.co.uk (Stewart Skardon) To: sam-users@nvg.unit.no Date: Thu, 5 Mar 98 16:01:00 X-Mailer: VTi Internet Email reader 1.09 : aa Subject: Re: C Compiler Content-Type: text/plain Message-Id: X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 597 Lines: 23 Talking about C compilers had just reminded me... What ever happened to that special offer that FRED and FORMAT were supposed to be doing? ;-) Stewart -- _ (_'tewart email : sskardon@argonet.co.uk ,_)kardon http://www.argonet.co.uk/users/sskardon/stewart/ * * * NEW - Stewart's SAM Information Pages. * * * http://www.argonet.co.uk/users/sskardon/sampages/ Crashed Magazine - The SAM Coupe and ZX Spectrum Magazine. Crashed WWW Site http://www.argonet.co.uk/users/sskardon Crashed Email - crashed@argonet.co.uk From owner-sam-users@nvg.ntnu.no Fri Mar 6 00:04:14 1998 X-Authentication-Warning: holly.csv.warwick.ac.uk: pyumi owned process doing -bs Date: Thu, 5 Mar 1998 23:43:59 +0000 (GMT) From: Mark Sturdy X-Sender: pyumi@holly To: sam-users@nvg.unit.no Subject: Standing at the door of the Pink Flamingo, crying in the rain Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 62 Lines: 9 Testing Take care, Mark "Hello Tony." "Hello, Control." From imc Fri Mar 6 00:36:12 1998 Subject: Re: Floppy Disks To: sam-users@nvg.unit.no Date: Fri, 6 Mar 1998 00:36:12 +0000 (GMT) In-Reply-To: <3.0.1.32.19980305115325.006c0e00@nessie.mcc.ac.uk> from "Simon Cooke" at Mar 5, 98 11:53:25 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 562 Lines: 14 On Thu, 05 Mar 1998 11:53:25 -0500, Simon Cooke said: > But auto-detection is easy enough; and should be used to get disk-ID info > for MasterDOS disks to enable disk cacheing. Incidentally, it would be good if the disk drive could detect when the disk has been changed... > Speaking of which... we need a good random number generator for the > purpose; MasterDOS appears to use the refresh register, AFAICR. You could have a random number system variable, and every time a keypress is detected bit 0 of FRAMES is shifted into it. Just a silly idea... imc From imc Fri Mar 6 00:37:51 1998 Subject: Re: Mostly 'ARMless To: sam-users@nvg.unit.no Date: Fri, 6 Mar 1998 00:37:51 +0000 (GMT) In-Reply-To: from "Allan Skillman" at Mar 5, 98 04:44:54 pm X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 297 Lines: 8 On Thu, 5 Mar 1998 16:44:54 +0000 (GMT), Allan Skillman said: > Its a VGA (standard VGA that is) trick pointed out to me by Aley (he or > the SAA TSR). You can halve the number of displayed lines in any VGAlike > mode ie 640x240 is 640x480 halved. How? Fiddling with one of the registers? imc From imc Fri Mar 6 00:44:23 1998 Subject: Re: Floppy Disks To: sam-users@nvg.unit.no Date: Fri, 6 Mar 1998 00:44:23 +0000 (GMT) In-Reply-To: from "Andrew Collier" at Mar 5, 98 01:40:12 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1428 Lines: 38 On Thu, 5 Mar 1998 01:40:12 +0000, Andrew Collier said: > At 1:13 am +0000 5/3/98, Simon Cooke wrote: > >>> The only problem then is the file attributes. > >>What problem? > >Well... program type, snapshot registers, etc. Oh. The file type (registers are no problem - use a different snapshot format that has the registers built in). > >Though... *thinks*... a file which contained those attributes... hmmm... > Would each individual disk file have a corresponding attributes file - > probably inefficient - or would you have one file holding information for > all other files on the disk An attribute file would presumably be one file for all the information. Like "EA DATA.SF" for the OS/2 extended attributes. On the other hand, a better idea might be just to give each file a short header as on PLUS3DOS. Even on Sam all files start with a 9-byte header, although that isn't used. > What exactly will happen when you save a file onto this disk in your PC > which takes no notice of your attributes file? You will get a raw CODE file. So you'll need a program to fix it up. > On similar lines, it would probably be possible to allow the use of 8.3 > filenames and Sam's 10-character filenames on such a disk without too much > hassle.... Why bother? Just use whatever filenames the medium allows. If you implement the VFAT filing system you can have long filenames and still retain MSDOS compatibility. imc From owner-sam-users@nvg.ntnu.no Fri Mar 6 01:16:43 1998 X-Sender: asc25@pop.hermes.cam.ac.uk Message-Id: In-Reply-To: <199803060044.AAA04076@chalca.comlab.ox.ac.uk> References: from "Andrew Collier" at Mar 5, 98 01:40:12 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Mar 1998 01:12:59 +0000 To: sam-users@nvg.unit.no From: Andrew Collier Subject: Re: Floppy Disks X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 888 Lines: 22 At 12:44 am +0000 6/3/98, Ian Collier wrote: >On the other hand, a better idea might be just to give each file a >short header as on PLUS3DOS. Even on Sam all files start with a >9-byte header, although that isn't used. That would break when you load or save a file with your PC... and would be more difficult to work around than replacing a missing entry in the attributes file. Andrew --- +-----------------+----------------------------+--------------------+ | Andrew Collier | email asc25@cam.ac.uk | " | | 1B NatSci | http://carou.sel.cam.ac.uk | Get your kicks | +-----------------+----------------------------+ on 8.124038405 | | Selwyn College Student Computer Support Team | " | | email support@sel.cam.ac.uk | anon | +----------------------------------------------+--------------------+ From owner-sam-users@nvg.ntnu.no Fri Mar 6 10:20:20 1998 From: BrenchleyR Message-ID: Date: Fri, 6 Mar 1998 05:07:49 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM (is a reply to: SamSon - The aim???) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2512 Lines: 72 In a message dated 05/03/98 15:43:35, you write: > >Hi Gang, Hi. > >Just a small question: What on earth is the aim of the SamSon project, >anyway? To enhance SAM, and then (possibly) build a new machine. > >The impression I get is that it is to end up creating a computer that we >can be proud of as computer enthusiasts that is easy to use/play-about- >with without all the higglety-pigglety crap that the PC gives us. True. > >Chatting to a work-mate of mine yesterday (as he was overlooking my >email writing as I wrote the word SamSon) he thought the idea of a >Z380 based new computer was rather pointless. He suggested that >as long as it has a decent operating system, that you can directly >play with the registers (both software and hardware) and some-such, >and that it had a decent processor to play with (ie, not Z80 based but >ARM or something). I must admit to not knowing a great deal about the ARM. But what I do know is that there are thousands of people with Z80 knowledge and those are the people that we should be aiming at. > >Do we really need something that's SAM compatible? When we already >have a SAM? (If we really want, we could compile SimCoupe for it!) Well, not 100% SAM compatible, just more the /feel/ of SAM, its user-friendly approachableness . > >There are plenty of 8bit computers in the world. But a MIPS R3000 (like >as used in the PlayStation) will attract some attention in the computer >enthusiats world. Would it? Yes, I suppose it would, but you could not turn SAM into such a machine in easy add-on stages. > >As long as we include the SAMs character (which, speaking to my >work-mate, is basically the same as the Amiga's), we should be >able to get not only us lot, but maybe a vast majority of other >ex-decent computer users (That's users of old decent computers, >not old decent users of computers) . Don't know about that, the Amiga may have been a big seller but it was always the ST that my programming friends liked. > >If something like that came on the market, he'd certainly buy one. >In fact, so would I! But the nice thing about the SAMSon project is that we are not setting out to build a new computer - we are setting out to use SAM to 'solve the problems/design the solutions' for a new machine, but in so doing we expand SAM. > >The only reason why I kept my SAM (and why my work-mate kept >his Amiga) was because we can "play" with them! > An I want you to play even more.... > >Take care, >Justin > > -- Bob. From owner-sam-users@nvg.ntnu.no Fri Mar 6 14:57:45 1998 From: Paul Walker Message-Id: <199803061340.NAA23400@crocus.csv.warwick.ac.uk> Subject: Re: Mostly 'ARMless In-Reply-To: <199803051612.QAA03065@chalca.comlab.ox.ac.uk> from Ian Collier at "Mar 5, 98 04:12:43 pm" To: sam-users@nvg.unit.no Date: Fri, 6 Mar 1998 13:40:33 +0000 (GMT) X-Approved: bill@whitehouse.gov X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 113 Lines: 4 > (why does netscape go dead when I accidentally press shift-insert?) It's Netscape, it doesn't need a reason. From owner-sam-users@nvg.ntnu.no Fri Mar 6 15:27:33 1998 From: BrenchleyR Message-ID: <7b72fbe2.350011ea@aol.com> Date: Fri, 6 Mar 1998 10:10:32 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: C Compiler Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 284 Lines: 16 In a message dated 05/03/98 18:58:56, you write: >o > >Talking about C compilers had just reminded me... > >What ever happened to that special offer that FRED and FORMAT were supposed >to >be doing? ;-) > >Stewart In the new issue, which is at the printers at the moment. -- Bob. From owner-sam-users@nvg.ntnu.no Fri Mar 6 15:27:34 1998 From: BrenchleyR Message-ID: <5ea048e2.350011e5@aol.com> Date: Fri, 6 Mar 1998 10:10:26 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1068 Lines: 30 In a message dated 05/03/98 17:11:56, you write: >o > >On Thu, 5 Mar 1998 11:11:20 EST, BrenchleyR said: >> Quite right. I though of using the device letter so D1 is disc drive 1, M1 >> would be MS-DOS disc in drive 1. We have 26 letters to go for.... > >1. There are not 26 spare letters, since t and n are already used. Well yes, of course, Tape and Network would be included in the 26. >2. Drive letters should specify the device, not the filing system. D1 and M1 > is a horrid idea. The D (M,T,N,H,S or that have you) is the device specifier, the 1,2,3,4 etc are the drives (or other) attached to the device. So floppy 1 can be read either as a SAM disc (D1) an MS-DOS disc (M1) or maybe a CP/M disc (C1)??? > >The filing system should be auto-detected, or depend on which module is >loaded, or else be set with a command (DEVICE FORMAT "MSDOS" anyone?). I agree you should be able to do something like "What is in floppy 1" and that you should be able to set things as defaults with a DEVICE command. How we do it??? More ideas please. > >imc -- Bob. From owner-sam-users@nvg.ntnu.no Fri Mar 6 15:27:35 1998 From: BrenchleyR Message-ID: <718736da.350011e9@aol.com> Date: Fri, 6 Mar 1998 10:10:31 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM. Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3723 Lines: 78 In a message dated 05/03/98 17:57:47, you write: >o > >At 2:38 pm +0000 2/3/98, BrenchleyR wrote: >>1. To provide on SAM a stable development platform for software required >both >>for the existing SAM and for anything that is to follow. > >Please confirm what exactly is "unstable" about the current Sam firmware; >the tools used for development - assemblers and compilers - don't rely on >ROM routines. Comet already seems pretty stable to me. We have gone over this time and time again. But for the record. There are problems in the ROM/MasterDOS which make it difficult (Nev reckons almost impossible) to fully implement a proper hard drive operating system. The have been complaints on this list for a long time the SAM C was no good for writing SAM software because it lacks many features the people on this list seem to think C needs. Therefore. Unless all development work is done either /off/ machine (on PC) or we ignore the obvious advantages of having bulk storage on a hard drive, we need to make SAM able to support a good HDOS and a good C and whatever else is needed to develop things. > >... > >>f) As platform becomes more stable develop more extensive form of C with >>possibly both Z80 and Z380 object versions. > >Z80 and Z380 compilers will be almost totally independent, due to the >fundamentally different architecture. The Z80 back-end will (for all but >the smallest and simplest projects) need to know about things like memory >paging which (particularly in terms of splitting your executable into 32K >blocks and switching between them whilst keeping track of the stack, data >structures etc) will be very difficult for a compiler to code automatically. What I meant by (f) was that source code going into the Z80 version should also be compilable (albeit with different object code) on the Z380 version. > >That's not to say I think the C compiler is a bad idea - but IMO the >eventual SamSon goal would be reached more quickly if the extra processor >board is designed first, and the compiler is written to produce Z380 object >code. For the last time. To put this matter to bed before we go any further. The second processor is not required at this early stage of development. It is in the future, how far in the future will depend on all the other things which have to be done before it is even worth looking at the second processor. If someone wants to get stuck into the Z380 processor board hardware, then that is fine by me. As long as we can ensure that no effort is diverted from the more important goals that were listed earlier in the plan. Please rest assured that the plan has been carefully considered and structured to allow for the maximum progress to be made with people actually being able to /see/ things happening fairly early - thus giving encouragement to the longer term project. Please do not miss the point that the project is NOT to build a new SAM, it is to expand the existing one. And the most urgent need is for an improved HDOS so more SAM users can have the benefits of hard drives. > >However I still think core of the operating system would be better written >in assembly. The low-level language is better suited to the task in hand, >and will produce more efficient code. The code may well be more reliable >too, since it will not have to rely on C libraries being bug free. Some things will have to be written in assembler of course. Many more parts will need to be hand optimized to improve them. But the experts tell me that C is the way to go for the bulk of the coding and I can see their point. However, at first, all you Z80 machine code fans can get stuck into improving the ROM/MasterDOS - that should keep you happy. > >Andrew -- Bob. From owner-sam-users@nvg.ntnu.no Fri Mar 6 15:27:35 1998 X-Lotus-FromDomain: CASE TECHNOLOGY From: Justin_Skists@case.co.uk To: sam-users@nvg.unit.no Message-ID: <002565BF.00513851.00@notes_a.case.co.uk> Date: Fri, 6 Mar 1998 15:11:51 +0000 Subject: Re: The Plan for SAM (is a reply to: SamSon - The aim???) Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1372 Lines: 38 > I must admit to not knowing a great deal about the ARM. But what I do know is > that there are thousands of people with Z80 knowledge and those are the people > that we should be aiming at. That's okie. I have no idea about the ARM either. Yes, there are thousands of people who can program the Z80. BUT, they already know how to program the Z80. They want the challenge. They want something new. They want to break new ground. Yes. We can still use the present SAM and have an add-on card for what-ever design issue problems you want sort out before-hand. But does it have to be a Z80 based processor? If the present SAM used the Z380 when it first came out, perhaps it wouldn't have the non-success it did. But is it wise to use it now? It reminds me of when I was deciding what to do for my final year project. I wanted to build something out of hardware. My supervisor asked what I wanted as the main processor. I said I wanted to use the Z80 becuase I knew it pretty well. "Why?" he asked, "It isn't very challenging if you used a Z80." In the end, I chose the processor that I could find to fit the rest of the project that I designed. What I'm trying to say is that if you are intending to spend all that money and time building something, why not do it properly and find something challenging. Now, back to software download onto flash.... *sigh* Justin. From owner-sam-users@nvg.ntnu.no Fri Mar 6 16:30:15 1998 Message-Id: <3.0.1.32.19980306111923.006ca0f0@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 06 Mar 1998 11:19:23 -0500 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: The Plan for SAM. In-Reply-To: <718736da.350011e9@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3587 Lines: 80 At 10:10 AM 3/6/98 EST, you wrote: >There are problems in the ROM/MasterDOS which make it difficult (Nev reckons >almost impossible) to fully implement a proper hard drive operating system. Perhaps it's more because he's writing most of it in C? It's a pity Nev's not on the list any more. Can you ask him to post up his reasons? (I've lost his email address). >The have been complaints on this list for a long time the SAM C was no good >for writing SAM software because it lacks many features the people on this >list seem to think C needs. What? You mean, things like all the stuff that's in the ratified C standard? Things like floating point numbers, long integers... File access... SAM C is not and should never have been marketed as a full C compiler, 'cos it's just a bodged version of the old Small C compiler for the CPM system, with a slow, kludgy IDE wrapped round it. >Therefore. Unless all development work is done either /off/ machine (on PC) or >we ignore the obvious advantages of having bulk storage on a hard drive, we >need to make SAM able to support a good HDOS and a good C and whatever else is >needed to develop things. At this stage, I'm plumping for off-machine development for those who have other machines. I mean, seriously, who here honestly programs their SAM any more for anything other than the hell of it? This late in the game, it's only the hard core users who are ever going to be SAM users, other than those who see SIM Coupe, get interested, and buy a SAM for kink value. The thing everyone has to remember at this stage is: 1. All the people who were promising coders around the start of the SAM now have real jobs. Their spare time is precious. 2. All the people who were brilliant coders producing products around the start of the SAM have moved onto more lucrative markets. 3. No-one is going to make any money working on the SAM.* *I'm talking serious money here. You know, the kind that you'd get by working the same hours in McDonalds that you do behind the SAM keyboard. The fiscal return from SAM programming unless you're Chris White is miniscule, and even then I suspect it wasn't all that much. At this point it's a labour of love, folks. >>However I still think core of the operating system would be better written >>in assembly. The low-level language is better suited to the task in hand, >>and will produce more efficient code. The code may well be more reliable >>too, since it will not have to rely on C libraries being bug free. > >Some things will have to be written in assembler of course. Many more parts >will need to be hand optimized to improve them. But the experts tell me that C >is the way to go for the bulk of the coding and I can see their point. >However, at first, all you Z80 machine code fans can get stuck into improving >the ROM/MasterDOS - that should keep you happy. Which experts? On a system the size of the SAM, assembly language is the way to go. O/S's need to be fast. C introduces many overheads that are hard to overcome. Not only that, but you need some damn clever workarounds in the back-end to overcome the SAM's paging architecture if you're going to write any routines that are larger than 32k. BTW: given that the base libraries will need to be mostly coded in assembler, and that's basically what the OS is, what's the point? Simon *********************************************************** *Product Development Specialist/WebMaster/Graphic Designer* *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* *********************************************************** From owner-sam-users@nvg.ntnu.no Fri Mar 6 17:43:40 1998 Message-Id: <199803061735.RAA19204@renko.ucs.ed.ac.uk> From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: stripwax paranoia consultants To: sam-users@nvg.unit.no Date: Fri, 6 Mar 1998 17:34:54 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Floppy Disks In-reply-to: <5ea048e2.350011e5@aol.com> X-mailer: Pegasus Mail for Win32 (v2.53/R1) X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2686 Lines: 58 > >2. Drive letters should specify the device, not the filing system. D1 and M1 > > is a horrid idea. > > The D (M,T,N,H,S or that have you) is the device specifier, the 1,2,3,4 etc > are the drives (or other) attached to the device. So floppy 1 can be read > either as a SAM disc (D1) an MS-DOS disc (M1) or maybe a CP/M disc (C1)??? donkey? the first sentence made sense, and then your second sentence totally contradicted it. the D,N,T etc is the device (that's DEVICE) specifier - and D means disk (Specifically of the floppy variety). So floppy 1 can be accessed using D1 now, bob, suppose you put in a sam disc but try and do a "DIR M1" or something... what do YOU think would happen? the ONLY way is to have the file system of the disc in drive D1 SPECIFIED in some way (ie, auto detected or set using DEVICE FORMAT "D1:Msdos") > I agree you should be able to do something like "What is in floppy 1" and that > you should be able to set things as defaults with a DEVICE command. How we do > it??? More ideas please. the whole DEVICE FORMAT "D1:msdos" thing is mucky and would probably lead to weird inconsistencies if / when the floppy disc in D1 is swapped for a non-msdos disk, without the system noticing the disk change. Also: what if you tell the system that the disc in D1 is an MS-DOS disk, when it quite blatantly is not? Either, the system will try and read the disc as if it were an MS-DOS disc (not entirely a useful thing if the disc is a Sam-format disc), or else it will give you an error, saying 'no it's not' - and if the system can do this last one, then it can autodetect. if the drive hardware cannot detect disc changes (and obviously notify the operating system accordingly) then you really need to check the disc format between successive writes and reads - and this might mean checking the format before every readsector or writesector command (and what use is that?) if you consider an application that uses readsector and writesector commands directly but which leaves a considerable pause between commands... so: get a drive that can tell the os that the disc has changed, and also build in some sort of autodetection for the disc format into the os. however, here's where extensibility comes into play: how can we deal with the potential situation of having a new floppy disc format coming into existence? one obvious way is to say 'Sam, Cpm and Msdos only' now. But, apart from autodetecting floppy disk format-types, are we also trying to autodetect the format type of other media? (hard drives, for instance) thought provoking? let's get this cleared up quick so we can all do something more useful dave From owner-sam-users@nvg.ntnu.no Fri Mar 6 17:43:41 1998 X-Sender: asc25@pop.hermes.cam.ac.uk Message-Id: In-Reply-To: <718736da.350011e9@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Mar 1998 17:37:59 +0000 To: sam-users@nvg.unit.no From: Andrew Collier Subject: Re: The Plan for SAM. X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2306 Lines: 52 At 3:10 pm +0000 6/3/98, BrenchleyR wrote: >In a message dated 05/03/98 17:57:47, you write: > >>o >> >>At 2:38 pm +0000 2/3/98, BrenchleyR wrote: >>>1. To provide on SAM a stable development platform for software required >>both >>>for the existing SAM and for anything that is to follow. >> >>Please confirm what exactly is "unstable" about the current Sam firmware; >>the tools used for development - assemblers and compilers - don't rely on >>ROM routines. Comet already seems pretty stable to me. > >We have gone over this time and time again. But for the record. The main reason we seem to go over the same questions over and over again, is that the questions aren't answered properly first time round. Basically. >There are problems in the ROM/MasterDOS which make it difficult (Nev reckons >almost impossible) to fully implement a proper hard drive operating system. > >The have been complaints on this list for a long time the SAM C was no good >for writing SAM software because it lacks many features the people on this >list seem to think C needs. Please read my question and read your reply. Then note firstly that MasterDos copes well enough with the Rom's so-called inconsistencies. Perhaps if the hard drive OS was written from the ground up as an integrated replacement for MasterDos - rather than a lump tacked on the side - it would stand more of a chance of working properly. This sounds like the approach you're eventually heading for, and indeed was the route chosen by Edwin Blink for BDOS although I don't have tehnical specs for that system. Secondly, note that the tools used for development - assemblers and compilers - don't rely on ROM routines. Please explain exactly why you say that it is the current ROM which is inhibiting the development of a decent C compiler. Andrew --- +-----------------+----------------------------+--------------------+ | Andrew Collier | email asc25@cam.ac.uk | " | | 1B NatSci | http://carou.sel.cam.ac.uk | Get your kicks | +-----------------+----------------------------+ on 8.124038405 | | Selwyn College Student Computer Support Team | " | | email support@sel.cam.ac.uk | anon | +----------------------------------------------+--------------------+ From owner-sam-users@nvg.ntnu.no Fri Mar 6 18:06:01 1998 X-Sender: asc25@pop.hermes.cam.ac.uk Message-Id: In-Reply-To: <3.0.1.32.19980306111923.006ca0f0@nessie.mcc.ac.uk> References: <718736da.350011e9@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 6 Mar 1998 17:49:28 +0000 To: sam-users@nvg.unit.no From: Andrew Collier Subject: Re: The Plan for SAM. X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1692 Lines: 43 At 4:19 pm +0000 6/3/98, Simon Cooke wrote: >>Some things will have to be written in assembler of course. Many more parts >>will need to be hand optimized to improve them. But the experts tell me >that C >>is the way to go for the bulk of the coding and I can see their point. >>However, at first, all you Z80 machine code fans can get stuck into improving >>the ROM/MasterDOS - that should keep you happy. FSVO happy. I'd rather be engaged in writing new stuff than trawling through undocumented code looking for the occasional obscure bug. >Which experts? None of the ones abundant on this list, obviously. >On a system the size of the SAM, assembly language is the way to go. O/S's >need to be fast. C introduces many overheads that are hard to overcome. Not >only that, but you need some damn clever workarounds in the back-end to >overcome the SAM's paging architecture if you're going to write any >routines that are larger than 32k. Exactly. It is Sam's awkward paging structure which puts the final nail in the coffin for a decent Sam C compiler. It is for this sort of reason that I still think an improved processor is of higher priority than bug fixes in the Sam Rom. Andrew --- +-----------------+----------------------------+--------------------+ | Andrew Collier | email asc25@cam.ac.uk | " | | 1B NatSci | http://carou.sel.cam.ac.uk | Get your kicks | +-----------------+----------------------------+ on 8.124038405 | | Selwyn College Student Computer Support Team | " | | email support@sel.cam.ac.uk | anon | +----------------------------------------------+--------------------+ From owner-sam-users@nvg.ntnu.no Fri Mar 6 18:06:02 1998 Message-Id: <199803061744.RAA20377@renko.ucs.ed.ac.uk> From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: stripwax paranoia consultants To: sam-users@nvg.unit.no Date: Fri, 6 Mar 1998 17:44:43 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Mostly 'ARMless In-reply-to: X-mailer: Pegasus Mail for Win32 (v2.53/R1) X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1684 Lines: 40 > I now have my new PC set up with Linux and Windows (spit) 95, and > yesterday I downloaded and installed DJGPP, and my SimCoupe sources > from my old notebook. The code built clean and runs great (100% speed > on this Pentium 166). i can't get my source to build... could be i'm using the wrong (different) version of make or something, but it gets stuck on one of the two libraries that you build... also gives some warnings about 'passing argument 1 of something-or-other means it will lose its 'volatile' type' with regard to something about a timer (related to the quit function, i think... just an impression... i didn't follow it through the source so i don't really know what's caused that warning) > o SAM speaker emulation using the PC speaker yay > To answer a question from Bob regarding SimCoupe and single stepping; > there is a simple debugger in the code, but it is turned off in > the DOS version, as the program runs in a graphics mode, and so has no > console to use for the debugger. On the UNIX version the program uses X11 > and so there is usually an xterm window to use as the console. could you not use your own gui in some way to implement the debugger in dos? also: when can we get sam snapshots? or a saa-1099 emulator that doesn't leave the sound 'on' when it should be 'off' (try playing hexagonia, then get up the help screen thing for the first level, then get rid of it again... agggh! .. bad sound ! ...) (need to get Aley or anyone else to implement the reset-soundchip control - or else get someone to write a set of non-tsr-and-windows95-friendly saa emulation routines for direct inclusion within the simcoupe source) dave From owner-sam-users@nvg.ntnu.no Fri Mar 6 18:14:54 1998 Message-Id: <3.0.1.32.19980306130349.006cb78c@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Fri, 06 Mar 1998 13:03:49 -0500 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Coming Home In-Reply-To: <01bd437d$5842fcc0$LocalHost@SPARKY> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1219 Lines: 27 At 12:43 PM 2/27/98 -0000, you wrote: >I had a dream about you last night Mr Cooke ;) ;) No, don't worry, it wasn't >that kind of dream (that was another night). I dreamt about the show on >Saturday and you were there giving a lecture to about 1000 SAM people. For >some reason everyone was bored and were playing hangman with each other. >(There was a big blue SAM logo on the wall, which was cool). After a few >hours of Cookie talking, a plane crashed into the hall, but we all escaped. >Just thought I would let you know. (I've just woken up, and yes I know what >time it is, but I'm a student). Next Time on SAM Users' Visions of Hell: David Zambonini on the time he was stuck in a room with the world's biggest electromagnet. And then they switched it on. :) Simon ps. Had a rather annoying night last night. Finally got off to sleep. Spent the entire night writing C and Visual Basic code in my dreams. Just when you think it's safe to turn off the outside world... *********************************************************** *Product Development Specialist/WebMaster/Graphic Designer* *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* *********************************************************** From owner-sam-users@nvg.ntnu.no Fri Mar 6 20:33:48 1998 From: BillRitman Message-ID: <2ab015c0.35005cb1@aol.com> Date: Fri, 6 Mar 1998 15:29:35 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM. Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0.i for Windows sub 178 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 176 Lines: 6 I do have a small point which I would like clarification on. How is it intended to pay for part or all of this project? Is it going to be funded by West Coast or what? Bill. From owner-sam-users@nvg.ntnu.no Fri Mar 6 23:06:37 1998 From: chris To: sam-users Subject: Re: Gloucester!!! Date: Fri, 6 Mar 1998 22:58:53 -0800 Message-ID: <01bd4996$7d6476e0$LocalHost@default> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 219 Lines: 13 >Oh yes, Gloucester has nightlife - you should see the state of Colin the >following day.... (on second thoughts, no, you shouldn't see the state of >him). > >-- >Bob. I Fully agree with you on that one Bob Chris From owner-sam-users@nvg.ntnu.no Fri Mar 6 23:17:45 1998 From: chris To: sam-users Subject: Re: The Plan for SAM. Date: Fri, 6 Mar 1998 23:09:55 -0800 Message-ID: <01bd4998$07d1f9a0$LocalHost@default> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 663 Lines: 25 Okay after reading one weeks worth of info on the NEW SAM, here's my input concerning the processor. 1) Do not use the Z380 2) Do not use the ARM family 3) Do Use the Mips but a) Not the R3000 b) Not the R3000a (PSX ONE) c) But the R4000 (N64 ONE) 'cause a) I can code MIPS b) Its really easy c) Further rendisions of Mips CPU's will work inplace of old CPU's d) The R4000 has built in 64bit FPU and if you do use Mips please do not hard wire COP2 (2nd FPU) to zero, this as given me some pain in the ?????? just latley Chris From owner-sam-users@nvg.ntnu.no Fri Mar 6 23:20:44 1998 From: chris To: sam-users Subject: Re: Coming Home Date: Fri, 6 Mar 1998 23:12:28 -0800 Message-ID: <01bd4998$637c7780$LocalHost@default> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 278 Lines: 10 > >Simon > >ps. Had a rather annoying night last night. Finally got off to sleep. Spent >the entire night writing C and Visual Basic code in my dreams. Just when >you think it's safe to turn off the outside world... > Don't tell me this has only just started happening to you From imc Fri Mar 6 23:57:15 1998 Subject: Re: Floppy Disks To: sam-users@nvg.unit.no Date: Fri, 6 Mar 1998 23:57:15 +0000 (GMT) In-Reply-To: from "Andrew Collier" at Mar 6, 98 01:12:59 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 907 Lines: 22 On Fri, 6 Mar 1998 01:12:59 +0000, Andrew Collier said: > At 12:44 am +0000 6/3/98, Ian Collier wrote: > >On the other hand, a better idea might be just to give each file a > >short header as on PLUS3DOS. Even on Sam all files start with a > >9-byte header, although that isn't used. > That would break when you load or save a file with your PC... As would any system. Except, why are you loading and saving files with your PC? There would be no problem with CODE files (just assume that any file without a header is CODE) and you wouldn't really be dealing with any other kind of file unless you had got it from another Sam, in which case having the header is good because all the relevant information is in the one file. > and would be > more difficult to work around than replacing a missing entry in the > attributes file. Why? imc From owner-sam-users@nvg.ntnu.no Sat Mar 7 00:18:48 1998 X-Sender: asc25@pop.hermes.cam.ac.uk Message-Id: In-Reply-To: <199803062357.XAA06424@chalca.comlab.ox.ac.uk> References: from "Andrew Collier" at Mar 6, 98 01:12:59 am Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 7 Mar 1998 00:15:03 +0000 To: sam-users@nvg.unit.no From: Andrew Collier Subject: Re: Floppy Disks X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1892 Lines: 44 At 11:57 pm +0000 6/3/98, Ian Collier wrote: >> That would break when you load or save a file with your PC... > >As would any system. Except, why are you loading and saving files with >your PC? There would be no problem with CODE files (just assume that any >file without a header is CODE) and you wouldn't really be dealing with any >other kind of file unless you had got it from another Sam, in which case >having the header is good because all the relevant information is in the >one file. I must admit there's a logic in that - I'm trying hard to think of a counter-example... it just sounds a bit dangerous. >> and would be >> more difficult to work around than replacing a missing entry in the >> attributes file. > >Why? Basic problem: How can you tell whether the file has got a header or not? If your header has a standard format, then you can probably recognise if a file _doesn't_ fit it. Though maybe not %100 reliably. But if you save j-random-code-file from your PC and the first few bytes happen to look like a genuine header, then you're stuffed. Wheras you can notice a missing attributes file entry, and create an entry saying "generic code file". Of couse, you have the problem of what happens when you (using your PC) save a file, overwriting another file with the same name but a different type. Andrew --- +-----------------+----------------------------+--------------------+ | Andrew Collier | email asc25@cam.ac.uk | " | | 1B NatSci | http://carou.sel.cam.ac.uk | Get your kicks | +-----------------+----------------------------+ on 8.124038405 | | Selwyn College Student Computer Support Team | " | | email support@sel.cam.ac.uk | anon | +----------------------------------------------+--------------------+ From imc Sat Mar 7 00:44:40 1998 Subject: Re: Floppy Disks To: sam-users@nvg.unit.no Date: Sat, 7 Mar 1998 00:44:40 +0000 (GMT) In-Reply-To: from "Andrew Collier" at Mar 7, 98 00:15:03 am X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1108 Lines: 27 On Sat, 7 Mar 1998 00:15:03 +0000, Andrew Collier said: > Basic problem: How can you tell whether the file has got a header or not? I know because I'm the one who saved it. :-) If I ask the computer to load a headerless file then it detects the lack of a header because the header will have a signature and a checksum. > But if you save j-random-code-file from your PC and the first few bytes > happen to look like a genuine header, then you're stuffed. True. But unlikely. > Of couse, you have the problem of what happens > when you (using your PC) save a file, overwriting another file with the > same name but a different type. Also true. And even if it has the same type but a different length, in some circumstances. Much more likely to happen than accidentally making a file which looks like a header. One disadvantage is that it makes the DIR command harder (see the *CAT command in 48KDB on the +3 - same problem). Easiest solution is to use DIR! unless you really want to know the types, in which case you can wait a few seconds for it to work them out. imc From owner-sam-users@nvg.ntnu.no Sat Mar 7 03:59:15 1998 Date: Fri, 6 Mar 1998 22:55:46 -0500 (EST) Message-Id: <199803070355.WAA25515@smtp3.erols.com> X-Mailer: HandStamp Pro 1.0 Subject: Assembler Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Mime-Version: 1.0 From: Simon Cooke To: sam-users@nvg.ntnu.no X-Orcpt: rfc822;sam-users@nvg.ntnu.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3079 Lines: 66 Been speccing out my Z80 assembler for PC based SAM development again... Here's the state of play on additional keywords. I'm particularly interested in what Edwin thinks, though all helpful criticism is welcomed. Macros: Start with: label: MACRO ... ENDMACRO Label references: As well as standard usage (eg LD (store),A), 2 new forms: label:a - refers to the data part of the instruction at that address - eg mycode: LD A,0 LD (mycode:a),E label:i - refers to the index offset part of an IX/IY instruction eg: mycode: LD A,(IX+0) LD (mycode:i),E *possibly* also have label:d:label2 - which would give the JR / DJNZ offset of label from label 2 (where label 2 refers to a JR or DJNZ instruction) Demo coders will probably appreciate how these could make writing fast code more readable and less error prone. Other tokens: ALIGN x where x is a power of 2, less than or equal to 16384. Aligns data or code that follows to the next boundary of that size. Eg. Current address = 16918. ALIGN 128 moves the output address to 17046. (I'm also hoping to add some computer-aided intelligence to make fitting things efficiently into memory possible) BOUND start,end warns you if the address your code is being created for exceeds its limits (handy for making sure you don't exceed a page limit) START "FILENAME" END Defines which bits of the file actually include important data. Eg: START "outfile.dta" DI LD A,23 LD (stash),A EI RET END stash: DB 0 the output file would end at the RET, but as stash in a place holder for data, it can still be referenced - it doesn't need to be included with the output. Note: if stash had held pre-initialised data that was needed elsewhere, it would need to be in the start-end block. Files can INCLUDE other files. Files can also be declared RELOCATABLE X on their first line, where X is either blank (relocatable anywhere), HIGH (must fit on a page at an ORG address 32768-65535), LOW (same, 0-32767), A B C or D (obvious, 16k boundary), PAGE (anywhere, as long as it all fits into one page) or within a specified range-( for the upper screen free area in mode 4, page low, it would look like: RELOCATABLE &E000,&FFFF ) Relocatable files can only include compatibly specified relocatable files. I'm working on C object code generation techniques for >32k progs (including use of external memory), but it may take some time. Getting close now tho! (basic schema: "bouncer" routines, runtime lib, interrupt data & stack always in low mem where possible. Data always in high where poss (it's no accident external is high only, it$eems) . Code that doesn't fit low will be called via a routine that pages it high. If that routine has to access data, it will be paged low, and in that page a "linker" routine will handle interrupts, repaging as necessary. More when I have a keyboard to scribble with. But it's not going to be a quick thing to do. We may yet have a proper (if slow) SAM C compiler) Simon --- This message scribbled for you by hand on a Palmpilot. Please excuse brevity and spelling mistakes. From owner-sam-users@nvg.ntnu.no Sat Mar 7 09:23:14 1998 From: BrenchleyR Message-ID: Date: Sat, 7 Mar 1998 04:16:51 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2326 Lines: 62 In a message dated 06/03/98 15:31:05, you write: >o > >> I must admit to not knowing a great deal about the ARM. But what I do >know is >> that there are thousands of people with Z80 knowledge and those are the >people >> that we should be aiming at. > >That's okie. I have no idea about the ARM either. Yes, there are thousands >of >people who can program the Z80. BUT, they already know how to program the >Z80. They want the challenge. They want something new. They want to break >new ground. That is the idea, just as SAM was new ground to Spectrum programmers and just as the Spectrum was new to ZX81 programmers. > >Yes. We can still use the present SAM and have an add-on card for what-ever >design issue problems you want sort out before-hand. But does it have to be >a Z80 based processor? If the present SAM used the Z380 when it first came >out, perhaps it wouldn't have the non-success it did. But is it wise to use >it now? I think you will find that the Z380 was not around then. There was the Z80G (which I think was 8MHz) but that was _far_ to expensive to use. And no, I can't say it is wise to use the Z380. I think, at the moment, it looks the most logical, but the question is how long will Zilog keep it going and is there going to be a Z480. Still, while the rest of the project moves forward we can continue to look at what other processor can be used, and indeed why should we limit ourselves to just one second processor. > >It reminds me of when I was deciding what to do for my final year project. >I >wanted to build something out of hardware. My supervisor asked what I >wanted >as the main processor. I said I wanted to use the Z80 becuase I knew it >pretty >well. "Why?" he asked, "It isn't very challenging if you used a Z80." In >the end, Yes, I can see his point. There is just too much info on the Z80 that you could have pinched for the project. But that is not life in the real world. >I chose the processor that I could find to fit the rest of the project that >I designed. > >What I'm trying to say is that if you are intending to spend all that money >and >time building something, why not do it properly and find something >challenging. Challenging to who? The designers of the machine or the users? > >Now, back to software download onto flash.... *sigh* > >Justin. -- Bob. From owner-sam-users@nvg.ntnu.no Sat Mar 7 09:23:31 1998 From: BrenchleyR Message-ID: <40340e05.3501107f@aol.com> Date: Sat, 7 Mar 1998 04:16:45 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Mostly 'ARMless Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 227 Lines: 13 In a message dated 06/03/98 14:58:51, you write: > >> (why does netscape go dead when I accidentally press shift-insert?) > >It's Netscape, it doesn't need a reason. > > Well at least its not a Microsloth product. -- Bob. From owner-sam-users@nvg.ntnu.no Sat Mar 7 09:23:32 1998 From: BrenchleyR Message-ID: <517ed17.35011089@aol.com> Date: Sat, 7 Mar 1998 04:16:54 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM. Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 4329 Lines: 114 In a message dated 06/03/98 16:24:01, you write: >o > >At 10:10 AM 3/6/98 EST, you wrote: >>There are problems in the ROM/MasterDOS which make it difficult (Nev reckons >>almost impossible) to fully implement a proper hard drive operating system. > >Perhaps it's more because he's writing most of it in C? No, you can't even get round them in machine code. > >It's a pity Nev's not on the list any more. Can you ask him to post up his >reasons? (I've lost his email address). Nevilley@ndirect.co.uk > >>The have been complaints on this list for a long time the SAM C was no good >>for writing SAM software because it lacks many features the people on this >>list seem to think C needs. > >What? You mean, things like all the stuff that's in the ratified C standard? Well some of the stuff that is in ANSI C, yes. > >Things like floating point numbers, long integers... Yes. > >File access... No. > >SAM C is not and should never have been marketed as a full C compiler, 'cos >it's just a bodged version of the old Small C compiler for the CPM system, >with a slow, kludgy IDE wrapped round it. Now slow down. C is a language, which like many other languages exists in several forms. Yes SAM C is a Small C, but that does not mean it is not a C compiler. > >>Therefore. Unless all development work is done either /off/ machine (on >PC) or >>we ignore the obvious advantages of having bulk storage on a hard drive, we >>need to make SAM able to support a good HDOS and a good C and whatever >else is >>needed to develop things. > >At this stage, I'm plumping for off-machine development for those who have >other machines. I mean, seriously, who here honestly programs their SAM any >more for anything other than the hell of it? This late in the game, it's >only the hard core users who are ever going to be SAM users, other than >those who see SIM Coupe, get interested, and buy a SAM for kink value. I disagree. I think that there will still be many people without day-to-day access to a powerful enough PC to run SIM Coupe. If we work on it being and 'on-machine' project then we can't go wrong. > >The thing everyone has to remember at this stage is: > >1. All the people who were promising coders around the start of the SAM now >have real jobs. Their spare time is precious. >2. All the people who were brilliant coders producing products around the >start of the SAM have moved onto more lucrative markets. >3. No-one is going to make any money working on the SAM.* > >*I'm talking serious money here. You know, the kind that you'd get by >working the same hours in McDonalds that you do behind the SAM keyboard. >The fiscal return from SAM programming unless you're Chris White is >miniscule, and even then I suspect it wasn't all that much. > >At this point it's a labour of love, folks. A valid point. > >>>However I still think core of the operating system would be better written >>>in assembly. The low-level language is better suited to the task in hand, >>>and will produce more efficient code. The code may well be more reliable >>>too, since it will not have to rely on C libraries being bug free. >> >>Some things will have to be written in assembler of course. Many more parts >>will need to be hand optimized to improve them. But the experts tell me >that C >>is the way to go for the bulk of the coding and I can see their point. >>However, at first, all you Z80 machine code fans can get stuck into >improving >>the ROM/MasterDOS - that should keep you happy. > >Which experts? Nev for a start, another good friend of my Jon Nixon, both of whom I consider to be very knowledgable on the subject. Then I would cite a large part of the world's programming team who have been using C to write operating systems ever since Windows 2.0 > >On a system the size of the SAM, assembly language is the way to go. O/S's >need to be fast. C introduces many overheads that are hard to overcome. Not >only that, but you need some damn clever workarounds in the back-end to >overcome the SAM's paging architecture if you're going to write any >routines that are larger than 32k. Some good points, some of which will have to be taken into account. > >BTW: given that the base libraries will need to be mostly coded in >assembler, and that's basically what the OS is, what's the point? Time. > >Simon -- Bob. From owner-sam-users@nvg.ntnu.no Sat Mar 7 09:23:33 1998 From: BrenchleyR Message-ID: Date: Sat, 7 Mar 1998 04:16:57 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3416 Lines: 87 In a message dated 06/03/98 17:46:00, you write: >o > >> >2. Drive letters should specify the device, not the filing system. D1 and >M1 >> > is a horrid idea. >> >> The D (M,T,N,H,S or that have you) is the device specifier, the 1,2,3,4 etc >> are the drives (or other) attached to the device. So floppy 1 can be read >> either as a SAM disc (D1) an MS-DOS disc (M1) or maybe a CP/M disc (C1)??? > >donkey? the first sentence made sense, and then your second sentence >totally contradicted it. Well I may be hung like one...... Ok, rephrase time. Logical device specifier. Try that in the paragraph. > >the D,N,T etc is the device (that's DEVICE) specifier - and D means >disk (Specifically of the floppy variety). So floppy 1 can be >accessed using D1 > >now, bob, suppose you put in a sam disc but try and do a "DIR M1" or >something... what do YOU think would happen? You would get an error message from the MS-DOS disc reading routine saying that it was not an MS-DOS formatted disc. > >the ONLY way is to have the file system of the disc in drive D1 >SPECIFIED in some way (ie, auto detected or set using DEVICE FORMAT >"D1:Msdos") I don't like auto-detect, it gives the computer control over something that I think should be under program/user control. > >> I agree you should be able to do something like "What is in floppy 1" and >that >> you should be able to set things as defaults with a DEVICE command. How we >do >> it??? More ideas please. > >the whole DEVICE FORMAT "D1:msdos" thing is mucky and would probably >lead to weird inconsistencies if / when the floppy disc in D1 is >swapped for a non-msdos disk, without the system noticing the disk >change. Also: what if you tell the system that the disc in D1 is an >MS-DOS disk, when it quite blatantly is not? Either, the system will >try and read the disc as if it were an MS-DOS disc (not entirely a >useful thing if the disc is a Sam-format disc), or else it will give >you an error, saying 'no it's not' - and if the system can do this >last one, then it can autodetect. I refer you to my earlier answer. > >if the drive hardware cannot detect disc changes (and obviously >notify the operating system accordingly) then you really need to >check the disc format between successive writes and reads - and this >might mean checking the format before every readsector or writesector >command (and what use is that?) if you consider an application that >uses readsector and writesector commands directly but which leaves a >considerable pause between commands... I think there was a reason Bruce ignored the disc-changed line but I can't remember what it was. > > >so: get a drive that can tell the os that the disc has changed, and >also build in some sort of autodetection for the disc format into the >os. however, here's where extensibility comes into play: how can we >deal with the potential situation of having a new floppy disc format >coming into existence? one obvious way is to say 'Sam, Cpm and Msdos >only' now. But, apart from autodetecting floppy disk format-types, >are we also trying to autodetect the format type of other media? >(hard drives, for instance) I think the routine for a particular type of disc only needs to detect its own discs, anything else would be an error. > > >thought provoking? let's get this cleared up quick so we can all do >something more useful > > dave -- Bob. From owner-sam-users@nvg.ntnu.no Sat Mar 7 09:23:34 1998 From: BrenchleyR Message-ID: <85a5ba96.3501108f@aol.com> Date: Sat, 7 Mar 1998 04:17:01 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM. Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3040 Lines: 76 In a message dated 06/03/98 17:46:02, you write: >o > >At 3:10 pm +0000 6/3/98, BrenchleyR wrote: >>In a message dated 05/03/98 17:57:47, you write: >> >>>o >>> >>>At 2:38 pm +0000 2/3/98, BrenchleyR wrote: >>>>1. To provide on SAM a stable development platform for software required >>>both >>>>for the existing SAM and for anything that is to follow. >>> >>>Please confirm what exactly is "unstable" about the current Sam firmware; >>>the tools used for development - assemblers and compilers - don't rely on >>>ROM routines. Comet already seems pretty stable to me. >> >>We have gone over this time and time again. But for the record. > >The main reason we seem to go over the same questions over and over again, >is that the questions aren't answered properly first time round. Basically. I answer the question in the only way it was worth answering - that is saying WHY the ROM/MasterDOS need to be worked on. > >>There are problems in the ROM/MasterDOS which make it difficult (Nev reckons >>almost impossible) to fully implement a proper hard drive operating system. >> >>The have been complaints on this list for a long time the SAM C was no good >>for writing SAM software because it lacks many features the people on this >>list seem to think C needs. > >Please read my question and read your reply. > >Then note firstly that MasterDos copes well enough with the Rom's so-called >inconsistencies. Only by using a lot of its space to get round them and in some cases even replace them. >Perhaps if the hard drive OS was written from the ground >up as an integrated replacement for MasterDos - rather than a lump tacked >on the side - it would stand more of a chance of working properly. But that is not the way to do things, MasterDOS extended the ROM, MasterBasic extended MasterDOS, HDOS should (if it could) have extended things again. THAT was the whole idea of SAM' Basic. >This >sounds like the approach you're eventually heading for, and indeed was the >route chosen by Edwin Blink for BDOS although I don't have tehnical specs >for that system. Neither do I, but if I understand it right all BDOS does it to patch things so 800K sections of disc appear to MasterDOS as if it was floppy drive 2. This was a way that was looked at by Nev and myself in the first few days of writing HDOS - and rejected because it was too restrictive. > >Secondly, note that the tools used for development - assemblers and >compilers - don't rely on ROM routines. Please explain exactly why you say >that it is the current ROM which is inhibiting the development of a decent >C compiler. But they do rely on ROM routines - unless you are going to do all assembly/compilation in memory. Files have to be loaded, bigger files require bigger disc storage. The hard drive is the answer to that, and THAT is why the ROM and MasterDOS need to be redone BEFORE we can have a stable and usable development system for later parts of the project. We HAVE to lay the foundations because otherwise we cannot build as high. > >Andrew -- Bob. From owner-sam-users@nvg.ntnu.no Sat Mar 7 09:36:20 1998 From: BrenchleyR Message-ID: <803c13d7.3501147d@aol.com> Date: Sat, 7 Mar 1998 04:33:47 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM. Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1153 Lines: 38 In a message dated 06/03/98 23:15:49, you write: >o > >Okay after reading one weeks worth of info on the NEW SAM, here's my input >concerning the processor. > > 1) Do not use the Z380 > 2) Do not use the ARM family > 3) Do Use the Mips but > a) Not the R3000 > b) Not the R3000a (PSX ONE) > c) But the R4000 (N64 ONE) > > > 'cause > a) I can code MIPS > b) Its really easy > c) Further rendisions of Mips CPU's will work inplace of old >CPU's > d) The R4000 has built in 64bit FPU > > and if you do use Mips please do not hard wire COP2 (2nd FPU) to >zero, this as given me some >pain in the ?????? just latley > > >Chris As I see it the choice of 2nd processor for the SAM is very open. When it comes to SAMSON, then whatever is the 2nd processor on SAM becomes the main processor but with a Z80 as second processor - that way there can always be backward compatibity built into SAMSON for exiting SAM code. [I'm thinking along the lines of using the Z80 on SAMSON to handle so I/O except when it is needed for SAM mode. -- Bob. From owner-sam-users@nvg.ntnu.no Sat Mar 7 15:56:02 1998 Date: Fri, 6 Mar 1998 16:53:16 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9803061553.AA19056@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: Floppy Disks X-Sun-Charset: US-ASCII X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1953 Lines: 42 > >2. Drive letters should specify the device, not the filing system. D1 and M1 > > is a horrid idea. > > The D (M,T,N,H,S or that have you) is the device specifier, the 1,2,3,4 etc > are the drives (or other) attached to the device. So floppy 1 can be read > either as a SAM disc (D1) an MS-DOS disc (M1) or maybe a CP/M disc (C1)??? The device is the disc drive. The format of the media should not be a part of the device specifier. What would be what if you eg. have one MS-DOS disc and one MS-DOS ZIP-drive? > > > >The filing system should be auto-detected, or depend on which module is > >loaded, or else be set with a command (DEVICE FORMAT "MSDOS" anyone?). > > I agree you should be able to do something like "What is in floppy 1" and that > you should be able to set things as defaults with a DEVICE command. How we do > it??? More ideas please. The tape device is already 'broken' as it's the only device which has a parameter mixed with the device specifier. To be syntactical good it should be something like 'DEVICE T(35)' or 'DEVICE T=35' or perhaps even 'FORMAT T 35' - however, this implies that something is 'wiped' clean if you don't look at T as the 'stream'. Normally you'd do 'DEVICE D1' to set the default device to D1. A new syntax could be 'DEVICE D1 MSDOS' (or 'DEVICE D1(MSDOS)'), it would still be device D1, but with a different format on the media. Ideally, this should be auto-detected. Hence, you should only need to do FORMAT d1:"xxx" MSDOS. Yes, the device driver should figure out which format driver to use by itself, hence separating the device from the format. This way, the device driver should subscribe itself to the kernel if a new device is installed. And this way the format driver should subscribe itself to the device driver when/if a new format on a given driver is relased. Completely transparent, or...? -Frode PS: It just occured to me that I have forgotten quite a lot about SAM BASIC. :( From owner-sam-users@nvg.ntnu.no Sat Mar 7 17:07:04 1998 Message-ID: Date: Sat, 7 Mar 1998 16:50:34 +0000 To: sam-users@nvg.unit.no From: James R Curry Subject: Re: Floppy Disks MIME-Version: 1.0 X-Mailer: Turnpike Version 3.03a X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 338 Lines: 8 > I don't like auto-detect, it gives the computer control over something > that I think should be under program/user control. Hmm, what's the problem here? Surely the disk change should generate an interrupt, which, by default the OS can handle but the programmer/user can grab to point to their own routines if wanted? -- James Curry From owner-sam-users@nvg.ntnu.no Sat Mar 7 17:15:13 1998 From: BillRitman Message-ID: Date: Sat, 7 Mar 1998 12:09:59 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM (is a reply to: SamSon - The aim???) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0.i for Windows sub 178 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1919 Lines: 51 In a message dated 06/03/98 15:31:05, you write: > > > I must admit to not knowing a great deal about the ARM. But what I do > know is > > that there are thousands of people with Z80 knowledge and those are the > people > > that we should be aiming at. > > That's okie. I have no idea about the ARM either. Yes, there are thousands > of > people who can program the Z80. BUT, they already know how to program the > Z80. They want the challenge. They want something new. They want to break > new ground. No they don't - if that was true then they would all be programming PC's or something else. People like the Spectrum and Sam because they are simple and easy to get to grips with. > > Yes. We can still use the present SAM and have an add-on card for what-ever > design issue problems you want sort out before-hand. But does it have to be > a Z80 based processor? If the present SAM used the Z380 when it first came > out, perhaps it wouldn't have the non-success it did. But is it wise to use > it now? > > It reminds me of when I was deciding what to do for my final year project. > I > wanted to build something out of hardware. My supervisor asked what I > wanted > as the main processor. I said I wanted to use the Z80 becuase I knew it > pretty > well. "Why?" he asked, "It isn't very challenging if you used a Z80." In > the end, > I chose the processor that I could find to fit the rest of the project that > I designed. > > What I'm trying to say is that if you are intending to spend all that money > and > time building something, why not do it properly and find something > challenging. Why have people gone on buying Ford Escort cars (like mine) for 30 years. Because they like them, they feel comfortable with something they can trust. Who wants to do something challanging? > > Now, back to software download onto flash.... *sigh* > > Justin. > Bill. From owner-sam-users@nvg.ntnu.no Sat Mar 7 17:23:25 1998 From: BillRitman Message-ID: Date: Sat, 7 Mar 1998 12:15:49 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0.i for Windows sub 178 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 256 Lines: 9 In a message dated 07/03/98 15:50:18, you write: > > The tape device is already 'broken' as it's the only device which has > a parameter mixed with the device specifier. It is also broken because tape loading/saving never works. Forget tape. Bill. From owner-sam-users@nvg.ntnu.no Sat Mar 7 18:33:46 1998 Message-Id: <3.0.1.32.19980307132701.006cca78@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sat, 07 Mar 1998 13:27:01 -0500 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Floppy Disks In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 857 Lines: 23 At 04:50 PM 3/7/98 +0000, you wrote: >Status: > >> I don't like auto-detect, it gives the computer control over something >> that I think should be under program/user control. > >Hmm, what's the problem here? Surely the disk change should generate an >interrupt, which, by default the OS can handle but the programmer/user >can grab to point to their own routines if wanted? Also, what's worse: 1. The computer auto-detects the disk format and throws an error 'cos the filename's wrong. 2. The user/program doesn't do it right, and it corrupts SAM disks with MSDOS files, or MSDOS disks with SAM files? Simon *********************************************************** *Product Development Specialist/WebMaster/Graphic Designer* *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* *********************************************************** From owner-sam-users@nvg.ntnu.no Sat Mar 7 19:18:25 1998 Message-Id: <3.0.1.32.19980307141013.006cca78@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sat, 07 Mar 1998 14:10:13 -0500 To: sam-users@nvg.ntnu.no From: Simon Cooke Subject: SMLU-C - assembly/C programmers only please Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;sam-users@nvg.ntnu.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 8624 Lines: 198 Hi folks. First off, I'd like to exclude people from this discussion who don't have extensive assembly / C programming experience. This isn't because I don't like you or anything, but I'd rather not muddy the waters of this discussion. Trying to fast-track this, so to speak. SMLU-C (SAM Mailing List Users C) ================================= I sat down last night and scribbled some ideas together for a version of C that we can work on. Part of this was working on a skeleton/structure for an ANSI C compiler that can handle generating programs up-to-4.5Mb in length on the SAM. I came to some conclusions. 1. We should be able to generate programs that can (on programmer preference): a. Coexist with the existing DOS/BASIC setup. b. Utilise keyscanning interrupts, etc. c. Allow the user to produce a standalone program that doesn't use *any* of the DOS/ROM routines. d. Load into available pages without destroying existing data that may be in there. e. Coexist happily with other programs loaded at the same time, where possible. This means that we'll need a variety of runtime portions that can be swapped in/out depending on which type of program we're compiling. This should also lead to more efficiently compiled programs depending on the situation we tailor them to. The downside is that the back-end of the compiler is going to be quite complex, and will involve a fair bit of intelligent programming. I'm hoping that the final version of the compiler could be compiled on the SAM and used by SAM users to compile their own programs; however, I feel that this may be impossible -- simple because some of the hoops that we're going to put this backend through will make compilation *incredibly* slow on the existing machine. I envisage these routines to be in the most comprehensive runtime: (A) Basic interface code. This will take the current paging setup, stack, etc and save them so that a safe return to BASIC can be made at program end. Also, it will allow SMLU-C programs to interface with BASIC and DOS through the standard documented entry points. (B) Interrupt handler. This will include a keyscan routine (enhanced and changed from the SAM keyscan one to allow for greater flexibility; probably based around the system I'm using for Termite) , and optionally patch through to a mouse handler, and will also have vectors for FRAME, LINE INT, MIDI IN, MIDI OUT and COMMS interrupts. An example of the interrupt handler code is included later. (C) Interrupt mask change routine. (Because of the way that I'm going to build this to work on large memory programs, an interrupt mask routine will be provided which will globally change the interrupt mask status for the program. More on this later). (D) Malloc routine. This will provide memory management for the SMLU-C program. Partially it'll work on the same basis as the SAM BASIC and MasterDOS allocation tables. (In that these will be copied to and from the SMLU-C allocation table to the MasterDOS/SAM BASIC ones when a BASIC routine is called -- NOTE: this will have a change flag on it too, so that it doesn't happen for every call; just ones where the memory allocation has changed). The malloc routine will provide a number of functions; more later. (E) One-time pointer de-reference code. (ie read-to and write-from pointer routines that are specifically used for low-intensity memory access... these will be called from a code segment that is in upper memory, and will page that segment out to access data, then page it back in and return it to the routine that was up there). (F) Code-segment access code. This will page in a code segment and pass control to it, as well as passing parameters to a private stack held in that segment if those parameters cannot be held in registers for this purpose. The alternate set of registers will be used as much as possible in this kind of swapping system for speed. --- The Runtime block is the base access point for most of the code. This is a single or double page, which will be paged in low during most of the program's execution. In that page will exist: 1. Parameter Passing / normal execution Stack. The size of this should be definable. Code segments which are stack-intensive will make RST &40 (or equivalent) calls to check that they've not overflowed the stack. Stack intensive, for this instance, is defined as putting data that is >64 bytes on the stack, though this could be defined at compile time. If the RST &40 call notes that the stack has overflowed, it will abort program execution, clean up, and return to BASIC / show an error and reset. 2. Local Malloc Heap. This will be a 1 to 16k local heap (defined at compile time) which routines can use to allocate small amounts of memory in (any malloc request for 256 bytes or less will use the local heap). Other requests will be complied with by using the ALLOCT table in way to be defined. 3. All of the interface code. There will be something known as an AUXILLIARY block. This will contain code segments which could not be placed high (they may use pointers a lot). This block will contain routines (similar to the runtime block) that interface with the Runtime block to provide access to other code segments, provide interrupt handling, etc. Code for (E) and (F) (see above) will always be present in the same place in an auxilliary block as it was in the runtime block. Code for (A)(B)(C) and (D) will pass control back to the runtime block for it to be handled there. The interrupt handler must always be present in some form; in the AUXILLIARY block it will look something like this: ORG &0038 PUSH AF IN A,(stat) CPL intmask: AND %mask ; This is affected by the Int. Mask Change Handler JR NZ,bounce.me ;if an interrupt we're interested in occurs, ;go handle it.Otherwise exit. POP AF EI RET bounceme: PUSH BC LD B,A IN A,(LMPR) LD C,A LD A,#runtimepage.low# ;this is modified by the loader for the ;SMLU-C program to give the right page. OUT (LMPR),A ... ;at this point, we've switch to the runtime page, where, at this address, ;we find the rest of the interrupt handler code for this instance. ; B holds the interrupt status; C holds the page we came from. runtimeintb: LD (spstore:a),SP LD SP,intstack ; give us a 256 byte interrupt stack? RR B JP C,lineint RR B JP C,commsint RR B JP C,midinint RR B JP C,frameint JP midioutint ;note: all of those jumps may be modified to provide patches. ;interrupt routines stack any registers they use, apart from AF. ;They *MUST* stack BC if they're going to use it. ; Should they be calls rather than jumps? ;here's the pass-back routine (in the runtime block) runtimepbint: spstore: LD SP,&0000 LD A,C OUT (LMPR),A ... ; At this point, we're back in the auxilliary block we came from, so... auxpbint: POP BC POP AF EI RET Questions: 1. Should AUX blocks have their own stacks, or should they page the runtime block in HIGH and use the standard stack there? (after adding 32768 to it). Or should it be done on a case by case basis by the compiler? 2. Is the way I'm suggesting of organising data (ie. have all the code in internal memory, data in external and internal where possible, code runs from low if it uses lots of pointer access) a good one? The compiler is going to have a lot of work to do... it'll have to be able to juggle functions around in pages so that they're placed effeciently for memory access, access to static data, access to other functions they call, etc. It should also be able to make "educated guesses" about pointer access. For example, we don't want to have to perform pointer munging so that we can access data that may be in internal or external memory on any page if we're just messing with an array of 128 bytes in length that's sitting on the parameter stack in low memory; we should just be able to assign, say, HL to it and leave it at that. Likewise, if a routine doesn't perform lots and lots of pointer accessing, then it can be kept high, and the one-time dereference routines can be used. We could have a scratch area of 1024k that could be written back and forth from the runtime block to the actual memory it's representing at that time for fast access too... that kind of thing. It all depends on how much information we can wring out of the compiler. Please throw in your 2p's worth. Simon *********************************************************** *Product Development Specialist/WebMaster/Graphic Designer* *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* *********************************************************** From owner-sam-users@nvg.ntnu.no Sat Mar 7 19:36:36 1998 Message-ID: <3500BCB5.4A62@postmaster.co.uk> Date: Fri, 06 Mar 1998 19:19:17 -0800 From: David Ledbury Organization: The Foundation for Green Eggs & Ham X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: sam-users@nvg.unit.no Subject: Re: The Plan for SAM. References: <01bd4998$07d1f9a0$LocalHost@default> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1935 Lines: 67 chris wrote: > > Okay after reading one weeks worth of info on the NEW SAM, here's my input > concerning the processor. > > 1) Do not use the Z380 The only problem I can see with the Z380 - is that I have my doubts to it's longevity. Perhaps escaping from the Zilog compatible family may not be a bad idea... > 2) Do not use the ARM family Hmmmmm.... They're nice enough processors - but what else uses them other than the 3DO and the Archemidies....? Saying which, using an Arm processor would allow existing software from the Archy to get transfered for this processor. Also, didn't Cookie do a bit of research into this family...? > 3) Do Use the Mips but > a) Not the R3000 > b) Not the R3000a (PSX ONE) > c) But the R4000 (N64 ONE) Well, at lease b & c do have existing systems available - and the R3000a has a development system in existence with the Playstation one. (Is this code compatible Chris?)... I wonder how much Nintendo would charge for their package? > 'cause > a) I can code MIPS Good reason :) > b) Its really easy Can you give ideas of any "mainstream" processor that it resembles? IYSWIM? > c) Further rendisions of Mips CPU's will work inplace of old > CPU's ie it's future upgradable... very important point! > d) The R4000 has built in 64bit FPU At this stage, I think even a lowly 16 or 32 bit FPU would out-strip what we're dealing with :) > and if you do use Mips please do not hard wire COP2 (2nd FPU) to > zero, this as given me some > pain in the ?????? just latley > > Chris Sounds like you've had some fun there :) Incidently, how fast could a R4000 emulate the Z80? Be interesting to see if the N64 could ever have a SAM or Sprctrum emulator built for it? Perhaps a future project for West-Coast? A hardware SAM Emulator for consol owners? David From owner-sam-users@nvg.ntnu.no Sat Mar 7 19:36:36 1998 From: SparkY To: sam-users Subject: Re: The Plan for SAM (is a reply to: SamSon - The aim???) Date: Sat, 7 Mar 1998 19:20:01 -0000 Message-Id: <01bd49fe$063ca340$2414a8c2@sparky> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1161 Lines: 32 -----Original Message----- From: BillRitman >> What I'm trying to say is that if you are intending to spend all that money >> and >> time building something, why not do it properly and find something >> challenging. > >Why have people gone on buying Ford Escort cars (like mine) for 30 years. >Because they like them, they feel comfortable with something they can trust. >Who wants to do something challanging? [snip] >Bill. Erm, they are going to stop making Ford Escorts ;) On the other hand, I think we should stick to the Z80 based processors, I can't really see the point of making the leap to another line of processors, just for the sake of it being "challenging". Most of us don't have time to learn to code for a new processor all over again, so we would lose most of our most needed coders! Erm. I just agreed with Bob. Oh dear. :) Gavin ========================================================= Email: gavin.smith@cableol.co.uk IRC: Undernet's #TheLocal, #Sam-users, #Akeran (SparkY or SparkYY) #TheLocal webpage: http://www.infj.ulst.ac.uk/~ckh225 ICQ: 5099913 ========================================================= From owner-sam-users@nvg.ntnu.no Sat Mar 7 19:36:36 1998 Message-Id: <3.0.1.32.19980307142157.006ce2b0@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sat, 07 Mar 1998 14:21:57 -0500 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Mostly 'ARMless In-Reply-To: <40340e05.3501107f@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 555 Lines: 20 At 04:16 AM 3/7/98 EST, you wrote: >Status: RO > >In a message dated 06/03/98 14:58:51, you write: > >> >>> (why does netscape go dead when I accidentally press shift-insert?) >> >>It's Netscape, it doesn't need a reason. >Well at least its not a Microsloth product. Tsk. Your prejudices are showing. :) Simon *********************************************************** *Product Development Specialist/WebMaster/Graphic Designer* *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* *********************************************************** From owner-sam-users@nvg.ntnu.no Sat Mar 7 20:16:30 1998 Message-Id: <3.0.1.32.19980307150641.006855c8@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sat, 07 Mar 1998 15:06:41 -0500 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: The Plan for SAM. In-Reply-To: <517ed17.35011089@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 964 Lines: 27 >Now slow down. C is a language, which like many other languages exists in >several forms. Yes SAM C is a Small C, but that does not mean it is not a C >compiler. Small C is a subset of C. C is defined in K&R. If it's not K&R, it's not C. Apples are fruit. However, all fruit are not apples. The same argument applies. >I disagree. I think that there will still be many people without day-to-day >access to a powerful enough PC to run SIM Coupe. If we work on it being and >'on-machine' project then we can't go wrong. Well, let's put it this way. I'm not going to spend 5 minutes waiting for a large assembly language program to compile, or 15 minutes for a C one, by using my SAM to do it. Time's precious. Simon *********************************************************** *Product Development Specialist/WebMaster/Graphic Designer* *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* *********************************************************** From owner-sam-users@nvg.ntnu.no Sat Mar 7 20:16:32 1998 Message-ID: <3500C199.AA6@postmaster.co.uk> Date: Fri, 06 Mar 1998 19:40:09 -0800 From: David Ledbury Organization: The Foundation for Green Eggs & Ham X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: sam-users@nvg.unit.no Subject: Re: The Plan for SAM (is a reply to: SamSon - The aim???) References: <01bd49fe$063ca340$2414a8c2@sparky> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1433 Lines: 46 SparkY wrote: > > -----Original Message----- > From: BillRitman > > >> What I'm trying to say is that if you are intending to spend all that > money > >> and > >> time building something, why not do it properly and find something > >> challenging. > > > >Why have people gone on buying Ford Escort cars (like mine) for 30 years. > >Because they like them, they feel comfortable with something they can > trust. > >Who wants to do something challanging? > > [snip] > >Bill. > > Erm, they are going to stop making Ford Escorts ;) On the other hand, I > think we should stick to the Z80 based processors, I can't really see the > point of making the leap to another line of processors, just for the sake of > it being "challenging". Most of us don't have time to learn to code for a Hmmmm.... A new whizzy processor would give us more future expansion... and a fair bit more umpf than even the fastest Zilog member.... How about this for a suggestion.... One of the R3000/R4000 series with Z80 emulation as well? Giving access to both sides for dedicated SAM'sters with Z80 knowledge, and even more power with those with the patience and power to learn it... > new processor all over again, so we would lose most of our most needed > coders! Erm. I just agreed with Bob. Oh dear. :) It happens... I think you can get cream to treat it tho ... :) (At least that's what I've heard :) > Gavin David From owner-sam-users@nvg.ntnu.no Sat Mar 7 20:44:50 1998 From: SparkY To: sam-users Subject: Re: The Plan for SAM (is a reply to: SamSon - The aim???) Date: Sat, 7 Mar 1998 20:37:48 -0000 Message-Id: <01bd4a08$e485a700$0314a8c2@sparky> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1387 Lines: 27 -----Original Message----- From: David Ledbury >Hmmmm.... A new whizzy processor would give us more future expansion... >and a fair bit more >umpf than even the fastest Zilog member.... Do we have the time and money to look at another line of processors? If we built a machine without a Z80 based CPU in it, would it be a SAM? This is getting to sound like the time the SAMSon was originally mentioned in 1996, with everyone getting carried away - if there is going ot be a SAMSon (and I personally don't think there is any serious commitment towards building one), then it's got to be one that doesn't drive current SAM owners away, it's got to be one our current coders can instantly use, so we can get some software done, and (perhaps most importantly), it's got to be cheap and quick to build. The plan is (and again I say that I have doubts that there is anything serious in this, at least from Bob's point of view), to build a series of add-ons to the current SAM, which may, at a later date, form a new computer. The Z380 seems to me, to be the way to go. Gavin ========================================================= Email: gavin.smith@cableol.co.uk IRC: Undernet's #TheLocal, #Sam-users, #Akeran (SparkY or SparkYY) #TheLocal webpage: http://www.infj.ulst.ac.uk/~ckh225 ICQ: 5099913 ========================================================= From owner-sam-users@nvg.ntnu.no Sat Mar 7 21:09:02 1998 Message-ID: <3500D54C.3627@postmaster.co.uk> Date: Fri, 06 Mar 1998 21:04:12 -0800 From: David Ledbury Organization: The Foundation for Green Eggs & Ham X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: sam-users@nvg.unit.no Subject: Re: The Plan for SAM References: <01bd4a08$e485a700$0314a8c2@sparky> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2106 Lines: 59 SparkY wrote: > > -----Original Message----- > From: David Ledbury > > >Hmmmm.... A new whizzy processor would give us more future expansion... > >and a fair bit more > >umpf than even the fastest Zilog member.... > > Do we have the time and money to look at another line of processors? If we > built a machine without a Z80 based CPU in it, would it be a SAM? This is This is one point we have to get straight here with all parties concerned... So for a change can Bob answer one of my points....??? Are we seriously talking about a new SAM in the long term, or looking at a realisticly priced upgrade for existing owners? Or even both? In all honesty, forgetting the power of any upgrade system for the moment, we have to look at the cost & availabilty at this stage. IE if such an upgrade is going to go past the "Dream-ware" stage - then we have to know that not only it can be affordable by the ordinary SAM user.... but also that it can still be got in another few years ... or at least a compatible upgrade... > getting to sound like the time the SAMSon was originally mentioned in 1996, > with everyone getting carried away - if there is going ot be a SAMSon (and I > personally don't think there is any serious commitment towards building > one), I'd like to see some definate commitment here as well... Incidently - by the same score, we could do with more of these people who say they support the plan, to buy other independant hardware... such as the Quazar Surround soundard? > then it's got to be one that doesn't drive current SAM owners away, > it's got to be one our current coders can instantly use, so we can get some > software done, and (perhaps most importantly), it's got to be cheap and > quick to build. See above... > The plan is (and again I say that I have doubts that there > is anything serious in this, at least from Bob's point of view), to build a > series of add-ons to the current SAM, which may, at a later date, form a new > computer. The Z380 seems to me, to be the way to go. It's certainly an option. > Gavin David From owner-sam-users@nvg.ntnu.no Sat Mar 7 21:24:53 1998 Message-ID: <19980307212107.24380.qmail@hotmail.com> X-Originating-IP: [138.251.20.14] From: Colin Piggot To: sam-users@nvg.unit.no Subject: Re: The Plan for SAM Content-Type: text/plain Date: Sat, 07 Mar 1998 13:21:07 PST X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 973 Lines: 23 David Ledbury said: >Incidently - by the same score, we could do with more of these people >who say they support the plan, to buy other independant hardware... >such as the Quazar Surround soundcard? Thanks for the plug ;) Colin Piggot. __ __ __ __ __ __ __ __ __ __ __ /_ / / /_/ / / //_ /_//_//_ / /_ : Fast Mode 4 __/ / / / / / /_/__// / //_ / /_ : 3d Vector Action! ---- Quoted As THE BEST GAME EVER FOR SAM ----- +------------------------+-------------------------------+ | COLIN PIGGOT | __ ___ __ | | c_piggot@hotmail.com | /| | | | | / | | |\ | | | / | | | |__| / |__| |_\ | | QUAZAR: Hardware and | /_\| |__| | | /__ | | | \ | | Software for the Sam | | +------------------------+-------------------------------+ ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From owner-sam-users@nvg.ntnu.no Sat Mar 7 21:53:03 1998 Message-Id: <3.0.1.32.19980307164501.006bedb8@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Sat, 07 Mar 1998 16:45:01 -0500 To: sam-users@nvg.ntnu.no From: Simon Cooke Subject: SMLU-C Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Orcpt: rfc822;sam-users@nvg.ntnu.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 580 Lines: 18 I'm going to try and make this a team project, so let's see who's willing to do / find what: 1. Preprocessor. 2. Syntax checking 3. Parsing 4. Intermediate code generation, *plus* the data that the intelligent-fit-it-onto-SAM routine needs. 5. Object code generation, linking, embedding, assembling. Feel free to tear this apart. Simon *********************************************************** *Product Development Specialist/WebMaster/Graphic Designer* *Systems Architect/Analyst/GUI Design Manager/GDB/-cookie-* *********************************************************** From owner-sam-users@nvg.ntnu.no Sat Mar 7 22:31:22 1998 Message-ID: <3500E87C.4ACA@postmaster.co.uk> Date: Fri, 06 Mar 1998 22:26:05 -0800 From: David Ledbury Organization: The Foundation for Green Eggs & Ham X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: sam-users@nvg.unit.no Subject: Re: The Plan for SAM References: <19980307212107.24380.qmail@hotmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3562 Lines: 86 Colin Piggot wrote: > > David Ledbury said: > >Incidently - by the same score, we could do with more of these people > >who say they support the plan, to buy other independant hardware... > >such as the Quazar Surround soundcard? > > Thanks for the plug ;) > > Colin Piggot. Np Colin... you deserve it... But seriously, I have a point to make here... We're talking about more plans for SAM expansion, and as most people are aware - Martin Rookyard and Simon Cooke have worked on some of the finest plans around on this.... But certain individuals here were part of the reason that these didn't see the light of day, despite them being prototyped and proved to have worked. And it's some of these people that are now pushing for new hardware? After killing off other peoples projects already? If - and notice that word - if! any "SAMSON" project see's the light of day... WHY THE F**K DIDN'T THESE PEOPLE DO SOMETHING ABOUT IT WHEN PEOPLE WHERE ACTUALLY WORKING ON THEM... INSTEAD OF F**KING YEARS TOO LATE! Please note: once again... I am not anything to do with the running of Persona - and thus this is my opinions only. I'm just (these days anyway :) - just the Editor of a lowly diskzine...) *I* have always supported new SAM hardware (even going to the extent of buying the shitty Blue Alpha Sampler!) - and will always do so... I've bought the Quazar Surround Soundcard... as well (although that WAS worth the money!) Look, if anything actually ever appears in the form of the "SAMSON" project - then I will buy it... as long as it's actually affordable... I think the 60 quid - 70 quid mark is the ceiling price for any decent processor upgrade... But .... unless someone builds an add-on to plug the SAM to the N64 (seriously, is this possible!) then I think an R4000 upgrade is unlikely. As that's the only way you'd ever see the R4000 on SAM i think. Let's be realistic here.... We assume want to see the SAM around for years... but in what form? And really, is anyone actually going to go any further than just talk? We're very good at that... but after all this time what have we got? A lot of talk about the SRAM board that no serious programmer that I've ever heard of (except Nev - no offence!) seems to think is a good idea... we had a lot of wibble about changing the disk commands to outdated Spectrum +D ones.... and that's about it. Perhaps Bob should bother to speak to the two people we know have had a little success of upgrading SAM ... Simon & Martin, eat humble pie and FIND OUT WHAT THE F**K TO DO TO UPGRADE THINGS PROPERLY!!! Have we got any further on this lark since it was first proposed? David Ledbury - still a loyal SAM supporter since 1989... > __ __ __ __ __ __ __ __ __ __ __ > /_ / / /_/ / / //_ /_//_//_ / /_ : Fast Mode 4 > __/ / / / / / /_/__// / //_ / /_ : 3d Vector Action! > ---- Quoted As THE BEST GAME EVER FOR SAM ----- > +------------------------+-------------------------------+ > | COLIN PIGGOT | __ ___ __ | > | c_piggot@hotmail.com | /| | | | | / | | |\ | > | | / | | | |__| / |__| |_\ | > | QUAZAR: Hardware and | /_\| |__| | | /__ | | | \ | > | Software for the Sam | | > +------------------------+-------------------------------+ > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ Quoting Address in full for another plug for Strato for Colin :) From owner-sam-users@nvg.ntnu.no Sat Mar 7 22:51:43 1998 From: chris To: sam-users Subject: Mips in the New Sam Date: Sat, 7 Mar 1998 22:43:38 -0800 Message-ID: <01bd4a5d$86957e40$LocalHost@default> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2022 Lines: 49 >Well, at lease b & c do have existing systems available - and the R3000a >has a development system >in existence with the Playstation one. (Is this code compatible >Chris?)... I wonder how much >Nintendo would charge for their package? You can get GNU 'C++' compilers to mips as freeware so thats not a problem all Mips processors are backward compatable (R4000 will work on a R3000) , but the extend opcodes would give an Exception error (which can be ignored in software) >Can you give ideas of any "mainstream" processor that it resembles? >IYSWIM? It resembles the 68000 for addressing modes/register loading, has the following registers v0, v1 // Return Regs a0, a1, a2 , a3 // Argument Regs t0 , t1 , t2 , t3 , t4 , t5 , t6 , t7 , t8 , t9 // Temp Registers s0 , s1 , s2 , s3 , s4 , s5 , s6 , s7 // Save Registers (Quick Stack) k0, k1 // Kernal/Rom Vars gp // global pointer (Quick Addressing) sp // stack pointer fp // frame pointer ra // return address + 64 32bit Fpu Registers (R4000+) or 32 64bit Fpu Registers >Incidently, how fast could a R4000 emulate the Z80? Be interesting to >see if the N64 could ever have a SAM or Sprctrum emulator built for it? >Perhaps a future project for West-Coast? A hardware SAM Emulator for >consol owners? > Okay the only example I can give on this is the PSX has a GB emulator and that easy runs in a 1/2 a Frame, (The PSX is a 33Mhz R3000a) so I think that the Sam should be emulated very easily indeed, especialty that all register command are only ONE cycle and Muls are only 8 Cycles, Same about memory accessing though, GOD KNOWS HOW LONG THEY TAKE, but that may just be the PSX, 'Cause the N64 Seems fine. Chris From owner-sam-users@nvg.ntnu.no Sat Mar 7 23:02:28 1998 Message-ID: <3500F022.3A6C@postmaster.co.uk> Date: Fri, 06 Mar 1998 22:58:42 -0800 From: David Ledbury Organization: The Foundation for Green Eggs & Ham X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: sam-users@nvg.unit.no Subject: Re: Mips in the New Sam References: <01bd4a5d$86957e40$LocalHost@default> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2500 Lines: 65 chris wrote: > > > I wonder how much > >Nintendo would charge for their package? > > You can get GNU 'C++' compilers to mips as freeware so thats not a problem Good! Shame It'd be C based only tho.... But its something. > all Mips processors are backward compatable (R4000 will work on a R3000) , > but the extend opcodes would give an Exception error (which can be ignored > in software) I'd assume then this would carry on in future family members? > >Can you give ideas of any "mainstream" processor that it resembles? > >IYSWIM? > > It resembles the 68000 for addressing modes/register loading, > has the following registers > > v0, v1 // Return Regs > a0, a1, a2 , a3 // Argument Regs > t0 , t1 , t2 , t3 , t4 , t5 , t6 , t7 , t8 , t9 // Temp Registers > s0 , s1 , s2 , s3 , s4 , s5 , s6 , s7 // Save Registers (Quick Stack) > k0, k1 // Kernal/Rom Vars > gp // global pointer > (Quick Addressing) > sp // stack pointer > fp // frame pointer > ra // return address > > + 64 32bit Fpu Registers (R4000+) > or 32 64bit Fpu Registers Again pretty helpful - it seems to have a fair bit of umpf... and more registers than the 6502 family :) Including the crap effort in the Super Nes. > >Incidently, how fast could a R4000 emulate the Z80? Be interesting to > >see if the N64 could ever have a SAM or Sprctrum emulator built for it? > >Perhaps a future project for West-Coast? A hardware SAM Emulator for > >consol owners? > > > > Okay the only example I can give on this is the PSX has a GB emulator and > that easy runs in a > 1/2 a Frame, (The PSX is a 33Mhz R3000a) so I think that the Sam should be > emulated very easily > indeed, especialty that all register command are only ONE cycle and Muls are > only 8 Cycles, Same about memory accessing though, GOD KNOWS HOW LONG THEY > TAKE, but that may just be the PSX, 'Cause the N64 Seems fine. > > Chris For us mere mortals - how would that compare in approx speed to a real exisiting SAM...? BTW - Unlike how my previous posting may appear - I AM in favour of a new processor... I just doubt it's cost effectiveness.... and likelyhood of being done. PLEASE PROVE ME WRONG! David From owner-sam-users@nvg.ntnu.no Sun Mar 8 05:19:44 1998 Date: Sun, 8 Mar 1998 00:17:01 -0500 (EST) Message-Id: <199803080517.AAA26840@smtp2.erols.com> X-Mailer: HandStamp Pro 1.0 Subject: Function Pointers Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Mime-Version: 1.0 From: Simon Cooke To: sam-users@nvg.ntnu.no X-Orcpt: rfc822;sam-users@nvg.ntnu.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1519 Lines: 38 I need a quick check on something: Can function pointers be cast to another type? Eg: are the lines below all valid? int (*comp)(char *, char *); int *c; void *v; long d; c = (int *)comp; v=(void *)comp; d=∁ ? If not, it'll make my life lots easier. If so... Yikes. The reason I ask is because I'm thinking of using a 4-byte representation of pointers. type,page,msbaddr,lsbaddr type= whether it's a pointer to int/ext memory, and if it's a function pointer, if the function has to be run low or high. (thinks) You know... I might be able to get away with it even if pointers can be cast between types. The study so far: 1. Pointer dereferencing will likely be slow, though on entry to a function, after the first usage it may speed up with clever optimisation. 2. Provided the size of an array is known at runtime always (and I reckon it is) I can make optimisations on array access for simple data types, and possibly more complex ones. 3. Same goes for structs. 4. Largest size of a struct / array subscript *may* be 16384 bytes - though alternatively, that may end up as an optimisation-style decision making factor. 5. Depending on the format of the output code of lcc, all we will need to write is the backend, not the whole caboodle. A simple (and slow to execute) output version could be up and running soon - with the provisos: no floating point most libraries probably missing. *phew* Nomis --- This message scribbled for you by hand on a Palmpilot. Please excuse brevity and spelling mistakes. From owner-sam-users@nvg.ntnu.no Sun Mar 8 11:29:31 1998 From: BrenchleyR Message-ID: Date: Sun, 8 Mar 1998 06:25:22 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2405 Lines: 63 In a message dated 07/03/98 15:50:18, you write: >o > >> >2. Drive letters should specify the device, not the filing system. D1 and >M1 >> > is a horrid idea. >> >> The D (M,T,N,H,S or that have you) is the device specifier, the 1,2,3,4 etc >> are the drives (or other) attached to the device. So floppy 1 can be read >> either as a SAM disc (D1) an MS-DOS disc (M1) or maybe a CP/M disc (C1)??? > >The device is the disc drive. The format of the media should not be >a part of the device specifier. What would be what if you eg. have one >MS-DOS disc and one MS-DOS ZIP-drive? I don't have the answer for everything :) However, I'm looking at it as a logical device rather than the hardware. Each logical device just needs a set of drivers. > >> > >> >The filing system should be auto-detected, or depend on which module is >> >loaded, or else be set with a command (DEVICE FORMAT "MSDOS" anyone?). >> >> I agree you should be able to do something like "What is in floppy 1" and >that >> you should be able to set things as defaults with a DEVICE command. How we >do >> it??? More ideas please. > >The tape device is already 'broken' as it's the only device which has >a parameter mixed with the device specifier. To be syntactical good >it should be something like 'DEVICE T(35)' or 'DEVICE T=35' or perhaps >even 'FORMAT T 35' - however, this implies that something is 'wiped' >clean if you don't look at T as the 'stream'. Mmmm. I think I see what you mean. > >Normally you'd do 'DEVICE D1' to set the default device to D1. A >new syntax could be 'DEVICE D1 MSDOS' (or 'DEVICE D1(MSDOS)'), it >would still be device D1, but with a different format on the media. >Ideally, this should be auto-detected. Hence, you should only need >to do FORMAT d1:"xxx" MSDOS. > >Yes, the device driver should figure out which format driver to use >by itself, hence separating the device from the format. This way, >the device driver should subscribe itself to the kernel if a new >device is installed. And this way the format driver should subscribe >itself to the device driver when/if a new format on a given driver >is relased. Completely transparent, or...? Yes, well, I also think I understand that. Will keep thinking. > > -Frode > >PS: It just occured to me that I have forgotten quite a lot about SAM >BASIC. :( It is like riding a bike, it will come back very quick when you need it. -- bob. From owner-sam-users@nvg.ntnu.no Sun Mar 8 11:29:31 1998 From: BrenchleyR Message-ID: <5c018ff7.35028027@aol.com> Date: Sun, 8 Mar 1998 06:25:24 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 726 Lines: 21 In a message dated 07/03/98 17:02:00, you write: >o > >> I don't like auto-detect, it gives the computer control over something >> that I think should be under program/user control. > >Hmm, what's the problem here? Surely the disk change should generate an >interrupt, which, by default the OS can handle but the programmer/user >can grab to point to their own routines if wanted? The problem is that different disc formats need to be checked, that means that the checking routine would have to be extended every time a new format was to be included. Better I think to leave that to the human in charge. If you make these sort of things tooooo intelligent it will just take up too much space and too much time. -- Bob. From owner-sam-users@nvg.ntnu.no Sun Mar 8 11:29:31 1998 From: BrenchleyR Message-ID: <299fbfe.35028028@aol.com> Date: Sun, 8 Mar 1998 06:25:26 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Floppy Disks Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 2.5.i for Windows sub 18 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 958 Lines: 30 In a message dated 07/03/98 18:31:48, you write: >o > >At 04:50 PM 3/7/98 +0000, you wrote: >>Status: >> >>> I don't like auto-detect, it gives the computer control over something >>> that I think should be under program/user control. >> >>Hmm, what's the problem here? Surely the disk change should generate an >>interrupt, which, by default the OS can handle but the programmer/user >>can grab to point to their own routines if wanted? > >Also, what's worse: > >1. The computer auto-detects the disk format and throws an error 'cos the >filename's wrong. >2. The user/program doesn't do it right, and it corrupts SAM disks with >MSDOS files, or MSDOS disks with SAM files? > >Simon But if you carry out a SAVE/LOAD with the disc, expecting SAM format, and it is MS-DOS format, you will get an error saying the disc is wrong format. There is no auto-detection involved in that, the very structure of the disc system means it will not work. -- Bob. From owner-sam-users@nvg.ntnu.no Sun Mar 8 15:15:26 1998 From: BillRitman Message-ID: <1d3ffe99.3502b414@aol.com> Date: Sun, 8 Mar 1998 10:06:58 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM (is a reply to: SamSon - The aim???) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0.i for Windows sub 178 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 777 Lines: 28 In a message dated 07/03/98 19:38:28, you write: > >Why have people gone on buying Ford Escort cars (like mine) for 30 years. > >Because they like them, they feel comfortable with something they can > trust. > >Who wants to do something challanging? > > [snip] > >Bill. > > Erm, they are going to stop making Ford Escorts ;) I know, sad :( >On the other hand, I > think we should stick to the Z80 based processors, I can't really see the > point of making the leap to another line of processors, just for the sake of > it being "challenging". Most of us don't have time to learn to code for a > new processor all over again, so we would lose most of our most needed > coders! Erm. I just agreed with Bob. Oh dear. :) Wow! you have :) > > Gavin Bill. From owner-sam-users@nvg.ntnu.no Sun Mar 8 15:15:26 1998 From: BillRitman Message-ID: Date: Sun, 8 Mar 1998 10:07:00 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM (is a reply to: SamSon - The aim???) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0.i for Windows sub 178 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 899 Lines: 34 In a message dated 07/03/98 20:21:21, you write: > > Hmmmm.... A new whizzy processor would give us more future expansion... > and a fair bit more > umpf than even the fastest Zilog member.... But then what do I do with the little bit of machine code I 've managed to learn over the years? > > How about this for a suggestion.... > > One of the R3000/R4000 series with Z80 emulation as well? Giving access > to both > sides for dedicated SAM'sters with Z80 knowledge, and even more power > with those > with the patience and power to learn it... It would have to be fast to emulate the SAM. > > > new processor all over again, so we would lose most of our most needed > > coders! Erm. I just agreed with Bob. Oh dear. :) > > It happens... I think you can get cream to treat it tho ... :) (At least > that's what I've heard :) > > > Gavin > > David > > Bill. From owner-sam-users@nvg.ntnu.no Sun Mar 8 15:15:26 1998 From: BillRitman Message-ID: <85a7c319.3502b418@aol.com> Date: Sun, 8 Mar 1998 10:07:02 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM (is a reply to: SamSon - The aim???) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0.i for Windows sub 178 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1446 Lines: 33 In a message dated 07/03/98 20:41:12, you write: > -----Original Message----- > From: David Ledbury > > >Hmmmm.... A new whizzy processor would give us more future expansion... > >and a fair bit more > >umpf than even the fastest Zilog member.... > > Do we have the time and money to look at another line of processors? If we > built a machine without a Z80 based CPU in it, would it be a SAM? This is > getting to sound like the time the SAMSon was originally mentioned in 1996, > with everyone getting carried away - if there is going ot be a SAMSon (and I > personally don't think there is any serious commitment towards building > one), then it's got to be one that doesn't drive current SAM owners away, > it's got to be one our current coders can instantly use, so we can get some > software done, and (perhaps most importantly), it's got to be cheap and > quick to build. The plan is (and again I say that I have doubts that there > is anything serious in this, at least from Bob's point of view), to build a > series of add-ons to the current SAM, which may, at a later date, form a new > computer. The Z380 seems to me, to be the way to go. I agree about the processor Gavin, the only other option I can see is lots of Z80s all doing their own bits. As to how serious things are, I note my question on where the money is comeing from has not been answered yet. > > Gavin Bill. From owner-sam-users@nvg.ntnu.no Sun Mar 8 15:15:29 1998 From: BillRitman Message-ID: <7975a018.3502b41d@aol.com> Date: Sun, 8 Mar 1998 10:07:07 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0.i for Windows sub 178 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3800 Lines: 94 In a message dated 07/03/98 22:31:50, you write: > > Colin Piggot wrote: > > > > David Ledbury said: > > >Incidently - by the same score, we could do with more of these people > > >who say they support the plan, to buy other independant hardware... > > >such as the Quazar Surround soundcard? > > > > Thanks for the plug ;) > > > > Colin Piggot. > > Np Colin... you deserve it... > > But seriously, I have a point to make here... > > We're talking about more plans for SAM expansion, and as most people are > aware - Martin Rookyard > and Simon Cooke have worked on some of the finest plans around on > this.... Scratch Martin Rookyard. He has never managed to make anything work AFAIK. I lost money with SAMCo because he could not ge the digitiser right, I'm led to believe he didn't get it right for Blue Alpha and he still hasn't done it right for Derek Morgan. Both he and Simon may have some good ideas, but the have not managed to finish one single thing so far. > > But certain individuals here were part of the reason that these didn't > see the light of day, despite > them being prototyped and proved to have worked. Try telling that to Derek Morgan. He put his own money into the latest version of the digitiser and was let down. There is a lot of difference between a prototype and a commercial product. > > And it's some of these people that are now pushing for new hardware? > After killing off other peoples > projects already? > > If - and notice that word - if! any "SAMSON" project see's the light of > day... > > WHY THE F**K DIDN'T THESE PEOPLE DO SOMETHING ABOUT IT WHEN PEOPLE WHERE > ACTUALLY WORKING ON THEM... > INSTEAD OF F**KING YEARS TOO LATE! > > Please note: once again... I am not anything to do with the running of > Persona - and thus this is my > opinions only. I'm just (these days anyway :) - just the Editor of a Believe you,,,,,,, > lowly diskzine...) *I* have always supported new SAM hardware (even > going to the extent of buying the shitty Blue Alpha Sampler!) - and will > always do so... I've bought the Quazar Surround Soundcard... as well > (although that WAS worth the money!) > > Look, if anything actually ever appears in the form of the "SAMSON" > project - then I will buy it... as long as it's actually affordable... I > think the 60 quid - 70 quid mark is the ceiling price for any decent > processor upgrade... That I would say depends on what you get for your money. I would not, for mayself anyway, put a price limit on things but it must be value for money. > > But .... unless someone builds an add-on to plug the SAM to the N64 > (seriously, is this possible!) then I think an R4000 upgrade is > unlikely. As that's the only way you'd ever see the R4000 on SAM i > think. > > Let's be realistic here.... We assume want to see the SAM around for > years... but in what form? And really, is anyone actually going to go > any further than just talk? We're very good at that... but after all > this time what have we got? A lot of talk about the SRAM board that no > serious programmer that I've ever heard of (except Nev - no offence!) > seems to think is a good idea... we had a lot of wibble about changing > the disk commands to outdated Spectrum +D ones.... and that's about it. > Perhaps Bob should bother to speak to the two people we know have had a > little success of upgrading SAM ... Simon & Martin, eat humble pie and > FIND OUT WHAT THE F**K TO DO TO UPGRADE THINGS PROPERLY!!! Again, I would have more faith in something Bob was behind than the two people you mention. > > Have we got any further on this lark since it was first proposed? > > David Ledbury - still a loyal SAM supporter since 1989... > Bill. Still loving his SAM. From owner-sam-users@nvg.ntnu.no Sun Mar 8 15:15:29 1998 From: BillRitman Message-ID: <268bf418.3502b41f@aol.com> Date: Sun, 8 Mar 1998 10:07:08 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: Mips in the New Sam Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0.i for Windows sub 178 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 196 Lines: 8 In a message dated 07/03/98 22:50:06, you write: > > You can get GNU 'C++' compilers to mips as freeware so thats not a problem > skews me, could someone explain what GNU stands for? Bill. From owner-sam-users@nvg.ntnu.no Sun Mar 8 15:15:30 1998 From: BillRitman Message-ID: <1687f598.3502b41a@aol.com> Date: Sun, 8 Mar 1998 10:07:04 EST To: sam-users@nvg.unit.no Mime-Version: 1.0 Subject: Re: The Plan for SAM Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0.i for Windows sub 178 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2616 Lines: 84 In a message dated 07/03/98 21:07:01, you write: > > SparkY wrote: > > > > -----Original Message----- > > From: David Ledbury > > > > >Hmmmm.... A new whizzy processor would give us more future expansion... > > >and a fair bit more > > >umpf than even the fastest Zilog member.... > > > > Do we have the time and money to look at another line of processors? If we > > built a machine without a Z80 based CPU in it, would it be a SAM? This is > > This is one point we have to get straight here with all parties > concerned... So for > a change can Bob answer one of my points....??? Ha! Was that a pig that just flew by the window? > > Are we seriously talking about a new SAM in the long term, or looking at > a realisticly > priced upgrade for existing owners? Or even both? Reading Bob's master plan for world domination I think his main aim is upgrades first. > > In all honesty, forgetting the power of any upgrade system for the > moment, we have to > look at the cost & availabilty at this stage. IE if such an upgrade is > going to go past > the "Dream-ware" stage - then we have to know that not only it can be > affordable by the > ordinary SAM user.... but also that it can still be got in another few > years ... or at least > a compatible upgrade... Your logic sounds good. > > > getting to sound like the time the SAMSon was originally mentioned in 1996, > > > with everyone getting carried away - if there is going ot be a SAMSon (and > I > > personally don't think there is any serious commitment towards building > > one), > > I'd like to see some definate commitment here as well... So would I. > > Incidently - by the same score, we could do with more of these people > who say they > support the plan, to buy other independant hardware... such as the > Quazar Surround soundard? And the SD hard drive.... (soory, can't think of any other hardware). > > > then it's got to be one that doesn't drive current SAM owners away, > > it's got to be one our current coders can instantly use, so we can get > some > > software done, and (perhaps most importantly), it's got to be cheap and > > quick to build. > > See above... > > > The plan is (and again I say that I have doubts that there > > is anything serious in this, at least from Bob's point of view), to build > a > > series of add-ons to the current SAM, which may, at a later date, form a > new > > computer. The Z380 seems to me, to be the way to go. > > It's certainly an option. > > > Gavin > > David > > Bill. From owner-sam-users@nvg.ntnu.no Sun Mar 8 16:11:29 1998 Message-ID: <3501E162.53FF@postmaster.co.uk> Date: Sat, 07 Mar 1998 16:08:02 -0800 From: David Ledbury Organization: The Foundation for Green Eggs & Ham X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: sam-users@nvg.unit.no Subject: Re: The Plan for SAM (is a reply to: SamSon - The aim???) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 858 Lines: 26 BillRitman wrote: > > In a message dated 07/03/98 20:21:21, you write: > > > > > Hmmmm.... A new whizzy processor would give us more future expansion... > > and a fair bit more > > umpf than even the fastest Zilog member.... > > But then what do I do with the little bit of machine code I 've managed to > learn over the years? *IF* and I mean IF, a fast enough emulator was built... it would literally be able to run any such code under emulation anyway. > > How about this for a suggestion.... > > > > One of the R3000/R4000 series with Z80 emulation as well? Giving access > > to both sides for dedicated SAM'sters with Z80 knowledge, and even more power > > with those with the patience and power to learn it... > > It would have to be fast to emulate the SAM. Again, not impossible. And as likely as a R4000 new processor being done... From owner-sam-users@nvg.ntnu.no Sun Mar 8 16:20:18 1998 Message-ID: <3501E377.3B98@postmaster.co.uk> Date: Sat, 07 Mar 1998 16:16:56 -0800 From: David Ledbury Organization: The Foundation for Green Eggs & Ham X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: sam-users@nvg.unit.no Subject: Re: The Plan for SAM References: <1687f598.3502b41a@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1670 Lines: 54 BillRitman wrote: > > This is one point we have to get straight here with all parties > > concerned... So for > > a change can Bob answer one of my points....??? > > Ha! Was that a pig that just flew by the window? I can't see why not... I mean surely Mr Brenchley is a sensible, reasonable sort of chap who listens to any sensible - or even not-so-sensible - input from people? > > Are we seriously talking about a new SAM in the long term, or looking at > > a realisticly > > priced upgrade for existing owners? Or even both? > > Reading Bob's master plan for world domination I think his main aim is > upgrades first. Sounds good.... What are they? > > affordable by the > > ordinary SAM user.... but also that it can still be got in another few > > years ... or at least > > a compatible upgrade... > > Your logic sounds good. Well... we've had the experience from the SAM itself... WD1772 anyone? BTW What about the floppy controller chip in the new Sintech interface? That's in the WD family ... any info on this? > > I > > > personally don't think there is any serious commitment towards building > > > one), > > > > I'd like to see some definate commitment here as well... > > So would I. Hmmmm.... how many people here - within scope of their means - are willing to put their money where their mouth is? > > Incidently - by the same score, we could do with more of these people > > who say they > > support the plan, to buy other independant hardware... such as the > > Quazar Surround soundard? > > And the SD hard drive.... (soory, can't think of any other hardware). Well... doesn't mean to say that it doesn't exist ;) From owner-sam-users@nvg.ntnu.no Sun Mar 8 16:26:37 1998 From: davewhitmore@enterprise.net (Dave) To: sam-users@nvg.unit.no Subject: Re: The Plan for SAM (is a reply to: SamSon - The aim???) Date: Sun, 08 Mar 1998 16:20:23 GMT Message-ID: <3506bfbe.13049796@mail.enterprise.net> References: <01bd4a08$e485a700$0314a8c2@sparky> In-Reply-To: <01bd4a08$e485a700$0314a8c2@sparky> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8BIT X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2185 Lines: 52 On Sat, 7 Mar 1998 20:37:48 -0000, you wrote: >-----Original Message----- >From: David Ledbury > >>Hmmmm.... A new whizzy processor would give us more future expansion... >>and a fair bit more >>umpf than even the fastest Zilog member.... I wonder why nobody has mentioned Pentiums? (he he) then Gavin wrote: >Do we have the time and money to look at another line of processors? If we >built a machine without a Z80 based CPU in it, would it be a SAM? This is The same arguments were applied to Amigas - the direction is now PPC i.e. RISC, so what's the matter with dumping Zilog? I'd say go with what the experts say - i.e. ARM. Enthusiast or not, I can't honestly see people shelling out to add bits onto the old SAM. That's a shame, but realistically its days are well and truly over. I'll rephrase that. At the moment SAM is either a nostalgia machine, or 'I use this cos I can't afford a proper computer' thing. I recently made room for my SAM so it is available whenever I want to use it, but it's still a lot less hassle for me to open my 'Dave's Retro Stuff' folder on the desktop and click on SIM Coupe (or X128, UAE, CCS64_95, MAME, or KGEN). PCs might be crap, but there isn't anything else that I can use to have everything in one box, so they can't be /that/ crappy. We have been supposedly trying to move on from CISC based machines for years now - when is it really gonna happen? Bruce Gordon told me that his plans were to eventually go 32bit RISC. Are we supposed to think that he wouldn't have considered moving on from the old processor family to do that? Times move on, and IMO a completely new 'start from scratch' approach is needed. I just can't see the point of doing anything else at all - apart from developing a few virtual devices for SIM Coupe. Yep.. port SIM Coupe over to the Acorn (or similar) then alter and optimise as and when to RISC. Move on from there, and 'oo-look another PPC'... Bur that's just the opinion of a non-hardware and non-programmer end-user kinda bloke.. so I guess it'll count as nothing. Bye, Dave Whitmore http://homepages.enterprise.net/davewhitmore/INDEX.HTM From owner-sam-users@nvg.ntnu.no Sun Mar 8 16:52:04 1998 X-Sender: asc25@pop.hermes.cam.ac.uk Message-Id: In-Reply-To: <268bf418.3502b41f@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 8 Mar 1998 16:49:33 +0000 To: sam-users@nvg.unit.no From: Andrew Collier Subject: Re: Mips in the New Sam X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1706 Lines: 40 At 3:07 pm +0000 8/3/98, BillRitman wrote: >In a message dated 07/03/98 22:50:06, you write: > >> >> You can get GNU 'C++' compilers to mips as freeware so thats not a problem >> >skews me, could someone explain what GNU stands for? GNU stands for "GNU's Not Unix" At the risk of looking like Bob, I'll answer a different question to the one you asked. Just on the offchance that you wanted a helpful reply, you understand :) GNU is, broadly speaking, an organization for the development of free software (free as defined by the GPL, GNU public license - and refers more to freedom of use rather than no-cost distribution). The original aim of the GNU project was to produce an alternative to Unix which was completely free, and GNU code is widely used in most Linux distributions. A part of this project was gcc (GNU C Compiler) which is now freely available across many platforms. They've also invented (and made freely available) various algorithms and standards, such as .gz (GNU-Zip compression) as a response to other, patented algorithms (a case in point is the GIF image format which is patented by IBM and Unisys) For lots more info, point your web browser toward http://www.gnu.org/ Andrew --- +-----------------+----------------------------+--------------------+ | Andrew Collier | email asc25@cam.ac.uk | " | | 1B NatSci | http://carou.sel.cam.ac.uk | Get your kicks | +-----------------+----------------------------+ on 8.124038405 | | Selwyn College Student Computer Support Team | " | | email support@sel.cam.ac.uk | anon | +----------------------------------------------+--------------------+ From owner-sam-users@nvg.ntnu.no Sun Mar 8 20:07:44 1998 From: Samsboss@Postmaster.co.uk (Samsboss) To: sam-users@nvg.unit.no Subject: Who has contributed most. Was RE: Floppy Disks. Date: Sun, 08 Mar 1998 20:03:23 GMT Organization: Brotherhood of man. Message-ID: <3502f972.31119900@mail.enterprise.net> X-Mailer: Forte Free Agent 1.1/16.230 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1247 Lines: 34 In a message dated 01/03/98 12:51:41, you write: > > >So I exagerated a bit, the point still stands that his claims have always > >exceeded what he actually does. If he spent less time arguing and actually > did > >something I would take him more seriously. > > > >-- > >Bob. > > HAHAHA! Are you serious?! The above applies to you more than to anyone > else!! I, and I believe, the majority on this list, have *much* more respect > for Andrew than for you. And Bob, your pathetic attempts to be the big > "authority" on this list, by insulting the people who actually *have* the > talent on this list, isn't going to work - neither is a reply from your > clone, saying "ooh but Bob is just great, I love him, I'm going to have his > babies, and I read Format as it's just the best blah blah" > > Gavin > Respect? For Andrew Collier? What has he done to earn anyones respect? Come on Gavin, play fair for once in your life, just compare what Andrew has done for the SAM world with what Bob has done. Why not sit down and make a list and then post it here so we can all compare. And while you are at it, list what you have done as well, then we can all have a good laugh. -- SamsBoss. The One And Only. Accept No Others. From owner-sam-users@nvg.ntnu.no Sun Mar 8 20:07:44 1998 From: Samsboss@Postmaster.co.uk (Samsboss) To: sam-users@nvg.unit.no Subject: Re: The Plan for SAM (is a reply to: SamSon - The aim???) Date: Sun, 08 Mar 1998 20:03:38 GMT Organization: Brotherhood of man. Message-ID: <3502f831.30799852@mail.enterprise.net> X-Mailer: Forte Free Agent 1.1/16.230 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2803 Lines: 74 In a message dated 08/03/98 16:24:43, you write: >On Sat, 7 Mar 1998 20:37:48 -0000, you wrote: > >>-----Original Message----- >>From: David Ledbury >> >>>Hmmmm.... A new whizzy processor would give us more future expansion... >>>and a fair bit more >>>umpf than even the fastest Zilog member.... > >I wonder why nobody has mentioned Pentiums? (he he) I don;t know about Pentiums, but I'm told there are lots of AMD 484DX4-100 chips floating around. But no! We want Z80. We want something that is different, don't we? > >then Gavin wrote: > >>Do we have the time and money to look at another line of processors? If we >>built a machine without a Z80 based CPU in it, would it be a SAM? This is > >The same arguments were applied to Amigas - the direction is now PPC >i.e. RISC, so what's the matter with dumping Zilog? I'd say go with >what the experts say - i.e. ARM. Enthusiast or not, I can't honestly >see people shelling out to add bits onto the old SAM. That's a shame, >but realistically its days are well and truly over. > > What? Call a follow Enterprise user 'rubbish', no, can't do that :) > >I'll rephrase that. At the moment SAM is either a nostalgia machine, >or 'I use this cos I can't afford a proper computer' thing. I recently Are you trying to say that SAM is not a proper computer? Pistols at dawn at this rate Dave. >made room for my SAM so it is available whenever I want to use it, but >it's still a lot less hassle for me to open my 'Dave's Retro Stuff' >folder on the desktop and click on SIM Coupe (or X128, UAE, CCS64_95, >MAME, or KGEN). PCs might be crap, but there isn't anything else that >I can use to have everything in one box, so they can't be /that/ >crappy. We have been supposedly trying to move on from CISC based >machines for years now - when is it really gonna happen? > >Bruce Gordon told me that his plans were to eventually go 32bit RISC. >Are we supposed to think that he wouldn't have considered moving on >from the old processor family to do that? Times move on, and IMO a >completely new 'start from scratch' approach is needed. I just can't >see the point of doing anything else at all - apart from developing a >few virtual devices for SIM Coupe. Yep.. port SIM Coupe over to the >Acorn (or similar) then alter and optimise as and when to RISC. Move >on from there, and 'oo-look another PPC'... I can see a lot of what you say, and agree with it. As long as we can keep clear of anything that will just make us another PC clone. > >Bur that's just the opinion of a non-hardware and non-programmer >end-user kinda bloke.. so I guess it'll count as nothing. Zero, zilch, nought, f'all. But at least you said it. > > >Bye, > >Dave Whitmore -- SamsBoss. The One And Only. Accept No Others. From owner-sam-users@nvg.ntnu.no Sun Mar 8 20:18:17 1998 From: chris To: sam-users Subject: Re: Function Pointers Date: Sun, 8 Mar 1998 20:10:35 -0800 Message-ID: <01bd4b11$4fa23680$b9065cc3@default> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 452 Lines: 24 Hi Simon, Function pointers are all ways the maximun address space in size (SAM 16bit , PC 32bit etc.) the casting is only relilant in the following reason's char* pCharPtr; int* pIntPtr; void* pPtr = (void*) (FRED())(void); pCharPtr = (char*) pPtr; pIntPtr = (int*) pPtr; pCharPtr++; // increase by sizeof(char) pIntPtr++; // increase by sizeof(int) By the way what are you doing????? Chris From owner-sam-users@nvg.ntnu.no Sun Mar 8 21:46:36 1998 Message-ID: <19980308214317.5180.qmail@hotmail.com> X-Originating-IP: [138.251.20.14] From: Colin Piggot To: sam-users@nvg.unit.no Subject: WEB PAGES OPEN !!!! Content-Type: text/plain Date: Sun, 08 Mar 1998 13:43:16 PST X-Orcpt: rfc822;sam-users@nvg.unit.no Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1048 Lines: 26 Hello! Just a quick post to say my Sam web pages are now open: http://members.tripod.com/~c_piggot/quazar/ There you'll find information on some of my products such as the 'Quazar Surround' soundcard and 'Stratosphere', as well as screen shots, reviews & feedback and of course my latest news. Colin Piggot. __ __ __ __ __ __ __ __ __ __ __ /_ / / /_/ / / //_ /_//_//_ / /_ : Fast Mode 4 __/ / / / / / /_/__// / //_ / /_ : 3d Vector Action! ---- Quoted As Being THE BEST GAME EVER FOR SAM ---- +------------------------+-------------------------------+ | COLIN PIGGOT | __ ___ __ | | c_piggot@hotmail.com | /| | | | | / | | |\ | | | / | | | |__| / |__| |_\ | | QUAZAR: Hardware and | /_\| |__| | | /__ | | | \ | | Software for the Sam | | +------------------------+-------------------------------+ ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com