Beiträge von Nervengift

    Bringt jemand zufälligerweise etwas mit womit man einen 6502 aus einem Apple IIe testen kann? Ich vermute, dass der 6502, der mal in meinen IIe gesteckt hat, hinüber ist.

    Im //e macht sich ein 65C02 besser

    Der 65C02 ist in meinen IIe auch schon kurz nachdem ich den IIe bekommen hatte reingewandert. Damit war der IIe dann schnell zu einem enhanced IIe geworden. Ich hatte dann zwischendrin mal wieder die alten ROMs und den ursprünglichen 6502 drin, um ein paar Tests zu machen. Dabei ist mein IIe allerdings gestorben bzw. der 6502 oder einer der originalen ROM-Bausteine. Letzten Endes ist der IIe in der enhanced Variante um einiges besser wie ich finde. Ich wollte nur gerne herausbekommen welcher Baustein sich verabschiedet hatte.

    Zur Not mache ich Platz und komme nur als Besucher vorbei ohne Austellungsstück. :) Ich wollte mit meiner Firebee vorbeischauen und die Biene auf einen aktuellen Stand bringen. Ich habe damit aber auch keinen Zeitdruck. ;)

    Wäre Schade wenn du ohne Hardware erscheinst, hätte gerne mal eine Firebee im Einsatz gesehen.

    Ich packe mal alles ein. Wenn jemand noch Platz braucht, kann ich ggf. auch etwas zusammenschieben und wir können uns dann einen Tisch teilen.

    Nimm ein Kopierprogramm wie CopyA oder Locksmith. Damit kannst Du den Inhalt von D1 nach D2 kopieren, also schreiben .

    Ich glaube, das geht so nicht. Ich habe auf der Prodos-Partition *.dsk Files liegen und will die auf die echte Floppy schreiben.

    Da gibt es ein Programm für, dass das macht. Nennt sich DISK2FILE. Das nutze ich auch öfters:


    DISK2FILE bei ASIMOV

    Das Programm war auch schon mal Thema hier im Forum:

    Schreiben von Apple II Disketten

    Ich habe den Text Viewer nochmal überarbeitet und INALL.DATA in denselben integriert. Jetzt ist das Programm tatsächlich ganz gut benutzbar und macht das, was ich ursprünglich im Sinn hatte. Ich habe nochmal ein bootfähiges 140 kB Diskettenimage des aktuellen Text Viewers für ProDOS gebastelt. Das Image enthält die Version 1.6, die dazugehörige Liesmich-Datei sowie den Sourcecode der Version 1.6 in einer Textdatei. Wer mag kann sich das Programm gerne runterladen und nutzen.


    Der Text Viewer ist zwar für sequentielle Textdateien gedacht, aber random Access Textdateien sollten vom Text Viewer auch zuverlässig angezeigt werden. Ein Problem ist noch, dass, wenn ein Eintrag einen String enthält, der mehr als 80 Zeichen hat, es leider zu Fehlern in der Anzeigemaske kommt. Mal sehen ob ich das nochmal angehe. Ich hoffe, dass das nicht so oft in Textdateien vorkommt.


    Hier könnt ihr euch den Text Viewer 1.6 herrunterladen: Text_Viewer_1_6.PO.zip

    Du bist ein Schatz!!! :love:<3:hahn::juchee:


    ALLIN.DATA funktioniert auch mit Textdateien!!! Es werden alle Zeichen ausgelesen und dargestellt!!!

    Na, das freut mich! Es gibt in einer späteren Ausgabe des Peeker dann noch eine erweiterte Fassung mit diversen Features. Die soll auch auf einer Begleitdiskette sein; das suche ich die Tage noch 'raus. Kann aber sein, dass die dann nicht mehr mit Textfiles läuft.

    Passt schon alles. Ich denke, ich kann erstmal das damit umsetzen, was ich möchte. Damit wäre dann die größte Baustelle des Programms abgearbeitet. Es gibt noch ein oder zwei andere Dinge, die mich an dem Programm stören, aber das kommt dann irgendwann mal.

    yalsi Du bist ein Schatz!!! :love:<3:hahn::juchee:


    ALLIN.DATA funktioniert auch mit Textdateien!!! Es werden alle Zeichen ausgelesen und dargestellt!!!


    :hüpf:


    Ich werde den Text Viewer morgen mal anpassen und gucken ob der dann so läuft wie er laufen sollte. Wenn das der Fall ist, poste ich hier nochmal eine aktualisierte Version.


    Holger mit dem direkten Laden einer Textdatei in den Speicher werde ich auch nochmal ein paar Versuche machen. Vielleicht kann ich in meinem alternativen Text Viewer (Fast Viewer) die Methode nutzen, um den etwas zu beschleunigen.


    Habt auf jeden Fall vielen Dank für euere Hilfe. Ohne euch wäre das Programm so geblieben wie es war.

    Die Qualität passt schon. Es ist lesbar. :) Ich kann nur rein gar nicht Assembler. :(

    Musst Du ja auch nicht. Die DATA Zeilen enthalten ja den Hexdump des Programms, das Assemblerlisting erläutert dann nur, was das Programm macht. Wenn Du das Stückchen BASIC an den Anfang Deines Programms stellst, ist schon alles getan.

    Du meinst das Basicprogramm hier:



    Ich versuche das nochmal umzusetzen. Mit NUINPUT hattest Du leider richtig vermutet. Das klappt nicht mit Textdateien. Wenn INALL auch nicht hinhaut, dann probiere ich @Holgers Methode aus und lade die Textdatei mit BLOAD. Habe ich Dein Programm richtig verstanden?

    10 PRINT CHR$(4);"BLOAD TEXT.FILE,TTXT,A$6000" --> Läd die Textdatei TEXT.FILE, was macht A$6000?

    20 REM Darstellen der geladenen Textdatei

    30 TS = 24576 --> Wozu ist TS gut und der Wert 24576? Die entsprechende Speicheradresse an der sich der Anfang der Textdatei befindet? Deswegen T(extdatei)S(tart)? :)

    40 L = <Länge der Datei, die Du rausgefunden hattest> --> Du meinst die Gesamtanzhal der Zeichen einer Textdatei?

    50 FOR A = TS TO TS + L: PRINT CHR$( PEEK( A ) );: NEXT --> Auslesen der einzelnen Zeichen der Textdatei von Dateianfang bis Ende.

    Wie hieß das damals im Labor: "Wenn eine Methode nicht funktioniert, probieren wir einfach eine andere. Die geht dann auch nicht." - darum habe ich mal ein bisschen gesucht und in einem Peeker-Heft etwas gefunden zum Abtippen. Ob das mit Textdateien geht, habe ich aber noch nicht getestet.


    Sorry für die schlechte Qualität- ist ein schnelles Handyfoto.

    Die Qualität passt schon. Es ist lesbar. :) Ich kann nur rein gar nicht Assembler. :( Hab mal auf jeden Fall vielen Dank, dass Du Dir die Mühe gemacht hast und etwas entsprechendes gefunden hast. 8-)


    Wie kann ich eine Texdatei denn mit BLOAD in den Speicher lesen? Sorry ... außer ein wenig Basic kann ich nichts. :oops:

    Ich mache mal mit NUINPUT rum und schaue was dabei rauskommt. Wenn's mit der Schwangerschaft nicht klappt, dann muss ich mal weiter gucken. 8o

    Wenn man diesem Beispiel hier folgt, dann sollte es eigentlich erstmal ganz einfach sein:


    CALL 250 entspricht einem INPUT ST$. Das Problem wird sein: Wie bastel ich das in eine Schleife? Ich brauche ein INPUT ST$(I). Ich denke, dass sich CALL 250 nicht indizieren lässt.

    NuInput sieht schon sehr vielversprechend aus:


    Zitat

    NuInput offers the following improvements over INPUT:


    accepts comma, colon, and double-quote


    Das würde mein Problem ja schon lösen. Muss ich mich nur mit der Anwndung des Programms vertraut machen. Das dürfte noch die größte Hürde an dem Unternehmen werden, den Text Viewer das mit dem Doppelpunt etc. beizubringen.

    Ich habe mal ein bootfähiges 140 kB Diskettenimage des Text Viewers für ProDOS gebastelt. Das Image enthält die aktuelle Version 1.5, eine Liesmich-Datei sowie den Sourcecode in einer Textdatei. Wer mag kann sich das ja mal anschauen. Wäre echt cool, wenn es einen Pokebefehl gäbe, so dass beim zeilenweise Auslesen einer Textdatei der Doppelpunt und das Komma nicht mehr stört.


    Hier könnt ihr euch den Text Viewer 1.5 herrunterladen: Text_Viewer_1_5.PO.zip

    Holger das mit dem GET-Befehl habe ich schon in einem alternativen Text Viewer, den ich Fast Viewer genannt habe, umgesezt. Dann ist das Problem tatsächlich nicht vorhanden. Vielleicht liegt's daran, dass jedes Zeichen einzeln eingelesen wird und nicht zeilenweise. Nachteil an meinem "Fast Viewer" ist, dass der tatsächlich langsamer ist als der Text Viewer. Der Bildschirmaufbau dauert viel länger, weil jedes Zeichen einzeln auf den Bildschirm gezeichnet wird. Ein weiterer Nachteil ist, dass ich bislang noch keine Möglichkeit gefunden haben bzw. eingebaut habe, um zu bestimmten Zeilen zu springen. Das ist bereits im Text Viewer umgesetzt.


    Den Source-Code des Text Viewers kann ich gerne zur Verfügung stellen bzw. auch das Programm an sich. Ich bin zur Zeit dabei, den Code zu überarbeiten und möchte noch ein wenig die Formatierungen verbessern. Sobald ich damit durch bin, lade ich das Programm gerne hier hoch.

    Hallo liebe Apple II Basic Profis!


    Ich hatte vor ca. einem Jahr unter ProDOS Basic einen Text Viewer für sequentielle Textdateien programmiert, der auch im Grude das macht, was er soll. ;) Nur leider hat das Programm ein gravierendes Problem: Sobald eine Zeile einen Doppelpunkt, Komma oder ähnliches enthält, wird der nachfolgende Text der Zeile nicht mehr dargestellt. Der Text wird zeilenweise (Record) eingelesen. Gibt es ggf. ein paar Poke-Befehle oder ähnliches mit denen sich diese Eigenschaft von ProDOS bzw. Applesoft Basic abschalten und auch auch wieder anschalten lässt?


    Nette Grüße

    Andreas

    felge1966 Ausnahmen bestätigen die Regel. :wegmuss:


    Joe_IBM ich hatte mit DOS 3.3 auf dem IIe angefangen und hatte mich dann mit ProDOS auseindergesetzt. Ich finde ProDOS um einiges besser als DOS. Aber ist eben alles Geschmackssache.

    Wenn man schon die Möglichkeit hat einen IIe zu einem fairen Preis zu bekommen, dann sollte man den sich nicht durch die Lappen gehen lassen, denke ich. :)

    Ich habe da mal etwas programmiert. :) Das Programm, das dabei enstanden ist, habe ich DOS Peeker genannt. Mit Hilfe des Programms kann man die beiden oben genannten Speicherbereiche auslesen (peeken). Die ausgelesenen Werte können optional in eine Textdatei geschrieben werden. Infolgedessen kann man prüfen welche Werte unterschiedliche DOS bzw. ProDOS Versionen in den entsprechenden Speicherbereichen drinstehen haben und jene gut miteinander vergleichen.


    Ich veröffentliche das Programm hier im Forum. yalsi ich hoffe das geht in Ordnung und ich verstoße nicht gegen Forenregeln? Ich bin da nicht so gut im Durcharbeiten von Regelwerken. :oops:


    DOS Peeker kann gerne weitergeben werden und auch verändert werden. Wenn's verändert wird, dann löscht nur bitte mein Pseudonym aus dem Code. Ob DOS Peeker wirklich einen Nutzen für jemanden hat, weiß ich nicht. Das mag bitte jeder für sich selbst entscheiden. Es ist ein kleines Weihnachtsgeschenk. :xmas:


    Ich habe zwei bootfähige 140 kB Diskettenimages für DOS (DSK-Image) und ProDOS (PO-Image) gebastelt. Also schlagt zu und angelt euch DOS_PEEKER.zip!


    :angeln:

    Ich würde mich auf jeden Fall für den IIe enstscheiden. Der ist eindeutig vielseitiger und bietet eine Ganze Menge mehr Möglichkeiten ohne die Kompatiblität zu den Vorgängern zu verlieren. Es ist zwar richtig, dass wenn ein ASIC des IIe das zeitliche gesegnet hat, eine Wiederbeschaffung nicht so einfach ist, aber man muss auch sagen, dass die Apple ASICs nicht dazu neigen kapputt zu gehen. Die Hauptplatine des IIe ist sehr robust und macht eigentlich kaum Zicken. Das Netzteil des IIe braucht auf jeden Fall etwas mehr Zuwendung.


    c001cafe wenn Du ganz hart bist, kannst Du Dir eine ganz neue Apple II (plus) Hauptplatine auch selbst neu zusammenbauen. Dazu findet sich auch eine ganz neue Tastatur und Netzteil. Von MacEffects gab's auch mal ein neues Plexiglasgehäuse. Zur Zeit scheint das aber nicht verfügbar zu sein. Allerdings ist der Spaß dann nicht ganz günstig, wenn Du alles neu zusammen baust. Es dürften insgesamt ca. 1000 € mindestens zusammenkommen, fürchte ich. Andererseits werden die Apple II plus inzwischen auch sehr hoch gehandelt.

    Für DOS 3.3 habe ich gefunden:

    Code
    X=PEEK(46725) Determines DOS version - if X=165 then DOS 3.3.0; if 186 then
       DOS 3.3e; if 182 then DOS 3.3f; if 206 then ProntoDOS

    siehe hier: https://www.vintagecomputer.net/browse_thread.cfm?id=790


    Aber ProDOS? Zumindest in den beiden ProDOS für Aufsteiger Büchern habe ich auf die Schnelle nichts gefunden.

    Danke yalsi das reicht mir eigentlich schon, um ggf. ProDOS auszuschließen. Muss ich mal testen. :)


    1. ProDOS hat eigentlich den Anspruch, bei seinem BASIC Interface weitestgehend kompatibel zu DOS 3.3 zu sein. Wenn Du also bei "gängigen" Problemstellungen das Gefühl hast, zwischen DOS 3.3 und ProDOIS unterscheiden zu müssen, könnte das ein Hinweis auf ein Problem "bei Dir" sein.


    2. PEEK(48.896) ist bei ProDOS gleich 76, bei DOS 3.3 hat es einen anderen Wert. So steht es z.B. in 'Beneath Apple ProDOS' Seite 6-63.

    Das Problem ist, dass DOS und ProDOS unterschiedlich mit Dateinamen umgehen. Diese können z. B. eine unterschiedliche Länge haben etc.. In Abhängigkeit davon wollte ich Dateinamen einer kleinen Prüfung unterziehen. Stellt sich die Frage ob das notwendig oder sinnvoll ist, wenn man den daraus entstehenden Fehler nicht eh anderweitig abfangen kann.

    Hallo liebe Apple II Verrückten,


    seit einiger Zeit bastel ich mir auf meinem Apple IIe enhanced Basic Programme zusammen. Im wesentlichen sind das ein paar Programme rund um Textdateien. Zwei Textviewer, eine Art Textdatei-Dienstprogramm, ein Skript zur Umwandlung von Basicdateien in Textdateien und zur Zeit ein Programm zum schnellen Ausdrucken von Textdateien. Im Grunde sind diese Programme ein wenig aus der Not heraus entstanden, weil ich entsprechende Programme nicht gefunden hatte oder diese einen viel zu großen Funktionsumfang hatten, sie mir nicht gefallen haben, umständlich zu bedienen waren oder was auch immer.


    Meine selbst zusammengefrickelten Programme tun tatsächlich weitestgehend ihren Zweck. Aber ich stoße mit meinem alten Schulbasic aus der Mittelstufe von/vor 30 Jahren an mein Grenzen. Infolgedessen sind die Programme noch nicht so smart wie sie sein könnten. Ich kann z. B. noch keine DOS-/ProDOS-Fehler abfangen. Ein anderes Problem ist, dass ich die Programme gerne unter DOS und auch ProDOS nutzen möchte. Hier also meine erste Frage: Gibt es eine Möglichkeit in Applesoft Basic oder ProDOS Basic die DOS-/ProDOS-Version abzufragen? Anhand des Ergebnisses der Abfrage würde ich dann gerne in die eine oder andere Richtung abbiegen. Ist das möglich oder kann ich mr das aus dem Kopf schlagen?


    :hau:

    Also die Platine scheint etwa Witziges zu sein - eine Platine im microATX Format, auf der man einen kompletten Atari aufbauen kann. Zudem einen mit einem Erweiterungsslot. Die kleine Platine (Bild2) gehört da vermutlich als RAM Upgrad dazu.


    Infos gibt es da https://chillichai.com/atari-st-micro-atx/ inkl. Bild vom Aufbau, und da http://ataripcb.pl/atari_st_atx_v1.1.html , http://ataripcb.pl/atari_st_atx_ram_board_1.html

    Vor allem erst vor kurzem erschienen. Die sollte man sich schon bewußt zugelegt haben. Ich hätte eigentlich auch gerne eine, aber ich gann die ganzen SMD-Bauteile nicht draufbrutzeln auf das Board und ich habe auch die Atari Chips nicht, die dafür benötigt werden.

    Heute war ein ziemlich ausführlicher Artikel in unserer Gärtnerzeitung, in dem es darum ging, dass Schüler in einem Projekt mit einem C64 Computerspiele in Basic programmierten. Online ist leider nur eine Kurzversion des Artikels vorhanden:

    Als die Pixel laufen lernten: Jugendliche programmieren mit C 64 wie im Jahr 1984


    Es wurden jeweils 8 Gruppen mit jeweils 2 Personen gebildet, die ein Spiel programmieren mussten. Die besten Spiele wurden prämiert. Das Fazit der Jugendlichen nach dem Projekt war durchweg positiv, auch wenn sie sich zuerst doch sehr schwer taten mit Basic. :)

    Ich finde das einen sehr interessanten Ansatz, der jüngeren Generation ältere Computer und wie sie funktionierten nahe zu bringen. Könnte sich der VzEkC auch vorstellen solche Projekte zu begleiten, wenn von Seiten einer Schule z. B. Interesse bestünde?