letzter Beitrag von Boulderdash64 am
Dazu musste ich allerdings den Text der Kurzhilfe (Befehl INFO) aus dem Memory auslagern und in eine SEQ Datei verfrachten. Das heißt es werden nun zwei Files zum Betrieb ausgeliefert, BASIC4.5 an sich und ein File INFO.TXT.
Das finde ich etwas schade. Ich habe meistens deine Erweiterung als Modul verwendet (CRT-Datei) und kann so den INFO-Befehl nicht verwenden, weil ich dafür zwingend die BASIC01.HLP-Datei verfügbar haben muss.
Ich fand es irgendwie "runder" als wirklich alles von deiner Erweiterung in einer Datei war.
Aber zum Glück betrifft es nur den INFO-Befehl. Das schmälert nicht den großen Vorteil deiner guten BASIC-Erweiterung. Ich nutze sie nach wie vor noch, wenn ich "mal schnell" was am C64 tippen will. 
Hallo Snoopy, ich muss dir zu gestehen das dies ein kleine Kröte ist die es zu schlucken gilt.
Ich überlege gerade wie man es in Verbindung mit einem Modul platzsparend hinbekommt. 
Aber ich habe keine so rechte Idee. Ich möchte auch ungerne zwei Versionen anbieten. Die Pflege wäre mir einfach zu groß und die Wahrscheinlichkeit von Fehlern ist hoch.
Wenn aber im allgemeinen der Wunsch besteht die Infoseite wieder in RAM zu bringen, bin ich gerne bereit dies zu tun. Dann aber zum Opfer von einigen Hundert Bytes.
Ich bitte all die jenigen, die gerne die Infoseite wieder ins RAM haben wollen diesen Beitrag zum Anlass zu nehmen und sich bei mir melden.
Danke an alle BASIC 4.5 Usern 
Wenn aber im allgemeinen der Wunsch besteht die Infoseite wieder in RAM zu bringen, bin ich gerne bereit dies zu tun. Dann aber zum Opfer von einigen Hundert Bytes.
Ich wäre hier ganz pragmatisch. Dann lagere die Datei einfach ganz aus (ins Handbuch, Readme-Datei o.ä.) und nimm den INFO-Befehl raus. 
Ich fände es einfach "unrund" und "umständlich", wenn man immer eine Datei für den INFO-Befehl "mitschleifen" müsste.
Ich überlege gerade wie man es in Verbindung mit einem Modul platzsparend hinbekommt.
Aber ich habe keine so rechte Idee. Ich möchte auch ungerne zwei Versionen anbieten.
"Mit Modul platzsparend" und "ungern zwei Versionen" widerspricht sich irgendwie... Wenn man sich solche Einschränkungen auferlegt, dann sehe ich auch keine Idee, wie das klappen könnte.
Die zweite Schwierigkeit sehe ich darin, dass wir von BASIC 3.5 derzeit keinen Quelltext haben. Ja ich weiß, nur eine Frage des Aufwandes, das lässt sich disaasemblieren.
Wenn man bereit ist, die selbstauferlegten Einschränkungen fallen zu lassen, sehe ich durchaus am Horizont, dass man vergleichbar viel Speicher frei haben könnte wie im "Business Basic" Modul. Wobei man für den Grafikspeicher was abziehen muss, wenn man den Grafikmodus braucht, das ist klar.
Guten Abend zusammen und vielen Dank für die rege Teilnahme an diesem Thread 
In Bezug auf den Beitrag von markusC64 versuche ich inhaltlich den Bogen zu meinem vorherigen Beitrag zu spannen:
"Mit Modul platzsparend" und "ungern zwei Versionen" widerspricht sich irgendwie... Wenn man sich solche Einschränkungen auferlegt, dann sehe ich auch keine Idee, wie das klappen könnte.
Vieleicht liegt es an meiner harten Woche, vollgespickt mit dem Betrieb von S4/HANA und EWM...(bla bla bla)...,aber ich kann den o.g. Beitrag nicht zu ordnen.
Mein Satz zielte darauf zwei Zielgruppen zu bedienen: Die einen die mehr Speicher wollen, die anderen die eine Hilfe wünschen und das ich bisher keine Idee habe beides in einer Version zu vereinen. Daher werde ich wohl dem Vorschlag von Snoopy folgen und den Befehl "Info" samt ausgelagerter Hilfedatei raus zu nehmen. Zumal ich ein (wie ich denke) ganz gutes Nachschlagewerk zum BASIC 4.5 geschrieben habe.
Zu diesem Thema:
Die zweite Schwierigkeit sehe ich darin, dass wir von BASIC 3.5 derzeit keinen Quelltext haben. Ja ich weiß, nur eine Frage des Aufwandes, das lässt sich disaasemblieren.
Da hat Markus recht. Leider gibt es keinen dokumentierten Quelltext. Zu diesem Thema habe in dem Thread Suche Hilfe bei der Disassemblierung für "BASIC 3.5 für C64" aus 64er, 1990, Ausgabe 6 bereits zur Mithilfe aufgerufen (mit mäßigem Erfolg). Ich habe den Medienverlag "Markt&Technik" angeschrieben ob diese ggf. noch im Besitz der damaligen Sourcen waren. Die Teilten mir mit das alles vor 1995 dem richtigen und virtuellen Mülleimer zum Opfer gefallen ist. Eine Suche nach dem Autor Michael Schimek habe ich begonnen aber nicht mehr weiter verfolgt.
Die Routine, in dem ich mich mit meinem BASIC 4.5 in das vorhandene BASIC 3.5 eingehangen habe war recht mühevoll zu disassemblieren. Mit disassemblieren meine ich nicht die Assembler Befehle, sondern die Funktion zu verstehen und zu dokumentieren.
Wenn man bereit ist, die selbstauferlegten Einschränkungen fallen zu lassen, sehe ich durchaus am Horizont, dass man vergleichbar viel Speicher frei haben könnte wie im "Business Basic" Modul. Wobei man für den Grafikspeicher was abziehen muss, wenn man den Grafikmodus braucht, das ist klar.
Hiermit weiß ich gar nicht was inhaltlich gemeint ist. Was ist den meine "selbstauferlegt Einschränkung"? Bis her war mein Bestreben auf Vorschläge und Wünsche einzugehen und für alle eine gute Lösung anzubieten. Habe ich eine falsche Selbstwahrnehmung?
Die Frage an die Community war doch m. e. recht simpel: Was ist euch lieber? Eine kleinen Hilfetext fest verbaut oder mehr Speicher?
Da finde ich den Lösungsvorschlag von Snoopy sehr konstruktiv.
Wie gesagt, es kann auch an meine harte Woche liegen. Ich bitte um Richtigstellung sollten Teile meines Beitrages völlig daneben liegen.
Herzliche Grüße aus den sonnigen Herzogenrath
Ok war in letzter Zeit nur wenig hier im Forum, daraum habe ich das hier nicht richtig mitbekommen.
Ich persönlich finde immer mehr Platz für Programme wichtiger, als eine Info die man auch auf eine PDF-Datei (Handbuch) schreiben kann, zu mal du eine gutes Handbuch geschrieben hast.
Wenn mir dein Handbuch nicht weiter helfen kann, schlage ich noch im Buch nach "Alles über den Plus 4 - Lernen und Nachschlagen". Darin sind alle Befehle was Basic 3.5 angeht alle gut erklärt. Und die restlichen Befehle was Basic 4.5 aus macht sind im Handbuch von DG5KR auch gut erklärt worden.
Aber das ist meine persönlich Meinung.
Gruß Drachen
Als NNN (NOCH NICHT-Nutzer) würde ich auch sagen: den Platz IM Rechner nur für Befehle und Co. nutzen - Infos in PDF-Form kann man sich auf dem PC ansehen und besser ausgedruckt daneben legen. Irgendwann nervt es eh die Meisten, wenn sie das Programm verlassen und in den Info-Screen wechseln müssen - ich denke, wenn genug Platz da ist (PC) kann man sowas immer auf F1 legen - aber im 64er muss man sich aufs Wesentliche beschränken - daher lieber Befehle und/oder Parameter erweitern, Doku und Infos und Bildchen/Logos usw. raus...
Mit den "selbstauferlegten Eimschränkungen" meine ich, dass dass Du effektiv nur eine Version hast - die Modulversion lädt effektiv die PRG Version ins RAM und schaltet das Modul ab.
Dabei hat man mit einem Easyflash Modul beispielsweise 1 MB (oder 512 KB, wenn man sich auf den Speicherbereich ab $8000 beschräken will) ROM zur Verfügung.
Dummerweise muss man, um die Vorzüge eiens Modules zu nutzen, den bestehenden Code so abändern, dass er per Banking den Bereich ab $8000 mehrfach nutzt.
Wenn der Code jedoch im ROM liegt statt im RAM, ist das RAM unter dem ROM frei und kann - sofern man möchte - auch für BASIC genutzt werden. Nur durch Nutzung des ROMs unter dem RAM und unter dem I/O schafft es Business Basic, 60k freier Basic Speicher zu bieten.
Ja, ist Aufwand. Ohne Zweifel. Jedoch ist es erreichbar.
PS: Easyflash Beispiel deswegen gewählt, weil man das auf jeder Menge Hardware zur Verfügung hat: TC64, Kung Fu Flash, Easyflash, Easyflash 3, Ultimate 64, 1541 Ultimate II(+) und nicht zuletzt im VICE. Und auch deswegen, weil die Software die Kontrolle hat, wann das Modul aktiv ist und wann nicht. Für den Zugriff aufs RAM unter dem ROM braucht man so was ja ggf.
Mein Satz zielte darauf zwei Zielgruppen zu bedienen: Die einen die mehr Speicher wollen, die anderen die eine Hilfe wünschen und das ich bisher keine Idee habe beides in einer Version zu vereinen.
Wie gesagt: In der Modul Version kein Problem - man hat 512 KB bzw. 1 MB ROM, wenn man möchte...
Dabei hat man mit einem Easyflash Modul beispielsweise 1 MB (oder 512 KB, wenn man sich auf den Speicherbereich ab $8000 beschräken will) ROM zur Verfügung.
Dummerweise muss man, um die Vorzüge eiens Modules zu nutzen, den bestehenden Code so abändern, dass er per Banking den Bereich ab $8000 mehrfach nutzt.
also ähnlich wie beim C16/plus4 - die ja in der 64 kB Variante fast 60 kB frei haben fürs Basic...?
Apropos plus/4 - habe das irgendwo mal angesprochen gesehen, aber finde es nicht mehr - gibt es auch für den plus/4 eine Version 4.5? Oder wird es evt. eine zum Nachladen geben?
also ähnlich wie beim C16/plus4 - die ja in der 64 kB Variante fast 60 kB frei haben fürs Basic...?
Halte ich für erreichbar. Wobei bei aktivierten Grafikmodus natürlich der Grafikspeicher davon abzuziehen ist. Sollte klar sein.
Nachtrag: Von der derzeitigen Modulversion bin ich offenbar nicht die Zielgruppe. Weißt, wenn ich das beim Einschalten verfügbar haben möchte, würde ich das wahlweise in den Superkernal laden, der 1541 Ultimate II(+) beibringen, das PRG beim EInschalten autozuladen oder sonstwas machen, was für beliebige PRG Dateien passt... Aber das Basic 4.5 insgesamt halte ich für sehr gelungen. Danke dafür.
Nachtrag 2: Wenn man mit dem Basic-Speiche nur bis $D000 geht, hätte man noch immer mehr Basic Speicher als Basic 2.0 vom C64 - und im Gegenzug eine einfachere Implementierung, weil man dann I/O nicht ausbleden müsste und demzufolge das RAM vom Easyflash im I/O Bereich nutzen könnte für den Code, der auf das RAM unter dem ROM zugreift...
Ich überlege gerade wie man es in Verbindung mit einem Modul platzsparend hinbekommt.
Warum platzsparend?
Wenn man ein Magic Desk Cartrige verwenden würde, hätte man bis zu einem MB Platz.
Das MD ist genial.
- einfach im Banking
- auch 16 KB möglich (einfache Änderung)
- sehr kostengünstig (ein paar Euro)
- einfach nachbaubar
- EPROM oder EEPROM sind günstig und einfach zu haben
- man kann auch Spiele Module adaptieren
- es läuft auch automatisch auf dem EF und Vice
Diddl Das geht ja in die selbe Richtung wie mein Ansatz... welcher Modultyp das am Ende ist, ist ja sekundär, wenn man die gesetzten Ziele damit hinbekommt.
Wobei ich für den INFO-Text über die paar Bytes nicht reden möchte, wenn man am Ende um Größenordnungen mehr Basicspeicher frei bekommen könnte.
Erstmal vielen Dank für den Lob an mein BASIC 4.5 
.
Danke auch für die Vorschläge zum Einsatz eines ROM-Cartridge für BASIC 4.5.
Allerdings ist es nicht so ohne weiteres möglich Speicher durch den Einsatz eines ROM-Cartridge zur gewinnen. Warum?
Das möchte ich kurz den Aufbau das BASIC 4.5 erläutern.
Als Grundpfeiler dient die BASIC 3.5 für den C64 Implementation von Michael Schimek. Dieses BASIC "schiebt sich von $A000 bis $BFFF unter das BASIC 2.0 ins darunter liegende RAM. Einweiterer Teil liegt im RAM von $C000 - $CFFF.
Mein BASIC 4.5 beginnt zur Zeit bei $8700. Das kann je nach fortschreitender Programmierung in Richtung $8000 wachsen (freier RAM nimmt ab).
Da BASIC 3.5 bereits den RAM unter dem ROM ($A000-$BFFF) belegt, bliebe nur noch der Bereich $8000-$9FFF.
Das BASIC 4.5 belegt somit den Bereich von $8700 - $CFFF. Durch die Überschneidung des BASIC ($A000-$BFFF) kann BASIC 4.5 nie in eine "herkömmliche" Cartridge untergebracht werden.
Liege ich da falsch?
Abgesehen davon kann ich das BASIC 3.5 in einem absehbaren Aufwand nicht "Banking fähig" machen, da ich bekannter weise nicht im Besitz eines dokumentierten Sourcecode bin.
Als Grundpfeiler dient die BASIC 3.5 für den C64 Implementation von Michael Schimek. Dieses BASIC "schiebt sich von $A000 bis $BFFF unter das BASIC 2.0 ins darunter liegende RAM. Einweiterer Teil liegt im RAM von $C000 - $CFFF.
Wenn ich mich nicht komplett vertan habe, geht der Bereich sogar bis $D7FF. Die Tage habe ich nämlich den Verschiebeteil entfernt und das eigentliche Programm einzeln in eine Datei gespeichert. Mit einem Loader, der in den Bereich unter $Dxxx laden kann, sollte es weiterhin funktionieren. Eigentlich ist die PRG Datei aber die Grundlage, was man zum Disassemblieren braucht (nicht, dass ich das direkt vor hätte... aber so kann man zumindest den Resourcer und ähnliche nutzen, um Teile zu sehen).
Dass man davon kein ROM Listing hat, macht es natürlich schwieriger. Allerdings braucht man für Code verschieben ($A000-$D7FF nach $8000-$B7FF) nicht unbedingt jede Routine zu verstehen... Den Bereich $B800-$BFFF hat man dann für Bankswitchingroutinen frei - den man in alle Bänke identisch nehmen kann- da blendet man statt Basic 3.5 dann die Basic 4.5 Routinen ein und spriungt die an oder umgekehrt... Ich sehe ein, kein Selbstläifer, aber immerhin einfacher als den ganzen Basic 3.5 Code verstehen zu müssen.
Wenn man Glück hat, findet man dabei alle Zugriffe auf den Basicspeicher und kann die auf Routinen umlenken, die auf das RAM unter den ROMS zugreifen...
Oder man macht gar nichts von den Ideen, sondern lädt das Basic 3.5 ins RAM und patched das ähnlich, wie Du es gemacht hast. Dabei werden aber nur Stubs angesprungen, welches statt dem RAM dort Cartridge ROM aktivieren und in die eigentliche Funktion springen. Mit weiteren Stubs im RAM schaltet man zurück auf Basic 3.5 RAM und springt zurück... Auch das müsste sparsammer sein als den gesamten Basic 4.5 Code ins RAM zu packen.
Hi
Die Diskution mit einer EF-Version oder was ähnliches finde ich äuserst spannend, wenn das klappen könnte, kann man das Basic 4.5 noch ein paar Befehle spendieren.
Aber leider reichen meine Programmierkenntnisse für sowas nicht aus. Habe mich mit sowas nie wirklich beschäftigt.
Deswegen finde ich es ja so spannend. Bin gespannt wie das weider geht.
Das BASIC 4.5 belegt somit den Bereich von $8700 - $CFFF. Durch die Überschneidung des BASIC ($A000-$BFFF) kann BASIC 4.5 nie in eine "herkömmliche" Cartridge untergebracht werden.
Doch das geht schon.
Allerdings muss man halt einiges an der Implementierung ändern.
Aus meiner Sicht gibt es zwei Möglichkeiten:
Jetzt schaltet das BASIC zwischen BASIC-ROM (A000-BFFF) auf RAM (A000-BFFF).
Mit einer Cartridge ist der RAM komplett frei.
Man hätte also 0800 bis CFFF für BASIC.
Theoretisch auch von 0800 bis FF00, mit etwas tricksen ...
Mit der Cartridge hätte man Platz ohne Ende.
Bis zu 1MB ist kein Problem.
Man kann halt immer nur 16KB gleichzeitig "sehen".
Das normale BASIC-ROM sieht man gar nicht mehr.
Diese 8KB müsste man halt in der Cartridge mit aufnehmen, zum Beispiel in der untersten Bank 0.
Da läuft dann auch die Interpreter Loop.
Wenn Befehle ausgeführt werden, die nicht in den ersten 16KB Platz finden, dann schaltet man in die entsprechende Bank.
Das Umschalten ist ein Schreibbefehl und dauert nur ein paar Mikrosekunden.
Nach dem Befehl schaltet man in die Bank 0 zurück.
Der RAM:
Von 0800 bis 8000 ist frei und einfach verfügbar.
Das würde ich verwenden für BASIC Code.
Der Code (ohne Variable) wäre daher beschränkt auf 30KB.
Die Variablen liegen ja nach dem BASIC Code.
Die Strings wachsen von "oben" nach unten.
Alle Befehle die auf Variable LESEND zugreifen müssen ggf. erst in den RAM wechseln.
Schreibend geht auch so, weil das RAM unter dem ROM erreicht man ja auch so, wenn ich mich recht erinnere.
Ausnahme: der IO Bereich
Entweder man läßt den aus oder man macht einfachheitshalber mal nur den Bereich von 0800 bis CFFF Verfügbar (52 KB).
Hi dg5kr
Hier habe ich eine Seite gefunden wo man das "Commodore Sachbuch - C16, C116 und Plus/4 - ROM-Listing" downloaden kann.
http://plus4world.powweb.com/p…116_Und_Plus4_ROM-Listing
Vielleicht liegt das ja schon in der Wolke, habe es aber nicht gefunden. Oder ich war zu blöde um es zu finden.
Ich schreibe es deswegen weil du hier
.
.
.
Abgesehen davon kann ich das BASIC 3.5 in einem absehbaren Aufwand nicht "Banking fähig" machen, da ich bekannter weise nicht im Besitz eines dokumentierten Sourcecode bin.
Naja vielleicht hast du das Buch schon, und wenn nicht, kann es dir vielleicht helfen es doch noch auf eine EF-Karte zu bekommen.
Gruß Drachen
Durch die Überschneidung des BASIC ($A000-$BFFF) kann BASIC 4.5 nie in eine "herkömmliche" Cartridge untergebracht werden.
Doch das geht. TSB belegt z.B. $8000 bis $cfff und trotzdem kann ich dafür sowohl eine UNIPROM- als auch eine Magic-Desk-Cartridge herstellen (siehe meine Signatur, unter Downloads)
Arndt
