elks-enhanced - XT-Emporium

File editor

State of the port

The most changes are made
  - in the OS/loader (setup.S)
  - the interrupt interface.
  
The OS/loader get rid of most configuration tests. The tests doesn�t performs
if the result is known. For example the strings for all 8086 processor 
models waste a lot of ROM space.

In contrast to the disk version of ELKS the segments have to initialise 
in an other way. In the disk version the kernel image (CODE+DATA) is
copied to RAM. The CODE segment is in RAM space (directly below the
DATA/BSS/STACK segment). In ROM version its nonsense to copy the CODE
from ROM (also in address space of the CPU) in RAM. Therefore the CODE 
segment stay in ROM while DATA (initialised part of data segment) is
copied form ROM into RAM.

A big problem are some CS variables (variables placed in the code segment).
In software this was a simple way to find this values when the segment 
registers (ES, DS, SS) for example after an interrupt are undefined. I�ve
placed this variables in a new absolute segment.


Present result:
---------------

The start-up and the self initialising of the kernels runs. The init task is
called. At boot time of /bin/init the system crashed. Because my debugger 
have some problems with the multitasking, I can't find the motive. At time
I work on a hardware extension for my ROM debugger.


10/1999
Christian Mardm�ller (christian.mardmoeller@quante.de / chm@kdt.de)

--------------------------------------------------------------------------------


Status der Portierung ELKS im ROM
----------------------------------

Die meisten �nderungen beziehen sich bisher auf:
  - den OS/loader (setup.S)
  - das Interruptinterface.
  
Im Ersteren habe ich eine Reihe von Konfigurationstest so auskommentiert,
da� das Ergebnis (falls bekannt) direkt angegeben werden kann. Gerade das
Vorhalten der vielen Prozessorvarianten als ASCII-Zeichenkette verschwendet
relativ viel Speicherplatz im ROM. 

Abweichend zur Diskettenversion m�ssen die Segmente anders initialisiert 
werden. In der Diskettenversion wird das kernel image im Block (CODE+DATA)
in den Speicher geladen. Auch der Code befindet sich somit im RAM (und 
zwar direkt unter dem DATA/BSS/STACK Segment. In der ROM Version w�re es 
Verschwendung, noch eine Kopie, des sich bereits im Adre�bereich des 
Prozessors befindlichen Codes, im RAM anzufertigen. Daher bleibt CODE im 
ROM, w�hrend DATA (initialisierter Teil des Datensegmentes) aus dem ROM 
ins RAM kopiert wird.

Ein gro�es Problem stellten einige CS-Variablen (Variablen im Codesegment)
dar. Programmtechnisch ist dieses eine einfache Art Werte in einem Interrupt
wieder zu finden (DS, SS , ES k�nnen undefiniert sein). Ich habe f�r diese
Variablen ein neues, absolut plaziertes Segment aufgemacht.


bisheriges Ergebnis:

Der startup und die Initialisierung des kernels l�uft durch. Der inittask wird
gestartet. Beim laden von /bin/init kommt es dann jedoch zu H�ngern. Da mein
derzeitiger Debugger noch nicht ganz Multitasking ist, konnte ich den genauen
Grund noch nicht aufsp�ren. Zur Zeit arbeite ich an der entsprechenden 
Hardwareerweiterung meines ROM-Debuggers.

Die gemachten �nderungen *scheinen* auf die Diskettenversion keinen negativen
Einflu� zu haben.

10/1999
Christian Mardm�ller (christian.mardmoeller@quante.de / chm@kdt.de)

-----------------------
Commit message
This repository is read-only for this account.
Repository snapshot

Current branch
master
Visibility
public
Your access
Read
Remote
Configured
File activity

View file history