Subject: Re: Re: Bob's amazing hard-drive plans... In a message to Johnathan Taylor <28 Oct 94 15:06> [EMAIL PROTECTED] wrote:
Ia> Ia> Apparently-to: jet Ia> Date: Fri, 28 Oct 1994 14:06:07 +0100 Ia> From: [EMAIL PROTECTED] Ia> On 27 Oct 94 04:59:00 +0000, Johnathan Taylor said: >> Subject: Re: Bob's amazing hard-drive plans... Ia> Just a small point... could you tell Ia> your software to put this line in the Ia> header instead of in the body of your message? That is a bug in the OLR mail door installed on my host system, it's beyond both my and the sys adminins control and apparently random on weither it gets included or not, If you want to discuss that problem further best go to email:-) >> Most other serious operating systems >> are disc based, even if the larger memory >> models use a substantial disc-buffer in >> ram to reduce drive accesses in a >> multi-tasking enviroment! Ia> Most other serious operating systems Ia> assume that you have a large rapid- Ia> access disk drive and a CPU which has Ia> MMU and basic multitasking facilities Ia> (note: MSDOS does not qualify as a Ia> "serious" operating system). Can't get more rapid than a 4Meg ramdrive! Since when is an 80x86 cpu designed for multi-tasking? AFAIK only transputers are inherintly designed to multi-task all the rest just have glue logic added on chip like mmu's etc. How many clock cycles does it take an 80486 running linux, NT, or a real AT&T unix to do a complete context switch? LOADS! T225 @ 25MHz can do it in 800nS! >> AFAIK gzip is useless without tar to >> make sam-dos filetypes a generic serial >> file! Ia> Not at all. Most things that get Ia> compressed are code files and they don't Ia> come with any particular information Ia> that you need in order to run them Ia> (they have a start address, but it Ia> isn't strictly necessary. Some existing Ia> compressors such as powercrunch (which Ia> isn't that powerful at all) make you Ia> specify the starting address for Ia> obvious reasons. In any case, the gzip Ia> header might well be able to contain Ia> the filetype information. You reckon? IF I were to want an archiver for Sam-native files I'd want it to retain date-stamp, type, start address, load-page, true length, plus directory info too like auto-run address and the various protection flags. Plus I'd want to be able combine assosiated files into a single archive not a seperate lose-able bunch of seperatly compressed files! To my knowlegde gzip compression is just a binary stream compressor much like the CP/M CRUNCH single file compressors... The only serious use I've seen it put to is to compress tar archives in file repositries, and recently used to compress packed newsgroup bundles for uucp/slip xfers. >>LHARC could be used to do that >> much simpler and in less space and in one process! Ia> I don't know what LHARC is. Why is LHarc format is a generic PD archive envelope definition that is supported from CP/M, BBC-B, IBM-CLONE, QL, and generic unix! even the humble speccy now has a LHARC faker that was used to store qwk reply packets so a BBS qwk door could digest it! It includes in its definition a variable lebgth area set aside to contain OS dependant data that wont be used to read the data on other platforms, there's upto almost 200bytes space for operating system specific data in each archived files header! More than enough to hold ALL sam-specific data. .LHA and .LZH files are examples of the LHArc archive. And the C source is freely available if you bothered to look! Ia> there such a large variety of file Ia> formats around (lbr, arc/ark, lha, Ia> hqx, zip, zoo, lzh, several forms Ia> of lzw, tar, ...)? It seems that every Ia> time someone wants to archive Ia> something they invent a new format for Ia> it instead of using one of the Ia> commonly available ones. Anyway, the The reason is simple, copyright restrictions and ego:-( Ia> compression rate of ".tar.gz" is Ia> hard to beat, so if you want to make Ia> everyone use lharc you'd better be Ia> sure of what you are doing... NO LHarc method beats the ZIP deflate alogarithm on achieved ratios. BUT they ALL require much LESS working ram space to compress and de-compress and the last 2 main methods -lh1- & -lh5- do produce respectable rates of compression, maybe 3 - 5% behind deflated files... -lh1- can decompress in less than 32k ram including tables! >> Obviously the multi-task facility would >> be functional but NOT for general use. >> It'd normally only get used if say a >> remote user was logged in and the >> operator (me) needed to do somthing important! Ia> A remote user logged in to a Sam? Get real! I have a BBS that runs on my SAM that works quite well and has had callers logged in when I had it online! The only reason I didn't keep it going is that I only have one SAM and it doesn't multi-task and no HD meant it was very difficult to maintain my normal mail activities and keep the BBS going, obviously:-( >> otherwise it'd be only running >> a single task but using the unix parent/child processing to >> seriously simplify the linking of programs actions to make >> a powerful if not blindingly fast system:-) Ia> You can't make a useable Unix process Ia> hierarchy on a Sam. It hasn't got Ia> basic memory allocation facilities. Says you eh? Obviously you think unix is ONLY the variety of system that is available today... UNIX doesn't HAVE to have an MMU! Virtual memory is NOT a basic requisit of a UNIX system, maybe it has become one for modern inefficient programmers! Because you cannot conceive of how it can be done, doesn't mean that it cannot be done by someone with a tad more inginuity and persistance eg. me or anyone else that wants it bad enough to learn how rather than cop-out and say *you can't do that!* unix with virtual-memory has been done on a twin 68000 without an integral MMU or the ability to interupt the cpu mid instruction! On that system it was done by an external MMU and the twin cpu's operating one instruction behind the other! Then IF an access violation ocoured the first cpu would be halted and the second one interupted prior to executing the instruction that caused the violation. The the violation was then dealt with by the trailing interupted cpu and the leading cpu is reset to the condition prior to the violation from the trailing cpu and then execution continues... There are MANY ways around technical problems and if all else fails certain comprimises/cheats can be made;-) Ia> Sure, if all your programs are below Ia> 32K then you can page them in and out Ia> without too much trouble. But how Ia> are you going to run programs which Ia> are over 32K? There's no way you can Ia> prevent one process from reading or Ia> scribbling over another process's memory Ia> and/or screwing up the entire system. Ever heard of total swapping? In such a system the entire task allocation is swapped to a fast HD or preferably a RAM-DRIVE obviously time for a context switch is increased quite a bit, so the time between context switches is increased acordingly... The user interface to the tasks can be interupt driven to individually allocated NON-swaped ram-buffers so I/O to a given task can continue even after the actual task is out of context which will smooth out the proccessing considerably! Or combined bank swaping of bottom 32k + file swapping of top 25 to 30k! Try 3D thinking, it's much more rewarding than 2D thinking! Ia> Sorry, but if I want a useable Unix Ia> system I'll buy a 486 or a 68040... If I wanted a real FULL-featured Unix and I had the cash I certainly wouldn't buy a 486! 68060 maybe but I'd prefer a DEC ALPHA or an array of T9000's! BUT THAT'S _NOT_ WHAT WE'RE TALKING ABOUT! This is not the unix-users list it's for the sam-users and realisng its inherant limits and working around them a USEABLE if not full-featured unix system IS possible! GET and read the contents of /pub/cpm/uzi/ on oak.oakland.edu and you'll see a *crude but functional* PD unix kernal and filesystem that works on a 64k z80 machine NO MMU, NO banked ram, NO AT&T code! That teaches the *principles* but is by no means the end product. Which because of the sams strengths will be A LOT better than UZI! I dunno this UNIX on a SAM part of this thread smacks of those readers letters in format where a READER says that somthing should be done for the SAM and Bob then goes on to trash the feasable request as invalid or stupid.... eg HD's, Archivers, COMMS etc etc... Or when I suggested that Interupt driven RS232 is possible on the sam everyone I spoke to in the SAM scene said it couldn't be done! Now I've been using it RELIABLY for over a year daily! ALL my OWN work! Hmmm has Bob joined this group using Ians FQDN as an alias? Ian just WHAT do you use (or want to use) your sam for? Do you program in machine-code at the lowest level on the sam? Have you seen and understood unix C source enough to port it to the SAM under any of the current operating systems? Have you seen the source and understood the functions&requirments of a minimal UNIX system? If no then to at least 2 out of 3 of those last questions then please stop saying that it can't be done as your not qualified to judge its viability, sorry. To be honest when I do eventually write any multi-tasking operating systems for MY sam (either unix based or a cp/m+ extension), it'll be for my needs not yours and as I've said before I doubt it'll ever be run on anyone elses SAM mainly because, currently NO other sam can run everything mine can due to lack of data-bus buffering, I don't do user manuals and it'll require more inteligence than the average home-computer user to use it as with any non-gui unix system! CYL. Johnathan. ___ Olms 1.60 [Evaluation] -- |Fidonet: Johnathan Taylor 2:2501/307 |Internet: [EMAIL PROTECTED] | | Standard disclaimer: The views of this user are strictly his own.
