Wer programmiert Basic von Euch ?

Es gibt 362 Antworten in diesem Thema, welches 39.495 mal aufgerufen wurde. Der letzte Beitrag (29. September 2023 um 22:13) ist von Goodwell.

  • d.h man könnte dann den IL auf andere Prozessoren hinassemblieren und die Spiele dann auf anderen Platformen spielen ??

    Interessant - Atmel AVR, ARM,68K.....

    Man könnte...aber dazu muss man halt die Runtime für die entsprechende Plattform noch bauen und man hat dann natürlich keine C64-Hardware dort laufen. Der Code an sich würde aber rennen. MOSpeed kann das ja bereits mit Javascript und Powershell. Dss macht zwar 0 Sinn, aber ging halt...

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Woraus besteht die Runtime eigentlich?

    Vectoren ins BASIC ROM ?

    Anderes ?

    Alles mögliche... natürlich werden einige Routinen aus dem BASIC-ROM verwendet, aber nicht nur. Stringverwaltung, Garbagecollection und generell Variablenzugriffe sind alle autonom und haben nichts mehr damit zu tun, was BASIC macht. Einige Floatingpoint-Routinen sind ersetzt usw usf.

    Auf einer höheren Ebene sind das aber letztendlich die Aufrufe, die man als Label in der IL findet, die dort aber keine Implementierung haben.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Aktuell programmiere ich viel mit dem Oric. Dessen Basic hat viel Ähnlichkeit mit dem des TI-99, was mir sehr gut gefällt, vom Befehlsumfang her.

    Im Moment des Todes verliert Nationalität völlig seine Bedeutung.

    Ist Sie dann nicht jetzt schon obsolet?!

  • check ! Danke ! Interessant

    Konntest du den Print Befehl oder anderes beschleunigen ?

    PRINT nur in der Form, dass ich für Integer und ganzzahlige Gleitkommazahlen im Integerbereich alternative Routinen eingebaut habe. Der Rest geht aus Gründen der Kompatibilität über die normalen ROM-Aufrufe.

    Durch die alternativen Gleitkommaroutinen werden +-*/ und SQR schneller.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Oric sagt mir gar nix ?

    Eigenartig was die Inselbewohner da für ein Zeug immer wieder heraus gedrückt haben....

    Interessant aber das: "Der Kummonisten Volx Computer"

    Der Atmos wurde in Jugoslawien lizenziert und als Nova 64 verkauft.[3] Die Klone basierten auf dem Atmos, der einzige Unterschied war das Logo mit der Aufschrift ORIC NOVA 64 anstelle von Oric Atmos 48K. Dies soll auf die 64 KB Arbeitsspeicher hinweisen - was auch für den Atmos galt -, von denen 16 KB in beiden Modellen beim Starten durch das ROM verdeckt werden, so dass 48 KB für die Arbeit mit der BASIC-Sprache übrig bleiben.


    In Bulgarien wurde der Atmos-Klon unter dem Namen Pravetz 8D zwischen 1985 und 1991 produziert.[3] Der Pravetz ist hard- und softwaremäßig vollständig mit dem Oric Atmos kompatibel. Die größte Änderung auf der Hardwareseite ist das größere weiße Gehäuse, das eine komfortable mechanische Tastatur und ein integriertes Netzteil beherbergt. Das BASIC-ROM wurde so gepatcht, dass es sowohl ein westeuropäisches als auch ein kyrillisches Alphabet enthält - der Großbuchstaben-Zeichensatz erzeugt westeuropäische Zeichen, während die Kleinbuchstaben kyrillische Buchstaben ergeben. Um die Verwendung der beiden Alphabete zu erleichtern, ist der Pravetz 8D mit einer Feststelltaste ausgestattet. Eine Disk II-kompatible Schnittstelle und ein eigenes DOS, genannt DOS-8D, wurden 1987-88 von Borislav Zahariev entwickelt

    lt. Wicki

    RAM von ROM verdeckt .... also echt jetzt ? Damals wo RAM so teuer war ..... und jeder mehr bieten wollte als der Konkurrent.....

    Keine Sprites ?

  • Bitte melde dich an, um dieses Bild zu sehen.

    Bitte melde dich an, um dieses Bild zu sehen.

    oric 1 schematic 48K - wenigstens übersichtlich :wink:
    Frag mich wie die in Yugoland MOS6502 CPUs importierten .... das war ja Embargo Ware ?!

  • Bitte melde dich an, um diesen Link zu sehen.

    ULA Deconstruction 1

    Back in 1996, when there was little hope of finding replacement HCS10017 ULAs for Oric, I began a deconstruction of the ULA's internals, using observed behaviour (the software inputs from memory, hardware outputs). This is the result of that process. There are some known minor discrepancies, so if you think there's a bug or inconsistency, you're probably right.

    As of August 2018, I have reverse engineered the actual schematic from a decapped and photographed example of the real silicon and its corresponding verilog file, see Bitte melde dich an, um diesen Link zu sehen.

    If you are searching for a replacement ULA for a broken Oric, look on eBay. They are now available from various sellers in Europe as NOS (new-old-stock) parts

    Download

    Documentation (original 1996 ZIP file of text and postscript/GIF diagrams, and 2018 complete PDF version) can be downloaded below.

    Bitte melde dich an, um diesen Link zu sehen.

    • Bitte melde dich an, um diesen Link zu sehen.
    • Bitte melde dich an, um diesen Link zu sehen.
    • Bitte melde dich an, um diesen Link zu sehen.
  • Kann man beim Mospeed irgendwie es so machen das ich für mein Adventure spiel die Räume als eigene Basicprogramme einzeln compiliere

    und ein Hauptprogramm die dann ladet, anspringt und trotzdem Variablen vom Hauptprogramm lesen und verändern kann ?

    Und auch in Unterprogramme ins Hauptprogramm springen kann ? Zb Parser und ablaufsteuerung des Spiels liegen im Hauptprogramm,

    während Räume mit den Rätseln und auch Objekte wie NPC Charactäre aber nachgeladen werden und in einem extra Bereich im Speicher laufen ?

    Wie müsste man das technisch angehen ?

  • Aktuell programmiere ich viel mit dem Oric. Dessen Basic hat viel Ähnlichkeit mit dem des TI-99, was mir sehr gut gefällt, vom Befehlsumfang her.

    Cool, was programmierst du auf dem Oric? Ich überlege auch mal etwas auf dem Oric zu coden.

  • check i ned ? worum gehts jetzt ?

    ULA => ooh la la :rolleyes:

    Übrigens, es gibt im Frühjahr immer diesen 10-Zeiler-Wettbewerb. Leute aus aller Welt, alle mit BASIC, aber auf verschiedenen 8bit-Systemen. Hab auch schon mal mitgemacht. Teilweise enorm, was die herausholen. Hier ein Bericht bei golem: Bitte melde dich an, um diesen Link zu sehen.

  • Aktuell programmiere ich viel mit dem Oric. Dessen Basic hat viel Ähnlichkeit mit dem des TI-99, was mir sehr gut gefällt, vom Befehlsumfang her.

    Cool, was programmierst du auf dem Oric? Ich überlege auch mal etwas auf dem Oric zu coden.

    Ach, bisher nur Spielereien. Habe so ein kleines Substraktionsprogramm für den Oric 1 programmiert und tippe auch viele Programme aus Magazinen ab, um mir das Basic anzuschauen.

    Im Moment des Todes verliert Nationalität völlig seine Bedeutung.

    Ist Sie dann nicht jetzt schon obsolet?!

  • Strukturiert ist das natürlich genauso wenig.

    Kann man schon machen, ich versuche so viel Struktur wie möglich in meine Programme zu bekommen.

    Das geht nicht. Nicht in dem Sinn, was man heute unter strukturierter Programmierung versteht.

    Ich dachte früher auch, dass ein bisschen Einrücken, viele GOSUB und schöne Kommentare strukturierte Programmierung ausmachen.

    "Uncle Bob" erzählt sehr launig vom "Krieg" der Programmiersprachen und -paradigmen:

    Bitte melde dich an, um dieses Medienelement zu sehen.

    Ab Minute 47:00 etwa auch Dijkstras Ansatz, Programme mathematisch zu beweisen. Im Gegensatz zu üblichen, Naturwissenschaftlich-orientierten Programm-Tests. Dijkstra: "Testing shows the presence, not the absence, of bugs."

    Dabei zeigte er, dass sich Programme mit GOTOs nicht beweisen lassen. Mit Strukturierter Programmierung, d.h. Beschränkung auf Sequenzen, Verzweigungen und Schleifen, ist das aber möglich.

    Daher auch seine Ablehnung von GOTO-lastigem, also unstrukturiertem BASIC.

  • Kann man beim Mospeed irgendwie es so machen das ich für mein Adventure spiel die Räume als eigene Basicprogramme einzeln compiliere

    und ein Hauptprogramm die dann ladet, anspringt und trotzdem Variablen vom Hauptprogramm lesen und verändern kann ?

    Und auch in Unterprogramme ins Hauptprogramm springen kann ? Zb Parser und ablaufsteuerung des Spiels liegen im Hauptprogramm,

    während Räume mit den Rätseln und auch Objekte wie NPC Charactäre aber nachgeladen werden und in einem extra Bereich im Speicher laufen ?

    Wie müsste man das technisch angehen ?

    Also vorgesehen ist das nicht. Ich habe eine grobe Idee, wie man sowas machen könnte aber auch die Gewissheit, dass ich das aktuell nicht tun möchte. In diesem speziellen Fall würde ich ohnehin eher argumentieren, dass es keine gute Idee ist, verschiedene Räume komplett über Code abzubilden.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • akademischer bullshit ... Philosphien eines Wichtigtuers ?

    Kann mich nicht erinnern je ein Spiel von diesem Dijkstas je besessen zu haben ?

    Beweisen von Programmen ? Sind wir jetzt Detektive oder Kriminalbeamte ?

    En Programm läuft auf einer Platform - oder eben nicht.

    Goto funktioniert und ist in 100erten Basic Programmen bewiesen. Für mich "Beweis" genug.

    Kein Goto in modernen Programmen? Echt ? Heutige Spiele werden doch alle "strukturiert" in C++ gemacht ?

    Habe in viele kommerzielle Programme hineingesehen und es sind tausende Jump Opcodes in den Libraries vorhanden !

    Einfach mal den IDA PRO aufreissen und ein aktuelles Spiel debuggen.

    Jeder hat doch seine eigene Struktur wo er im Speicher was , wie unterbringt.

    Auch ob er Preprozessoren verwendet um die Zeilennummern loszuwerden und dafür ein Labelsystem macht um sich das ständige RENUMBER zu sparen....

    Mein Topic bezieht sich auf den C64 da es ja das Forum64 ist und es geht jetzt eben ums C64 Basic

    Klar das man auf einem Mini Computer oder PC (microcomputer) anders programmiert weil es ja die Entwicklungsumgebungen so vorgeben....

    Ich würde mir lieber echte Vorbilder hernehmen welche auch ordentlich abgesaht haben (im finanziellen Sinn)

    Bitte melde dich an, um diesen Link zu sehen.

  • Kein Goto in modernen Programmen? Echt ? Heutige Spiele werden doch alle "strukturiert" in C++ gemacht ?

    Habe in viele kommerzielle Programme hineingesehen und es sind tausende Jump Opcodes in den Libraries vorhanden !

    Einfach mal den IDA PRO aufreissen und ein aktuelles Spiel debuggen.

    Na ich hoffe mal dass das jetzt nicht ernst gemeint ist...

    - neue Spiele für den C64 -
    Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.Bitte melde dich an, um diesen Link zu sehen.

  • Idee:

    Also wenn man am Raumcode einfach per Peek sich die Variablen vom hauptprogramm variablenspeicher in aktuelle Variablen holt , verarbeitet und zurück poked hat man eine Schnittstelle.

    Mit SYS kann ich Routinen im Hauptprogramm (nennen wir es mal "unten" weil es bei 0400 starten soll)

    vom Raumcode (nenn es oben , ab $8000) anspringen ..

    Aber wie ist das mit der RUNTIME ? ist die dann 2x im RAM ? einmal für den Raumcode und einmal fürs Hauptprg ?

    oder verstricke ich mich dann mit Zeropageadressen wo deine Runtime fixe Werte braucht die dann durcheinanderrutschen ?

    Es müsste eine Commandline option geben welche den Programmstart für "oben" auf $8000 setzten könnte .

    Gibt es das ?

    Ist halt mühsam herauszufinden wo im Hauptprogramm später welche variablen gespeichert sind

    auch die Adressen der Zeilennummern im Hautprogramm sollten irgendwo sein

    Gibt der Assembler / Linker eigentlich irgendwo diese Daten in einer Labelliste.txt aus ?