BASIC und Python - Was ist denn einfacher zu lernen?

  • Stephan schrieb:

    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: :cry: .
  • Mike schrieb:

    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: :cry: .
    Okay, danke für diese klarstellende Information eingangs ;) Dass BBC-Basic was besseres sei, sei zugestanden - halt nicht auf dem C16 ... mich nerv(t)en auch Basic-Erweiterungen, die einseitig für bestimmte Dinge den Komfort erhöhten, aber andererseits wenns ans Eingemachte geht- eben die Schleifen, Kontrollstrukturen, Stringverwaltung etc. keine belebenden Neuerungen brachten.

    Immerhin brachte der C128 einen Sprite-Editor mit - somit ein Zuckerl bzw. Goodie für die Fans derartigen Komforts , hier wurde wohl eine Marktanalyse durchgeführt ;)

    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?

    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 .... ;( ;)
    Gesendet über das Bimetall Thermorelais meines Rowenta DW 4015 Dampfbügeleisens
  • Stephan schrieb:

    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...

    Stephan schrieb:

    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:

    Quellcode

    1. REM>source
    2. DIM code 4096
    3. ** hier hab ich ein paar Zeilen ausgelassen **
    4. FOR pass=4 TO 7 STEP 3
    5. P%=&3000:O%=code
    6. [OPT pass
    7. ** hier steht auch noch einiges anderes Zeugs **
    8. .Cali
    9. LDX #0
    10. .Cali_00
    11. CLC
    12. LDA &EDE4,X:ADC Cali_16,X:STA &9000,X
    13. INX:CPX #6:BNE Cali_00
    14. LDA #&08:STA &900F
    15. LDX #0
    16. .Cali_01
    17. LDA #23:STA &1000,X:STA &1000+198,X:STA &1000+396,X
    18. LDA #6 :STA &9400,X:STA &9400+198,X:STA &9400+396,X
    19. INX:CPX #198:BNE Cali_01
    20. LDX #0
    21. .Cali_02
    22. LDA Charset,X :STA &1800,X
    23. LDA Charset+172,X:STA &1800+172,X
    24. LDA Charset+344,X:STA &1800+344,X
    25. LDA Charset+516,X:STA &1800+516,X
    26. INX:CPX #172:BNE Cali_02
    27. LDX #0
    28. .Cali_03
    29. LDA Cali_17,X:TAY
    30. TXA:CLC:ADC #80
    31. STA &1000,Y
    32. STA &1000+20,Y
    33. STA &1000+22*24,Y
    34. STA &1000+22*24+20,Y
    35. INX:CPX #6:BNE Cali_03
    36. JSR Clear
    37. LDX #0
    38. .Cali_04
    39. LDA Messages+0*12,X:STA &1000+22*12+5,X
    40. LDA Messages+1*12,X:STA &1000+22*14+5,X
    41. INX:CPX #12:BNE Cali_04
    42. LDA #0:STA XOrg:STA YOrg
    43. .Cali_05
    44. JSR Read:CMP #&9C:BNE Cali_05
    45. .Cali_06
    46. JSR Read
    47. CMP #&1C:BEQ Cali_07
    48. CMP #&8C:BEQ Cali_07
    49. CMP #&94:BEQ Cali_07
    50. CMP #&98:BNE Cali_06
    51. .Cali_07
    52. EOR #&9C:STA MASK
    53. JSR Clear
    54. LDX #0
    55. .Cali_08
    56. LDA Messages+2*12,X:STA &1000+22*13+5,X
    57. INX:CPX #12:BNE Cali_08
    58. .Cali_09
    59. JSR Read:AND MASK:BEQ Cali_09
    60. JSR Clear
    61. LDX #0
    62. .Cali_10
    63. LDA Messages+3*12,X:STA &1000+22* 9+5,X
    64. LDA Messages+4*12,X:STA &1000+22*11+5,X
    65. LDA Messages+5*12,X:STA &1000+22*13+5,X
    66. LDA Messages+6*12,X:STA &1000+22*15+5,X
    67. LDA Messages+7*12,X:STA &1000+22*17+5,X
    68. INX:CPX #12:BNE Cali_10
    69. LDX #0
    70. .Cali_11
    71. LDA Cali_18,X:STA scrn
    72. LDA Cali_19,X:STA scrn+1
    73. LDA #1:JSR Cali_15
    74. .Cali_12
    75. JSR Read:AND MASK:BNE Cali_12
    76. LDY YPos+1:CPY #&80:BEQ Cali_12
    77. LDA XPos :STA Data ,X
    78. LDA XPos+1:STA Data+4 ,X
    79. LDA YPos :STA Data+8 ,X
    80. LDA YPos+1:STA Data+12,X
    81. LDA #6:JSR Cali_15
    82. .Cali_13
    83. JSR Read:AND MASK:BEQ Cali_13
    84. INX:CPX #4:BNE Cali_11
    85. JSR Clear
    86. LDX #0
    87. .Cali_14
    88. LDA Messages+8*12,X:STA &1000+22*12+5,X
    89. LDA Messages+9*12,X:STA &1000+22*14+5,X
    90. INX:CPX #12:BNE Cali_14
    91. RTS
    92. .Cali_15
    93. LDY #0:STA (scrn),Y
    94. LDY #1:STA (scrn),Y
    95. LDY #22:STA (scrn),Y
    96. LDY #23:STA (scrn),Y
    97. LDY #44:STA (scrn),Y
    98. LDY #45:STA (scrn),Y
    99. RTS
    100. .Cali_16
    101. EQUB &00:EQUB &F8:EQUB &00:EQUB &08:EQUB &00:EQUB &0E
    102. .Cali_17
    103. EQUB 0:EQUB 1:EQUB 22:EQUB 23:EQUB 44:EQUB 45
    104. .Cali_18
    105. EQUB (&9400+22* 0+ 0) MOD 256
    106. EQUB (&9400+22* 0+20) MOD 256
    107. EQUB (&9400+22*24+20) MOD 256
    108. EQUB (&9400+22*24+ 0) MOD 256
    109. .Cali_19
    110. EQUB (&9400+22* 0+ 0) DIV 256
    111. EQUB (&9400+22* 0+20) DIV 256
    112. EQUB (&9400+22*24+20) DIV 256
    113. EQUB (&9400+22*24+ 0) DIV 256
    114. ]
    115. NEXT
    Alles anzeigen

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Mike ()

  • Woran der Interpreter erkennt , dass er gar nicht 'interpreten' darf sondern compilen muss (sobald das Wort "2-Pass" auftaucht , liegt für mich ein Compiler vor, Sonderfall: Assembler), ist mir nicht automatisch klar und was OPT bewirkt auch nicht. Insbesondere ist reichlich kryptisch, welche Startadresse der Code denn nun zugewiesen bekommt. wie kommt man auf die Idee, hexadezimale Zahlen als Oktal zu kennzeichnen? ;)

    - Dass das Programm mit CALL aufgerufen werden kann, schön und gut, aber der von dir versprochene CALL taucht nirgends auf. Stattdessen dutzende male "CALI".
    en.wikipedia.org/wiki/Kali

    - Du hast den VC 20 erwähnt und die trickreiche Umwidmung. Dass dein Beispiel dann tatsächlich für VC 20 und nicht für den BBC Mikrocomputer ist, habe ich erst verifizieren können anhand des Buchs "VC 20 intern" mit dem ROM-Listing.

    - auf die Variablen o% und p% die anscheinend mit der Code-Organisation zu tun haben, wird sonst nirgends zugegriffen?

    - das Unterprogramm READ wird vielmals benutzt aber nirgends definiert / deklariert?

    - soviel hab ich wenigstens herausbekommen, dass das Programm die VIC 6561-Bildschirmabmessungen aus der ROM-Tabelle nimmt und die ersten 6 Werte tlw. modifiziert in den VIC schreibt.
    Es werden der Bildschirm um 16 Pixel nach oben erweitert (verschoben), nach unten 4 Zeichenzeilen mehr drangehängt (im Ergebnis bleibt es wieder mittig und zentriert, aber statt 23 nun 27 Zeilen), der Zeichengenerator ins RAM verlagert und zwar mutmaßlich ab Adresse $0c00. Dann hat mich die Konzentration verlassen ...
    Gesendet über das Bimetall Thermorelais meines Rowenta DW 4015 Dampfbügeleisens
  • 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. :)
    Dateien
    • minisketch.zip

      (7,5 kB, 2 mal heruntergeladen, zuletzt: )

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Mike ()

  • Das ist ja ein richtiger Cross-Assembler .. die BBC Micro-Leute scheinen geahnt zu haben, dass man von dieser Seite den markt aufrollen kann ;)

    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..

    O% und P% die nur großgeschrieben sein dürfen: geschenkt. Erinnert mich aber an "case sensitive" unter Unix und das empfand ich mehrheitlich "doof".

    Dass einzelne bits von "vereinbarten Variablen" separate Bedeutung tragen: gibts ja auch bei Commodore. Statusvariable "ST" ...

    Insgesamt hab ich mir die Assembler - Einbindung unter BBC Basic viiiiel einfacher leichter leichtfüßiger (englisch: light weighted) vorgestellt. Der Assembler genau wie Debug oder TIM im PET, allenfalls um eine forward-Direktive bereichert, damit nicht 2 oder mehr Pässe notwendig sind, hätte eig. genügt -..... Selbsterklärend ist das OPT und Code und Pass-Gedöns aber wirklich nicht :drunk:
    Gesendet über das Bimetall Thermorelais meines Rowenta DW 4015 Dampfbügeleisens
  • Stephan schrieb:

    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 :drunk: , funktioniert aber!

    :D


    *) tatsächlich 20x12 doppelt-hohe Zeichen

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Mike ()

  • Ist das MINIGRAFIK Modul in obigem Lightpen-Programm voll enthalten, oder verkaufst du es separat? ;)

    ich finde, dieses Konzept hat die Datenkompression quasi eingebaut und daher ist es zeitlos relevant.
    Gesendet über das Bimetall Thermorelais meines Rowenta DW 4015 Dampfbügeleisens
  • 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 kann es trotz idiotensicherer Konstruktion hier und heute nicht gleich ausprobieren.
    Eine Korrektur will ich aber nachreichen: oben pries ich die eingebaute Datenkompression. Das war zu früh gefreut - dank doppelt hoher Zeichen sind die - unter Hires-Gesichtspunkten irrelevanten da nicht informationstragenden - Zeichenzeiger im Bildschirmspeicher nur noch 240 Stück, wodurch sogar noch 16 Zeichen für allg. Alphanumerische Zwecke verfügbar wären. Also stünde für jede der 240 Bildschirmpositionen auch mind. ein "eindeutiger" Glyph zur Verfügung und so erklärt sich auch dein Format das ca. 4 KB groß ist (= etwa die Hälfte einer C64-Hires-Bitmap ohne Farbinfo ) Datenkompression durch dynamischen Abgleich neuer Glyphs mit bereits bestehenden (ähnlich Brush-Konzept) und Re-Use derselben scheint hier gar nicht notwendig. Fast schade eigentlich :D
    Gesendet über das Bimetall Thermorelais meines Rowenta DW 4015 Dampfbügeleisens
  • 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.
    Dateien
    • manual.zip

      (241,24 kB, 2 mal heruntergeladen, zuletzt: )

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Mike ()

  • Was Mike mit dem VC20 noch so alles macht sieht man hier:
    sleepingelephant.com/ipw-web/b…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.
  • Deine Antwort verwischt leider zusehends, auf welchem System die ganzen neuen Programme eigentlich laufen sollen: auf einem original -(nahen)- C64? oder doch auf "Wintel", da du am Schluss von Windows schreibst?

    Zitat: "...moderne C64 Tools auf Windows-Basis ..."


    Ich habe den Thread schon so interpretiert, dass es um Python auf einem 6502-basierten System gehen sollte...

    danke für die Buch-Empfehlung! zu den Verwendungszwecken kann ich sagen, d'accord, für so etwas möchte man nicht unbedingt langwierige Prozedurköpfe schreiben müssen, sondern man möchte ohne langwierige Compilerläufe Erfolge erzielen.

    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 ?
    - Die Heizung ist aus Gußeisen und nicht aus Stahl!
    - 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? 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

    Ich fasse noch einmal ein paar Anforderungen zusammen, die eine Python-Implementierung auf einem 6502 können sollte:

    - Interpreter statt Compiler für schnellen Turn-around und kompakte Code-Größe;
    - Funktionen und Prozeduren, wodurch sich Funktionalität mittels Hierarchie zusammenbauen lässt;
    - keine Notwendigkeit, (alle) Variablen zu deklarieren; erstes Benutzen = Deklaration; (vgl. Basic!)
    - leistungsfähige Stringverarbeitung z.b. für das o.g. Durchsuchen und Ersetzen in Text-Files;
    Gesendet über das Bimetall Thermorelais meines Rowenta DW 4015 Dampfbügeleisens
  • Stephan schrieb:

    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?
    - Die Heizung ist aus Gußeisen und nicht aus Stahl!
    Ja. Und?
    - 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.
    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.
  • @Mike: ich wollte keinesfalls respektlos rüberkommen, vermutlich war ich nicht ganz ausgeschlafen und der 'Gähn'-Effekt hat sich dann eingeschlichen... vermutlich wollte ich nur darauf hinaus, dass es leider nicht jedermanns Sache ist, den Rechner soweit umzugestalten dass er 4x soviel Farb-RAM hat damit die eigentlichen Software-Quirks und Experimente wie FLI* laufen (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.)

    * ich komme schon wieder mit den Abkürzungen durcheinander, denn FLI(-4LINUX) war mal ein Selbstbau-Router aus abgelegten PC's ;)

    @Bytebreaker:
    kann das gut nachvollziehen was du schreibst. Genauso habe ich seinerzeit auch auf dem C128 für den C64 entwickelt oder auf dem C16 für den VC20 ... beim Editor lohnt sich der Komfort und kommt der Kreativität zugute.

    Edit:
    Um auf den Threadtitel zurückzukommen: Die Frage ist so wie sie ist eine Glaubensfrage. wenn wir, nach z.T. jahrzehnten EDV-Erfahrung, uns dies fragen, so ist es eher die Frage nach dem "Umstieg": wie leicht fällt der?

    Da die Sprache einigermaßen erfolgreich ist, glaube ich, dass sie jedenfalls nicht schwerer zu erlernen ist als BASIC. Sie ist sozusagen didaktisch einigermaßen intakt.

    Erst dadurch, dass die Frage hier, in einem Forum für Retro-Computer , gestellt wird, bekommt sie automatisch die ganzen Folge-Fragestellungen "ab": wie müsste man eine Portierung anstellen, kann man sie statt Basic gleich ins ROM packen usw.

    Kann man Python statt Basic ins ROM eines C64 oder C16/+4 packen?
    beim Plus 4 vereinfacht sich die Frage denn dort sind ja Funktions-ROMs reichlich im System vorgesehen.

    Es stellt sich eher die Systematische Frage:
    Das Basic V2 ist ja zugleich die Bediensprache für das rudimentäre CBM-Betriebssystem.
    Ich kenne Python nicht gut genug. Aber eignet sich Python überhaupt für das Konzept des C64:
    - full screen Editor
    - Unterscheidung Direktmodus / Zeilen mit und ohne Zeilennummern f. weitere Bearbeitung?

    Lässt sich sowas wie der Basic-Direktmodus überhaupt mit dem Sprachkonzept von Python vereinbaren?
    Gesendet über das Bimetall Thermorelais meines Rowenta DW 4015 Dampfbügeleisens

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Stephan ()

  • Stephan schrieb:

    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).
    ... 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.
    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?
    (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...

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Mike ()