decrazyo / lng-fds Goto Github PK

This is the (new) development tree of LNG (LUnix next generation)
I decided to rewrite it from scratch, because i don't want to use those
old LUnix/LUnix0.8 stuff i've written years ago any more.
I'll try to make better, cleaner code.

The most important changes from LUnix 0.1/0.8:
----------------------------------------------

 o  reduce the amount of static memory that is used for per process
    data. (keep it in a dynamically allocated page together with the copy of
    the process' stack and zp).
    
 o  use much more zp in the kernel.
 
 o  try to be less C64 specific in the kernel core.


  Any help is welcome !!!!
  (even questions are welcome, because they will help me building a minimal+
  simple+fast kernel)

Porting to other systems
------------------------

 All files that include "c64.h" must be changed.
 (currently: calib.s, console.s, init.s, keyboard.s, tasksw.s)
 You can either write completely new ones for replacement, or (if there are
 not that much things to change [eg. tasksw.s]) add some #ifdef/#else/#endif
 to the original sourcecode.
 
 Example
 -------
   Original file:
   
   ...
   ldx  #40   ; number of chars per lines
   ...
   
   Ported file:
   
   ...
   #ifdef C128VDC
   ldx  #80   ; VDC displays 80 chars per line
   #else
   ldx  #40   ; number of chars per line
   #endif
   ...
      
my TODO list:
-------------
  o  memory management (external memory)
  o  signals (run/stop key...)
  o  friend-list (explain it later:)
  o  environment
  o  more file-ops (mv, chmod, format,...)
  o  80 column console
  o  web-browser ??
  ...
  o  more (usefull) applications ?
   
compiling lunix
---------------

  Case A)

  You have a UNIX system...  (with gcc, and (GNU-)make installed)

  o  Make the develompent tools

     Do a "make devel" in the top level directory. You can also
     change into the devel_utils subdirectory and type "make" there.
     You should get the binaries of luna, lupo and lld. If you want, you
     can move the binaries into a common place (eg. /usr/local/bin) and/or
     add the path of the binaries to the system's search path

     PATH=/path/to/the/binaries:$PATH

     This may not be neccassary since the PATH variable will also be changed
     in the top level makefile.


  o  Make the Commodore64/Commodore128 binaries

     If your target is different from the C64, edit the top level
     makefile - line 14, replace c64 by c128 for example.

     Go into the parent directory and type "make". 

     If you've chaned the target or edited the makefile do a "make clean"
     first !

     Optional: Before making the binaries, change/optimize the
               configuration (edit "Makefile" and/or
               "kernel/<Machine>/config.h")


  o  Make a Commodore64 disk

     type "make package", this will create some selfextracting archives in
     the pkg subdirectory.

     for example:
       core.c64       -> system core
       apps.c64       -> applications
       help.c64       -> optional help files (used by "help" application)

     Copy these files to an empty (commodore-) floppy
     disk. On the C64 type (after inserting the newly created
     disk into drive 8, connected to your C64...)
      
       load"core.c64",8,1
       run 
       (will install the archived files)

       new
       load"...
       ...

     When every thing is installed

       load"loader",8
       run

     Don't expect me to explain, how to transfer binaries to a Commodore
     floppy. (I use a null modem connection between a PC running Linux and
     the Commodore64 running Novaterm9.5)


   o Make an Atari bootable disk

     Edit the toplevel makefile and change the line
     
     MACHINE=c64
     
     to
     
     MACHINE=atari

     and remove everything from MODULES= line

     Configure the kernel to your needs by editing kernel/atari/config.h.

     Then do:

     make distclean
     make devel
     make
     make disc

     which will result in bootable floppy image: pkg/lngboot.atr
     Don't worry with errors after 'make' step because currently applications
     for Atari cannot be built now. However they are binary compatible across
     all supported architectures so you might build system for C64/128 and
     copy applications from there.


   o Make a Commodore floppy

     Do

     make disc

     to build a ready for use floppy with all tools/modules/docs/scripts
     extracted. You can use this floppy with emulator or transfer it to a
     physical media.


   o Notes to the Commodore 128 version

     Edit the toplevel makefile and change the line

     MACHINE=c64

     to

     MACHINE=c128

     Configure the kernel to your needs by editing kernel/c128/config.h.
     Do a "make clean" (maybe even a "make distclean" in the kernel
     subdirectory is required) then "make" and "make package" to get
     a selfextracting archives in pkg (named "*.c128")
     
     Note: the *.c128 files can only be extracted in c64 mode (sorry)

   Note2: The applications in the apps subdirectory are architecture 
          independent and run on the C64 and C128 version of LNG
          without recompilation.


  Case B)

  You don't have the GNU tools available on your system (gcc,make,bash).
  Sorry, you can't build the system from source. But you can still run
  lunix (precompiled binaries for the Commodore64 are included)
  and read the source code..  ;-)



What does micros-hell do ?
--------------------------

  After starting LNG you get a "." prompt, this is the microshell
  (or init) prompt.

  Two commands are available for now:
  load: l <filename> 
  exit: x

  eg.

  l sh

  Will load and execute the "sh" application (default device is a 1541 with
  device number 8)
  sh is the standard LUnix-shell.

  l /disk8/ps

  Is equivalent to "l ps".

  l /disk9/ps

  Will load from device number 9 (for example a second 1541)


Multiple consoles
-----------------
If the kernel has been compiled with support for multiple consoles,
(compile option "MULTIPLE_CONSOLES" set in <MACHINE>/config.h)
you can switch between several virtual consoles using a hotkey sequence.

Init opens a console on startup, after issuing the first command (eg. "l sh")
this command takes over control of the current console. Init now tries to
open a second console, waiting for commands there. This means, that once
you have started a first command, the ". " prompt moves to the next
console. Even after the first command has finished, the init-prompt ". "
stays on the other console. You have to switch to the next console manually
to issue a second command.

Example:
.l sh         (load the first application)
-press F3 to go to the second console-
.l sh         (load the second application)
-press F1/F3 to jump between the 2 applications-
(you can also use SHIFT+COMMODORE to switch between consoles)

Limitations:
There is only one keyboard buffer to store pressed keys!
If the application on console 1 doesn't read from the keyboard, the keyboad
buffer fills up - switching to console 2 with an application running, that
is waiting for keystrokes, will pass all the buffered keystrokes to this
application! (tiggered by the next keystroke)


sh - the LUnix standard command shell
-------------------------------------

  The shell's prompt is "# ".
  Some example commandlines:
    
  # ps
        
  load and execute the PS application
            
  # sh
                
  load and start a subshell
                    
  # ps ! wc
                        
  load and execute PS, pass its' output to WC
                            
  # exit
                                
  leave the shell (you can also press CTRL+d at the beginning of a new line)


Shell goodies:

 History:
  you can reload old commandlines, by using the cursor keys (up/down).

 Line Completion:
  you can ask the shell to complete the current line (using the history of
  old command lines) by pressing the commodore-key (tab-key)


Applications
------------

    (232echo - for debugging)
      testapplication for serial-communication-modules (SERv2-API)
      eg. "swiftlink" module

    (232term - for debugging)
      test application for serial-communication-modules
      dump terminal (exit with CTRL+d) on top of the SERv2-API

    beep
      alert console user by a audible sound. beep prints ASCII code 7
      to standard error output. (the console must support beep)

    buf 
      reads from stdin into internal memory until EOF, then
      passes input to stdout (from memory)
      (nice, if you don't want floppy accesses, while receiving
      uuencoded data from a remote host via TCP/IP)

    cat [file]
      load file (stdin if ommitted) and pass to stdout

    connd port app [args] 
      connect demon, starts to listen on the specified port (0..255)
      and spawns the specified application, when someone connects.
      (needs TCP/IP subsystem)
      eg. "connd 200 sh&"
      offers shell-accesses.

    cp source-file destination-file
      simple file copy (slow)
      for small files (smaller than 30kbyte), i suggest to use 
      "cat source ! buf ! tee destination" instead

    date [-t hh:mm:ss.tt|-d ccyy.mm.dd|-w ww|-z (+|-)hhmm]
      Get/set date and time of RTC clock. You need a supported
      RTC module (or emulate one using ciartc)

    dcf77
      Read time signal from the DCF-77 module and sets time
      and date once a minute using a RTC module (eg. ciartc)

    time [-s hh:mm[:ss](a|p)m]
      set/get time of day directly from CIA1 TOD
      e.g.
        time -s 11:25am

    ftp host 
      connect to a remote host (via TCP/IP) using the Internet
      file transfer protocol (FTP).
      Supported commands:
        cd - change directory
        pwd - view current working directory
        type a/i - set ascii (a) or binary (i) transfer mode
        dir - list files in current directory (needs 80 column screen)
        more - display remote textfile
        get - get remote file
        quit - leave ftp (CTRL+d should also work)
      new: when downloading ftp uses all available internal memory
           for buffering (because disc accesses slow tcp down to a crawl)

    getty speed
      run getty at baud rate 'speed'
      allows to connect a VT100/102/ANSI terminal to your C64
      for a second/remote user

    kill [-sig] pid 
      send a signal to a running process
      valid signals are 0..7 and 9 (default).
      signal 9 terminates the process immediately

    ls [dir]
      list files in current or specified directory
      (the 1541 has just one directory)

    lsmod
      print table of all installed modules

    loop
      loop back packet driver for running local TCP/IP client-server
      applications (off line)

    meminfo
      print summary of usage of internal memory
      owner is the value stored in lk_memown and specifies owner/usage
      of the page(s).

    microterm
      simple terminal emulation
      (depends on serial-communication-module with simple API)

    more
      display text page wise (return - print next line, space - print
      next 20 lines, q - quit)

    ps
      print table of all processes (tasks) in the system
    
    rm [files...]
      remove (delete) files

    sh
      LUnix standard shell

    sleep [sec]
      sleep sec seconds (1 second if sec is ommitted)

    (sliptst - for debugging only)
      small testapplication, receives packet from packet-delivery-module
      (eg. "slip") and makes a hexdump
    
    strminfo
      Print short summary of all allocated streams in the system (open files)
      maj/min is the major and minor number of the device, for example
        3 0 - console 0
        3 1 - console 1
        2 8 - CBM drive 8 (connected to IEC serial bus)
      wr/rd is the number of open writing/reading ends

    tcpipstat
      print status of TCP/IP stack

    tee [file]
      pass stdin to file (or stdout if ommitted)

    telnet host port
      connect to a remote host via TCP/IP
      (see README.tcpip for more details)

    (testapp - for debugging only)
      simple hello world programm
      prints a small message, installs a signal handler (waits for
      signal 2), and consumes some CPU seconds.

    uname [-srvmpa]
      print information about the system
       -s  print operating system name (LNG)
       -v  print OS version
       -r  print OS release
       -m  print machine type (c64pal, c64ntsc, c128pal, c128ntsc)
       -p  print processor type (6510, with SCPU: s6510, with REU: 6510+r)
       -a  print all (shortcut for -srvmp)

    uptime
      print the time the system is up (time since last reboot)

    uudecode
      decode file (stdin) that was coded with uuencode

    uuencode [-m] rmt_name
      encode file (stdin) and write to stdout, when decoding a file
      named rmt_name is created

    wc [file]
      count lines, words, chars on stdin or file and report to stdout


Modules
-------

  API: "SER" Version 1  (ctrl, getc, putc)
    sswiftlink - swiftlink device driver
    sfifo64    - driver for 16550 UART based rs232-cards)
    srs232std  - driver for standard userport RS232 interface *not complete*

  API: "SER" Version 2 (ctrl)
    fifo64    - driver for 16550 UART based rs232-cards)
    rs232std  - driver for standard userport RS232 interface
    swiftlink - swiftlink device driver should also support Turbo232

  API: "PKG" Version 1 (putpacket, getpacket)
    slip - SLIP packet encapsulation over serial lines
    ppp  - PPP protocol and packet encapsulation over serial lines
    loop - loop back packet driver

  API: "IP4" Version 1 (connect, listen, accept, sockinfo)
    tcpip - TCP/IP packet wise communication

  API: "RTC" Version 1 (time_read,time_write, date_read, date_write, raw_write)
    ciartc   - emulate real time clock using timer alarm of CIA1
    dcf77    - read German time signal from user port (radio)
    ide64rtc - RTC on IDE64 interface card
    smwrtc   - for the Smart Watch (Dallas DS1216 B series)


Module-Dependencies
-------------------

  sfifo64      (SERv1)  getty
  srs232std   -------> 
  sswiftlink            microterm

                      |
                      | 232echo
                      | 232term
                      |
              (SERv2) |        (PKG)   |         (IP4)    telnet
  swiftlink  -------> | slip  -------> | tcpip  ------->  ftp
  rs232std            | ppp            |                  connd 
                                       |
  loop  -----------------------------> |
                                       |

Setup of TCP/IP subsystem
-------------------------

  in case of SLIP

  l sh
  # swiftlink
  # slip 9600 &           (or an other supported baud rate)
  # tcpip 192.168.0.64 &  (replace with the IP address you use)

  or in case of PPP

  l sh
  # swiftlink
  # ppp 9600 &            (you may also apply username and password here)
  # tcpip &               (the IP address will be autodetected)

  if you don't have a swiftlink or compatible cardridge, you may also
  use rs232std - the driver for the standard userport interface
  (up to 2400baud)


Micro Terminal
--------------

  Some of the basic VT102/ANSI escape codes are implemented (enough for 
  running IRC remotely)

    Example (i assume you have a linux-box next to your C64):

    - build a nullmodem connection between the second serial port of your
      Linux-PC and the Swiftlink-Cardridge that is pugged into the C64.
      (and configured to NMI and $de00)

    - load and start linux and LNG (microterm)
        l sswiftlink
        l microterm

        or

        l swiftlink / rs232std
        l 232term

    - log into linux as root and type:
        /sbin/setserial /dev/cua1 spd_normal
        /sbin/agetty -h /dev/cua1 9600 vt102

    - you should get a login message on the C64 screen.
      log into your linux box and type
        stty cols 40
        stty rows 25
        irc

      HAVE FUN !


SLIP based connection
---------------------

First get the above (micro terminal) running, than read on.

On Linux-side (just an example):
  Add the line "192.168.0.64 c64" to the file /etc/hosts
  slattach -v -s BAUDRATE -p slip /dev/ttyS1 &
  ifconfig sl0 up mtu 984 192.168.0.1
  route add -host 192.168.0.64 sl0

  implies: C64 has IP 192.168.0.64 Linux-Bos has IP 192.168.0.1
           Nullmodem connection at serial port No.2 of the Linux-Box 

On LUnix-site:
  swiftlink  (or rs232std)
  slip BAUDRATE &
  tcpip 192.168.0.64 &

Now try "ping c64" on your Linux-Box (you might want to make a dump of all
IP-Packets flowing between Linux and LUnix: "tcpdump -i sl0")

Run "connd 200 sh" on the LUnix side, than log into LUnix from the Linux-Box
with "telnet c64 200"

Get redir from http://users.qual.net/~sammy/hacks to let people from the
internet log into your C64 trough the Linux-Box (Linux-Box acting as a kind
of firewall).


PPP based connection
--------------------

Same as SLIP with some small differences. PPP isn't just a way to 
encapsulate IP packets, it also includes a couple of protocols to
negotiate link capabilities and IP configuration. The current PPP
implementation is a baseline solution, there are still many things to
improve. 

sample setup to connect with a linux machine...

on linux side:
  pppd /dev/ttyS1 BAUDRATE 192.168.0.1:192.168.0.64 passive noauth

  You might also need to add the "local" option to pppd, if your nullmodem
  cable doesn't connect the CD, DTR and DTS lines.
 
on LUnix side:
  swiftlink / rs232std
  ppp BAUDRATE &
  tcpip &

The PPP implementation on LUnix side will retrieve the IP settings from
the remote machine and will send a faked IP packet to the TCP/IP stack
to make him learn his IP-address automatically.

Limitations:
 There currently is no way to terminate the PPP connection under LUnix.
 This means you have to restart LUnix each time you want to do a new
 ppp-connection.


Known Bugs
----------

  Some!
  Plase let me know, if you find a way to crash the system
  (report any other bug too)

  other bugs:
   - both ppp and slip work very unreliable at baud rates higher than
     19200 (at least at 1MHz - i prefer to run it at 9600 baud)


Additional documentation
------------------------

apps/README   - more information about writing and compiling apps - for luna
		and ca65 (.o65 file format)

kernel/README - detailed description of system variables and some other
                more general things

kernel/atari/README      - Status of the Atari port
devel_utils/atari/README - Atari tools readme file

There are several other READMEs in the kernel directory.

        
Where to get it
---------------

  You can get all stuff mentioned above from my WWW site at:

   http://www.heilbronn.netsurf.de/~dallmann/lunix/lng.html

  Starting with version 0.17 LUnix is hosted on sourceforge
  (www.sourceforge.net). You can download daily snapshots or
  directly access the source tree through CVS.
   

Conclusion
----------
 
  Take a look into the sources, make your modifications, find bugs, have ideas
  and (most important) SEND REPORTS !  :-)
  
  Besides don't forget: HAVE FUN !!
     
...
  Daniel  (eMail: [email protected])