Hi,

ich schreibe gerade zu einem 10 Jahre alten Hardware-Projekt die noch fehlende Software fertig. Da diese doch umfangreicher werden wird als gedacht (ich schätze 5 KB Code) und ich keine Lust habe, Zeilennummern einzutippen, will ich zum ersten Mal komplett auf dem PC entwickeln, obwohl die Software nur auf der Original-Hardware lauffähig ist. Testen im Emulator ist also nicht möglich.

1) Ich habe mir den ATASM 1.06 als Assembler ausgeguckt. Bei Durchsicht der Direktiven fiel mir auf, dass die vom SynAssembler (Bibo-Assembler) bekannte Direktive .TA zu fehlen scheint. Die wäre mir aber schon wichtig, da ich sonst in einem Programmteil bei jeder absoluten Adresse einen Offset addieren/subtrahieren müsste.
Beispiel (SynAssembler):
.OR $A000
.TA $4000
Dies assembliert den folgenden Code nach $4000 so, dass er nach Verschiebung auf $A000 lauffähig ist.

2) Da ich nur auf der Original-Hardware testen kann, will ich ein SIO2PC einsetzen. Ich stelle mir das so vor:
Ich mounte mit einer SIO2PC-Software ein ATR auf D1: und lasse von ATASM den Code als COM-File direkt in das ATR reinassemblieren. Nun muss ich der SIO2PC-Software beibringen, dass sie das ATR neu einlesen soll, bevor ich dann am ATARI das assemblierte File starte.
Wisst ihr vielleicht, welche SIO2PC-Software das kann und wie (ohne das ATR neu mounten zu müssen)?

Gruß Dietrich

Hallo Stefan

Dietrich hat geschrieben:ich schreibe gerade zu einem 10 Jahre alten Hardware-Projekt die noch fehlende Software fertig.

Ist es das, wonach ich auf der Nomam 2010 gefragt habe?

Tschüß

Mathy

Hi!

Dietrich hat geschrieben:1) Ich habe mir den ATASM 1.06 als Assembler ausgeguckt.

Vorsicht: die 1.06er Version hat einen blöden Bug, Label Definitionen auf der Kommandozeile funktionieren nicht richtig (zB "atasm -dFOO=1 test.src"). In der 1.07er Vorab-Release ist das korrigiert.

.OR $A000
.TA $4000
Dies assembliert den folgenden Code nach $4000 so, dass er nach Verschiebung auf $A000 lauffähig ist.

Dafür gibt's bei MAC/65 und ATasm die ".SET 6, <offset>" Direktive. Das verschiebt die Adresse des Codes um den angegebenen Offset, der Offset kann auch negativ sein und bei ATasm auch Variablen oder die aktuelle Adresse referenzieren. zB:

Code: Alles auswählen

* = $A000
.SET 6, [$4000 - *]
....

Es gibt auch noch einen komplett anderen Weg (den ich persönlich recht oft verwende): Speicher den $A000 Code in ein eigenes File und assembliere ihn separat in ein RAW File ("atasm -r -omycode.bin mycode.src"). Den Code kannst Du dann per .incbin "mycode.bin" im Haupt-Source File einbinden.

Wenn Du Labels aus dem $A000 Codeblock brauchst, wird's aber etwas tricksig (dann müsstest Du den Source nochmal per ".OPT NOOBJ" einbinden).

2) Da ich nur auf der Original-Hardware testen kann, will ich ein SIO2PC einsetzen. Ich stelle mir das so vor:
Ich mounte mit einer SIO2PC-Software ein ATR auf D1: und lasse von ATASM den Code als COM-File direkt in das ATR reinassemblieren. Nun muss ich der SIO2PC-Software beibringen, dass sie das ATR neu einlesen soll, bevor ich dann am ATARI das assemblierte File starte.
Wisst ihr vielleicht, welche SIO2PC-Software das kann und wie (ohne das ATR neu mounten zu müssen)?

Puh, gute Frage. Ich arbeite fast genauso wie Du und habe aus genau diesem Grund in mein AtariSIO eine "reload" Funktion eingebaut. Ich weiss nicht, ob die anderen (WIN)DOS Programme sowas auch unterstützen, evtl. könnte es mit der "PC Mirror" Funktion in APE klappen (das stellt ein Verzeichnis am PC als Laufwerk zur Verfügung).

BTW: Zum Erzeugen des ATRs verwende ich mein "dir2atr" Programm, damit gehen auch Double Density und grössere ATR Images. Ich habe mir mittlerweile angewöhnt das komplett zu automatisieren und kann damit das ATR inkl DOS komplett "from scratch" am PC erstellen. Hier ein kleiner Ausschnitt aus einem meiner Makefiles:

Code: Alles auswählen

flash.atr: flash.com ftest.com piconame.txt
        rm -rf disk
        mkdir -p disk
        cp -f flash.com ftest.com disk
        atascii piconame.txt > disk/PICONAME.TXT
        dir2atr -b MyPicoDos405 $@ disk

so long,

Hias

Hiassoft hat geschrieben:Vorsicht: die 1.06er Version hat einen blöden Bug, Label Definitionen auf der Kommandozeile funktionieren nicht richtig ... In der 1.07er Vorab-Release ist das korrigiert.

Oha, danke! Habe mir soeben 1.07c geholt, da ich das auch nutzen will. Oder sollte ich doch besser zu 1.05 greifen (1.06 und 1.07 sind ja relativ neu) ?

EDIT: Soeben 1.07c ausprobiert und ich kriege einen Haufen Warnungen "Immediate Overflow". Er meckert folgenden Code an: lda #'.-$20
EDIT2: Und folgende Zeile wird mit einem Error Unknown Symbol quittiert:
chkdat .byte 'R,64
Sieht so aus, als ob 1.07 das Zeichen ' nicht akzeptiert - jedenfalls nicht immer.
Außerdem gibt er immer die Symboltabelle aus - auch wenn ich .opt no list setze.
1.05 schafft es seltsamerweise gar nicht, meinen Code zu assemblieren - er bleibt hängen.
EDIT3: Also, 1.07 scheint ziemlich buggy zu sein - ich kriege Fehlermeldungen, wo ganz klar keine Fehler sind. Ich benutze bis auf weiteres 1.06 - auf das Setzen von Labels in der Kommandozeile kann ich verzichten.

Hiassoft hat geschrieben:Dafür gibt's bei MAC/65 und ATasm die ".SET 6, <offset>" Direktive.

Nanu, mein MAC/65 kennt SET 6 nicht?!?
Sehe ich das richtig: .OR $A000 .TA $4000 beim Synassembler ist dasselbe wie *=$a000 .SET 6,-$6000 ? D.h. der Code ist ab $a000 lauffähig, wird aber vom Assembler nach $4000 geschrieben?

Hiassoft hat geschrieben:Wenn Du Labels aus dem $A000 Codeblock brauchst, wird's aber etwas tricksig

Genau das brauche ich. Daher denke ich, die Sache mit SET 6 ist das richtige für mich.

Hiassoft hat geschrieben:Ich arbeite fast genauso wie Du und habe aus genau diesem Grund in mein AtariSIO eine "reload" Funktion eingebaut.

Leider hab ich nur Windows. Muss ich wohl doch etwas mit SIO2PC & Co experimentieren. Aber vielleicht hat jemand anders einen Tipp?

Hiassoft hat geschrieben:Zum Erzeugen des ATRs verwende ich mein "dir2atr" Programm.

Ich erstelle meine ATRs einfach aus Kopiervorlagen. 1xSD, 1xMD, 1xDD jeweils mit dem gewünschten DOS drauf, das reicht mir

Mathy hat geschrieben:Ist es das, wonach ich auf der Nomam 2010 gefragt habe?

Weiß ich nicht mehr.

Noch eine Frage: In alten Mac/65-Sourcen lasse ich mir häufiger einzelne Adressen oder Ausdrücke ausgeben (um zu kontrollieren, ob irgendwelche Grenzen überschritten werden und wieviel Platz ich noch habe) - und zwar so

Code: Alles auswählen

        .OPT LIST
CHKLEN1 = *        ; muss < $8000 sein
        .OPT NO LIST


Beim ATASM funktioniert das nicht. Die Zeile wird nicht ausgegeben, dafür wird die komplette Symboltabelle angezeigt. Gibt es eine Möglichkeit, einzelne berechnete Ausdrücke anzuzeigen? Mit .WARN kann ich ja nur konstante Texte ausgeben.

Gruß Dietrich (der heute viel Code getippt hat)

Dietrich hat geschrieben:Oha, danke! Habe mir soeben 1.07c geholt, da ich das auch nutzen will. Oder sollte ich doch besser zu 1.05 greifen (1.06 und 1.07 sind ja relativ neu) ?

EDIT: Soeben 1.07c ausprobiert und ich kriege einen Haufen Warnungen "Immediate Overflow". Er meckert folgenden Code an: lda #'.-$20
EDIT2: Und folgende Zeile wird mit einem Error Unknown Symbol quittiert:
chkdat .byte 'R,64
Sieht so aus, als ob 1.07 das Zeichen ' nicht akzeptiert - jedenfalls nicht immer.
Außerdem gibt er immer die Symboltabelle aus - auch wenn ich .opt no list setze.
1.05 schafft es seltsamerweise gar nicht, meinen Code zu assemblieren - er bleibt hängen.
EDIT3: Also, 1.07 scheint ziemlich buggy zu sein - ich kriege Fehlermeldungen, wo ganz klar keine Fehler sind. Ich benutze bis auf weiteres 1.06 - auf das Setzen von Labels in der Kommandozeile kann ich verzichten.

Das mit dem ' dürfte ein Bug in der aktuellen Testversion sein. Ich hab' hier auf meinem Rechner seit Ewigkeiten die 1.05er Version laufen, die klappt soweit (für meinen Code) recht gut.

Vor ca. 2 Monaten hatte ich die 1.06er ausprobiert, bin dann gleich über den Bug mit den Command Line Defines gestolpert und hab Mark einen Bugreport und Fix geschickt (der dann auch gleich im SVN war).

Es gibt übrigens noch einen kleinen, lästigen Bug in ATasm: Man kann an Macros keine lokalen Variablen (zB ?FOO) übergeben. Das hab' ich auch schon an Mark gemailt, weiss aber nicht, ob das mittlerweile behoben ist.

Wenn die 1.06er Version bei Dir ansonsten stabil läuft, kann ich Dir den Fix im Sourcecode für die Command Line Defines schicken (ist nur eine Zeile).

Achja: das mit der Symboltabelle ist seltsam. Evtl. liegt's an den .opt list/nolist statements. In meinem Code verwende ich das garnicht, ein "normaler" ATasm Aufruf gibt auch keine Symboltabelle aus. Wenn ich die Symboltabelle (oder das Code-Listing) brauche verwende ich die Optionen "-s" bzw. "-v".

Nanu, mein MAC/65 kennt SET 6 nicht?!?

Hmmm... Ich dachte, das wäre Standard?

Sehe ich das richtig: .OR $A000 .TA $4000 beim Synassembler ist dasselbe wie *=$a000 .SET 6,-$6000 ? D.h. der Code ist ab $a000 lauffähig, wird aber vom Assembler nach $4000 geschrieben?

Ja, genau. Der Offset bestimmt die Adresse an der der Code abgelegt wird.

Hiassoft hat geschrieben:Wenn Du Labels aus dem $A000 Codeblock brauchst, wird's aber etwas tricksig

Genau das brauche ich. Daher denke ich, die Sache mit SET 6 ist das richtige für mich.

Wenn das klappt, ist es sicher der einfachere weg. Ansonsten: File mit dem ganzen $A000 Code anlegen (inkl. * = $A000 und so), separat assemblieren und im Hauptfile dann folgendes machen:

Code: Alles auswählen

* = $4000
.incbin "mycode.bin"
.opt noobj
.include "mycode.src"
.opt obj

Damit bekommst Du den Code an $4000 und zusätzlich die Labels. Klar, .SET 6 ist etwas eleganter :-)

Hiassoft hat geschrieben:Ich arbeite fast genauso wie Du und habe aus genau diesem Grund in mein AtariSIO eine "reload" Funktion eingebaut.

Leider hab ich nur Windows. Muss ich wohl doch etwas mit SIO2PC & Co experimentieren. Aber vielleicht hat jemand anders einen Tipp?

Eine Idee habe ich noch: Wenn Du die ATR Images auf der Kommandozeile übergeben kannst, ist das wahrscheinlich der schnellste Weg. Das mach ich bei AtariSIO auch gelegentlich.

Code: Alles auswählen

atariserver mydisk.atr

Mit 'q' beende ich dann atariserver, dann in der Shell einmal Cursor-Up drücken (um das Kommando wieder her zu holen) und Return. Geht schneller als die Maus zu schubsen und blöd am Bildschirm rumzuklicken :-)

Zumindest bei dem originalen SIO2PC konnte man Kommandozeilen Parameter übergeben, wie's bei den anderen Programmen aussieht kann ich leider nicht sagen. Die Trial-Versionen von APE fallen wohl flach, dort gibt's ja die nervigen Zwangspausen.

Noch eine Frage: In alten Mac/65-Sourcen lasse ich mir häufiger einzelne Adressen oder Ausdrücke ausgeben (um zu kontrollieren, ob irgendwelche Grenzen überschritten werden und wieviel Platz ich noch habe) - und zwar so

Code: Alles auswählen

        .OPT LIST
CHKLEN1 = *        ; muss < $8000 sein
        .OPT NO LIST


Beim ATASM funktioniert das nicht. Die Zeile wird nicht ausgegeben, dafür wird die komplette Symboltabelle angezeigt. Gibt es eine Möglichkeit, einzelne berechnete Ausdrücke anzuzeigen? Mit .WARN kann ich ja nur konstante Texte ausgeben.

Puh. Da bin ich ehrlich gesagt überfragt. Schick mal Mark einen Bugreport.

Konkret für diesen Check könntest Du es aber in etwa so lösen:

Code: Alles auswählen

.if * >= $8000
.warn "size check failed"
.endif

Gruß Dietrich (der heute viel Code getippt hat)

Fleissiger Dietrich! :-)

so long,

Hias

Dietrich hat geschrieben:...Da ich nur auf der Original-Hardware testen kann, will ich ein SIO2PC einsetzen. Ich stelle mir das so vor:
Ich mounte mit einer SIO2PC-Software ein ATR auf D1: und lasse von ATASM den Code als COM-File direkt in das ATR reinassemblieren. Nun muss ich der SIO2PC-Software beibringen, dass sie das ATR neu einlesen soll, bevor ich dann am ATARI das assemblierte File starte.
Wisst ihr vielleicht, welche SIO2PC-Software das kann und wie (ohne das ATR neu mounten zu müssen)?

AspeQt kann das, wenn man statt eines ATR ein Verzeichnis auf dem PC mounted. Wird etwas im PC-Verzeichnis geändert, bringt der nächste DIR-Befehl den aktuellen Inhalt. Allerdings gibt es dabei eine "ATARI"-Beschränkung auf 64 Fileeinträge, die aus der PC-DIR gelesen werden. Sind mehr drin, kann man die nicht erreichen und muss eine weitere DIR anlegen.

So verschiebe ich Dateien vom PC auf eine Partition am XL.

Mit ATRs habe ich das nur vom ATARI aus hinbekommen. Ändert man ein gemountetes ATR z.B. mit "makeatr", dann erfolgt die Aktualisierung erst nach dem Beenden von "makeatr" und man muss das ATR neu mounten, damit der ATARI den neuen Inhalt sieht.

Im neuen RealDOS wird es eine Funktion geben, mit der man ATRs auf dem PC direkt vom ATARI aus anlegen kann. Ob da so etwas möglich wird, muss man sehen.

Moin,

GoodByteXL hat geschrieben:

Dietrich hat geschrieben:...Da ich nur auf der Original-Hardware testen kann, will ich ein SIO2PC einsetzen. Ich stelle mir das so vor:
Ich mounte mit einer SIO2PC-Software ein ATR auf D1: und lasse von ATASM den Code als COM-File direkt in das ATR reinassemblieren. Nun muss ich der SIO2PC-Software beibringen, dass sie das ATR neu einlesen soll, bevor ich dann am ATARI das assemblierte File starte.
Wisst ihr vielleicht, welche SIO2PC-Software das kann und wie (ohne das ATR neu mounten zu müssen)?

AspeQt kann das, wenn man statt eines ATR ein Verzeichnis auf dem PC mounted. Wird etwas im PC-Verzeichnis geändert, bringt der nächste DIR-Befehl den aktuellen Inhalt. Allerdings gibt es dabei eine "ATARI"-Beschränkung auf 64 Fileeinträge, die aus der PC-DIR gelesen werden. Sind mehr drin, kann man die nicht erreichen und muss eine weitere DIR anlegen.

Jop, so mache ich das auch bei Datenaustausch, allerdings verwende ich APE 3.04 - damit geht´s auch prima, natürlich (technisch bedingt) bleibt auch das 64 Dateien pro Verzeichnis-Limit, aber das ist kein echtes Hindernis.

Gruß, Jürgen

Hi!

HiassofT hat geschrieben:

Dietrich hat geschrieben:EDIT: Soeben 1.07c ausprobiert und ich kriege einen Haufen Warnungen "Immediate Overflow". Er meckert folgenden Code an: lda #'.-$20

Das mit dem ' dürfte ein Bug in der aktuellen Testversion sein.

So, jetzt hab' ich mir das etwas genauer angesehen und einen Bugreport an Mark geschickt.

Code: Alles auswählen

LDA #'A

funktioniert richtig.

Code: Alles auswählen

LDA #'A+1

assembliert zu falschem Code, A9 9B statt A9 42. Und

Code: Alles auswählen

LDA #'A ; Kommentar

Liefert einen Fehler "Error: Unknown symbol ''"

so long,

Hias

Und schon gibt es eine neue Version 1.07d zum Download, bei der alles OK ist. Auch die Symboltabelle wird nun nicht mehr ausgegeben. Trotzdem benutze ich lieber 1.05 (wenn ich die Ursache für den Hänger gefunden habe) - 1.06 und 1.07 scheinen wohl nicht richtig durchgetestet zu sein - sind ja auch relativ neu.

HiassofT hat geschrieben:Konkret für diesen Check könntest Du es aber in etwa so lösen:
.if * >= $8000
.warn "size check failed"
.endif

Ja, so habe ich das auch erstmal gemacht. Allerdings sehe ich da nicht, wieviel Platz ich noch habe. Naja, darauf kann ich auch verzichten.

HiassofT hat geschrieben:Wenn das klappt, ist es sicher der einfachere weg. Ansonsten: File mit dem ganzen $A000 Code anlegen (inkl. * = $A000 und so), separat assemblieren und im Hauptfile dann folgendes machen:
* = $4000
.incbin "mycode.bin"
.opt noobj
.include "mycode.src"
.opt obj

Ja, das ist wohl sicherer, möglicherweise funktioniert SET 6 nicht richtig. Und negative Offsets gehen laut Release-Notes erst ab 1.06.

HiassofT hat geschrieben:Wenn die 1.06er Version bei Dir ansonsten stabil läuft, kann ich Dir den Fix im Sourcecode für die Command Line Defines schicken (ist nur eine Zeile).

Ähh, ich habe hier keinen C-Compiler. Und installieren will ich eigentlich keinen, da die sich normalerweise in Windows tief eingraben. Es sei denn, es gibt einen schnuckelig kleinen Kommandozeilen-C-Compiler, der ohne Installation (d.h. nur Entpacken), ohne Registry-Einträge und ohne aufwendige Konfiguration lauffähig ist ...

GoodByte XL, tfhh hat geschrieben:AspeQt kann das, wenn man statt eines ATR ein Verzeichnis auf dem PC mounted. Wird etwas im PC-Verzeichnis geändert, bringt der nächste DIR-Befehl den aktuellen Inhalt.... Jop, so mache ich das auch bei Datenaustausch, allerdings verwende ich APE 3.04 - damit geht´s auch prima...

Hey, das hört sich gut an. Muss ich mal bei Gelegenheit ausprobieren. Leider will APE auf meinem PC nicht so richtig ... Was ist denn AspeQt, habe ich noch nie gehört?

HiassofT hat geschrieben:Zumindest bei dem originalen SIO2PC konnte man Kommandozeilen Parameter übergeben

Guter Tipp! In der SIO2PC-Doku (immerhin 119KB lang) habe ich zwar nichts darüber gefunden, aber durch Ausprobieren rausgefunden:
sio2pc 1 l1xdos.atr benutzt COM1 und belegt d1 mit XDOS.ATR
Super! Zum Neuladen des ATR brauch ich nur mit Alt-Tab ins SIO2PC-Fenster zu wechseln und dann q, Pfeil hoch und Return zu drücken. Das geht schnell genug, finde ich

Gruß Dietrich (der größere Sachen ab jetzt auf dem PC entwickelt)

Dietrich hat geschrieben:Gruß Dietrich (der größere Sachen ab jetzt auf dem PC entwickelt)

Und sich ein Notebook fürs proggen zulegt, um auch bei den Treffen weiter zu arbeiten

Bernd

Dietrich hat geschrieben:Und schon gibt es eine neue Version 1.07d zum Download, bei der alles OK ist. Auch die Symboltabelle wird nun nicht mehr ausgegeben. Trotzdem benutze ich lieber 1.05 (wenn ich die Ursache für den Hänger gefunden habe) - 1.06 und 1.07 scheinen wohl nicht richtig durchgetestet zu sein - sind ja auch relativ neu.

Ich hab gerade die neueste Version aus dem SVN getestet und gleich einen neuen Bugreport an Mark geschickt :-)

Ein ".if .def FOO .or .def BAR" klappt nicht richtig, da kommt immer "false" dabei raus. In der 1.06er ging das noch.

HiassofT hat geschrieben:Wenn die 1.06er Version bei Dir ansonsten stabil läuft, kann ich Dir den Fix im Sourcecode für die Command Line Defines schicken (ist nur eine Zeile).

Ähh, ich habe hier keinen C-Compiler. Und installieren will ich eigentlich keinen, da die sich normalerweise in Windows tief eingraben. Es sei denn, es gibt einen schnuckelig kleinen Kommandozeilen-C-Compiler, der ohne Installation (d.h. nur Entpacken), ohne Registry-Einträge und ohne aufwendige Konfiguration lauffähig ist ...

Vor einer dreiviertel Ewigkeit (so Mitte der 90er) hatte ich gerne den djgpp Compiler für DOS genommen. Einfach in ein Verzeichnis entpackt, PATH drauf gesetzt (evtl. noch ein oder zwei Environment Variablen) und gut war's.
http://www.delorie.com/djgpp/

mingw dürfte auch OK sein, den C/C++ Compiler verwende ich auch unter Linux um Win32 Code zu erzeugen.

Hey, das hört sich gut an. Muss ich mal bei Gelegenheit ausprobieren. Leider will APE auf meinem PC nicht so richtig ... Was ist denn AspeQt, habe ich noch nie gehört?

AspeQt ist ein recht neues SIO2PC Programm für Windows und Linux (evtl. später auch mal Mac). Hab's selber schon getestet (unter Linux), läuft recht fein!
http://aspeqt.sourceforge.net/

so long,

Hias

Oh je,

wieso sind da soviele Fehler in den neueren ATASM-Versionen? Naja egal, ich benutzte jetzt 1.05 - der scheint ja nach Deiner Erfahrung gut zu funktionieren.

Endlich habe ich auch ein brauchbares Batchfile zusammengebastelt. Es assembliert und mountet dann per SIO2PC das ATR mit dem erzeugten COM-File darin auf D1:, so dass ich sofort am ATARI testen kann. Klappt ganz ausgezeichnet.

Und die Ursache für den Hänger habe ich auch gefunden: Mein Editor kann ATASM 1.05 nicht (per Tastenkombi) richtig starten, er bleibt in einer Endlosschleife hängen. Aus einem DOS-Fenster gestartet geht es aber. Und lustigerweise kommt mein Editor mit 1.06 und 1.07 gut zurecht.

HiassofT hat geschrieben:mingw dürfte auch OK sein, den C/C++ Compiler verwende ich auch unter Linux um Win32 Code zu erzeugen.

Sieht recht kompliziert aus. Es gibt kein ZIP-File, das alles enthält und das man nur entpacken muss, sondern man muss sich einen Installer oder alles einzeln runterladen?!? So ganz schlau bin ich daraus nicht geworden. Gibt es überhaupt ein erstes Release? Das angebotene nur 26KB große File enthält jedenfalls nicht den Compiler.

Bernd hat geschrieben:Und sich ein Notebook fürs proggen zulegt, um auch bei den Treffen weiter zu arbeiten

Tja, das bringt nicht viel, da moderne Notebooks keine RS232-Schnittstelle mehr haben
Und ständig eine SD-Karte umzustecken finde ich blöd.

HiassofT hat geschrieben:AspeQt ist ein recht neues SIO2PC Programm für Windows und Linux (evtl. später auch mal Mac). Hab's selber schon getestet (unter Linux), läuft recht fein!

Beim Starten von AspeQt kriege ich die Fehlermeldung:
Die Datei QTCORE4.DLL ist verknüpft mit dem fehlenden Export-KERNEL32.DLL:SetFilePointerEx.
Stimmt, KERNEL32.DLL gibt es nicht auf meinem Rechner. AspeQt ist wohl nicht auf Win ME lauffähig?!?

Dietrich hat geschrieben:Ähh, ich habe hier keinen C-Compiler. Und installieren will ich eigentlich keinen, da die sich normalerweise in Windows tief eingraben. Es sei denn, es gibt einen schnuckelig kleinen Kommandozeilen-C-Compiler, der ohne Installation (d.h. nur Entpacken), ohne Registry-Einträge und ohne aufwendige Konfiguration lauffähig ist ...

Es gibt hier einen online C und C++ -Compiler, was der taugt, weiß ich allerdings nicht.
http://www.comeaucomputing.com/tryitout/

Moin Stefan,

Dietrich hat geschrieben:

Bernd hat geschrieben:Und sich ein Notebook fürs proggen zulegt, um auch bei den Treffen weiter zu arbeiten

Tja, das bringt nicht viel, da moderne Notebooks keine RS232-Schnittstelle mehr haben
Und ständig eine SD-Karte umzustecken finde ich blöd.

Also entweder Aspect oder das alte Atari810 verwenden. Beide Tools kommen mit einem Seriall-2-USB Wandler fehlerfrei klar, sofern dieser den FT232-Chipsatz verwendet (z.B. Hersteller Digitus, so um die 10 Euro). Die billigen 5 Euro Modelle auf der Bucht haben meist den Profilic-Chipsatz, den kannsu vergessen.

APE funktioniert nur im SIO 1x Modus mit einem USB-2-Seriell Wandler, und selbst da hakelt es verhältnismäßig oft.

Gruß, Jürgen

Dietrich hat geschrieben:wieso sind da soviele Fehler in den neueren ATASM-Versionen? Naja egal, ich benutzte jetzt 1.05 - der scheint ja nach Deiner Erfahrung gut zu funktionieren.

Mark hat einige Erweiterungen eingebaut die wohl unangenehme Nebenwirkungen haben. Normalerweise teste ich die aktuellen ATasm Versionen und schick' Mark dann eine Mail wenn was nicht geht (ich habe hier mittlerweile schon etliches an Code rumliegen). Die 1.06er Version hab' ich aber verschlafen, die Bugreports hole ich nun nach :-)

HiassofT hat geschrieben:mingw dürfte auch OK sein, den C/C++ Compiler verwende ich auch unter Linux um Win32 Code zu erzeugen.

Sieht recht kompliziert aus. Es gibt kein ZIP-File, das alles enthält und das man nur entpacken muss, sondern man muss sich einen Installer oder alles einzeln runterladen?!? So ganz schlau bin ich daraus nicht geworden. Gibt es überhaupt ein erstes Release? Das angebotene nur 26KB große File enthält jedenfalls nicht den Compiler.

Die Download Seite bei Sourceforge ist in der Tat etwas unübersichtlich, Infos zur Installation findest Du hier

Der Installer (MinGW-5.1.6.exe) ist etwas veraltet, klappt aber nach wie vor. Alternative: die Files einzeln runterladen (Du brauchst die Runtime, Win32API, binutils, gcc und ggf make) und mit 7zip entpacken.

Eine weitere Alternative könnte OpenWatcom sein. Mitte/Ende der 90er hab' ich den (damals kommerziellen) Watcom Compiler beruflich verwendet und war recht zufrieden damit.

Beim Starten von AspeQt kriege ich die Fehlermeldung:
Die Datei QTCORE4.DLL ist verknüpft mit dem fehlenden Export-KERNEL32.DLL:SetFilePointerEx.
Stimmt, KERNEL32.DLL gibt es nicht auf meinem Rechner. AspeQt ist wohl nicht auf Win ME lauffähig?!?

Puh, mit Win ME dürfte es schwierig werden. Im Vergleich zur Win NT Schiene fehlen bei Win 9x/ME viele wichtige API Funktionen...

so long,

Hias

Dietrich hat geschrieben:wieso sind da soviele Fehler in den neueren ATASM-Versionen? Naja egal, ich benutzte jetzt 1.05 - der scheint ja nach Deiner Erfahrung gut zu funktionieren.

Gute Neuigkeiten: ich habe nun den Bug mit dem ".if .def FOO .or .def BAR" gefunden und Mark eine Mail geschickt. Er wird den Fix demnächst einbauen und dann eine neue Release machen.

Mit dem Fix läuft ATasm 1.07 jetzt sehr gut: ich habe meinen gesamten Atari 6502 Code damit assemblieren können und identischen Code (verglichen mit 1.05 und 1.06 mit dem commandline-define-patch) erhalten.

so long,

Hias

Hi,

tfhh hat geschrieben:Also entweder Aspect oder das alte Atari810 verwenden. Beide Tools kommen mit einem Seriall-2-USB Wandler fehlerfrei klar, sofern dieser den FT232-Chipsatz verwendet (z.B. Hersteller Digitus, so um die 10 Euro).

Danke für den Tipp. Ich habe mir so einen Adapter zugelegt und dann mal AspeQt auf einem Netbook mit WinXP ausprobiert. Wow, funktioniert fantastisch. Ich kann ohne Probleme mit 3xSpeed vom Atari auf ATRs und PC-Verzeichnisse des Netbooks zugreifen; es gibt keine Fehler und keine umständliche Konfiguration - so muss es sein! Damit kann ich das auf dem Netbook assemblierte XEX sofort auf dem ATARI ohne erneutes Mounten starten. Super, einfacher geht es wirklich nicht mehr!

Nur der ATARI-Emulator will auf meinem Netbook nicht so recht. Obwohl er 370% Geschwindigkeit schafft (im Energissparmodus 280%, mein Desktop schafft nur 270%), läuft er im 100%-Modus nur sehr sehr langsam (8%). Im Full Speed-Modus funktioniert er richtig. Hat jemand vielleicht eine Idee?

Nervig weil hörbar ist auch, dass die Festplatte schon nach ein paar Sekunden Nichtbenutzung den Schreib-Lesekopf parkt (leises Klicken) und etwas später sogar den Motor anhält. Ist das bei Notebook-Platten normal - erhöht das nicht den Verschleiß durch das ständige Wiederanfahren des Motors bzw. Ausfahren des Schreib-/Lesekopfes enorm? Wozu ist das gut - nur um Energie zu sparen?

@HiassofT: Der C-Compiler mingw sieht ganz interessant aus - werde ich später mal ausprobieren - im Moment will ich für den ATARI proggen. Läuft der Compiler eigentlich unter WinME? Wie groß ist der Download etwa (ich bin hier mit einem Modem unterwegs).

HiassofT hat geschrieben:Gute Neuigkeiten: ich habe nun den Bug mit dem ".if .def FOO .or .def BAR" gefunden und Mark eine Mail geschickt. Er wird den Fix demnächst einbauen und dann eine neue Release machen.

Super, da kann ich ja dann 1.07 ohne Gefahr benutzen, wenn es veröffentlicht ist. Danke für die Tests - und Deine Korrektur

Gruß Dietrich

Hi!

Dietrich hat geschrieben:Nur der ATARI-Emulator will auf meinem Netbook nicht so recht. Obwohl er 370% Geschwindigkeit schafft (im Energissparmodus 280%, mein Desktop schafft nur 270%), läuft er im 100%-Modus nur sehr sehr langsam (8%). Im Full Speed-Modus funktioniert er richtig. Hat jemand vielleicht eine Idee?

Welchen Emu verwendest Du, den Atari800WinPlus? Der ist ja mittlerweile reichlich angestaubt, ich würde empfehlen mal einen Blick auf Altirra zu werfen. Ich hab' ihn mir selber mal kurz angesehen und er läuft wirklich sehr fein.

Nervig weil hörbar ist auch, dass die Festplatte schon nach ein paar Sekunden Nichtbenutzung den Schreib-Lesekopf parkt (leises Klicken) und etwas später sogar den Motor anhält. Ist das bei Notebook-Platten normal - erhöht das nicht den Verschleiß durch das ständige Wiederanfahren des Motors bzw. Ausfahren des Schreib-/Lesekopfes enorm? Wozu ist das gut - nur um Energie zu sparen?

Ja, genau, Energiesparen. Aktuelle Notebook Platten sollten einige hunderttausend solcher Zyklen durchhalten, in einem Western Digital Datenblatt habe ich 600000 gelesen. Wenn's Dich stört kannst Du evtl. in den Windows Energie-Einstellungen was verdrehen oder, falls das nicht klappt, beim Hersteller nachsehen ob's dafür ein spezielles Tool gibt.

@HiassofT: Der C-Compiler mingw sieht ganz interessant aus - werde ich später mal ausprobieren - im Moment will ich für den ATARI proggen. Läuft der Compiler eigentlich unter WinME? Wie groß ist der Download etwa (ich bin hier mit einem Modem unterwegs).

Gerade in einer Win98SE VM getestet: Funktioniert :-)

Der Download (inkl. Make und C++ Compiler) war ca. 20MB gross, entpackt dann ca. 70MB.

Code: Alles auswählen

~/install/mingw$ du -h *
11M     binutils-2.20-1-mingw32-bin.tar.gz
2.7M    gcc-core-3.4.5-20060117-3.tar.gz
3.9M    gcc-g++-3.4.5-20060117-3.tar.gz
240K    make-3.81-20090914-mingw32-bin.tar.gz
160K    MinGW-5.1.6.exe
4.0K    mingw.ini
4.0K    mingw.ini.old
552K    mingwrt-3.17-mingw32-dev.tar.gz
8.0K    mingwrt-3.17-mingw32-dll.tar.gz
1.6M    w32api-3.14-mingw32-dev.tar.gz

so long,

Hias

HiassofT hat geschrieben:Der Download (inkl. Make und C++ Compiler) war ca. 20MB gross, entpackt dann ca. 70MB.

Oha, für den Download werde ich damit etwas über eine Stunde brauchen. Das mach ich aber - ich würde schon gerne einen einfachen brauchbaren C-Compiler haben.

HiassofT hat geschrieben:Welchen Emu verwendest Du, den Atari800WinPlus? Der ist ja mittlerweile reichlich angestaubt, ich würde empfehlen mal einen Blick auf Altirra zu werfen. Ich hab' ihn mir selber mal kurz angesehen und er läuft wirklich sehr fein.

Ja genau, den Atari800WinPlus 4.0. Altirra läuft besser als der Atari800Win im 100%-Modus, aber nur mit etwa 20-30000 fps, ab und zu auch 40-50000 fps, egal ob ich die CPU mit 1GHz oder 1.7GHz laufen lasse oder den Warpspeed-Mode einschalte. Die CPU-Last ist konstant bei 55-59%, wie auch bei Atari800WinPlus. Sounds hören sich abgehackt sein (Tonhöhe ist OK, aber in unregelmäßigen recht kurzen Abständen setzt der Sound ganz kurz aus). Da muss irgendwas sein, was die Emulation immer wieder für ganz kurze Zeit anhält - was kann das sein bzw. wie kann man das feststellen?

Hiassoft hat geschrieben:Ja, genau, Energiesparen. Aktuelle Notebook Platten sollten einige hunderttausend solcher Zyklen durchhalten, in einem Western Digital Datenblatt habe ich 600000 gelesen.

Wenn ich davon ausgehe, dass es durchschnittlich alle 20 Sekunden klickt (Parken), macht das 180 pro Stunde, also hält die Platte nur 2000-4000 Stunden! Sehr seltsam.

Hiassoft hat geschrieben:Wenn's Dich stört kannst Du evtl. in den Windows Energie-Einstellungen was verdrehen oder, falls das nicht klappt, beim Hersteller nachsehen ob's dafür ein spezielles Tool gibt.

In den Windows-Einstellungen habe ich nichts gefunden. Zwar kann ich Energiesparschemata einstellen, mit denen u.a. festgelegt wird, wann die Platte ganz abgeschaltet wird, aber nichts davon beeinflusst das Motor an/aus und das Parken. Auch im Gerätemanager und im BIOS war nichts zu finden. Schließlich habe ich mit einem Tool das APM abgeschaltet - und jetzt klickt's nicht mehr, die Festplatte läuft nun immer.
Interessanterweise hält mein Akku auch mit ständig laufender Festplatte 8 Stunden durch (12% pro Stunde). APM scheint also gar nichts zu bringen - jedenfalls nicht unter Windows.

Gruß Dietrich

Dietrich hat geschrieben:Ja genau, den Atari800WinPlus 4.0. Altirra läuft besser als der Atari800Win im 100%-Modus, aber nur mit etwa 20-30000 fps, ab und zu auch 40-50000 fps, egal ob ich die CPU mit 1GHz oder 1.7GHz laufen lasse oder den Warpspeed-Mode einschalte. Die CPU-Last ist konstant bei 55-59%, wie auch bei Atari800WinPlus. Sounds hören sich abgehackt sein (Tonhöhe ist OK, aber in unregelmäßigen recht kurzen Abständen setzt der Sound ganz kurz aus). Da muss irgendwas sein, was die Emulation immer wieder für ganz kurze Zeit anhält - was kann das sein bzw. wie kann man das feststellen?

Du hast geschrieben, daß Du ein Netbook verwendest, ich nehme mal an mit Intel Atom CPU, richtig?

In dem Fall vermute ich, daß die CPU einfach am Anschlag ist. Die Performance der Atom CPUs liegt in etwa in der Grössenordnung eines ~1GHz Pentium-III. Allerdings unterstützen die Atoms Hyper-Threading, das OS sieht also 2 Kerne. Das dürfte auch der Grund sein, wieso die CPU-Auslastung nur bei 50-60% liegt. Im Task-Manager müsstest Du unter "Verlauf der CPU Auslastung" (oder wie immer das genau heisst) 2 Diagramme sehen - eines pro Kern. Da die Emus (soweit ich weiss) nicht multi-threaded implementiert sind, können sie auch max. 1 Kern ausnutzen, der 2. wird dann halt von Windows (Hintergrund-) Programmen genutzt.

Du könntest versuchen die Video- und/oder Sound-Einstellungen in den Emus zu ändern, evtl. wird dadurch die Performance besser. Oder Du versuchst es mit dem Atari800 Emulator. Für Windows gibt's da 2 Versionen, eine mit DirectX Frontend und eine mit SDL Frontend. Ausserdem sind auf der Website auch die älteren Versionen verfügbar (der "WinPlus" basiert glaube ich auf einer 1.3er Version).

Einige Sachen können beim Atari800 nur per Kommandozeilen Optionen konfiguriert werden (eine Liste aller Optionen gibts per "atari800 --help"). Ich hab' mir unter Linux dazu ein kleines Shell-Script namens "a8" geschrieben, das die wichtigsten Optionen enthält:

Code: Alles auswählen

#!/bin/sh
atari800 -windowed -width 672 -height 480 "$@"

Ich hab' da mal kurz getestet:

Auf meinem Rechner (Core2Duo 6750, 2.66GHz) braucht die Linux SDL Version von Atari800 beim Basic "Ready" prompt im Windowed Modus mit doppelter Grösse ca. 10-12% eines CPU Kerns. Dabei entfallen ca. 2/3 auf den Emu und 1/3 auf X (also die Grafikausgabe). Im Turbo-Modus (für SDL erst in den aktuellen Entwicklerversionen vorhanden) ist eine CPU dann komplett ausgelastet. Im Windowed Modus mit doppelter Grösse läuft der Atari dann mit ca. 1300%, im Fullscreen Modus oder im Windowed Modus mit normaler Grösse mit ca. 4300%.

Wie die Performance von Atari800 auf Deinem Netbook aussieht kann ich natürlich nicht sagen. Angefangen von CPU über Grafikkarte bis zum Betriebssystem ist da ja alles anders als auf meinem PC.

so long,

Hias