LTCD_070816.ISO

This commit is contained in:
Terry A. Davis authored and minexew committed 2018-09-08 21:45:20 +02:00
1 parent d14bbc24f9
commit 0e9364ff4c
506 files changed
+157705 -41812

No files matched your search

+94
View File
@@ -0,0 +1,94 @@
$WW,1$$FG,5$$TX+CX,"Introduction"$$FG$
There's no point being an inferior immitation of $FG,2$Windows$FG$. I picked a niche and specialized -- $BK,1$programming as entertainment$BK,0$. I chose simplicity intentionally over conventional approaches. This is not a platform for games, but a platform for writing games. Hobbiest programmers are a higher priority than commercial developers.
I have no plans to support multimedia or the Internet. This is a supplemental operating system (like supplemental insurance). Duel boot and do that stuff on your primary operating system. There's no reason to reinvent the wheel and, unlike what I've done in LoseThos , I see nothing I could add to a browser or multimedia player -- you can't change the file formats.
LoseThos has no networking and will never have networking so there's no need for security. Did an $FG,2$Apple II$FG$ or $FG,2$Commodore 64$FG$ have security? I mention these classic systems because the intended usage of LoseThos is similar, only modern.
LoseThos is not for desktop publishing or word processing. It's document format is designed for interaction on the screen and does not lend itself to printing. Click here for a hint $HS$This text is hidden until you click on it.$HE$.
When I started programming in 1981 on an $FG,2$Apple II$FG$, it took two lines of code to draw a line on the screen and it could be typed from the command line or in a $FG,2$BASIC$FG$ program:
$FG,4$HGR
HLINE 1,1 TO 30,30$FG$
Programming is far more intimidating, now. It's not uncommon for a "Hello World" application to take 50 lines of code.
Most game development packages for amateurs are like fitting a square peg in a round hole. People want good looking games, but don't have "the chops". $FG,2$LoseThos$FG$ games will not look as good, but there is complete freedom -- you won't be constrained. I suggest you stick to 2D instead of 3D.
Game companies employ more artists than programmers. In the past, games were often made by individual programmers. Modern games are more like movies, relying on lots of "canned" video and sound.
I had to have an option for simple graphics so I made a graphic layer that is "persistent" (stays on the screen without having to be refreshed.) There is a second layer which is redrawn each refresh. The two layers are merged (XOR), along with a text layer, to form the screen image. There's actually a persistent layer for each CPU, but beginners don't need to know that.
I hate fighting with fonts. There will always be just one font, a fixed-width font, because variable width letters screw-up tables. Now, I fight with colors and it's about the same. Oh, well.
I like $FG,2$ASCII$FG$ more than $FG,2$UNICODE$FG$. I'll stick to the American market. I might add extended $FG,2$ASCII$FG$, but not $FG,2$UNICODE$FG$. Let programmers in other countries write their own operating systems.
The text layer allows animated character graphics, which were fun. It's been modified to shift the character in each position horizontally or vertically, so you can do $SY,-3$superscripts $SY,0$or $SY,3$subscripts$SY,0$.
I hated learning one language for the command line and another for programming. With $FG,2$LoseThos$FG$, the command line feeds right into the $FG,2$C+$FG$ (more than $FG,2$C$FG$, less than $FG,2$C++$FG$) compiler, line by line, and it places code in memory it $LK,"MAlloc","MN:MAlloc"$()s. It's like the compiler is paused. Naturally, you $FG,2$#include$FG$ a program to load it into memory and, usually, start it. During boot, many files get compiled before it allows you to access the command line. All the header declarations for the operating system are already compiled and are available for use in your programs without needing to $FG,2$#include $FG$them. Everything is truely compiled and nothing is "interpreted".
Statements outside the "scope" of a $FG,2$C+$FG$ function execute immediately. There is no $FG,2$main()$FG$ function. Instead, you give a meaningful name and invoke that function by calling it with a statement outside the scope of any function, usually at the bottom of your file.
I started with $FG,2$C$FG$ syntax, but didn't like the command line for a directory listing looking like this:
$FG,4$Dir("*.*",FALSE);
$FG$So, I added default parameters from $FG,2$C++$FG$ and it looked like this:
$FG,4$Dir();
$FG$I didn't like that, so I made parentheses optional on calls with no parameters and it looks like this:
$FG,4$Dir;$FG$
The only side effect in changing the syntax is that when you specify the address of a function, you must include a $FG,2$&$FG$ in front (which is better anyway).
Once I was no longer using standard syntax, I decided to change everything I didn't like. Here are the new $LK,"operator precidence","FA:::/LT/Compiler/CmpInit.CPZ,OP_precidence"$ rules. See $LK,"Departures from C/C++","FI:::/LT/Doc/Differences.TXZ"$.
There are no object files in LoseThos and, normally, you don't make executable files either, but you can. That's known as "static" compilation.
I looked at $FG,2$Linux$FG$ code to learn how to use a hard drive and, damn it was confusing. It had so many layers it was hard to find the actual $FG,4$IN$FG$ and $FG,4$OUT$FG$ instructions that access the hardware. I decided I'd keep layering to a minimum. Why have open source software if people can't understand and modify it?
One problem with $FG,2$Linux$FG$ is it handles many platforms and different pieces of hardware so it's full of $FG,4$#if$FG$'s and I found it difficult to read. I don't know if LoseThos will become that way or not. I'm starting with 64-bit CPU's and hardware of that vintage, so I have no reason to support the majority of old hardware.
I cherished a book called "Mapping the $FG,2$Commodore 64$FG$" when I was a kid because it literally told what everything did. I had a lot of fun. $FG,2$Commodore$FG$, Ticketmaster's $FG,2$VAXTMOS$FG$ and $FG,2$MATLAB$FG$ are influences.
I made the kernel (known as OSMain) intentionally simple, so everybody could understand and tinker. Technically, it shouldn't be called a kernel since $BK,1$everything always runs in kernel mode$BK,0$. All code always has full priviledge. User programs can access all memory, use all CPU instructions, access all I/O ports directly, and can access all parts of the disk. My system reboots in 3 seconds if I crash it and I like total freedom as a programmer.
Tasks have no priority scheme and are never removed from the queue. Instead they poll whatever they are waiting on and swap-out. This keeps it simple. It's only a problem if you have too many tasks busy.
The file system is simple so no body can sue me. There is an allocation bitmap and all files are stored contiguously. You cannot grow files. Files have checksums, however. Filenames ending in "Z" are stored compressed. LoseThos supports direct block access into files. There is no $FG,2$PATH$FG$ but parent directories are searched when a file is not found. See $LK,"LTZ","FI:::/LT/Doc/LTZ.TXZ"$ for transferring files to your primary partition.
At one job I made a hardware device which plugged into the parallel port. When we upgraded from $FG,2$Win98$FG$ to $FG,2$WinXP$FG$, hardware ports became off-limits. A coworker found some software to enable them. $FG,2$LoseThos$FG$ allows full access to ports. Some hobbiests might want to plug hobby hardware projects into the parallel port.
I like being able to turn-off interrupts ($FG,2$Cli; $FG$and $FG,2$Sti;$FG$) when I change a structure used in a multitasking environment. $FG,2$LoseThos$FG$ runs all programs in kernel mode, so no instructions are restricted. Turning-off preemption with $LK,"Preempt","MN:Preempt"$() is a less drastic measure that is usually sufficient.
The graphic resolution is poor, 640x480x4. I've decided to set this as the one and only resolution, forever. It uses minimal CPU. A fixed size keeps it simple. Everybody has the same appearance on their screen. It's good for mobile devices. VGA is currently the least common denominator on PC's. Look on the bright-side -- you won't spend your time twiddling pixels.
$FG,2$LoseThos$FG$ is for hobbiest programmers on single user home computers. The focus task is all-important so "symmetrical multiprocessing" is almost pointless. When it comes to multicore utilization, all resources should be devoted to the focus task. For now, you must explicitly make use of mutlicore in your programs. You can make use of $FG,4$Gs->grbase$FG$, a persistent graphics layer present for each core. It gets merged (XORed) to make the final image. Multicore is fun. A practical use I plan is placing time-critical tasks on a core which doesn't allow long periods with preemption turned-off.
I didn't want to use virtual memory, but I had to for 64-bit mode. It's just as though there is no virtual memory, except you can mark pages as uncached or write-through for MultiCore programming.
There is no distinction between "task", "process" or "thread". All have a $LK,"TssStruct","MN:TssStruct"$() pointed to by $FG,4$Fs->$FG$ while $FG,4$Gs->$FG$ points to a $LK,"CPUStruct","MN:CPUStruct"$ for the current CPU. Each task can have just one window.
In LoseThos , "$FG,2$Adam$FG$" refers to the father of all tasks. He's never supposed to die. Since task's inherit the symbols of parents, system-wide stuff is associated with $FG,2$Adam$FG$. His heap is like kernel memory in other operating systems. He stays in a server mode, taking requests, so you can ask him to $FG,2$#include$FG$ something which places that code system-wide. A funny story is that, originally, I called it the "root" task and even had a "$FG,2$/LT/Root$FG$" directory.
For easy back-up, place everything you do in your $FG,2$HOME$FG$ directory and subdirectories. That should make upgrading easy, too. To make an account use $LK,"MkDir","MN:MkDir"$() to create a directory under $FG,2$/LT/Accts$FG$. It will be $FG,2$HOME$FG$ if you boot to it. The customizable start-up scripts should go in your $FG,2$HOME$FG$ directory. The default start-up files are in $FG,2$/LT/Accts$FG$, the parent of all accounts. Copy the start-up files you wish to customize into $FG,2$HOME$FG$ and modify them. See $LK,"Account Files","FF:::/LT/Doc/GuideLines.TXZ,ACCOUNT FILES"$.
Typically, your usage pattern through the day will be repeatedly left or right clicking on filenames in a command line $LK,"Dir","MN:Dir"$() listing. You left-click files to edit them and right-click to $FG,2$#include$FG$ them. To begin a project, type $LK,"Edit","MN:Edit"$(""); and supply a filename. Press $FG,2$ESC$FG$ to save and exit the file. You'll need to do a new $LK,"Dir","MN:Dir"$() command, periodically, so make a macro. Access the macro by pressing the $FG,2$WINDOWS$FG$ key, cursoring until you are on top of it and pressing the $FG,2$SPACE BAR$FG$.
$FG,2$CTRL-T$FG$ toggles plain text mode, similar to html. $FG,2$CTRL-L$FG$ inserts a nongraphic widget. $FG,2$CTRL-R$FG$ inserts a graphic or edits the graphic under the cursor.
$FG,2$CTRL-ALT-ESC$FG$ creates a new terminal window. $FG,2$CTRL-ALT-X$FG$ kills a window. You'll do these periodically. $FG,2$CTRL-SHIFT-F$FG$ pops-up the "favorites" document. The favorites can be used from anywhere. You can put anything there. I use it as a handy TODO file, along with common links.
$LK,"Grep","MN:Grep"$() is your best friend. There's a wrapper function called $LK,"F","MN:F"$() in your $FG,2$User.CPZ$FG$ file. $LK,"Grep","MN:Grep"$() can also be used to replace strings across multiple files.
As you browse code, use the $FG,2$WordStat$FG$ window to look-up functions, etc. Press $FG,2$CTRL-SHIFT-F1$FG$ (or whatever) to follow a symbol to it's source. You can browse deeper and deeper. You go back with $FG,2$CTRL-Q$FG$.
Use the $LK,"Help Index","FI:::/LT/Doc/HelpIndex.TXZ"$ to find-out what exists. It's broken down by category. A link to the help index should be on your menu. ($FG,2$WINDOW's KEY$FG$). Also, look in the $FG,2$/LT/Demo$FG$ directory.
$MA+A-X+PU,"Take Tour","SpawnUser(\"Cd(\\\"::/LT/Accts/Tour\\\");;AutoFile(\\\"Tour\\\");\r\");"$
+25
View File
@@ -0,0 +1,25 @@
$WW,1$$FG,5$$TX+CX,"Proverbs"$$FG$
Writing your own code is more fun then modifying someone else's. Sadly, I heard 90% of programmers work on maintaining code. One good thing about looking at other people's code is it's a good way to learn -- you can learn what to and what NOT to do.
Code written by one person is less redundant than code written by a team because one person knows when he is reinventing the wheel. It is more vertical, meaning deeper levels of subroutines.
When working on other people's code, you tend to be defensive, using caution about uncertain items and this adds unnecessary code.
Documentation which is out-of-date is worse than no documentation. With LoseThos, I tried to keep documentation right by code.
If you call common low-level routines, there is a potential for huge added functionality with changes to the low level routines, benefitting everything. Imagine modifying a file choosing dialog.
Not all features are good to use. I've seen cases where people use macro functions ($FG,2$#define$FG$) to make C code look like C++ code. It becomes one-more layer you have to look-up to understand. An advantage of nonvertical coding is readibility. It is possible to get carried away with nonstandard library routines.
One mentor discouraged using abbreviations. One advantage of nonabreviated labels is there's no uncertainty on how to spell them. Typing is never what slows you down, except maybe at the command line. Uncertainty is what slow you down.
One mentor always put "temp" on the beginning of local variables -- "$FG,2$tempd$FG$" instead of just "$FG,2$d$FG$". The reason is probably for text searches. I've somewhat eliminated this need with the "whole label" search feature.
$LK,"Grep","MN:Grep"$() is my best friend. I use a wrapper function $LK,"F","MN:F"$().
It's easier to write a command-line interface than a GUI one and if it's for personal use, why not?
On a modern home computer, the only things which take significant memory are disk cache, graphics and sound. Code related items do not. If you had a million lines of code and stored an 8-byte value telling where each line was located, that would be 8 Meg. I have 2Gig, so that would be 0.4 %. Structures for classes and functions amount to nothing.
A home computer doesn't really need a big disk cache. How often do you listen to the same multimedia items more than once? If you have a server for a database, sure you need disk cache.
+62
View File
@@ -0,0 +1,62 @@
/*
$FG,2$$WW,1$You may wonder why I do scaled integer arithmetic in the graphics routines. The transformation matrix in a $LK,"GrBitMap","MN:GrBitMap"$, r, is stored as 8-byte integers shifted 32 bits left to allow fractions. This is faster than floating point (double) arithmetic, but less accurate.
$WW,0$
$FG$*/
#define SAMPLE_SIZE 100000000
I4 coordinates[65536];
void TimeIns()
{
U8 start1,end1,start2,end2,overhead_time,test_time;
double reg d1;
I8 reg i,reg temp,reg d2,reg sum;
//Set-up some sample coordinates
for (i=0;i<65536;i++)
coordinates[i]=RandU4;
Preempt(OFF);
//$FG,2$Measure Loop Overhead$FG$
start1=GetTimeStamp;
for (i=0;i<SAMPLE_SIZE;i++) {
}
end1=GetTimeStamp;
overhead_time=end1-start1;
//$FG,2$Measure double arithmetic$FG$
d1=Sin(1.0);
sum=0;
start2=GetTimeStamp;
for (i=0;i<SAMPLE_SIZE;i++)
$FG,4$ sum+=d1*coordinates[i&65535];
$FG$ coutln "Double Arithmetic Sum :",sum;
end2=GetTimeStamp;
test_time=end2-start2;
PrintF("Double Arithmetic Cycles: %10.5f\r\n",
(test_time-overhead_time)*1.0/SAMPLE_SIZE);
//$FG,2$Measure scaled integer arithmetic$FG$
d2=Sin(1.0)*0x100000000;
sum=0;
start2=GetTimeStamp;
for (i=0;i<SAMPLE_SIZE;i++) {
$FG,4$ temp=d2*coordinates[i&65535];
sum+=temp.i4[1];
$FG$$FG$ }
end2=GetTimeStamp;
test_time=end2-start2;
coutln "Scaled Integer Sum :",sum;
PrintF("Scaled Integer Cycles :%10.5f\r\n",
(test_time-overhead_time)*1.0/SAMPLE_SIZE);
Preempt(ON);
}
TimeIns;