letzter Beitrag von Ruudi am
Jo. Beide Varianten probiert. Ich hatte auch den Tipp gelesen, dass man 5x ohne Verify brennen soll. Hat aber noch nicht gebracht.
Hab nun die minipro Sources studiert, und weiss nun, warum ich dort den Fehler bekomme. Der vergleicht einfach IC-Grösse mit Filegrösse, was bei eprom-Bin-File geht, aber nicht bei nem jedec File.
Mal schauen. Vielleicht dort mal Bug melden.
Die Linux Version habe ich nicht probiert.
Hab es heute nochmal alles frisch auf einem Win 7 Netbook installiert und tatsächlich 2 GALs programmiert bekommen die sogar ein Verify erfolgreich bestanden haben. Die Minipro Software wollte zunächst nicht, bis ich den 64 Bit Treiber in einem Verzeichnis gefunden hatte und einzeln installiert hab. Dann ging es aber erstaunlich problemlos.
Vielen Dank für die Hilfe!
cp/m im FPGA:
http://www.eevblog.com/forum/p…bout-cpm-board/?topicseen
Interessant daran find ich z.B. die Video-Ausgabe und das SD-Karten Interface.
Bemerkenswert finde ich das Statement, dass im Prinzip alles mit ner seriellen Anbindung als Ausgabemedium geht oder besser: ausreicht. Ich interpretiere das so, dass man serielle Anschlüsse bereitstellt und dort entweder PC, Raspberry Pi oder einen intelligenten Videoterminalschaltkreis anbindet. Hätte den Vorteil, dass man nicht auf die Verfügbarkeit von bestimmten Videochips angewiesen ist. Wäre damit zukunftssicher 
ausreicht
'Ausreichend' ist Note vier. Für EDLIN reicht ein serielles Terminal, Turbo Pascal oder WordStar brauchen etwas schnelleres. Und vorzugsweise etwas, das seinen Bidlspeicher nicht in die TPA quetscht, sondern entweder extern verwaltet inklusive Scrolling (VDC auf dem C128, diverse Systeme mit TI-Grafikchip) oder aber ein gebanktes System (wie der geniale Schatten-Bildschirm für die 40-Zeichen-Darstellung im 128er(*) oder der Grafikschirm beim CPC 6128)
Banking des BIOS funktioniert übrigens auch untrer CP/M 2.2. Man muß sich halt nur selbst um alles kümmern, und das BDOS bekommt man auch nicht aus der TPA-Bank raus. Andererseits bleibt auch in einem gebankten CP/M 3.0 noch erstaunlich viel in der TPA-Bank...
(*) irgendwo weiter vorne wurde diese Lösung als ineffizient kritisiert- das mag sein, und wenn man das 50-Zeichen-System komplett aus dem BIOS rasuwirft hat man tatsächlich einen gewissen Gewinn an Geschwindigkeit. Andererseits sollte das CP/M halt auch mit einer 1541 und einem Fernseher benutzbar sein, und das ist dem externen Entwickler Von Ertwine durchaus ganz gut gelungen)
ausreicht != Ausreichend 
Serielle Anbindung kann schnell genug sein - alles eine Frage der Baudrate, die mit den 8MHz auf der Z80-Karte erreicht werden kann. Der Vorteil des intelligenten Terminals - wenn es einen gängigen Standard, z. B. VT52 unterstützt, dann braucht das BIOS nur noch die (Steuer-)Zeichen durchzureichen und nicht wie bei VIC oder VDC die Steuercodes auswerten und die Bildschirmdaten hin- und herkopieren. VDC kann zwar Bildschirmspeicher intern kopieren, aber man muss danach immer noch schauen, ob er auch fertig ist.
Banking des BIOS ist unter 2.2 nicht ganz so problemlos wie unter 3.0. Soweit ich gelesen habe (falls Beleg gewünscht, kann ich den raussuchen) sollen Anwendungsprogramme unter 3.0 nicht mehr BIOS-Funktionen direkt aufrufen, weil diese in einer anderen Bank liegen. Die BDOS-Funktionen sind stattdessen zu verwenden. Dass die TPA-Bank bei 3.0 noch relativ voll ist mag dem Aufbau von CP/M (und dem Streben nach Kompabilität zur Vorgängerversion) geschuldet sein - BIOS, BDOS und CCP haben ihren festen Startbereich im Speicher, der zumindest bei BIOS und BDOS identisch mit dem von CP/M 2.2 ist.
Zur 40/80-Zeichendarstellung beim 128er: es ist nach dem Start nur der Bildschirm aktiv, in dem das CP/M gestartet wurde, auch wenn während des Bootvorgangs beide Bildschirme aktualisiert werden. Gibt auch ein Tool unter 3.0, dass den VIC abschaltet. Ich weiß aber nicht, ob es die 8502 auch auf 2MHz setzt und wenn ja, was es für Auswirkungen auf den Z80-Teil hat.
von Ertwine... war doch der, der kurz vor der Präsentation mal eben das CP/M direkt auf der Diskette gepatcht hat, weil ihm niemand vorher gesagt hatte, dass der VDC die Befehle doppelt gesagt bekommen muss. Und zwar ohne Assembler, nur Bytewerte inkl. Neuberechnung der Prüfsummen...
Meinst Du jetzt für den c64? Da haben wir die Tage im Chat drüber gesprochen und jemand meinte (ich glaub, es war GottKohl) , dass man sich die Datasetten Routinen anschauen muss. Dort wird ja wegen dem Timing auch der Bildschirm abgeschaltet.
$D011 Bit4 gilt auch im C128 Mode
Ist beim Original-Commodore-C128-CP/M dabei (Version 28 May 87):
Es bringt aber deutlich mehr, wenn Du gleich die cpmfastfinal nutzt, die hat noch ein paar mehr Speedups drin:
http://www.zimmers.net/anonftp…8/system/cpmfastfinal.zip
"A speed-improved and generally-fixed (also Y2K fixed) CP/M distributionfor the C128. Uploaded by the author, Linards Ticmanis."
Das ist schon eingebaut im C128 Modus, der Befehl nennt sich Fast und wird beendet mit Slow. Dabei schaltet der c128 auch auf die doppelte Taktfrequenz.
(war zu langsam)
Für den c64 schien mir das Abschalten Sinn zu machen, wenn Video Out über das CP/M Modul läuft.
Über Autoboot geht das nicht, aber mit normal Booten. Der Befehl dazu lautet Boot.
Also Einschalten,
Fast,
und Boot.
CP/M wird es herzlich egal sein, ob man es aus FAST oder SLOW bootet, das initialisiert sich die IO-Chips schon ganz alleine wie es sie haben will.
Der Trick an 40col=off liegt auch nicht am VIC-Abschalten, sondern am Umgehen der Schattenbildschirm-Logik: Das BIOS schreibt normalerweise alle Bildschirmausgaben sowohl auf den VDC-Schirm als auch in einen Schatten-Puffer in Bank 0. Der geneigte 40-Zeichen-Nutzer kann dann ein 'Sichtfenster' da drüber schwenken, während das Anwendungsprogramm weiterhin die üblichen 80 Zeichen Zeilenlänge verwendet. Und ja, das geht ganz gut, kostet aber Geschwindigkeit. Wenn man das abschaltet, bekommt man deutlich mehr Gewinn als vom bloßen Abschalten des VIC (sprich: keine Baslines mehr)
Und was der Z80 macht, wenn man den VIC in den 2-MHz-Modus schaltet (sprich: nur noch Refresh-Zyklen, alles andere frei verwendbar) wäre auch noch zu prüfen- bisherige Diskussionen in die Richtung deuten in die Richtung 'instabil' bis 'Absturz', weil das ganze Timing durcheinander gerät... es ist immerhin nicht ganz trivial das Z80-Timing in das 6502-Bus-Raster zu quetschen.
