Hallo, für die Weiterentwicklung meines OS steht ein größerer Schnitt an, zudem ich ein eigen entwickeltes Monitorsystem habe. Dieses kann aktuell auch Userprogramme von einer SD Karte einlesen und starten. Die 16KB EPROM sollen ja auch genutzt werden und nicht einfach beim Start des Userprogs weggeschaltet werden wie derzeit. Der C64 schwirrt mir etwas im Kopf herum. Seine 64Kb waren in RAM und ROM aufgeteilt, manches lag übereinander und konnte umgeschaltet werden. Viele Funktionen konnte man direkt nutzen wenn deren Adresse bekannt war. Aktuell tendiere ich dazu das so zu Machen: Z80 startet auf aus dem ROM und initialisiert die Hardware wie zb RX/TX Mechanismus, die Interrupts dafür und Ringpuffer. Auch die LED Matrix wird verknüpft mit ihren Zeilen/Spalten Zaehlern und einem RAM Bereich. Der Data Bereich des Monitors liegt in einer geschützten Area ganz oben. Der User Data Bereich liegt direkt hinter dem Programm. Die INT Mode 2 Tabelle kopiert der Monitor ins RAM bei $2000, so dass sie beim Monitorleerlauf benutzt wird und auch vom Userprogramm (ab $2100) modifizierbar ist. Das Userprogramm beschreibt dann zb den RAM Bereich der LED Matrix und kümmert sich nicht darum wie das dargestellt wird. Nicht benutzte Ints werden auf leere Routinen geleitet im ROM. Werden die vom Userprogramm benötigt muss per Hand umgelenkt werden. Routinen wie putchar und getchar, printf werden aus dem Userprogramm her im ROM aufgerufen, das Userprogramm muss sie nicht mitbringen. Spart locker 4kb Platz. Veränderungen an den INTS werden vom Userprogramm in der RAM Tabelle vorgenommen, zb die Umlenkung auf eigene Routine, bevor dann in die eigentliche Routine zurückgesprungen wird. Stellt sich auch die Frage ob Userprogramme überhaupt Rechte haben zb Ints umzubiegen? Das BIOS stellt ja eigentlich alles als API zur Verfügung, bei DOS rief man INT21 auf, im BIOS war es INT13 und konnte damit alles erreichen. Der Z80 hätte die RST Soft Interrrupts frei für sowas. Viele Wege scheinen nach ROM zu führen.... Gruss, Christian
Christian J. schrieb: > Viele Wege scheinen nach ROM zu führen Man könnte natürlich einfach ein vorhandenes Betriebssystem übernehmen. Oder, wenn das zu einfach ist, nur die Funktionsaufrufe (BDOS Calls) übernehmen. Für den Monitor bietet sich die Standard Sprungleiste eines CP/M-BIOS an. Man kann aber auch alles selbst neu erfinden.
Georg G. schrieb: > Man kann aber auch alles selbst neu erfinden. Der Weg ist schon begangen worden... zurück gehts nicht mehr. Beim nächsten Male würde ich was Fertiges nehmen, Standard Interfaces usw. Ich schreibe aber jetzt alles selbst oder kloppe das Ding in die Tonne.
Christian J. schrieb: > Viele Wege scheinen nach ROM zu führen.... Das ist ein weit verbreiteter Irrtum, viele Wege führen weg von ROM :-) Aber der Ansatz ist doch ok, und BIOS Funktionen zu nutzen ist doch der richtige Weg, zumal der Z80 die ja mit voller Geschwindigkeit nutzt. Meine Z80 Monitore hatten noch einen MiniAssembler und Disassembler an Bord, einen Receiver für Intel-Hex Files, Peek und Poke für einzelne Speicherstellen und I/Os und so Sachen wie Ansprechroutinen für lustige Peripherie (wie damals z.B. die Grafik beim Mupid). YMMD, ich hatte ab und zu nur undokumentierte Hardware, bei der ich mühselig die Adresse der SIO rausgefunden hatte und dann mittels Monitor den Rest erkundet habe.
:
Bearbeitet durch User
Matthias Sch. schrieb: > Aber der Ansatz ist doch ok, und BIOS Funktionen zu nutzen ist doch der > richtige Weg, zumal der Z80 die ja mit voller Geschwindigkeit nutzt. Yep. Ergo muss ich dann nur das EPROM mit nützlichen Dingen bestücken, wie qsort, bubblesort, xatoi, hex2bin, open_sd_card und anderen Routinchen die man oft braucht und dann in einem eprom.h File Zeiger drauf legen, die dem Compiler auch sagen wie er den Stackframe zu bauen hat. extern char (* putchar) (char) = 0x1234; Aufruf mit res = putchar(c); Die Methode das mit INT Aufrufen zu lösen gäbe es allerdings auch noch. register beladen, Funktion einladen und dann einen festen INT aufrufen. Dieser Weg wurde bei MSDOS und den AT Computern damals beschritten. Heute braucht man ja kein BIOS mehr bzw nur noch zum booten.
Christian J. schrieb: > und dann in einem eprom.h File Zeiger > drauf legen Das ist nicht sehr änderungsfreundlich, weil das H-File ja erst beim Neukomplieren wirksam wird. Für Standardfunktionen (APIs) gehen daher die meisten Betriebssysteme/BIOSe den Weg einer Sprungtabelle, so dass das Anwendungsprogramm den Einsprung immer an der gleichen Stelle findet. Siehe CP/M und MSDOS. Bei denen sieht man auch, dass alles gleich bleibt und neue Funktionen hinten dran geklatscht werden, wenn nötig. Ein weitsichtiger Programmierer hat sowas natürlich nicht nötig :-) Georg
Christian die Frage ist doch was Du Dir vorstellst mit dem Ding zu machen. CP/M wolltest Du ursprünglich nicht. Im Endeffekt ist es aber nur eine Plattform für Anwendungen über recht universell gehaltener Hardware (Speicher = 64K RAM). Ich versehe ja das man nicht auf einem Z80 System unter CP/M arbeiten will, aber was willst Du jetzt machen? Danach richtet sich doch was Du an Software zweckmäßigerweise auf die ROMs spielst. Da Du nicht das X. CP/M System bauen möchtest, informiere Dich doch mal über RIO.. das wäre mal was extravagantes... Gruß, Holm
Holm Tiffe schrieb: > Christian die Frage ist doch was Du Dir vorstellst mit dem Ding zu > machen. CP/M wolltest Du ursprünglich nicht Ja Holm.... dreh das Messer ruhig im wunden Punkt nochmal herum :-( Das ist wie mit ner Modelleisenbahn....nur interessant solange sie im Bau ist, ist sie fertig ist der Spass weg. Letztendlich kommt das ganze System jetzt in eine Holz-Plexiglas Kiste und wird mit genügend LEDS ausgestattet eine Art Kugelbahn steuern, die mit Elektromagneten die nötige Hilfsenergie kriegt, damit sie endlos läuft. Trotzdem soll es "gescheit" werden, also das Userprogramm was ich öfter anfassen muss auf eine Art Kernel zurückgreifen. Damit bei der Erweiterung des Monitors nicht jedesmal alle Adressen neu abgeschrieben werden müssen, weil die sich ändern werde ich mir die Sache mit der Sprungtabelle mal überlegen, die Georg hier angeführt hat.
Christian J. schrieb: > Holm Tiffe schrieb: >> Christian die Frage ist doch was Du Dir vorstellst mit dem Ding zu >> machen. CP/M wolltest Du ursprünglich nicht > > Ja Holm.... dreh das Messer ruhig im wunden Punkt nochmal herum :-( Sorry, das war nicht meine Absicht. Ich wollte viel mehr wissen in welche Richtung Du mit dem Teil hin willst. >Das > ist wie mit ner Modelleisenbahn....nur interessant solange sie im Bau > ist, ist sie fertig ist der Spass weg. > > Letztendlich kommt das ganze System jetzt in eine Holz-Plexiglas Kiste > und wird mit genügend LEDS ausgestattet eine Art Kugelbahn steuern, die > mit Elektromagneten die nötige Hilfsenergie kriegt, damit sie endlos > läuft. Nette Idee.. Ich vermute nur das Dir das nach einer Weile gehörig auf den Wecker gehen wird :-)) >Trotzdem soll es "gescheit" werden, also das Userprogramm was ich > öfter anfassen muss auf eine Art Kernel zurückgreifen. Damit bei der > Erweiterung des Monitors nicht jedesmal alle Adressen neu abgeschrieben > werden müssen, weil die sich ändern werde ich mir die Sache mit der > Sprungtabelle mal überlegen, die Georg hier angeführt hat. Das ist eine vernünftige Idee, du kannst Dich ja diesmal an der Sprungverteilerei des CP/M Bios orientieren, es gibt ja nicht nur Filesystem-Funktionen. Gruß, Holm
Hi Leg doch einfach den ROM ans Ende des Speicherbereichs, wie es der Z1013 gemacht hat. Da wird einfach der Datenbus bis zum Start des MonitorRoms auf $FF gelegt. Damit wird der komplette RAM ab 0X000 frei für Anwenderprogramme. MfG Spess
Wohl eher nicht $ff, das wäre RST38, damit kommt der Prozessor nie im ROM an, $00 (NOP) ist wahrscheinlicher. Das ist eine der möglichen Urlader-Varianten. Gruß, Holm
Christian J. schrieb: > Aktuell tendiere ich dazu das so zu Machen: Viel zu komplex. D.h. irgendwann passt das nicht mehr. Da es wohl nicht um Banking für mehr als 64k geht, hat sich damals eine Methode bewährt: Der Z80 startet nach RESET ja von 0 und erwartet Stack bei FFFF. Also muss bei 0 ROM sein und bei FFFF RAM. Später gibt es viele Systeme (wie CP/M), die bei 0 auch RAM sehen wollen. Also mappt man die 64k RAM auf den ganzen Speicher und blendet nach RESET vorne ab 0 das ROM ein nur für Lesezugriffe (Schreibzugriffe gehen nach wie vor ans RAM). dann kopiert das Programm im ROM alle benötigten Daten an die passenden Stellen ins RAM und wenn es das getan hat, schaltet es sich bis zum nächsten RESET ab, die nächste Instruktion kommt aus dem RAM. Ich hatte dafür eine I/O-Instruktion benutzt, die das FF löscht, welches die Einblendung des ROM übernahm. Da in Betreib alles im RAM ist, gibt es keine Einschränkungen, sogar selbstmodifizierender Code ist möglich.
MaWin schrieb: > Der Z80 startet nach RESET ja von 0 und erwartet Stack bei FFFF. Leider falsch. Dr PC wird auf 0000 gesetzt, aber der Stackpointer nicht auf FFFF - den muss man am Anfang des Programms selbst setzen, und zwar auf jeden beliebigen Wert den man möchte, wobei es sich von selbst versteht, dass dort RAM sein sollte. das kann aber eben auch jede andere Adresse sein. Da du von falschen Voraussetzungen ausgehst, ist auch der Rest deiner Ausführungen unbrauchbar. Ein System mit ROM von 0000 ... 1FFF und RAM von 2000 ... 2FFF funktioniert völlig problemlos, jedenfalls für einfache Aufgaben. Ist halt doch schon lange her. Georg
Ab Reset muss zunächst nur ROM oder anderweitiger nichtflüchtiger Speicher zwingend existieren. Der Initialisierungscode kann zunächst völlig ohne ansprechbares RAM arbeiten. Und wenn diese Initialisierung durch ist, dann ist andererseits irgendwelches ROM im Adressraum verzichtbar. Man kann auch so arbeiten, dass anfangs jeder Lesezugriff im ROM und jeder Schreibzugriff im RAM landet, egal welche Adresse angesprochen wird und egal wie gross das ROM ist. MaWins Flipflop schaltet die Lesezugriffe von ROM auf RAM um. Eine Dekodierung von Speicheradressen ist dann völlig unnötig (mal vorausgesetzt, dass man mit einem einzelnen RAM-Chip auskommt).
:
Bearbeitet durch User
Georg schrieb: > in System mit ROM von 0000 ... 1FFF und RAM von 2000 ... 2FFF > funktioniert völlig problemlos, jedenfalls für einfache Aufgaben. Natürlich kann man den SP neu laden, aber initialisiert ist er auf FFFF. Ein System wie du es beschreibst ist aber völlig inflexibel, kann kein CP/M, kein anderes existierendes System ausführen.
Ähm... darf ich mal kurz unterbrechen? Danke :-) An diesem System ist nix mehr bankbar oder umschaltbar, es ist Fix und Foxi auf 0x0000-3ffff = ROM und 0x4000-FFFF = NVRAM bestückt. Und CPM interessiert mich ungefähr so, wie DOS 1.0, nämlich gar nicht. Bze derzeit nicht. Vielleicht später mal wegen Pascal Programmierung usw. Das Thema Banking >64k wird leider nicht vom SDCC unterstützt, man müsste alles per Hand umschalten. Darüber hat sich Alan Cox allerdings schon beschwert als er sein Fuzzix schrieb. Sollte ich je wieder einen Z80 Rechner bauen, dann kriegt der all den Luxus verpasst und vermutlich auch das FuzixOS wenn es denn dann soweit fertig sein sollte. Es tut sich ja was wie ich sehe bei GitHub.
MaWin schrieb: > Natürlich kann man den SP neu laden, aber initialisiert ist er auf FFFF. Du bist ja längst sattsam dafür bekannt, dass du sofort ausrastest, wenn jemand es wagt dir zu widersprechen, aber durch Wiederholen werden deine Behauptungen nicht wahrer und das Argument "ich habe recht, weil ich MaWin bin" zieht höchstens bei deinen Jüngern. Anbei eine Kopie aus dem Zilog-Z80-Handbuch von 1985, mehr ist dazu nicht zu sagen und auf deine folgenden Beschimpfungen werde ich nicht antworten. Ein Streit über dokumentierte Eigenschaften ist einfach lächerlich und mit meiner Gotteslästerung muss ich halt leben. Georg
MaWin schrieb: > Natürlich kann man den SP neu laden, aber initialisiert ist er auf FFFF. Das ist ein undokumentiertes (Mis)feature. Hab's jetzt hier gefunden: http://www.z80.info/zip/z80-documented.pdf Zitat (CHAPTER 2. OVERVIEW):
1 | RESET Reset (input, active low). Initializes the CPU as follows: it resets the interrupt flip-flops, |
2 | clears the PC and IR registes, and set the interrupt mode to 0. During reset time, the |
3 | address bus and data bus go to a high-impedance state, and all control output signals go to |
4 | the inactive state. Note that RESET must be active for a minimum of three full clock cycles |
5 | before the reset operation is complete. Note that Matt found that SP and AF are set to |
6 | FFFFh. |
Der Z180 setzt den SP hingegen dokumentiert auf 0. Das ist auch nur geringfügig sinnvoller.
Georg schrieb: > Du bist ja längst sattsam dafür bekannt, dass du sofort ausrastest, wenn > jemand es wagt dir zu widersprechen, aber durch Wiederholen werden deine > Behauptungen nicht wahrer und das Argument "ich habe recht, weil ich > MaWin bin" zieht höchstens bei deinen Jüngern. Auch hier blamierst du dich mal wieder zu Tode, denn wie üblich; Ich habe dummerweise doch recht. Siehe Leo's Beitrag oder http://www.z80.info/interrup.htm Wenn man - wie du - natürlich nur das dokumentierte Verhalten kennt, weil man sich nicht ausreichend intensiv mit dem Thema beschäftigt hat, glaubt man, man wüsste alles besser.
Natürlich hat Georg recht. Dieses "Feature" ist undokumentiert, unsinnig und nutzlos. Niemand wird sich darauf verlassen, daß der SP nach Reset auf 0ffffh steht. Außerdem bliebe das letzte Byte ungenutzt, wenn man den SP dort stehen läßt. (Vorausgetzt, daß man überhaupt RAM am Ende des Adressraums hat.) Da undokumentiert könnte es sich auch um einen Seiteneffekt handeln, oder von einem anderen Hersteller anders implementiert werden. Wahrscheinlich initialisiert der HD64180 wie der Z180 den SP auch auf 0. Dokumentiert ist es dort nicht. Könnte ich aber ausprobieren.
MaWin schrieb: > Wenn man - wie du - natürlich nur das dokumentierte Verhalten kennt Das ist das einzige, wonach sich ein seriöser Programmierer richtet. Auch wenn der unfehlbare Gottvater des Forums was anderes meint. Georg
Worüber streitet ihr eigentlich? MaWin schrieb: wird auf 0xFFFF initialisiert. stimmt Georg schrieb: keine SP Initialisierung dokumentiert. stimmt Leo schrieb: ist sowieso Blödsinn. stimmt Und trotzdem geht es ab wie bei den Kesselflickern. ;-)
:
Bearbeitet durch User
MaWin schrieb: > Georg schrieb: >> Du bist ja längst sattsam dafür bekannt, dass du sofort ausrastest, wenn >> jemand es wagt dir zu widersprechen, aber durch Wiederholen werden deine >> Behauptungen nicht wahrer und das Argument "ich habe recht, weil ich >> MaWin bin" zieht höchstens bei deinen Jüngern. > > Auch hier blamierst du dich mal wieder zu Tode, > denn wie üblich; Ich habe dummerweise doch recht. > Siehe Leo's Beitrag oder > http://www.z80.info/interrup.htm > Wenn man - wie du - natürlich nur das dokumentierte Verhalten kennt, > weil man sich nicht ausreichend intensiv mit dem Thema beschäftigt hat, > glaubt man, man wüsste alles besser. Mawin läßt wieder den Manfred raushängen oder häh? Du hast NICHT Recht, es handelt sich weder umeine offiziell dokumentierte noch um eine verläßlich vorhandene Funktion. Jemand der Software unter Berücksichtigung solcher "Features" schreibt ist ein Stümper. Gruß, Holm
> Dir geht es auch nicht um Wahrheit
Um Wahrheit gehts schon lange nicht mehr.
Meine Z80 Kenntnisse sind schon arg angerostet.
Aber das ist hier, glaube ich, auch irrelevant.
Wenn Datenblätter und Testergebnisse widersprüchlich sind, dann
initialisiert man eben den SP so, wie man es für richtig hält. Muss man,
je nach Speicherkonfiguration, sowieso.
Damit ist das fachliche soweit geklärt, dass jeder Interessierte das
umsetzen kann.
Zum Streit:
Davon gibts in diesem Forum viel zu viel.
(Zu mir selber: Kannste ja gehen, wenns dir nicht passt!)
Kennt ihr den Unterschied zwischen Ping Pong und Tischtennis?
Die erste Fraktion schreit sofort: "Idiot, das ist doch das gleiche!"
Die Zweite hört ein entspanntes Ping Pong Ping Pong Ping Pong ...
Die Dritte hört Knall, Peng, Klatsch ...
Da scheiden sich die Geister.
Sieg und Niederlage... allzu oft eskaliert es so weit, dass selbst der
Sieger mit einem Knick im Genick vom Platz geht.
Ein Forum ist keine Arena.
Und sollte dieses eine sein, dann bin ich hier falsch.
Ich will dass der Ball auf dem Tisch bleibt.
Christian J. schrieb: > Ähm... darf ich mal kurz unterbrechen? Danke :-) > > An diesem System ist nix mehr bankbar oder umschaltbar, es ist Fix und > Foxi auf 0x0000-3ffff = ROM und 0x4000-FFFF = NVRAM bestückt. Und CPM > interessiert mich ungefähr so, wie DOS 1.0, nämlich gar nicht. Bze > derzeit nicht. Vielleicht später mal wegen Pascal Programmierung usw. Hmm.. nun, genau damit haust du dir aber selbst auf den Fuß. Das Hauptproblem bei den mir noch erinnerlichen Z80-Systemen war immer wieder, daß man einfach zu wenig adressierbaren Speicher hatte. Zum Lösen dieses Problemes kann und muß man Speicherbänke umschalten und das ist eine Hardware-Angelegenheit, bei der man sehr genau die verwendbare Software einplanen muß. Anders geht es nicht - und du solltest dies schlichtweg einsehen. Bei deiner Speicheraufteilung hingegen kannst du nur eines sinnvoll tun: einen ZX-Spectrum daraus bauen. Die dafür benötigte Bildschirm-Ansteuerung läßt sich heutzutage relativ einfach per CPLD erledigen. Lediglich für die Tastatur-Ansteuerung mußt du dir entweder Gedanken machen oder die originale Beschaltung nehmen. Alles Andere dürfte wenig befriedigend für dich werden. Mein Rat wäre, ganz einfach die Hardware auf CP/M auszulegen. W.S.
Holm Tiffe schrieb im Beitrag #4080885: > Seit Jahrzehnten beginnen die Erpoms in Z80 Sytemen mit einer 0x31 und > das nicht aus dem Grund das die Leute den Proheten MaWin ignorieren. Stimmt nicht.... mit 0xC3. Was laberst Du also das wieder? :-) 0000 C3 00 01 [10] 63 jp init Wie gesagt es ist alles gebaut, es kann nix mehr geändert werden, nur das nächste Mal. Der N8VEM hat umschaltbare Bänke aber leider hatte der Autor der Doku mehr Ahnung von Technik als vom Dokumentieren. Scheinbar sind die ersten 32KB da aus ROM und RAM und die letzten 32kb werden über die Erweiterung des Busses auf A15,16,17 eingeblendet, wobei jetzt nicht direkt klar ist welche Leitungen zum Umschalten benutzt werden. "Automatisch" kann da nix gehen, bei 0xffff geht es mit dem Pc weiter bei 0x0000. Vermutlich I/O Leitungen, die per Glue Logic auf A15,16,17 für das 512kb RAM erweitert werden. Der Z80 kann ja nix mit 0x10AFFE anfangen. Verwendet man einen C Compiler (wie jeder normale Mensch), dann hat man nix davon, ein int array[100.000] geht trotzdem nicht und auch kein "gekauftes" CP/M Programm was > 32kb ist, denn irgendwo muss ja der Umschalter reingebracht werden und vor allem muss der Code adressunabhängig sein, Sprünge dürfen nicht über die Grenzen usw. Mir fiele nur eine Verwaltung über einen Taskmanager ein, der ständig im OS läuft und der eine Task knallhart per Hardware Interrupt beendet und den PC auf die nächste setzt, einschliesslich Kontextsicherung. Oder wie haben die das gemacht?
Christian J. schrieb: > Der N8VEM hat umschaltbare Bänke aber leider hatte der Autor der Doku > mehr Ahnung von Technik als vom Dokumentieren. Nicht zu fassen. Seitenweise Doku auf der Homepage[1], insbesondere die Schaltpläne. > Scheinbar sind die ersten 32KB da aus ROM und RAM und die letzten 32kb ... Wenn man Schaltpläne halbwegs lesen kann, braucht man nicht zu spekulieren. > Vermutlich I/O Leitungen, die per Glue Logic auf A15,16,17 für das 512kb Schaltplan anschauen. Kein Grund Vermutungen anzustellen. > und auch kein > "gekauftes" CP/M Programm was > 32kb ist, denn irgendwo muss ja der Auf dem N8VEM läuft (u.a.) CP/M 3. Mit gescheitem BIOS laufen darunter Programme bis 60K. > Umschalter reingebracht werden und vor allem muss der Code > adressunabhängig sein, Sprünge dürfen nicht über die Grenzen usw. Alles Quatsch. [1] http://n8vem-sbc.pbworks.com
Leo C. schrieb: > Alles Quatsch. Ich habe eigentlich keine Lust mehr mich mit einem selbstherrlichen Typen zu unterhalten, der sich lieber seiner eigenen Spielwiese hier widmen sollte aber was ich sagte ich genau richtig: Mit 16 Bit gibt es KEINE Möglichkeit mehr als 64k direkt zu adressieren. Egal wie man es auch dreht. Das geht nur über Multiplexing mit Latches unter Zuhilfenahme von zusätzlichen Leitungen die aus dem I/O Bus herausgeschraubt werden. Und genau DAS wurde beim N8VEm gemacht. A5,A6,M1 und IOREQ formen CS_CFG. Mit CS_CFG mit wird mit A2,A1 verknuselt und ergibt CS_CFG1 und 2. Und die gehen auf ein LATCH woraus dann die A16,17,18 Leitungen erzeugt werden. Gültig solange bis ein neuer I/O Befehl gegeben wird. Die Umschaltung passiert aber mit Befehlen auf dem I/O Bus: OUT 78 und OUT 7C. Natürlich muss die Software darauf angepasst sein. Ein Bild hätte tausend Zeilen erspart das umständlich zu beschreiben.
Christian J. schrieb: > für die Weiterentwicklung meines OS steht ein größerer Schnitt an, zudem > ich ein eigen entwickeltes Monitorsystem habe. Dieses kann aktuell auch > Userprogramme von einer SD Karte einlesen und starten. Die 16KB EPROM > sollen ja auch genutzt werden und nicht einfach beim Start des Userprogs > weggeschaltet werden wie derzeit. Und das ist schlecht, weil? > Der C64 schwirrt mir etwas im Kopf herum. Seine 64Kb waren in RAM und > ROM aufgeteilt, manches lag übereinander und konnte umgeschaltet werden. > Viele Funktionen konnte man direkt nutzen wenn deren Adresse bekannt > war. Jein. Es gibt beim C64 zwei Overlays. Zum einen das System-ROM bei $E000 - $FFFF. Und das BASIC-ROM bei $A000 - $BFFF. Beide Overlays sind effektiv nur für Lese-Zugriffe, Schreibzugriffe gehen immer in das darunter liegende RAM. Und im Bereich $C000 - $CFFF sind diverse IO-Chips eingeblendet. Und das Farbcode-RAM. Das kann man auch noch abschalten (bei dann sehr merklichen Kollateralschäden) > Aktuell tendiere ich dazu das so zu Machen: > > Z80 startet auf aus dem ROM und initialisiert die Hardware wie zb RX/TX > Mechanismus, die Interrupts dafür und Ringpuffer. ,,, > Der Data Bereich des Monitors liegt in einer geschützten Area ganz oben. Was ist eine "geschützte Area"? > Die INT Mode 2 Tabelle kopiert der Monitor ins RAM bei $2000, so dass > sie beim Monitorleerlauf benutzt wird und auch vom Userprogramm (ab > $2100) modifizierbar ist. "modifizierbar" wie halt der gesamte RAM bei einem Z80-System. > Routinen wie putchar und getchar, printf werden aus dem Userprogramm her > im ROM aufgerufen, das Userprogramm muss sie nicht mitbringen. Spart > locker 4kb Platz. Das Konzept kommt mir vage bekannt vor. "BIOS" = "Basic Input Output System" ... dämmert da was? > Nicht benutzte Ints werden auf leere Routinen geleitet im ROM. Werden > die vom Userprogramm benötigt muss per Hand umgelenkt werden. ... > Veränderungen an den INTS werden vom Userprogramm in der RAM Tabelle > vorgenommen, zb die Umlenkung auf eigene Routine, bevor dann in die > eigentliche Routine zurückgesprungen wird. Interrupt-Vektoren umbiegen. Ein Klassiker. Ich hoffe, du versuchst nicht das zu patentieren. Könnte schief gehen. Prior Art und so. > Stellt sich auch die Frage ob Userprogramme überhaupt Rechte haben zb > Ints umzubiegen? Gegenfrage: was sollte sie daran hindern? Besteht denn überhaupt ein Unterschied zwischen dem was du "Userprogramm" nennst und einer Routine aus deinem ROM? > Das BIOS stellt ja eigentlich alles als API zur > Verfügung, bei DOS rief man INT21 auf, im BIOS war es INT13 und konnte > damit alles erreichen. Der Z80 hätte die RST Soft Interrrupts frei für > sowas. Deine Erinnerung trügt. Das BIOS in der Prä-DOS Ära hatte eine Sprung- Tabelle an einer definierten Adresse. CP/M hat BDOS-Aufrufe per CALL 5 entgegen genommen (ähnlich wie DOS später per INT 21). Auch der "INT n" Mechanismus des i8086 war nur eine marginale Erweiterung des "RST n" beim Z80. PS: ja, ich bin spät dran. Ostern und so :)
:
Bearbeitet durch User
Angehängte Dateien:
-
Zilog_Z-80A_CPU.jpg
37 KB -
z80-reset-1.png
65 KB -
z80-reset-2.png
76 KB
Nochmal zu Reset und Stackpointer. Inzwischen habe ein lauffähiges System mit Zilog NMOS Z80 CPU und ich kann jetzt sagen: Bei dieser CPU wird der Stackpointer durch RESET nicht beeinflusst. Die oben zitierte Aussage aus dem "Undocumented Z80 Documented" Dokument [1] ist also definitiv falsch. In dem Dokument gibt es noch einen Abschnitt zum Power Up:
1 | 2.4 Power on defaults |
2 | Matt has done some excellent research on this. He found that AF and SP are always set to |
3 | FFFFh after a reset, and all other registers are undefined (different depending on how long the |
4 | CPU has been powered off, different for different Z80 chips). |
5 | ... |
Auch diese Aussage kann ich mit meiner CPU nicht ganz nachvollziehen. Der SP hatte bei mir z.B. die Werte FEFF, FEFD und FE9E. Das einzige, was man sicher sagen kann, ist, daß alle Register (außer PC, IFF1 IFF2) nach Power Up undefiniert sind, und (bei NMOS) zu gesetzten Bits tendieren. Damit die Register ihren Inhalt verlieren, reicht es übrigens schon, den Takt (vorzugsweise auf low) anzuhalten. [1] http://www.myquest.nl/z80undocumented/
Leo C. schrieb: > Nochmal zu Reset und Stackpointer. > > Inzwischen habe ein lauffähiges System mit Zilog NMOS Z80 CPU und ich > kann jetzt sagen: Bei dieser CPU wird der Stackpointer durch RESET nicht > beeinflusst. Die oben zitierte Aussage aus dem "Undocumented Z80 > Documented" Dokument [1] ist also definitiv falsch. Gegenfrage: Ist das nicht völlig wurscht? Da der Z80 (anders als ein AVR) sowieso nicht weiß, wieviel Speicher er hat und wo der liegt, kann es daher sowieso keinen irgendwie vernünftigen Wert geben und jedes Z80 Programm muss zwangsweise damit beginnen, dass der SP relativ früh im Programmlauf hardwareabhängig gesetzt wird. Womit die Frage, welchen Wert der SP nach einem Reset hat, rein akademischer Natur ist. Denn egal welcher es ist, er ist sowieso in den meisten Fällen nicht wirklich brauchbar.
:
Bearbeitet durch User
Karl Heinz schrieb: > Ist das nicht völlig wurscht? Natürlich. Es gab hier aber den Vorschlag, daß man das (nicht vorhandene Feature) beim Hardwaredesign auszunutzen (Beitrag "Re: Z80: Aufteilung der Aufgabenverteilung auf ROM und RAM").
Leo C. schrieb: > Karl Heinz schrieb: >> Ist das nicht völlig wurscht? > > Natürlich. Es gab hier aber den Vorschlag, daß man das (nicht vorhandene > Feature) beim Hardwaredesign auszunutzen > (Beitrag "Re: Z80: Aufteilung der Aufgabenverteilung auf ROM und RAM"). SOrry wenn ich da wiederspreche. Ich seh ausser der Erwähnung des vermeintlichen Sachverhaltes in MaWins Beitrag nichts, was einen definierten SP voraussetzen würde. Der wesentliche Punkt ist, dass das ROM bei 0 eingeblendet wurde und dann von dort weggebelendet wird. Die Sache mit dem SP ist dafür völlig irrelevant. Hätte MaWin geschrieben
1 | Der Z80 startet nach RESET ja von 0. |
2 | Also muss bei 0 ROM sein. |
hätte das überhaupt nichts am grundsätzlichen Vorgehen geändert.
:
Bearbeitet durch User
Karl Heinz schrieb: > SOrry wenn ich da wiederspreche. Kein Problem. MaWin schrieb: > Der Z80 startet nach RESET ja von 0 und erwartet Stack bei FFFF. > Also muss bei 0 ROM sein und bei FFFF RAM. > Später gibt es viele Systeme (wie CP/M), die bei 0 auch RAM > sehen wollen. Da steht allerdings das bei FFFF RAM sein muß.
Leo C. schrieb: > Karl Heinz schrieb: >> SOrry wenn ich da wiederspreche. > > Kein Problem. > > MaWin schrieb: >> Der Z80 startet nach RESET ja von 0 und erwartet Stack bei FFFF. >> Also muss bei 0 ROM sein und bei FFFF RAM. >> Später gibt es viele Systeme (wie CP/M), die bei 0 auch RAM >> sehen wollen. > > Da steht allerdings das bei FFFF RAM sein muß. Ja. Ignorier es. Es ist so nicht richtig. Allerdings trägt es auch nichts zur Sache bei, egal ob richtig oder falsch. Eine Aussage ala > Da du von falschen Voraussetzungen ausgehst, ist auch der Rest deiner Ausführungen unbrauchbar. ist daher unbegründet. Der Rest von MaWins Ausführungen hängt nicht davon ab, ob dort RAM liegt oder nicht oder welchen Wert der SP nach einem Reset hat.
:
Bearbeitet durch User
Christian J. schrieb: > Mit 16 Bit gibt es KEINE > Möglichkeit mehr als 64k direkt zu adressieren. Egal wie man es auch > dreht. nanana.. jetzt spielst aber du den Selbstherrlichen. Schon beim Z8 hatte man zwei Adreßräume (je nach verwendetem Maschinenbefehl), womit sich ein Gesamtraum von 64K plus 62K ergeben hatte - aber das nur am Rande. Bei CP/M-Systemen war das Dilemma fast immer so gelöst worden, daß der gesamte Speicherbereich schlichtweg RAM war - mit 2 Ausnahmen: 1. direkt nach Reset war der RAM weggeschaltet und nur ein ROM ab 0 eingeblendet. (Also nix mit RAM auf FFFF) Dort war sowas wie der Kaltstartcode und die wesentlichen Teile des BIOS untergebracht. Danach folgte ein anderer RAM-Bereich, der zum Video-Puffer gehörte, von wo aus der damals übliche Alpha-Bildschirm von 80x25 oder 64x24 Zeichen je nach Hardware betrieben wurde. 2. ein möglichst kleiner Bereich am oberen Speicherende war immer ROM, in meiner Erinnerung hatte dazu 1 oder 2K ausgereicht. Dort war nur der Umschalter zwischen RAM und ROM sowie die Einsprünge ins BIOS und deren Rückkehrcode (und wohl auch die Laufwerks-Deskriptoren - ist zu lange her!!) angeordnet. Somit hatte eine Anwendung bis zu 60K freien RAM, wenn man den CCP rotzfrech überschrieb - was durchaus normal und erlaubt war. W.S.
W.S. schrieb: > 60K freien RAM Naja, das BDOS brauchte auch seinen Platz. Das war in den 2k nicht mit drin. Was manchen Experten heute nicht (mehr?) bewusst ist: Ein System mit 48k verfügbarem RAM war durchaus brauchbar für eine schöne Textverarbeitung. Auch Turbopascal war damit zufrieden. Und alles lief sauschnell. Und was noch seltsamer ist: Es gab nicht einmal im Monat 100MBytes Fehlerkorrekturen. Die Soft funktionierte einfach.
Nun ja, unserem TO "hobel" haben wir ja nun mehrere ganze Breitseiten an Anregungen und Vorschlägen gemacht - und es gibt wohl immer noch eine durchaus erkleckliche Menge an Software für solche historischen Systeme. Nun kan er sich aussuchen, was er draus macht. W.S.
Georg G. schrieb: > Die Soft funktionierte einfach. Abgesehen davon, dass die Grösse von Patches mindestens mit der Grösse der installierten Software wächst war das im Zeitalter vor dem Internet und vor den Virus-Epidemien. Bugs blieben mindestens bis zur nächsten Version einfach drin.
W.S. schrieb: > nanana.. jetzt spielst aber du den Selbstherrlichen. Schon beim Z8 hatte > man zwei Adreßräume Der Z8 kam nach dem Z80 - und hatte einen völlig anderen Zielmarkt.
W.S. schrieb: > Christian J. schrieb: >> Mit 16 Bit gibt es KEINE >> Möglichkeit mehr als 64k direkt zu adressieren. Egal wie man es auch >> dreht. > > nanana.. jetzt spielst aber du den Selbstherrlichen. Schon beim Z8 hatte > man zwei Adreßräume (je nach verwendetem Maschinenbefehl), womit sich > ein Gesamtraum von 64K plus 62K ergeben hatte - aber das nur am Rande. > > Bei CP/M-Systemen war das Dilemma fast immer so gelöst worden, daß der > gesamte Speicherbereich schlichtweg RAM war - mit 2 Ausnahmen: > > 1. direkt nach Reset war der RAM weggeschaltet und nur ein ROM ab 0 > eingeblendet. (Also nix mit RAM auf FFFF) Dort war sowas wie der > Kaltstartcode und die wesentlichen Teile des BIOS untergebracht. > > Danach folgte ein anderer RAM-Bereich, der zum Video-Puffer gehörte, von > wo aus der damals übliche Alpha-Bildschirm von 80x25 oder 64x24 Zeichen > je nach Hardware betrieben wurde. > > 2. ein möglichst kleiner Bereich am oberen Speicherende war immer ROM, > in meiner Erinnerung hatte dazu 1 oder 2K ausgereicht. Dort war nur der > Umschalter zwischen RAM und ROM sowie die Einsprünge ins BIOS und deren > Rückkehrcode (und wohl auch die Laufwerks-Deskriptoren - ist zu lange > her!!) angeordnet. > > Somit hatte eine Anwendung bis zu 60K freien RAM, wenn man den CCP > rotzfrech überschrieb - was durchaus normal und erlaubt war. > > W.S. Die 1 oder 2k oben sind auch nicht notwendig. Wesentlich ist lediglich ein Lader der das System nach dem Rest an den Haaren aus dem Sumpf zieht, also ein BIOS + BDOS + CCP von irgend einem Massenspeicher laden kann. Ich habe gerade ein historisches DDR System wieder zusammengebastelt und zum Laufen bekommen (K1520, http://www.robotrontechnik.de/html/forum/thwb/showtopic.php?threadid=12101). Das System besteht aus 3K ROM und 64K RAM. Der RM enthält außer dem primären Lader noch den CCP um ihn schnell beim Warmstart nachladen zu können. Gruß, Holm
Georg G. schrieb: > W.S. schrieb: >> 60K freien RAM > > Naja, das BDOS brauchte auch seinen Platz. Das war in den 2k nicht mit > drin. > > Was manchen Experten heute nicht (mehr?) bewusst ist: Ein System mit 48k > verfügbarem RAM war durchaus brauchbar für eine schöne Textverarbeitung. > Auch Turbopascal war damit zufrieden. Und alles lief sauschnell. Und was > noch seltsamer ist: Es gab nicht einmal im Monat 100MBytes > Fehlerkorrekturen. Die Soft funktionierte einfach. Man kann auch das BDOS überscheiben wenn man seine Dienste nicht braucht (Dateiarbeit). Der Programmexit entspricht dann aber einem Kaltstart, d.h. neu laden von BDOS+CCP(+BIOS). Gruß, Holm
Christian J. schrieb: > [...] Der Z80 kann Instruktionen nicht neu starten. Damit kannst du keine Pagefaults implementieren und jede Form von transparentem "ich habe mehr als 64 KB RAM" fällt schlichtweg aus. Aber es muss ja nicht transparent sein...
S. R. schrieb: > Der Z80 kann Instruktionen nicht neu starten. Damit kannst du keine > Pagefaults implementieren Das muss man ja auch nicht, man könnte schon probieren, den Takt mitten im Befehl anzuhalten, den Speicher nachzuladen und dann den Befehl zu Ende zu führen, ich denke dass das trotz nichtstatischer Hardware gehen müsste, sofern das für neuere Ausführungen (CMOS) überhaupt noch zutrifft. Ich wüsste aber nicht dass das schon mal jemand realisiert hat, und ich glaube auch nicht, dass sich das lohnt - bei meinem CP/M-System wird beim Aufruf eines Unterprogramms geprüft, ob es sich im Speicher befindet, und notfalls wird es nachgeladen, das reicht völlig, im konkreten Fall für Steuerungen mit mehr als 100 k Zeilen Code. Georg
Bleibt das Problem, dass du den Pagefault komplett in Hardware beheben musst, während der Z80 auf /WAIT steht und am Bus zerrt, d.h. du kannst währenddessen nichtmal aus dem RAM lesen. Wenn du das sinnvoll (=allgemeingültig) hinbekommst, Hut ab. :-)
Georg schrieb: > Ende zu führen, ich denke dass das trotz nichtstatischer Hardware gehen > müsste, Schon das Original war nach Zilogs Aussage vollständig statisch. Aufgelaufen wärst du bei den 6800ern, die waren dynamisch. > Ich wüsste aber nicht dass das schon mal jemand realisiert hat, Ich wüsste auch nicht warum. Zu dem Zeitpunkt, zu dem solche Speichermengen billig genug für Masseneinsatz waren, hatte man bessere Alternativen. Als die Z80 rauskam waren 4KB RAM schon ganz ordentlich.
:
Bearbeitet durch User
S. R. schrieb: > musst, während der Z80 auf /WAIT steht und am Bus zerrt, d.h. du kannst > währenddessen nichtmal aus dem RAM lesen. Wenn du das sinnvoll > (=allgemeingültig) hinbekommst, Hut ab. :-) Schon mal was von Tristate-fähigen Bustreibern gehört? Gibt natürlich, wenn stilecht in Retro ausgeführt, ein ziemliches Gattergrab. Und bevor jemand CPLD ruft: Ins FPGA passt auch eine Z80 mit virtuellem Speicher rein, ggf. gleich im Rudel für Multithreading. Ausserdem kann man dann gleich auf die 32-Bit Z80 gehen, aka Z380.
:
Bearbeitet durch User
Angehängte Dateien:
A. K. schrieb: > Schon das Original war nach Zilogs Aussage vollständig statisch. > Aufgelaufen wärst du bei den 6800ern, die waren dynamisch. Z80 irgendwie auch. Oder wie soll man sonst z.B. die Fußnote im Technical Manual von 1977 erkären?
1 | E. Although static by design. testing guarantees tw(PHI H) of 200 µsec maximum |
Für tw(PHI L) sind sogar nur max 2000ns angegeben. Das Thema wurde hier irgendwo schonmal diskutiert. Ich weiß aber nicht mehr, ob es damals eine Erklärung gab. Im Anhang ist ein Ausschnitt aus der FAQ von hier: http://www.z80.info/zip/ZilogProductSpecsDatabook129-143.pdf Und letzter Satz hier: Beitrag "Re: Z80: Aufteilung der Aufgabenverteilung auf ROM und RAM"
Leo C. schrieb: > Z80 irgendwie auch. Oder wie soll man sonst z.B. die Fußnote im > Technical Manual von 1977 erkären? "static by design" ist unmissverständlich. Die Grenzen beziehen sich erklärtermassen auf die Testprozedur, nicht auf das Design.
:
Bearbeitet durch User
Leo C. schrieb: > Und letzter Satz hier: > Beitrag "Re: Z80: Aufteilung der Aufgabenverteilung auf ROM und RAM" Im Netz gibts jede Menge nette Aussagen. So findet sich irgendwo auch die Aussage, 6800 und 6809 wären vollständig statisch, während die Datasheets von Motorola explizit das Gegenteil behaupten - und zwar im Kontext vom DMA beim cycle stealing Verfahren, das deshalb nicht mehr als 10 Takte ununterbrochen durchgeführt werden darf.
:
Bearbeitet durch User
Angehängte Dateien:
A. K. schrieb: >> Und letzter Satz hier: >> Beitrag "Re: Z80: Aufteilung der Aufgabenverteilung auf ROM und RAM" > > Im Netz gibts jede Menge nette Aussagen. So findet sich irgendwo auch Die Aussage da oben ist aber von mir. ;) Vor ein paar Tagen selbst getestet. Mein Z80A-Exemplar verliert bei Clock auf High irgendwann die Registerinhalte (Bei Clock auf Low sowieso). A. K. schrieb: > "static by design" ist unmissverständlich. Die Grenzen beziehen sich > erklärtermassen auf die Testprozedur, nicht auf das Design. Ich habe mich falsch ausgedrückt. Mich interessiert, warum Zilog ein Design als Statisch bezeichnet (bezeichnen kann), obwohl die Registerinhalte ohne Takt verloren gehen. Nach landläufiger Meinung ist so ein Design eben nicht statisch, egal wie Zilog das nennt. Übrigens sind im aktuellen Datenblatt TwCh und TwCl beide mit max 2000ns spezifiziert.
Leo C. schrieb: > sind im aktuellen Datenblatt TwCh und TwCl beide mit max 2000ns > spezifiziert. Und es steht auch ausdrücklich drin, weshalb das so sei: Weil das die Grenzen des Testverfahrens wären. > warum Zilog ein Design als Statisch bezeichnet (bezeichnen kann) Ich kann natürlich nicht ausschliessen, dass Zilog hier blankweg gelogen oder die CPU später umdesigned hat.
:
Bearbeitet durch User
Holm Tiffe schrieb: > Die 1 oder 2k oben sind auch nicht notwendig. Doch. wieviel konkret, ist diskutabel, aber sein muß es. Denn das ganze BIOS, was ja sämtlichen I/O-Verkehr macht, muß ja auch irgendwo hin. Also gab's im allerobersten Stückchen RAM nur die BIOS-Einsprünge und den Umschalter, der den viel weiter unten liegenden RAM ausblendet und den EPROM mit dem eigentlichen BIOS einblendet. Das was du da mit dem historischen DDR-Modell beschrieben hast, wäre dann ein System, wo das BIOS komplett im RAM residiert und dementsprechend so seinen Platz braucht, der wiederum von den zur verfügung stehenden 60K oder 62K abgeht. (Hab wirklich vergessen, wie groß das BDOS eigentlich war, entweder 2,5K oder 3,5K glaub ich..) W.S.
A. K. schrieb: >> musst, während der Z80 auf /WAIT steht und am Bus zerrt, d.h. du kannst >> währenddessen nichtmal aus dem RAM lesen. Wenn du das sinnvoll >> (=allgemeingültig) hinbekommst, Hut ab. :-) > > Schon mal was von Tristate-fähigen Bustreibern gehört? Gibt natürlich, > wenn stilecht in Retro ausgeführt, ein ziemliches Gattergrab. Daran hatte ich nicht gedacht. Mitten im Befehl mag der Z80 kein /BUSREQ ausführen, und mit /WAIT allein zieht er den Bus nicht auf Tristate. Aber wenn man eine echte MMU so diskret aufbaut, wird die vermutlich komplizierter als das Gespann aus Z80 und restlicher Logik. Gibt es denn richtige, pagefault-fähige MMUs, die man mit dem Z80 verheiraten könnte? Die 68k-Teile werden vermutlich eher nicht passen. Irgendwie wäre das lustig. W.S. schrieb: > Also gab's im allerobersten Stückchen RAM nur die BIOS-Einsprünge und > den Umschalter, der den viel weiter unten liegenden RAM ausblendet und > den EPROM mit dem eigentlichen BIOS einblendet. War diese Vorgehensweise üblich? Die paar Systeme, die ich mir angeschaut hatte, haben das BIOS entweder in den RAM kopiert und dort gelassen, oder das ROM dauerhaft in den Adressraum gemappt. Nicht zu komplizierte Hardware vorausgesetzt, sollte sich ein vollständiges BIOS locker in 2 oder 4 KB implementieren lassen. Aber mal weiter gedacht: Wenn man das mit dem BIOS kann, müsste man das doch auch mit dem BDOS können. Sind ja beides nur Einsprungtabellen. Hat man das gemacht, und wenn ja, gibt's da Beschreibungen zu?
A. K. schrieb: > Leo C. schrieb: >> sind im aktuellen Datenblatt TwCh und TwCl beide mit max 2000ns >> spezifiziert. > > Und es steht auch ausdrücklich drin, weshalb das so sei: Weil das die > Grenzen des Testverfahrens wären. > >> warum Zilog ein Design als Statisch bezeichnet (bezeichnen kann) > > Ich kann natürlich nicht ausschliessen, dass Zilog hier blankweg gelogen > oder die CPU später umdesigned hat. Mir wäre nicht bekannt, daß der Z80 in NMOS als "static design" beworben worden wäre. Es waren im Gegenteil die CMOS-Versionen des Z80 die diese Eigenschaft als neues Feature vorzuweisen hatten. Mir spuken noch 200kHz minimale Taktfrequenz im Kopf herum. Und daß man halt diese aufwendige Einzelschrittlogik mit /WAIT brauchte, statt einfach den Takt anzuhalten.
S. R. schrieb: > Aber mal weiter gedacht: Wenn man das mit dem BIOS kann, müsste man das > doch auch mit dem BDOS können. Im typischen CP/M-System ist zur Laufzeit alles RAM. Es basierte ja zunächst mal auf Floppies, und es war eine Art Urlader notwendig, bei mir z.B. ein Prom mit 512 Byte an der Adresse 0 in Bank 0, das etwa das gleiche machte wie auch im PC, hauptsächlich die vorgesehene Anzahl Sektoren an eine vorgesehene Adresse laden, und dazu einige weniger grundlegende Sachen, bei mir z.B. eine Bildschirmgrafik mit der Aufforderung eine Floppy einzulegen, was aber für die Funktion nicht unbedingt notwendig ist. Hatte der spätere UrPC auch so ähnlich. Soweit hatte das aber mit CP/M noch garnichts zu tun, das kam erst nach dem Laden von Floppy durch einen Sprung an die BDOS-Startadresse ins Spiel, lief komplett im (64k) RAM, das Bootprom wurde ausgeblendet. So funktionierten auch die ersten praktisch einsetzbaren Bürorechner wie etwa der Superbrain. Aus Performancegründen habe ich später die Floppies ersetzt durch eine ROM-Floppy für die Steuerungssoftware und eine RAM-Floppy für die Daten, was aber im Prinzip nichts änderte, die ROM-Floppy war genauso in Sektoren organisiert wie die echten Floppies auch, es ging bloss vergleichsweise rasend schnell. Insofern waren CP/M und DOS sehr ähnlich, und durchaus änderungsfreudlich - neue Boot-Floppy = Betriebssystem-Update, sofern nötig. Übrigens konnte man, wenn man keine Funktionen des Betriebssystems brauchte, durchaus den ganzen 64k-RAM für eigene Zwecke nutzen, man musste bloss am Ende einen hardwaregleichen Reset aufrufen (Adresse 0, ev. auch Bank 0), dann wurde ja das BS neu geladen (Kaltstart). Georg
S. R. schrieb: > W.S. schrieb: >> Also gab's im allerobersten Stückchen RAM nur die BIOS-Einsprünge und >> den Umschalter, der den viel weiter unten liegenden RAM ausblendet und >> den EPROM mit dem eigentlichen BIOS einblendet. > > War diese Vorgehensweise üblich? Die paar Systeme, die ich mir > angeschaut hatte, haben das BIOS entweder in den RAM kopiert und dort > gelassen, oder das ROM dauerhaft in den Adressraum gemappt. Yep. Das BIOS statisch in den Adreßraum gemapt ist die klassische Variante. Die nur eben extra Aufwand erfordert, um den Z80 nach einem Kaltstart das (nicht initialisierte) RAM ab 0x0000 zu überspringen zu lassen bis zum BIOS-Eintrittspunkt. > Nicht zu > komplizierte Hardware vorausgesetzt, sollte sich ein vollständiges BIOS > locker in 2 oder 4 KB implementieren lassen. Yep. 4KB waren üblich und beinhalteten gerne noch feste RAM-Bereiche wie einen (character) frame buffer. > Aber mal weiter gedacht: Wenn man das mit dem BIOS kann, müsste man das > doch auch mit dem BDOS können. Sind ja beides nur Einsprungtabellen. Nicht direkt. Das BIOS hat eine Einsprungtabelle am Anfang. In das BDOS springt man per CALL 5. Und den JMP an Adresse 5 im RAM muß man auch erstmal initialisieren. > Hat man das gemacht, und wenn ja, gibt's da Beschreibungen zu? Ich will nicht ausschließen daß es gemacht wurde. Also daß man BDOS und gegebenenfalls CCP aus einem ROM ins RAM kopiert hat. Oder nach dem Kaltstart erstmal in "sichere" Speicherbereiche z.B. eine RAM-Disk kopiert hat um sie bei Bedarf schnell wiederherstellen zu können. Allerdings widerspricht das der Grundidee, daß Grundsystem so flexibel wie möglich zu halten. Denn es gab ja gar nicht das BDOS, sondern u.U. mehrere Varianten. Oder gleich ganz fremde Betriebssysteme wie UDOS.
Axel Schwenke schrieb: > Mir wäre nicht bekannt, daß der Z80 in NMOS als "static design" beworben > worden wäre. Ist er. Das Thema hatten wir nun schon x-mal, und wirklich eine Rolle spielt es immernoch nicht. ;-) Georg schrieb: > Im typischen CP/M-System ist zur Laufzeit alles RAM. [...] Ich meinte die atypischen CP/M-Systeme, die das gesamte BIOS im ROM haben. War es bei denen eher üblich, das BIOS dauerhaft gemappt zu haben, oder wurden nur die Einsprünge vorgehalten und dann umgemappt? Und wenn letzteres, hat man das gleiche mit dem BDOS auch gemacht, um den TPA möglichst weit nach oben zu drücken? Mein jetziges System hat einen externen Urlader, der das BIOS (ca. 450 Bytes) in den RAM kopiert, die nächste Iteration hat einen großen Flash und eine MMU (4k Pagegröße). Da ergeben sich mir gerade folgende Möglichkeiten: (a) Das typische System: 64 KB RAM und ROM-Floppy. Maximaler TPA. (b) BIOS im ROM: 60 KB RAM, 4 KB ROM. (c) BIOS und BDOS im ROM: 60 KB RAM, 4 KB ROM. Sind (b) und (c) sinnvoll, bzw. kann man CP/M überhaupt aus einem ROM ausführen?
S. R. schrieb: > Ich meinte die atypischen CP/M-Systeme, die das gesamte BIOS im ROM So was gibts nicht. Das BIOS muß nun mal zum BDOS passen und wird bei jedem Kaltstart ins RAM geladen. Es gibt aber BIOSe, die I/O-Funktionen im ROM aufrufen. Z.B. das MDS-800 BIOS, das im Anhang des CP/M 2.2 Alteration Guide abgedruckt ist. > haben. War es bei denen eher üblich, das BIOS dauerhaft gemappt zu > haben, oder wurden nur die Einsprünge vorgehalten und dann umgemappt? Bei Rechnern wie Amstrad/Schneider CPC zum Beispiel. Der mappt das ROM auch in Interrupt-Routinen um. Bei reinen CP/M Maschinen eher weniger. > Und wenn letzteres, hat man das gleiche mit dem BDOS auch gemacht, um > den TPA möglichst weit nach oben zu drücken? Sicher nicht bei CP/M 2. CP/M 3 hat in der gebankten Version den größten Teil des BDOS in Bank 0 und die TPA in Bank 1. > kann man CP/M überhaupt aus einem ROM ausführen? Original CP/M nicht. Das 2er BDOS hat einen Variablenblock und den lokalen Stack mitten im Code und einen weiteren Block am Ende (vor dem BIOS). Aber die Quellen sind heute ja Netz. Könnte man also umarrangieren.
W.S. schrieb: > Holm Tiffe schrieb: >> Die 1 oder 2k oben sind auch nicht notwendig. > > Doch. wieviel konkret, ist diskutabel, aber sein muß es. Denn das ganze > BIOS, was ja sämtlichen I/O-Verkehr macht, muß ja auch irgendwo hin. > Also gab's im allerobersten Stückchen RAM nur die BIOS-Einsprünge und > den Umschalter, der den viel weiter unten liegenden RAM ausblendet und > den EPROM mit dem eigentlichen BIOS einblendet. > > Das was du da mit dem historischen DDR-Modell beschrieben hast, wäre > dann ein System, wo das BIOS komplett im RAM residiert und > dementsprechend so seinen Platz braucht, der wiederum von den zur > verfügung stehenden 60K oder 62K abgeht. (Hab wirklich vergessen, wie > groß das BDOS eigentlich war, entweder 2,5K oder 3,5K glaub ich..) > > W.S. Ähh...ich verstehe Dich nicht. Du hat offensichtlich gelesen was ich gemacht habe und ich habe nur das zu DDR Zeiten von anderen Leuten konstruierte System nachgebaut. Dieses System hat 3K ROM ab 0000, und 64K RAM ab 0000 die sich 16K-weise abschalten lassen. 2K von den 3K ROM enthalten den CCP (wegen schnellem Nachladen bei Warmstart), das restliche eine Kilobyte enthält den ab Reset aktiven Lader der von der Floppy BIOS und BDOS in den RAM schaufelt und den Kaltstart bewerkstelligt. Da ist kein ROM am oberen Ende. Der verbreitete DDR Computer BC A5120 hat auf seinen Platinen exakt 1 Kilobyte ROM, von Zeichengeneratoren mal abgesehen, die nur den primären Lader enthalten und der auch ab Adresse 0 liegt. (Dieser Computer hat eine 2. CPU die als DMA für den Floppybetrieb arbeitet). Wir können uns also wohl darauf einigen das zwar oben ein ROM unbedingt sein muß, dessen Größe aber sehr gerne 0 ist? ..oder wie soll ich das verstehen. Ich meine, Deine Aussage in allen Ehren, aber ich sitze vor dem Zeuch und weiß was ich da zusammengebaut habe. Gruß, Holm
Georg schrieb: > 512 Byte an der Adresse 0 Nicht so üppig bitte! 32 Bytes in einem Fuse-Prom waren völlig ausreichend (Tarbell Controller).
Leo C. schrieb: > S. R. schrieb: > Das BIOS muß nun mal zum BDOS passen und wird bei jedem Kaltstart ins > RAM geladen. Ich dachte, dass die BIOS-Schnittstelle von CP/M relativ stabil ist. Aber gut, das war das BDOS auch, insofern hatte ich da wohl ein falsches Bild im Kopf. >> kann man CP/M überhaupt aus einem ROM ausführen? > Original CP/M nicht. Gut zu wissen. Dann wird es also auf ein "typisches" System hinauslaufen: 64 KB RAM, wo per Loader aus dem Flash beim Start BIOS, BDOS und CCP hinkopiert werden. :-)
Ah, das ging ja noch weiter, gar nicht mehr auf dem Watch gehabt. Diese Milchmädchenstreitereien um den Sp sind banane, er wird immer gesetzt und fertig, direkt als erstes. Trotzdem mal für Normalbürger, verständlich, abstrakt, global gesehen: a) Ich mmöchte auf einem Z80 System mit RAM Banks ein 80kb Programm ausführen das nichts davon weiss, dass es auf einem banked system läuft. Dazu braucht es noch 20kb .bss Space. Geht das? b) Ist es möglich ein gebanktes System, was unten ROM hat und den oberen Teil umschalten kann OHNE IRGENDWELCHE Sonderroutinen in den Programmen zu betreiben? Per Hardware? Muss das Programm wissen, dass es auf einem gebankten System arbeitet? c) Was habe ich von 256kb RAM in Banks aus Sicht des Userprogramms? Kann es jetzt fröhlich über 200kb verfügen, einen 100KB Array anlegen quer über alle Banks drüber? Das Einzige was ich mir nur vorstellen kann ist ein Multitasking, d.h. aus einem Kontrollprogramm im OS wird verwaltet wo geladene Programme hinkommen. Das war es was ich wissen wollte. PS: Und wieso ist der Z80 nicht statisch? Register sind keine RAM Zellen sondern Flipflops. Takt weg = Alle stillgestanden? Wieso soll der nicht statisch sein? Die Z80 enthält intern nichts weiter als Gatter und das Design ist synchron.
Christian J. schrieb: > a) Ich mmöchte auf einem Z80 System mit RAM Banks ein 80kb Programm > ausführen das nichts davon weiss, dass es auf einem banked system läuft. > Dazu braucht es noch 20kb .bss Space. Geht das? Soweit ich weiss ist es bei Z80 nicht möglich, zwischen Code- und Datenadressen zu unterscheiden. Das ist der klassische Weg, mit 16-Bit Adressen operierenden CPUs ohne irgendeine Form von aktiv genutzter MMU mehr Platz zu verschaffen. > PS: Und wieso ist der Z80 nicht statisch? Register sind keine RAM Zellen > sondern Flipflops. Takt weg = Alle stillgestanden? Wieso soll der nicht > statisch sein? Die Z80 enthält intern nichts weiter als Gatter und das > Design ist synchron. Es gibt dynamische Logikgatter (such mal nach "domino logic") und Register können wie DRAM-Zellen implementiert sein. Motorolas 6800 durfte nicht länger als offizielle ~10 Takte ohne Taktsignal bleiben (z.B. im cycle stealing DMA), sonst liefen die Daten aus. Mit synchron/asynchron hat das nichts zu tun.
:
Bearbeitet durch User
Christian J. schrieb: > a) Ich mmöchte auf einem Z80 System mit RAM Banks ein 80kb Programm > ausführen das nichts davon weiss, dass es auf einem banked system läuft. > Dazu braucht es noch 20kb .bss Space. Geht das? Nein, es sei denn, dein Linker sorgt zusammen mit einer passenden Runtime Lib dafür. Mir ist kein derartiger Linker bekannt. > b) Ist es möglich ein gebanktes System, was unten ROM hat und den oberen > Teil umschalten kann OHNE IRGENDWELCHE Sonderroutinen in den Programmen > zu betreiben? Per Hardware? Muss das Programm wissen, dass es auf einem > gebankten System arbeitet? Das ist dem Programm egal. Es muss nur für den passenden Adressraum relokiert werden. > c) Was habe ich von 256kb RAM in Banks aus Sicht des Userprogramms? Kann > es jetzt fröhlich über 200kb verfügen, einen 100KB Array anlegen quer > über alle Banks drüber? Da wird schon dein Compiler mit dir schimpfen. Das geht nicht. > Das Einzige was ich mir nur vorstellen kann ist > ein Multitasking, d.h. aus einem Kontrollprogramm im OS wird verwaltet > wo geladene Programme hinkommen. Genau so ist es. C/PM3 ist da für erste Versuche der beste Kandidat, gut dokumentiert, schnell an deine Hardware adaptiert. Wenn es dann besser werden soll, gibt es spezielle Varianten von Turbodos. Da hast du dann sogar Netzwerkfunktionen, Multi-User und Multi-CPU.
Georg G. schrieb: > Nein, es sei denn, dein Linker sorgt zusammen mit einer passenden > Runtime Lib dafür. Mir ist kein derartiger Linker bekannt. Auf anderen Rechnern damaliger Ära war Overlay-Technik recht verbreitet, beispielsweise PDP-11. Ich sollte es auch bei CP/M gegeben haben. http://os.lightweightsystems.com/2012/03/overlays-in-cpm.html Allerdings geht das nicht ganz ohne Mitarbeit des Programmierers. Die Organisation der Overlays war seine Aufgabe, er musste dem Linker das entsprechend mitteilen.
:
Bearbeitet durch User
Da gab es doch mal "Overlays" bei TurboPascal (3?, nur für x86?), wo sich der Compiler bzw. das Runtime-System um das nachladen gekümmert hat. Dann müsste "nur noch" das Nachladen durch Bank-Switching ersetzt werden.
A. K. schrieb: > Ich sollte es auch bei CP/M gegeben haben. Natürlich gab es Overlay Linker auch für CP/M. Aber die Frage war ja nach einem für den Programmierer transparenten System mit mehr als 64k. Bei einem Overlay Linker muss man schon - wie du ja auch geschrieben hast - heftig nachdenken. Was Christian sucht, ist ein komplettes Memory Management.
Konrad S. schrieb: > Da gab es doch mal "Overlays" bei TurboPascal (3?, nur für x86?), wo Auch für Z80 CP/M. Für viele Programmiersprachen unter CP/M gab es Overlay-Linker. Die Overlays wurden von Floppy nachgeladen. > sich der Compiler bzw. das Runtime-System um das nachladen gekümmert > hat. Dann müsste "nur noch" das Nachladen durch Bank-Switching ersetzt > werden. CP/M 3 war halt zu spät.
A. K. schrieb: > Es gibt dynamische Logikgatter (such mal nach "domino logic") und > Register können wie DRAM-Zellen implementiert sein. Motorolas 6800 > durfte nicht länger als offizielle ~10 Takte ohne Taktsignal bleiben > (z.B. im cycle stealing DMA), sonst liefen die Daten aus. Mit > synchron/asynchron hat das nichts zu tun. Was jemand schon ausführlich untersucht hat .....er ist "nicht ganz statisch": http://forum.tlienhard.com/phpBB3/viewtopic.php?f=3&t=917 >>Auch für Z80 CP/M. Für viele Programmiersprachen unter CP/M gab es >>Overlay-Linker. Die Overlays wurden von Floppy nachgeladen. Nun ja... eine DLL dürfte nichts anderes sein, mein Microsoft VB System lädt die erst rein wenn sie benutzt werden und entlädt sie danach auch wieder.
Christian J. schrieb: > Nun ja... eine DLL dürfte nichts anderes sein, Ziemlich anders. Overlays überlagern sich, wie der Name schon sagt. DLLs tun das nicht. Zudem setzen die meisten DLLs virtuellen Speicher voraus, denn über diesen Mechanismus werden sie nachgeladen.
Christian J. schrieb: > Nun ja... eine DLL dürfte nichts anderes sein, mein Microsoft VB System > lädt die erst rein wenn sie benutzt werden und entlädt sie danach auch > wieder. Dein Win läuft ganz sicher nicht auf einem Z80.
Georg G. schrieb: > Natürlich gab es Overlay Linker auch für CP/M. Aber die Frage war ja > nach einem für den Programmierer transparenten System mit mehr als 64k. > Bei einem Overlay Linker muss man schon - wie du ja auch geschrieben > hast - heftig nachdenken. > > Was Christian sucht, ist ein komplettes Memory Management. Ich fasse mal zusammen .... um aus einem Krüppel (=Z80) einen 100m Sprinter zu machen ist jede Menge Doping nötig und mann befasst sich eigentlich nur noch mit den Kunstgriffen das Unmögliche möglich zu machen. Ich erinnere mich da noch an den C64 und die Vergewaltigung des Zeilen-Interrupts um getrennte Bildschirme zu haben. Der eigentliche Sinn, nämlich das Userprogramm geht dabei verloren. Ich belasse es dabei wie es ist, 48kb sind da und dabei bleibt es auch. Für alles andere gibts den STM32F4 Cortex.
Ulrich F. schrieb: > Dein Win läuft ganz sicher nicht auf einem Z80. Nicht? UNd ich dachte ich könnte auch Excel 2014 darauf laufen lassen und auch im Internet surfen. Wie schade :-)
Christian J. schrieb: > Ich belasse es dabei wie es ist, 48kb sind da und dabei bleibt es auch. > Für alles andere gibts den STM32F4 Cortex. Irgenwie kommt mir die Alternative Z80 v. STM32F4 etwas komisch vor. Willst du dich nicht noch noch an einem 68000 versuchen? Das wäre passender. Oder notfalls an einem 8088.
Christian J. schrieb: > Excel 2014 darauf laufen lassen Das nicht. Aber es gab ähnliche Programme auch für Z80. Und die waren nicht mal schlecht. > und auch im Internet surfen. Wo liegt das Problem? Netzwerkadapter für Z80 gibt es (kannst eine Platine von mir haben, hi) und Lynx sollte man auch zum Laufen bekommen.
Hmmm.... Kann mir mal einer einen Emulator schreiben, damit ich mein Win auf meiner ollen CPM Kiste zum laufen bekomme? Muss auch nicht Win8.1 sein, XP würde mir reichen.... Im Ernst: Der Z80 hat ja nichts intus, was irgend ein Memory Mapping unterstützt. Keine Schutzkonzepte, noch nicht einmal ein Supervisor Modus. Ok, einen zweiten Registersatz... Aber das wars dann auch..... Damals. zu meiner Z80 Zeit, war ich mit 2KB RAM glücklich. 64KB hätte ich nie voll bekommen.... ;-)
Georg G. schrieb: > Das nicht. Aber es gab ähnliche Programme auch für Z80. Und die waren > nicht mal schlecht. Ich habe noch mit "Visicalc" Erfahrungen gemacht auf dem Apple ][ ... >>Damals. zu meiner Z80 Zeit, war ich mit 2KB RAM glücklich. >>64KB hätte ich nie voll bekommen.... ;-) Ja, das waren noch Zeiten, da hatte ich auch noch ein "Bonanza-Rad" und Mutti fand mich morgens eingeschlafen über der C64 Tastatur :-)
Hallo, im Prinzip kann man aus einem von Neumann-Z80 eine Havardsystem basteln, wie das ja auch umgekehrt geht, z.B. beim 8051. Z.B. könnte man M1 auswerten und hätte dann 64k Programmspeicher und 64k Daten-RAM. Dann müsste sich aber der Programmierer selbst darum kümmern, dass er den Inhalt des Programmspeichers nur ausführen, aber nicht lesen oder schreiben kann, es sei denn man macht die Mimik umschaltbar, aber so ein System ist einfach nicht beherrschbar, schon garnicht mit einem C-Compiler. In der Praxis wird man an irgendeinem Punkt scheitern, wo man etwa eine Tabelle aus dem Programmspeicher lesen müsste. Folgender Kompromiss ist denkbar: man legt ein System zugrunde mit viel Programm (aber < 64k) und wenig Daten und lagert grössere Datenteile aus in ein RAM, dass sich normalerweise hinter dem Programm verbirgt - der Zugriff darauf erfolgt dann nur durch spezielle Routinen, die das RAM per Banking freischalten. Ich habe z.B. Messdaten zu verwalten, auf die indiziert zugegriffen wird, dafür brauche ich dann nur eine Lese- und Schreibfunktion, die in einem nicht gebankten Teil des Programmspeichers ausgeführt wird. Auf die Art kann man auf grosse Datenmengen in fast unbeschränkt vielen Bänken zugreifen, aber halt nicht auf mehr Programm. Aber "ohne dass der Z80 was davon weiss" kann man nicht mehr als 64k verwenden, zumindest müsste man sich den Compiler zurechtschnitzen, aber dann weiss der das eben. Auch wenn man dem Z80 eine komplette Hardware-MMU verpassen würde, die müsste ja auch verwaltet werden. Georg
Georg schrieb: > Folgender Kompromiss ist denkbar: man legt ein System zugrunde mit viel > Programm (aber < 64k) und wenig Daten und lagert grössere Datenteile aus > in ein RAM, McFly..... aufwachen! :-) Lassen wir die Kirche im Dorf und lassen den Z80 auch das zu was er heute noch am besten kann: Spass am Basteln haben. In überschaubaren Systemen. Aber daraus jetzt mit Hängen und Würgen das erzeugen zu wollen, wofür es heute 1000-fach bessere systeme gibt, das würde ihm nicht gerecht. I<ch habe mit dem SDCC Compiler und einigen Tricks jetzt das OS so gebastelt, dass das Userprogramm nützliche Dinge von ihm erledigen lassen kann. es gibt 20 Einspringpunkte für Funktionen und damit ist es jetzt auch gut.
>Z.B. könnte man M1 auswerten und hätte dann 64k Programmspeicher und 64k >Daten-RAM. Das ist Käse. Beispiel: 01 34 12 LD BC,0x1234 /M1 geht nach Low, wenn der Opcode 0x01 gelesen wird, aber nicht, wenn die beiden Datenbytes (die auch zum Befehl gehören) gelesen werden. Viel Spaß dabei, das mit separatem Programm- und Datenspeicher zu managen.
Ulrich F. schrieb: > Im Ernst: > Der Z80 hat ja nichts intus, was irgend ein Memory Mapping unterstützt. > Keine Schutzkonzepte, noch nicht einmal ein Supervisor Modus. Kann man alles nachrüsten. ;) Der Anhang stammt aus: http://bitsavers.informatik.uni-stuttgart.de/pdf/zilog/1983_Zilog_Microprocessor_Applications_Reference_Book_Volume_2.pdf Zitat:
1 | CONClUSION |
2 | The scheme described provides memory expansion and |
3 | memory protection by using a flexible paging |
4 | mechanism. The scheme is compatible with both l80 |
5 | object code and the forthcoming Z800 design. |
6 | It therefore bridges the capabilities of the two |
7 | compatible microprocessor families and saves both |
8 | circuit design and software conversion effort. |
:
Bearbeitet durch User
Jim schrieb: > Das ist Käse. Nö. Du musst nur den Befehl mitdekodieren und daraus ableiten, welche Mx(x>=2) Zyklen Code- und welche Datenoperationen sind. ;-)
Holm Tiffe schrieb: > Ähh...ich verstehe Dich nicht. Ist doch ganz einfach: Entweder man packt CCP+BDOS+BIOS in voller Schönheit in den RAM, der dadurch relativ voll wird, oder man sucht nach Auswegen zum Freimachen von RAM. Und so ein Ausweg besteht darin, vom BIOS nur die aller-aller-nötigsten Teile, insbesondere die Einsprünge oben im RAM zu belassen und dort eine Umschaltng vorzusehen, welche einen unteren Teil des RAM's ausblendet und dafür dort den Rest des BIOS einblendet, der dann die eigentliche Arbeit macht. Da dein System (ich vermute mal K1520 vom weltberühmten Kombinat Robotron) im ROM nur den CCP und einen Kaltstartlader hat, muß folglich der Rest (BDOS+BIOS) eben oben im RAM residieren. W.S.
Christian J. schrieb: > Trotzdem mal für Normalbürger, verständlich, abstrakt, global gesehen: Du stellst wunderbare Fragen, die genau durchblicken lassen, welche Antwort du gerne hören möchtest, und welche nicht. Bist du zufällig Journalist und möchtest nur noch schnell einen O-Ton aus einem Interview bekommen, für den bereits vorige Woche geschriebenen Artikel? > a) Ich mmöchte auf einem Z80 System mit RAM Banks ein 80kb Programm > ausführen das nichts davon weiss, dass es auf einem banked system läuft. > Dazu braucht es noch 20kb .bss Space. Geht das? Du kannst transparent mehr als 64 KB adressieren, wenn du einen Adressraum mit mehr als 16 Bit hast. Der Z80 hat das nicht, also muss man sich anderweitig Abhilfe schaffen: Du entwirfst eine Architektur, die dem Z80 sehr ähnlich ist, aber 24-Bit Pointer vorsieht. Dann schreibst du dir eine VM, die diese Architektur auf einem Z80 nachbildet. Fertig. Nein, du kannst mit einem 16-Bit Pointer keine 80 KB Arrays adressieren. Du kriegst auch in eine 2m hohe 40 m²-Wohnung keine 100 m³ Schrankwand untergebracht, egal wie sehr du dich abmühst. > b) Ist es möglich ein gebanktes System, was unten ROM hat und den oberen > Teil umschalten kann OHNE IRGENDWELCHE Sonderroutinen in den Programmen > zu betreiben? Per Hardware? Muss das Programm wissen, dass es auf einem > gebankten System arbeitet? Natürlich ist das möglich, solange deine Programme in den Adressraum passen. Wenn sie das nicht tun, du sie aber in Stücke zerschneiden kannst, die jeweils einzeln in den Adressraum passen, dann hilft dir eine Overlay-Technik. Ansonsten hilft dir wieder eine VM. Innerhalb der VM brauchst du dann natürlich keine Sonderroutinen mehr, du hast ja genug Adressraum. > c) Was habe ich von 256kb RAM in Banks aus Sicht des Userprogramms? Kann > es jetzt fröhlich über 200kb verfügen, einen 100KB Array anlegen quer > über alle Banks drüber? Klar, solange du nicht linear mit einem Pointer darauf zugreifen möchtest... alles eine Frage der Zugriffsfunktionen. Einen linearen Zugriff bekommst du am einfachsten mit der oben skizzierten VM hin. > Das Einzige was ich mir nur vorstellen kann ist ein Multitasking, > d.h. aus einem Kontrollprogramm im OS wird verwaltet wo geladene > Programme hinkommen. Ein einzelnes Programm darf auch in mehreren Banks liegen, die Technik nennt man dann Overlay-Technik. > Das war es was ich wissen wollte. Nein, ist es nicht. Du willst nichts wissen. Du willst hören, was du schon weißt.
W.S. schrieb: > Holm Tiffe schrieb: >> Ähh...ich verstehe Dich nicht. > > Ist doch ganz einfach: > Entweder man packt CCP+BDOS+BIOS in voller Schönheit in den RAM, der > dadurch relativ voll wird, CPM2.2 > oder man sucht nach Auswegen zum Freimachen > von RAM. Und so ein Ausweg besteht darin, vom BIOS nur die > aller-aller-nötigsten Teile, insbesondere die Einsprünge oben im RAM zu > belassen und dort eine Umschaltng vorzusehen, welche einen unteren Teil > des RAM's ausblendet und dafür dort den Rest des BIOS einblendet, der > dann die eigentliche Arbeit macht. CPM3 Ja. allerdings beist sich das was Du jetzt schreibst mit Deiner Aussage das man unbedingt einen ROM am oberen Ende benötigt. > > Da dein System (ich vermute mal K1520 vom weltberühmten Kombinat > Robotron) K1520 und Robotron ist Hardware, eine Version eines Bussystems, zehntausendfach weltweit bewährt. Hast Du daran irgendwas auszusetzen oder warum erwähnst du das explizit? Wäre irgend Etwas anders wenn ich weltberühmtes ECB-Bus-System geschrieben hätte? Außer das da andere Steckverbinder und Platinenformate benutzt werden gibt es keinen wesentlichen Unterschied. > im ROM nur den CCP und einen Kaltstartlader hat, muß folglich > der Rest (BDOS+BIOS) eben oben im RAM residieren. > > W.S. BDOS+BIOS+Frambeuffer im RAM ist die Standardarchitektur eines CP/M 2.x Rechners. Womit hast Du da ein Problem? Damit sind 55-58K TPA möglich und mehr benutzt kein mir bekanntes, damals kommerzielles Programm. Gruß, Holm
Christian begreift nicht wirklich von was er redet, das ist hier das Problem. Wie soll ein Programm auf einem Z80 größer als 64K werden können wenn der Programmcounter nur 64K adressieren kann? Angesichts der Tatsache das Christian auch keine Lust hat sich mit Maschineninterna aka Assembler auseinander zu setzten und gerne einen "C-Computer" haben möchte bei dem er sich um Details nicht kümmern muß, gibt es keine Lösung für sein Problem. Gruß, Holm
Holm Tiffe schrieb: > Christian begreift nicht wirklich von was er redet, das ist hier das > Problem. > Wie soll ein Programm auf einem Z80 größer als 64K werden können wenn > der Programmcounter nur 64K adressieren kann? > > Angesichts der Tatsache das Christian auch keine Lust hat sich mit > Maschineninterna aka Assembler auseinander zu setzten Ich schaue mir die Sache von oben her an und wäge ab, ob es sich lohnt sich damit zu befassen. Die Antwort lautet inzwischen: Nein. Als es nur 16 Bit Busse gab mögen sich Generationen von Tüftlern die tollsten Geschichten ausgedacht haben doch mehr als 64kb zu haben. Hier noch ein Gattergrab, da noch eine Bankumschaltung, da eine MMU oder VMU usw. Nimmt man zu den 15 Ax noch ein paar I(O hinzu und dazu einen Treiber kann man das natürlich. Der Tag hat 24h also immer rein in die Trickkiste. Die Thematik ist für mich daher erledigt, mein Z80 bleibt wie er ist, da wird nur noch an dem OS etwas gefeilt und die Relaiskarte gebaut, bzw. die LED Matrix angeschlossen. Irgendwo muss ich auch die Zeit, die ich damit verbringe noch überschauen, die Drohung "Ich oder die Computer!" steht unausgesprochem im Raume. Die von Leo geposteten Sachen habe ich allerdinbgs kopiert, interessante Sache. Auch das Applikationsbuch ist recht spannend. PS: Ich habe inzwischen so einiges an "ASM" erzeugt ....Snippets, Hilfen, Umschaltungen usw. Aber alles nur "unter C". Mich interessiert das Problem eben mehr als die Maschine. Gruss, Christian
Christian J. schrieb: > Holm Tiffe schrieb: > >> Christian begreift nicht wirklich von was er redet, das ist hier das >> Problem. >> Wie soll ein Programm auf einem Z80 größer als 64K werden können wenn >> der Programmcounter nur 64K adressieren kann? >> >> Angesichts der Tatsache das Christian auch keine Lust hat sich mit >> Maschineninterna aka Assembler auseinander zu setzten > > Ich schaue mir die Sache von oben her an und wäge ab, ob es sich lohnt > sich damit zu befassen. Jepp, von oben halt. Wie Gott ... :-) >Die Antwort lautet inzwischen: Nein. Als es nur > 16 Bit Busse gab mögen sich Generationen von Tüftlern die tollsten > Geschichten ausgedacht haben doch mehr als 64kb zu haben. Hier noch ein > Gattergrab, da noch eine Bankumschaltung, da eine MMU oder VMU usw. > Nimmt man zu den 15 Ax noch ein paar I(O hinzu und dazu einen Treiber > kann man das natürlich. Der Tag hat 24h also immer rein in die > Trickkiste. > > Die Thematik ist für mich daher erledigt, mein Z80 bleibt wie er ist, da > wird nur noch an dem OS etwas gefeilt und die Relaiskarte gebaut, bzw. > die LED Matrix angeschlossen. Irgendwo muss ich auch die Zeit, die ich > damit verbringe noch überschauen, die Drohung "Ich oder die Computer!" > steht unausgesprochem im Raume. Offensichtlich hast Du erneut eine falsche Entscheidung getroffen. > > Die von Leo geposteten Sachen habe ich allerdinbgs kopiert, interessante > Sache. Auch das Applikationsbuch ist recht spannend. > > PS: Ich habe inzwischen so einiges an "ASM" erzeugt ....Snippets, > Hilfen, Umschaltungen usw. Aber alles nur "unter C". Mich interessiert > das Problem eben mehr als die Maschine. > > Gruss, > Christian Christian Du hast Deinen Thread "Aufteilung der Aufgabenverteilung auf ROM und RAM" genannt. Das kommt zu keinem Ergebnis, weil Du keine aufgaben zu verteilen hast. Du hast kein Problem das Du damit lösen willst, Du spielst mit der Hardware und Software. Daran ist nichts Schlechtes, aber es gibt keine Lösung für ein nicht existierendes Problem. Bei Deiner Spielerei hast Du herausgefunden das es eine Grenze des adressierbaren Speichers gibt, die Du durch Deine Entscheidung keine Urladerfunktion zu implementieren noch weiter eingeschränkt hast. Du hast nie CP/M und die Leistungsfähigkeit seiner Programme erlebt um überhaupt beurteilen zu können was man mit 64K RAM alles bewerkstelligen kann und so erscheint Dir das was Du da gebastelt hast als "zu wenig". Klar, das isses ja auch, dafür wars wegen dem Compiler sehr einfach, zumal Du hier ständig die Anderen Deine Probleme hast lösen lassen. Ich weiß was Du hören willst: Deine Hardware ist Klasse! Es gibt Nichts zu verbessern! Dein Menüsystem ist TOP! Schlechte Nachricht: Ich brauche nichts davon. Gruß, Holm
Holm Tiffe schrieb: > Du hast nie CP/M und die Leistungsfähigkeit seiner Programme erlebt um > überhaupt beurteilen zu können was man mit 64K RAM alles bewerkstelligen > kann Ich habe so vieles verpasst vor meiner Geburt aber ich hatte ein Bonanza Fahrrad, viele Dosen "Slime", Zauberwürfel, einen Universum Kassettenrekorder, weiss das Twix mal Raider hiess und ich habe den Kalten Krieg life als Wachsoldat auf einem Sonderwaffendepot (SAS) der Amis miterlebt. Das reicht finde ich, CP/M gehört nicht zu den Erfahrungen. Wir hatten damals Apple ][ und mit dem konnte ich bestens und noch besser mit dem C64. Amen. :-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.