From owner-sam-users@nvg.unit.no Sun Dec 1 12:57:55 1996 Date: Sun, 1 Dec 1996 07:54:17 -0500 From: Neville Young <106166.1560@compuserve.com> Subject: re: sos nos dos To: sam users Message-Id: <199612010754_MC1-C83-1A7F@compuserve.com> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1412 Lines: 47 >I think it should be:- >LOAD D1"Filename" >or >LOAD H1"Filename" >That way the device specifier is seperate. I don't realy care if it is LOAD D1"flename" or LOAD "D1:filename" but I do NOT think we should have LOAD H..... or LOAD "H:...... At present HDOS (Hardly a Disk Operating System) can run many (bu by no way all) current programs as when loaded the hard drive is D7. If you then use the ALTER DEVICE D7 to D1 command most progs that use D! will now work from the hard drive. This is because Andy built a lookup table in MDOS to change REAL devices into VIRTUAL ones. I think this is a better road to go down so that at some time you can set up SAMSON to alter any request for D! say into H1 or T1 or N1 or CD1 or whatever. In this way when new devices come along the programs do not need to be changed as they often do now. Perhaps if we had a table for devices D1 to D99 (255?) which point to actual devices then D1 could point to DRIVE1 or HARDDRIVE1 or BACKUPTAPE or NETWORK or matter transporter and in that way the command could be passed to the driver for the device as the table would also hold the required entry points into the drivers. It would make the system sooooo much easier to entend for new hardware. Even now we can do somthing (more limited) eg want a pc type keyboard? OPEN #0,"PCKEY" and OPEN #0,"K" only problem is the syntax won't hold it for long stream types. Nev From owner-sam-users@nvg.unit.no Sun Dec 1 13:18:32 1996 Date: Sun, 1 Dec 1996 13:16:31 +0000 (GMT) From: Tim Wells To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS In-Reply-To: <961130154851_1218996317@emout19.mail.aol.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 717 Lines: 30 On Sat, 30 Nov 1996 BrenchleyR@aol.com wrote: > I think it should be:- > > LOAD D1"Filename" > or > LOAD H1"Filename" > > That way the device specifier is seperate. Can't agree with you on that one, as it means the user would be unable to change the drive from within a program: ie with your syntax: Within the program you'd have to have: Change drive to required drive (not all programs give this option) Input filename: proggy LOAD Dx"proggy" Whereas with the the other system: Input filename: Dx:proggy LOAD "Dx:proggy" Easier to do if you just want one file from a different drive to that you use the rest of the time, and also can be done if the programmer hasn't put in a Change Drive option. Tim From owner-sam-users@nvg.unit.no Sun Dec 1 14:43:14 1996 Date: Sun, 1 Dec 1996 09:41:39 -0500 From: BrenchleyR@aol.com Message-Id: <961201094139_1286190154@emout20.mail.aol.com> To: sam-users@nvg.unit.no Subject: Proposed Changes to DOS and ROM Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 6322 Lines: 157 A very long time ago I produced the following document in order to get feed-back on proposed changes to create SAM ROM V4 and SAMDOS V3. It now need a lot more work doing on it but I thought is would give a few people something to think about in the meantime. Bob.. SAMDOS V3.0 NOTES FOR CHANGES FROM EXISTING SAMDOS 2 This document lays out the changes required to SAMDOS version 2 to create SAMDOS version 3. No priority should be implied by the order given. Section 1. Syntax Changes. 1.1 Disc device numbers within LOAD; SAVE; MERGE etc. Drive numbers are to be specified outside of the filename in the same way as used by both the DISCiPLE and PLUS D, i.e. LOAD d1[;]"FILENAME" ..... SAVE d1[;]"FILENAME" ..... etc. Allow d1,d2 etc, or d* (*=last drive used). Where possible the old syntax will remain but the new syntax will have priority. i.e. LOAD d2"D1:FRED" will look on drive 2 for a file called D1:FRED. The [;] before the open quotes of the filename may be required if a drive number is given as a variable. 1.2 Filenames. SAMDOS 3 will allow all characters except '*' and '?' to be used in a filename. On LOAD, COPY and ERASE operations a '?' may be used as a wild card to replace any single character in the 10 character filename, '*' can be used at the end of a partial filename to say match ANY character from that point on. Neither the '*' or the '?' character can be used in a SAVE and should give an error of 'Invalid Filename'. 1.3 Filename extensions are not allowed. If say ERASE "*.BAS" was typed it should produce the message 'INVALID FILENAME' because there are one or more characters between the * and the " at the end of the filename. 1.4 CAT to replace DIR. The token will print as CAT, therefore any program saved under SAMDOS 2 will have all its DIRs come up as CATs. If DIR is typed at the keyboard then CAT will appear in the listing. CAT [device number] gives full listing of the directory. CAT [device number]! gives a short listing. CAT #n; [device number][!] prints the catalogue to the specified stream. CAT [device number][!];"FILENAME" can be used for a selective CAT using * or ? if required. If no device number is given then the last drive used is catalogued. 1.4 LOAD @ and SAVE @ as valid alternative to READ AT and WRITE AT. 1.5 LOAD Pn loads the file at Position 'n' on the current disc/sub directory. Section 2. Other Changes 2.1 Change all occurrence of the spelling DISK to read DISC in messages. Section 3. Items To Delete 3.1 FORMAT TO "d2". As most people have only one drive we will give them a copier program on the system disc. Section 4. New Items (Most from MasterDOS) 4.1FORMAT [OVER] d1"DISCNAME"[,tracks] The OVER formats a disc without asking you Yes or No if the disc is already formatted. The tracks if give will over-ride the DVAR variable, as usual add 128 for Double Sided drives. 4.2 Date stamping of files provided user has set up date or hase clock/calendar. No time stamping unless clock fitted. 4.3 Serial (OPENTYPE) files - (not talking about random access here). Valid tags to be IN, OUT, EXP. An error report should be given if the correct file is not found with IN or EXP, or if a file already exists with OUT. The extension EXP is short for EXPand and opens the file to write at the end of existing data. Any filetype can be opened IN. LET A=EOF #n gives 0 if there are characters still to read or 1 if the file is at an end. 4.4 Cut down versions of DSTAT (options 1 & 2) and FSTAT (option 1) as detailed in the MasterDOS manual. 4.5 Provide variables to be copied to SVARs 14 & 15 on boot up. FINAL NOTES. What I seek to do is to make SAMDOS 3 a more logical and intuitive tool for disc users. Quite deliberatly I have not included many of the Masterdos features which are not requires by the average user, this allows Masterdos to still be sold as an upgrade and I feel that FORMAT should still push people in that direction. In most cases the old syntax of commands will still be valid, although the new will have priority over the old. However, because providing two different syntax structures is, in the long term, a waste of space, the manuals will only list the new syntax. Users will be warned that future versions of SAMDOS will not necessarally understand the old SAMDOS 2 syntax and they are therefore advised to use the new at all times. The Spectrum Basic converter provided on the SAMDOS 3 disc should be able to convert most (if not all) programs from PLUS D disc now, because the disc commands are much more compatible. SAMROM V4.0 NOTES FOR CHANGES FROM EXISTING SAM ROM (V3.0). This document lays out the changes required to the SAM ROM version 3.0 to create version 4.0. No priority should be implied by the order given. To be read in conjunction with the notes on changes to create SAMDOS 3. Section 1. Syntax Changes. 1.1Alter following keywords:- GO TO becomes GOTO GO SUB " GOSUB DIR " CAT 1.2 Make the changes to the filename rules as listed in the SAMDOS 3 document. 1.3 With the LPRINT command if a CHR$(27) is encountered then send the next character unaltered. i.e to send the Epson codes to switch on underlined printing you would do:- LPRINT CHR$(27); CHR$(27); CHR$(45); CHR$(27);CHR$(1) In this way there is no need to open a separate channel just to send a limited number of control codes. 1.4 Allow OPEN #3;"t" as well as OPEN #3;"p" Section 2. Other Changes. 2.1 Change character set to an 8*8 one and change default CSIZE to 8,8. Alter defaul graphic offsets. 2.2 Change all occurrence of DISK to DISC in messages. 2.3 Set SVAR 15 default to 0 not 1 2.4 Provide a way for programmers to move cursor through listing even when a line is in editing area. 2.5 Reverse logic of screen blanking so that you have to do a poke to turn ON the feature. 2.6 To improve syntax checking alter procedure calls so that either there has to be a command PROC at the start of each, or there has to be ( and ) around the parameter list - even if it is empty. 2.7 Include as many bug fixes as possible in the new ROM. Notes. Also remove all network code from ROM in order to provide extra space. The exception is to allow a load of an auto-running code file from the master machine, this would be the NOS for the slave computer. From owner-sam-users@nvg.unit.no Sun Dec 1 14:55:45 1996 Message-Id: <1.5.4.32.19961201144939.008f094c@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Dec 1996 14:49:39 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 305 Lines: 13 At 16:57 29/11/96 +0000, you wrote: >Status: > >Hmmm.... CLI on top of a bios. BASIC on top of a CLI. >GUI on top of the CLI (or BASIC CLI). SOunds horribly >PCish... can we not whittle things down to just >one layer somehow? (Hierarchy is nice, but on a 6MHz >8-bit machine?!). No we can't. Simon From owner-sam-users@nvg.unit.no Sun Dec 1 14:55:54 1996 Message-Id: <1.5.4.32.19961201144951.008f8c54@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Dec 1996 14:49:51 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 303 Lines: 12 At 21:29 30/11/96 GMT, you wrote: > >By its filetype of course. Why would you need an extension when the >filetype is already there? because when you do DIR 1! you don't get filetype info. As has been said on this list many times before, filetypes are a *BAD* idea for future extensibility. Simon From owner-sam-users@nvg.unit.no Sun Dec 1 14:56:05 1996 Message-Id: <1.5.4.32.19961201144945.008f642c@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Dec 1996 14:49:45 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SOS magic TAB & CLI - Reply Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 658 Lines: 23 At 15:15 30/11/96 -0500, you wrote: >But Basic IS our operating system, it IS our CLI, why would we need to change >that? Because the current syntax of DIR="/tijet/jfo/asf":LOAD"jdoijawf" is incredibly nasty. Because BASIC is not an operating system, and it was never meant to be. Because you can't extend the DOS at the moment because all the file handling syntax is BASIC driven, so you need masses of code to make what should be a simple change. Because any system where you have to do: 10 CLEAR 32767:OPEN TO 10 20 LOAD "code" CODE 32768 to load a machine code program without possibly overwriting existing data is plain WRONG WRONG WRONG. Simon From owner-sam-users@nvg.unit.no Sun Dec 1 14:56:43 1996 Message-Id: <1.5.4.32.19961201144935.008f9dc4@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Dec 1996 14:49:35 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re:SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2932 Lines: 72 At 16:44 29/11/96 +0000, you wrote: >In your design, there is no level at which REAL programs can run. We >need a level where we can do whatever we want to memory and the >processors, without the need to conform to the rules and regulations that >GUI or CLI may impose. This Level 1 is where fast games and demos etc. >should live. Hang on... hang on... "real programs"??? "where we can do whatever we want to the memory and the processors, without the need to conform to the rules and regs"???? Come off it... there's nothing wrong with having a mechanism for memory allocation. If people go too crazy in low-level accessing, then we're going to have the problems we've got with the SAM now. If done right, it won't slow down a thing... >The GUI should be a fairly high level abstraction. Not a low one, this can >only slow things down. Infact, there is no need for the GUI system to be ^^^^^^^^^^^^ not necessarily. >'loaded' at all if all you want to do it SAMbasic or low level stuff. It >would just take up memory and needlessly withstrict you -we don't want >another Mac! ^^^^^^^ as I put in my design, the GUI is only loaded if applicable to the current application. >True, It would be nice to run SAMSON basic in a window of the GUI in terms >of file sharing and multitasking but Basic is not FOR multasking, and >with the brilliant NOS functions living within SAMSONbasic file sharing >would not be a proplem, even if there is any call for it. We don't realy >want to run more than one Basic program at once. *YOU* don't want to run more than one BASIC program at once, you mean. That's very closeminded thinking. >No, C should be the main programming language living on top of the GUI. Fair enough. But that shouldn't stop people from using BASIC. [snip] >I don't understand quite what is ment here, My point is that in the >existing SAMbasic/DOS combination, the basic can USE the files that the >DOS MANIPULATES without the need to swap into using what is in effect a >different language (whether this is by opening another window or using >strange shell commands). A raw DOS is a bit pointless and is only ever >usefull to move arround files and subdirectories. IT DOES NOT ACTUALY DO >ANYTHING! Basic does, it has POWER. There is little point in splitting the ^^^^^^^ balderdash. >two. The GUI would have power because of its applications. You cannot >write progams in a raw DOS. Nor should you be able to. The reason for separating the DOS from the BASIC is to make it all a lot more flexible. Name *ONE* reason that the SAM's current BASIC/DOS structure is a good one. And name *any* reasons why separating the two is a bad move. [snip] >>but the *good* stuff (file handling) seems to be all at the BASIC level, >>where there's no interface to it outside of writing a BASIC program. > >>Simon > >This is what hook codes are supposed to be for!!! And this is what they don't currently do. Simon From owner-sam-users@nvg.unit.no Sun Dec 1 14:56:44 1996 Message-Id: <1.5.4.32.19961201144943.008fe39c@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Dec 1996 14:49:43 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1079 Lines: 28 At 15:15 30/11/96 -0500, you wrote: >>I must admit never understanding the point in a raw DOS without any >>programming language around it (as found on TRCs for example). The whole >>point of having the data in the first place is to COMPUTE with and on it. >>Why access it from an environment that can not compute? >Put so well I could not think of anything to add. > >My point exactly. That's not what a DOS is though. A DOS is a method of accessing files. Programming languages (such as BASIC) call the DOS to use the file system in a transparent way. BASIC should not be a part of the DOS, and vice versa. Stick a CLI on top of the DOS, and you have an easy file-access system. Stick BASIC on top of it and you can manipulate your files using BASIC. Stick Machine Code on top of the DOS, and you can access files easily. Simon ps. I think the problem here is that people are very used to the way the SAM does things, and have no idea what a DOS, BIOS, CLI, programming language etc are, and what part they play. On the SAM, they're all mashed together in a nasty way. From owner-sam-users@nvg.unit.no Sun Dec 1 14:56:44 1996 Message-Id: <1.5.4.32.19961201144946.008f655c@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Dec 1996 14:49:46 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SAMSON Character Set. Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 558 Lines: 17 At 15:48 30/11/96 -0500, you wrote: >Status: > >I would like to propose the adoption of the ANSI character set for SAM. >Codes 0-31 are used as special codes (some peculiar to SAMSON) >Codes 32 to 255 use the standard ANSI set. > >Comments anyone? No problems here... except that a mode should be included to tell the system to interpret those codes as existing SAM codes instead, for compatibility. To do this, we can have a new filetype for BASIC programs on the new system... (or rather, a new entry in the fileheader... I'll explain later). Simon From owner-sam-users@nvg.unit.no Sun Dec 1 14:57:07 1996 Message-Id: <1.5.4.32.19961201144940.008d9590@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Dec 1996 14:49:40 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 420 Lines: 13 At 20:31 29/11/96 GMT, you wrote: >And the BIOS controls a jump table which DOS, Basic and other things can >communicate through, then as you add new bits in the whole power of the >rest is available to you. > >Note. No CLI, no need, DOS/NOS/TOS/FLOS whatever, all there at same time >and at same level, so why duplicate? Please explain further why there's no need for a CLI and what you mean by duplcation. Simon From owner-sam-users@nvg.unit.no Sun Dec 1 14:57:08 1996 Message-Id: <1.5.4.32.19961201144948.008f4bf8@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Dec 1996 14:49:48 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 407 Lines: 22 At 15:48 30/11/96 -0500, you wrote: >I think it should be:- > >LOAD D1"Filename" >or >LOAD H1"Filename" > >That way the device specifier is seperate. But it also screws up the syntax even more, so that you can't have a flexible way of accessing files. Riddle me this: How would you interpret the following command: LOAD a$ where a$ can point to any file on any device, hard-drive or otherwise? Simon From owner-sam-users@nvg.unit.no Sun Dec 1 14:57:19 1996 Message-Id: <1.5.4.32.19961201144949.008d081c@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Dec 1996 14:49:49 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 562 Lines: 18 At 21:15 30/11/96 GMT, you wrote: >Status: > >On Nov 30, 1996 20:59:43, '"Gavin Smith" ' wrote: > > >>Yes, really must agree with Bob here. Can we have LD for load as well >>as the word "load" itself and sv for "save"? That is, if we are gonna >>use the word load at all, and not just type the .exe filename like in >>MS-DOS >-- >No extensions, please, no extensions. Or at least, no extensions which specify which file type the file is. Let extensions be used for the purpose of human readability, and nothing more. Simon From owner-sam-users@nvg.unit.no Sun Dec 1 14:59:46 1996 Date: Sun, 1 Dec 1996 14:57:26 +0000 (GMT) From: "A.S. Collier" X-Sender: asc25@blue.csi.cam.ac.uk To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS In-Reply-To: <961130154846_572422877@emout15.mail.aol.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1659 Lines: 39 On Sat, 30 Nov 1996 BrenchleyR@aol.com wrote: > Oh no, we must never again fall into the trap of allowing programs to just do > what they want - especially when we come to the Z380 and the new graphics > cards. Programmers must never again be allowed to think "I know a better way > of doing that, so I'm going to", that is where half our problems have come > from. > > What we need to do is say "here is an enviroment to run your programs in, and > here are the rules you may work by". > > Bob. Are you serious?? Guidelines yes, rules no. Anything which especially needs to be multitaskable, or runs under the GUI, or whatever, indeed does need to obey certain conventions. But what has been suggestted is a seperate level, which does not involve the GUI or the CLI. But if we are to ever have a chance of writing a game like DOOM or some other really fast, intensive application, the program has got to have close-to absolute control over the computer. If a programmer DOES know a better way round some problem, why stop him from using it? It makes no sense to deliberately restrict the programs in this way. Our advantage is that, once developed, our processor and graphics cards will become more-or-less standard. If a trick works on one SamSon it will work on the next, unlike PCs which have a multitude of 'standard' formats. If there are future developments, it is the programmer's responsibility to keep their software up to date - after all, it will be mostly games and (dare I say it) demos which use this level; any serious applications will be running under the usual operating system, and therefore immune. And what problems? Andrew From owner-sam-users@nvg.unit.no Sun Dec 1 15:06:40 1996 Message-Id: <1.5.4.32.19961201150033.0090c97c@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Dec 1996 15:00:33 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Proposed Changes to DOS and ROM Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 5372 Lines: 163 At 09:41 01/12/96 -0500, you wrote: >SAMDOS V3.0 >Section 1. Syntax Changes. >1.1 Disc device numbers within LOAD; SAVE; MERGE etc. Drive numbers are to be >specified outside of the filename in the same way as used by both the >DISCiPLE and PLUS D, i.e. >LOAD d1[;]"FILENAME" ..... >SAVE d1[;]"FILENAME" ..... >etc. Nope... this is old +D syntax, and should have died as such. It only exists as it's the only way that was possible to bodge the DOS to work with Spectrum BASIC. My reasons are detailed in a previous message. >1.3 Filename extensions are not allowed. If say ERASE "*.BAS" was typed it >should produce the message 'INVALID FILENAME' because there are one or more >characters between the * and the " at the end of the filename. Bad idea. It's handy to be able to use extensions to separate files into classes. >1.4 CAT to replace DIR. The token will print as CAT, therefore any program >saved under SAMDOS 2 will have all its DIRs come up as CATs. If DIR is typed >at the keyboard then CAT will appear in the listing. WHYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY? Give *ONE* good reason for doing so. >1.4 LOAD @ and SAVE @ as valid alternative to READ AT and WRITE AT. +D syntax... >1.5 LOAD Pn loads the file at Position 'n' on the current disc/sub directory. +D syntax again. Fond of the +D are you? > >Section 2. Other Changes >2.1 Change all occurrence of the spelling DISK to read DISC in messages. Dubious. >Section 3. Items To Delete > >3.1 FORMAT TO "d2". As most people have only one drive we will give them a >copier program on the system disc. Good idea. >Section 4. New Items (Most from MasterDOS) > >4.1FORMAT [OVER] d1"DISCNAME"[,tracks] The OVER formats a disc without >asking you Yes or No if the disc is already formatted. The tracks if give >will over-ride the DVAR variable, as usual add 128 for Double Sided drives. Good idea. >4.2 Date stamping of files provided user has set up date or hase >clock/calendar. No time stamping unless clock fitted. OK. >4.3 Serial (OPENTYPE) files - (not talking about random access here). Valid >tags to be IN, OUT, EXP. An error report should be given if the correct file >is not found with IN or EXP, or if a file already exists with OUT. The >extension EXP is short for EXPand and opens the file to write at the end > of existing data. Any filetype can be opened IN. LET A=EOF #n gives 0 if >there are characters still to read or 1 if the file is at an end. Sounds okay to me. >4.4 Cut down versions of DSTAT (options 1 & 2) and FSTAT (option 1) as >detailed in the MasterDOS manual. Why cut down? >4.5 Provide variables to be copied to SVARs 14 & 15 on boot up. Which ones are they again? >FINAL NOTES. [snip] >In most cases the old syntax of commands will still be valid, although the >new will have priority over the old. However, because providing two different >syntax structures is, in the long term, a waste of space, the manuals will >only list the new syntax. Users will be warned that future versions of SAMDOS >will not necessarally understand the old SAMDOS 2 syntax and they are >therefore advised to use the new at all times. The "old" syntax is better than your proposed new one, which is just a +D one anyway. >The Spectrum Basic converter provided on the SAMDOS 3 disc should be able to >convert most (if not all) programs from PLUS D disc now, because the disc >commands are much more compatible. And what's the problem with having it so the converter converts +D programs to standard SAM syntax instead? It's perfectly easy to do because of the strangeness of the +D syntax. >SAMROM V4.0 >Section 1. Syntax Changes. > >1.1Alter following keywords:- >GO TO becomes GOTO >GO SUB " GOSUB >DIR " CAT Why? Other than saving 2 bytes? >1.4 Allow OPEN #3;"t" as well as OPEN #3;"p" Which does what? >Section 2. Other Changes. > >2.1 Change character set to an 8*8 one and change default CSIZE to >8,8. Alter defaul graphic offsets. No, the 6,8 character set is very handy. If you can't read it, don't use it and get yourself a better monitor. >2.2 Change all occurrence of DISK to DISC in messages. Cosmetic and dubious. >2.3 Set SVAR 15 default to 0 not 1 Which means? Hang on... is that the escape key one? >2.4 Provide a way for programmers to move cursor through listing even when a >line is in editing area. Why? But that one may be useful... >2.5 Reverse logic of screen blanking so that you have to do a poke to turn ON >the feature. Better screen blanking logic full stop would be better. >2.6 To improve syntax checking alter procedure calls so that either there has >to be a command PROC at the start of each, or there has to be ( and ) around >the parameter list - even if it is empty. I quite like the idea of the parameter list thing... >2.7 Include as many bug fixes as possible in the new ROM. If we can find the bugs :) >Notes. >Also remove all network code from ROM in order to provide extra space. The >exception is to allow a load of an auto-running code file from the master >machine, this would be the NOS for the slave computer. Ummmmmm.... it doesn't take up much space actually. In fact, I don't reckon that you could make a saving more more than about... oooh... 100 bytes by removing it -- namely because it's very highly integrated into the tape load/save system. Simon From owner-sam-users@nvg.unit.no Sun Dec 1 15:08:38 1996 Message-Id: <1.5.4.32.19961201150240.008fe8dc@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 01 Dec 1996 15:02:40 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 194 Lines: 8 At 14:57 01/12/96 +0000, you wrote: >And what problems? Oh, stuff like not being able to upgrade the drive controller to one you can actually buy for a realistic price these days... :) Simon From owner-sam-users@nvg.unit.no Sun Dec 1 15:20:06 1996 Date: Sun, 1 Dec 1996 15:18:28 +0000 (GMT) From: "A.S. Collier" X-Sender: asc25@blue.csi.cam.ac.uk To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS In-Reply-To: <1.5.4.32.19961201150240.008fe8dc@nessie.mcc.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 395 Lines: 18 On Sun, 1 Dec 1996, Simon Cooke wrote: > At 14:57 01/12/96 +0000, you wrote: > >And what problems? > > Oh, stuff like not being able to upgrade the drive controller to one you can > actually buy for a realistic price these days... :) > > Simon Ah yes, but if the hook codes worked, we wouldn't need to write out own routines now, would we? ;) Fair point though. Andrew From owner-sam-users@nvg.unit.no Sun Dec 1 15:59:08 1996 Date: Sun, 1 Dec 1996 15:55:51 GMT Message-Id: <199612011555.PAA22837@pipe1.uk.pipeline.com> To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM From: samsboss@uk.pipeline.com (Samsboss@uk.pipeline.com) Cc: sam-users@nvg.unit.no X-Pipeuser: samsboss X-Pipehub: uk.pipeline.com X-Pipegcos: (Samsboss@uk.pipeline.com) X-Mailer: Pipeline v3.5.0 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 612 Lines: 22 On Dec 01, 1996 15:00:33, 'Simon Cooke ' wrote: >>Also remove all network code from ROM in order to provide extra space. The >>exception is to allow a load of an auto-running code file from the master >>machine, this would be the NOS for the slave computer. > >Ummmmmm.... it doesn't take up much space actually. In fact, I don't reckon >that you could make a saving more more than about... oooh... 100 bytes by >removing it -- namely because it's very highly integrated into the tape >load/save system. > >Simon > Take out all the tape stuff as well. -- Samsboss. From owner-sam-users@nvg.unit.no Sun Dec 1 15:59:08 1996 Date: Sun, 1 Dec 1996 15:55:55 GMT Message-Id: <199612011555.PAA22842@pipe1.uk.pipeline.com> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS From: samsboss@uk.pipeline.com (Samsboss@uk.pipeline.com) Cc: sam-users@nvg.unit.no X-Pipeuser: samsboss X-Pipehub: uk.pipeline.com X-Pipegcos: (Samsboss@uk.pipeline.com) X-Mailer: Pipeline v3.5.0 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1992 Lines: 61 On Dec 01, 1996 14:49:43, 'Simon Cooke ' wrote: [snip] >That's not what a DOS is though. > >A DOS is a method of accessing files. Programming languages (such as BASIC) >call the DOS to use the file system in a transparent way. BASIC should not >be a part of the DOS, and vice versa. > >Stick a CLI on top of the DOS, and you have an easy file-access system. > >Stick BASIC on top of it and you can manipulate your files using BASIC. > >Stick Machine Code on top of the DOS, and you can access files easily. > >Simon > >ps. I think the problem here is that people are very used to the way the SAM >does things, and have no idea what a DOS, BIOS, CLI, programming language >etc are, and what part they play. On the SAM, they're all mashed together in >a nasty way. > Balls.... I know exactly what we don't want, summit like MS-DOS. The words we use are causing the argument here. Now if I get this right, it goes like this: Camp 1. The CLI Tribe. They think that there is a difference between typing summit in on a command line and typing similar commands in the syntax used by Basic. Camp 2. The Basic Tribe. They take the attitude that as Basic is there - all the time - us it. Well I'm sorrrreeee if I put a few noses out of joint - but the Basic tribe win, hands down - in fact no contest. Basic is a set of commands whose syntax is interpreted by the ROM which then calls low level routines to do things. Underneath de Basic is a set of low level routines and drivers that do the work. We only consider DOS not to be part of Basic cos we loads it up when we needs it - it is part of Basic and there is now need to confuse the issue by saying that we need a different syntax called a CLI to handle files - that is just pure BALLS! Yes the low level routines should be accessable from MCode, C and whatever. But that be the low level, not the high-level user interface. -- Samsboss. (By jove I need that.) From owner-sam-users@nvg.unit.no Sun Dec 1 16:33:03 1996 Date: Sun, 1 Dec 1996 16:30:32 +0000 (GMT) From: "A.S. Collier" X-Sender: asc25@blue.csi.cam.ac.uk To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM In-Reply-To: <961201094139_1286190154@emout20.mail.aol.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 5515 Lines: 127 On Sun, 1 Dec 1996 BrenchleyR@aol.com wrote: > 1.3 Filename extensions are not allowed. If say ERASE "*.BAS" was typed it > should produce the message 'INVALID FILENAME' because there are one or more > characters between the * and the " at the end of the filename. ??????????????????????????????????????????????????????????????????????????????! This is a seriously bad idea. Do you want this to be compatible with SamDos or not? > 1.4 CAT to replace DIR. The token will print as CAT, therefore any program > saved under SAMDOS 2 will have all its DIRs come up as CATs. If DIR is typed > at the keyboard then CAT will appear in the listing. No no no no no no > 2.1 Change all occurrence of the spelling DISK to read DISC in messages. Argh. The word disk is not just American, it is used universally in computing. Have you ever seen someone write 'floppy discette?'. No, Always with a K. Are you also as pedantic when you write font? > What I seek to do is to make SAMDOS 3 a more logical and intuitive tool for > disc users. Quite deliberatly I have not included many of the Masterdos > features which are not requires by the average user, this allows Masterdos to > still be sold as an upgrade and I feel that FORMAT should still push people > in that direction. Well, if we're trying to clean up the system by removing the unnecessary handshaking between ROM and RAM-based DOS / BASICs, then we want to make the internal system complete - remember your idea of using SRAM instead of ROM will help us update the software easily. In other words, don't try to clutter up the market by selling a replacement Dos. Which means that useful functions like BACKUP should be included. I would also propose using DISPLAY "file" as an equivalent of MOVE "file" TO #2. > 1.1Alter following keywords:- > GO TO becomes GOTO > GO SUB " GOSUB Any reason? This seems like a pointless effort. > DIR " CAT Look, if you really insist on this, can't we have a flag, and the user chooses the one he prefers? > 1.3 With the LPRINT command if a CHR$(27) is encountered then send the next > character unaltered. i.e to send the Epson codes to switch on underlined > printing you would do:- > > LPRINT CHR$(27); CHR$(27); CHR$(45); CHR$(27);CHR$(1) > > In this way there is no need to open a separate channel just to send a > limited number of control codes. Good idea, but would possibly need slightly more development to allow some other things; eg many CHR$ 27 commands require more than one arbitrary data byte. Of course, you can always open a channel "b" but people might not remember to do that when you've given the easy route. > 1.4 Allow OPEN #3;"t" as well as OPEN #3;"p" Some sort of operator-definable channels area would be nice, and accounts for whatever new devices might be introduced later. But I don't see what "t" would be supposed to do. > 2.2 Change all occurrence of DISK to DISC in messages. Oh dear > 2.5 Reverse logic of screen blanking so that you have to do a poke to turn ON > the feature. And give a sensible time limit (definable?) like three mins instead of 22. And count the mouse as 'use' > 2.6 To improve syntax checking alter procedure calls so that either there has > to be a command PROC at the start of each, or there has to be ( and ) around > the parameter list - even if it is empty. Nah. Unless this makes the OS programming significantly easier, it is a useless effort for the basic programmer. Not even Pascal makes you do that. > 2.7 Include as many bug fixes as possible in the new ROM. Rather hopeful, somebody has to identify and fix the old bugs, not to mention the new ones caused by fiddling about with Andy Wright's code. > Also remove all network code from ROM in order to provide extra space. The > exception is to allow a load of an auto-running code file from the master > machine, this would be the NOS for the slave computer. And add some *real* networking? I nearly managed to get a token ring system working - but the program needed to be in low memory all the time to recieve the data. Not too useful generally, but if the code was in ROM....? Then again, if there is going to be a network it had probably better be a *standard* network, so I can connect it to the PC network around college and send emails? Actually, why do we need to save the small amount of space that network takes up? Wasn't the plan to have a 128K "ROM"? On a more general note: is it really possible to alter the system so dramatically without totally rewriting all the code? It is a big step to mix together the three systems (ROM, DOS and HDOS) and produce one unified, efficient program. I've said this before (in slightly different context) but if we spend time and effort developing this for the SRAM board before the Z380 board arrives, we will be left with an inefficient, 8 bit operating system running on the superior processor, but not using it to the full. (That's if it works properly at all - the memory won't be paged, but the ROM as it is would be expecting that) In an ideal world (yes I know) we would be developing the SRAM board together with the Z380 processor interface. Only then can we develop the software it deserves. Put it this way: no processor we could use would seriously compete with the competition unless we continue to stretch our hardware to the limits. We need the OS to be user friendly, but also efficient and optimised for the right system (And not needlessly restrictive to the m/c programmer). Andrew From owner-sam-users@nvg.unit.no Sun Dec 1 16:38:43 1996 From: Mr P R Walker Message-Id: <9998.199612011636@holly.csv.warwick.ac.uk> Subject: Disc/k To: sam-users@nvg.unit.no Date: Sun, 1 Dec 1996 16:36:41 +0000 (GMT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 113 Lines: 4 Andrew, If when you say "write font" you mean Format magazine, yes he is usually that fussy about the spelling! From owner-sam-users@nvg.unit.no Sun Dec 1 16:41:35 1996 Date: Sun, 1 Dec 1996 16:39:28 +0000 (GMT) From: "A.S. Collier" X-Sender: asc25@blue.csi.cam.ac.uk To: sam-users@nvg.unit.no Subject: Re: Disc/k In-Reply-To: <9998.199612011636@holly.csv.warwick.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 230 Lines: 12 On Sun, 1 Dec 1996, Mr P R Walker wrote: > Andrew, > > If when you say "write font" you mean Format magazine, > yes he is usually that fussy about the spelling! No, I mean the word 'font', as in typeface. Look it up. Andrew From owner-sam-users@nvg.unit.no Sun Dec 1 16:48:00 1996 From: Mr P R Walker Message-Id: <10751.199612011646@holly.csv.warwick.ac.uk> Subject: Re: Disc/k To: sam-users@nvg.unit.no Date: Sun, 1 Dec 1996 16:46:07 +0000 (GMT) In-Reply-To: from "A.S. Collier" at Dec 1, 96 04:39:28 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 206 Lines: 6 > > If when you say "write font" you mean Format magazine, > > yes he is usually that fussy about the spelling! > No, I mean the word 'font', as in typeface. Look it up. I'll take that to mean yes, then. From owner-sam-users@nvg.unit.no Sun Dec 1 17:36:36 1996 Date: Sun, 1 Dec 1996 17:35:08 +0000 (GMT) From: "A.S. Collier" X-Sender: asc25@blue.csi.cam.ac.uk To: sam-users@nvg.unit.no Subject: Re: Disc/k In-Reply-To: <10751.199612011646@holly.csv.warwick.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 403 Lines: 16 On Sun, 1 Dec 1996, Mr P R Walker wrote: > > > If when you say "write font" you mean Format magazine, > > > yes he is usually that fussy about the spelling! > > No, I mean the word 'font', as in typeface. Look it up. > I'll take that to mean yes, then. I think we're talking cross-purposes here. I'm not talking about Format at all. If you spell 'disk' as 'disc', how do you spell 'font'? Andrew From owner-sam-users@nvg.unit.no Sun Dec 1 17:51:30 1996 From: Mr P R Walker Message-Id: <16377.199612011749@holly.csv.warwick.ac.uk> Subject: Re: Disc/k To: sam-users@nvg.unit.no Date: Sun, 1 Dec 1996 17:49:54 +0000 (GMT) In-Reply-To: from "A.S. Collier" at Dec 1, 96 05:35:08 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 253 Lines: 10 > I think we're talking cross-purposes here. I'm not talking about Format at > all. Fair enough. In words of two syllables or less, what /are/ you talking about? :) > If you spell 'disk' as 'disc', how do you spell 'font'? With an 'X', of course. From owner-sam-users@nvg.unit.no Sun Dec 1 18:03:07 1996 Date: Sun, 1 Dec 1996 17:56:04 +0000 (GMT) From: "A.S. Collier" X-Sender: asc25@puce.csi.cam.ac.uk To: Sam-users Subject: Re: Disc/k In-Reply-To: <16377.199612011749@holly.csv.warwick.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 414 Lines: 20 On Sun, 1 Dec 1996, Mr P R Walker wrote: > > I think we're talking cross-purposes here. I'm not talking about Format at > > all. > > Fair enough. In words of two syllables or less, what /are/ you talking > about? :) > > > If you spell 'disk' as 'disc', how do you spell 'font'? > > With an 'X', of course. What operating system are you running? :) Didn't I tell you to look 'font' up? :) Andrew From owner-sam-users@nvg.unit.no Sun Dec 1 18:04:13 1996 From: Mr P R Walker Message-Id: <17151.199612011802@holly.csv.warwick.ac.uk> Subject: Re: Disc/k To: sam-users@nvg.unit.no Date: Sun, 1 Dec 1996 18:02:26 +0000 (GMT) In-Reply-To: from "A.S. Collier" at Dec 1, 96 05:56:04 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 261 Lines: 10 > > With an 'X', of course. > What operating system are you running? :) Currently, twm version: MIT X consortium, R5. :) > Didn't I tell you to look 'font' up? :) Oddly enough, I don't usually take a dictionary with me into the computer room... From owner-sam-users@nvg.unit.no Sun Dec 1 19:05:38 1996 Date: Sun, 1 Dec 1996 14:00:31 -0500 From: BrenchleyR@aol.com Message-Id: <961201140029_1918314136@emout09.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS magic TAB & CLI - Reply Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 978 Lines: 39 In a message dated 01/12/96 14:55:58, you write: > >At 15:15 30/11/96 -0500, you wrote: >>But Basic IS our operating system, it IS our CLI, why would we need to >change >>that? > >Because the current syntax of DIR="/tijet/jfo/asf":LOAD"jdoijawf" >is incredibly nasty. Agreed, we need a PATH command. > >Because BASIC is not an operating system, and it was never meant to be. > Who said? >Because you can't extend the DOS at the moment because all the file handling >syntax is BASIC driven, so you need masses of code to make what should be a >simple change. Yes but when it gets properly intergrated, then we will have no probs. > >Because any system where you have to do: > >10 CLEAR 32767:OPEN TO 10 >20 LOAD "code" CODE 32768 > >to load a machine code program without possibly overwriting existing data is >plain WRONG WRONG WRONG. Not nice I admit, and I'm sure we can find a better way - especially when running an independent bit of machine code. > >Simon > > Bob. From owner-sam-users@nvg.unit.no Sun Dec 1 19:05:42 1996 Date: Sun, 1 Dec 1996 14:00:35 -0500 From: BrenchleyR@aol.com Message-Id: <961201140034_706737689@emout12.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 485 Lines: 17 In a message dated 01/12/96 14:57:42, you write: >>No extensions, please, no extensions. > >Or at least, no extensions which specify which file type the file is. Let >extensions be used for the purpose of human readability, and nothing more. > >Simon > > Agreed, if the only characters you can't use in a filename are ?,* and characters below 32 then what people do with the filename is their own thing. However, the DOS will not do anything with any extensions people use. Bob. From owner-sam-users@nvg.unit.no Sun Dec 1 19:05:47 1996 Date: Sun, 1 Dec 1996 14:00:33 -0500 From: BrenchleyR@aol.com Message-Id: <961201140032_2049592473@emout10.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 313 Lines: 13 In a message dated 01/12/96 14:55:59, you write: >because when you do DIR 1! you don't get filetype info. > >As has been said on this list many times before, filetypes are a *BAD* idea >for future extensibility. > >Simon But you have to have a filetype, how else does the system know what you are doing? Bob. From owner-sam-users@nvg.unit.no Sun Dec 1 19:05:47 1996 Date: Sun, 1 Dec 1996 14:00:35 -0500 From: BrenchleyR@aol.com Message-Id: <961201140033_638829849@emout11.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 898 Lines: 24 In a message dated 01/12/96 14:57:41, you write: >That's not what a DOS is though. > >A DOS is a method of accessing files. Programming languages (such as BASIC) >call the DOS to use the file system in a transparent way. BASIC should not >be a part of the DOS, and vice versa. > >Stick a CLI on top of the DOS, and you have an easy file-access system. > >Stick BASIC on top of it and you can manipulate your files using BASIC. Yes but Basic is an easy way to handle the syntax of DOS commands, so why bother with a CLI? It takes up space and is not needed because Basic is ALWAYS there. What you are objecting to is just the way SAM Basic/MasterDOS does things at the moment. Take a step back and think of the new, seamless, logical, system and you will see that there is no need to talk of seperate CLIs. > >Stick Machine Code on top of the DOS, and you can access files easily. > >Simon Bob. From owner-sam-users@nvg.unit.no Sun Dec 1 19:06:02 1996 Date: Sun, 1 Dec 1996 14:00:37 -0500 From: BrenchleyR@aol.com Message-Id: <961201140037_1152080409@emout13.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1025 Lines: 39 In a message dated 01/12/96 14:57:42, you write: >>I think it should be:- >> >>LOAD D1"Filename" >>or >>LOAD H1"Filename" >> >>That way the device specifier is seperate. > >But it also screws up the syntax even more, so that you can't have a >flexible way of accessing files. > >Riddle me this: > >How would you interpret the following command: > >LOAD a$ > >where a$ can point to any file on any device, hard-drive or otherwise? Well exactly, a$ is a filename, it could be anywhere, but unless tols otherwise the system should look on the current default device (Floppy, Hard, Tape, CD, Network, RAM, something we get in a few years that we don't know anything about now) and follow the current PATH for that device to get the file whose name is stored in a$. Fo some unknown reason, Bruce thought it was a good idea to include the device within the filename string - WRONG. It has no place there, it is a device specifier which (if it is part of the command at all) should be a separate paramiter. > >Simon > > Bob. From owner-sam-users@nvg.unit.no Sun Dec 1 19:06:08 1996 Date: Sun, 1 Dec 1996 14:00:51 -0500 From: BrenchleyR@aol.com Message-Id: <961201140049_1884759577@emout20.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 592 Lines: 17 In a message dated 01/12/96 15:59:09, you write: >We only consider DOS not to be part of Basic cos we loads it up when we >needs it - it is part of Basic and there is now need to confuse the issue >by saying that we need a different syntax called a CLI to handle files - >that is just pure BALLS! > >Yes the low level routines should be accessable from MCode, C and whatever. >But that be the low level, not the high-level user interface. >-- > >Samsboss. S/he has a valid point there, when we have true intergration then there is no need for the duplication a CLI would give. Bob. From owner-sam-users@nvg.unit.no Sun Dec 1 19:06:17 1996 Date: Sun, 1 Dec 1996 14:00:43 -0500 From: BrenchleyR@aol.com Message-Id: <961201140042_1650717721@emout16.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2569 Lines: 59 In a message dated 01/12/96 15:00:08, you write: >Are you serious?? Guidelines yes, rules no. Enough people break the rules to make guidelines not worth the paper they get written on. > >Anything which especially needs to be multitaskable, or runs under the >GUI, or whatever, indeed does need to obey certain conventions. But what >has been suggestted is a seperate level, which does not involve the GUI or >the CLI. > >But if we are to ever have a chance of writing a game like DOOM or some >other really fast, intensive application, the program has got to have >close-to absolute control over the computer. If a programmer DOES know a >better way round some problem, why stop him from using it? It makes no >sense to deliberately restrict the programs in this way. Indeed, why stop him from doing what he wants? Because if we don't then you have the situation you get on the PC where every program thinks IT IS GOD, that it is the only program any sensible person could possible want to use. So of it goes, writing all over the config files of both DOS and/or Windows setting up the machine just for itself without a care in the world fro what went on before it arrived on the scene or what will come after. Bastard though Win95 is (spit, spit) at least it tries to keep programs in check. We though will not have the advantage of masses of hardware and the overload of Win95 to keep things in line - therefore RULES WILL HAVE TO BE MADE. > >Our advantage is that, once developed, our processor and graphics cards >will become more-or-less standard. If a trick works on one SamSon it will >work on the next, unlike PCs which have a multitude of 'standard' formats. >If there are future developments, it is the programmer's responsibility to >keep their software up to date - after all, it will be mostly games and >(dare I say it) demos which use this level; any serious applications will >be running under the usual operating system, and therefore immune. > >And what problems? Disc access (in particular with relation to protection routines). ROM calls (other than through the jump table). Programs that don't check the page allocation table. Programs that don't even check what version of ROM+DOS is loaded. That will do for starters. > > >Andrew > > Ok, we cannot pass a law that will prevent a programmer 'doing his own thing', nor can we prevent him selling his wares to users. However, it would be nice to lay down the rules and then agree that programs that stick to them should have some form of recognized badge awarded. (Just an idea). Bob. > From owner-sam-users@nvg.unit.no Sun Dec 1 19:06:23 1996 Date: Sun, 1 Dec 1996 14:00:48 -0500 From: BrenchleyR@aol.com Message-Id: <961201140047_1717826713@emout17.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 4916 Lines: 152 In a message dated 01/12/96 15:07:06, you write: [CUT] > >Nope... this is old +D syntax, and should have died as such. It only exists >as it's the only way that was possible to bodge the DOS to work with >Spectrum BASIC. My reasons are detailed in a previous message. No, it exists because it is a better syntax. > > [CUT] >Bad idea. It's handy to be able to use extensions to separate files into >classes. Use prefixes then, or use the filetype if we can agree on a syntax. BUT NEVER put anything AFTER the * because it is WRONG. > [CUT] >WHYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY? >Give *ONE* good reason for doing so. Because you CATalogue the directory, you do not produce a DIRectory of the directory. > >>1.4 LOAD @ and SAVE @ as valid alternative to READ AT and WRITE AT. > >+D syntax... True, I liked this when it first went in (about 1992) but I'm not too sue now. > >>1.5 LOAD Pn loads the file at Position 'n' on the current disc/sub >directory. > >+D syntax again. Fond of the +D are you? Yes I am, in many ways its system was a lot more logical. LOAD Pn stands for LOAD the file from Position N in the current directory, on SAM it became LOAD n - n what? n bytes? n cats? > >> [CUT] >>4.4 Cut down versions of DSTAT (options 1 & 2) and FSTAT (option 1) as >>detailed in the MasterDOS manual. > >Why cut down? The intention when this was written was still to market MasterDOS as an upgrade, I doubt that that will now hold true. > >>4.5 Provide variables to be copied to SVARs 14 & 15 on boot up. > >Which ones are they again? Right hand margin for LPRINT (14) and number of line feeds to send after a carrage return (15) These are the two most peoples AUTO file resets. This feature may not be needed in the new system. > [CUT] >The "old" syntax is better than your proposed new one, which is just a +D >one anyway. I hope that after reading this you will now come to change your mind. > >>SAMROM V4.0 >>Section 1. Syntax Changes. >> >>1.1Alter following keywords:- >>GO TO becomes GOTO >>GO SUB " GOSUB >>DIR " CAT > >Why? Other than saving 2 bytes? Because that extra space in GO TO and GO SUB is just about the most annoying thing I've ever come across. > >>1.4 Allow OPEN #3;"t" as well as OPEN #3;"p" > >Which does what? the 't' stands for tokens > >No, the 6,8 character set is very handy. If you can't read it, don't use it >and get yourself a better monitor. Sorry, did not make myself clear, what I hate about the SAM is the F***ING stupid way it got landed with a character set that needed CSIZE 8,9 to give it a clear line of pixels between it and the next. If I lay one thing to rest with the new system it has just GOT to be this. Having to type CSIZE 8,8 just to make the system usable drives me up the wall. So, width is fine by the hight - that WILL change. > CUT > >>2.3 Set SVAR 15 default to 0 not 1 > >Which means? Hang on... is that the escape key one? No that is the number off linefeeds. > >>2.4 Provide a way for programmers to move cursor through listing even when a >>line is in editing area. > >Why? But that one may be useful... When you bring a line down into the editing area (which by the way is one of the things I love about SAM - far less messy than a full screen editor) the cursor keys now only move withing the line. But often you want to refer to another line, so it would be nice to move up and down through the listing as you could on the Spectrum. >[CUT] >Better screen blanking logic full stop would be better. Very true, but no screen blanking is better than what we got. > [CUT] >I quite like the idea of the parameter list thing... Yes, you see if it is done like that then the procedure call prnt() sould pass syntax while prnt a,b,c would fail - and of course in the latter case you have (odds on I would say) left out the i in print. This would allow us at one stroke to cut the number of NOT UNDERSTOOD messages by a very large percentage. Putting PROC at the start of a procedure would be slightly easier on the Basic, but both Nev and I like the () as well. > >>2.7 Include as many bug fixes as possible in the new ROM. > >If we can find the bugs :) True, but MasterDOS and MasterBasic provide some pointers in the bugs they fix. > >>Notes. >>Also remove all network code from ROM in order to provide extra space. The >>exception is to allow a load of an auto-running code file from the master >>machine, this would be the NOS for the slave computer. > >Ummmmmm.... it doesn't take up much space actually. In fact, I don't reckon >that you could make a saving more more than about... oooh... 100 bytes by >removing it -- namely because it's very highly integrated into the tape >load/save system. True, Andy pointed that out to me a couple of years ago. But if we made the TOS/NOS seperate we would save quite a bit I think. > >Simon Thanks for you comments Simon, working hard on a Sunday I see. Bob. From owner-sam-users@nvg.unit.no Sun Dec 1 19:06:41 1996 Date: Sun, 1 Dec 1996 14:00:53 -0500 From: BrenchleyR@aol.com Message-Id: <961201140052_2083146906@emout02.mail.aol.com> To: sam-users@nvg.unit.no Subject: Just a note. Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 173 Lines: 6 Redoing some of the software on my PC over the next few days, if I don't reply to emails right away you will know the reason why. Don't worry, I won't miss anything. Bob. From owner-sam-users@nvg.unit.no Sun Dec 1 19:25:10 1996 From: Mr P R Walker Message-Id: <21840.199612011917@holly.csv.warwick.ac.uk> Subject: Re: Proposed Changes to DOS and ROM To: sam-users@nvg.unit.no Date: Sun, 1 Dec 1996 19:17:42 +0000 (GMT) In-Reply-To: <961201140047_1717826713@emout17.mail.aol.com> from "BrenchleyR@aol.com" at Dec 1, 96 02:00:48 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1481 Lines: 35 > Use prefixes then, or use the filetype if we can agree on a syntax. BUT NEVER > put anything AFTER the * because it is WRONG. Can't be "WRONG", as it's only an opinion. Personally, I don't mind it doing that - Unix does it (I'm getting more used to it), and MS-DOS does it to an extent. It's simply saying "match everything up to this string" - would you allow "??????.BAS"? Why not? It's doing the same thing. > Because you CATalogue the directory, you do not produce a DIRectory of the > directory. Nope, you produce a DIRectory /listing/. Mere words - not really getting us anywhere. > Yes I am, in many ways its system was a lot more logical. LOAD Pn stands for > LOAD the file from Position N in the current directory, on SAM it became LOAD > n - n what? n bytes? n cats? Load the "nth file", which to me seems more logical. > I hope that after reading this you will now come to change your mind. He might have done - I think that those areas of the SamDos syntax are fine. (It's having to use the quotes while loading that catches me out, as well as having to load executables rather than just running them.) > Because that extra space in GO TO and GO SUB is just about the most annoying > thing I've ever come across. SamBasic puts it in, so why worry about it? Some people might love it. :) (I don't especially care either way, to be honest - it just seems to me as though you're changing things merely because you can, rather than because it's needed.) Paul From owner-sam-users@nvg.unit.no Sun Dec 1 19:26:29 1996 From: Mr P R Walker Message-Id: <21955.199612011919@holly.csv.warwick.ac.uk> Subject: Re: SOS NOS and DOS To: sam-users@nvg.unit.no Date: Sun, 1 Dec 1996 19:19:23 +0000 (GMT) In-Reply-To: <961201140032_2049592473@emout10.mail.aol.com> from "BrenchleyR@aol.com" at Dec 1, 96 02:00:33 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 172 Lines: 6 > But you have to have a filetype, how else does the system know what you are > doing? Being as most people here seem very fond of unix, how does that system manage it? From owner-sam-users@nvg.unit.no Sun Dec 1 20:28:29 1996 Message-Id: <199612012011.UAA28687@mail.enterprise.net> From: David Munden To: sam-users Subject: At last Date: Sun, 1 Dec 1996 18:11:27 -0000 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 164 Lines: 6 At last, I`m back up to date with all of my mail. Now I`d better go and get some more. :) _ |_)avid (\/)unden http://homepages.enterprise.net/davidm/index.html From owner-sam-users@nvg.unit.no Sun Dec 1 20:28:30 1996 Message-Id: <199612012011.UAA28661@mail.enterprise.net> From: David Munden To: sam-users Subject: Re: Sam Users List Again (Was: Re: Like a - Reply Date: Sun, 1 Dec 1996 16:40:15 -0000 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 215 Lines: 15 > > Spelling is slightly wrong :) > Whoops :) That`s ok. > It has been changed. Thank you. I`m a bit behind on my mail at the moment. :) _ |_)avid (\/)unden http://homepages.enterprise.net/davidm/index.html From owner-sam-users@nvg.unit.no Sun Dec 1 20:28:30 1996 Message-Id: <199612012011.UAA28666@mail.enterprise.net> From: David Munden To: sam-users Subject: Re: Samson text editor (was Re: SAMSON: b - Reply Date: Sun, 1 Dec 1996 17:28:10 -0000 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 228 Lines: 10 > I had a backlog of 221 messages and was going through them replying > as I went.... I know the feeling well. Nearly up to date again now though. :) _ |_)avid (\/)unden http://homepages.enterprise.net/davidm/index.html From owner-sam-users@nvg.unit.no Sun Dec 1 20:28:30 1996 Message-Id: <199612012011.UAA28672@mail.enterprise.net> From: David Munden To: sam-users Subject: Re: SAMSON ugly? Date: Sun, 1 Dec 1996 17:36:25 -0000 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 374 Lines: 10 > Hmm...I have a Sam with a mouse interface, a printer interface and > soon I will have a hard drive interface, a clock, a two-up and a > Quazar soundcard. I'm going to have to buy a new desk just to put the > cute little white boxes on! And doesn`t it look impressive to people who visit and see? _ |_)avid (\/)unden http://homepages.enterprise.net/davidm/index.html From owner-sam-users@nvg.unit.no Sun Dec 1 20:29:54 1996 Message-Id: <199612012011.UAA28680@mail.enterprise.net> From: David Munden To: sam-users Subject: Re: Sam Users List Again (Was: Re: Like a virgin?) Date: Sun, 1 Dec 1996 17:37:20 -0000 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 297 Lines: 9 > > It is not easy writing with one hand I can tell you. :) > Okay, I'll bite - why are you writing with one hand? (No filthy > answers, please...) Due to a broken humerus, that`s why. Still I`ve got two months off work :) _ |_)avid (\/)unden http://homepages.enterprise.net/davidm/index.html From owner-sam-users@nvg.unit.no Sun Dec 1 20:49:43 1996 Date: Sun, 1 Dec 1996 20:48:14 +0000 (GMT) From: Tim Wells To: sam-users@nvg.unit.no Subject: re: sos nos dos In-Reply-To: <199612010754_MC1-C83-1A7F@compuserve.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 902 Lines: 22 On Sun, 1 Dec 1996, Neville Young wrote: > > Perhaps if we had a table for devices D1 to D99 (255?) which point to > actual devices then D1 could point to DRIVE1 or HARDDRIVE1 or BACKUPTAPE or > NETWORK or matter transporter and in that way the command could be passed > to the driver for the device as the table would also hold the required > entry points into the drivers. It would make the system sooooo much easier > to entend for new hardware. What might be a more interesting idea, and equally easy would be to invert your idea slightly: Have a table for devices D1 to D99, pointing to your actual devices, but also a table for device names, pointing to the D1-D99 table Then you could have: LOAD "D1:XXXX" where D1 => DRIVE1 or LOAD "LeftFloppy:XXXX" LeftFloppy => D1 => DRIVE1 or LOAD "Samantha:XXXX" etc. Perhaps I'm getting a little carried away here. Tim W. From owner-sam-users@nvg.unit.no Sun Dec 1 21:03:59 1996 Date: Sun, 1 Dec 1996 16:02:18 -0500 From: BrenchleyR@aol.com Message-Id: <961201160216_1286230085@emout19.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3987 Lines: 112 In a message dated 01/12/96 16:32:33, you write: [cut] >????????????????????????????????????????????????????????????????????????????? ?! >This is a seriously bad idea. Do you want this to be compatible with >SamDos or not? No, not necessarily. > [cut] >Argh. The word disk is not just American, it is used universally in >computing. Have you ever seen someone write 'floppy discette?'. No, Always >with a K. Are you also as pedantic when you write font? Ah, there you have it. The floppy diskette - but inside it is a disc. > [cut] >Well, if we're trying to clean up the system by removing the unnecessary >handshaking between ROM and RAM-based DOS / BASICs, then we want to make >the internal system complete - remember your idea of using SRAM instead of >ROM will help us update the software easily. In other words, don't try to >clutter up the market by selling a replacement Dos. Which means that >useful functions like BACKUP should be included. I would also propose >using DISPLAY "file" as an equivalent of MOVE "file" TO #2. As I said in another email, this was drawn up quite some time ago, so a lot of it is not now relavent. > >> 1.1Alter following keywords:- >> GO TO becomes GOTO >> GO SUB " GOSUB > >Any reason? This seems like a pointless effort. Because the spaces should not be there. > >> DIR " CAT > >Look, if you really insist on this, can't we have a flag, and the user >chooses the one he prefers? In listings it should be CAT, but as I said type DIR and it will still work. > [cut] > >> 1.4 Allow OPEN #3;"t" as well as OPEN #3;"p" > >Some sort of operator-definable channels area would be nice, and accounts >for whatever new devices might be introduced later. But I don't see what >"t" would be supposed to do. t was what for some unknown reason became p in SAM, it it the tokenized channel which comes from Microdrive, Discovery, DISCiPLE and PLUS D. > >> 2.2 Change all occurrence of DISK to DISC in messages. > >Oh dear > >> 2.5 Reverse logic of screen blanking so that you have to do a poke to turn >ON >> the feature. > >And give a sensible time limit (definable?) like three mins instead of 22. >And count the mouse as 'use' Yep, right on. > >> 2.6 To improve syntax checking alter procedure calls so that either there >has >> to be a command PROC at the start of each, or there has to be ( and ) >around >> the parameter list - even if it is empty. > >Nah. Unless this makes the OS programming significantly easier, it is a >useless effort for the basic programmer. Not even Pascal makes you do >that. See my reply to Simon, it does make the Basic syntax more rigid and therefore easier to parse. > >> 2.7 Include as many bug fixes as possible in the new ROM. > >Rather hopeful, somebody has to identify and fix the old bugs, not to >mention the new ones caused by fiddling about with Andy Wright's code. Lots of the fixes are in MasterDOS and MasterBasic as patches, we just need to put the in the right place to avoid duplication. > [cut] > >On a more general note: is it really possible to alter the system so >dramatically without totally rewriting all the code? It is a big step to >mix together the three systems (ROM, DOS and HDOS) and produce one >unified, efficient program. True, but it has to be done sometime - but maybe not all at once because we can just load new version as we want - no burning eproms. > >I've said this before (in slightly different context) but if we spend time >and effort developing this for the SRAM board before the Z380 board >arrives, we will be left with an inefficient, 8 bit operating system >running on the superior processor, but not using it to the full. (That's >if it works properly at all - the memory won't be paged, but the ROM as >it is would be expecting that) No, you miss the point, this is not the operating system for the Z380, that come much futher down the road. This is one step to giving us the tools to develop the Z380 based system. > [cut] > > >Andrew Bob. From owner-sam-users@nvg.unit.no Sun Dec 1 21:25:49 1996 Date: Sun, 1 Dec 1996 21:24:31 +0000 (GMT) From: Tim Wells To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM In-Reply-To: <961201094139_1286190154@emout20.mail.aol.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 5453 Lines: 148 On Sun, 1 Dec 1996 BrenchleyR@aol.com wrote: > SAMDOS V3.0 > NOTES FOR CHANGES FROM EXISTING SAMDOS 2 > This document lays out the changes required to SAMDOS version 2 to create > SAMDOS version 3. No priority should be implied by the order given. > > Section 1. Syntax Changes. > 1.1 Disc device numbers within LOAD; SAVE; MERGE etc. Drive numbers are to be > specified outside of the filename in the same way as used by both the > DISCiPLE and PLUS D, i.e. > LOAD d1[;]"FILENAME" ..... > SAVE d1[;]"FILENAME" ..... > etc. No - this would make SAMDOS completely incompatible with MasterDos, and restrict drive identifiers to be "d*". > 1.2 Filenames. SAMDOS 3 will allow all characters except '*' and '?' to be > used in a filename. On LOAD, COPY and ERASE operations a '?' may be used as a > wild card to replace any single character in the 10 character filename, '*' > can be used at the end of a partial filename to say match ANY character from > that point on. Neither the '*' or the '?' character can be used in a SAVE and > should give an error of 'Invalid Filename'. How does this vary from the current syntax? > 1.3 Filename extensions are not allowed. If say ERASE "*.BAS" was typed it > should produce the message 'INVALID FILENAME' because there are one or more > characters between the * and the " at the end of the filename. I use filename extensions a lot on the SAM - eg I use Comet, which defaults to saving source as "*.S" and its backups as "*.B". Without extensions, I would have to guess which code files were in fact source files, which data, and which executable. Frequently I do DIR "*.S" to check which files I have on a disk. > 1.4 CAT to replace DIR. The token will print as CAT, therefore any program > saved under SAMDOS 2 will have all its DIRs come up as CATs. If DIR is typed > at the keyboard then CAT will appear in the listing. Personal preference. On the SAM we have now had 7 years of DIR - lets not start messing commands around like that. On a more important note, MasterDOS uses DIR to change directories - CAT="\progs\source" wouldn't make a lot of sense. > 1.4 LOAD @ and SAVE @ as valid alternative to READ AT and WRITE AT. Personal preference - However it would further complicate the LOAD and SAVE syntax, and providing the alternative would take up memory. > Section 2. Other Changes > 2.1 Change all occurrence of the spelling DISK to read DISC in messages. Personal preference - make it customisable! > Section 3. Items To Delete > > 3.1 FORMAT TO "d2". As most people have only one drive we will give them a > copier program on the system disc. Seems sensible - however I was reminded of someone commenting earlier about problems with copying on a one drive AMIGA. Also a copier program is no use if you want to use it within a program. If you take this command out, you might want to replace it with MasterDos's BACKUP. > Section 4. New Items (Most from MasterDOS) All sound OK. > > FINAL NOTES. > The Spectrum Basic converter provided on the SAMDOS 3 disc should be able to > convert most (if not all) programs from PLUS D disc now, because the disc > commands are much more compatible. The converter shouldn't have that much of a problem converting to SAMDOS 2 - weren't Opentype files the only unimplemented aspect? > NOTES FOR CHANGES FROM EXISTING SAM ROM (V3.0). Section 1. Syntax Changes. > > 1.1 Alter following keywords:- > GO TO becomes GOTO > GO SUB " GOSUB > DIR " CAT Personal preference again - I see no real reason for changing. > 1.2 Make the changes to the filename rules as listed in the SAMDOS 3 > document. > > 1.3 With the LPRINT command if a CHR$(27) is encountered then send the next > character unaltered. i.e to send the Epson codes to switch on underlined > printing you would do:- > > LPRINT CHR$(27); CHR$(27); CHR$(45); CHR$(27);CHR$(1) > > In this way there is no need to open a separate channel just to send a > limited number of control codes. Undecided on this one. Where you send one control code, you often want to send many. What does CHR$27 do at the moment - nothing? > 1.4 Allow OPEN #3;"t" as well as OPEN#3;"p" ? > Section 2. Other Changes. > > 2.1 Change character set to an 8*8 one and change default CSIZE to > 8,8. Alter defaul graphic offsets. I rarely run Spectrum Basic programs on the SAM, so don't really care about this one. I do nearly all of my programming in CSIZE 6,8 in Mode 3, so as long as you don't affect that, I'll be happy. > 2.2 Change all occurrence of DISK to DISC in messages. > > 2.3 Set SVAR 15 default to 0 not 1 Get your printer set up correctly! :) > 2.4 Provide a way for programmers to move cursor through listing even when a > line is in editing area. > > 2.5 Reverse logic of screen blanking so that you have to do a poke to turn ON > the feature. I like screen blanking, as I'm sure has stopped nasty things happening to my monitor on more than one occasion. Would be nice if the time limit for blanking could be adjustable though. Why would you want it to default to off anyway? > 2.6 To improve syntax checking alter procedure calls so that either there has > to be a command PROC at the start of each, or there has to be ( and ) around > the parameter list - even if it is empty. No. > 2.7 Include as many bug fixes as possible in the new ROM. Generally a good rule (unless you introduce new ones in the process) Tim W. From owner-sam-users@nvg.unit.no Mon Dec 2 08:42:35 1996 Message-Id: <1.5.4.32.19961202084144.008fd788@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 02 Dec 1996 08:41:44 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 517 Lines: 18 At 07:19 PM 12/1/96 +0000, you wrote: >Status: RO > > >> But you have to have a filetype, how else does the system know what you are >> doing? > >Being as most people here seem very fond of unix, how does that system >manage it? You have magic strings in the files themselves :) If we defined a 4-byte header for each file -- IN the file itself -- that'd sort it out :) (also have /some/ attribute info in the directory so that we can do quick and concise file directories, but not as much as on the SAM). Simon From owner-sam-users@nvg.unit.no Mon Dec 2 08:42:35 1996 Message-Id: <1.5.4.32.19961202084146.008f2058@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 02 Dec 1996 08:41:46 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: re: sos nos dos Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1420 Lines: 35 At 08:48 PM 12/1/96 +0000, you wrote: >Status: RO > >On Sun, 1 Dec 1996, Neville Young wrote: >> >> Perhaps if we had a table for devices D1 to D99 (255?) which point to >> actual devices then D1 could point to DRIVE1 or HARDDRIVE1 or BACKUPTAPE or >> NETWORK or matter transporter and in that way the command could be passed >> to the driver for the device as the table would also hold the required >> entry points into the drivers. It would make the system sooooo much easier >> to entend for new hardware. > >What might be a more interesting idea, and equally easy would be to >invert your idea slightly: >Have a table for devices D1 to D99, pointing to your actual devices, but >also a table for device names, pointing to the D1-D99 table > >Then you could have: > LOAD "D1:XXXX" where D1 => DRIVE1 >or LOAD "LeftFloppy:XXXX" LeftFloppy => D1 => DRIVE1 >or LOAD "Samantha:XXXX" etc. I'd propose a 26*4 byte table (the 4 bytes being so that we can point it to any memory page in the machine). If an entry is null, it doesn't correspond to any device (and reports an error). If it's not, then it points to a handler for a devicename beginning with the letter which that position in the table corresponds to. There's good and bad ways of doing it :) I'm not sure which is best yet... (I'd prefer just a device letter, and a device enumerator for simplicity, but that's just me). Simon From owner-sam-users@nvg.unit.no Mon Dec 2 08:42:42 1996 Message-Id: <1.5.4.32.19961202084139.008f6cb0@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 02 Dec 1996 08:41:39 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Proposed Changes to DOS and ROM Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 5568 Lines: 165 At 02:00 PM 12/1/96 -0500, you wrote: >[CUT] >> >>Nope... this is old +D syntax, and should have died as such. It only exists >>as it's the only way that was possible to bodge the DOS to work with >>Spectrum BASIC. My reasons are detailed in a previous message. > >No, it exists because it is a better syntax. Really? Let's see: LOAD d1;"iojoij" ---> Spectrum parser Spectrum parser throws "syntax" or "nonsense in BASIC" error to RST &08 handler. DISCiPLE / +D catches the RST &08 with its own ROM, which then parses the rest of the line, up until the ":", or the carriage return code. HOWEVER: doing LOAD "d1:10ioie" on the spectrum would involve rewriting the spectrum parser and entailing a massive overhead. You've said elsewhere that file commands should always act on the current drive. Why? BTW: this also puts in the problem of... what happens if someone does: LOAD "ioioio" ? THe thing with the +D syntax is that it causes problems -- namely because *no-one* else does it that way, so users will get confused. >> >> >[CUT] >>Bad idea. It's handy to be able to use extensions to separate files into >>classes. >Use prefixes then, or use the filetype if we can agree on a syntax. BUT NEVER >put anything AFTER the * because it is WRONG. Why is it wrong? Take this filename for example -- sam'sfile.type.source match code result ---------- ------ * sam'sfile.type.source anythingelse.source loadsafiles.type examplefile *.source sam'sfile.type.source anythingelse.source *.type loadsafiles.type *.type.source sam'sfile.type.source *e sam'sfile.type.source examplefile loadsafiles.type anythingelse.source Where's the problem with that? It's easy to code (scan from the end of the filename backwards to the start, matching characters as you go.. a "*" character in this context means "stop matching"). >[CUT] >>WHYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY? >>Give *ONE* good reason for doing so. >Because you CATalogue the directory, you do not produce a DIRectory of the >directory. Actually you LIST a directory -- thus LS on the UNIX systems. CAT actually stands for conCATenate on all other systems. >>>1.4 LOAD @ and SAVE @ as valid alternative to READ AT and WRITE AT. >> >>+D syntax... >True, I liked this when it first went in (about 1992) but I'm not too sue >now. It complicates the syntax parser for the LOAD/SAVE system, for a start :) > >>>1.5 LOAD Pn loads the file at Position 'n' on the current disc/sub >>directory. >> >>+D syntax again. Fond of the +D are you? > >Yes I am, in many ways its system was a lot more logical. LOAD Pn stands for >LOAD the file from Position N in the current directory, on SAM it became LOAD >n - n what? n bytes? n cats? But unless you're told that P means "Position", it could be anything from Peas to Proletariats. Given that both methods require prior knowledge to make sense of the syntax, neither one is better than the other for that reason. Dropping the "P" means: Less to type Less space taken up in the BASIC program You can use variables in the LOAD statement -- such as LOAD alpha -- to choose a program to load. It's another Spectrum Basic bodge -- necessary to overcome the BASIC syntax. Though it must be said that the quick loading method is handy, it should really be ditched right now -- it's not a feature that is compatible with extending the file system, unless the number no-longer applies to directory entries -- and in that case, the numbers will change if you erase a file, or save one into a slot in the middle of the directory. >>> >[CUT] >>>4.4 Cut down versions of DSTAT (options 1 & 2) and FSTAT (option 1) as >>>detailed in the MasterDOS manual. >> >>Why cut down? > >The intention when this was written was still to market MasterDOS as an >upgrade, I doubt that that will now hold true. Ahhhhh.... Actually, I've always thought that it'd be nice to release a version of MasterDOS without the FSTAT and DSTAT commands, RAMdisks and BACKUP command, so that everyone could upgrade to it for nothing... just an idea. >[CUT] >>The "old" syntax is better than your proposed new one, which is just a +D >>one anyway. > >I hope that after reading this you will now come to change your mind. Afraid not... the +D syntax isn't logical -- I still don't see why device specifiers shouldn't be a part of the syntax. To be honest, I'd prefer it if we didn't have them at all -- the unix way of doing it is in a lot of ways more extensible, in that it hides that side of things completely (well, apart from having to MOUNT/UMOUNT devices). [snip] >Because that extra space in GO TO and GO SUB is just about the most annoying >thing I've ever come across. *grins* Oh well. That's just a cosmetic change though. We could do you a custom rom :) >Sorry, did not make myself clear, what I hate about the SAM is the F***ING >stupid way it got landed with a character set that needed CSIZE 8,9 to give >it a clear line of pixels between it and the next. If I lay one thing to rest >with the new system it has just GOT to be this. Having to type CSIZE 8,8 just >to make the system usable drives me up the wall. So, width is fine by the >hight - that WILL change. The thing is though, the Speccy had the same problem. The only way we're going to be able to do that is if and when we get a new graphics card. >Thanks for you comments Simon, working hard on a Sunday I see. *grins* No problem. Simon From owner-sam-users@nvg.unit.no Mon Dec 2 08:43:06 1996 Message-Id: <1.5.4.32.19961202084143.008fcea4@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 02 Dec 1996 08:41:43 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Proposed Changes to DOS and ROM Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 424 Lines: 12 At 07:17 PM 12/1/96 +0000, you wrote: >> I hope that after reading this you will now come to change your mind. > >He might have done - I think that those areas of the SamDos syntax are fine. >(It's having to use the quotes while loading that catches me out, as well >as having to load executables rather than just running them.) Paul -- read with care :) It was Bob who proposed those syntax changes, not myself :) Simon From owner-sam-users@nvg.unit.no Mon Dec 2 09:10:00 1996 Date: Mon, 2 Dec 1996 09:07:50 +0000 (GMT) From: Tim Wells To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS In-Reply-To: <961130151546_1286089037@emout03.mail.aol.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1018 Lines: 27 On Sat, 30 Nov 1996 BrenchleyR@aol.com wrote: > In a message dated 29/11/96 12:20:59, you write: > > >I must admit never understanding the point in a raw DOS without any > >programming language around it (as found on TRCs for example). The whole > >point of having the data in the first place is to COMPUTE with and on it. > >Why access it from an environment that can not compute? > > > >Numb. > > Put so well I could not think of anything to add. > > My point exactly. > It's not an environment that can't compute - merely an environment that computes without Basic. When you use C, you compile the program and end up with some executable code. That code doesn't need Basic at all, but would still compute. Hence for many applications, Basic is irrelevant. That is why a CLI could be useful. This is not an option for the SAM at the moment however - merely something that we are discussing for future use. At the moment, the SAM is too centred around Basic to make separating things pointless. Tim W. From owner-sam-users@nvg.unit.no Mon Dec 2 09:18:14 1996 Date: Mon, 2 Dec 1996 09:14:46 +0000 (GMT) From: Tim Wells To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS In-Reply-To: <199612011555.PAA22842@pipe1.uk.pipeline.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 950 Lines: 32 On Sun, 1 Dec 1996, Samsboss@uk.pipeline.com wrote: > Balls.... > > I know exactly what we don't want, summit like MS-DOS. > The words we use are causing the argument here. > > Now if I get this right, it goes like this: > > Camp 1. The CLI Tribe. > > They think that there is a difference between typing summit in on a command > line and typing similar commands in the syntax used by Basic. The difference is: you don't have all the overheads of Basic when you want to run your programs. > Camp 2. The Basic Tribe. > > They take the attitude that as Basic is there - all the time - us it. But come the day of the GUI, as proclaimed on this list, Basic won't be there all the time. What then? > Well I'm sorrrreeee if I put a few noses out of joint - but the Basic tribe > win, hands down - in fact no contest. It does at the moment on the SAM, but in the future it will be a limitation. > [... Rest Ignored ...] Tim W. From owner-sam-users@nvg.unit.no Mon Dec 2 09:36:23 1996 Message-Id: From: ee31ag@ee.surrey.ac.uk (Andrew M Gale) Subject: Re: SOS NOS and DOS To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 09:34:51 +0000 (GMT) In-Reply-To: <1.5.4.32.19961201144949.008d081c@nessie.mcc.ac.uk> from "Simon Cooke" at Dec 1, 96 02:49:49 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 414 Lines: 12 > >No extensions, please, no extensions. > > Or at least, no extensions which specify which file type the file is. Let > extensions be used for the purpose of human readability, and nothing more. > Or.. allow extensions to be added by programs - for example, a CAD package may save a code file with the extension .CAD and Andrew's Amazing Art Package could save code files with the extension .AAAP etc.. -Andy From owner-sam-users@nvg.unit.no Mon Dec 2 10:05:36 1996 Date: Mon, 2 Dec 1996 11:02:19 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9612021002.AA08342@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: SAMSON Character Set. X-Sun-Charset: US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 298 Lines: 12 > I would like to propose the adoption of the ANSI character set for SAM. > Codes 0-31 are used as special codes (some peculiar to SAMSON) > Codes 32 to 255 use the standard ANSI set. > > Comments anyone? ANSI does not catter for all foreign languages. I say again ISO8859. -Frode > > Bob. > From owner-sam-users@nvg.unit.no Mon Dec 2 10:07:56 1996 Date: Mon, 2 Dec 1996 11:05:32 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9612021005.AA08345@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS X-Sun-Charset: US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 399 Lines: 24 > I think it should be:- > > LOAD D1"Filename" > or > LOAD H1"Filename" > > That way the device specifier is seperate. Would it be too much to ask for if all devices are maped to the filesystem? LOAD "/dev/disk/setup" - a file from disk LOAD "/bin/games/lemmings" - from the harddrive LOAD "/dev/tape/backup.01" - you guessed it OPEN #3,"/dev/mem" READ #3,addr,len etc. > > Bob. > -Frode From owner-sam-users@nvg.unit.no Mon Dec 2 10:08:43 1996 Date: Mon, 2 Dec 1996 11:06:37 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9612021006.AA08348@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS X-Sun-Charset: US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 247 Lines: 8 > Erm. No extensions? I'm confused. Why not??! How do u distinguish > between a code file and a screen file?!? I'm not sure I get your > point... You don't. That's the point. They are both binary files - could fit anywhere in memory. -Frode From owner-sam-users@nvg.unit.no Mon Dec 2 10:32:14 1996 Date: Mon, 2 Dec 1996 11:22:20 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9612021022.AA08355@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM X-Sun-Charset: US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1424 Lines: 35 > 1.2 Filenames. SAMDOS 3 will allow all characters except '*' and '?' to be > used in a filename. On LOAD, COPY and ERASE operations a '?' may be used as a > wild card to replace any single character in the 10 character filename, '*' > can be used at the end of a partial filename to say match ANY character from > that point on. Neither the '*' or the '?' character can be used in a SAVE and > should give an error of 'Invalid Filename'. Why 10 characters? That's very lmiting. > > 1.3 Filename extensions are not allowed. If say ERASE "*.BAS" was typed it > should produce the message 'INVALID FILENAME' because there are one or more > characters between the * and the " at the end of the filename. Why? Extensions are ideal to group files for readability! > > 1.4 CAT to replace DIR. The token will print as CAT, therefore any program > saved under SAMDOS 2 will have all its DIRs come up as CATs. If DIR is typed > at the keyboard then CAT will appear in the listing. > > CAT [device number] gives full listing of the directory. > > CAT [device number]! gives a short listing. > > CAT #n; [device number][!] prints the catalogue to the specified stream. > > CAT [device number][!];"FILENAME" can be used for a selective CAT using * or > ? if required. > > If no device number is given then the last drive used is catalogued. Hardly something to waste time and effort on. Let's go for 'LS' ;) -Frode From owner-sam-users@nvg.unit.no Mon Dec 2 10:36:29 1996 Date: Mon, 2 Dec 1996 11:27:39 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9612021027.AA08358@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS X-Sun-Charset: US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 268 Lines: 11 > > > > But you have to have a filetype, how else does the system know what you are > > doing? > > Being as most people here seem very fond of unix, how does that system > manage it? It doesn't. A file is a file is a file - except when it's a device. :) -Frode From owner-sam-users@nvg.unit.no Mon Dec 2 10:52:51 1996 Date: Mon, 2 Dec 1996 10:47:53 +0000 (GMT) From: "A.S. Collier" X-Sender: asc25@puce.csi.cam.ac.uk To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 656 Lines: 21 On Mon, 2 Dec 1996, Andrew M Gale wrote: > > >No extensions, please, no extensions. > > > > Or at least, no extensions which specify which file type the file is. Let > > extensions be used for the purpose of human readability, and nothing more. > > > > Or.. allow extensions to be added by programs - for example, > a CAD package may save a code file with the extension .CAD > and Andrew's Amazing Art Package could save code files with > the extension .AAAP etc.. > -Andy Agreed, extensions (as they do now) shouldn't actually MEAN anything to the system, but indesputably must be supported in terms of directory handling (as they are now) Andrew From owner-sam-users@nvg.unit.no Mon Dec 2 10:55:08 1996 Date: Mon, 2 Dec 1996 05:51:54 -0500 From: BrenchleyR@aol.com Message-Id: <961202055153_1817755703@emout01.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1534 Lines: 50 In a message dated 02/12/96 09:18:15, you write: >On Sun, 1 Dec 1996, Samsboss@uk.pipeline.com wrote: > >> Balls.... No, no. The accepted phrase is now "small round squashable objects". (little grin) >> >> I know exactly what we don't want, summit like MS-DOS. >> The words we use are causing the argument here. >> >> Now if I get this right, it goes like this: >> >> Camp 1. The CLI Tribe. >> >> They think that there is a difference between typing summit in on a command >> line and typing similar commands in the syntax used by Basic. > >The difference is: you don't have all the overheads of Basic when you >want to run your programs. > >> Camp 2. The Basic Tribe. >> >> They take the attitude that as Basic is there - all the time - us it. > >But come the day of the GUI, as proclaimed on this list, Basic won't be >there all the time. What then? Sorry Tim, but Basic will ALWAYS be there, inside the SRAM. If a line of CLI will do a job then what the hell is wrong with a line of Basic doing the job - no duplication of coding then. I'm sorry, but over the last few weeks I have not seen ONE SINGLE reason why there should be a seperate CLI which cannot simply be countered with "but use the Basic instead". Why have TWO interpreters when one will do? > >> Well I'm sorrrreeee if I put a few noses out of joint - but the Basic tribe >> win, hands down - in fact no contest. > >It does at the moment on the SAM, but in the future it will be a limitation. > >> [... Rest Ignored ...] > >Tim W. > > Bob. From owner-sam-users@nvg.unit.no Mon Dec 2 10:55:09 1996 Date: Mon, 2 Dec 1996 05:51:53 -0500 From: BrenchleyR@aol.com Message-Id: <961202055150_1684376887@emout17.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3437 Lines: 93 In a message dated 01/12/96 21:26:09, you write: >> SAMDOS V3.0 [cut] >No - this would make SAMDOS completely incompatible with MasterDos, and >restrict drive identifiers to be "d*". No, D stands for device, not disc. > [cut] >I use filename extensions a lot on the SAM - eg I use Comet, which >defaults to saving source as "*.S" and its backups as "*.B". Without >extensions, I would have to guess which code files were in fact source >files, which data, and which executable. Frequently I do DIR "*.S" to >check which files I have on a disk. But having anything after the 'match anything wildcard (*)' is no legal. > >> 1.4 CAT to replace DIR. The token will print as CAT, therefore any program >> saved under SAMDOS 2 will have all its DIRs come up as CATs. If DIR is >typed >> at the keyboard then CAT will appear in the listing. > >Personal preference. On the SAM we have now had 7 years of DIR - lets not >start messing commands around like that. On a more important note, >MasterDOS uses DIR to change directories - > >CAT="\progs\source" wouldn't make a lot of sense. The Masterdos use of DIR is dirty, there should be a new PATH command. > >[cut] >> >> 3.1 FORMAT TO "d2". As most people have only one drive we will give them a >> copier program on the system disc. > >Seems sensible - however I was reminded of someone commenting earlier >about problems with copying on a one drive AMIGA. Also a copier program >is no use if you want to use it within a program. If you take this >command out, you might want to replace it with MasterDos's BACKUP. Of course. > >> Section 4. New Items (Most from MasterDOS) > >All sound OK. > [cut] >Undecided on this one. Where you send one control code, you often want to >send many. What does CHR$27 do at the moment - nothing? Correct, nothing. This is just a little amemdment to put back in somthing that was dropped from SAMDOS. > >I rarely run Spectrum Basic programs on the SAM, so don't really care >about this one. I do nearly all of my programming in CSIZE 6,8 in Mode 3, >so as long as you don't affect that, I'll be happy. Fine, as you will have seen from another email, it is only the hight that will change to give us back the 24 line screen. > >Get your printer set up correctly! :) Mine is, to UK standard, as used by the BBC micro and most non-IBM compatible machines until a few years ago. That is that the printer does and auto LF after CR. > [cut] >I like screen blanking, as I'm sure has stopped nasty things happening >to my monitor on more than one occasion. Would be nice if the time limit >for blanking could be adjustable though. Why would you want it to default >to off anyway? Because in most cases it is a pain in the bum that the screen blanks. It is never needed if you use a TV and only needed really if you have a very cheap green-screen monitor. > >> 2.6 To improve syntax checking alter procedure calls so that either there >has >> to be a command PROC at the start of each, or there has >to be ( and ) around >> the parameter list - even if it is empty. > >No. Sorry, but yes, if we ever want to get the Basic working properly, and be able to implement it for the Z380, we have to start tightening the syntax structure so a set of 'rules' can be written that define the language. > >> 2.7 Include as many bug fixes as possible in the new ROM. > >Generally a good rule (unless you introduce new ones in the process) > >Tim W. From owner-sam-users@nvg.unit.no Mon Dec 2 10:55:19 1996 Date: Mon, 2 Dec 1996 05:51:55 -0500 From: BrenchleyR@aol.com Message-Id: <961202055154_1884864183@emout03.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 589 Lines: 15 In a message dated 02/12/96 09:36:28, you write: >Or.. allow extensions to be added by programs - for example, >a CAD package may save a code file with the extension .CAD >and Andrew's Amazing Art Package could save code files with >the extension .AAAP etc.. >-Andy Programs can do what the heck they like with filenames provided that they take responsibility for the outcome. However, a line like ERASE Dn"*.CAD" should not be a legal command - and I don;t care what other systems do or what SAM does at the moment - this is just an illegal structure that should not be allowed. Bob. From owner-sam-users@nvg.unit.no Mon Dec 2 10:56:27 1996 Date: Mon, 2 Dec 1996 05:51:55 -0500 From: BrenchleyR@aol.com Message-Id: <961202055151_1717931319@emout18.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1541 Lines: 41 In a message dated 02/12/96 08:42:45, you write: >>I hope that after reading this you will now come to change your mind. > >Afraid not... the +D syntax isn't logical -- I still don't see why device >specifiers shouldn't be a part of the syntax. To be honest, I'd prefer it if >we didn't have them at all -- the unix way of doing it is in a lot of ways >more extensible, in that it hides that side of things completely (well, >apart from having to MOUNT/UMOUNT devices). But the device number is NOT part of a filename. It has nothing to do with a filename. And I never managed to find out how Bruce came to make it part of the filename. > > >>Sorry, did not make myself clear, what I hate about the SAM is the F***ING >>stupid way it got landed with a character set that needed CSIZE 8,9 to give >>it a clear line of pixels between it and the next. If I lay one thing to >rest >>with the new system it has just GOT to be this. Having to type CSIZE 8,8 >just >>to make the system usable drives me up the wall. So, width is fine by the >>hight - that WILL change. > >The thing is though, the Speccy had the same problem. The only way we're >going to be able to do that is if and when we get a new graphics card. Speccy did not have a problem, the 8x8 character set on the Spectrum worked fine. In fact in a lot of software I have written for SAM I do load the Spectrum character set to avoid capital letters touching each other. > >>Thanks for you comments Simon, working hard on a Sunday I see. > >*grins* No problem. > >Simon > > Bob. From owner-sam-users@nvg.unit.no Mon Dec 2 10:56:28 1996 Date: Mon, 2 Dec 1996 05:51:59 -0500 From: BrenchleyR@aol.com Message-Id: <961202055156_1951973175@emout04.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 514 Lines: 31 In a message dated 02/12/96 10:07:42, you write: > >> I think it should be:- >> >> LOAD D1"Filename" >> or >> LOAD H1"Filename" >> >> That way the device specifier is seperate. > >Would it be too much to ask for if all devices are maped to the >filesystem? > >LOAD "/dev/disk/setup" - a file from disk >LOAD "/bin/games/lemmings" - from the harddrive >LOAD "/dev/tape/backup.01" - you guessed it > >OPEN #3,"/dev/mem" >READ #3,addr,len >etc. > >> >> Bob. >> > > -Frode Pass the sick-bucket please... Bob. From owner-sam-users@nvg.unit.no Mon Dec 2 10:56:36 1996 Date: Mon, 2 Dec 1996 05:51:58 -0500 From: BrenchleyR@aol.com Message-Id: <961202055157_1985527607@emout05.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 449 Lines: 18 In a message dated 02/12/96 10:09:03, you write: >You don't. That's the point. They are both binary files - could >fit anywhere in memory. > > -Frode And the filetype tells the system what to do with the file by default. If I say:- SAVE d1"TEST" SAVE d1"TEST" CODE 40000,1024 SAVE d1"TEST" SCREEN$ Then I would expect three files called TEST on the drive. The system would handle it because there are three different file types involved. Bob. From owner-sam-users@nvg.unit.no Mon Dec 2 11:04:54 1996 X-Authentication-Warning: dcsun4.comp.brad.ac.uk: lwillis owned process doing -bs Date: Mon, 2 Dec 1996 10:59:11 +0000 (GMT) From: Lee Willis To: sam-users@nvg.unit.no Subject: Re: Samson text editor (was Re: SAMSON: bundled software) In-Reply-To: <961127132355_1352719377@emout07.mail.aol.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2355 Lines: 71 On Wed, 27 Nov 1996 BrenchleyR@aol.com wrote: ;>In a message dated 27/11/96 11:01:10, you write: ;> ;>>It can't be that difficult. If you drop the "", you can have two advantages: ;>> ;>>1) You can do ;>> > LOAD foo (instead of LOAD "foo") ;>> ;>>There can be no ambiguty as foo can only be a numeric litral. OK, ;>>a bit more overhead on the ROM routines, but ;> ;>But how do you cope with the device specifier? the command LOAD d1:foo would ;>cause mega problems. Why, we just write the parser so that it will recognize a filename starting with d1:, wouldn't be hard at all. Besides if we were implementing a Unix style system then we could lose this syntax (Admittedly also losing compatability ..) and it could become LOAD /drives/d1/foo Also no problem. Take your pick. And why have a LOAD command anyway, you either want to execute a program or edit it, so you have foo to execute the file and textedit foo to edit it ... ;>> ;>>2) You can say something like: ;>> > bar ;>> ;>>This will plunge the ROM into searching it's internal comands, which ;>>it will not find and then look for procedures to call with that name. ;>>If this does not succede, it leaves control over to the DOS which will ;>>search the path for a program with that name to execute. ;> ;>I would like to see the syntax parsing simplyfied by either:- ;> ;>a) including the command PROC to introduce a call to a procedure ;>or You could have it like Unix and have /basic/foo to pipe the output to a procedure in memory, but this is all going horribly pear-shaped 'coz we're assuming an environment like the one we have now, and I think it'd be better to have a proper CLI environment where you can execute programs that's it. You don't have a program in memory or anything like that so this problem wouldn't exist, ARGH I'm confusing myself, and probably everyone else. If anyone understood this then please try and explain it better for everyone else ... ;>The only problems at the moment are caused by there being SAM ROM, plus DOS, ;>plus MasterBasic, plus HDOS - all needing to have their go at things. One ;>intergrated operating system, with a set of commands that follow rules, will ;>cure that. I agree. Lee. How many Microsoft employees does it take to screw in a light bulb? None, they just make darkness the industry standard! From owner-sam-users@nvg.unit.no Mon Dec 2 11:09:03 1996 Date: Mon, 2 Dec 1996 12:03:52 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9612021103.AA08426@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS X-Sun-Charset: US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 699 Lines: 14 > Sorry Tim, but Basic will ALWAYS be there, inside the SRAM. > If a line of CLI will do a job then what the hell is wrong with a line of > Basic doing the job - no duplication of coding then. I'm sorry, but over the > last few weeks I have not seen ONE SINGLE reason why there should be a > seperate CLI which cannot simply be countered with "but use the Basic > instead". Why have TWO interpreters when one will do? The one simple reason is 'simplicity and efficiency'. BASIC is fine as a programming language, and as such a batch language. But it is no good for manipulating large amounts of files. With it "'s, ;'s, ='s, etc. it's a complete mess to type and to remember. That's why! -Frode From owner-sam-users@nvg.unit.no Mon Dec 2 11:10:21 1996 Message-Id: <1.5.4.32.19961202110636.008e53f8@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 02 Dec 1996 11:06:36 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 573 Lines: 30 At 05:51 AM 12/2/96 -0500, you wrote: >Status: > >In a message dated 02/12/96 10:09:03, you write: > >>You don't. That's the point. They are both binary files - could >>fit anywhere in memory. >> >> -Frode > >And the filetype tells the system what to do with the file by default. > >If I say:- >SAVE d1"TEST" >SAVE d1"TEST" CODE 40000,1024 >SAVE d1"TEST" SCREEN$ > >Then I would expect three files called TEST on the drive. The system would >handle it because there are three different file types involved. > >Bob. But what happens if you do: ERASE "TEST" ? Simon From owner-sam-users@nvg.unit.no Mon Dec 2 11:11:16 1996 Date: Mon, 2 Dec 1996 12:05:25 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9612021105.AA08429@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS X-Sun-Charset: US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 339 Lines: 9 > Programs can do what the heck they like with filenames provided that they > take responsibility for the outcome. However, a line like ERASE Dn"*.CAD" > should not be a legal command - and I don;t care what other systems do or > what SAM does at the moment - this is just an illegal structure that should > not be allowed. Why? -Frode From owner-sam-users@nvg.unit.no Mon Dec 2 12:42:53 1996 Date: Mon, 2 Dec 1996 11:08:39 +0000 (GMT) From: "A.S. Collier" X-Sender: asc25@puce.csi.cam.ac.uk To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS In-Reply-To: <961202055157_1985527607@emout05.mail.aol.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 805 Lines: 32 On Mon, 2 Dec 1996 BrenchleyR@aol.com wrote: > In a message dated 02/12/96 10:09:03, you write: > > >You don't. That's the point. They are both binary files - could > >fit anywhere in memory. > > > > -Frode > > And the filetype tells the system what to do with the file by default. > > If I say:- > SAVE d1"TEST" > SAVE d1"TEST" CODE 40000,1024 > SAVE d1"TEST" SCREEN$ > > Then I would expect three files called TEST on the drive. The system would > handle it because there are three different file types involved. > > Bob. This is silly, BOB! Don't try to have lots of files with one name. If I wanted to load the screen at a specific address, eg so it could be included as part of a machine code program, you would have to do: LOAD d1"TEST" Now, what would your syntax do with that? Andrew From owner-sam-users@nvg.unit.no Mon Dec 2 13:00:52 1996 Message-Id: <32A2C580.2781@math.uni-goettingen.de> Date: Mon, 02 Dec 1996 13:03:12 +0100 From: Slawomir Grodkowski X-Mailer: Mozilla 3.0 (X11; I; OSF1 V3.2 alpha) Mime-Version: 1.0 To: sam-users@nvg.unit.no Subject: Re: SAM BASIC - Comments needed. References: <961130151545_1218993485@emout02.mail.aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 634 Lines: 25 BrenchleyR@aol.com wrote: > > In a message dated 29/11/96 10:37:02, you write: > > >> 1) features they like/use most > > > >I love SamBasic ;-)) > >> > >> 2) features the dislike > > > >I hate MasterBasic .... > >> > >Slawek. > > Any particular reason you 'hate' MasterBasic? > I mean it contains so much that you surely can't hate it all. > > Bob. When YOu write a simple , tiny , and not complicated program , You can use MasterBasic very well , but I try to write more complicated things and MasterBasic is too slow and make all that , what I don't need it to make ( uff , I hope You undestand my poor english ... ) Slawek. From owner-sam-users@nvg.unit.no Mon Dec 2 13:00:52 1996 From: James R Curry Organization: De Montfort University To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 12:09:05 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: SAM BASIC - Comments needed. Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: <3332911082C@sahara.cms.dmu.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 362 Lines: 11 > Any particular reason you 'hate' MasterBasic? > I mean it contains so much that you surely can't hate it all. > > Bob. I don't like ANY programming language where someone has to have bought a copy of the language THEMSELVES to run your programs. -- James R Curry hc95jc@dmu.ac.uk "20 Dollars! Aw, I wanted a peanut.." - Homer Simpson, the Simpsons. From owner-sam-users@nvg.unit.no Mon Dec 2 13:01:48 1996 Date: Mon, 2 Dec 1996 11:13:13 +0000 (GMT) From: "A.S. Collier" X-Sender: asc25@puce.csi.cam.ac.uk To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS In-Reply-To: <961202055154_1884864183@emout03.mail.aol.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 399 Lines: 15 On Mon, 2 Dec 1996 BrenchleyR@aol.com wrote: > However, a line like ERASE Dn"*.CAD" > should not be a legal command - and I don;t care what other systems do or > what SAM does at the moment - this is just an illegal structure that should > not be allowed. I have never in my life read such a complete load of utter rubbish until you started this discussion. Don't be so bl***y stupid. Andrew From owner-sam-users@nvg.unit.no Mon Dec 2 13:04:58 1996 Date: Mon, 2 Dec 1996 11:14:53 +0000 (GMT) From: "A.S. Collier" X-Sender: asc25@puce.csi.cam.ac.uk To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 423 Lines: 23 On Mon, 2 Dec 1996, A.S. Collier wrote: > This is silly, BOB! Don't try to have lots of files with one name. > > If I wanted to load the screen at a specific address, eg so it could be > included as part of a machine code program, you would have to do: > > LOAD d1"TEST" > > Now, what would your syntax do with that? > > Andrew Sorry, I meant: LOAD d1"TEST"CODE someaddress But the question still stands Andrew From owner-sam-users@nvg.unit.no Mon Dec 2 13:04:58 1996 Message-Id: <1.5.4.32.19961202111719.008e7d14@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 02 Dec 1996 11:17:19 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 440 Lines: 13 At 12:05 PM 12/2/96 +0100, you wrote: >> Programs can do what the heck they like with filenames provided that they >> take responsibility for the outcome. However, a line like ERASE Dn"*.CAD" >> should not be a legal command - and I don;t care what other systems do or >> what SAM does at the moment - this is just an illegal structure that should >> not be allowed. > >Why? And not just because of the ERASE Dn"blah" structure ;) Simon From owner-sam-users@nvg.unit.no Mon Dec 2 13:06:32 1996 X-Authentication-Warning: dcsun4.comp.brad.ac.uk: lwillis owned process doing -bs Date: Mon, 2 Dec 1996 11:17:05 +0000 (GMT) From: Lee Willis To: sam-users@nvg.unit.no Subject: Re: SOS magic TAB & CLI - Reply In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 579 Lines: 22 On Thu, 28 Nov 1996, Dan Doore wrote: ;>Surely it would be easier to make a stable OS if you concentrate on making the CLI ;>robust and have an additional programs (such as a BASIC) load *on top* of it instead ;>of being part of it. ;> ;>It's time for the OS to get a divorce from BASIC. ;> This was what I meant in my lasy confused posting ... Cheers Dan ... If only I read all the mails before replying ... Oh well .. Lee. How many Microsoft employees does it take to screw in a light bulb? None, they just make darkness the industry standard! From owner-sam-users@nvg.unit.no Mon Dec 2 13:24:35 1996 From: Gavin Smith Organization: University of Ulster To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 11:35:45 GMT Subject: Re: SOS NOS and DOS Priority: normal X-Mailer: Pegasus Mail for Windows (v2.23) Message-Id: <23B07B65263@smserver1.ulst.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 612 Lines: 11 > Programs can do what the heck they like with filenames provided that they > take responsibility for the outcome. However, a line like ERASE Dn"*.CAD" > should not be a legal command - and I don;t care what other systems do or > what SAM does at the moment - this is just an illegal structure that should > not be allowed. Personally I find file extensions very useful. If I want to delete all the gif files in a given directory, I just type del *.gif (in MS-Dos of course). I don't understand what is so wrong with that. I agree that the file extensions should only be there for human readability though. From owner-sam-users@nvg.unit.no Mon Dec 2 13:29:06 1996 Date: Mon, 2 Dec 1996 11:35:09 +0000 (GMT) From: Justin Skists X-Sender: c93js1@lagrange.cms.dmu.ac.uk To: sam-users@nvg.unit.no Subject: Re: SOS magic TAB & CLI - Reply In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1011 Lines: 26 On Sat, 30 Nov 1996, Tim Wells wrote: > On Fri, 29 Nov 1996, Justin Skists wrote: > > > [some stuff about including SCADS into SAMSON basic] > No. > > This is precisely the road we don't want to go down - adding lots of junk > into the system as standard. Whilst these types of extensions are nice, > they add overheads in terms of ROM space and syntax checking time, etc, and > they are not of universal application. Fine. I was only throwing in some ideas... (Isn't that what this list is for?) It was an idea that's an extension to the GRAB, PUT, SCROLL commands in BASIC which we all know are slow... -- ============================================================================= |Justin Skists (c93js1@dmu.ac.uk) | Don't take life so seriously, | |BSc (Hons) Computer Science, Year 4 | you'll never survive it! | |De Montfort University, Leicester, England | - (C) CamLoRTS 1996 | ============================================================================= From owner-sam-users@nvg.unit.no Mon Dec 2 13:30:55 1996 X-Authentication-Warning: dcsun4.comp.brad.ac.uk: lwillis owned process doing -bs Date: Mon, 2 Dec 1996 11:36:40 +0000 (GMT) From: Lee Willis To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 515 Lines: 18 On Fri, 29 Nov 1996, Andrew M Gale wrote: ;>Hmmm.... CLI on top of a bios. BASIC on top of a CLI. ;>GUI on top of the CLI (or BASIC CLI). SOunds horribly ;>PCish... can we not whittle things down to just ;>one layer somehow? (Hierarchy is nice, but on a 6MHz ;>8-bit machine?!). ;> Erm, but surely we're talking about a machine that _won't_ be 6MHz, 8-bit? Lee. How many Microsoft employees does it take to screw in a light bulb? None, they just make darkness the industry standard! From owner-sam-users@nvg.unit.no Mon Dec 2 13:37:32 1996 Date: Mon, 2 Dec 1996 12:43:31 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9612021143.AA08534@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS X-Sun-Charset: US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 590 Lines: 20 > >You don't. That's the point. They are both binary files - could > >fit anywhere in memory. > > > > -Frode > > And the filetype tells the system what to do with the file by default. > > If I say:- > SAVE d1"TEST" > SAVE d1"TEST" CODE 40000,1024 > SAVE d1"TEST" SCREEN$ > > Then I would expect three files called TEST on the drive. The system would > handle it because there are three different file types involved. That would be very confusion for the user to have it like that. What would happen here if you tried loading the screen to a different location than the screen? -Frode From owner-sam-users@nvg.unit.no Mon Dec 2 13:41:40 1996 Date: Mon, 2 Dec 1996 11:45:38 +0000 (GMT) From: "A.S. Collier" X-Sender: asc25@blue.csi.cam.ac.uk To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM In-Reply-To: <961201160216_1286230085@emout19.mail.aol.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 340 Lines: 14 On Sun, 1 Dec 1996 BrenchleyR@aol.com wrote: [deletia] > No, you miss the point, this is not the operating system for the Z380, that > come much futher down the road. This is one step to giving us the tools to > develop the Z380 based system. > > Bob. I hardly think people will be writing the SamSon system software in Basic. Andrew From owner-sam-users@nvg.unit.no Mon Dec 2 13:41:45 1996 From: James R Curry Organization: De Montfort University To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 11:52:05 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: roms & srams Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: <332E0627DB8@sahara.cms.dmu.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 871 Lines: 20 . > I'm not daunted by computers, but that doesn't mean I want crappy > wordprocessors, and want to use a CLI all the time. I thought the > main reason for wysiwyg wps and proportional fonts is because *we* > want them. > > If we worry too much about what the man in the street wants then > we're going to get nowhere - because there's no way that the > SAM can give them what they expect. Like it or not, we WERE talking about what the man on the street would want, it would be pretty shortsighted to develop this machine into something which non technical minded people will find daunting! OS expansions on plug in ROM chips would be seen like this, and limit the machines sales outside present SAM owners and hardware enthusiasts almost completely. -- James R Curry hc95jc@dmu.ac.uk "20 Dollars! Aw, I wanted a peanut.." - Homer Simpson, the Simpsons. From imc Mon Dec 2 13:46:05 1996 Subject: Re: SOS NOS and DOS To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 13:46:05 +0000 (GMT) In-Reply-To: <961130154847_740167517@emout16.mail.aol.com> from "BrenchleyR@aol.com" at Nov 30, 96 03:48:48 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: 1270 Lines: 31 On Sat, 30 Nov 1996 15:48:48 -0500, BrenchleyR@aol.com said: ic>A raw DOS operates the disk, as its name implies. It provides functions ic>which can be called by machine code programs. The CLI and BASIC are ic>programs which need disk access. Therefore they are implemented on top ic>of DOS, calling DOS functions whenever they need access. A machine code ic>program (which is called from the CLI or from the BASIC) does the same. ic>DOS and BASIC are completely separate entities and should stay separate. ic> ic>This is, incidentally, much like how the +3 is programmed. > Look, for the last time, the CLI is the Basic - unified, as one, combined, > all together. > There is NO VALID reason to seperate them. Firstly, nothing I have said above implies that CLI and BASIC are different (except perhaps for the fact that I named both; try "and/or" instead of "and" and "or" above). Secondly, There IS TOO a valid reason, ner ner na ner ner. Consider the difference between CLI: cd /foo and BASIC: DIR="/foo" rm test ERASE "test" prog x y z OPEN TO 10: LOAD "prog" CODE 32768: CALL 3276 8,x,y,z and then tell me you prefer to do everything in BASIC syntax. imc From imc Mon Dec 2 13:47:44 1996 Subject: Re: SAMSON Character Set. To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 13:47:44 +0000 (GMT) In-Reply-To: <961130154853_1353093725@emout20.mail.aol.com> from "BrenchleyR@aol.com" at Nov 30, 96 03:48:53 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: 351 Lines: 10 On Sat, 30 Nov 1996 15:48:53 -0500, BrenchleyR@aol.com said: > I would like to propose the adoption of the ANSI character set for SAM. > Codes 0-31 are used as special codes (some peculiar to SAMSON) > Codes 32 to 255 use the standard ANSI set. > > Comments anyone? My comment is "What on earth is the ANSI set?". Also, "Stick to ISO8859-1". imc From owner-sam-users@nvg.unit.no Mon Dec 2 13:50:53 1996 Date: Mon, 2 Dec 1996 11:54:28 +0000 (GMT) From: Justin Skists X-Sender: c93js1@lagrange.cms.dmu.ac.uk To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM In-Reply-To: <961201094139_1286190154@emout20.mail.aol.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 787 Lines: 16 On Sun, 1 Dec 1996 BrenchleyR@aol.com wrote: > 1.4 CAT to replace DIR. The token will print as CAT, therefore any program > saved under SAMDOS 2 will have all its DIRs come up as CATs. If DIR is typed > at the keyboard then CAT will appear in the listing. You mean, not only do I get confused with TYPE (in ms-dos) and CAT (which is TYPE for unix), I have to get confused with DIR aswell? -- ============================================================================= |Justin Skists (c93js1@dmu.ac.uk) | Don't take life so seriously, | |BSc (Hons) Computer Science, Year 4 | you'll never survive it! | |De Montfort University, Leicester, England | - (C) CamLoRTS 1996 | ============================================================================= From imc Mon Dec 2 13:55:26 1996 Subject: Re: sos nos dos To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 13:55:26 +0000 (GMT) In-Reply-To: <199612010754_MC1-C83-1A7F@compuserve.com> from "Neville Young" at Dec 1, 96 07:54:17 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: 1050 Lines: 21 On Sun, 1 Dec 1996 07:54:17 -0500, Neville Young said: > Perhaps if we had a table for devices D1 to D99 (255?) which point to > actual devices Possibly, though I don't think you should waste the other 26 letters of the alphabet. In fact, why not make the number the "minor device number", so that "D3:" always means the third "D" (whatever "D" is). So "N3:" might mean the third network station. On the other hand, if you remap N<->D then it might mean the third disk. So you can remap each letter to a different device if you like, and on certain devices such as disks you could keep the ability to rearrange the numbers. Also I much prefer the way CP/M can map "A:" and "B:" to the same drive ("Insert disk for drive B: and press a key") rather than SamDOS's [I almost reversed the last three characters of that name by accident...] insistence that whenever you copy something to the same drive you must be wanting to change the disk. COPY "a:foo" TO "b:" is more intuitive than COPY "foo" TO "*" (especially if you have used MSDOS). imc From owner-sam-users@nvg.unit.no Mon Dec 2 14:01:08 1996 Date: Mon, 2 Dec 1996 12:10:18 +0000 (GMT) From: Justin Skists X-Sender: c93js1@lagrange.cms.dmu.ac.uk To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM In-Reply-To: <21840.199612011917@holly.csv.warwick.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 610 Lines: 16 On Sun, 1 Dec 1996, Mr P R Walker wrote: > (It's having to use the quotes while loading that catches me out, as well > as having to load executables rather than just running them.) New command? RUN "filename" :) -- ============================================================================= |Justin Skists (c93js1@dmu.ac.uk) | Don't take life so seriously, | |BSc (Hons) Computer Science, Year 4 | you'll never survive it! | |De Montfort University, Leicester, England | - (C) CamLoRTS 1996 | ============================================================================= From owner-sam-users@nvg.unit.no Mon Dec 2 14:04:44 1996 From: James R Curry Organization: De Montfort University To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 12:20:38 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: SOS NOS and DOS Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: <3335A3E0DCF@sahara.cms.dmu.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1244 Lines: 35 > >> No extensions, please, no extensions. > >> > >> Samsboss. > > > >Erm. No extensions? I'm confused. Why not??! How do u distinguish > >between a code file and a screen file?!? I'm not sure I get your > >point... > -- > > By its filetype of course. Why would you need an extension when the > filetype is already there? Here's an idea.. Why not have some spare characters in the file entry, not in the filename, in which a string can be stored.. This string could be the filetype for non-standard files.. Therefore if someone writes SAMScribe, a word processor, then the file-type for it's code files could show up as SAMScribe document. This wouldn't need to be entered when loading a file, or copying it, like a DOS file extension, it would just show up in a directory listing so that people would know what the file was for. Advantages - * No irritating file extensions to type in * No limited amount of file types, leaving you with a directory full of CODE files * Directory gives an instant view of what each file is * Easy way to make programs only list their own files when loading/saving -- James R Curry hc95jc@dmu.ac.uk "20 Dollars! Aw, I wanted a peanut.." - Homer Simpson, the Simpsons. From imc Mon Dec 2 14:08:35 1996 Subject: Re: Proposed Changes to DOS and ROM To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 14:08:35 +0000 (GMT) In-Reply-To: <961201094139_1286190154@emout20.mail.aol.com> from "BrenchleyR@aol.com" at Dec 1, 96 09:41:39 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: 3649 Lines: 100 On Sun, 1 Dec 1996 09:41:39 -0500, BrenchleyR@aol.com said: > A very long time ago I produced the following document in order to get > feed-back on proposed changes to create SAM ROM V4 and SAMDOS V3. It now need > a lot more work doing on it but I thought is would give a few people > something to think about in the meantime. Where do we begin?... > Section 1. Syntax Changes. > 1.1 Disc device numbers within LOAD; SAVE; MERGE etc. Drive numbers are to be > specified outside of the filename in the same way as used by both the > DISCiPLE and PLUS D, i.e. > LOAD d1[;]"FILENAME" ..... > SAVE d1[;]"FILENAME" ..... I'll leave this for later as it has its own thread, but suffice to say this is a retrograde step... > 1.3 Filename extensions are not allowed. If say ERASE "*.BAS" was typed it > should produce the message 'INVALID FILENAME' because there are one or more > characters between the * and the " at the end of the filename. Good grief man. You should be improving the wildcard syntax, not cutting it down. I'd like to see any characters allowed after the star (and indeed any number of stars allowed). For instance, DIR "b*r*y" lists Barry and Brenchley but not Bailey or Barton. > 1.4 CAT to replace DIR. Oh yes, a really useful change there then. > 1.4 LOAD @ and SAVE @ as valid alternative to READ AT and WRITE AT. And another. > 1.5 LOAD Pn loads the file at Position 'n' on the current disc/sub directory. Look, there should be no unquoted literals in BASIC. "DEVICE D" was bad enough, but not this! > Section 2. Other Changes > 2.1 Change all occurrence of the spelling DISK to read DISC in messages. What planet are you on?! > Section 4. New Items (Most from MasterDOS) Why incorporate MasterDOS? People can buy it if they want the extra capabilities. > 4.1FORMAT [OVER] d1"DISCNAME"[,tracks] The OVER formats a disc without > asking you Yes or No if the disc is already formatted. The tracks if give > will over-ride the DVAR variable, as usual add 128 for Double Sided drives. This is not from MasterDOS. In MasterDOS the tracks argument specifies the size of the directory. > 4.3 Serial (OPENTYPE) files - (not talking about random access here). Valid > tags to be IN, OUT, EXP. An error report should be given if the correct file > is not found with IN or EXP, or if a file already exists with OUT. The > extension EXP is short for EXPand and opens the file to write at the end > of existing data. Hmm, but that is usually called "Append" not "Expand", and it is non- intuitive to expect me to remember "EXP" if I merely want to open the file for read and write. (I don't know what MasterDOS does here because I've never used it). > What I seek to do is to make SAMDOS 3 a more logical and intuitive tool for > disc users. What you appear to seek to do is make SAMDOS 3 a less logical and intuitive tool for disk users. ^ > LPRINT CHR$(27); CHR$(27); CHR$(45); CHR$(27);CHR$(1) Incidentally, 45 is a printing character (most codes after Esc are) so it doesn't need a 27 before it. > 1.4 Allow OPEN #3;"t" as well as OPEN #3;"p" It presumably means the same? > 2.2 Change all occurrence of DISK to DISC in messages. Grr... > 2.5 Reverse logic of screen blanking so that you have to do a poke to turn ON > the feature. And make it respond to shift keys and reduce the timeout. > Also remove all network code from ROM in order to provide extra space. You'd better put it into SamDOS then! I actually used to use this (now I use the networking from MasterDOS instead, although it is slightly buggy in that you can't select it as the default device to load from). imc From owner-sam-users@nvg.unit.no Mon Dec 2 14:11:44 1996 Date: Mon, 2 Dec 1996 12:23:02 +0000 (GMT) From: Justin Skists X-Sender: c93js1@lagrange.cms.dmu.ac.uk To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS In-Reply-To: <9612021027.AA08358@asmal.edh-net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1503 Lines: 37 On Mon, 2 Dec 1996, Frode Tenneboe wrote: > > > But you have to have a filetype, how else does the system know what you are > > > doing? > > > > Being as most people here seem very fond of unix, how does that system > > manage it? > > It doesn't. A file is a file is a file - except when it's a device. :) Yep.. File is a file.. Even devices act like files.. But, a file can be run (whether script (batch) or compiled program) when it has a x flag in the attributes eg:- -r-xr-xr-x 1 bin bin 90112 May 18 1996 CC dr-xr-xr-x 2 bin bin 1024 Apr 11 1996 X11 -r-xr-xr-x 1 bin bin 106496 Apr 22 1994 adb -r-xr-xr-x 1 bin bin 20480 Apr 22 1994 adjust -r-xr-xr-x 1 bin bin 49152 Jan 10 1996 admin The d means directory.. the next three characters means world can read. world can't write. world can execute. (the next 6 are the same but split up for class of users and the user itself) BTW, my thoughts on SAMDos3: A bit silly... The only reason +D had CAT as the directory listing is because the Speccy never had a DIR key... -- ============================================================================= |Justin Skists (c93js1@dmu.ac.uk) | Don't take life so seriously, | |BSc (Hons) Computer Science, Year 4 | you'll never survive it! | |De Montfort University, Leicester, England | - (C) CamLoRTS 1996 | ============================================================================= From owner-sam-users@nvg.unit.no Mon Dec 2 14:14:15 1996 Message-Id: <1.5.4.32.19961202122704.008f6d20@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 02 Dec 1996 12:27:04 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Proposed Changes to DOS and ROM Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 564 Lines: 28 At 12:10 PM 12/2/96 +0000, you wrote: >Status: > >On Sun, 1 Dec 1996, Mr P R Walker wrote: > >> (It's having to use the quotes while loading that catches me out, as well >> as having to load executables rather than just running them.) > >New command? > >RUN "filename" :) Actually, that does add a certain something to the debate -- whether unwittingly or not :) I'd like to see the possibility of this: 10 INCLUDE "basicprog2",procedurelibrary1 20 INCLUDE "basicprog3",procedurelibrary2 ... 30 EXTPROC procedurelibrary1,procedurename (params) :) Simon From owner-sam-users@nvg.unit.no Mon Dec 2 14:15:28 1996 Message-Id: <199612021319.OAA08031@dxmint.cern.ch> From: Allan Skillman Subject: Re: SOS NOS and DOS To: sam-users@nvg.unit.no Date: Mon, 2 Dec 96 14:19:20 MET In-Reply-To: <961202055153_1817755703@emout01.mail.aol.com>; from "BrenchleyR@aol.com" at Dec 2, 96 5:51 am Mailer: Elm [revision: 70.85] Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3427 Lines: 75 Hello Bob and All > > Sorry Tim, but Basic will ALWAYS be there, inside the SRAM. > If a line of CLI will do a job then what the hell is wrong with a line of > Basic doing the job - no duplication of coding then. I'm sorry, but over the > last few weeks I have not seen ONE SINGLE reason why there should be a > seperate CLI which cannot simply be countered with "but use the Basic > instead". Why have TWO interpreters when one will do? One single reason - accessing the DOS from outside BASIC. Anyone who tried to do this sort of thing with a Spectrum and a microdrive will know it was darn near impossible. The hook codes never did what you wanted and you couldn't call the ROM routines beacuse there were several versions of the ROM. The result was that everyone rewrote the code to access the drive directly and wasted even more memory, not to mention the problems of incompatability between different code. Now I'll admit that this is not such a big problem with the SAM, at least there is a hook code to load a block of code into memory (Something like LOAD CODE was impossible with the Interface I hook codes!). But a lot of the stuff you really want to do for say the standard library in C is just not there. For example, imagine trying to code the C function fopen() from ANSI C the syntax is FILE *fopen(const char *path, const char *mode) (fopen returns a pointer to a 'stream') Now this is v.close to the BASIC OPEN #stream;" But this form of i/o is NOT part of the low level DOS, it is part of the BASIC interface to the DOS - THIS IS TOTALLY WRONG. Even worse the storage for the streams is also part of BASIC - it should be part of the DOS. Otherwise an MC program can screw up a resident BASIC program. What most people in the list who are in favour of a 'CLI' mean is not purely the line interface it self, but the DOS access underneath. Let me give you a nice example of what I'm, getting at from the BBC OS. In BBC basic you had BASIC commands such as LOAD, SAVE, CHAIN etc - these are equivalent to the SAM's But you also had OS (as opposed to BASIC) commands all prefixed with a * *LOAD, *SAVE *FX etc etc These were hooks straight into the OS (including the DOS). This way of doing things had several advantages, including 1) expandability - New features couldn't be added to the BBC system without a BASIC upgrade, just by adding extra * commands eg ROM access, new languages new filing systems etc etc. 2) The OS can be accessed directly from assembler (and other languages by calling the OS routines (ie OSCLI) Note that although the BBC did have a CLI (the *LOAD etc routines above), all the features of the system could be used in the SAM, even if the CLI was not. Allan +--------------------------------------------------------------------------+ | Now available! XCoupe, the one and only SAM Coupe emulator | | *** http://www.hep.ucl.ac.uk/~ajs/xcoupe *** | +------------------------------+-------------------------------------------+ | Allan Skillman | "There are five flavours of resons, the | | HEPP Group | elementary particles of magic : up, down, | | University College London | sideways, sex-appeal and peppermint." | | Email : ajs@hep.ucl.ac.uk | - Terry Pratchett (Lords and Ladies) | +------------------------------+-------------------------------------------+ From owner-sam-users@nvg.unit.no Mon Dec 2 14:20:19 1996 From: James R Curry Organization: De Montfort University To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 12:35:40 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Proposed Changes to DOS and ROM Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: <3339A57680F@sahara.cms.dmu.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 709 Lines: 21 > >>Also remove all network code from ROM in order to provide extra space. > The > >>exception is to allow a load of an auto-running code file from the master > > >>machine, this would be the NOS for the slave computer. > > > >Ummmmmm.... it doesn't take up much space actually. In fact, I don't > reckon > >that you could make a saving more more than about... oooh... 100 bytes by > >removing it -- namely because it's very highly integrated into the tape > >load/save system. > > > >Simon > Take out all the tape stuff as well. Eeeekk!! NOOOOOOOOOOOOO! Surely not. Leave it in. -- James R Curry hc95jc@dmu.ac.uk "20 Dollars! Aw, I wanted a peanut.." - Homer Simpson, the Simpsons. From owner-sam-users@nvg.unit.no Mon Dec 2 14:21:36 1996 Date: Mon, 2 Dec 1996 12:32:18 +0000 (GMT) From: Tim Paveley To: sam-users@nvg.unit.no Subject: Unix File Permissions (was: Re: SOS NOS and DOS) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1268 Lines: 28 On Mon, 2 Dec 1996, Justin Skists wrote: > Yep.. File is a file.. Even devices act like files.. > But, a file can be run (whether script (batch) or compiled program) when > it has a x flag in the attributes eg:- > > -r-xr-xr-x 1 bin bin 90112 May 18 1996 CC > dr-xr-xr-x 2 bin bin 1024 Apr 11 1996 X11 > -r-xr-xr-x 1 bin bin 106496 Apr 22 1994 adb > -r-xr-xr-x 1 bin bin 20480 Apr 22 1994 adjust > -r-xr-xr-x 1 bin bin 49152 Jan 10 1996 admin > > The d means directory.. the next three characters means world can read. > world can't write. world can execute. (the next 6 are the same but split > up for class of users and the user itself) just to be picky, it's the last 3 that are world read/write/exe :) the first 3 (okay 2-4) are infact the owners permissions. Slightly important when your trying to make sure that no-one else on your system can write to your files, or for making sure people can actually read your web pages ;) Tim ....@/ .........................................................................@/ Unc - Tim Paveley - http://dplinux.sund.ac.uk/~unc/ Staff of the Monochrome BBS - http://www.mono.org/ Owner of a Sam Coupe - http://www.mono.org/~unc/Coupe/ From owner-sam-users@nvg.unit.no Mon Dec 2 14:27:46 1996 Date: Mon, 2 Dec 1996 12:36:42 +0000 (GMT) From: Tim Paveley To: sam-users@nvg.unit.no Subject: Wildcards (was: Re: SOS NOS and DOS) In-Reply-To: <961202055154_1884864183@emout03.mail.aol.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1110 Lines: 25 On Mon, 2 Dec 1996 BrenchleyR@aol.com wrote: > Programs can do what the heck they like with filenames provided that they > take responsibility for the outcome. However, a line like ERASE Dn"*.CAD" > should not be a legal command - and I don;t care what other systems do or > what SAM does at the moment - this is just an illegal structure that should > not be allowed. Urm, surely if we are dealing with wild cards a * means 'match 0 to infinity characters', thus "*.CAD" is valid. If not then it should be, and we should be allowed to use any valid regular expressions. How else am I supposed to delete all my files ending with the characters .BAK (I'm not calling it an extension, but a convienent system for naming my back up files) other than to delete the all one at a time. ? matches 1 character doesn't it (or does it also match no characters) Tim ....@/ .........................................................................@/ Unc - Tim Paveley - http://dplinux.sund.ac.uk/~unc/ Staff of the Monochrome BBS - http://www.mono.org/ Owner of a Sam Coupe - http://www.mono.org/~unc/Coupe/ From owner-sam-users@nvg.unit.no Mon Dec 2 14:32:34 1996 Date: Mon, 2 Dec 1996 13:42:18 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9612021242.AA08627@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS X-Sun-Charset: US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 908 Lines: 23 > > It doesn't. A file is a file is a file - except when it's a device. :) > > Yep.. File is a file.. Even devices act like files.. > But, a file can be run (whether script (batch) or compiled program) when > it has a x flag in the attributes eg:- In all practical sense, yes, but they have a special sort of filetype associated with them.... > > -r-xr-xr-x 1 bin bin 90112 May 18 1996 CC > dr-xr-xr-x 2 bin bin 1024 Apr 11 1996 X11 > -r-xr-xr-x 1 bin bin 106496 Apr 22 1994 adb > -r-xr-xr-x 1 bin bin 20480 Apr 22 1994 adjust > -r-xr-xr-x 1 bin bin 49152 Jan 10 1996 admin > > The d means directory.. the next three characters means world can read. > world can't write. world can execute. (the next 6 are the same but split > up for class of users and the user itself) Well, it's actaully the other way around... -Frode From owner-sam-users@nvg.unit.no Mon Dec 2 14:33:11 1996 Message-Id: <199612021323.OAA01352@mailserv.caiw.nl> From: Robert van der Veeke To: sam-users Subject: Re: SOS NOS and DOS Date: Tue, 3 Dec 1996 02:23:35 +0100 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 328 Lines: 9 Some wild idea? ;) You could color-code your file-names in the CLI, lets say white for programs, yellow for MC, blue for Screen-files (Gif, PXC, BMP, Screen$ ect.), red for files that has no application attached to it ect. Robert van der Veeke AKA RJV Graphics [rjvveeke@caiw.nl] Ben je getikt joh? Nee ik gebruik kabelfoon. From owner-sam-users@nvg.unit.no Mon Dec 2 14:43:38 1996 From: James R Curry Organization: De Montfort University To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 12:57:13 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: SOS NOS and DOS Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: <333F61435ED@sahara.cms.dmu.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 611 Lines: 13 > Programs can do what the heck they like with filenames provided that they > take responsibility for the outcome. However, a line like ERASE Dn"*.CAD" > should not be a legal command - and I don;t care what other systems do or > what SAM does at the moment - this is just an illegal structure that should > not be allowed. WHY????? For gods sake, give the user the power! If the user WANTS to delete all files that end with .CAD then the user should be able to delete all files that end .CAD! -- James R Curry hc95jc@dmu.ac.uk "20 Dollars! Aw, I wanted a peanut.." - Homer Simpson, the Simpsons. From owner-sam-users@nvg.unit.no Mon Dec 2 14:57:37 1996 Date: Mon, 2 Dec 1996 13:57:45 +0000 (GMT) From: Justin Skists X-Sender: c93js1@cantor.cms.dmu.ac.uk To: sam-users@nvg.unit.no Subject: Re: SAMSON Character Set. In-Reply-To: <9612021347.AA01303@boothp2.ecs.ox.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 983 Lines: 22 On Mon, 2 Dec 1996 Ian.Collier@comlab.ox.ac.uk wrote: > On Sat, 30 Nov 1996 15:48:53 -0500, BrenchleyR@aol.com said: > > I would like to propose the adoption of the ANSI character set for SAM. > > Codes 0-31 are used as special codes (some peculiar to SAMSON) > > Codes 32 to 255 use the standard ANSI set. > > > > Comments anyone? > > My comment is "What on earth is the ANSI set?". Also, "Stick to ISO8859-1". ANSI is a bit like the SAM set but with the control codes (slightly different) under chr(32). Has things like pretty colors, and chr(128 to 255) as extended "graphics" -- ============================================================================= |Justin Skists (c93js1@dmu.ac.uk) | Don't take life so seriously, | |BSc (Hons) Computer Science, Year 4 | you'll never survive it! | |De Montfort University, Leicester, England | - (C) CamLoRTS 1996 | ============================================================================= From owner-sam-users@nvg.unit.no Mon Dec 2 15:36:34 1996 From: Mr P R Walker Message-Id: <2398.199612021432@lupin.csv.warwick.ac.uk> Subject: Re: SOS NOS and DOS To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 14:32:53 +0000 (GMT) In-Reply-To: <9612021027.AA08358@asmal.edh-net> from "Frode Tenneboe" at Dec 2, 96 11:27:39 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 337 Lines: 13 > > > > > > > > But you have to have a filetype, how else does the system know what you are > > > doing? > > > > Being as most people here seem very fond of unix, how does that system > > manage it? > > It doesn't. A file is a file is a file - except when it's a device. :) I was actually thinking more of the "x" attribute. :) From owner-sam-users@nvg.unit.no Mon Dec 2 15:57:45 1996 Date: Mon, 2 Dec 1996 13:55:27 +0000 (GMT) From: Justin Skists X-Sender: c93js1@cantor.cms.dmu.ac.uk To: sam-users@nvg.unit.no Subject: Re: Unix File Permissions (was: Re: SOS NOS and DOS) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 856 Lines: 22 On Mon, 2 Dec 1996, Tim Paveley wrote: > just to be picky, it's the last 3 that are world read/write/exe :) > the first 3 (okay 2-4) are infact the owners permissions. Yes.. Well.. I couldn't remember off hand at the time so I made an estimated guess... i prefer to think of files and files.. not bother with type.. and let the name tell the user what it is... eg. nice_picture.b_carlisle_in_summer.tiff isn't going to be a Wordperfect for Unix file.. -- ============================================================================= |Justin Skists (c93js1@dmu.ac.uk) | Don't take life so seriously, | |BSc (Hons) Computer Science, Year 4 | you'll never survive it! | |De Montfort University, Leicester, England | - (C) CamLoRTS 1996 | ============================================================================= From imc Mon Dec 2 16:03:30 1996 Subject: Re: SOS NOS and DOS To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 16:03:30 +0000 (GMT) In-Reply-To: <199612021319.OAA08031@dxmint.cern.ch> from "Allan Skillman" at Dec 2, 96 02:19:20 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: 1564 Lines: 31 On Mon, 2 Dec 96 14:19:20 MET, Allan Skillman said: > One single reason - accessing the DOS from outside BASIC. Anyone who tried > to do this sort of thing with a Spectrum and a microdrive will know it was > darn near impossible. The hook codes never did what you wanted and you > couldn't call the ROM routines beacuse there were several versions of the > ROM. The result was that everyone rewrote the code to access the drive > directly and wasted even more memory, not to mention the problems of > incompatability between different code. > Now I'll admit that this is not such a big problem with the SAM, at least > there is a hook code to load a block of code into memory (Something like > LOAD CODE was impossible with the Interface I hook codes!). You have this reversed. The microdrive hook codes are quite useful and I'm fairly sure you can do LOAD CODE. I wrote lots of microdrive utilities without duplicating ROM code (as far as I know there were only two different ROMs and I coded programs so that they knew the addresses in both wherever appropriate). Plus3DOS is even better in this regard, though having to page bank 7 in is a bit of a pain sometimes. On the other hand, the Sam hook codes don't actually work and even if they did they would be of rather limited use. > 1) expandability - New features couldn't be added to the BBC system without ^^^^^^^^ > a BASIC upgrade, just by adding extra * commands eg ROM access, new > languages new filing systems etc etc. Typo? imc From owner-sam-users@nvg.unit.no Mon Dec 2 16:08:41 1996 Date: Mon, 2 Dec 1996 09:59:45 -0500 From: Neville Young <106166.1560@compuserve.com> Subject: sos magig tab To: sam users Message-Id: <199612020959_MC1-C88-ED6A@compuserve.com> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 349 Lines: 21 >>Because the current syntax of DIR="/tijet/jfo/asf":LOAD"jdoijawf" >>is incredibly nasty. >Agreed, we need a PATH command. This tat only esists because of the desire to reuse existing keywords and give then new meanings. just MAKE A NEW KEYWORD eg. CD CHDIR PATH PIP TWAT frogspawn&poo Its only a bleeding word. Nev (Sorry I've had a bad day) From owner-sam-users@nvg.unit.no Mon Dec 2 16:08:43 1996 Date: Mon, 2 Dec 1996 09:59:39 -0500 From: Neville Young <106166.1560@compuserve.com> Subject: proposed changes to the universe as we know it. To: sam users Message-Id: <199612020959_MC1-C88-ED68@compuserve.com> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 7769 Lines: 128 >A very long time ago I produced the following document in order to get feed-back on proposed changes to create SAM ROM V4 and SAMDOS V3. It now need a lot more work doing on it but I thought is would give a few people something to think about in the meantime. >Bob.. >SAMDOS V3.0 >NOTES FOR CHANGES FROM EXISTING SAMDOS 2 This document lays out the changes required to SAMDOS version 2 to create SAMDOS version 3. No priority should be implied by the order given. >Section 1. Syntax Changes. >1.1 Disc device numbers within LOAD; SAVE; MERGE etc. Drive numbers are to be specified outside of the filename in the same way as used by both the DISCiPLE and PLUS D, i.e. >LOAD d1[;]"FILENAME" ..... >SAVE d1[;]"FILENAME" ..... >etc. Bollocks! this is duff +D syntax to force a RST 8. >Allow d1,d2 etc, or d* (*=last drive used). Where possible the old syntax will remain but the new syntax will have priority. i.e. LOAD d2"D1:FRED" will look on drive 2 for a file called D1:FRED. The [;] before the open quotes of the filename may be required if a drive number is given as a variable. I don't think you should be allowed to refer to a device at all! Only the name by which it is known eg. have disks labeled "system" " usr" "data" then use LOAD "SYSTEM:/myprog" OPEN "DATA:/myfile" etc etc >1.2 Filenames. SAMDOS 3 will allow all characters except '*' and '?' to be used in a filename. On LOAD, COPY and ERASE operations a '?' may be used as a wild card to replace any single character in the 10 character filename, '*' can be used at the end of a partial filename to say match ANY character from that point on. Neither the '*' or the '?' character can be used in a SAVE and should give an error of 'Invalid Filename'. I quite like LOAD "SYSTEM:/u*/s*e/^m*e$" and if you can't handle regular expressions then type it in full. >1.3 Filename extensions are not allowed. If say ERASE "*.BAS" was typed it should produce the message 'INVALID FILENAME' because there are one or more characters between the * and the " at the end of the filename. Why ever not? OK the .BAS does NOT mean it is a file of type basic. But I like to group things by suffix. >1.4 CAT to replace DIR. The token will print as CAT, therefore any program saved under SAMDOS 2 will have all its DIRs come up as CATs. If DIR is typed at the keyboard then CAT will appear in the listing. A rose by any other name would smell as sweet. how about ls ? >CAT [device number] gives full listing of the directory. No! CAT >CAT [device number]! gives a short listing. POO. CAT -l >CAT #n; [device number][!] prints the catalogue to the specified stream. HA. CAT | lpr >CAT [device number][!];"FILENAME" can be used for a selective CAT using * or ? if required. BAH. CAT >If no device number is given then the last drive used is catalogued. No. Use the specified current default drive. >1.4 LOAD @ and SAVE @ as valid alternative to READ AT and WRITE AT. BOLLOCKS >>>> OPEN "SYSMEM,"r+". Any program reading and writing raw sectors should have it's bits chopped off. >1.5 LOAD Pn loads the file at Position 'n' on the current disc/sub directory. Oh yeah!! LOAD P429763 You gets lots of files on hard drives. Type the F88King file name you idle bastards >Section 2. Other Changes >2.1 Change all occurrence of the spelling DISK to read DISC in messages. BUT DISK IS CORRECT (if we can't agree lets call it DASD) >Section 3. Items To Delete >3.1 FORMAT TO "d2". As most people have only one drive we will give them a copier program on the system disc. OK. (bet that surprised ya) >Section 4. New Items (Most from MasterDOS) >4.1FORMAT [OVER] d1"DISCNAME"[,tracks] The OVER formats a disc without asking you Yes or No if the disc is already formatted. The tracks if give will over-ride the DVAR variable, as usual add 128 for Double Sided drives. No. Format should be a seperate loadable program. Why take up rom space for something you do so rarely. >4.2 Date stamping of files provided user has set up date or hase clock/calendar. No time stamping unless clock fitted. OK >4.3 Serial (OPENTYPE) files - (not talking about random access here). Valid tags to be IN, OUT, EXP. An error report should be given if the correct file is not found with IN or EXP, or if a file already exists with OUT. The extension EXP is short for EXPand and opens the file to write at the end of existing data. Any filetype can be opened IN. LET A=EOF #n gives 0 if there are characters still to read or 1 if the file is at an end. Shuttle cocks! If we're going to have modes of opening then make real words to describe them EXP what the hell do you think SAMSON is a 48K speccy? >4.4 Cut down versions of DSTAT (options 1 & 2) and FSTAT (option 1) as detailed in the MasterDOS manual. No. >4.5 Provide variables to be copied to SVARs 14 & 15 on boot up. Who says SVARS will exist. and any way if SAMSON can only handle EPSON printers I don't want one. >FINAL NOTES. >What I seek to do is to make SAMDOS 3 a more logical and intuitive tool for disc users. Quite deliberatly I have not included many of the Masterdos features which are not requires by the average user, this allows Masterdos to still be sold as an upgrade and I feel that FORMAT should still push people in that direction. What a load of cack. Love Nev. >In most cases the old syntax of commands will still be valid, although the new will have priority over the old. However, because providing two different syntax structures is, in the long term, a waste of space, the manuals will only list the new syntax. Users will be warned that future versions of SAMDOS will not necessarally understand the old SAMDOS 2 syntax and they are therefore advised to use the new at all times. >The Spectrum Basic converter provided on the SAMDOS 3 disc should be able to convert most (if not all) programs from PLUS D disc now, because the disc commands are much more compatible. >SAMROM V4.0 >NOTES FOR CHANGES FROM EXISTING SAM ROM (V3.0). This document lays out the changes required to the SAM ROM version 3.0 to create version 4.0. No priority should be implied by the order given. To be >read in conjunction with the notes on changes to create SAMDOS 3. >Section 1. Syntax Changes. >1.1Alter following keywords:- >GO TO becomes GOTO >GO SUB " GOSUB >DIR " CAT >1.2 Make the changes to the filename rules as listed in the SAMDOS 3 document. >1.3 With the LPRINT command if a CHR$(27) is encountered then send the next character unaltered. i.e to send the Epson codes to switch on underlined printing you would do:- >LPRINT CHR$(27); CHR$(27); CHR$(45); CHR$(27);CHR$(1) >In this way there is no need to open a separate channel just to send a limited number of control codes. >1.4 Allow OPEN #3;"t" as well as OPEN #3;"p" >Section 2. Other Changes. >2.1 Change character set to an 8*8 one and change default CSIZE to 8,8. Alter defaul graphic offsets. >2.2 Change all occurrence of DISK to DISC in messages. >2.3 Set SVAR 15 default to 0 not 1 >2.4 Provide a way for programmers to move cursor through listing even when a line is in editing area. >2.5 Reverse logic of screen blanking so that you have to do a poke to turn ON the feature. >2.6 To improve syntax checking alter procedure calls so that either there has to be a command PROC at the start of each, or there has to be ( and ) around the parameter list - even if it is empty. >2.7 Include as many bug fixes as possible in the new ROM. >Notes. >Also remove all network code from ROM in order to provide extra space. The exception is to allow a load of an auto-running code file from the master machine, this would be the NOS for the slave computer. From imc Mon Dec 2 16:10:49 1996 Subject: Re: Proposed Changes to DOS and ROM To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 16:10:49 +0000 (GMT) In-Reply-To: from "A.S. Collier" at Dec 1, 96 04:30:32 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: 1200 Lines: 27 On Sun, 1 Dec 1996 16:30:32 +0000 (GMT), A.S. Collier said: > Well, if we're trying to clean up the system by removing the unnecessary > handshaking between ROM and RAM-based DOS / BASICs, then we want to make > the internal system complete - remember your idea of using SRAM instead of > ROM will help us update the software easily. In other words, don't try to > clutter up the market by selling a replacement Dos. This is probably a separate issue from the Samson operating system; that is, aren't we just discussing "Sam" DOS at the moment? > I would also propose > using DISPLAY "file" as an equivalent of MOVE "file" TO #2. Well not really as MOVE "file" TO #2 isn't that useful really (especially with the bug that leaves the file open if you break in). On the other hand you could install "less" as standard... :-) > > LPRINT CHR$(27); CHR$(27); CHR$(45); CHR$(27);CHR$(1) > Good idea, but would possibly need slightly more development to allow some > other things; eg many CHR$ 27 commands require more than one arbitrary > data byte. Each data byte gets a separate 27 under this scheme; the 27s themselves are not transmitted. imc From imc Mon Dec 2 16:12:34 1996 Subject: Re: Disc/k To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 16:12:34 +0000 (GMT) In-Reply-To: from "A.S. Collier" at Dec 1, 96 05:35:08 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: 192 Lines: 6 On Sun, 1 Dec 1996 17:35:08 +0000 (GMT), A.S. Collier said: > If you spell 'disk' as 'disc', how do you spell 'font'? Um, how many different ways are there to spell 'font'? 'Phaunte'? imc From imc Mon Dec 2 16:28:50 1996 Subject: Re: proposed changes to the universe as we know it. To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 16:28:50 +0000 (GMT) In-Reply-To: <199612020959_MC1-C88-ED68@compuserve.com> from "Neville Young" at Dec 2, 96 09:59:39 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: 7 On Mon, 2 Dec 1996 09:59:39 -0500, Neville Young said: > >Allow d1,d2 etc, or d* (*=last drive used). Where possible the old syntax will remain but the new syntax will have priority. i.e. LOAD d2"D1:FRED" will look on drive 2 for a file called D1:FRED. The [;] before the open quotes of the filename may be required if a drive number is given as a variable. > I don't think you should be allowed to refer to a device at all! Who removed all the carriage returns from Bob's message? Very hard to read! imc From imc Mon Dec 2 16:32:01 1996 Subject: Re: SOS NOS and DOS To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 16:32:01 +0000 (GMT) In-Reply-To: <961201140037_1152080409@emout13.mail.aol.com> from "BrenchleyR@aol.com" at Dec 1, 96 02:00:37 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: 636 Lines: 17 On Sun, 1 Dec 1996 14:00:37 -0500, BrenchleyR@aol.com said: > Fo some unknown reason, Bruce thought it was a good idea to include the > device within the filename string - WRONG. It has no place there, it is a > device specifier which (if it is part of the command at all) should be a > separate paramiter. Says who? Of course the device should be part of the name (inasmuch as there is a device at all). Next you'll be saying that the directory in which the file resides has no place in the file name! Is this or is it not a valid MSDOS command? more < C:\TEXT\README Is the device allowed as part of the filename? YES! imc From owner-sam-users@nvg.unit.no Mon Dec 2 16:32:48 1996 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 02 Dec 1996 15:20:39 +0000 From: Dan Doore To: sam-users@nvg.unit.no Subject: Kernel Saunders (Was: re; doc sos toss) Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 676 Lines: 24 > I think we should go more like unix where we have a > system kernel. Programs, cli, basic, etc make calls > to the kernel and if required the kernel makes calls > to the device driver routines. > > I think this would resolve a lot of the discussions > about DOS CLI GUI BASIC etc. If we had a nice sterile kernal which could just be trapped from the DOS or CLI or GUI then problem solved. This is pretty much what I had in mind except the CLI was the lowest layer, or in light of the kernel idea, have the CLI running as an 'executive' program instead of a user program - Multi tasking here we come :) :) However I'm still a brave in the 'CLI Tribe' *laughs* Dan. From owner-sam-users@nvg.unit.no Mon Dec 2 16:35:23 1996 From: Mr P R Walker Message-Id: <2031.199612021428@lupin.csv.warwick.ac.uk> Subject: Re: Proposed Changes to DOS and ROM To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 14:28:49 +0000 (GMT) In-Reply-To: from "Justin Skists" at Dec 2, 96 12:10:18 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 288 Lines: 8 > > (It's having to use the quotes while loading that catches me out, as well > > as having to load executables rather than just running them.) > New command? > RUN "filename" :) Not a bad idea, actually. I'd prefer just to type the filename though, and let the system sort it out. :) From imc Mon Dec 2 16:38:52 1996 Subject: Re: Proposed Changes to DOS and ROM To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 16:38:52 +0000 (GMT) In-Reply-To: <961201160216_1286230085@emout19.mail.aol.com> from "BrenchleyR@aol.com" at Dec 1, 96 04:02:18 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: 947 Lines: 26 On Sun, 1 Dec 1996 16:02:18 -0500, BrenchleyR@aol.com said: > Ah, there you have it. The floppy diskette - but inside it is a disc. Huh? > >> 1.4 Allow OPEN #3;"t" as well as OPEN #3;"p" > t was what for some unknown reason became p in SAM, it it the tokenized > channel which comes from Microdrive, Discovery, DISCiPLE and PLUS D. Tokenized? No, it is the expanded channel (in which tokens are expanded instead of being transmitted directly). T stands for "text", as opposed to "binary". T does not stand for "token" because that doesn't mean anything. [about proc with brackets] > See my reply to Simon, it does make the Basic syntax more rigid and therefore > easier to parse. No, it makes it exactly as easy to parse, because you've got to get to the end of the word and discover no bracket before you claim an error. The only difference is that it detects typos when you type the line in instead of waiting until you run it. imc From owner-sam-users@nvg.unit.no Mon Dec 2 16:39:52 1996 From: Mr P R Walker Message-Id: <2352.199612021432@lupin.csv.warwick.ac.uk> Subject: Re: SOS NOS and DOS To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 14:32:07 +0000 (GMT) In-Reply-To: <961202055154_1884864183@emout03.mail.aol.com> from "BrenchleyR@aol.com" at Dec 2, 96 05:51:55 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 448 Lines: 9 > Programs can do what the heck they like with filenames provided that they > take responsibility for the outcome. However, a line like ERASE Dn"*.CAD" > should not be a legal command - and I don;t care what other systems do or > what SAM does at the moment - this is just an illegal structure that should > not be allowed. Um. Fine, if you want to take five steps back, go ahead. Just don't expect me to be using the finished product, will you? From imc Mon Dec 2 16:40:24 1996 Subject: Re: Proposed Changes to DOS and ROM To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 16:40:24 +0000 (GMT) In-Reply-To: from "A.S. Collier" at Dec 1, 96 04:30:32 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: 391 Lines: 10 On Sun, 1 Dec 1996 16:30:32 +0000 (GMT), A.S. Collier said: [about procs with brackets] > Nah. Unless this makes the OS programming significantly easier, it is a > useless effort for the basic programmer. Not even Pascal makes you do > that. So what? C does make you use the brackets to call a procedure. What's more, it doesn't even give you a syntax error when you miss them out. imc From owner-sam-users@nvg.unit.no Mon Dec 2 16:50:13 1996 From: Mr P R Walker Message-Id: <2626.199612021435@lupin.csv.warwick.ac.uk> Subject: Re: SOS NOS and DOS To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 14:35:03 +0000 (GMT) In-Reply-To: <1.5.4.32.19961202084144.008fd788@nessie.mcc.ac.uk> from "Simon Cooke" at Dec 2, 96 08:41:44 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 616 Lines: 12 > >Being as most people here seem very fond of unix, how does that system > >manage it? > You have magic strings in the files themselves :) If we defined a 4-byte > header for each file -- IN the file itself -- that'd sort it out :) > (also have /some/ attribute info in the directory so that we can do quick > and concise file directories, but not as much as on the SAM). Ah! Correcting myself again, I was meaning the magic string approach rather than +X :) I knew that's how unix sorted shell scripts, I wasn't sure if it took that approach for the other types as well. (Do we need 4 bytes? Would 3 be enough?) From owner-sam-users@nvg.unit.no Mon Dec 2 16:50:29 1996 From: Mr P R Walker Message-Id: <2693.199612021435@lupin.csv.warwick.ac.uk> Subject: Re: Proposed Changes to DOS and ROM To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 14:35:55 +0000 (GMT) In-Reply-To: <1.5.4.32.19961202084143.008fcea4@nessie.mcc.ac.uk> from "Simon Cooke" at Dec 2, 96 08:41:43 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 181 Lines: 8 > Paul -- read with care :) It was Bob who proposed those syntax changes, not Read with care? Why change the habit of a lifetime...? ;) [ I was actually "talking to" Bob ] Paul From imc Mon Dec 2 16:52:58 1996 Subject: Re: Proposed Changes to DOS and ROM To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 16:52:58 +0000 (GMT) In-Reply-To: <1.5.4.32.19961202084139.008f6cb0@nessie.mcc.ac.uk> from "Simon Cooke" at Dec 2, 96 08:41:39 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: 723 Lines: 18 On Mon, 02 Dec 1996 08:41:39 +0000, Simon Cooke said: [pattern matching with a star in the middle] > Where's the problem with that? It's easy to code (scan from the end of the > filename backwards to the start, matching characters as you go.. a "*" > character in this context means "stop matching"). How would this work on, say, "a*b*c"? It's possible to do full matching with "*" in a non-recursive way in about 35 lines of C, because I have included it in "samtools". I have also done it in assembler in the CAT command of 48K Disk BASIC on the +3. It's probably possible to make the code a bit shorter if you use recursion. Full regular expression searching is probably not possible in a non- recursive way. imc From imc Mon Dec 2 17:07:40 1996 Subject: Re: Proposed Changes to DOS and ROM To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 17:07:40 +0000 (GMT) In-Reply-To: <961202055150_1684376887@emout17.mail.aol.com> from "BrenchleyR@aol.com" at Dec 2, 96 05:51:53 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: 546 Lines: 17 On Mon, 2 Dec 1996 05:51:53 -0500, BrenchleyR@aol.com said: > No, D stands for device, not disc. Oh, so N doesn't stand for network and T doesn't stand for tape either then? What nonsense! > The Masterdos use of DIR is dirty, there should be a new PATH command. PATH? What does that word mean? > Because in most cases it is a pain in the bum that the screen blanks. It is > never needed if you use a TV and only needed really if you have a very cheap > green-screen monitor. Well that explains why screen savers are so common then... imc From owner-sam-users@nvg.unit.no Mon Dec 2 17:23:07 1996 Date: Mon, 2 Dec 1996 09:59:51 -0500 From: Neville Young <106166.1560@compuserve.com> Subject: re; doc sos toss To: sam users Message-Id: <199612021000_MC1-C88-ED6B@compuserve.com> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2964 Lines: 87 >That's not what a DOS is though. >A DOS is a method of accessing files. Programming languages (such as BASIC) call the >DOS to use the file system in a transparent way. >BASIC should not be a part of the DOS, and vice versa. D O S Disk Operating System This (I believe) came from the PC world where the operating system kernel and the disk driver routines are more or less integrated. I think we should go more like unix where we have a system kernel. Programs, cli, basic, etc make calls to the kernel and if required the kernel makes calls to the device driver routines. I think this would resolve a lot of the discussions about DOS CLI GUI BASIC etc. (If not sorry) NEV -------------------------------------- >As has been said on this list many times before, filetypes are a *BAD* idea for future extensibility. They are only bad when they are restricted. As I wrote some time ago lets have meaninfil filetypes eg PB = printerbackup CF = codefile BA = basic CO = C object DB = Database and that is only using two characters. Nev ----------------------------------------------- >> what they want - especially when we come to the Z380 and the new graphics >> cards. Programmers must never again be allowed to think "I know a better way >> of doing that, so I'm going to", that is where half our problems have come >> from. >> >> What we need to do is say "here is an enviroment to run your programs in, and >> here are the rules you may work by". >> >> Bob. >Are you serious?? Guidelines yes, rules no. Look it's no problem. If anybody is daft enough to write a program that totally F**ks up the machine by ignoring the operating system then nobody in their right mind is gonna use it or buy it. Can you imagine the reviews" Great program! does everything! but you have to reset the machine to exit losing all data in other programs 2/10. DON'T BUY IT" Nev --------------------------------------------- >> But you have to have a filetype, how else does the system know what you are >> doing? >Being as most people here seem very fond of unix, how does that system manage it? rwsrwxrwx + magic! Nev. ------------------------------------------------ >But if we are to ever have a chance of writing a game like DOOM or some >other really fast, intensive application, the program has got to have >close-to absolute control over the computer. If a programmer DOES know a >better way round some problem, why stop him from using it? It makes no >sense to deliberately restrict the programs in this way. The Cyberdeon knows that programs like this can not run in a multitasking environment. I can not run warcraft2 or dukenukem while the answering machine program is running. I just accept this and run them in a (MS)DOS environment. On Samson programs that whish to bypass the OS and scribble to the screen /memory at will just can not be run alongside others. But as Si said if we get the drivers right then it won't slow the programs down. Nev. From owner-sam-users@nvg.unit.no Mon Dec 2 18:02:14 1996 Date: Mon, 2 Dec 1996 16:44:21 +0000 (GMT) From: Justin Skists X-Sender: c93js1@napier.cms.dmu.ac.uk To: sam-users@nvg.unit.no Subject: re: sos nos dos In-Reply-To: <9612021630.AA17979@turner.cursci.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1220 Lines: 28 On Mon, 2 Dec 1996, Keith Turner wrote: > > Nev suggested: > > Perhaps if we had a table for devices D1 to D99 (255?) which point to > > actual devices then D1 could point to DRIVE1 or HARDDRIVE1 or BACKUPTAPE or > > NETWORK or matter transporter and in that way the command could be passed > > to the driver for the device as the table would also hold the required > > entry points into the drivers. It would make the system sooooo much easier > > to entend for new hardware. > > Cool! A matter transporter. I can't afford to buy one of those, but perhaps > you could upload the schematics to ftp.dcc.uchile.cl in raw PGM format, so I > can build one myself. Will it use the new graphics chip or the Z386? No! I want it in PS format! :) > (Sorry but sometimes this list really does need to be parodied!) I agree... -- ============================================================================= |Justin Skists (c93js1@dmu.ac.uk) | Don't take life so seriously, | |BSc (Hons) Computer Science, Year 4 | you'll never survive it! | |De Montfort University, Leicester, England | - (C) CamLoRTS 1996 | ============================================================================= From owner-sam-users@nvg.unit.no Mon Dec 2 18:52:43 1996 Date: Mon, 2 Dec 1996 16:26:43 +0000 (GMT) From: Justin Skists X-Sender: c93js1@napier.cms.dmu.ac.uk To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM In-Reply-To: <9612021408.AA01349@boothp2.ecs.ox.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 699 Lines: 15 > Hmm, but that is usually called "Append" not "Expand", and it is non- > intuitive to expect me to remember "EXP" if I merely want to open the > file for read and write. (I don't know what MasterDOS does here because > I've never used it). I thought EXP stood for the mathmatical symbol of exponent? -- ============================================================================= |Justin Skists (c93js1@dmu.ac.uk) | Don't take life so seriously, | |BSc (Hons) Computer Science, Year 4 | you'll never survive it! | |De Montfort University, Leicester, England | - (C) CamLoRTS 1996 | ============================================================================= From owner-sam-users@nvg.unit.no Mon Dec 2 18:59:40 1996 Date: Mon, 2 Dec 1996 16:30:13 GMT From: Keith Turner Message-Id: <9612021630.AA17979@turner.cursci.co.uk> To: sam-users@nvg.unit.no Subject: re: sos nos dos Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 723 Lines: 17 Nev suggested: > Perhaps if we had a table for devices D1 to D99 (255?) which point to > actual devices then D1 could point to DRIVE1 or HARDDRIVE1 or BACKUPTAPE or > NETWORK or matter transporter and in that way the command could be passed > to the driver for the device as the table would also hold the required > entry points into the drivers. It would make the system sooooo much easier > to entend for new hardware. Cool! A matter transporter. I can't afford to buy one of those, but perhaps you could upload the schematics to ftp.dcc.uchile.cl in raw PGM format, so I can build one myself. Will it use the new graphics chip or the Z386? (Sorry but sometimes this list really does need to be parodied!) / Message-Id: <9612021658.AA17996@turner.cursci.co.uk> To: sam-users@nvg.unit.no Subject: SAMSON-DOS personality test (long) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3542 Lines: 75 SAMSON-DOS personality test =========================== Some of the suggestions on this list are trying to do away with the essential character of the Sam. I want to take this opportunity to list the endangered quirks of the Sam. 1) Sam has no operating system. ROM BASIC directly supports tapes, much like the Spectrum. Any new hardware (like floppy disk drives) can be made accessible from BASIC by loading BASIC device drivers and BASIC language extensions. Those BASIC drivers are in turn made available to native code running alongside BASIC using hook codes. This allows for fast uniform access to BASIC. BASIC is boss, unless you boot from your application disk. 2) Sam uses 10 character filenames, and MSDOS/CPM-like "DEVICE:" specifiers. This means that any program which cannot be loaded completely into memory and which uses more than one device needs to know what sort of media it is currently recorded on. 3) BASIC maintains file type information where any file is one of a BASIC defined list of types. DOS-like suffixes are purely informative. ---- All of the arguments about CLIs, NOSs, GUIs seem in my opinion to boil down to the question: 1A) Do we add new functionality to BASIC to support new hardware, and leave BASIC as the only low level user interface? 1B) Do we put the core device access routines in a seperate package and run the user's preferred user interface on top of that? 1C) Or do we replace BASIC as the primary user interface with a command line interface that tries to be like other system's CLI's? All of the arguments about device specifiers seem to boil down to the question: 2A) Do we include references to specific hardware in the syntax of BASIC and expect alternative user interfaces to also implement hardware specifiers in some other way? 2B) Do we use abstract filenames which make no explicit reference to the actual device the file resides on? 2C) Or do we invent a uniform file name system which includes the reference to the device in the filename, so that it can be used in any programming language and not just through BASIC? All of the arguments about suffixes seem to boil down to the question: 3A) Do we extend the BASIC file-type list ad infinitum? 3B) Do we get rid of file types altogether and just have homogeneous data files. 3C) Or do we replace the BASIC file-type concept with an extendable file-type specifier, like MS-DOS suffixes (.xxx, e.g. .JPG) or Macintosh creator+type attributes (xxxx/zzzz, e.g. TDRW/JPEG). If most of your answers were A's then, like Sam celebrity Bob Brenchley, you think that the design of the ZX80 as a simple BASIC calculator was elegant cost-effective and simple, and that the Sam should follow in that tradition. If most of your answers were B's then, like Sam celebrity Ian Collier, you think that Unix is the true programmers operating system, and therefore all the superficial features of Unix should be implemented on the Sam, even though the Sam and it's successors are unlikely to ever be able to run something as flexible and powerful as Unix. If most of your answers were C's then, like Sam mystery-man Samsboss, you believe that true computing started with MS-DOS 5 and MS-Windows 3 and that what you really want is a cheap PC, with MS-Office thrown in at a cut price. Joking aside, I happen to think that the most user-friendly answers are the C's, the most programmer friendly answers are the B's and the easiest to actually achieve while retaining backwards compatibility are the A's. / X-Mailer: Novell GroupWise 4.1 Date: Mon, 02 Dec 1996 16:47:29 +0000 From: Dan Doore To: sam-users@nvg.unit.no Subject: Re: E-Tracker music - Reply - Reply - Reply Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1511 Lines: 53 > >heh heh heh > > That sounds like a very evil and devious laugh > indeed Dan! Are you trying to get some competition > going here so that at least someone will do > something to get you a convertor??? ;) Damn, my subtle plans goes ary again! :) > >Chip MODS are (AFAIK) MODS that don't use samples but simple > >waveforms > > I think that's right. I would have put it as such: > mods which have really really crap samples > (waveforms) with just one advantage - they take up > hardly any disc space (that is the /ONLY/ advantage). I've heard a *few* good chip mods, or ones that can be appoximated to a chip mod. Matt Simonds/4Mat wrote some nice, if harsh sounding ones - check out the music on Entro 2 - it's one of his re-hashed by Mike Andrews. The only advantage is that they will *hopefully* be easy to convert by the likes of me... :) > >Stefan's the MOD man, he can do it :))) > > > >HEH HEH HEH > > Evil laugh again - no I will NOT do it! :) *grins* > >Right, I've got a home to go to, seeya. > > Does it include falling down steps and stuff??? ;) Nope, not enough beer consumed, plus I managed to catch the train [1] :)) Dan. +==========================+---------------------------------+ | Dan Doore | dooredj@parliament.uk | | HOC SOC & TOP POD | House of Commons Library | +==========================+---------------------------------+ [1] If you have no idea what is being talked about, you should have come to the Gloucester Show... From owner-sam-users@nvg.unit.no Mon Dec 2 19:26:07 1996 From: Gavin Smith Organization: University of Ulster To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 17:10:37 GMT Subject: Re: SAMSON-DOS personality test (long) Priority: normal X-Mailer: Pegasus Mail for Windows (v2.23) Message-Id: <2409C68141B@smserver1.ulst.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 379 Lines: 9 > If most of your answers were C's then, like Sam mystery-man Samsboss, you > believe that true computing started with MS-DOS 5 and MS-Windows 3 and that > what you really want is a cheap PC, with MS-Office thrown in at a cut price. > / To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM In-Reply-To: <961202055150_1684376887@emout17.mail.aol.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 914 Lines: 19 On Mon, 2 Dec 1996 BrenchleyR@aol.com wrote: > [Screen Blanking] Why would you want it to default to off anyway? > > Because in most cases it is a pain in the bum that the screen blanks. It is > never needed if you use a TV and only needed really if you have a very cheap > green-screen monitor. Having worked with a monitor manufacturer for a short while, I know that screen blanking is much more important than that - that manufacturer refuses to provide guarantees to industrial purchasers of its monitors, unless those purchasers use screen-blanking in their applications. Home use of computers is much less critical, as monitors are normally only used for a few hours a day on average. However, in these applications, it is known that screen-blanking clearly extends monitor life. Therefore, as I don't intend to have to replace my monitor prematurely, I would like to keep screen blanking. Tim W. From owner-sam-users@nvg.unit.no Mon Dec 2 20:08:01 1996 From: Stephen Harding Message-Id: <199612021110.LAA02130@BITS.bris.ac.uk> Subject: SOS LOAD "too long" To: sam-users@nvg.unit.no (sam users) Date: Mon, 2 Dec 1996 11:10:38 +0000 (GMT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 899 Lines: 25 > >I do know > >however that I'm sick of typing load"whatever". Its slow and > >fustrating to have to type that and I just hope that the format for > >loading a program gets shortened. > -- >I don't find the syntax a problem, it is short (compared to some systems >I used in the past) and at least it makes sence. >Samsboss. If you are so sick of it, simply redefing the "F7" key to... LOAD " I have! I load this mod. in most times that I turn the machine on. (I also change some other F keys I don't use into the cursors cos my cursors often chose not to work!) There is no need to keep F7 and F8 as LOAD "" and LOAD "" CODE as no one uses tapes anymore! Yes, seperate TOS from SAMbasic. We must put TOS, DOS (and if we have it NOS) on the ROM equivilant though. Think of all the disC space we would save! YES GREAT PLAN! Change DIR to CAT! And give me my Opus Discovery back! Numb. From owner-sam-users@nvg.unit.no Mon Dec 2 21:40:39 1996 From: Stephen Harding Message-Id: <199612021404.OAA02862@BITS.bris.ac.uk> Subject: SOS Z380 OS? To: sam-users@nvg.unit.no (sam users) Date: Mon, 2 Dec 1996 14:04:21 +0000 (GMT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2573 Lines: 54 > >I've said this before (in slightly different context) but if we spend > >time and effort developing this for the SRAM board before the Z380 > >board arrives, we will be left with an inefficient, 8 bit operating > >system running on the superior processor, but not using it to the full. >Andrew >No, you miss the point, this is not the operating system for the Z380, >that come much futher down the road. This is one step to giving us the >tools to develop the Z380 based system. >Bob. In that case I miss the point too. We do not NEED to make any of these changes to develop the new machine. We NEED to plan the operating system for the Z380 board. Then we NEED the boards (or the emulators) in front of us so we can code and test it. The only point I can see in making these changes to the Z80 based system would be to ensure we correct all of the bugs without creating any new ones. But then there is not much point in this as we are more likely to end up with more serious bugs from changing platforms that these changes anyway. I am not convinced for the need to change the paging of the current machine at all. It can only increase the cost of the final machine in the streets for ,relatively speaking, insignificant effect on performance and convenience. I do hope you are including the cost of the current machine in your estimates for that price. Next thing you know you will be wanting us to write the Z80 version of the GUI! True, We need to evolve the machine in a modula way but there is little point in spending our time writing and re-writing the same software over and over again. We do need to design a new memory system for the old part be we WANT to design that structure in such a way as to give the new structures as much access to that memory as possible, we WANT to be able to dynamically allocate the memory chips between the different processors if at all possible/practical. We need to be thinking at ALL levels of the design. I would love a new SAM, but I do not want us to get to the stage where we could not make it to the marketplace. We need the new hardware to make it to the mass market. Bob, you always seem to be hedging your bets that the new hardware will not appear, yet if the new hardware does not appear we may be doomed to live in our small 'cult' SAM community. The work we would have done would not be for nothing but we will always have the fealing that we only did it for ourselfs, and not for the greater good that is bigger than us all. WHO said we should aim high? Numb. -WOOOOoooooooo I sound political again. From owner-sam-users@nvg.unit.no Mon Dec 2 21:47:32 1996 From: Stephen Harding Message-Id: <199612021239.MAA02514@BITS.bris.ac.uk> Subject: Proposed Changes to DOS and ROM 1.1 To: sam-users@nvg.unit.no (sam users) Date: Mon, 2 Dec 1996 12:39:47 +0000 (GMT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3214 Lines: 82 >1.1 Disc device numbers within LOAD; SAVE; MERGE etc. Drive numbers are >to be specified outside of the filename in the same way as used by both >the DISCiPLE and PLUS D, i.e. >LOAD d1[;]"FILENAME" ..... >SAVE d1[;]"FILENAME" ..... >etc. > >Allow d1,d2 etc, or d* (*=last drive used). Where possible the old syntax >will remain but the new syntax will have priority. i.e. LOAD d2"D1:FRED" >will look on drive 2 for a file called D1:FRED. The [;] before the open >quotes of the filename may be required if a drive number is given as a >variable. Having the identifier as a seperate parameter does make sense, but I am not sure that the priority should be placed on the seperate parameter over the internal one. I apreciate that the intebntion of the suggestion was to eventualy phase out the "D2:FileName" version, but... Should the external one should set the current steam and the internal one change it on a tempory basis? e.g. compared to print... PAPER 2: PRINT PAPER 5;"Grobo is green" the PAPER 2 will set the permanent colours, paper 5 the tempory one, the text is printed with PAPER 5. LOAD D1 "D2:Grobo" could be implemented to make D1 the permanent stream and D2 the tempory one, the file being loaded from D2. So this instruction could also be written (using current syntax)... DEVICE D1: LOAD "D2:Grobo" Even If we don't do this we need to ask ourselfs if LOAD D1 "Grobo" should make the current stream D1 or just use this stream for the one command. To keep with the current system it would only change the stream on a tempory basis. TIM> Have a table for devices D1 to D99, pointing to your actual devices, TIM> but also a table for device names, pointing to the D1-D99 table TIM> TIM> Then you could have: TIM> LOAD "D1:XXXX" where D1 => DRIVE1 TIM> or LOAD "LeftFloppy:XXXX" LeftFloppy => D1 => DRIVE1 TIM> or LOAD "Samantha:XXXX" etc. TIM> TIM> Perhaps I'm getting a little carried away here. TIM> Tim W. Great idea! I surpose we would have to allocate the DXX numbers in much the same way that the numbers for new BASIC commands are given out to worthy causes. The numbers used being set on the respective interfaces at a hardware level. -We need fixed DXX numbers to provide a fixed way of refering to the drives within applications. The individual users will probabaly want to redefine their own names in your table. It would not be nice for an application to try and use "H1" only to find the PC loving fool has changed their D table so they can refer to the hardrive as "C:" or something! This could add an element of unportability to BASIC programs. Trouble unless we give each drive identifier a specific token, and these tokens are expanded using the table everytime the BASIC program is loaded. Then I surpose there would be a problem with storing the stream to use in a predefined or generated string, say LOAD (A$) B$ Should brackets be used around the drive identifier to prevent problems with LOAD A$ ? It would be hard to assume a default value Should the tape drive have a DXX number, and not be a seperate channel? give it D0: ! Will 2 digits be enough if we also chose to simply give NXX channels DXX numbers too? Numb. From owner-sam-users@nvg.unit.no Mon Dec 2 21:47:32 1996 From: Stephen Harding Message-Id: <199612021336.NAA02705@BITS.bris.ac.uk> Subject: Proposed Changes 1.3 To: sam-users@nvg.unit.no (sam users) Date: Mon, 2 Dec 1996 13:36:02 +0000 (GMT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 4140 Lines: 98 > > 1.3 Filename extensions are not allowed. If say ERASE "*.BAS" was > > typed it should produce the message 'INVALID FILENAME' because there are > > one or more characters between the * and the " at the end of the > > filename. > > Bob. > I use filename extensions a lot on the SAM - eg I use Comet, which > defaults to saving source as "*.S" and its backups as "*.B". Without > extensions, I would have to guess which code files were in fact source > files, which data, and which executable. Frequently I do DIR "*.S" to > check which files I have on a disk. > Tim W. I don't think it would be very nice to impose more, unnecessary withstrictions on the DOS. Exspecialy if we want to win over the DOS<>BASIC gang Bob. >From the way people are writing it looks like we are only going to surport the same length file names. What happen to the 512 character file names? To be honist I couldn't care less if they stay the same or they grow, but what I do care about is that newBASIC AND newGUI USE THE SAME NUMBER!!! It is sickening looking at Win95 long filenames and trying to manipulate them in MSDos or anywhere bar Win95! If we keep 10 charater names in the DOS within SAMSONbasic we keep 10 character names in the GUI! YOU HAVE BEEN WARNED! Do we want to have to put silly .txt .bas .c .snp .scr .gif .app .etc extensions to all of our files? NO! We want the choice. I like the special file types SAMbasic uses. Someone stated that these should be abolished for expandability. I am on another camp. True, it will make expandability a bit harder but we are putting this stuff on a flash anyway. We need to plan these things, we need a larger number of these standard 'out side of the filename' identifiers, we need a table of the sort... (I cannot remember the names or numbers of the exsisting ones but you get my meaning...) 0,SAMbasic 1,SAMscreen 2,ZX-Snap-48K 3,CODE 4,GUI application 5,c source 6,Standard text format 7,Idntified Alien text format 8.Typeface 9...etc... and to ensure future compatability we allocate the rest of them using common sense by splitting them into rough groups with the same name for now, later DOS versions will fill in the details e.g. we allocate numbers 10 to 30 as type '12,application data', these numbers can be given to people making quality, specialist applications to save their files as. Using an old version of DOS these files would appear as type 'application data' but to newer versions of DOS the details would have been expanded so in a directory it may read 'SOS CAD file' for example. The change is purly visual and for the convenience of the user so would not effect the handling of the file, it is just a name. I think that perhaps I went too far in suggesting that the typefaces should have thier own extension, but in general it is a good idea. I beleive Power Macs OS tries to get a similar effect by checking the .XXX extensions against a hash table! If the table is held compressed on the flash and expanded into memory, the application that makes the files should quite easily be able to change the table entry when it is loaded in to memory if you have an old DOS. The modification would remain in place until there was a reset. BEFORE YOU COMPLAIN ENSURE YOU READ THIS BIT: The way SAMbasic handels these extensions in NOT the way the new system should. In SAMbasic there is no really convenient way to change the type of as file once it has been saved. We need to think of a simple logical way to change them. That poor old .sna->.snp converter from nvg has to scan through the directory entrys looking for the file name then change it! SAMbasic seems to treat CODE files and 'snap' files differently when they are the same. All of the interesting ones that must be treated differently must be identified now, or at the advent of a new major DOS version. Here is another DOS bug for you... Try to copy a file of the type 'ZX-Snap' (or whatever it is called) file made with the system disk (or that cool converter from nvg) from one disk to another. Is it hard? COPY "D1:spyhunt" TO "D1:spyhunt" Does it refuse to work or is it just me?! Numb. From owner-sam-users@nvg.unit.no Mon Dec 2 22:34:04 1996 Date: Mon, 2 Dec 1996 20:28:03 +0000 (GMT) From: Tim Wells To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM 1.1 In-Reply-To: <199612021239.MAA02514@BITS.bris.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1167 Lines: 28 On Mon, 2 Dec 1996, Stephen Harding wrote: > Having the identifier as a seperate parameter does make sense, How so? >[Bit about naming devices] > > Great idea! > I surpose we would have to allocate the DXX numbers in much the same way > that the numbers for new BASIC commands are given out to worthy causes. > The numbers used being set on the respective interfaces at a hardware > level. Why? The devices can just be installed as you get them. The devices don't care what their number is, so long as the number maps to the driver. > -We need fixed DXX numbers to provide a fixed way of refering to > the drives within applications. The individual users will probabaly want > to redefine their own names in your table. It would not be nice for an > application to try and use "H1" only to find the PC loving fool has > changed their D table so they can refer to the hardrive as "C:" or > something! This could add an element of unportability to BASIC programs. But an application wouldn't care what you called your drives - you tell it where it should find its files, and you tell it where it find your files. What else does it need to know? Tim W. From owner-sam-users@nvg.unit.no Mon Dec 2 22:38:13 1996 From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: Edinburgh Uni (CS and MATHS) To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 20:48:34 +0000 Subject: Re: SAM BASIC - Comments needed. Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 772 Lines: 15 > 3) any new command you would like to see (with example if needed) SHELL "something" to use the CLI > 4) known bugs (code to demo the bug if poss - and a solution if you have it) There was some bug with KEYIN, but I can't remember it too well. Say you have a procedure name in a$ eg a$="printHello" (with of course some DefProc printHello code somewhere) KEYIN a$ sometimes falls down dead. Strange things too sometimes happen with a$ containing a dos command (eg a$="LOAD ""data.bin"" CODE 81920") +---------------------------------------+------------------------+ | a shot in the dark with a rubber gun | wizards and 3D an | | http://www.geocities.com/area51/5636/ | unbeatable combination | +---------------------------------------+------------------------+ From owner-sam-users@nvg.unit.no Mon Dec 2 22:39:52 1996 From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: Edinburgh Uni (CS and MATHS) To: sam-users@nvg.unit.no Date: Mon, 2 Dec 1996 20:56:09 +0000 Subject: Re: Sequencer + SCADS Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 563 Lines: 11 > Any other MIDI users out there? Yuh. > I'm thinking of getting (In fact, I know I want to get) the SAM MIDI Sequencer > thingy out there. (By Persona?) I want to ask a few questions about it: I'm using MIDI Sequencer 3 by Tim Humphries. It's pretty cool. I know nowt about any others. sorry +---------------------------------------+------------------------+ | a shot in the dark with a rubber gun | wizards and 3D an | | http://www.geocities.com/area51/5636/ | unbeatable combination | +---------------------------------------+------------------------+ From owner-sam-users@nvg.unit.no Mon Dec 2 22:49:49 1996 From: Stephen Harding Message-Id: <199612021446.OAA02965@BITS.bris.ac.uk> Subject: SOS levels To: sam-users@nvg.unit.no (sam users) Date: Mon, 2 Dec 1996 14:46:30 +0000 (GMT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2041 Lines: 49 Samboss> 1) BIOS Samboss> 2) DOS / NOS / User Drivers / Basic / GUI / Standalone m-code Samboss> 3) Applications Great, we are all starting to say the same things (in different ways!) Are we sticking with this? I would personally chose to re-write this as... 1, BIOS 2, DOS / NOS / TOS / User Drivers 3, CLIbasic / GUI / Standalone M_Code 4, GUI applications if applicable This is of course exactly the same thing, I just wrote the drivers as their own level to illustrate that from a programmers perspective, BASIC, the GUI and M_Code actually use the Drivers by an interface of standard, well chosen Hook codes. Numb> True, It would be nice to run SAMSON basic in a window of the GUI in Numb> terms of file sharing and multitasking but Basic is not FOR Numb> multasking, and with the brilliant NOS functions living within Numb> SAMSONbasic file sharing would not be a proplem, even if there is Numb> any call for it. We don't realy want to run more than one Basic Numb> program at once. Simon> *YOU* don't want to run more than one BASIC program at once, you Simon> mean. That's very closeminded thinking. Not true, True. I would love to run more than one at a time! I appologise. I underestimated the call for it, did I overestimate the complexity? I seem to remember in the early days there was a fair bit of talk that it would be possible to have many different SAM BASIC programs memory resident at the same time, living one after each other in memory. I would imagine that when the machine was first being designed and the commands specified they indended to do include this feature but gave up fairly soon. Is this the case? If so it may make out job a little easier. I would imagine that we would want to access BASIC from 2 places (asin PCs), from the CLI and from a CLI window within the GUI. I would also imagine that we would want the GUI version to be able to multi-task, is it worth bothering trying to make it multitask as a raw CLI? We would need to define some keyboard shorcuts to swap between raw CLI ones. From owner-sam-users@nvg.unit.no Mon Dec 2 22:49:49 1996 From: Stephen Harding Message-Id: <199612021508.PAA03023@BITS.bris.ac.uk> Subject: SOS REAL programs To: sam-users@nvg.unit.no (sam users) Date: Mon, 2 Dec 1996 15:08:52 +0000 (GMT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2302 Lines: 52 > >And what problems? > Disc access (in particular with relation to protection routines). We could start thinking about disc protection now. Do we want to give each individual disc an identitly number that cannot be copied? We have full control over the disc format at the moment, in adition to MSDOS discs etc. we could design a special type, for games specialy designed to be hard to reproduce without the correct tools. Or there again we could just get a CD drive as standard! > ROM calls (other than through the jump table). There will be no need as we will plan more than comprehensive hook codes that actually work and do what they are surposed to do. All programmers know that they do such things at their own risk (especially if we all have access to our own flashes!!!) > Programs that don't check the page allocation table. True, but there again if the user is daft enough to try and load SAMdoom when they are still writing a text document in 'processor. Correct, this is not a nice attitude (and not mine!) but one that many programers may have. The trouble is that these things, although not hard, requre thought. It would be nich to provide 2 ROM calls, 1 to call at the start of such a program and one at the end, these could do all of the work so the lazy programmer need not worry about doing any extra work. The 2nd call could be called at any time with no conditions and just return the control straight back to the old environment, the 1st call should be the first instruction of all independent programs, it would check if there is enough room and let the program dump control back to the OS is the conditions are not right or a page in the middle is used by an application. We could have a 'quick save' to save the current vital info about the OS before entering such a program. If there is something that cannot be saved and returned to after the program has finnised we should tell the user so and give them a chance to correct it. We could write 'quick boot' to restore all of the systems to their default status and call this upon quitting such a program. > Programs that don't even check what version of ROM+DOS is loaded. The 2 calls above could do it and see if it is suilable > That will do for starters. Yup, It will. Numb. -Ahhhh late for a lecture!!!!!!! From owner-sam-users@nvg.unit.no Mon Dec 2 22:53:56 1996 Date: Mon, 2 Dec 1996 21:45:09 +0000 (GMT) From: "A.S. Collier" X-Sender: asc25@blue.csi.cam.ac.uk To: sam-users@nvg.unit.no Subject: Re: Disc/k In-Reply-To: <9612021612.AA01123@booth9.ecs.ox.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 838 Lines: 34 On Mon, 2 Dec 1996 Ian.Collier@comlab.ox.ac.uk wrote: > On Sun, 1 Dec 1996 17:35:08 +0000 (GMT), A.S. Collier said: > > If you spell 'disk' as 'disc', how do you spell 'font'? > > Um, how many different ways are there to spell 'font'? 'Phaunte'? > > imc Well, it seems that comment went right above everybody's heads... I'm surprised at you all. Still, here goes: Bob, there are two ways in which you might spell 'font', as in typeface. a) Font If you spell 'font' as 'font' but 'disk' as 'disc' then you are inconsistent, and thus have no right to impose on us your interpretation of computing terms. b) Fount If you spell 'font' as 'fount' then you are as sad as our computing lecturer and obviously stark raving. We must pay no attention to your incoherent mumblings. (And I haven't even mentioned filenames) Andrew From owner-sam-users@nvg.unit.no Mon Dec 2 23:24:06 1996 Date: Mon, 2 Dec 1996 18:21:38 -0500 From: BrenchleyR@aol.com Message-Id: <961202182137_673393809@emout08.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS Z380 OS? Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1920 Lines: 39 Points noted, but look at it this way please. We need to sell the bits - yes we want the Z380 based SAMSON, but that is a way down the road. The first stage is the SRAM board - needed to allow the development of the Z80 side of the operating system which will then allow the developemnt of the Z380 side. To sell the SRAM card to normal SAM users you have to make it appealing - otherwise they will not part with their cash. Make just enough boards for the developers and they will cost 20 quid each. Make 50 boards and the price is down to around 7 quid. Buy parts to build 5 and the price is high, buy to build 25 and the price tumbles. What we HAVE TO DO, not just want to do, is sell things as we go along. Now to sell the SRAM card we need to give the user something. That something should at the very least be a combined Basic/DOS/HDOS - because a combined is going to be better than the sum of the parts. It will alos give us a stable base on which to run things like C compilers and the rest that so many people on this list seem to be crying out for. You HAVE to have the operating system BEFORE you can operate. At the same time as merging the existing code I want to clean up a few problems that have crept in - mainly due to the fact that the original ROM was written in such a hurry and was not written to a spec - it just evolved. We need to DEFINE the Basic Syntax in a form that will allow a rewrtie to be done on the Z380 without the need to do it all in assembler. SAM Basic has to many places where it bends rules. Some I have delt with in postings already, some have still to be discovered as we develop this syntax. However, the tighter these rules are then the easier it will be to write the interpreter (and possibly a compiler) and the less duplication of code will be made. If people want to see lots of extra things in the SRAM then we still have to pay attention to space. Bob. Bob. From owner-sam-users@nvg.unit.no Tue Dec 3 07:41:30 1996 Date: Tue, 3 Dec 1996 07:33:49 +0000 (GMT) From: Si Owen To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM In-Reply-To: <9612021652.AA01263@booth9.ecs.ox.ac.uk> Message-Id: Organisation: Wordcraft International Ltd. Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 940 Lines: 21 On Mon, 2 Dec 1996 Ian.Collier@comlab.ox.ac.uk wrote: > Full regular expression searching is probably not possible in a non- > recursive way. yacc and bison use a data stack to store states without any expensive recursive _function_ calls. It's possible to recurse much deeper without running out of stack space. A good way to try and kill most compilers is to use an expression with 100 or so '('s since each open bracket causes 3 or 4 function calls to implement precedence with terms, factors etc. Hours of fun :-) (Sam C?!) Si /------------------------------------+----------------------------------------\ | Si Owen | Home: si@obobo.demon.co.uk | | Wordcraft International Ltd, UK | Work: sowen@wordcraft.co.uk | | Fax: +44-1332-295525 | WWW: www.obobo.demon.co.uk | \------------------------------------+----------------------------------------/ From owner-sam-users@nvg.unit.no Tue Dec 3 08:05:17 1996 Date: Tue, 3 Dec 1996 07:55:41 +0000 (GMT) From: Si Owen To: sam-users@nvg.unit.no Subject: Re: Proposed Changes 1.3 In-Reply-To: <199612021336.NAA02705@BITS.bris.ac.uk> Message-Id: Organisation: Wordcraft International Ltd. Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2219 Lines: 54 On Mon, 2 Dec 1996, Stephen Harding wrote: > Do we want to have to put silly .txt .bas .c .snp .scr .gif .app .etc > extensions to all of our files? > > NO! We want the choice. I like the special file types SAMbasic uses. It's much easier to remember file extensions than obscure values meaning different file types. Someone would have to be responsible for defining them too. Also, what happens when you run out of values? A limit of 255 (keeping with the old disk format) isn't really *that* much for ever. > we allocate numbers 10 to 30 as type '12,application data', these numbers > can be given to people making quality, specialist applications to save > their files as. 20 values for all possible types of application data? You must be joking! What happens when you run out, do you just allocate another block in the next available region? It starts to get out of hand... > I think that perhaps I went too far in suggesting that the typefaces > should have thier own extension, but in general it is a good idea. Keeping with file type values, you'd run out rather quickly. > The way SAMbasic handels these extensions in NOT the way the new > system should. In SAMbasic there is no really convenient way to change the > type of as file once it has been saved. We need to think of a simple > logical way to change them. File extensions are really only just guides to help people and computers spot files that they can deal with. There's nothing to say that the file really is what it appears to be. To change the 'type' of a file you can just rename it. Treating all files as simple files you'd be able to process then by opening them and just reading bytes from them. > SAMbasic seems to treat CODE files and 'snap' files differently when they > are the same. Yeah, I've always hated that! Si /------------------------------------+----------------------------------------\ | Si Owen | Home: si@obobo.demon.co.uk | | Wordcraft International Ltd, UK | Work: sowen@wordcraft.co.uk | | Fax: +44-1332-295525 | WWW: www.obobo.demon.co.uk | \------------------------------------+----------------------------------------/ From owner-sam-users@nvg.unit.no Tue Dec 3 10:04:40 1996 Date: Tue, 3 Dec 1996 10:02:20 +0000 (GMT) From: Justin Skists X-Sender: c93js1@lagrange.cms.dmu.ac.uk To: SAM users list Subject: SMIDIP Works - (almost) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1469 Lines: 39 Yes! It (almost) works!!!! :) Thanks to all those guy who helped me relearn how to program the SAM to make the alpha version of SMIDIP.... It the moment, it's going just a tad too slow - But I know lots of ways of speeding it up:- It plays "Shoot the Birdie" (2KB) (by me.. crap tune but good testing groud) quite nicely.. But when I play "What is love?" (78KB), it took 3 minutes to decode (ouch!) and the sound was really funny! :) Some places it slowed down where there was lots of MIDI traffic and then it speeded up really fast to catch up.. A bit like a dodgy tape player... *chuckles* Next plan:- To redefine the interrupt handler to ignore most of the INTs that I don't care about (Already working on that) Speed up the decoding... (or at least allow the decoded file to be saved, but that defeats the object!) Speed up the loopings in the player.. I have loads of ideas of completing the tasks. The alpha version was made as a modular program rather than optimised.. (the High Level language programmer got the better of me!) Wish me luck! :) -- ============================================================================= |Justin Skists (c93js1@dmu.ac.uk) | Don't take life so seriously, | |BSc (Hons) Computer Science, Year 4 | you'll never survive it! | |De Montfort University, Leicester, England | - (C) CamLoRTS 1996 | ============================================================================= From owner-sam-users@nvg.unit.no Tue Dec 3 10:11:49 1996 Message-Id: <1.5.4.32.19961203100938.008f9760@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Dec 1996 10:09:38 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SAMSON-DOS personality test (long) Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2418 Lines: 58 At 04:58 PM 12/2/96 GMT, you wrote: >I want to take this opportunity to list the endangered quirks of the Sam. > >1) Sam has no operating system. ROM BASIC directly supports tapes, much >like the Spectrum. Any new hardware (like floppy disk drives) can be made >accessible from BASIC by loading BASIC device drivers and BASIC language >extensions. Those BASIC drivers are in turn made available to native code >running alongside BASIC using hook codes. This allows for fast uniform >access to BASIC. BASIC is boss, unless you boot from your application disk. The lack of an OS is the problem. The SAM has no proper BIOS, has no proper DOS. This causes the immense problems we are currently experiencing in upgrading the system. You try adding a new floppy disk driver to the DOS. I dare you. I'll even give you the SAMDOS 2.2 source. Just try it buster. We're not advocating getting rid of the BASIC, just abstracting it a little, which will make all kinds of things possible (want your BASIC to work with the new graphics card? or how about have it all in a window? multitasking? interfacing with the GUI? compiled?) >2) Sam uses 10 character filenames, and MSDOS/CPM-like "DEVICE:" >specifiers. This means that any program which cannot be loaded completely >into memory and which uses more than one device needs to know what sort of >media it is currently recorded on. I don't follow this. >3) BASIC maintains file type information where any file is one of a >BASIC defined list of types. DOS-like suffixes are purely informative. Which causes hell if you want, say, a file you can read and write to, and then load as a SCREEN$ file. Ever tried doing that with an OPENTYPE? > ---- > >All of the arguments about CLIs, NOSs, GUIs seem in my opinion to boil down >to the question: > >1A) Do we add new functionality to BASIC to support new hardware, and leave >BASIC as the only low level user interface? Nope... bad idea. Make it optional. >1B) Do we put the core device access routines in a seperate package and >run the user's preferred user interface on top of that? Not necessarily on top of it, but YES. >1C) Or do we replace BASIC as the primary user interface with a command line >interface that tries to be like other system's CLI's? Nothing wrong with having a CLI that you can access BASIC from by doing "BASIC", or a BASIC that you can access the CLI from by typing "SHELL" Simon From owner-sam-users@nvg.unit.no Tue Dec 3 10:11:57 1996 Message-Id: <1.5.4.32.19961203100936.008f2364@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Dec 1996 10:09:36 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Proposed Changes 1.3 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 505 Lines: 19 At 01:36 PM 12/2/96 +0000, you wrote: >Here is another DOS bug for you... > >Try to copy a file of the type 'ZX-Snap' (or whatever it is called) >file made with the system disk (or that cool converter from nvg) from one >disk to another. Is it hard? >COPY "D1:spyhunt" TO "D1:spyhunt" > >Does it refuse to work or is it just me?! >Numb. It's not a bug - it's a feature. Namely to stop people copying snapshots for all and sundry. However, it never stopped me (wrote me own backup utility ;)) Simon From owner-sam-users@nvg.unit.no Tue Dec 3 10:12:02 1996 Message-Id: <1.5.4.32.19961203100934.008e1e08@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Dec 1996 10:09:34 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SOS LOAD "too long" Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 842 Lines: 29 At 11:10 AM 12/2/96 +0000, you wrote: >Status: RO > >> >I do know >> >however that I'm sick of typing load"whatever". Its slow and >> >fustrating to have to type that and I just hope that the format for >> >loading a program gets shortened. >> -- >>I don't find the syntax a problem, it is short (compared to some systems >>I used in the past) and at least it makes sence. >>Samsboss. > >If you are so sick of it, simply redefing the "F7" key to... > LOAD " >I have! I load this mod. in most times that I turn the machine on. >(I also change some other F keys I don't use into the cursors cos my >cursors often chose not to work!) > >There is no need to keep F7 and F8 as LOAD "" and LOAD "" CODE as no one >uses tapes anymore! Which is why we changed them in the HominROM to: F7 - LOAD, F8 - DIR *, SHIFT+F9 - BOOT 1 :) Simon From owner-sam-users@nvg.unit.no Tue Dec 3 10:12:14 1996 Message-Id: <1.5.4.32.19961203100941.008f5198@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Dec 1996 10:09:41 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Proposed Changes 1.3 Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1291 Lines: 35 At 07:55 AM 12/3/96 +0000, you wrote: >Status: > >On Mon, 2 Dec 1996, Stephen Harding wrote: > >> Do we want to have to put silly .txt .bas .c .snp .scr .gif .app .etc >> extensions to all of our files? >> >> NO! We want the choice. I like the special file types SAMbasic uses. > >It's much easier to remember file extensions than obscure values meaning >different file types. Someone would have to be responsible for defining >them too. Also, what happens when you run out of values? A limit of 255 >(keeping with the old disk format) isn't really *that* much for ever. Actually, the limit built into SAMDOS and MASTERDOS is 32 different file types, one of which stands for "erased". > >> we allocate numbers 10 to 30 as type '12,application data', these numbers >> can be given to people making quality, specialist applications to save >> their files as. > >20 values for all possible types of application data? You must be joking! >What happens when you run out, do you just allocate another block in the >next available region? It starts to get out of hand... What's more, who allocates them? Speaking of which, we need a new memory allocation method -- the existing one is too haphazard. Namely because everyone looks at the values and goes "oooh, I'll have that one!". Simon From owner-sam-users@nvg.unit.no Tue Dec 3 10:18:18 1996 Message-Id: From: ee31ag@ee.surrey.ac.uk (Andrew M Gale) Subject: Re: Disc/k To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 10:15:58 +0000 (GMT) In-Reply-To: from "A.S. Collier" at Dec 2, 96 09:45:09 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 942 Lines: 30 > a) Font > > If you spell 'font' as 'font' but 'disk' as 'disc' then you are > inconsistent, and thus have no right to impose on us your interpretation > of computing terms. > How is that inconsistent?! I have kept quiet on the disc/k matter so far, but I canny take it no more! A vinyl record is a disc. The earth is a disc (not a sphere as some people suppose). A flat, round thing is a disc. None of them are disks! The old 8" things were called discs. Then we started to get these new small, 5.25" discs, and because they were miniature versions of their 8" counterparts they were called 'diskettes'. ('discettes' would have been stupid) People realised that diskette was a gobfull, so started calling them discs again. But certain stupid ****s reasoned that disk was the abbreviation of diskette, completely ignoring the fact that diskette was itself an extension of disc. Let's hear no more nonsense on the matter! -Andy From owner-sam-users@nvg.unit.no Tue Dec 3 10:21:38 1996 Message-Id: From: ee31ag@ee.surrey.ac.uk (Andrew M Gale) Subject: Re: SAMSON-DOS personality test (long) To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 10:19:26 +0000 (GMT) In-Reply-To: <1.5.4.32.19961203100938.008f9760@nessie.mcc.ac.uk> from "Simon Cooke" at Dec 3, 96 10:09:38 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 285 Lines: 10 > > You try adding a new floppy disk driver to the DOS. I dare you. I'll even > give you the SAMDOS 2.2 source. Just try it buster. > Why is it so tricky? OK, the format command could be a pain to modify, but aren't there just a few subroutines that need changing otherwise? -Andy From owner-sam-users@nvg.unit.no Tue Dec 3 10:23:19 1996 Message-Id: <1.5.4.32.19961203102205.009bc690@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Dec 1996 10:22:05 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Disc/k Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 424 Lines: 14 At 10:15 AM 12/3/96 +0000, you wrote: >People realised that diskette was a gobfull, so started calling >them discs again. But certain stupid ****s reasoned that >disk was the abbreviation of diskette, completely ignoring the >fact that diskette was itself an extension of disc. > >Let's hear no more nonsense on the matter! I spy with my little eye something beginning with RW. (it happens a lot on this list...) Simon From owner-sam-users@nvg.unit.no Tue Dec 3 10:30:56 1996 Message-Id: <1.5.4.32.19961203102849.008f2e34@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Dec 1996 10:28:49 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: SAMSON-DOS personality test (long) Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 535 Lines: 25 At 10:19 AM 12/3/96 +0000, you wrote: >Status: > >> >> You try adding a new floppy disk driver to the DOS. I dare you. I'll even >> give you the SAMDOS 2.2 source. Just try it buster. >> > > >Why is it so tricky? OK, the format command could be a pain to modify, >but aren't there just a few subroutines that need changing otherwise? >-Andy *chuckles* :) "just a few subroutines" Those are the words of someone who's never hacked the DOS ;) Everything's interconnected and interlinked for speed. You've got no chance. Simon From owner-sam-users@nvg.unit.no Tue Dec 3 11:35:50 1996 From: Stephen Harding Message-Id: <199612031136.LAA05413@BITS.bris.ac.uk> Subject: Re:SOS file types To: sam-users@nvg.unit.no (sam users) Date: Tue, 3 Dec 1996 11:36:22 +0000 (GMT) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 3001 Lines: 78 > >> Do we want to have to put silly .txt .bas .c .snp .scr .gif .app .etc > >> extensions to all of our files? > >> > >> NO! We want the choice. I like the special file types SAMbasic uses. > > > >It's much easier to remember file extensions than obscure values > >meaning different file types. Yes, We need to find a cunning way of refering to them. It would be nice to be able to type something along the lines of... CAT 1;"~basic" to get a directory of all the basic files and RENAME "grobo~code" TO "grobo~snap" to change the code file grobo to a snap, in most cases the filetype is not stated as it can always be found out from the directory. so we can have... RENAME "grobo" TO "grobo~code" to change it back This is an ugly syntax, can anyone think of a better one? perhaps we could have another field in the basic command. LOAD "grobo" "snap" We could do with some nice way of changing the types even if we keep the number of these types just the same and don't extend their use to their logical conclusion. > >>20 values for all possible types of application data? You must be > >>joking! I was actualy! All unidentified types should simply be refered to as CODE files by older versions of the DOS. > >>What happens when you run out, do you just allocate another block in the > >>next available region? It starts to get out of hand... We plan it so that we don't run out. see later. > > Someone would have to be responsible for defining them too. No, all un-ID-ed ones should just be called CODE files. Someone will have to dish the types out to worthy applications though, who dishes out the unused BASIC tokons? > >Also, what happens when you run out of values? A limit of 255 (keeping > >with the old disk format) isn't really *that* much for ever. > > > Actually, the limit built into SAMDOS and MASTERDOS is 32 different file > types, one of which stands for "erased". We don't have to stick to the old system! there is loads of room in the directory structure that we could use. We could do it in much the same way as the BASIC tokons work, the first 8 bits can have 255 different types. If this byte is a &FF then you look at the next byte. If this one is an &FF then you look at the next one .etc... I am fairly confident that we will never use more than 255 anyway but it is best to be safe! extreme case: 4 bytes would give 1020 different file types! We would limit the number of codes given out to a bare MINIMUM and use very general names. PROBLEM: A large table would be requred. Each entry would need to store a type definition to appear in the directory listing and a short string to refer to the type as. I think we will have to include such (hash?) tables in the new ROM anyway. At the moment we have 4 screen modes, what is going to happen when we have a great number more? It would no longer be convenient to refer to them by numbers. We may want to refer to them by name. We could also use such a structure to give the DXX devices sensible names. Numb. From owner-sam-users@nvg.unit.no Tue Dec 3 11:42:21 1996 Date: Tue, 3 Dec 1996 06:37:17 -0500 From: BrenchleyR@aol.com Message-Id: <961203063715_1252961652@emout08.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: Proposed Changes to DOS and ROM Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 529 Lines: 19 In a message dated 02/12/96 11:49:38, you write: >> No, you miss the point, this is not the operating system for the Z380, that >> come much futher down the road. This is one step to giving us the tools to >> develop the Z380 based system. >> >> Bob. > >I hardly think people will be writing the SamSon system software in Basic. > >Andrew Oh don't be so stupid. As I've said, you can't develop the Z380 until we at least have the tools - an they need a stable, integrated system to run on with good hard drive support. Bob. From owner-sam-users@nvg.unit.no Tue Dec 3 11:42:26 1996 Date: Tue, 3 Dec 1996 06:37:10 -0500 From: BrenchleyR@aol.com Message-Id: <961203063709_1118811764@emout06.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 459 Lines: 16 In a message dated 02/12/96 11:07:59, you write: >> Programs can do what the heck they like with filenames provided that they >> take responsibility for the outcome. However, a line like ERASE Dn"*.CAD" >> should not be a legal command - and I don;t care what other systems do or >> what SAM does at the moment - this is just an illegal structure that should >> not be allowed. > >Why? > > -Frode Because it allows something after the * that is why. Bob. From owner-sam-users@nvg.unit.no Tue Dec 3 11:42:26 1996 Date: Tue, 3 Dec 1996 06:37:19 -0500 From: BrenchleyR@aol.com Message-Id: <961203063718_1353502580@emout10.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 608 Lines: 15 In a message dated 02/12/96 12:54:51, you write: >WHY????? For gods sake, give the user the power! If the user >WANTS to delete all files that end with .CAD then the user should be >able to delete all files that end .CAD! >-- >James R Curry hc95jc@dmu.ac.uk I have no problem with giving the user extra powers. If for instant we used ! to say "reverse the normal logic and start doing your string compare from the end of the string and work back". That would allow ERASE Dn"!.CAD". But my point is that using * in the way that it has been has to be seen a being against the normal rules. Bob. From owner-sam-users@nvg.unit.no Tue Dec 3 11:43:41 1996 Date: Tue, 3 Dec 1996 06:37:20 -0500 From: BrenchleyR@aol.com Message-Id: <961203063720_1487088116@emout11.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SAMSON Character Set. Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 318 Lines: 13 In a message dated 02/12/96 13:50:07, you write: >My comment is "What on earth is the ANSI set?". Also, "Stick to ISO8859-1". > >imc Look upon ANSI as being 8 bit ASCII, it has the advantage that it is the Windows character set so a lot of software already exists on other systems that understand the set. Bob. From owner-sam-users@nvg.unit.no Tue Dec 3 11:43:41 1996 Date: Tue, 3 Dec 1996 06:37:22 -0500 From: BrenchleyR@aol.com Message-Id: <961203063721_1520643572@emout12.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 486 Lines: 16 In a message dated 02/12/96 13:56:30, you write: > CLI: cd /foo and BASIC: DIR="/foo" > rm test ERASE "test" > prog x y z OPEN TO 10: LOAD "prog" CODE 32768: CALL >3276 > 8,x,y,z > >and then tell me you prefer to do everything in BASIC syntax. > >imc Well I've used many different systems, but Basic does have the advantage that more 'normal' people will understand the Basic syntax. Bob. From owner-sam-users@nvg.unit.no Tue Dec 3 11:43:41 1996 Date: Tue, 3 Dec 1996 06:37:23 -0500 From: BrenchleyR@aol.com Message-Id: <961203063722_1587752564@emout13.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: SAMSON-DOS personality test (long) Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 262 Lines: 10 In a message dated 03/12/96 10:12:12, you write: >Nothing wrong with having a CLI that you can access BASIC from by doing >"BASIC", or a BASIC that you can access the CLI from by typing "SHELL" > >Simon Two words to that idea and the second one is OFF. Bob. From owner-sam-users@nvg.unit.no Tue Dec 3 11:43:42 1996 Date: Tue, 3 Dec 1996 06:37:25 -0500 From: BrenchleyR@aol.com Message-Id: <961203063724_1617447924@emout14.mail.aol.com> To: sam-users@nvg.unit.no Subject: Re: Wild Cards. Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1835 Lines: 41 On Dec 02, 1996 12:36:42, 'Tim Paveley ' wrote: >Urm, surely if we are dealing with wild cards a * means 'match 0 to >infinity characters', thus "*.CAD" is valid. If not then it should be, >and we should be allowed to use any valid regular expressions. > >How else am I supposed to delete all my files ending with the characters >..BAK (I'm not calling it an extension, but a convienent system for naming >my back up files) other than to delete the all one at a time. > >? matches 1 character doesn't it (or does it also match no characters) > >Tim ....@/ -- Well now, just dug out my sons GCSE Computer Studies Course notes. They say this. "Wild Cards: many computer systems use Wild Cards to help matching routines perform in a more flexible way. By common concensus ? is used to match any single character (any char) # is used to match with a number (some systems allow this to also match with space and decimal point) and * is used to match any number of characters from that point to the end of the field." So, if his teacher told him no lies, then things have not changed since I learnt programming back in the late 70s.. If a filename is "ANYNAME" then typing ERASE "*.CODE" will erase it if the standard rules are followed. Methinks (well I do sometimes) that the problems come from that dreaded MS-DOS, where they mix the device, the directory path, the filename and the file extension all on one line. Poo. Stinks. Not nice. When in MS-DOS you type DEL c:\mysub\myfile.bas you are enterings a drive or device, a sub directory, a filename, and the file type/extension. It uses : \ and . as delimiters. Not nice, three different delimiters in one line (four if you count the space after the DEL) no wonder MS-DOS is so shitty. As I've said, we could find another character, but which? Bob. From owner-sam-users@nvg.unit.no Tue Dec 3 11:52:10 1996 Message-Id: <1.5.4.32.19961203114843.008e2b18@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Dec 1996 11:48:43 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Wild Cards. Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 820 Lines: 23 At 06:37 03/12/96 -0500, you wrote: >Well now, just dug out my sons GCSE Computer Studies Course notes. They say >this. > >"Wild Cards: many computer systems use Wild Cards to help matching routines >perform in a more flexible way. By common concensus ? is used to match any >single character (any char) # is used to match with a number (some systems >allow this to also match with space and decimal point) and * is used to match >any number of characters from that point to the end of the field." Please note: you said "Computer Studies Course notes" There's a world of difference between that and Computer Science. ie. One is for managers, the other for programmers. (I've done Computer Studies GCSE, and Computer Studies A/S... and all the time I wished that they'd let me do Computer Science instead). Simon From owner-sam-users@nvg.unit.no Tue Dec 3 11:54:47 1996 Date: Tue, 3 Dec 1996 12:48:29 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9612031148.AA10387@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: SOS NOS and DOS X-Sun-Charset: US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 597 Lines: 18 > >> Programs can do what the heck they like with filenames provided that they > >> take responsibility for the outcome. However, a line like ERASE Dn"*.CAD" > >> should not be a legal command - and I don;t care what other systems do or > >> what SAM does at the moment - this is just an illegal structure that > should > >> not be allowed. > > > >Why? > > > > -Frode > > Because it allows something after the * that is why. Could you be more specific. Nothing wrong with something after an * - fully implemented regular expressions even allows for matching from the end of the string. -Frode From owner-sam-users@nvg.unit.no Tue Dec 3 11:55:10 1996 From: James R Curry Organization: De Montfort University To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 11:54:03 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Proposed Changes to DOS and ROM X-Confirm-Reading-To: "James R Curry" X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: <34AE9601957@sahara.cms.dmu.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1100 Lines: 22 > > [Screen Blanking] Why would you want it to default to off anyway? > > > > Because in most cases it is a pain in the bum that the screen blanks. It is > > never needed if you use a TV and only needed really if you have a very cheap > > green-screen monitor. > > Having worked with a monitor manufacturer for a short while, I know that > screen blanking is much more important than that - that manufacturer > refuses to provide guarantees to industrial purchasers of its monitors, > unless those purchasers use screen-blanking in their applications. Home > use of computers is much less critical, as monitors are normally only > used for a few hours a day on average. However, in these applications, it > is known that screen-blanking clearly extends monitor life. Therefore, as > I don't intend to have to replace my monitor prematurely, I would like to > keep screen blanking. Perhaps we could also have an option to replace the screen blanking with your own screensaver :) -- James R Curry hc95jc@dmu.ac.uk "20 Dollars! Aw, I wanted a peanut.." - Homer Simpson, the Simpsons. From owner-sam-users@nvg.unit.no Tue Dec 3 12:03:08 1996 From: James R Curry Organization: De Montfort University To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 12:03:05 GMT Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: SMIDIP Works - (almost) Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: <34B102040DF@sahara.cms.dmu.ac.uk> Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 396 Lines: 12 > I have loads of ideas of completing the tasks. The alpha version was made > as a modular program rather than optimised.. (the High Level language > programmer got the better of me!) > > Wish me luck! :) Good luck! (Is it just me or did everyone get two copies of your message?) -- James R Curry hc95jc@dmu.ac.uk "20 Dollars! Aw, I wanted a peanut.." - Homer Simpson, the Simpsons. From owner-sam-users@nvg.unit.no Tue Dec 3 12:09:10 1996 Message-Id: <1.5.4.32.19961203120635.008ed38c@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Dec 1996 12:06:35 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re:SOS file types Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1899 Lines: 51 At 11:36 03/12/96 +0000, you wrote: >All unidentified types should simply be refered to as CODE files by older >versions of the DOS. Actually, they're referred to as "WHAT?" >> >>What happens when you run out, do you just allocate another block in the >> >>next available region? It starts to get out of hand... >We plan it so that we don't run out. >see later. > >> > Someone would have to be responsible for defining them too. >No, all un-ID-ed ones should just be called CODE files. >Someone will have to dish the types out to worthy applications though, who >dishes out the unused BASIC tokons? No-one does. This is the problem though -- we'll run out!!! >We don't have to stick to the old system! there is loads of room in the >directory structure that we could use. We could do it in much the same way >as the BASIC tokons work, the first 8 bits can have 255 different types. >If this byte is a &FF then you look at the next byte. If this one is an >&FF then you look at the next one .etc... >I am fairly confident that we will never use more than 255 anyway but it >is best to be safe! extreme case: 4 bytes would give 1020 different file >types! And where, pray tell, are you going to find these extra 3 bytes in the directory structure? A better way: at the beginning of the file, have four characters: BAS - BASIC CODE - CODE 48KS - 48K snapshot 128K - 128k snapshot NUMD - Numeric Data STRD - String data OPEN - OPENTYPE (or /no/ header perhaps?) SCRN - SCREEN file GIF - GIF file IFF - Amiga IFF file ETRK - E tracker module PTRK - Pro Tracker module. Only certain files will be recognised and have their files displayed. (ie the standard SAM ones). They should also have a greatly cut down amount of info stuck in the directory space. Simon From owner-sam-users@nvg.unit.no Tue Dec 3 12:26:17 1996 Date: Tue, 3 Dec 1996 12:09:40 +0000 (GMT) From: Justin Skists X-Sender: c93js1@napier.cms.dmu.ac.uk To: sam-users@nvg.unit.no Subject: Re: SMIDIP Works - (almost) In-Reply-To: <34B102040DF@sahara.cms.dmu.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 573 Lines: 18 On Tue, 3 Dec 1996, James R Curry wrote: > Good luck! Thanks.. > (Is it just me or did everyone get two copies of your > message?) I'm sorry... Not sure what happened... -- ============================================================================= |Justin Skists (c93js1@dmu.ac.uk) | Don't take life so seriously, | |BSc (Hons) Computer Science, Year 4 | you'll never survive it! | |De Montfort University, Leicester, England | - (C) CamLoRTS 1996 | ============================================================================= From owner-sam-users@nvg.unit.no Tue Dec 3 12:51:07 1996 Date: Tue, 3 Dec 1996 12:19:05 +0000 (GMT) From: Justin Skists X-Sender: c93js1@napier.cms.dmu.ac.uk To: sam-users@nvg.unit.no Subject: Re:SOS file types In-Reply-To: <1.5.4.32.19961203120635.008ed38c@nessie.mcc.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1119 Lines: 24 On Tue, 3 Dec 1996, Simon Cooke wrote: > A better way: at the beginning of the file, have four characters: I tend to anyway.. When I made Arcanum for the PC (file encryption) I used AME. The chr$ 26 was a nice thing to stop people TYPEing the file and making lots of funny noises and pretty ASCII mess on the screen since it was a binary file.. This kind of made sure the decrypter didn't try to decrypt another file that the user may have loaded... Executables have MZ or ZM in MS-DOS/Windows as the first two characters. The trouble with displaying this info in the directory is that it will be slow having to read the directory sectors and also reading the first sector of each file... -- ============================================================================= |Justin Skists (c93js1@dmu.ac.uk) | Don't take life so seriously, | |BSc (Hons) Computer Science, Year 4 | you'll never survive it! | |De Montfort University, Leicester, England | - (C) CamLoRTS 1996 | ============================================================================= From owner-sam-users@nvg.unit.no Tue Dec 3 12:59:47 1996 Message-Id: <1.5.4.32.19961203122951.009ab054@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Dec 1996 12:29:51 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re:SOS file types Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 993 Lines: 30 At 12:19 03/12/96 +0000, you wrote: >Status: > >On Tue, 3 Dec 1996, Simon Cooke wrote: > >> A better way: at the beginning of the file, have four characters: > >I tend to anyway.. When I made Arcanum for the PC (file encryption) I >used AME. The chr$ 26 was a nice thing to stop >people TYPEing the file and making lots of funny noises and pretty ASCII >mess on the screen since it was a binary file.. This kind of made sure >the decrypter didn't try to decrypt another file that the user may have >loaded... > >Executables have MZ or ZM in MS-DOS/Windows as the first two characters. > >The trouble with displaying this info in the directory is that it will be >slow having to read the directory sectors and also reading the first >sector of each file... In that case, define new tags: APPLICATION FILE Which is what these files will appear as in the directory. Then the programs which have to use them can make the decision what to do with them. Simon From owner-sam-users@nvg.unit.no Tue Dec 3 13:01:39 1996 Date: Tue, 3 Dec 1996 13:44:02 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9612031244.AA10698@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: Wild Cards. X-Sun-Charset: US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1533 Lines: 41 > Well now, just dug out my sons GCSE Computer Studies Course notes. They say > this. > > "Wild Cards: many computer systems use Wild Cards to help matching routines > perform in a more flexible way. By common concensus ? is used to match any > single character (any char) # is used to match with a number (some systems > allow this to also match with space and decimal point) and * is used to match > any number of characters from that point to the end of the field." Eh....this must be relics from the 60's.... > > So, if his teacher told him no lies, then things have not changed since I > learnt programming back in the late 70s.. Uhm... > If a filename is "ANYNAME" then typing ERASE "*.CODE" will erase it if the > standard rules are followed. The 'standards' have changed.. > Methinks (well I do sometimes) that the problems come from that dreaded > MS-DOS, where they mix the device, the directory path, the filename and the > file extension all on one line. Poo. Stinks. Not nice. > > When in MS-DOS you type DEL c:\mysub\myfile.bas you are enterings a drive or > device, a sub directory, a filename, and the file type/extension. It uses : \ > and . as delimiters. Not nice, three different delimiters in one line (four > if you count the space after the DEL) no wonder MS-DOS is so shitty. It is, but for other reasons. Oh..the filename and the extension is the same thing - pitty DOS does not stick to this. > > As I've said, we could find another character, but which? No other character. * it is. -Frode From owner-sam-users@nvg.unit.no Tue Dec 3 13:05:37 1996 Date: Tue, 3 Dec 1996 13:34:07 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9612031234.AA10573@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: SAMSON Character Set. X-Sun-Charset: US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 484 Lines: 17 > In a message dated 02/12/96 13:50:07, you write: > > >My comment is "What on earth is the ANSI set?". Also, "Stick to ISO8859-1". > > > >imc > > Look upon ANSI as being 8 bit ASCII, it has the advantage that it is the > Windows character set so a lot of software already exists on other systems > that understand the set. 1) 8 bit ASCII does not exists. 2) The ANSI character set used in Windows (not NT) is a hybrid towards ISO-8859-1 (ISO-Latin-1). Use ISO-8859-1! -Frode From owner-sam-users@nvg.unit.no Tue Dec 3 13:24:39 1996 From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: Edinburgh Uni (CS and MATHS) To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:08:49 +0000 Subject: Re: Disc/k Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 847 Lines: 17 > If you spell 'font' as 'font' but 'disk' as 'disc' then you are > inconsistent, and thus have no right to impose on us your interpretation > of computing terms. > If you spell 'font' as 'fount' then you are as sad as our computing > lecturer and obviously stark raving. We must pay no attention to your > incoherent mumblings. (And I haven't even mentioned filenames) So, spell font as font, and disk as disk, or be eternally damned. Or something. Just a thought, is font of all knowledge actually fount of all knowledge, or are the two phrases interchangeable, or what? +---------------------------------------+------------------------+ | a shot in the dark with a rubber gun | wizards and 3D an | | http://www.geocities.com/area51/5636/ | unbeatable combination | +---------------------------------------+------------------------+ From owner-sam-users@nvg.unit.no Tue Dec 3 13:27:49 1996 From: Mr P R Walker Message-Id: <17239.199612031306@holly.csv.warwick.ac.uk> Subject: Re: Wild Cards. To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:06:12 +0000 (GMT) In-Reply-To: <961203063724_1617447924@emout14.mail.aol.com> from "BrenchleyR@aol.com" at Dec 3, 96 06:37:25 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 344 Lines: 10 > file extension all on one line. Poo. Stinks. Not nice. Sounds fine - it allows you to specify quickly and easily precisely which file you want, with the required amount of detail. > As I've said, we could find another character, but which? I think you're outvoted, Bob - it looks like this is going to be the way in which "*" operates. From owner-sam-users@nvg.unit.no Tue Dec 3 13:33:34 1996 Date: Tue, 3 Dec 1996 14:13:58 +0100 From: ft@edh.ericsson.se (Frode Tenneboe) Message-Id: <9612031313.AA10872@asmal.edh-net> To: sam-users@nvg.unit.no Subject: Re: Disc/k X-Sun-Charset: US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 117 Lines: 6 > So, spell font as font, and disk as disk, or be eternally damned. Or > something. How about...'floppy'? -Frode From imc Tue Dec 3 13:33:37 1996 Subject: Re: SOS file types To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:33:37 +0000 (GMT) In-Reply-To: <1.5.4.32.19961203120635.008ed38c@nessie.mcc.ac.uk> from "Simon Cooke" at Dec 3, 96 12:06:35 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: 344 Lines: 12 On Tue, 03 Dec 1996 12:06:35 +0000, Simon Cooke said: > BAS - BASIC > CODE - CODE > 48KS - 48K snapshot > SCRN - SCREEN file > GIF - GIF file > IFF - Amiga IFF file Actually GIF already has "GIF" at the start of the file (but it's followed by '8' instead of a space). imc From owner-sam-users@nvg.unit.no Tue Dec 3 13:33:46 1996 From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: Edinburgh Uni (CS and MATHS) To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:18:02 +0000 Subject: Re: SMIDIP Works - (almost) Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 316 Lines: 7 > Wish me luck! :) G'luck. Twice, so it seems +---------------------------------------+------------------------+ | a shot in the dark with a rubber gun | wizards and 3D an | | http://www.geocities.com/area51/5636/ | unbeatable combination | +---------------------------------------+------------------------+ From imc Tue Dec 3 13:34:00 1996 Subject: Re: SMIDIP Works - (almost) To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:34:00 +0000 (GMT) In-Reply-To: <34B102040DF@sahara.cms.dmu.ac.uk> from "James R Curry" at Dec 3, 96 12:03:05 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: 172 Lines: 7 On Tue, 3 Dec 1996 12:03:05 GMT, James R Curry said: > Good luck! (Is it just me or did everyone get two copies of your > message?) It's not you - I got them too. imc From owner-sam-users@nvg.unit.no Tue Dec 3 13:36:00 1996 Date: Tue, 3 Dec 1996 13:24:09 +0000 (GMT) From: Justin Skists X-Sender: c93js1@jacobi.cms.dmu.ac.uk To: sam-users@nvg.unit.no Subject: Re:SOS file types In-Reply-To: <1.5.4.32.19961203122951.009ab054@nessie.mcc.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 876 Lines: 23 On Tue, 3 Dec 1996, Simon Cooke wrote: > In that case, define new tags: > > APPLICATION > FILE > > Which is what these files will appear as in the directory. Then the programs > which have to use them can make the decision what to do with them. Exactly! :) Oh, btw, does the LBYTE(?), SBYTE(?) and associated hookcodes (opening files etc for loading single bytes) work in SAMDOS2? I've heard some things on here (probably read wrongly, by me) that the hookcodes don't work? -- ============================================================================= |Justin Skists (c93js1@dmu.ac.uk) | Don't take life so seriously, | |BSc (Hons) Computer Science, Year 4 | you'll never survive it! | |De Montfort University, Leicester, England | - (C) CamLoRTS 1996 | ============================================================================= From owner-sam-users@nvg.unit.no Tue Dec 3 13:36:00 1996 From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: Edinburgh Uni (CS and MATHS) To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:29:10 +0000 Subject: Re:SOS file types Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1428 Lines: 34 > I am fairly confident that we will never use more than 255 anyway but it > is best to be safe! extreme case: 4 bytes would give 1020 different file > types! 32 10 Bleh? How is 2 1020? 2 = 1024, so wouldn't 4 bytes therefore give 4294967296 different file types? !!excessive methinks!! 2 or 3 bytes at the most > We would limit the number of codes given out to a bare MINIMUM and use > very general names. Yes - if file types are to be used, keep them general. Eg, GIF IMAGE, BITMAP IMAGE rather than GIF89aINTERLACED IMAGE, GIF89aNONINTERLACED IMAGE, GIF87 IMAGE, BITMAP RGB COMPRESSED, BITMAP RLE COMPRESSED, etc > PROBLEM: A large table would be requred. Each entry would need to store a > type definition to appear in the directory listing and a short string to > refer to the type as. > > I think we will have to include such (hash?) tables in the new ROM anyway. But what about NEW files types... Hmm? Haaa? > At the moment we have 4 screen modes, what is going to happen when we have > a great number more? It would no longer be convenient to refer to them by > numbers. We may want to refer to them by name. Unh? +---------------------------------------+------------------------+ | a shot in the dark with a rubber gun | wizards and 3D an | | http://www.geocities.com/area51/5636/ | unbeatable combination | +---------------------------------------+------------------------+ From imc Tue Dec 3 13:37:24 1996 Subject: Re: Wild Cards. To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:37:24 +0000 (GMT) In-Reply-To: <961203063724_1617447924@emout14.mail.aol.com> from "BrenchleyR@aol.com" at Dec 3, 96 06:37: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: 1216 Lines: 31 On Tue, 3 Dec 1996 06:37:25 -0500, BrenchleyR@aol.com said: > Well now, just dug out my sons GCSE Computer Studies Course notes. They say > this. > "Wild Cards: many computer systems use Wild Cards to help matching routines > perform in a more flexible way. By common concensus ? is used to match any > single character (any char) # is used to match with a number (some systems > allow this to also match with space and decimal point) and * is used to match > any number of characters from that point to the end of the field." No wonder education is in the state it's in then... What they mean is, "In MSDOS, ...". On the other hand, in Unix (and on the 48KDB CAT command) the '*' works correctly. > If a filename is "ANYNAME" then typing ERASE "*.CODE" will erase it if the > standard rules are followed. No, because the "." delimits a different field and according to the above the ".CODE" field still has to be matched. > Methinks (well I do sometimes) that the problems come from that dreaded > MS-DOS, where they mix the device, the directory path, the filename and the > file extension all on one line. Nothing wrong with that - otherwise, how are you going to specify where the file comes from? imc From owner-sam-users@nvg.unit.no Tue Dec 3 13:37:39 1996 From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: Edinburgh Uni (CS and MATHS) To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:21:34 +0000 Subject: Re: Proposed Changes 1.3 Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 647 Lines: 11 > Speaking of which, we need a new memory allocation method -- the existing > one is too haphazard. Namely because everyone looks at the values and goes > "oooh, I'll have that one!". If this is for the SAMSON with its flat memory arrangement, couldn't the OS allocate the memory, on the assumption that all programs are relocatable? Oh, but then, compatibility with SAM ... +---------------------------------------+------------------------+ | a shot in the dark with a rubber gun | wizards and 3D an | | http://www.geocities.com/area51/5636/ | unbeatable combination | +---------------------------------------+------------------------+ From owner-sam-users@nvg.unit.no Tue Dec 3 13:38:26 1996 From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: Edinburgh Uni (CS and MATHS) To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:23:05 +0000 Subject: Re: Disc/k Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 329 Lines: 6 > I spy with my little eye something beginning with RW. eh? +---------------------------------------+------------------------+ | a shot in the dark with a rubber gun | wizards and 3D an | | http://www.geocities.com/area51/5636/ | unbeatable combination | +---------------------------------------+------------------------+ From imc Tue Dec 3 13:41:39 1996 Subject: Re: SOS file types To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:41:39 +0000 (GMT) In-Reply-To: <1.5.4.32.19961203122951.009ab054@nessie.mcc.ac.uk> from "Simon Cooke" at Dec 3, 96 12:29:51 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: 526 Lines: 16 On Tue, 03 Dec 1996 12:29:51 +0000, Simon Cooke said: > In that case, define new tags: > APPLICATION > FILE > Which is what these files will appear as in the directory. Then the programs > which have to use them can make the decision what to do with them. And if you really want to know what a file is, have a command (called "file", perhaps :-) ) which reads the first bit of a file and tries to work out what it is. The user could have a list of possible file types and store it somewhere, say in /etc/magic. :-) imc From imc Tue Dec 3 13:42:49 1996 Subject: Re: SOS NOS and DOS To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:42:49 +0000 (GMT) In-Reply-To: <961203063721_1520643572@emout12.mail.aol.com> from "BrenchleyR@aol.com" at Dec 3, 96 06:37:22 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: 487 Lines: 12 On Tue, 3 Dec 1996 06:37:22 -0500, BrenchleyR@aol.com said: > > CLI: cd /foo and BASIC: DIR="/foo" > > rm test ERASE "test" > > prog x y z OPEN TO 10: LOAD "prog" CODE 32768: CALL > > 32768,x,y,z > Well I've used many different systems, but Basic does have the advantage that > more 'normal' people will understand the Basic syntax. Huh? You still say this after looking at the above? imc From imc Tue Dec 3 13:44:36 1996 Subject: Re: SOS NOS and DOS To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:44:36 +0000 (GMT) In-Reply-To: <961203063718_1353502580@emout10.mail.aol.com> from "BrenchleyR@aol.com" at Dec 3, 96 06:37:19 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: 436 Lines: 10 On Tue, 3 Dec 1996 06:37:19 -0500, BrenchleyR@aol.com said: > But my > point is that using * in the way that it has been has to be seen a being > against the normal rules. What rules? Whose rules? You keep saying that it's "illegal" and "against the rules" but I have yet to see any evidence that these so-called rules exist anywhere except inside your head! imc From imc Tue Dec 3 13:47:46 1996 Subject: Re: Disc/k To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:47:46 +0000 (GMT) In-Reply-To: <1.5.4.32.19961203102205.009bc690@nessie.mcc.ac.uk> from "Simon Cooke" at Dec 3, 96 10:22:05 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: 227 Lines: 8 On Tue, 03 Dec 1996 10:22:05 +0000, Simon Cooke said: > I spy with my little eye something beginning with RW. Don't you mean something beginning with BS? "Rwanda" is the only thing I can think of beginning with rw. :-) imc From imc Tue Dec 3 13:50:49 1996 Subject: Re: Disc/k To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:50:49 +0000 (GMT) In-Reply-To: from "Andrew M Gale" at Dec 3, 96 10:15:58 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: 633 Lines: 14 On Tue, 3 Dec 1996 10:15:58 +0000 (GMT), Andrew M Gale said: > People realised that diskette was a gobfull, so started calling > them discs again. But certain stupid ****s reasoned that > disk was the abbreviation of diskette, completely ignoring the > fact that diskette was itself an extension of disc. Nope, not true. The VM/CMS command to list your DASDs (which was probably invented while people were still using 8 inch floppies) is: "Q DISK". "Disk" is the American spelling of "disc". However, as with "programme" vs "program" we have come to use the American word for disk because that's where the term originated. imc From imc Tue Dec 3 13:52:04 1996 Subject: Re: Proposed Changes 1.3 To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:52:04 +0000 (GMT) In-Reply-To: <1.5.4.32.19961203100936.008f2364@nessie.mcc.ac.uk> from "Simon Cooke" at Dec 3, 96 10:09:36 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: 598 Lines: 14 On Tue, 03 Dec 1996 10:09:36 +0000, Simon Cooke said: > >Try to copy a file of the type 'ZX-Snap' (or whatever it is called) > >file made with the system disk (or that cool converter from nvg) from one > >disk to another. Is it hard? > >COPY "D1:spyhunt" TO "D1:spyhunt" > It's not a bug - it's a feature. Namely to stop people copying snapshots for > all and sundry. Yes well I expect it is because the copy command doesn't expect to have to copy the directory entry verbatim as well as the file. Not really much you can do about that unless you want it to special-case snapshot files. imc From imc Tue Dec 3 13:54:02 1996 Subject: Re: Proposed Changes to DOS and ROM To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:54:02 +0000 (GMT) In-Reply-To: from "Si Owen" at Dec 3, 96 07:33:49 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: 693 Lines: 16 On Tue, 3 Dec 1996 07:33:49 +0000 (GMT), Si Owen said: > yacc and bison use a data stack to store states without any expensive > recursive _function_ calls. It's possible to recurse much deeper without > running out of stack space. Oh OK, you can eliminate recursion using a loop by implementing your own stack. Hardly a productive thing to do though. > A good way to try and kill most compilers is to use an expression with 100 or > so '('s since each open bracket causes 3 or 4 function calls to implement > precedence with terms, factors etc. Hours of fun :-) (Sam C?!) Well with 8 megs of stack space I can type a Rexx expression with about 10000 nested pairs of parentheses. imc From owner-sam-users@nvg.unit.no Tue Dec 3 13:58:17 1996 From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: Edinburgh Uni (CS and MATHS) To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:32:11 +0000 Subject: Re: SOS NOS and DOS Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 799 Lines: 15 > Because it allows something after the * that is why. And what's wrong with that? The * wildcard stands for 'stuff', and not specifically 'stuff to the end of the string'. How else would you propose to delete all the useless .tmp files cluttering the hard drive? Oh - I'd quite like a method to delete all 'old' filenames, eg, an extensive delete command, that takes parameters specifying which files to delete, eg, older than 1 month, or all hidden files, etc (Maybe MasterDos did this, never got it, couldn't afford it) +---------------------------------------+------------------------+ | a shot in the dark with a rubber gun | wizards and 3D an | | http://www.geocities.com/area51/5636/ | unbeatable combination | +---------------------------------------+------------------------+ From owner-sam-users@nvg.unit.no Tue Dec 3 13:58:35 1996 From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: Edinburgh Uni (CS and MATHS) To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:36:10 +0000 Subject: Re: "SHELL" (was Re: SAMSON-DOS personality test (long)) Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 565 Lines: 13 > >Nothing wrong with having a CLI that you can access BASIC from by doing > >"BASIC", or a BASIC that you can access the CLI from by typing "SHELL" > > > >Simon > > Two words to that idea and the second one is OFF. Bet the first one is BLAST. I don't see anything wrong with the idea, mesel'. +---------------------------------------+------------------------+ | a shot in the dark with a rubber gun | wizards and 3D an | | http://www.geocities.com/area51/5636/ | unbeatable combination | +---------------------------------------+------------------------+ From owner-sam-users@nvg.unit.no Tue Dec 3 13:58:47 1996 Message-Id: <1.5.4.32.19961203133909.009b118c@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Dec 1996 13:39:09 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re:SOS file types Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 617 Lines: 16 At 13:29 03/12/96 +0000, you wrote: >Yes - if file types are to be used, keep them general. >Eg, GIF IMAGE, BITMAP IMAGE rather than GIF89aINTERLACED IMAGE, >GIF89aNONINTERLACED IMAGE, GIF87 IMAGE, BITMAP RGB COMPRESSED, BITMAP >RLE COMPRESSED, etc Actually, GIFs and BMPs don't need this -- they've already got that header info in the format themselves. All files should start off as pure data when copied from other systems. All new files should take the magic string approach, all old ones will have the header system modified slightly for the new DOS anyway (at least, that's how I see it happening). Simon From owner-sam-users@nvg.unit.no Tue Dec 3 13:59:02 1996 Message-Id: <1.5.4.32.19961203133908.009b6f2c@nessie.mcc.ac.uk> X-Sender: scooke@nessie.mcc.ac.uk X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Dec 1996 13:39:08 +0000 To: sam-users@nvg.unit.no From: Simon Cooke Subject: Re: Disc/k Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 137 Lines: 10 At 13:23 03/12/96 +0000, you wrote: >Status: > >> I spy with my little eye something beginning with RW. >eh? Religious War. Simon From owner-sam-users@nvg.unit.no Tue Dec 3 13:59:31 1996 From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: Edinburgh Uni (CS and MATHS) To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:44:24 +0000 Subject: Re: Proposed Changes to DOS and ROM Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 410 Lines: 8 > Perhaps we could also have an option to replace the screen blanking > with your own screensaver :) Another SRAM option there methinks =) +---------------------------------------+------------------------+ | a shot in the dark with a rubber gun | wizards and 3D an | | http://www.geocities.com/area51/5636/ | unbeatable combination | +---------------------------------------+------------------------+ From owner-sam-users@nvg.unit.no Tue Dec 3 13:59:37 1996 From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: Edinburgh Uni (CS and MATHS) To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:42:51 +0000 Subject: Re: Wild Cards. Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 2144 Lines: 46 > "Wild Cards: many computer systems use Wild Cards to help matching routines > perform in a more flexible way. By common concensus ? is used to match any > single character (any char) # is used to match with a number (some systems > allow this to also match with space and decimal point) and * is used to match > any number of characters from that point to the end of the field." But, 'many computer systems' use the * in the bastardized-but-more-friendly way we all love as opposed to what GCSE teachers are talking about these days. Amigas use '#?' instead of '*' - explain that one! > So, if his teacher told him no lies, then things have not changed since I > learnt programming back in the late 70s.. > If a filename is "ANYNAME" then typing ERASE "*.CODE" will erase it if the > standard rules are followed. .. or at least give a syntax error (characters following * wildcard or something) > Methinks (well I do sometimes) that the problems come from that dreaded > MS-DOS, where they mix the device, the directory path, the filename and the > file extension all on one line. Poo. Stinks. Not nice. 'Salright. UNIX does it too, I beleive. Maybe it doesn't. Don't like UNIX anyway. > When in MS-DOS you type DEL c:\mysub\myfile.bas you are enterings a drive or > device, a sub directory, a filename, and the file type/extension. It uses : \ > and . as delimiters. Not nice, three different delimiters in one line (four > if you count the space after the DEL) no wonder MS-DOS is so shitty. Eh? What's so shitty about using many delimeters. If all the delimeters were the same, would there not be a bigger problem? Or are you suggesting the above command /should/ be implemented as c: cd \ cd mysub del myfile.bas followed by some 'miraculous' change directory back to where you started, whichever drive / directory / subdirectory that may have been... +---------------------------------------+------------------------+ | a shot in the dark with a rubber gun | wizards and 3D an | | http://www.geocities.com/area51/5636/ | unbeatable combination | +---------------------------------------+------------------------+ From imc Tue Dec 3 13:59:55 1996 Subject: Re: Proposed Changes 1.3 To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:59:55 +0000 (GMT) In-Reply-To: <199612021336.NAA02705@BITS.bris.ac.uk> from "Stephen Harding" at Dec 2, 96 01:36:02 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: 402 Lines: 10 On Mon, 2 Dec 1996 13:36:02 +0000 (GMT), Stephen Harding said: > SAMbasic seems to treat CODE files and 'snap' files differently when they > are the same. They are not the same. For a start, snap files have no 9-byte header. Secondly, snap files have a load of info (namely the register block) dumped into the directory. This is never accessed except when you load or save the file as a snap. imc From owner-sam-users@nvg.unit.no Tue Dec 3 14:02:03 1996 From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: Edinburgh Uni (CS and MATHS) To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:46:14 +0000 Subject: Re:SOS file types Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 425 Lines: 8 > A better way: at the beginning of the file, have four characters: Is this the beginning of the file name or its directory entry? Presumably the latter ;) +---------------------------------------+------------------------+ | a shot in the dark with a rubber gun | wizards and 3D an | | http://www.geocities.com/area51/5636/ | unbeatable combination | +---------------------------------------+------------------------+ From imc Tue Dec 3 14:03:30 1996 Subject: Re: SOS file types To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 14:03:30 +0000 (GMT) In-Reply-To: from "Dave Hooper" at Dec 3, 96 01:46:14 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: 313 Lines: 10 On Tue, 3 Dec 1996 13:46:14 +0000, Dave Hooper said: > > A better way: at the beginning of the file, have four characters: > Is this the beginning of the file name or its directory entry? > Presumably the latter ;) No, at the beginning of the file. Actually in the file. As part of the file's contents. imc From owner-sam-users@nvg.unit.no Tue Dec 3 14:09:12 1996 From: Dave Hooper <9531427@EIGG.SMS.ED.AC.UK> Organization: Edinburgh Uni (CS and MATHS) To: sam-users@nvg.unit.no Date: Tue, 3 Dec 1996 13:51:47 +0000 Subject: Re:SOS file types Priority: normal X-Mailer: Pegasus Mail for Windows (v2.42a) Message-Id: Reply-To: sam-users@nvg.unit.no Status: RO Content-Length: 1118 Lines: 28 > >Eg, GIF IMAGE, BITMAP IMAGE rather than GIF89aINTERLACED IMAGE, > >GIF89aNONINTERLACED IMAGE, GIF87 IMAGE, BITMAP RGB COMPRESSED, BITMAP > >RLE COMPRESSED, etc > > Actually, GIFs and BMPs don't need this -- they've already got that header > info in the format themselves. But, then you don't get the identification in a directory listing, unless you are prepared to read the first few bytes of every file... The file types are mainly for the user anyway (the OS /could/ feasibly ignore them) What about compressed files? Could there be a bit in the directory header indicating compressed? Then we could get the composite filetype COMPRESSED GIF IMAGE formed from the file type byte/s and the compressed flag. Archives could be handled as ARCHIVE FILE and COMPRESSED ARCHIVE FILE (although I guess most (all?) archives are compressed) +---------------------------------------+------------------------+ | a shot in the dark with a rubber gun | wizards and 3D an | | http://www.geocities.com/area51/5636/ | unbeatable combination | +---------------------------------------+------------------------+