Eine wirklich traurige Nachricht... Ruhe in Frieden irgendwo da oben in der 8-bit Welt.
...
Posts by FloatingRiver
-
-
Verbraten habe ich Stunden und Stunden mit dem LOADSP und Co., aber COMAL-128 will einfach nicht kooperieren und alles verweigert jegliche Zusammenarbeit auf allen ebenen, also aus C128 und BLOAD wird wohl nix. Alle alten Zeitungen, Comal Today Vorschläge {Z. Bsp. COMAL-TODAY ISSUE 15, PAGES 12/13, DISK to SCREEN}... Macht alles nur 'kosmisches' Zeug... Es hat mich aber auf die Idee gebracht: {Screen2Memory
}CommodoreWelt_89_01_SH_Commodore-C128-Special hat auch interessantes Zeug drin, aber in Verbindung mit COMAL-128, keine Chance was zu verwenden!
{Eine ordentliche COMAL-C128 Anleitung wo alles drin abgehackt wird, fehlt einfach}
Also da ich auf endlose DATA Linien verzichten will um meine Assemblerroutinen ins Programm einzubinden, kam ich auf die Idee, wie erwähnt: Screen2Memory {nur weil es cool aussieht und vor allem weil es funktioniert}.
Natürlich, eine 'direct' Disk2Memory Idee ist hier auch nicht weit weg wenn man es schlicht halten will!
Auf jeden Fall, die Assemblerzeilen lassen sich schön abspeichern, wieder laden und katapultieren dort wo sie hingehören.
BSAVE & BLOAD, aber anders! Und es ist eigentlich keine Hexerei, Null kompliziert!
{Müsste allerdings ziemlich schwitzen bis ich auf die Idee gekommen bin!}
Assemblerzeilen zuerst eingeben {mit dem C128 ML-Monitor}
. 00b00 a2 00 ldx #$00
. 00b02 8a txa
. 00b03 9d 00 04 sta $0400,x
. 00b06 e8 inx
. 00b07 e0 ff cpx #$ff
. 00b09 d0 f7 bne $0b02
. 00b0b 60 rts
COMAL-128 Zeilen
0010 DIM mlc(12)
0020 USE system
0030 cpuspeed(1)
0040 FOR a:=1 TO 12 DO mlc(a):=PEEK(2815+a)
0050 OPEN FILE 1,"@testml",WRITE
0060 FOR bin:=1 TO 12 DO WRITE FILE 1: mlc(bin)
0070 CLOSE FILE 1
0075 FOR delbin:=0 TO 12 DO POKE 2816+delbin,255 // fill with ff
0080 OPEN FILE 2,"testml",READ
0090 FOR bin:=1 TO 12 DO READ FILE 2: mlc(bin)
0100 CLOSE FILE 2
0110 PAGE
0120 FOR bin:=1 TO 12 DO POKE 1023+bin,mlc(bin)
0130 FOR bin:=1 TO 12 DO POKE 2815+bin,PEEK(1023+bin)
0135 PRINT AT 5,1: "binary code transferred"
Das ist die erste Ausgabe... Teile es hier schnell mit, an alle interessierten Kameraden.
Nächste Aufgabe ist das hier in sinnvolle Prozeduren zu verpacken {SPEICHERN und LADEN trennen etc.}
Assemblerteil lässt sich natürlich mit SYS 2816 vom COMAL aus abrufen.
Bitte beachten, wenn kein Assemblercode vorhanden ist, dann wird einfach das abgespeichert was dort war!
{was auf Diskette ist, wird überschrieben!} Natürlich ist es dann nicht Sinnvoll SYS 2816 anzuwenden wenn kein Assemblercode vorhanden war!}
-
Display MoreIch habe nun schon einiges probiert, aber halt noch kein wirkliches Ergebnis bekommen.
Entweder es kommt sofort ein "device not present' , oder nach dem ersten Laden.Ich bleibe dran.
LG
Claus
Wohl sehr wahr! COMAL-128 fordert einen bis zum schwitzen...
Weiß gar nicht mehr was ich nicht alles ausprobiert habe damit es klappt.
Zum Glück ist das mit den Emulatoren nicht so ein großes Problem wenn was einfriert und nicht mehr geht.
Demo-Floppy für C128 deckt nicht alle Änderungen und Anpassungen ab die bei dem COMAL-128 gemacht worden sind, schätze ich mal vorsichtig ab. Die COMOL-128 Dokumentation als Addendum zu COMAL-80 C64 Buch ist wahrscheinlich nur 20% von dem was COMAL-128 gebraucht hätte an Informationen damit man dem COMAL-128 alles abverlangt.
Es hat mich schon erstaunt, dass BLOAD, BSAVE im COMAL-128 selbst fehlen, aber unter MONITOR funktionieren die einwandfrei. Eventuell lassen sich diese Routinen dort verwenden bzw. im COMAL BLOAD implementieren oder sogar direkt ansprechen?!
Irgendwo habe ich vor Jahren gelesen, wie man vom BASIC 7.0 heraus auf ML-Monitor zugreifen, dann Monitor-Befehle ausführen und anschließend den ML-Monitor verlassen und zum BASIC 7.0 zurück kehren kann {praktisch eine Reise ins ML-Monitor-Land mit RTS-Karte} um nächsten BASIC Befehle auszuführen.
ML-Monitor hat so viele sinn- und nutzvolle Funktionen, dass ein Zugriff darauf vom COMAL aus, ein Segen wäre!
Muss schauen ob sich das noch finden lässt {wer dachte damals es könnte eines Tages nützlich werden in Verbindung mit COMAL wenn man COMAL gar nicht kannte}
-
Display More
Auch nach dieser Mission, bin ich kein Byte schlauer geworden! 5000 Zeichen Beispiel...
Warum sind GURU's unfähig ein Beispiel zu stricken, das auch 08/15 Benutzer verstehen können, wird wohl für immer und ewig ein Geheimnis bleiben!
Bei den Packages ist es für mich auch nicht einfach das zu begreifen.
Wo genau hakt es denn bei den Beispielen?
Vielleicht kann ich ja helfen.
Generell sollte natürlich das Verständnis für Maschinensprache vorhanden sein.Ich habe mittlerweile ein paar Packages vom C64 auf den C128 portiert, und auf meiner GitHub-Seite veröffentlicht.
Es sind zwar bisher nur 2, aber es werden hoffentlich mehr werden.
LG aus dem fernen China
ClausAlso, als Erstes, danke für die Packages!
Hab' die jetzt {gestern angefangen}, angeschaut.
Alles herunter geladen, aber ich kann das drehen und wenden wie ich will, ich begreife es einfach nicht!
Also, den oberen Bereich verstehe ich noch, aber alles weitere, nur Bahnhof!
{in Assembler {EDASS 128} habe ich schon einen {funktionierenden} Level-Editor geschrieben mit Speicherfunktion, aber COMAL-Package überfordert mich
}Mein Geist weigert sich das zu verstehen {bin zu alt mittlerweile, hehe}!
Denke, von meiner Seite aus werden keine C-128 Packages so schnell kommen
...
Darum suche ich jetzt nach Umwegen um doch noch ans Ziel zu kommen.
Und natürlich 100% COMAL-Kompatibel zu bleiben damit es überall funktioniert!
Mit "überall" meine ich selbstverständlich nur den C64 und C128. Ich muss lediglich Binäre Dateien von der Floppy laden können {C128}
Das hier* {COMAL-TODAY-6-Last-Page} funktioniert wunderbar auf der C64er Seite, aber auf der C128er Seite ist das Gegenteil der Fall!
Da geht gar nichts auch wenn LOADSP Call normalerweise auch bei dem C128 genau so und auf der gleichen Adresse vorhanden ist.
Einfach gesagt, COMAL-128 macht da einiges anders!
Gelesen habe ich, dass COMAL KERNAL abgestellt hat, aber dafür Ersatz zur Verfügung stellt in anderen Bereichen.
Nur finde ich nix brauchbares, sprich, all das hier** geht nicht als Ersatz für LOADSP auf der C128 Seite. {Lustigerweise steht SETNAM bereit}
Habe noch viel mehr ausprobiert...
Brachte das Laufwerk x-mal zum Absturz {der Zugriff funktioniert unter MONITOR, aber COMAL wollte nix mehr mit dem Laufwerk zu tun haben!}
**=
1. LOAD= $17B0 { not working }
2. LOADIN= $1742 { not working }
3. LOADMD= $1736 { not working }
4. JLOAD= $1969 { not working }
*=
COMAL-80 / Commodore C64
{this is working fine to load a binary file from disk into a location where it was previously saved!}
0010 USE system
0011 DIM binfile$ OF 10
0012 binfile$:="c64mlcode"
0013 load'obj(binfile$)
0014 PAGE
0015 PROC load'obj(binfile$) CLOSED
0016 RESTORE mlpart
0017 FOR a:=0 TO 4 DO
0018 READ mlcode
0019 POKE 2024+a,mlcode
0020 ENDFOR a
0021 OPEN FILE 78,binfile$+",p",READ
0022 SYS 2024
0023 CLOSE FILE 78
0024 mlpart:
0025 DATA 169,0,76,213,255
0026 ENDPROC load'obj
DATA 169,0,76,213,255 = lda #$00, jmp $ffd5
BOTTOM LINE : Was muss in die Linie 25 eingetragen werden, damit das auch mit dem C128 funktioniert?
-
Display More
Welches von den Büchern für Comal80 ist das bitte unten ?
Kannst du mal die PDF dafür bitte angeben?
-----------------------------------------------------
Lese gerade COMAL-80 Buch {gescannt} und auf der Seite 271 fand ich C64 Beispiel von TEST {COMAL Paket Erstellung}
-----------------------------------------------------
Danke.
Dieses hier: https://archive.org/details/comal-80-for-the-commodore-64
Und ansonsten, dort das COMAL Wort als Suchbegriff eingeben bringt einiges bezüglich COMAL ans Tageslicht.
-
Lese gerade COMAL-80 Buch {gescannt} und auf der Seite 271 fand ich C64 Beispiel von TEST {COMAL Paket Erstellung}...
Wer also mit dem was ich gemacht bzw. übersetzt habe #52, nicht klar kommt, kann sich im COMAL-80 Buch auch alles anschauen.
-
Hier ist auch noch dieses Beispiel von der Diskette {Comal-128-Demo}
Eventuell habe ich es korrekt ins Englische übersetzt. Ist alles einzeln kontrolliert worden, aber trotzdem kann immer wieder was
entgehen.
Auch nach dieser Mission, bin ich kein Byte schlauer geworden! 5000 Zeichen Beispiel...
Warum sind GURU's unfähig ein Beispiel zu stricken, das auch 08/15 Benutzer verstehen können, wird wohl für immer und ewig ein Geheimnis bleiben!
-
Display More
Die "C128 COMAL 2.02 Demo-Disk", mit der "c128symb.asm" steht ja Dank Snoopy zur Verfügung.
Ich habe die Disk bisher aber nur recht oberflächlich angeschaut.
Diese Woche habe ich mir diese Disk nun etwas näher angeschaut.
Leider gibt es bisher ausser der Demo-Datei auf der Disk, keine weiteren Packages dafür.
Das bedeutet, es muss erst noch erkundet werden, wie der Speicher von Comal 2.02 im C128 verwaltet wird, usw.
Ich habe mich in der Vergangenheit nicht wirklich mit dem C128 im Allgemeinen beschäftigt, so dass es auch für mich "Neuland" ist.
Ich könnte wahrscheinlich auch Packages dafür schreiben, aber da fehlt noch Hintergrundwissen, wo genau Files hingeladen werden können, und auch wie man die Bänke in COMAL 2.02 verwaltet.
Ich bleibe aber dran am COMAL 2.02 für den C128, schon aus reiner Neugier.
Allerdings ohne Terminvorgabe.
Sobald ich weiteres habe, werde ich hier berichten.
LG
Claus
Vor langer, langer Zeit, als ich noch ganz schön und praktisch ein Jungbrunnen war {November 2024!}, voller Tatendrang stürzte ich mich an die Arbeit und übersetzte das Dänische COMAL 2.02 Buch {Ergänzung zu COMAL-80 Buch, C64} ins "English", also nur für mich damit Copyright keine Probleme macht.
Info: Wie ich bereits erwähnte, das "excellent book" COMAL 2.0 Packages hat bei mir nix gebracht
Im Ergänzungsbuch steht:
STRUCTURE OF MODULES:
The modules are structured in exactly the same way as in the C-64 cartridge, however, .lib c64symb is changed to .lib C128symb (.lib C128symb corresponds to .lib C128symbl + .lib C128symb2 without comments, etc.).
Also, <start address> will typically be $C000 instead of $8009.
Now .byte <map> indicates memory areas, and the meaning of different map values are shown in the following table.
(The same memory areas also apply to SETPAGE in the system package!)
Map Value Storage Area (memory map)
01 RAM 0
02 RAM 0 + I/O
03 RAM 1
04 RAM 1 + I/O
05 COMAL cartridge + RAM 0
06 COMAL cartridge + RAM 0 + I/O
07 COMAL cartridge + RAM 1
08 COMAL cartridge + RAM 1 + I/O
09 COMAL cartridge + RAM 2
10 COMAL cartridge + RAM 2 + I/O
11 COMAL cartridge + RAM 3
12 COMAL cartridge + RAM 3 + I/O
13 KERNEL + RAM O + I/O
14 KERNEL + RAM O + CHARROM
15 KERNEL + RAM O + I/O + BASIC + MONITOR
Weiterhin:
WHERE MODULES CAN BE PLACED:
Modules can be placed in RAM 0 from $2100-$FEFF. However, if the start address is less than $C000, the user storage area is limited. Note: the range $AC00-$BFFF must not be used if the FONT package is used for the 40-character screen.
WHERE THE MODULE'S VARIABLES CAN BE PLACED:
Variables that must survive from call to call can be placed in the module itself or in the $1200 to $12FF range. In addition, tape and RS-232 buffers can be used, provided they are not already used.
Ausserdem:
PACKAGE EXAMPLE:
The package example on the C-128 Demo disk has been changed as described, which means:
.lib C64symb
. opt list ;list this module
*=$8009 ;start address
has changed to:
.lib C128symb
.opt list ;list this module
*=$c000 ;start address
As can be seen from the above, in most cases it will be easy to adapt a C-64 package so that it can also run on a C-128.
LITERATURE:
{For more information on COMAL packages, see the excellent book:}
Jesse Knight, COMAL 2.0 Packages, published by COMAL Users Group, 5501 Groveland Terrade, Madison, W1 53716-3251 USA.
-
Display More
...Werde wieder einsteigen und hoffentlich hilft ClausS etwas ...
Ich brauche das nur für ein paar Assemblerroutinen. Dann kann ich auf DATA verzichten und Platz sparen.
Habe schon dem ClausS erwähnt, dass bereits BLOAD für Comal-128 eine Weltveränderung wäre!
Die "C128 COMAL 2.02 Demo-Disk", mit der "c128symb.asm" steht ja Dank Snoopy zur Verfügung, siehe auch hier.
Ich habe die Disk bisher aber nur recht oberflächlich angeschaut.
Diese Woche habe ich mir diese Disk nun etwas näher angeschaut.
Leider gibt es bisher ausser der Demo-Datei auf der Disk, keine weiteren Packages dafür.Das bedeutet, es muss erst noch erkundet werden, wie der Speicher von Comal 2.02 im C128 verwaltet wird, usw.
Ich habe mich in der Vergangenheit nicht wirklich mit dem C128 im Allgemeinen beschäftigt, so dass es auch für mich "Neuland" ist.
Ich könnte wahrscheinlich das Package mit dem Befehl BLOAD dafür schreiben, aber da fehlt noch Hintergrundwissen, wo genau Files hingeladen werden können, und auch wie man die Bänke in COMAL 2.02 verwaltet.Ich bleibe aber dran am COMAL 2.02 für den C128, schon aus reiner Neugier.
Allerdings ohne Terminvorgabe.Sobald ich weiteres habe, werde ich dort: COMAL-80 für den c128 berichten, da es hier im Thread ja eigentlich um COMAL2.01 geht.
LG
Claus
THANK YOU VERY MUCH!
Ich schreibe dann die Antwort dort...
-
Was mich erstaunt hat, ist die Dauer des Lesevorgang!
Ja, in der Tat. Das Schreiben und Lesen von Relativ-Dateien mit wahlfreiem Zugriff (RANDOM) dauert recht lange. Zumindest in diesem Fall, wenn die Datensatzlänge nur 4 Bytes ist (jede Note belegt 4 Bytes in der Datei). Dies ist mir auch aufgefallen.
Ich weiß nicht, ob das an COMAL oder an den C= Laufwerken im Allgemeinen liegt. Dies ist aber die einzige Möglichkeit, um direkt auf beliebige Datensätze einer Datei zuzugreifen.
Und überhaupt: Warum muss das so schnell gehen? Wo bleibt da der Genuss?
Der Fluch heißt: die Macht der Gewohnheit!
1571 ist schon ziemlich schnell {so 10x schneller als 1541 wenn ich mich recht erinnere}
Habe zwei davon, also echte Hardware
, nicht EmulationDenke bis jetzt bin ich von den Relativ-Dateien verschont geblieben und darum kann man davon ausgehen, dass ich 'ein wenig' verwöhnt gewesen bin die letzten 30, 40, 50... Jahre... Na gut, 50 jetzt auch wieder nicht ...
-
Display More
Hat sich erledigt , danke.
Ich meinte die :
c128symb.seq
Die befinden sich in deiner D64.
Hast du schon einmal Packages entworfen für Comal80 auf den C128?
Danke.
Noch nicht...
Habe es am Anfang angeschaut, aber Interesse verloren... Das war irgendwann November 2024
Habe auch das Comal Buch Packages angeschaut, war aber alles Bahnhof
Werde wieder einsteigen und hoffentlich hilft ClausS etwas ...
Ich brauche das nur für ein paar Assemblerroutinen. Dann kann ich auf DATA verzichten und Platz sparen.
Habe schon dem ClausS erwähnt, dass bereits BLOAD für Comal-128 eine Weltveränderung wäre!
-
FloatingRiver , hast du auch die Demo-C128 mit Packages für das C128-Comal80 ?
Wo hast du den System-Inhalt-c128 vom Comal80 her?
Ich meine nicht das Ergänzungs-Handbuch welches du hier reingestellst hast.
Danke.
Demo Floppy COMAL-C128 C128_Comal_2_02_Demo_Disk.d64
Wo hast du den System-Inhalt-c128 vom Comal80 her?
Was meinst du damit genau? Kann mich gar nicht erinnern, dass ich so was habe!
Wo habe ich das platziert?
Meine Gehirnzellen sind nicht mehr die frischesten und auch sind einige Bereiche bestimmt auf inaktiv geschaltet worden
-
Gleich so "schnell" wie beim C64 {allerdings mit .d71 Floppy / 1571 Laufwerk auf der C128 Seite}
Wahrscheinlich war das d64-image mit einer 1541 formatiert und nicht mit einer 1571.
Also d64-image mit 1571 formatieren bzw. erstellen und darauf das prg mit 1571 speichern..
Dann sollte von der "1571"-Diskette auch schneller gelesen werden können.
Zuerst habe ich das Programm mit Originaldiskette .d64 geladen, gestartet, wie oben beschrieben, wenig angepasst damit es mit es auf dem C128 funktioniert.
Dann das Programm auf .d71 gespeichert und mit DirMaster3.15 die restlichen 3 .rel Dateien kopiert.
Also eigentlich alles korrekt {.d71 Image hat 342KB}
Kann sein, dass COMAL die Dinger so einliest/bearbeitet, dass es halt lange dauert {da bringt es nichts schnell zu sein, wenn COMAL nicht nachkommt}
Das würde auch die gleiche "Geschwindigkeit" bei beiden System erklären. 2MHz haben auch nix gebracht!
-
Display More
Heute möchte ich euch einmal ganz praktisch zeigen, wie sich der Gültigkeitsbereich von Variablen in COMAL auswirkt - und wie man mit CLOSED-Prozeduren echten Speicher spart.
In der ersten Version meiner Tetris-Melodie hatte ich die Noten in Form riesiger DATA-Zeilen-Wüsten direkt ins Programm geschrieben. Das war weder elegant noch speichersparend - und die sechs dafür verwendeten Arrays haben während der gesamten Programmlaufzeit RAM belegt, selbst wenn sie nicht mehr gebraucht wurden.
Diesmal habe ich es besser gemacht: Die drei Stimmen der Melodie sind nun jeweils in einer Relativdatei auf Diskette gespeichert. Diese Dateien werden in einer CLOSED-Prozedur eingelesen und in sechs Arrays abgelegt. Der dafür benötigte Speicher liegt bei etwa 3,8 KB - aber nur während der Laufzeit der Prozedur.
Und das Ergebnis spricht für sich:
- Vor dem Abspielen der Musik stehen 28338 Bytes zur Verfügung.
- Während die Musik läuft, sind es 24458 Bytes.
- Und nach dem Abspielen hat man wieder die vollen 28338 Bytes frei - automatisch!
COMAL kümmert sich um die Speicherfreigabe ganz von selbst - wenn man die Prozeduren korrekt mit CLOSED definiert.
So kann man selbst auf dem C64 relativ aufwändige Musikstücke in Programme einbauen, ohne dass sie den gesamten RAM-Speicher blockieren.
Toll, oder?
Ich konnte nicht widerstehen und spielt die Tetris-Musik auch auf meinem C128 {emuliert}.
Und meine Befürchtungen haben sich total {nochmals} bestätigt... Ich lag tatsächlich 200% falsch mit den geschlossenen Prozeduren bzw. mit meiner Meinung, dass es eigentlich den Speicher verschwendet. Das Gegenteil ist der Fall, ganz klar!
C64 und C128 können nicht lügen!
Übrigens, wollte nicht auf Anhieb abspielen. Es brach immer ab bei der ersten Note!
Lag am KEY$ wie ich herausgefischt habe.
Meine Lösung: Ersetzen, nicht mit POKE, sondern mit PEEK
... or PEEK(212)<>88 und schon war alles okay.Was mich erstaunt hat, ist die Dauer des Lesevorgang!
Als hätte ich eine 200 BLOCK-Datei eingelesen, aber es waren nur 13 und es hat über 40 Sekunden gedauert!
Gleich so "schnell" wie beim C64 {allerdings mit .d71 Floppy / 1571 Laufwerk auf der C128 Seite}
C64
C128 -
Display More
...da fragt man sich schon wie wichtig eine geschlossene Prozedur eigentlich sein kann?
Hey FloatingRiver,
nachdem ich meinen Herzinfarkt überwunden und mich mit dem Defibrillator erfolgreich reanimiert habe, möchte ich dir gerne noch etwas zum Thema CLOSED mitgeben.
Wenn man COMAL so nutzt, wie es gedacht ist, sollten PROC und FUNC immer mit CLOSED geschrieben werden. Und zwar aus folgenden Gründen:
Lokale Variablen sind nur mit CLOSED möglich
Nur in CLOSED-Prozeduren bleiben Variablen innerhalb der Prozedur. Ohne CLOSED sind alle Variablen global. Das heißt: Prozeduren können sich gegenseitig beeinflussen, und der Überblick geht schnell verloren. Das macht Programme fehleranfälliger - und widerspricht dem Grundprinzip prozeduraler Programmierung: Klare, abgeschlossene Bausteine.
Speicher wird effizienter genutzt
In CLOSED-Prozeduren werden Variablen nur während der Ausführung im Speicher gehalten. Nach dem Ende der Prozedur wird der Speicher sofort freigegeben. Ohne CLOSED bleiben alle Variablen dauerhaft erhalten - selbst wenn sie gar nicht mehr gebraucht werden. Auf einem C64 mit begrenztem RAM kann das schnell zum Problem werden.
Der Code bleibt sauber und nachvollziehbar
Prozeduren sollten so geschrieben sein, dass sie für sich selbst funktionieren - ohne Abhängigkeiten von außen. Das erreicht man nur mit CLOSED. Der Code bleibt dadurch übersichtlich, leichter zu testen und vor allem: Sicher vor unerwarteten Seiteneffekten.
Fazit:
Wer COMAL sinnvoll und strukturiert einsetzen möchte, sollte PROC und FUNC grundsätzlich mit CLOSED schreiben. Alles andere führt zu genau den Problemen, die COMAL gegenüber BASIC eigentlich vermeiden wollte.
Ich sage das bewusst so klar, weil ich oft den Eindruck habe, dass COMAL zwar irgendwie verwendet wird, aber die Konzepte prozeduraler Programmierung nicht wirklich verstanden werden. Manche sehen die Stärken von COMAL in der LOGO-ähnlichen Turtle-Grafik oder in bestimmten Grafikbefehlen - aber das sind eigentlich nur nette Zugaben.
Die eigentliche Stärke von COMAL liegt in seiner sauberen, strukturierten und prozeduralen Programmierung - genau das unterscheidet es fundamental von den alten BASIC-Varianten.
Mit freundlichen Grüßen,
der Oberlehrer
Was sehen da meine Augen und Ohren...
Denke jetzt muss ich gezwungenermaßen auf CLOSED umstellen!
Soviel zum Thema Freiheit und Demokratie in der 8-Bit Welt.
Dachte CLOSED wäre Unsinn bei den Prozeduren, aber so dargestellt, macht es schon sehr viel Sinn!
Danke für die ausführliche Erklärung!
-
Seit dem ist natürlich bei mir alles OPEN und ich habe es nicht weiter verfolgt.
OMG!!!!!
Dann nutzt du COMAL nicht richtig. Eine Prozedur/Funktion sollte im Idealfall immer CLOSED sein. Wenn du das nicht so machst, dann hast du wahrscheinlich das Konzept einer prozeduralen Programmiersprache nicht verstanden.
Ich glaube, ich muss da später noch mehr zu schreiben. Im Moment geht es nicht. Ich krieg' nämlich gerade einen Herzinfarkt. Wo ist der Defilibrator?
Haha... Ja, das COMAL-80 Buch hat sich nicht so Kraftvoll und vor allem nicht so eindeutig vorgestellt.
Ansonsten wäre ich jetzt ganz bestimmt ein CLOSED Procedure Ninja mit COMAL-Diplom!
Aber mal im Ernst. Nach dem ich jetzt, wir wissen schon wofür, fast 30KB verpulvert habe, alles ohne CLOSED,
da fragt man sich schon wie wichtig eine geschlossene Prozedur eigentlich sein kann?
Dann warte ich mal gespannt auf die Informationen um zu sehen welche Argumente sprechen dafür, welche dagegen!
In der Zwischenzeit werde ich natürlich auch selber wieder ein Blick darauf werfen.
-
Ich bin ein sehr faules Pelztier in Bezug auf eigene Threads, aber eventuell werde ich mich mal selber überreden was in Bewegung zu setzen.
Ich würde mir das gut überlegen! So ein eigener Thread braucht regelmäßig Futter und Pflege und wenn man im Urlaub ist, muss sich jemand drum kümmern. Alles nicht so einfach!
Hmmm... Ich wollte es nicht so Präzise beschreiben, aber wenn es schon auf dem Tisch ist
-
Hier ist ein Comal-Buch für den C128.
Danke für die Bemühungen. Das habe ich schon und habe sogar alles auf Englisch übersetzt.
Aber ClausS hat denke vor einer Woche auch eine Deutsche Übersetzung zur Verfügung gestellt.
Gefunden:
C128-COMAL-Buch
-
Display More
Vergessen wir dann das Spiel. Werde damit diesen Grund und Boden nicht mehr belasten
Verstehe mich bitte nicht falsch:
Ich möchte nicht, dass wir dein Spiel vergessen. Im Gegenteil: Ich finde es sehr gelungen und ich möchte, dass es noch mehr Aufmerksamkeit bekommt.
Aber es wäre sinnvoll, wenn du für das Spiel einen eigenen Thread eröffnen würdest. Wir können dann dort weiter darüber diskutieren und uns ganz auf das Spiel konzentrieren.
Ich würde das genauso machen: Wenn ich ein tolles COMAL-Programm erstellen würde, dann würde ich es hier im Thread kurz erwähnen und dann auf einen anderen Thread verweisen, in dem ich das Programm gebührend mit Pauken und Trompeten vorstellen würde.
Dieser Thread hier soll eher dazu dienen, allgemeine COMAL-Fragen zu klären. Z.B. "Was ist eine Prozedur?". Oder: "Warum funktioniert GOTO 10 nicht?". Oder "Sollte ich CLOSED verwenden oder besser nicht?".
Nix für Ungut.
Das Spiel geht schon nicht ganz vergessen.
Im Gegenteil, es wird fleißig weiterentwickelt, man wird einfach hier nichts merken.
Ich bin ein sehr faules Pelztier in Bezug auf eigene Threads, aber eventuell werde ich mich mal selber überreden was in Bewegung zu setzen.
Wenn wir schon bei allgemeinen COMAL-Fragen sind... Bei CLOSED habe ich mich auch gefragt wozu es gut sein soll.
Irgendwo habe ich in den COMAL Anfangszeiten eine CLOSED Prozedur gemacht und da hat COMAL sofort gemeckert, weil ich USE {Package} nicht verwendet habe, also innerhalb der Prozedur {war alles mit COMAL-128}
Da habe ich natürlich überlegt warum brauche ich USE {Package} am Anfang und dann noch in den geschlossenen Prozeduren nochmals? Mein erster Gedanke war: Unnötiger Speicherverbrauch...
Seit dem ist natürlich bei mir alles OPEN und ich habe es nicht weiter verfolgt.
-
Display More
Display More
Natürlich...
Jetzt wo das Allgemeinwissen breit verbreitet ist, kommen neue Ideen ins COMAL-Spiel rein
Eigentlich wäre es nett, wenn du für dein Spiel einen separaten Thread aufmachen würdest. Hier im Thread soll es eigentlich um COMAL im Allgemeinen- und nicht um spezielle Projekte gehen.
Vergessen wir dann das Spiel. Werde damit diesen Grund und Boden nicht mehr belasten
Bei Allgemein-Projekten bin ich auch gerne dabei. Mal sehen was da noch alles kommt in Bezug auf COMAL.
Neues Wissen und Ideen kann ich immer gut gebrauchen.
Das wäre schade, aber Omega hat schon Recht .. das hier ist seine "Spielwiese" .. und ein eigener Thread wäre von Vorteil.
Ich verstehe ihn 100%. Leiste kein Widerstand
Darum werde ich jetzt meine Energie in diese Packages/Header Geschichte investieren, die ClausS erwähnt hat.
Allerdings für Comal-128... Ich bin halt eine C128 Seele
So wie ich es aus den Büchern / Dokumentionen verstanden habe, ist die Vorgehensweise praktisch identisch mit C64,
allerdings in einem anderen Adressbereich.
Im Grunde genommen, benötige ich nur BLOAD damit ich die Sprites und ML in ihre Bereiche katapultieren kann ohne KB-Weise DATA xyz zu schreiben und damit wertvollen Speicher verschwenden {Quellcode}
Grafik/Farbe und Sprites sind im RAM BLOCK 1 {und RAM BLOCK 0, $0e00) und somit sollte BLOAD hier bessere Dienste leisten als die C64 Version, oder?
