COMAL-80 - "Super Chip" Package - eigene Implementierung

Sehr gut,

genau das dachte ich mir auch schon mal.

Deswegen auch gleich mal eine passende Einleitung von meiner Seite.

Wie ihr alle wisst, gibt es wohl das Superchip EPROM, denoch ist es fuer un sim Moment nicht verfuegbar.

Aus diesem Grund hatten wir uns ja entschlossen die Kommandos so weit es geht selber zu programmieren, bzw. vorhandene Programmteile aus anderen Quellen zu uebernehmen, und damit unser eigenes Super-Chip-II EPROM zu gestalten.

Diddl hat ja schon wirklich viel dazu beigetrage, um es zu verwirklichen.

Mit seinem unermuedlichem Einsatz haben wir fast das komplette Math-Packet nachbilden koennen, und auch andere Pakete wachsen stetig weiter unter seiner Obhut.

Danke dafuer.

In der Zwischenzeit war ich aber auch nicht untaetig, und habe einiges programmiert, bzw. Source-Codes aus vorhandenen Modulen, und Paketen erstellt.

Folgende Pakete habe ich aufbereitet:

. Deutsch

. C128

. Matrix

. Quickload

. Keyboard

. System2

. Cmon

Cmon ist eine an COMAL angepasste Smon-Plus-Version.

Und zum Math-Paket habe ich noch HYPOTENUSE und auch DISTANCE mit beigesteuert.

Die Pakete Deutsch, Keyboard, Systam2 und Cmon habe ich mal auf ein d64-Image gepackt.

Hier eine kleine Uebersicht:

• deutsch:
  Das Paket linken, und mit ‘use deutsch’ starten.
  Dann stehen wie auch schon im Hagensoft-Modul, die deutschen Fehlermeldungen zur Verfuegung.
• keyboard:
  Das Paket linken, und mit ‘use keyboard’ starten.
  Befehle dazu:
  • repeatkeys(a)
    schaltet die Tastenwiederholfunktion ein, bzw. aus
  • clearkeys
    loescht den Tastaturpuffer
  • fillkeys(a$)
    fuellt den Tastaturpuffer mit dem angegebenen String
    Es sind bis zu 10 Zeichen moeglich
  • enable’keyboard
    setzt die Anzahl der moeglichen einzugebenden Zeiche auf 10, somit sind Tastatureingaben wieder moeglich.
  • disable’keyboard
    setzt die Anzahl der moeglichen einzugebenden Zeichen auf 0, somit sind keine Tastatureingaben mehr moeglich.
    Im Direkmodus wird diese Funktion nicht unterstuetzt.
  • lock’lowercase
    schaltet auf Kleinschreibung um.
  • lock’upercase
    schaltet auf Grosschreibung um.
  • shift
    mit PRINT shift kann man feststellen, ob die Shifttaste gedrueckt ist.
    Damit kann man z.B in einem Programm mit ‘WHILE NOT shift DO’ auf das druecken der Shift-Taste warten.
  • version’keyboard$
    mit Print version’keyboard$ wird die Version des Pakets angezeigt.
• system2:
  Das Paket linken, und mit ‘use system2’ starten.
  Befehle dazu:

  
  

  • current'page
    Mit ‘PRINT current’page’ wird die aktuelle PAGE angezeigt.
    PAGE ist hierbei der momentan von COMAL aktivierte Bereich im EPROM.
  • Host
    Mir ‘PRINT host’ wird entweder “c64”, oder “C128” angezeigt, je nachdem auf welchem Commodre Rechner COMAL gerade laeuft.
    Das kann z.B. dazu genutzt warden, um festzustellen, ob der VDC-Ram zur Verfuegung steht.
  • Hidescreen
    Die Eingabe von ‘hidescreen’ schaltet den Bildschirm aus
  • showscreen
    Die Eingabe von showscreen’ schaltet den Bildschirm an
• cmon
  Das Paket linken, und mit ‘use monitor’ starten.
  Danach kann man den Cmon mit ‘cmon’ aufrufen.
  Im cmon stehen fast alle Befehle, welche auch im SMON in der PLUS-Version verfuegbar sind zur Verfuegung.

In der finale Version von Super-Chip-II werden alle Pakete integriert sein.

Zusaetzlich zu den schon in der Excel-Tabelle angegebenen Paketen, werden noch die folgenden Pakete enthalten sein:

. Matrix

. Quickload (statt RABBIT, das ist der jetzige Status, kann sich eventuell noch aendern.)

. Cmon

Es gibt zudem noch andere Pakete, welche ich mir noch nicht richtig angeschaut habe. Eventuell ist da noch was interresantes dabei.

Soweit erst mal der Status von meiner Seite.

wie schon so oft, mfG aus dem fernen China

Claus

Ich denke mal, es wird nicht noetig sein, CMON in einen anderen Block zu verschieben.

Wahrscheinlich ist es auch nicht moeglich, da COMAL diesen Bereich, so wie es im Moment aussieht, nicht verwalten kann.

Stattdessen habe ich CMON etwas geaendert.

CMON liegt jetzt im RAM-Bereich ab $7000.

Beim starten wird zuerst die COMAL-eigene Zeropage gesichert, der IRQ-Vector wird auf den 'normalen' Wet gesetzt. ($EA31), und die Speicherstelle $01 wird mit $37 beschrieben.

Dadurch ist es moeglich, durch Beschreiben der Speicherstelle $DE00 mit den Weren $x0 - $x5, die verschiedenen COMAL-PAGES einzuschalten und zu betrachten, usw.

Beim Beenden von CMON ueber 'X" werden die Zeropage, und der zuvor geanderte IRQ-Vector wieder auf die COMAL-eigenen Werte zurueckgesetzt.

Zum Speichern der Zeropage, und des Vectors wird der Speicherbereich von $C000 - $c125 benutzt.

Fuer diesen Bereich gilt waehrend CMON aktiv ist: anschauen erlaubt, anfassen verboten.

Anbei das Image mit der angepassten CMON-Version.

COMALpackages.d64

MfG

Claus

Zitat von Diddl

Die Frage ist halt, was genau speichert man denn in die Datei?

Also meiner bescheidenen Meinung nach will niemand jemals ROM speichern, es sollte immer das RAM sein. Wie sinnvoll das ist bei den von Comal benutzten Bereichen mag dahingestellt sein, aber der Kunde ist König, daher würde ich das nicht einschränken.

Zitat von Diddl

Nun ja, wenn jemand ein COMAL Modul findet bei sich zu Hause.

Und dieses Modul hat eine unbekannte Erweiterung.

Er mag aber nicht das Modul öffnen oder er hat kein EPROM Lesegerät ...

Dann wäre es gut wenn man das COMAL ROM einfach speichern kann.

Das ist dann aber eigentlich kein Comal-Usecase, sondern eher ein allgemeiner Reverse-Engineering Usecase, oder? Wer weiß, vielleicht hat das geheimnisvolle Comal-Modul dann ja einen ganz anders implementierten BSAVE-Befehl ?

Zitat von Diddl

Aber was ist, wenn COMAL bereits Daten abgelegt hat in diesem RAM Bereich?

Ich muss gestehen, das habe ich mir noch nicht angesehen.

Edit:

So ich habe kurz mal getestet.

Wenn der Speicher schon von einem anderen Paket belegt ist, meldet COMAL 'memory area is protected'

Variablen werden beim 'linken' eines Pakets zurueckgestzt., da ist sowieso kein entkommen, und COMAL psst das Speicherende, und auch die Zeiger entsprechend an.

Stehen andere Daten dort, welche nicht direkt von COMAL verwaltet werden, also falls jemand dort Daten ablegt, dann sind die natuerlich nicht geschuetzt.

Wenn CMON ueber den LINK-Befehl geladen wird, kuemmert sich ja COMAL selbst darum, oder meinst du einen Bereich fuer CMON resevieren, wenn CMON im EPROM integriert ist?

Ich verstehe es jetzt im Moment so,

du moechtest fuer den CMON, welcher sich im EPROM befindet, extra Speicher resevieren. Richtig?

Falls ja, fuer was genau soltte dieser Speicher dann genutzt werden?

Nun noch zum Aufbau der Module,

Ein Modul kann auf SIGNALE (EVENTS) reagieren.

Ein Paket kann beim Start eine Initialisierungsroutine aufrufen, bevor das Paket selber aktiviert wird.

Mit dem SIGNAL koennen somit bestimmte Programme ausgefuehrt werden.

Z.B. der Speicher welcher von CMON reseviert wurde koennte wieder freigegeben werden.

Das kann aber CMON auch selbst, wenn man ihn mit 'x' verlaesst. Und das waere meiner Meinung nach besser.

Interessanter ist aber wahrscheinlich die INIT-Routine vom Paket,

damit koennte man, wenn man weiss wie, Speicher fuer CMON resevieren, bevor CMON startet.

Aber dazu nuss ich sehen, ob ich in Erfahrung bringen kann, wie das funktioniert.

Ich hatte mir ja schon die Variablenverwaltung angeschaut, und auch einiges in Erfahrung bringen koennen.

Pakete, und FNC/PRC werden, soweit ich das sehe, nach dem selben System verwaltet.

Die relevanten Pointer in der Zeropage sind dabei:

$16 Programspeicher start

$18 Variablenzeiger start

$1a Stapelzeiger start

$1c Speicherende

$2d Stapelzeiger ende

Wenn man sich den Speicherbereich aus $18/$19, welcher zu Beginn auf $0804 zeigt, anschaut, kann man dort die Variablen, und auch die Pakete und Funktionen finden.

Der Aufbau ist dabei folgender:

!by Laenge

!by Typ

!word address

!pet "name"

Die Laenge ist die Anzahl Bytes vom Anfang inkl. die Laengenangabe, bis zum Ende des Eintrags

Typen kenne ich bisher folgende:

$10 REAL

$11 INT

$12 STR

$14 PROC (welches aufgerufen wurde)

$18 PKG (Paket welches mit USE eingebunden wurde)

Die Adresse zeigt auf den Variableninhalt, bzw. auf den verwendeten Paketspeicher.

Name ist der Name der Variablen, oder des Pakets, oder Funktion.

Das kann man sich mit dem CMON ja anschauen, und selber mal Variablen anlegen, und schauen wie diese dann im Speicher liegen.

Vielleicht kannst du ja was mit anfangen, ich werde parallel dazu auch noch mal schauen, ob ich selber da weiter komme.

LG

Claus

Ich habe dem Paket FILES neue Funktionen hinzugefuegt

BLOAD(name$,adr)

laedt den Inhalt einer Datei in den Speicher ab der angegebenen Adresse. (der Speicher wird ohne Nachfrage ueberschrieben)

BSAVE(name$,adr1,adr2)

speichert den Bereich von adr1 bis adr2 in die angegebene Datei

TYPE(name$)

liesst den Inhalt einer Datei byte fuer byte auf den Bildschirm. (Steuerzeichen werden nicht auf dem Bildschirm angezeigt.)

COLLECT

validiert die Disk im aktuellen Laufwerk.

Eine Package-Datei habe ich nicht erstellt, diese wird spaeter veroeffentlicht.

Anbei mal eine neue Uebersicht, inklusive des von Diddl neu angelegtem Memory-Pakets.

Zur Erlaeuterung:

Gruen waren, bzw. sind vorhandene Funktionen

Orange wurde von Diddl eingearbeitet.

blau ist von mir erarbeitet worden.

Was jetzt noch fehlt:

Ich finde, das Super-Chip-II Modul schon recht weit vorangeschritten.

Wir bleiben auf jedenFall dran.

MfG

Claus