HiassofT hat geschrieben: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.

Wow, gute Erklärung - daran hätte ich nie gedacht. Stimmt, ich sehe 2 CPU-Diagramme - ist mir noch gar nicht aufgefallen. Verflixte neue Technik aber auch. Ich habe hier einen EeePC 1001P mit Intel Atom N450-CPU (1,67 GHz).

Ich hab nun allerlei ausprobiert. Ganz zuletzt habe ich das Netzkabel angesteckt - und damit gibt's gar keine Probleme mehr. Altirra erreicht im Warpspeed-Modus nun sogar 200000 fps. Und auch Atari800Win läuft nun ganz normal.

Ohne Netzkabel krieg ich Altirra nun auch zum Laufen, aber nur, wenn ich kurz in den Standby gehe, wieder heraus, eine kleine EeePC-Anwendung stoppe, Altirra starte und dann die EeePC-Anwendung wieder starte. Im Taskmanager werden beide (!) Kerne mit 50% Last angezeigt. Mit Warpspeed kommt Altirra dann aber nur auf 65000 fps. Sieht ganz so aus, als läuft die CPU im Akkubetrieb mit stark verminderter Leistung. Grmpf, warum steht sowas nicht im Handbuch ...

Gruß Dietrich

Entschuldigung das ich mal so kurz dazwischen funke:
... habe das Problem mit dem abgehackten Ton bei ALTIRA aber auch bei meinem Notebook einem Toshiba mit IntelPentium4 mit 2,66MHz.
Möchte übrigens wider mehr unter KyanPascal progen... bekomme es aber nicht sauber installiert - Hilfe.

Kann ich aber auch auf dem Treffen am 22. nachfragen - also kein Stress .....

Gruss Udo

Dietrich hat geschrieben:Ohne Netzkabel krieg ich Altirra nun auch zum Laufen, aber nur, wenn ich kurz in den Standby gehe, wieder heraus, eine kleine EeePC-Anwendung stoppe, Altirra starte und dann die EeePC-Anwendung wieder starte. Im Taskmanager werden beide (!) Kerne mit 50% Last angezeigt. Mit Warpspeed kommt Altirra dann aber nur auf 65000 fps. Sieht ganz so aus, als läuft die CPU im Akkubetrieb mit stark verminderter Leistung. Grmpf, warum steht sowas nicht im Handbuch ...

Das mit den beiden Kernen bei 50% dürfte OK sein. Der Scheduler wird wohl beide virtuelle Kerne gleich auslasten wollen. Bei Hyper-Threading ist das kein Problem, der Prozess bleibt ja auf der gleichen CPU, der Cache bleibt auch identisch (bei "richtigem" SMP ist's etwas anders, da sollte der Scheduler schauen, daß die Prozesse möglichst auf der gleichen CPU bleiben, ansonsten geht der Cache verloren, was Performance kostet - noch kritischer ist's bei NUMA Systemen wo die CPUs lokalen RAM haben, da werden dann RAM Zugriffe richtig "teuer" wenn man einen Prozess auf eine andere CPU verschiebt).

Aber zurück zum Thema, der Performance-Optimierung:

Schau' mal nach, ob Du irgendwie beeinflussen kannst ob die CPU runtergetaktet wird. Das kann aber auch ziemlich hart verdrahtet sein, zB so, daß die maximale Performance nur bei Netzbetrieb erlaubt wird. Bei einigen Laptops steckt das direkt in der Hardware und man kann nix selber dran drehen, oft ist's aber auch eine reine Software Sache, dann sieht's besser aus. Wie's bei Deinem Netbook genau ist, weiss ich aber leider auch nicht.

so long,

Hias

Moin,

HiassofT hat geschrieben:

Dietrich hat geschrieben:Sieht ganz so aus, als läuft die CPU im Akkubetrieb mit stark verminderter Leistung. Grmpf, warum steht sowas nicht im Handbuch ...

Aber zurück zum Thema, der Performance-Optimierung:

Nun, die Hersteller wollen dem Käufer natürlich nichts "Negatives" um die Ohren hauen - und die immensen Akkulaufzeiten mit dem bißchen Batterie geht natürlich nur zu Lasten der Power.

Also ich besitze kein EeePC, hatte aber mal einen zum Spielen da (und dann entschlossen, daß mir sowas nicht ins Haus kommt). Ich hatte auch den Atari800Win 4.0 drauf getestet, und die Grafik hakelte sehr, bei 100% Einstellung sackte die Leistung sehr häufig ab - teilweise bei einfachsten Basic-Sachen.

Folgende Haken habe ich gesetzt, dann wurde es etwas erträglicher:


Offenbar bringen diese Einstellungen bei leistungsschwachen CPUs etwas. Probier´s einfach mal aus.

Gruß, Jürgen

Hallo Dietrich,

ich habe ein Asus Netbook 1000H, also etwas älter als dein Gerät mit Windows XP.
Unten rechts in der Task-Leiste (da wo die Uhr zu sehen ist) gibt es bei mir ein Symbol mit einem "H" das wohl für "Super Hybrid Engine" steht.
Wenn ich dort mit der rechten Maustaste klicke, kann ich zwischen "Performance Modes" auswählen.
Standardmäßig ist die Einstellung "Auto Mode", im Akku-Betrieb heißt das relativ schlechte Leistung. Mein Emulator läuft mit dieser Einstellung auch nicht korrekt.
Wähle ich aber "High oder Super Performance" aus läuft auch der Emulator mit 100%, natürlich auf Kosten der Akku-Laufzeit.

Gruß

Tigerduck

Hi,

die SuperHybridEngine habe ich natürlich auf "High Performance" geschaltet. Auch "GDI für Windows" im Atari800Win ist aktiv.

Wie auch immer, bei angestecktem Netzkabel geht es ja. Warum im Akku-Betrieb der Atari800Win im 100%-Modus nicht geht und Altirra nur nach Neustart des Eee-Docking-Utilities habe ich nicht herausgefunden. Ist auch nicht soooo wichtig - letztendlich habe ich das Teil ja nur, um auf Treffen ATARI programmieren zu können.
Danke jedenfalls für Eure Hilfe

ATARI-Proggen am PC macht echt Spaß. Keine nervigen Zeilennummern mehr, beliebig viele Source-Files sind möglich, Kommentieren nach Belieben ohne auf den Speicher achten zu müsen, Assemblieren geht mit Strg-A in 0 Sekunden, Emulator-Start zum Testen mit Strg-E (oder das erzeugte XEX bzw. ATR per SIO2PC am ATARI starten).

Ich benutze nun ATASM 1.06 (1.05 funktioniert mit meinem Editor nicht). Das klappt recht gut, der generierte Code ist in Ordnung. Man muss nur aufpassen, keine Vorwärtsreferenzen auf Equates machen. Das assembliert er zwar ohne zu meckern, aber der generierte Code ist falsch. Und man sollte bei Assemblierung in ein ATR hinter das erzeugte XEX kein weiteres ATARI-File packen - das löscht ATASM nämlich bei der nächsten Assemblierung.

@UdoWy: Mach mal wegen KyanPascal einen neuen Thread auf, das passt nicht hier hin.

Gruß Dietrich

Hi!

Dietrich hat geschrieben:Wie auch immer, bei angestecktem Netzkabel geht es ja. Warum im Akku-Betrieb der Atari800Win im 100%-Modus nicht geht und Altirra nur nach Neustart des Eee-Docking-Utilities habe ich nicht herausgefunden. Ist auch nicht soooo wichtig - letztendlich habe ich das Teil ja nur, um auf Treffen ATARI programmieren zu können.
Danke jedenfalls für Eure Hilfe :-)

Es freut mich, daß es nun klappt! Die Sache mit dem Akkubetrieb sollte sich auch noch irgendwie lösen lassen, vielleicht findest Du im Netz dazu ja Hinweise. Ich bin da mit meinem Wissen jedenfalls am Ende :-)

Ich benutze nun ATASM 1.06 (1.05 funktioniert mit meinem Editor nicht). Das klappt recht gut, der generierte Code ist in Ordnung. Man muss nur aufpassen, keine Vorwärtsreferenzen auf Equates machen. Das assembliert er zwar ohne zu meckern, aber der generierte Code ist falsch.

Oh, das mit den Equates klingt nicht gut. Hast Du da Beispielcode dazu? Mir ist in der Richtung bisher noch nichts aufgefallen.

Ich hab' nun mal ein win32 exe mit meinem korrigierten Code gebaut (siehe Anhang), könntest Du die mal testen? Wenn die Version auch Probleme mit Equates macht sollten wir uns das genauer ansehen und Mark Bescheid geben, damit er das in der offiziellen 1.07er Version noch fixen kann.

so long,

Hias

Diese Version hat 2 Bugs von 1.06 immer noch - ein Bug (Labelname bei der Fehlermeldung Symbol '=5=0' already defined falsch) kommt nicht mehr. Hier ein Beispiel:

Code: Alles auswählen

   .opt list
         * = $4000
run      lda #$80
         sta 710
   lda keytab,x           <--- Vorwärtsreferenz
         rts
   .byte "asd              <--- Anführungszeichen fehlen

blub   lda #3

keytab = var+32             <--- noch eine Vorwärtsreferenz

var .ds 4


Das wird assembliert zu:

Code: Alles auswählen

ATasm 1.07 (A mostly Mac65 compatible 6502 cross-assembler)
Pass 1: Success. (0 warnings)
Pass 2:
00:40  A9 80    run      lda #$80
02:40  8D C6 02          sta 710
05:40  BD FF FF         lda keytab,x      <--- 2 Vorwärtsreferenzen sind wohl zu viel für ihn
08:40  60                rts
09:40  61 73    .byte "asd                 <---- Oh Oh, ein Byte fehlt
0B:40  A9 03    blub   lda #3

Assembly successful
  Compiled 13 bytes (~0k)
    Block: 4000-400c (13 bytes)


Hallo Stefan,
ich habe hier einen Eclipse Plugin für die 6502 Cross-Assembler (ATASM, MADS und XASM) gefunden:

http://www.wudsn.com/

Hi,
einen großen Dank an tfhh (Jürgen). Ich habe mir auch ein Digitus USB2COM Konverter mit dem FT232 Chipsatz zugelegt. In Verbindung mit Aspect lässt es sich doch viel leichter Proggen. Jetzt geht´s viel schneller.

Bernd

Hi Bernd,
Es liegt nicht am Digitus-Adapter, sondern am AspeQt.
Mit dieser Software funken alle "USB2Serial" Adapter (auch mit Prolific Chipsatz).
Gruß
Marcin

Moin,

Montezuma hat geschrieben:Hi Bernd,
Es liegt nicht am Digitus-Adapter, sondern am AspeQt.
Mit dieser Software funken alle "USB2Serial" Adapter (auch mit Prolific Chipsatz).

Das würd ich so pauschal nicht sagen. Vom Profilic-Chipsatz gibt es (wie auch vom FT232) diverse Variationen. Nicht alle funktionieren, die meisten laufen garnicht, wenige laufen mit AspeQt - aber auch nicht so galant wie mit FT232 und dessen Varianten.

Ich habe mir für ein Projekt 6 verschiedene Profilic, 2 FT232 (davon 1x Digitus und 1x Chip selbst auf eine Experiementier-Platine samt MAX232 drauf) und ein weiteren Wandler, dessen Chipsatz ich nicht identifizieren konnte, bei eBay gekauft und mit allen SIO2PC-Programmen getestet. Die FT232-basierenden Wandler sind die einzigen, die generell mit ALLEN Lösungen klarkommen. Von meinen Profilic-Adaptern lief nur ein Einziger mit AspeQt, und das auch deutlich langsamer und mit gelegentlichen Sektorfehlern (d.h. Datenfehler, Sektor mußte nochmal übertragen werden) im Highspeed-Modus.

Alle Lösungen kommen nicht an die APE Vollversion mit einem nativen COM-Port heran, was Speed und Stabilität angeht, aber AspeQt oder Atari810 mit einem FT232 Chipsatz ist ein gutes Gespann.

Achja: Profilic-Adapter machen teilweise unheimliche Probleme an einem USB2-Port, der nicht von einem Intel-Chipsatz gesteuert wird. Ich habe einen Core2Duo mit g45 Chipsatz getestet und ein älteres AMD-System mit nvidia-Chipsatz, darauf lief kein einziger Profilic stabil - nicht mal im 9600 bps TTY Betrieb ohne Handshake... am Intel-System liefen sie aber zumindest hiermit einigermaßen.

Von daher: Nicht am falschen Ende sparen und gleich zum FT232 greifen, die paar Euro Mehrkosten machen den potentiellen Streß (Nicht-Funktion, Treiberstreß uvm.) mehr als wett.

Gruß, Jürgen

Tagchen,
den USB2COM Adapter hatte Dietrich beim letzten HAR Treffen im Einsatz. Auf der Webseite und auf der Verpackung steht
USB - Seriell Adapter, USB 2.0 mit FTDI / FT232RL Chipsatz.. Diesen Hinweis habe ich bislang noch bei keinem anderen
Hersteller auf der Verpackung gesehen. AspeQt in Verbindung mit Hias´s gepachten SIO-OS ist gut abgestimmt. Getestet
habe ich die Übertragung bis 52400 Baud.

@Marcin: Ich greife lieber auf einen getesten Adapter zurück. Mein anderer Adapter (Noname) läuft überhaupt nicht damit.

Viele Grüße,
Bernd

PS: Bei Amazon gibt es den Adapter für 9,45€ inklusive Versandkosten.

Hallo
danke für die Erklärung. So ausführlich habe ich es natührlich nicht getestet
Auf meinem Netbook (Asus Eee PC 1101HA) laufen beide (Noname mit Prolific und Digitus mit FTDI) problemlos.
Das aber nur mit AspeQt (und nicht mit APE).
Schöne Grüße
Marcin

P.S.
Hat jemand von Euch das Eclipse-Plugin getestet?
Der Autor (Peter Dell) hat schon vor einem Jahr in diesem Forum darüber berichtet:
viewtopic.php?f=10&t=4647&start=0&hilit=WUDSN
Es gibt mittlerweile eine neue Version (http://www.wudsn.com/).
Das Plugin funktioniert echt klasse.
Ich habe es mit ATASM 1.06 und Atari800Win getestet.
Auf der Webseite vom Autor gibt es auch den Quellcode von seiner Demo-Applikation:
http://www.wudsn.com/productions/homecon5/homecon5.zip
Man kann es ganz einfach (eine Tastenkombination) assemblieren und ausführen.

Moin,

Montezuma hat geschrieben:Hallo
danke für die Erklärung. So ausführlich habe ich es natührlich nicht getestet

Das war auch nicht unfreiwillig (nicht, daß ich da keine Lust hätte, aber meistens keine Zeit). Es gibt etwas, das noch zickiger als das SIO-Timing ist: Analyse-Ports von älteren Alcatel-DSLAMs. Da mittlerweile unsere Servicetechniker nur noch 2 funktionsfähige Notebooks mit echter COM-Schnittstelle haben, mußte ich eine USB-Lösung finden. Und "nebenbei" testete ich halt SIO2PC-Software

Gruß, Jürgen

Da bin ich ja zur richtigen Zeit über diese Thema gestolpert, es wird mich vor vielen Problemen bewahren.

Nach dem ich längere Zeit nichts mehr für die kleine Atari's gemacht habe, wollte ich nun wieder loslegen, Turbo Basic XL 1.5 und Assembler, evtl. auch Action! und C.
Ich hatte mir auch schon den ATasm ausgeguckt und bin erfreut zu sehen, das der wohl noch aktiv weiter entwickelt wird.
Für mich kommt nur noch die Entwicklung auf dem PC in Frage, es ist viel bequemer und man hat bei der Programmerstellung nicht so viele Beschränkungen - ich kann mich da noch an ATMAS II erinnern, der nicht schlecht war, aber wo der Platz doch arg beschränkt war.
Wenn ich das richtig in Erinnerung habe, dann wurde bei Atari auf einer PDP entwickelt, ich meine da mal einen Bericht gelesen zu habe, wo auf einem Foto eine PDP zu sehen war.

Viele von Euch setzen ja das SIO2PC per RS232 ein. Ich wollte mich demnächst evtl. die USB-Variante anschaffen, da ich eh keinen alten PC mit RS323 mehr im Betrieb habe und meistens am Laptop oder sehr oft am Nettop (Samsung N140/WinXP/2 GB-Ram) sitze, wo ich, wenn ich im Haus bin, einen zusätzlichen 17" Bildschirm angeschlossen habe. Ich habe auch alle Nicht-USB-Geräte inzwischen verbannt.
Läuft die USB-Variante von SIO2PC mit AspeQt? Dann habe ich noch von dem XL-OS mit SIO-Patch gelesen (von Hias ist es wohl).
Was ist dort geändert bzw. welchen Effekt hat es und wie kann man es bekommen?

Zu den Emulatoren:
Ich nutze fast immer den ATARI800winPlus4.0 in der eingedeutschten Version, der aber wohl leider nicht mehr aktiv weiterentwickelt wird.
Atari800 in der SDL-Variante habe ich mir auch schon mal angesehen, das ist die mit XEP80-Support oder?
Sehr erfreut war ich, als ich gelesen habe, das sich hier auch noch Andere mit den Emulatoren beschäftigen und teilweise auch in die aktuellen Entwicklung Einblicke haben. Des weiteren hat mich gefreut, das zumindest der Atari800-Emulator nicht weiterentwickelt wird. Ich interessiere mich hier besonders für die SDL-Variante, da ich Interesse hätte an dieser Linie mitzuarbeiten - ich habe allerdings noch keine Sourcen der SDL-Variante finden können, und in Sourceforge verlaufe ich mich regelmäßig, mit SVM usw. habe ich noch gar keine Erfahrungen. In SDL habe ich in einem Testprojekt unter Visual Basic 2008 (per SDL-DotNet) schon Einblicke gewinnen können.
Altirra habe ich durch die Suche nach Information über VBXE gefunden und gleich auch mal ausprobiert. Es sind viele schönen Dinge dort enthalten, die ich z.B. von WinCPC (einen Schneider CPC-Emulator) kenne, dort ist allerdings auch gleich ein Z80/8080-Assembler integriert, was sehr angenehm ist.
Das Altirra eine VBXE-Emulation enthält ist natürlich grandios. Allerdings muss ich sagen, das Altirra in meine Augen noch einiges an Arbeit benötigt, besonders was die Performance angeht. Ein "Problem" it sicherlich, das Altirra in großen Teilen auf Code aus dem VirtualDub-Projekt basiert und nicht speziell für den Emulator optimiert wurde.
Es wäre schön, wenn Atari800-Emulator auch noch eine VBXE-Emulation bekommen würde.
Und mein grösster Wunsch eine Möglichkeit vom Emulator aus eine TCP/IP-Verbindung aufbauen zu können, in Atari800winPlus gibt es j leider nur einen Telnet-Server im R:-Patch. Hintegrund ist, das ich Möglichkeit suche mit der mehere Atati800-Emulatoren miteinander kommunizieren können, ohne diese umständlich über Dateien (H:) zu realisieren zu müssen.

EDIT:
Ich habe auch grad mal eine CPU-Last Vergleich gestartet:
Mein Testrechner ist mein Nettop Samsung N140 (Intel Atom N270 @1.66GHz, 2 GB-Ram, Mobile Intel 945 Express Grafik, WindowsXP Home SP3)

Atari800winPlus 4.0:
-Vollbild: ~9%
-Fenster (Groß und Klein): ~20%

Atari800dx 2.1.0:
- Vollbild: ~6%
- Fenster (672*480*32): ~45%

Atari800sdl 2.1.0:
- Vollbild (336*240*32): ~10%
- Fenster (672*480*32): ~27%

Altirra:
- Fenster (672*480*32) ohne VBXE: ~23%
- Fenster (672*480*32) mit VBXE: ~43%

ATARI++ 1.56 / VBXE 1.09 Build 205
- Fenster: ~40%

ATARI++ 1.58 ohne VBXE
- Fenster: 12%

Hi,

EightBitWitch hat geschrieben:Viele von Euch setzen ja das SIO2PC per RS232 ein.

Ich benutze für meinen WinXP-Rechner ein ganz normales SIO2PC-Kabel (SIO-Stecker auf der einen, RS232-Stecker auf der anderen Seite). Die RS232-Seite schließe ich mit einem USB-Adapter der Fa. Digitus (10 Euro) an den PC an. Zusammen mit AspeQt klappt das ganz ausgezeichnet - und ohne Probleme in 3xSIO-Speed. Keine umständliche Konfiguration oder Aussetzer wie etwa bei APE!

EightBitWitch hat geschrieben:Für mich kommt nur noch die Entwicklung auf dem PC in Frage, es ist viel bequemer und man hat bei der Programmerstellung nicht so viele Beschränkungen

Kann ich nur bestätigen. Ich habe jetzt für mein Projekt in 5 Wochen 8 KB recht komplizierten 6502-Code geschrieben (4500 Codezeilen) - das hätte ich auf dem ATARI nie so schnell geschafft. Größte Vorteile sind:
- Bildschirmorientierter Editor, einfaches Umkopieren von Codeteilen möglich
- Keine nervigen Zeilennummern
- Aufteilung in mehrere Dateien problemlos möglich
- Umfangreiche Kommentierung möglich
- Schnelles Assemblieren und Testen per Tastenkombi
Nett wäre noch eine Möglichkeit, direkt im Sourcecode Breakpoints zu setzen (oder gar durch den Code zu steppen). Aber das wird wohl Wunschdenken bleiben. Hilfsweise mache ich ein jmp * im Code, assembliere neu und drücke dann im Emulator F8. Das Testen auf dem ATARI ist nicht ganz so einfach - dafür habe ich ein Logging in den Code mit eingebaut, das ich per Define-Schalter einschalten kann. Zusammen mit dem Monitor im QMEG-OS sehe ich dann auch, was passiert ist.

Der ATASM 1.06 funktioniert gut, nur das Fehlerhandling hat ein paar Schwächen. Er bemerkt nicht jeden (Syntax-)Fehler im Source und produziert dann u.U. falschen Code:
1) Doppelte Vorwärtsreferenzen assembliert er ohne Meckern zu $ffff, da bin ich 2mal drauf reingefallen. Hier hilft es, bei unerklärlichen Fehlern das Assembler-Listing mal auf "FF FF" zu durchsuchen...
2) Doppelte globale Labeldefinitionen bemerkt er nur, wenn es keine Equates sind. Auch deswegen sollte man pro Sourcedatei einmal .local verwenden und globale Labels nur benutzen, wenn sie aus anderen Sourcedateien angesprochen werden.
3) Fehlende schließende Anführungszeichen meckert er nicht an. Dafür fehlt dann das letzte Byte - das bemerkt man recht schnell.
4) .set 6 funktioniert auch nicht so richtig: Das Konstrukt, das ich üblicherweise verwende, produziert Assemblierfehler. Ich habe daher meine betreffenden Codeteile (etwa 1 KB) von Hand reloziert, was allerdings viel Disziplin erfordert. Hat man sich aber erstmal daran gewöhnt, geht es ganz gut. Vorteil: Ich kann den Code sowohl an seiner Original-Adresse als auch an der Target-Adresse ansprechen, was ich teilweise auch brauche, z.B:

Code: Alles auswählen

...
loadorg = $800        ; der folgende Codeteil soll ab $800 lauffähig sein
ldiff   = loadorg-*   ; der Relozier-Offset
loadrun
...                   ; hier zu jeder absoluten Adresse ldiff addieren
loadend


EightBitWitch hat geschrieben:Allerdings muss ich sagen, das Altirra in meine Augen noch einiges an Arbeit benötigt, besonders was die Performance angeht.

Die Performance finde ich OK. Aber der Atari800Win hat einfach viele nette Features, auf die ich nicht verzichten will (schneller Mount von D1-D8, Screenshot, Dateikonvertierung, Monitor im Extra-Fenster, mehrere H:-Laufwerke). Die Fenster bei Altirra verhalten sich teilweise seltsam. Und die Doku ist noch unvollständig. Die Einfg- und Entf-Taste sind unglücklich belegt. Nett ist dagegen, dass man die Fenstergröße beliebig einstellen kann. Und er braucht keine Windows-Installation - schreibt allerdings unnötigerweise in die Registry (warum nicht einfach in eine ini-Datei). D.h. man muss seine Einstellungen wiederholen (oder aus der Registry exportieren), wenn man Altirra auf einen anderen Rechner kopiert - das gilt allerdings auch für Atari800Win. Die Debugging-Funktionen sehen interessant aus - sind aber leider gar nicht dokumentiert. Und er läuft nicht auf meinem alten WinME-Rechner.

Nett wäre noch eine Möglichkeit, direkt im Sourcecode Breakpoints zu setzen (oder gar durch den Code zu steppen). Aber das wird wohl Wunschdenken bleiben.

Debugging mit Anzeige des Sourcecode soll wohl mit Altirra möglich sein,

Ausschnitt aus der Feature-List Ver. 1.3
* Debugger: *.lst and *.lab symbols are automatically detected and loaded for direct-run EXEs and cartridges.
* Debugger: Improved source-level debugging capability.

allerdings nur mit speziellen Output (Source- und Label-Dateien) eines Assembler den ich nicht kenne.
Ich denke es lohnt sich Altirra im Augen zu behalten, obwohl ich mir wünschen würde, das solche Features (wie auch VBXE) auch ins Atari800-Projekt einzug finden.
Einen kleinen Bug-Report (den zweiten, es gab auch eine Antwort) bzgl. des Fensterverhaltens und der unglücklichen Belegung von INS und DEL habe ich an Avery Lee, den Author, per Mail gesendet. Viele Funktionen sind im laufe der letzten Versionen dem Verhalten/Vorbild von Atari800winPlus angeglichen worden, den wohl sehr viele Leute benutzen oder genutzt haben. Daher ist es sehr schade, das dieser nicht mehr weiter entwickelt wird.
Wobei der Atari800-Emulator der einzige mir bekannte Emulator ist, der mit dem 128KB SDX-Modul als ROM-Datei klar kommt, die 64KB-Version können auch andere Emulatoren laden.

Das die aktuelleren Programme kaum noch INI-Dateien benutzen (die ich auch bevorzuge, auch beim Programmieren) liegt auch daran, das diese oft von den Compilern (besonders die von M$) nicht mehr direkt unterstützt werden und man sich WinAPI-Funktionen bedienen muss - für C-Programmierer wäre das allerdings kein Problem. So ist es zumindest in Visual Basic 2008 für das .net-Framework, dort gibt es keine Funktionen für INI-Dateien. INI-Dateien scheinen den Touch des verstaubten zu haben und gelten wohl als unmodern.
Das aktuelle Software nicht mehr auf Win95-ME läuft ist kaum verwunderlich, da viele aktuelle Funktionen dort einfach nicht verfügbar sind, da M$ dafür keine Updates mehr bereit stellt. Ich selbst nutze nur WinXP (manchmal auch Ubuntu) und bin mal gespannt wie lange es für WinXP noch eine gute Unterstützung von M$ gibt, einige Funktionen sind ja auch jetzt schon nur auf Vista oder Win7 verfügbar.