Ggf kann man sich dann auch das Problem mit dem starten anschauen.
Das wäre definitiv eine super Gelegenheit!
Ggf kann man sich dann auch das Problem mit dem starten anschauen.
Das wäre definitiv eine super Gelegenheit!
Ich möchte mich hiermit als Besucher anmelden, wobei es nett wäre, wenn ich mich ab und zu mit Notebook irgendwo noch in eine Ecke quetschen könnte, Stuhl kann ich selber mitbringen.
Falls nalkem seinen CPC mitbringt, könnten wir dann ein bischen schnacken und Hardware-Erweiterungen ausprobieren und so.
Schneider TexPack
Vor 13 Jahren hast Du (oder wer auch immer) auf das Wort genau den selben Satz hier gepostet, nur mit anderem Nick. Ich finds lustig aus vielen Gründen
Leider kenn ich ausser dieser Infoseite nichts näheres:
https://cpcrulez.fr/applications_bureau-texpack.htm
Im VCFED Forum verstecken sich mehr Leute als hier im deutschsprachigen Forum. Die meisten sind aber auch da passiv. Stellt man einen Artikel ein, ist der nach zwei Tagen etwa 40 mal gelesen, so im Schnitt. Könnte mir vorstellen die Zahl gibt die spezieller PDP8 Interessierten wieder. Aber es gibt eine harten Kern der sehr sehr fleissig ist und einen Menge Sachen macht. Allen voran Vince Slynstad mit Seiner Seite und David Gesswein mit seiner Seiner Seite. Ohne die Leistung Anderer abzutun, haben beiden sehr viel Informationen systematisch zusammengetragen. Das ist schon toll. Immer wenn es mir gelingt etwas unbekanntes an Software zu bekommen, liefere ich beiden zu.
David Gesswein hat lauter Images von Bändern, Disketten und Festplatten, die zum Stöbern einladen Hier. Gerade auch für Simulatoren finden sich da eine Menge Futter für lange Winterabende.
Der Z80 Simulator, liefe der auch auf einem Kaypro II? Eventuell wäre das ja ein spannendes Thema, Simulatoren auf fast zeitgleichen Geräten zum Original auf der CC vorzuführen?
Oder um es auf die Spitze zu treiben, einen PDP8 Simulator auf einer DECMATE II (auf deren Z80 Erweiterung) laufen zu lassen. Eine PDP8 Simulation auf einem der ganz späten PDP8 Rechner.....
Vielleicht machen wir da ein Projekt draus?
Deine Links sind super, ich kann da jetzt erstmal ewig rumstöbern und tolles wissenswertes Zeugs aufsaugen!
Der Kaypro II ist ja "erst" von 1984, wie meinst Du "zeitgleich" zum Original? Das sind ja eher fast 20 Jahre Unterschied, oder meinst Du nicht die PDP-8 sondern den Amstrad CPC bzw die anderen Z80 Rechner?
Aktuell läuft SymbOS und damit auch der PDP-8 Emulator auf folgenden Rechnern:
- Amstrad/Schneider CPC
- MSX 1/2/2+/TurboR
- Enterprise 64/128
- Amstrad/Schneider PCW/Joyce
- Amstrad NC100/200
- ZX Spectrum Next
- SymbOSVM
Alte "typische" CP/M Maschinen sind nicht dabei, weil sie entweder keine Bitmap Grafik (2 Farben reichen, am besten 256x192 oder mehr) und/oder kein flexibles Speicherbanking für mehr als 64K haben.
Prevtenet hat seinen PDP8-Emulator aber veröffentlicht, ich muss das nochmal raussuchen, das wichtigste ist die komplette optimierte PDP8-CPU-Emulation in Z80 Code.
Man kann nun den PDP8-CPU Emulator in Z80 getrennt rausnehmen und damit einen kompletten Emulator ohne das SymbOS Multitasking-Betriebssystem bauen, d.h. man läßt dann die grafische Darstellung von dem Bedien-Panel mit all den "Blinkenlights" weg und macht den Teletype Input/Output mit einem normalen Textscreen.
Ich such mal hierfür morgen die Dateien raus.
Vor einigen Wochen hat Prevtenet (USA) einen PDP-8 Emulator für Z80 Maschinen herausgebracht:
Ich selber hatte prominent immer nur die PDP-11 in Erinnerung, aber durch dieses neue PDP-8 Projekt hab ich mich mal endlich intensiver mit der ganzen Mini-Computer-Geschichte von DEC auseinandergesetzt und dadurch auch rausgefunden, wie cool bereits die PDP-8 ist.
Aus dem Grund musste ich auch mal ein Video machen, allerdings ist der Ton verkackt, daher einfach nur so zum Gucken geeignet:
Das Projekt ist als SymbOS App in SCC entwickelt worden (SymbOS C Compiler), der Quelltext ist Opensource bei Github, die PDP8-CPU Emulation ist in recht optimiertem Inline Z80 Assembler implementiert (nur ein paar ganz winzige Optimierungsmöglichkeiten habe ich gefunden : ) )
Was mich dann beim Testen des ganzen Paketes wirklich fasziniert hatte, ist, wie einfach man mal eben so in Focal programmieren kann! Das ist ja echt der knaller und für mich definitiv ein absolut würdiger "Basic Vorgänger".
Was ich mich nun frage ist:
Gibt es eigentlich noch PDP8-Communities? Ich bin Fan vom Mitglied "GnuPublic" hier im Forum und seinen PDP Videos.
VG,
Prodatron
Habe das iRAM gestern nacht noch in meinen Ur-CPC eingebaut. Absolut fantastisch, wie gut sie reinpasst und wie einfach es ist, selbst für eine Hardware-Null wie mich.
Übrigens passt sie auch unter das zusätzliche Abschirm-Blech, welches nur in deutschen CPCs verbaut ist!
Z80 rausgehebelt:
Aufs iRam drauf und das ganze wieder auf den CPU-Sockel drauf:
Funzt ausgezeichnet:
Besten Dank, Eto, für dieses super Projekt und all die Arbeit damit!!
Damit ist ein großer Traum, einen CPC mit genug Ram zu haben, ohne daß man dafür hinten was dranhängen muss, endlich in Erfüllung gegangen!
Normalerweise kommt der Termin immer so im März/April.
eto, super cool, hätte auch Interesse an einem Set...
Wir werden das wohl nicht mehr lösen, es sei denn, es findet sich jemand, der die Leute, die das verbrochen haben, direkt befragen kann.
(auch funkenzupfer )
Haben eine Antwort von Federico Faggin bekommen:
Frage: "16bit I/O addresses were an official feature of the Z80, but it required the B register as well (or even A), so some opcodes were not usable; wasn't the Z80 designed for 16bit I/O addresses, but later you found out, that it's working as well, and so you added it to the documentation?"
Faggin: "I do not remember precisely, but I think that if those instructions were in the early documentation (prior to 1981, the year I left Zilog as CEO), those instructions were not an accident. To my knowledge we did not document any of the spurious instructions that were not intentional but a consequence of the way the CPU control was designed."
Laut dem Vater des Z80 ist dessen 16bit I/O Fähigkeit wohl kein Unfall gewesen, soweit er sich noch erinnern kann.
Also, ich bin echt froh, dass der CPC mit 16 Bit I/O arbeitet. Die 256 Ports bei anderen Z80 Rechnern sind schnell verbraucht, vor allem wenn man dann noch nicht komplett dekodierte Schatten-Ports hat.
Die Erweiterungen am CPC nutzen heutezutage schon mehr als 256 Ports, da ist es schön wenn Platz ist.
Wieso froh?
Wie gesagt, 16bit I/O kann jeder. Auch andere Z80 Rechner wie MSX, PCW, Enterprise etc. Die sind also alle froh
Das ist kein Vorteil beim CPC, sondern eine Beschränkung.
Denn die meisten anderen müssen es nicht zwingend machen. Der MSX hat sogar einen Standard, bei dem ein Bereich innerhalb der 256 Ports für multiple Erweiterungen benutzt werden kann, siehe hier ("Expanded I/O ports (a.k.a. switched I/O)"):
Damit können dann trotz 8bit I/O Adresse nochmal 256*15 extra Ports verwendet werden.
Wie gesagt, auf dem CPC und ZX Spectrum geht's gar nicht anders, da sind die 16bit I/Os der offizielle Weg.
So sieht z.B. ein Teil einer Sektor-Lese-Routine für ein IDE Interface aus:
ld bc,ide_data
ld a,16
[...]
iominp1
ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b
ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b
ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b
ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b:ini:inc b
dec a
jr nz,iominp1
[...]
Alles anzeigen
Ob man das jetzt als Krücke bezeichnet, ist eine persönliche Sache, jedenfalls geht's so am schnellsten (160KB/s Datendurchsatz) auf dem CPC.
Und warum zählen jetzt die Comments für Dich nicht zur Dokumentation? Zilog hat es schwarz auf weiß da stehen, daß B für die oberen 8bit benutzt wird.
Bitte nicht mit den undokumentierten 8bit-Indexregistern gleichstellen, die waren nunmal wirklich nicht dokumentiert
Danke für den Link, also Ankündigung Februar 1977, Produktionsstart Mai 1977. Dann könnte das aber Sinn machen, daß die Dokumentation auch von 1977 ist.
Wenn 5 Opcodes nicht brauchbar sind, was geht denn dann?
Folgende Opcodes gehen auch mit 16bit I/O:
IN A,(n)
IN r,(C)
OUT (C),r
INI, IND
OUTI, OUTD
Folgende Opcodes gehen nicht mit 16bit I/O:
OUT (n),A (außer man hat Glück)
INIR, INDR
OTIR, OTDR
Wenn es geplant war, warum wurde es nicht dokumentiert ?
Auf welche Dokumentation beziehst Du Dich eigentlich? Zumindest schon 1977 wurde die 16bit I/O Fähigkeit vom Z80 von Zilog offiziell dokumentiert.
Siehe z.B. hier:
http://www.bitsavers.org/components/zilog/z80/03-0029-01_Z80_CPU_Technical_Manual_1977.pdf
Seite 54, bzw. im PDF ist es die 60; siehe "Comments".
Ich würde das jetzt nicht so deuten, daß erst "Hacker" rausfinden mussten, was mit den oberen 8 Bits los war.
Die Dokumentation von 1977 enthält lediglich noch die fehlerhafte Beschreibung der B-Register-Dekrementierung beim OUTI Befehl, aber das hat jetzt nicht wirklich was mit der 16bit I/O Fähigkeit zu tun.
Im Mai habe ich Federico noch persönlich getroffen, hätte ich ihn das mal gefragt
*EDIT* Ich sehe gerade, daß in der Dokumentation zwar 1977 steht. Allerdings nennt sie auch den Z80A. Wann kam der Z80A eigentlich raus? Vielleicht ist die gar nicht von 1977 und in den Dokus vorher wurde B für A8-A15 nicht erwähnt?
Sonst wüsste ich eigentlich keinen Rechner, der das obere Byte verwendet.
Interessant eigentlich, gab's vorher keinen "kostenreduzierten Z80 Rechner", wo man zum Dekodieren der I/O Port-Adresse nur ein einziges Bit oder so genommen hat, um Kosten zu sparen? Oder kamen die anderen dann trotzdem alle mit den unteren 8bit klar?
Aber auch die können ja (notfalls) auch alle 16bit I/Os. Der 16bit Adressbus ist ja eh da. So werden z.B. beim Amstrad PCW (Schneider Joyce) die oberen 8bit genutzt, um MSX Hardware mittels dem Amsdap-Adapter reinzumappen, in dem man die #xx Ports vom MSX auf #xxB0 beim PCW remapt.
Und das ist genau das, wovon der CPC (im Gegensatz zu vielen anderen Z80-basierten Rechnern) intensiv Gebrauch macht. Das macht auch den OUT (imm),A - Befehl ein bißchen obsolet - Denn der Z80 legt den Inhalt des Akkumulators nicht nur auf den Port, sondern auch auf die oberen Addressbits, was auf dem CPC dafür sorgt, dass der angesprochene Port vom Ausgabewert abhängig ist.
Das stimmt, deswegen kann man auf dem CPC auch nur IN A,(n) halbwegs vernüftig verwenden, wenn man vorher A für das Highbyte definiert.
Ja, beim ZX Spectrum und CPC waren Sparfüchse mit dabei, deshalb muss man 16bit I/Os machen und kann weder OUT (n),A noch die INIR/OTIR Befehle verwenden.
Was aber nicht heisst, daß der Z80 nicht für 16bit I/O vorgesehen war, und sowas nur ausversehen geht!
Ich denk mal schon, daß Faggins Truppe das schon vernünftig und optimiert geplant hat, denn 16bit I/O mit dem Z80 ist absolut kein Problem, lediglich etwa 5 Opcodes sind nicht brauchbar.
Übrigens ist auch in meinem geliebten DDR-U880 Buch von Ludwig Claßen (1981; wird bis heute benutzt) das mit dem B bei OUTI noch falsch dokumentiert, obwohl es auch der U880 genau wie der Z80 macht
Z80 hat ein paar Opcodes mit überraschendem Verhalten
Wo es hier eh schon um die IN/OUTs ging, was ich auch nie verstanden habe, ist das "überraschende" Verhalten beim OUTI Befehl:
- INI: (HL)=port(BC), HL++, B--
- OUTI: B--, port(BC)=(HL), HL++
Weiß jemand, warum bei OUTI das B Register VORHER dekrementiert wird?
(als CPCler ist man auf diese beiden Befehle durchaus angewiesen, weil man hier immer mit 16bit I/O-Adressen arbeiten muss und durch unrolled Loops damit schnelle Block-I/Os machen kann)
Gelegentlich auch mal ein Bild vom Sprecher, wenn der das überhaupt wünscht.
Seit dem ganzen DSVGO Kram kenne ich Veranstaltungen, bei denen im Eingang ein Hinweis hängt a la:
"Wenn Du hier reingehst, stimmst Du zu, daß jeder Bilder von Dir machen und diese auch öffentlich publizieren darf. Wenn Dir das nicht passt, dann bleib einfach draussen!"
(ich meine genau sowas z.B. auf der Revision-Demoparty dieses Jahr gesehen zu haben)
Ich finde das völlig ok. So eine Veranstaltung ist öffentlich, und man will definitiv Fotos machen, nicht nur von den Kisten, sondern auch vom Gesamten, und da sind nunmal auch die Leute drauf, weil die fest dazugehören.
Kein Ahnung, ob so ein Eingangsschild rechtlich schon ausreichend ist.
PS: Wo ist der Thread mit der entsprechenden Diskussion?
Ich komme gerne wieder, gerne auch mit dem ein oder anderen Steckschwein im Gepäck!
War richtig cool euch endlich mal wieder zu treffen, wenn auch etwas knapp vorm (unserem) Schluss!
Die MENSCHEN! Gerne wieder, vielen Dank für diese geniale Veranstaltung.
Die CC war wieder sowas von klasse, für mich war das wieder eine einzige Berauschung, auch ohne BTMs
Unser Verein ist einfach der geilste, ihr seid die besten, ohne Frage!
( CBM_Ba , danke übrigens für den zum Nummernschild passenden MOS Aufkleber )
Hier meine Video-Zusammenfassung zur Classic Computing 2024:
Was für ein super Übersichts-Video, vielen Dank dafür!!
Die CC2024 war wieder sowas von toll, vielen vielen Dank an ALLE!!!
Es war wieder sowas von super mit euch!
Der Samstag Abend war erneut der Knaller, mit Christian, Norbert und co. als die besten Entertainer und Salesman bei der Versteigerung
Aber das war nur eines von den vielen Highlights. Meine Bilderauswahl ist etwas fokussiert, aber es war einfach super wieder!
Ich habe noch Multiplan, den Vorgänger von Excel für den Ti 99/4A.
Diskette und Modul.
Kannst Du das mitbringen und zeigen???
Oh bitte bitte! Da ich gerade selber an dem Thema arbeite (Excel-like für Z80), wäre das megacool zu sehen!
Bin sowas von voll zufrieden mit dem Plan, bitte nichts mehr ändern
Man bräuchte auch relative Unterprogrammaufrufe. [...] Und der Zugriff auf die Daten muss auch komplett relativ erfolgen.
Mittlerweile gibt es mehrere Assembler, die eine Relocator-Tabelle mitgenerieren können.
Bekannt sind mir SJAsm+ und der eingebaute im WinApe CPC Emulator, bei dem ich das selber nutze.
Der Trick ist, daß das Programm einfach 2x assembliert wird, beim zweiten mal an eine versetzte Adresse. Dann vergleicht man beide Binaries und findet genau die Stellen, die reloziert werden müssen, und kann deren Adressen in eine Tabelle schreiben. Das klappt wunderbar.
Welcher Prozessor aus dieser Zeit kann das?
Mitte der 70er wohl noch keiner, aber ab 1978 dann die x86er, die das ja quasi vollständig über die Segmentregister können.
Bei den 8bittern kenne ich nur den Motorola 6809, bei dem es das Ziel war, Code vollständig positionsunabhängig zu schreiben (aber das hat jetzt nichts mit CP/M zu tun ).
Schon krass die Reaktionen hier.
- Von begeistert wie RetroShare (das Beispiel ist aber auch echt geil!)
- über Leute, die es nüchtern als gutes neues Tool sehen wie Hans Hübner, Detlef und viele andere
- bis zu hardcore-wütend-schaum-vorm-mund-aaarrrgg-ichdrehdurch Typen wie ***, deren Kommentare (ziemlich am Anfang vom Thread) schon fast belustigend wirken
Weiß übrigens nicht, was das neue KI/LLMs usw. Zeugs mit finanz-bezogenen Hypes wie Bitcoin usw. zu tun haben. Nur weil was neues bei vielen gut ankommt, ist es nicht automatisch schlecht. Finanzspekulationen erledigen sich früher oder später immer von selbst, neue nützliche Technologien bleiben.
VIELEN Dank für die Info!
Werde am Samstag dort sein, habe Tickets besorgt.
Für mich war es Ende der 1980er herum unvorstellbar, daß Commodore jemals pleite gehen könnte.
Erst hatten sie den unfassbar erfolgreichen C64, dann den unglaublich fortschrittlichen und traumhaften Amiga rausgebracht.
Als Laie hatte ich damals gedacht, Commodore wäre ein unschlagbarer Monopolist, der immer die besten Rechner bringt.
Wie konnten da andere überhaupt eine Chance haben?
Absurd wurde es dann, daß "mein" Amstrad 10 Jahre länger als Commodore lebte, und auch nicht pleite ging, sondern einfach nur irgendwann aufgekauft wurde, und der Chef heute einer der reichsten Engländer aller Zeiten ist.
Richtig verstanden habe ich das dann alles erst, als ich das wirklich coole Buch "VolksComputer" (GamePlan, von Brian Bagnall) gelesen hatte.
Egal wie groß und erfolgreich man ist, es kann einen immer erwischen, wenn man Mist baut oder keine Lust mehr hat.