(16.08.2013)

Erste Infos zur 2.8.0 BETA

 

(20.07.2013)

Zweites Update für BETA 2.7.1

Eine weitere EXE für die 2.7.1 BETA.
Diese behebt den Fehler im Debugger bei  asl / rol (s. u.). Auch hier gilt natürlich, dass die EXE nur für die BETA gedacht ist!
Bitte denkt dran, dass es sich noch immer um eine BETA handelt und es noch einige Probleme gibt, z. B. funktioniert der Screeneditor nicht ganz sauber. Ein Update wird in den nächsten Tagen erscheinen.

---

(19.07.2013)

Update für BETA 2.7.1

Die neue EXE (s. u.) scheint zu funktionieren und der Fehler wurde auch behoben.
Wer die 2.7.1 BETA einsetzt (und nur dann!) kann, wenn er möchte, die Datei CBMPrgStudio.exe in seinem Installationsverzeichnis mit dieser neuen Version ersetzen (einfach entpacken und kopieren).
Ein neues Setup folgt mit der offziellen Freigabe.

---

(18.07.2013)

CBM prg Studio 2.7.1 BETA

Habe eben die BETA 2.7.1 von Arthur (mit der Erlaubnis der Weitergabe) erhalten, einige Fehler wurden dort bereits behoben (s. u.). Den Download gibt es zur Zeit nicht auf seiner Seite, ihr müsst also obigen Link verwenden.

Denkt aber bitte dran, dass es sich um eine BETA handelt.

• Neu ist ein Video-Memory-Fenster für den Debugger. Dort könnt ihr eure Textausgaben verfolgen.
• Fehler: In der 2.7.1 BETA funktioniert  sta $0700-24,X überhaupt nicht! Die Zeile wird beim assemblieren komplett übersprungen!
  Ich habe heute (19.07.13) bereits eine korrigierte Version erhalten, möchte diese aber erstmal testen, bevor ich sie als Download bereitstelle.
  

---

(13.07.2013)

CBM prg Studio 2.7.0

Auch im Release 2.7.0 gibt es wieder einige Probleme, die natürlich bereits an Arthur gemeldet wurden. Damit ihr aber nicht unnötig nach bereits bekannten Fehlern sucht, liste ich hier die mir bekannten Fehler und Probleme auf.
Solltet ihr weitere Fehler oder Probleme finden, postet die doch einfach in den Kommentaren oder benutzt das Feedback ganz links, dann nehme ich diese auch noch in die Liste auf.

Wirklich ‚hinterhältige‘ Fehler (solche die unbemerkt ein fehlerhaftes Programm erzeugen) habe ich rot hervorgehoben!

• Breakpoints: Verwendet ihr incasm und setzt in einer Zeile danach, im Source einen Breakpoint für den Debugger, dann erkennt dieser beim Start den gewünschten Breakpoint nicht! Die Adresse ist meistens 0000. Ohne incasm funktioniert es wieder.
   
• Konstanten: Verwendet ihr eine nicht definierte Konstante als Adresse und addiert zu dieser noch etwas, dann erzeugt der Assembler anscheinend fehlerfrei das Programm. Nur stimmt dann die Adresse leider nicht!
  lda UNBEKANNT+1
  Der Assembler erzeugt hier eine falsche Adresse, wie sollte die auch stimmen, die
  Konstante UNBEKANNT  wurde ja nicht definiert.
  Korrigiert: BETA 2.7.1
   
  
• Neue Hi/Lo-Option: Stellt ihr diese Option auf „Calc adress first,…“ dann wird leider nicht mehr korrekt gerechnet bei sta ZP_ADR+1 wird die Konstante ZP_ADR nicht ums 1 erhöht! Das Programm wird allerdings ohne jegliche Meldung erstellt.
  Danke an ThomBraxton
  Korrigiert: BETA 2.7.1
   
• (Sprung)label: Der Assembler erkennt es nicht, falls ein Label doppelt vorhanden ist. Es scheint das letzte Label zu ‚gewinnen‘.
  
  Assembly (x86)

  <del> jsr lab01: rts lab01: inc $D020 rts lab01: BYTE $00</del>

  1 2 3 4 5 6 7 8 9

  <del> jsr lab01: rts   lab01: inc $D020 rts   lab01: BYTE $00</del>

  Hier landet das assemblierte Programm bei der BYTE-Anweisung, statt beim inc-Befehl.
  Korrigiert: BETA 2.7.1
  

• Debugger: Der Debugger wirft eine System-Fehlermeldung, sobald er auf einen Rotations- oder Shiftbefehl mit absoluter Adressierung stößt und durchs Verschieben das Carry-Flag gesetzt wird.
  
  Assembly (x86)

  asl var: var: BYTE $80

  1 2 3 4

  asl var:   var: BYTE $80

  
  Korrigiert: Update-2 für BETA 2.7.1

 

---

 

 

Es ist zwar nicht direkt ein Fehler (den gibt es hier oben), aber doch etwas unschön und kann zu Problemen führen.

Ab 2.7.0 kann man einstellen, wie sich der Assembler bei einem Befehl wie
lda #>SCREENRAM+$0300 verhalten soll.

1. erst den Hi-/Lo-Wert bilden, dann rechnen
2. oder erst die Berechnung durchführen und dann den Hi-/Lo-Wert bilden

Leider weicht der aktuelle Standard, vom bisherigen Verhalten ab. Bis 2.6.0 gab es nur den 2. Punkt, jetzt wird aber erstmal automatisch von 1. ausgegangen und so kann es zu Fehlern beim Übersetzen bisher lauffähiger Programme kommen.

Dank, an ThomBraxton, der darüber gestolpert ist.

Ab 2.8.0 gibt es eine neue Assemblerdirektive: Operator Calc | HiLo, mit der ihr dieses Verhalten direkt über den Source steuern könnt!

 

---

Wer lieber zu einer vorherigen Version zurückkehren möchte, findet die unter CBM prg Studio.