TSB Info
- GoDot
- Thread is Unresolved
-
Ich habe mir das zweitneuste CRT angesehen (das neuste kam zu kurzfristig). Meine Meinung: Eine CRT Version gerne, dann sollte die jedoch die Möglichkeiten auch ausschöpfen.
Ein paar Beispiele, wo noch Luft nach oben ist:
* Befehle "nrm", "inst", "graphics" sollten den nachzuladenen Teil aus dem CRT holen
* Eventuell sogar Banking benutzen, damit HSG, "mem" und Wedge nicht Befehle abschalten müssen - mit allen Code zwischen $8000 und $BFFF.
Mit etwas Anpassungsarbeit sollte sich das per Easyflash CRT machen lassen, denn dort haben wir folgende Features:
* Haben dann RAM ab $DF00-$DFFF für Bankswitchcode
* Können ROM ab $A000 ein- und ausschalten (dann ist da wieder das BASIC). denn über $DE02 hast Du Kontrolle über /GAME und /EXROM
* 64 Bänke, wobei ein Bankswitch LOROM and HIROM gleichtzeitig wechselt - mit teilweise identischen Inhalt der Bänke kann man natürlich auch nur ein ROM switchen "simulieren". Über Register $DE00 Bankauswahl.
Edit: Das freiwerdende RAM unter dem ROM $8000-$BFFF kann dann ggf. anders benutzt werden.
-
Hier meine bulidchain für das UNIPROM64 - Modul - funzt nun alles.....
einfach das D64 file in den ./bin/ Ordner kopieren und eines der make-files ausführen.
make_32kb_UNIPROM-CRT.sh macht aus den files tsb.hsg und tsb.obj aus dem D64 ein UNIPROM64-CRT
tsb.hsg und tsb.obj liegen beide nach dem Init im Speicher
Der Quellcode des Modulheaders kann bei Bedarf gern noch erweitert werden mit - wie Markus64 schon erwähnte - Nachladefiles aus dem CRT o.ä.
Fertig gebaute files liegen schonmal mit bei
-
Display MoreHier meine bulidchain für das UNIPROM64 - Modul - funzt nun alles.....
einfach das D64 file in den ./bin/ Ordner kopieren und eines der make-files ausführen.
make_32kb_UNIPROM-CRT.sh macht aus den files tsb.hsg und tsb.obj aus dem D64 ein UNIPROM64-CRT
tsb.hsg und tsb.obj liegen beide nach dem Init im Speicher
Der Quellcode des Modulheaders kann bei Bedarf gern noch erweitert werden mit - wie Markus64 schon erwähnte - Nachladefiles aus dem CRT o.ä.
Fertig gebaute files liegen schonmal mit bei
Danke für die Erwähnung, aber du meintest markusC64
-
Cool!
Eins fehlt noch: Die Vektoren für LOAD und SAVE ($0330..$0333) müssen noch geändert werden, sonst lädt TSB nicht ohne ",8"! Dort muss stehen:
LOAD: $8bfc
SAVE: $8c03
Ansonsten habt ihr mich gerade umgehauen!
Arndt
-
Sehe gerade, dass dafür reicht, in "starter.asm" die richtige (!) Einsprungadresse zu setzen, nämlich "jmp $8170" (statt jmp $8171). Sorry, im File "TSB" von der TSB-Demodisk war das noch falsch (33137 statt 33136!). In der Startdatei im geZIPpten D64 ist das aber richtig! Tut mir leid! Kann man das irgendwie noch nachträglich ins CRT friemeln?
jo, ist passiert und läuft prima
Danke für die Erwähnung, aber du meintest markusC64
ups - kleine Verwechselung - sind aber auch zu ähnlich Eure beiden Nicknames
-
was mir noch aufgefallen ist: die Abkürzungen funzen nicht mehr ....
Also z.B. for LOAD L [shift-o] oder für LIST L[shift-I]
Ist das so auch beim SimonsBasic so ?
Nich dass es schlimm wäre - ist mir nur aufgefallen .....
-
jo, ist passiert und läuft prima
Ah, super, danke, danke!
was mir noch aufgefallen ist: die Abkürzungen funzen nicht mehr ....
Das ist TSB. Da die TSB-Befehle beim Tokenisieren Vorrang haben (sonst gäbe es mit einigen SB-Befehlen Probleme!), muss jetzt bei einigen Standardbefehlen anders gekürzt werden. Im TSB-DEMO ist eine Abteilung, wo man sich die Befehle ausgeben lassen kann.
Aber mir ist noch aufgefallen, dass jetzt der REU-Zugriff nicht mehr funktioniert! (MEM-Befehle) Kann das sein? Die neue CRT liegt auch auf $df00, stimmt's?Falsch, alles in Ordnung!
Arndt
-
Aber mir ist noch aufgefallen, dass jetzt der REU-Zugriff nicht mehr funktioniert! (MEM-Befehle) Kann das sein? Die neue CRT liegt auch auf $df00, stimmt's?
So was passiert, wenn man CRT macht ohne echte Anpassungen. Die Nachteile nimmt man mit, und die Vorteile bekommt man nicht.
BTT: Wobei REU echt schwierig ist bei den bestehenden Modultypen. Von den Typen, wo ich das auswendig weiß, ist nur Retro Replay auf der Liste, die REU kompatibel sind. Und die 8k sowie 16k Module ohne weitere Logic, natürlich.
Mit meinem Easyflash CRT Vorschlag hätten wir das REU Problem leider auch... Da hilft fast nur, ein eigenes Modul zu designen. Was relativ leicht in der 1541 U2+ möglich ist. Andere Hardware zur Unterstützung zu bringen ist dagegen ein Problem und VICE sowieso (in dem Fall aber wegen der Policy der Entwickler). Eigenes Modul designen ist also nicht die perfekte Wahl. Aber man könnte ja Easyflash nur minimal abwandeln, so dass REU parallel geht... Gideon macht gerade sowieso eine Überholung des Modulsystems seiner Hardware.
-
Die neue CRT liegt auch auf $df00, stimmt's?
stimmt.
aber nach dem Kopieren vom CRT wird die Cartridge komplett abgeschaltet und ist somit nicht mehr präsent...
Modulcode_cbm80_32KB-Cartridge.asm - Zeile 278:
-
Da muss ich mir die Hardware mal genauer ansehen. Bedenke aber, dass IO1 und IO2 auch ohne GAME und EXROM aktiv bleiben können. Weil in dem Bereich ein C64 nichts hat - wenn nicht andere Module vorhanden sind - und der Expansionsport ja eh mit dem Modul belegt ist, haben die Modulhardwareentwickler das nicht immer mit abgeschaltet.
-
So, jetzt möchte ich mich mal bei tecman bedanken! Ohne seine Anfrage in Post#9 wäre diese ganze Sache überhaupt nicht in Gang gekommen, dann hätte ich nicht so viel über CRTs gelernt und dann hätte GI-Joe nicht dieses super TSB.CRT gebastelt! Also an alle Beteiligten: Ich bin hochzufrieden mit diesem Vorgang! Danke an alle!
Ich hebe ein Glas auf euch! 
Arndt
-
Update von TSB! (Einschließlich Cartridge)
Wer unter TSB häufiger auch ursprüngliche Simons'-Basic-Programme laufen lässt, die den Befehl EXEC verwenden, sollte besser das Update herunterladen. Ein Bug in EXEC verhindert, dass bei ausdrücklicher Anwendung des Befehls (was in TSB ja nicht mehr nötig ist, in SB aber schon) das Ziellabel gefunden wird. Es werden dadurch also PROC NOT FOUND ERRORs erzeugt. Das Update behebt den Fehler. Downzuloaden auf dieser Seite: GoDot Downloads (godot64.de) (ganz unten - ich will hier nicht den Server mit immer neuen Dateien zumüllen...)
Hat mir ein aufmerksamer User aus den Niederlanden gemeldet. Vielen Dank für diese super Mitarbeit an ihn! Gerne mehr davon!
Arndt
-
Hallo,
ich hab mich mal bisschen mit TSB beschäftig und ein kleines Programm, ausgehend von "tsb-demo-Disk -> Zeichensatz.dmo", geschrieben.
Funktioniert alles soweit, aber wenn ich dann die Zeile 330 einfüge, um die Return-Taste abzufragen, reagiert das Programm auf die Cursortasten seeehr langsam. An was liegt das ?
Ingo
-
aber wenn ich dann die Zeile 330 einfüge, um die Return-Taste abzufragen, reagiert das Programm auf die Cursortasten seeehr langsam. An was liegt das ?
Es dürfte dann überhaupt nicht reagieren (außer mit der Fehlermeldung END PROC WITHOUT EXEC), denn in 330 springst du nach 1680, von wo aus es keinen Rücksprung (schon gar nicht auf dein Zentrum 260) mehr gibt.
Außerdem ist ON KEY ein Einmalbefehl, ähnlich wie ON ERROR. Du versetzt damit das System in einen Überwachungszustand, ab diesem Befehl (ON KEY) reagiert TSB im Interrupt auf deine Tastendrücke, vergleicht sie mit der Liste hinter ON KEY und verzweigt ggf. an das Ziel hinter ON KEY, ansonsten kehrt es scheinbar ohne Reaktion aus dem Interrupt zurück. D.h. ON KEY ist gut geeignet für Hotkeys, nicht so sehr jedoch für eine Tastenabfrage zum Steuern eines Menüs.
Wenn du nämlich die ON-KEY-Tastenliste änderst (was du da in *Dauerschleife* machst: 320 und 330 liegen innerhalb deiner GOTO-Schleife 260-340), ist es natürlich ziemlich zufällig, welche Liste dann, wenn du gerade drückst, aktiviert ist! Entweder die mit <Return> oder die mit den Cursortasten...
Warum kapselst du nicht die einzelnen Aufgaben in je einer Prozedur und fragst dann
IF taste$="{dwn} THEN abwaerts
IF taste$="{up} THEN aufwaerts
usw...? Oder so ähnlich. Und überlässt ON KEY eventuellen Hotkey-Tasten?
Arndt
-
Hier mal ein nützlicher TSB-Tipp!
Die Befehle SCRSV und SCRLD speichern bzw. laden im Normalfall den Textscreen und die dazugehörenden Farben (jeweils 1 KB, die entstehende Datei ist also immer 2048 Bytes plus Startadresse lang). In TSB ist zusätzlich eingebaut, dass man eine Bitmap abspeichern kann und mit einem POKE-Trick, der im C64-Wiki (und auf dem Screenshot hier unten) beschrieben ist, auch deren Farben per SCRSV.
Der genannte POKE (nach $b21c) ändert also die Basisadresse des ersten abzuspeichernden 1K-Bereichs (des Textscreens, eigentlich an $0400). Mit einem weiteren POKE (nach $b218) kann man aber auch den zweiten 1K-Bereich abändern. Normalerweise zeigt der auf das Farb-RAM ($d800). Was hat man davon? Man kann nun beliebige zwei 1K-Bereiche aus dem (freien) RAM speichern und wieder laden (ebenfalls beliebig anderswo hin, nicht einmal zusammenhängend), zum Beispiel Zeichensätze! Und das zeigt der Screenshot. Hier ist Retrofans lesbarer Zeichensatz, eingebunden in TSB:
Cool, oder?
Auch 1KB lange Zeichensätze gehen, man muss nur beide POKEs auf die gleiche Adresse setzen.
Arndt
