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//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 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 /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: Dallmann@heilbronn.netsurf.de)