Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: notesnews 0.1 (unido 12/05/84); site unido.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!mcvax!unido!hmm From: hmm@unido.UUCP Newsgroups: net.lang.forth Subject: Re: Why FORTH screens? Message-ID: Date: Tue, 26-Mar-85 13:01:00 EST Article-I.D.: unido.nf9600001 Posted: Tue Mar 26 13:01:00 1985 Date-Received: Tue, 2-Apr-85 03:47:53 EST References: <7349@watrose.UUCP> Sender: notes@unido.UUCP Lines: 35 Nf-ID: #R:watrose:-734900:unido:9600001:000:1482 Nf-From: unido!hmm Mar 26 16:01:00 1985 I'm using FORTH for about 3 years on my TRS-80 Mod.I without underlying operating system. After zapping my Level II ROMS I burnt an EPROM with a simple disk booter and adapted a FORTH system from a friend. It is real fun for games and little programs, but the memory (32k) and my spare time are too limited for any serious application. I have only two objections to the screen concept: 1. You get a lot of fragmentation. I am used to start new programs some screens away from the last used screen to provide space for changes to the older programs. This can be very annoying if you use up to 30% of the disk for empty screens ! 2. Since I don't have much space, I tend to sqeeze my definitions on the screens. It's awful, but it's the only way to use space economically. I would like to have some expandable concept: Named files which consist of screens internally. Maybe there should be two file types: Raw block files and text files. Text files have line-oriented text and should only be accessed by the editor and the load word. Block files are for data, but they are also editable and loadable. Every block file would have screens 0..N and should be used for the data of one program. Common routines for random generator, game subroutines etc could reside in their own files. What do you think of it ? Hans-Martin Mosner Universitaet Dortmund (Germany) ihnp4!hpfcla!hpbbn!unido!hmm {decvax,philabs}!mcvax!unido!hmm