BASIC und Python - Was ist denn einfacher zu lernen?

Zitat von ZeHa

Wenn es lediglich ein Port vom C128- oder C16-BASIC waere auf den C64, dann waere es zwar eine feine Sache

Falls noch nicht bekannt: Basic 3.5 für C64

Zitat von Stephan

hier bringe ich gern , quasi als running gag, die Frage, wieviel ROM-Space hatte BBC-Basic zur Verfügung, und wieviel hatte BASIC V2 des C64 (und PET)?

Nebenbei zeigt sich die Überlegenheit einfacher Speicher-Maps wie z.-B. beim C116: 60KB für die Hochsprache frei ... dank (im Gegensatz zu C64) nicht zerklüfteten Speicherbereichs und simplem Bankswitching. Und man kann 32 KB System-ROM unterbringen für besseren Interpreter.

Kann man eine Python-Implementierung in 9KB schreiben?

Okay... BBC BASIC III ging in 32K ROM rein. Mit diesen 32K hatte Acorn aber bereits was besseres am Start als CBM BASIC V3.5.

Selbst die 48K für BASIC V7 brachten da keine entscheidende Verbesserung. Was die Kontrollstrukturen anging, kam bei V7 ggü. V3.5 nur noch BEGIN...BEND dazu. Und das war mir so obskur, daß ich diese Blockbildung de-facto nie eingesetzt habe.

Dafür gab's in BBC BASIC bereits Prozeduren, Funktionen und lokale Variablen. Und man konnte locker auf GOTO und GOSUB verzichten - der Interpreter brauchte die Zeilennummern nur für das korrekte Einsortieren der Zeilen im Editor. Der war allerdings schon gewöhnungsbedürtig ...

Jetzt nehmen wir noch den Inline-Assembler dazu, der die gesamte Ausdrucksauswertung von BBC BASIC mitnutzen kann, und über IF...THEN und FOR...NEXT eine Stufe höher konditionierte und wiederholte Assemblierung zuläßt und dann kann man als C64 User eigentlich nur noch das: .

Zitat von Stephan

Versteh ich das richtig, BBC-Basic brauchte dennoch Zeilennummern zum Einordnen der Zeilen obwohl genug mit Struktur gesegnet? Und Basic V2 hatte einen branchenweit anerkannten Screen-Editor (der ein Arbeiten fast wie in Turbo Pascal hätte ermöglichen können) aber dennoch nicht genug Strukturlemente um auf Zeilennummern verzichten zu können?

Ad BBC BASIC: ganz genau. Irgendwo in der Anleitung steht auch noch drin, daß man ansonsten GOTO, GOSUB und die ON ... GOTO/GOSUB Befehle auch deshalb behalten hätte, damit es beim Portieren von Programmen in 'schwächeren' BASIC-Dialekten nach BBC BASIC keine unnötigen Probleme gibt.

Der Standard-Editor war aber, wie gesagt, etwas gewöhnungsbedürftig. Der Cursor konnte zwar innerhalb der Eingabezeile nicht frei bewegt werden (nur Löschen mit Delete war möglich), 'ging' man aber mit den Cursor-Tasten heraus, bekam man zwei Cursor-Marken, wobei man von beliebiger anderer Stelle am Bildschirm in die aktuelle Zeile reinkopieren konnte.

Es gab dann aber als Standard-Anwendung einen richtigen Fullscreen-Editor, der später auch auf den Archimedes portiert wurde. Auch hier wurden links noch Zeilennummern eingezeigt - die 'lebten' aber sozusagen in ihrer eigenen Welt (waren per Cursor nicht anfahrbar!) und wurden automatisch umnumeriert, wenn Zeilen eingefügt wurden und der Nummernbereich nicht mehr ausreichte...

Zitat von Stephan

Also diesen springbrunnenartigen Tränenfluss könnte man auch bekommen, wenn man sich vorstellt wie es wäre wenn der BBC-Basic Interpreter eine in einer FOR-NEXT-Schleife angeordnete Assembler-Routine bei JEDEM Schleifendurchlauf erneut "übersetzt" = assembliert , was zwar formal hochkorrekte Ergebnisse zeitigt und es dem Assemblerprogramm komfortablerweise ermöglicht auf die Bezeichner des Basic-Programms ohne Federlesens zuzugreifen, doch den SInn eines Assemblerprogramms auf den Kopf stellt .. hoffentlich ist es nicht so gelöst ....

Für das übllicherweise ohnehin notwendig 2-Pass-Assemblieren wird FOR...NEXT da sogar explizit eingesetzt. Beim ersten Pass wird mit der OPT-Direktive die Fehlerausgabe abgeschaltet und damit die Fehler durch Vorwärtsreferenzen unterdrückt. Beim zweiten Pass sind die Fehler dann dabei - aber alle Referenzen sind ja jetzt bekannt.

Natürlich springt ein Assemblerprogramm anschließend nicht in den BASIC-Interpreter zurück um sich die Zahlen abzuholen. Die Ausdrücke werden immer als Konstante in Adressen oder direkte Operanden hineingeschrieben. Vor dem Assemblieren wird noch Speicherbereich angefordert, der Inline-Assembler schreibt das Programm, und dann ist es fertig in kann per CALL aufgerufen werden.

Oder abgespreichert werden und dann kommt der Objektcode z.B. auf einem VC-20 zum Einsatz.

Ich hab' hier mal einen Ausschnitt eines neueren Programms (Malprogramm für einen Lightpen) parat:

Hi, Stephan,

ich habe da nicht den kompletten Source gepostet, der wäre dutzende Bildschirmseiten lang. Mir ging es speziell mal darum zu zeigen, wie der Inline-Assembler von BBC BASIC die Ausdrucksauswertung beim Assemblieren nutzt, mit einem Real-Life-Beispiel und nicht nur ein paar isolierten Programmzeilen.

Nicht vorgesehen war jetzt, daß Du dir die Mühe machst, das Programm zu reversen.

Der Inline-Assembler wird mit einer eckigen Klammer auf "[" gestartet, und hört bei einer eckigen Klammer zu "]" auf. Mit O% und P% werden zwei Adressen angegeben (s.u.), mit der OPT-Direktive gesteuert, ob Fehler gemeldet werden sollen, ein Listing erzeugt werden soll, Offset-Assemblierung erwünscht ist und ob überwacht werden soll, daß eine vorgegeben Adresse beim Assemblieren nicht überschritten wird (quasi ein Check auf Buffer-Overflow). Mit der Variante von DIM wird ein Speicherbereich alloziert und die Adresse davon in "code" abgelegt - der Wert wandert später nach O%. Das BASIC-Programm kann auch mehrere Abschnitte mit "[" "]" haben, O% und P% werden entsprechend weitergeschrieben.

Die Routine baut (unter Zurhilfenahme einiger Hilfsroutinen, die - wie gesagt - hier nicht gelistet sind) den Bildschirm auf, mit dem der Lichtgriffel kalibriert wird - daher der Name der Routine: "Cali". Dabei werden vier Fadenkreuze und einiger erklärender Text auf den Bildschirm gebracht. Sie ist ein kleinerer Teil des Gesamtprogramms, welches dann auch noch den Treiber für den Lichtgriffel enthält, schnelle Linienziehroutinen, und eine State-Machine für die Bedienung mit dem Lichtgriffel (s. Anleitung auf Diskette).

Noch zu O% und P% (Groß- und Kleinschreibung ist hier relevant!) - der Code wird ab O% geschrieben, die Adressen aber so generiert als wäre es gedacht, daß er ab P% laufen soll. OPT wird hier einmal mit 4 aufgerufen (Offset-Assembly AN, Fehler und Listing AUS) und dann mit 7 (alle, Offset-Assembly, Fehler-Meldungen und Listing AN).

Im Anhang mal das Ergebnis: braucht eine +8K RAM-Erweiterung. In echt brauchst Du einen Röhrenmonitor und Lichtgriffel - in VICE mußt Du den Lichtgriffel im Menü aktivieren: die linke Maustaste "führt" dann den Mauszeiger als Lichtgriffel ans VICE-Fenster, die rechte Maustaste ist für den Triggerkontakt an der Spitze zuständig.

Die weitere Bedienungsanleitung steht im READ ME auf der Diskette. Einfach bei Auswahl des Diskimages diese Datei im Dateibrowser doppelklicken.

Zitat von Stephan

Prima ... zu würdigen ist auch, dass das Programm mit Zeichensatz-Grafik arbeiten muss. Keine Sprites, keine freien Hires-Bitmaps, sondern nur Zeichengenerator-Grafik bei beengtem RAM. VC-20-Programmierung at its best..

Naja - dafür hab' ich mir mit MINIGRAFIK schon vor Jahren eine Programmbibliothek gebaut, so daß sich Programme da nicht mehr um die Grundlagen kümmern müssen. Aus Sicht der Nutzerprogramme steht da eine echte Bitmap von $1100..$1FFF im Speicher, mit einer Auflösung von 160x192 Pixeln. Es gibt auch ein genau definiertes Format zum Speichern auf Tape oder Disk.

Der Kalibrier-Bildschirm nutzt allerdings nicht diese Bitmap, da die Mitten der Fadenkreuze in den Ecken des später verwendeten Grafikfensters stehen - deren Fläche also "herausragt". Das ist in der Tat mit einem speziellen Zeichensatz alles zurechtgebaut, und die Bildschirmdimensionen so angepaßt, wie sie benötigt werden. Die Bitmap ist von den Dimensionen her effektiv 20x24 Zeichen *), der Kalibrierbildschirm 22x27 da die Fadenkreuze 2x3 Zeichen sind - also muß der Kalibrierbildschirm 1 Zeichen nach links und rechts und 1 1/2 Zeichen nach oben und unten herausstehen - gegenüber der 20x24 Bitmap, nicht etwa dem normalen 22x23 Textbildschirm!

Ich hab's aber an anderer Stelle schon erwähnt - was der VC wirklich kann, läuft hier im Forum 64 weitgehend unter dem Radar.

...

Auf den Inline-Assembler von BBC BASIC bin ich über meinen "Umweg" über den Acorn Archimedes gekommen. Da hatte ich dann zuerst den Inline-Assembler vom BBC BASIC unter RISC OS zwischen, der da natürlich ARM-Code erzeugt hat. Mitgeliefert wird an Software da aber auch noch die sogenannte "6502Tube", die einen an einen BBC angeschlossenen 65C02-Koprozessor emuliert. Darauf läuft dann HI-BASIC (eine Variante von BBC BASIC mit mehr verfügbarem Speicher) ...

... und das ganze (incl. RISC OS) läuft jetzt schon lange als Emulation auf meinem Win-Notebook. DAS ist wirklich , funktioniert aber!

*) tatsächlich 20x12 doppelt-hohe Zeichen

Klar ist MINIGRAFIK im Diskimage mit drin.

Es wird automatisch mitgestartet, wenn die erste Datei BOOT oder die Datei READ ME geladen und gestartet werden. Diese beiden Bootloader starten dann zum eigentlichen Nutzprogramm, einmal MINISKETCH zum anderen BROWSE, durch.

Dadurch, daß BOOT als erstes Programm auf der Disk steht, wird es automatisch von VICE ausgeführt, wenn Du das Disk-Image in das Hauptfenster von VICE ziehst. Einfacher kann ich es nicht mehr machen.

Ich sag doch, daß es eine echte Bitmap ist! Jedem Bit in der Bitmap entspricht ein Pixel auf dem Bildschirm.

Kein Rumgedöne mit dem Textbildschirm - das nimmt MINIGRAFIK alles den Nutzprogrammen ab.

Übrigens wird sehr wohl auch Farbinformation mitgespeichert, nur nutzt MINISKETCH diese nicht. Das Speicherformat sieht aber für jede der 8x16-Pixel-Attribut-Zellen den Wert vor (die Nibbles werden kompakt weggespeichert) und es ist sogar noch eine Display-Routine dabei, so daß man das Bild einfach mit LOAD "NAME",8 (*nicht* ,8,1!) laden und mit RUN anzeigen kann.

...

Als Abschluß für heute reiche ich hier noch die Doku zu MINIGRAFIK nach. Siehe Anhang B in der Bedienungsanleitung zu MINIPAINT.

Gute Nacht beisammen.

Was Mike mit dem VC20 noch so alles macht sieht man hier:
http://sleepingelephant.com/ip…n/bb/viewtopic.php?t=4882

Btt:

Ich habe dieses Python-Buch für 9,90 Euro ebenfalls gekauft und ich finde es gut! Es richtet sich an Menschen, die keine Ahnung von Hardware haben und noch nie zuvor programmiert haben.
Mein Ziel ist, mit Python solche Dinge zu tun wie Formate konvertieren, Werte-Tabellen aufbauen und Textdateien nach Informationen durchsuchen und gezielt verändern. Auch möchte ich mit Python Windows GUIs aufbauen als Oberfläche für kleine Tools. Ich habe noch nie eine GUI-Benutzeroberfläche erstellt und würde das mit Python gerne mal ausprobieren.

V2 Basic versagt hier zu großen Teilen, was ja auch keine Schande ist, wir reden ja von über 30 Jahren Entwicklungsabstand. Das Retro-Thema lässt sich mit den Mitteln von heute besser ausreizen, daher ist ein Cross-Assembler sinnvoll, ein moderner Texteditor, moderne C64 Tools auf Windows-Basis und eben auch ein Basic-Ersatz wie Python, der mit allen möglichen Erweiterungen sehr praktisch und mächtig sein kann.

Zitat von Stephan

Zu dem Sleeping Elephant-Thread und Mikes Aktivitäten:
- zu den Hardware-Modifikationen gehört anscheinend auch die Demontage von Taste "7" auf dem VC-20 Keyboard ?

Den Schmäh hat e5frog in eben jenem Thread vor 7 Jahren auch schon gebracht. Gähn. Das ist eben das, was passiert, wenn jemand anders einem die Datasette auf die Tastatur wirft. Sonst noch Fragen?

Zitat

- Die Heizung ist aus Gußeisen und nicht aus Stahl!

Ja. Und?

Zitat

- Warum heisst der Betreiber eig. "Sleeping elephant" und was ist der genaue Bezug warum das Wiki "Denial Wiki" heisst? Sind das Wortspiele aus dem angelsächsischen Raum die hier keiner versteht?

Jeff macht noch andere Sachen mit der Website als nur das VC-20-Forum zu betreiben. Davon ab ist "Denial" einfach ein modifiziertes Anagramm seines Nachnamens.

Zitat

Lustig fand ich, dass die anderen User Mike darauf hingewiesen haben, dass er quasi den Rechner neu aufbauen muss für den FLI-Modus und dass aber die Hersteller-Garantie auf seinen VC 20 durch die Löterei verloren ginge

O.K. - nochmals - der Schmäh ist kalt.

...

Um noch meinen Beitrag zum Original-Topic mit unterzubringen: es stellt sich ohnehin gar nicht die Frage, ob man Python jemals auf dem C64 sehen wird. Wenn man eine neue Programmiersprache lernt, wird es auf jeden Fall einfacher, wenn man in der Lage ist, gewisse Transferleistungen zu erbringen. Schlimmstenfalls schaut es dann nur eine Zeitlang so aus, als würde man Programme in der neuen Sprache B so programmieren, wie man sie auch in der alten Sprache A programmiert hat. Irgendwann kommt man dann vielleicht darauf, das sich die Aufgabenstellungen in B auch viel konziser lösen lassen, wenn man sich auf deren Eigenheiten einläßt - das dauert nur halt seine Zeit.

BASIC auf 8-Bittern kommt so out-of-the-box und ist dort weitgehend unveränderlich (es sei denn man hilft mit Spracherweiterungen nach ... ) - auf heutigen Rechnern kommt bei den Programmiersprachen neben deren Sprach-"Kern" auch immer ein Haufen von Bibliotheksfunktionen, selbige u.U. auch noch OS-abhängig dazu, und das im stetigen Fluß. Da muß man erst mal die Lernkurve aufbringen und später auch immer noch bei Neuigkeiten diese dann überschauen. Ist also nicht nur speziell bei Python so.

Letztenendes ist es jedem selbst überlassen womit er zu Hause, als Hobby, programmiert. Auf der Arbeit wird man sich das im Regelfall nicht selbst aussuchen können.

@ Stephan
Für den Fall dass ich mich nicht klar genug ausgedrückt habe möchte ich betonen, dass der c64 das Zielsysten bleibt für das entwickelt wird. Ich entwickle nur nicht mehr AUF dem c64.
Python ersetzt dabei insofern Basic als es um mathematische Berechnungen geht die ich sonst in v2 Basic gemacht hätte.
Reines V2 Basic stirbt trotzdem nicht für mich aus da ich trotzdem weiter Lust habe, Basic
Entwicklungen für den c64 zu machen (obwohl es ein Zorn -Erreger -Basic ist. ;-).). Die entstehen aber in einem Texteditor und nicht mehr am 40 Zeichen Bildschirm.

Zitat von Stephan

vermutlich wollte ich nur darauf hinaus, dass es leider nicht jedermanns Sache ist, den Rechner soweit umzugestalten ...

Auch das hab' ich bereits feststellen dürfen. Sonst gäbe es nämlich mehr als die zwei mir bislang bekannten umgebauten VC-20 (meiner und noch von jemand aus NTSC-Land, siehe Thread).

Zitat

... dass er 4x soviel Farb-RAM hat ...

16x soviel Farb-RAM und die "Lücke" von $0400 bis $0FFF ist jetzt auch für den VIC-Chip zugreifbar. Mit einer externen +3K-RAM-Erweiterung geht das nicht (der VIC kann allgemein überhaupt auf gar nichts am Expansionsport zugreifen) - sonst hätte ich mir erst gar nicht die Mühe machen müssen, den Rechner umzubauen.

Davon ab ist der VFLI-Mod nur ein Seitenzweig eines viel größeren Projekts, bei dem Torsten Kracke und meinereiner ausgelotet hatten, was an Grafik-Modi jenseits der 160x192 und *ohne* Umbauten tatsächlich geht. Ohne Umbau geht z.B. die halbe Auflösung von VFLI, statt 208x256 halt 104x256, mit sonst gleichen Eigenschaften. Allerdings ist dann die CPU zu 100% damit beschäftigt, den VIC zu unterstützen und macht nichts anderes mehr. Mit dem Umbau und dann bei 208x256 hat die CPU immerhin noch 20% für's User-Programm über.

Zitat

damit die eigentlichen Software-Quirks und Experimente wie FLI* laufen

Die Vorarbeit ist bereits geleistet, es gibt eine Umbauanleitung, Treiber für die neue Grafik-Hardware und u.a. ein Konverter auf dem PC, der Bilder ins VFLI-Format umrechnet. Was willst Du mehr?

Zitat

(man fragt sich bei sowas allerdings erneut, warum Commodore nicht selber auf die Idee gekommen ist, das Design entsprechend flexibel freizuhalten .. und sei es ein leerer Sockel und freie Decoderausgänge.)

Die 5K RAM waren das Ergebnis sauberer Kostenkalkulation.

Tatsächlich nutzt der Mod zwei ansonsten freie Gatter in einem der ICs - daher kommt er ganz ohne (Zwischen-)Platine aus. Was die Anwendung angeht - in der Zeit wäre es schwierig gewesen, auf Echtfarbdaten zuzugreifen, sprich: die Anwendung wäre damals gar nicht umsetzbar gewesen und kein Hersteller hätte es sich leisten können, nicht nutzbare Hardware zu verbauen.

...

VFLI ist übrigens zusammengezogen aus VIC-I FLI und da steht FLI für Flexible Line Interpretation und damit *genau* dasselbe wie die FLI-Modi auf dem C64: die Attribut-Zellen sind nur noch 1 Pixel hoch. Jedes 8x1-Pixel-Feld kann frei über allen 8 Vordergrundfarben und Hires/Multicolour gewählt werden, weiterhin sind die 3 "globalen" Farben (Hintergrund/Rahmen/Hilfsfarbe) in jeder Rasterzeile frei wählbar, und das nutzt der Konverter voll aus.

Als Ergebnis gehen dann so Bilder wie ich sie unlängst in einem CPC-Thread über Farbmodelle (CPC <-> C64) mal reingesetzt habe, und die ohne weiteres mit der Qualität von NUFLI auf dem C64 mithalten können.

...

In dem Thread fragte e5frog dann auch noch, ob das beste was mit einem nicht umbauten VC gemacht werden könnte, bereits getan wäre: daraufhin kam von mir nur die Entgegnung, daß für normale Grafikanwendungen mindestens ein gutes Software-Paket längst zur Verfügung stehe und er sich doch bitte so frei fühlen solle, es auch zu benutzen.

Aber die Tendenz geht ja eher dahin, daß die Leutz lieber das (quadratische) Rad für sich neu erfinden...

Zitat von Stephan

Was ist TSB?

Siehe C64-Wiki.

Zitat von Stephan

Von einem Port "BBC basic auf C64" weiß Wikipedia nix

Google aber schon.