Beiträge von Prodatron

Besten Dank, Andreas! Falls Du es auf 15:00 (45min schätze ich) verschieben könntest, wäre es noch besser, er hat glaub ich Samstag eine Anreise von über 5 Stunden, dann wäre das um 15 Uhr etwas entspannter.

Roelof und ich wir würden zusammen gerne einen Vortrag über den...

Isetta TTL Computer

Isetta TTL computer

This computer is built from simple TTL circuits. There is no microprocessor, microcontroller or FPGA. It can execute 6502 instructions and can on-the-fly…

hackaday.io

...machen.

Das müsste nach Möglichkeit irgendwann Samstag am Nachmittag stattfinden, wenn's noch geht, da er selbst wohl von Samstag mittag bis abends anwesend sein wird.

Der Isetta TTL Computer ist eine Maschine, die keinen Mikroprozessor besitzt, sondern komplett aus TTL-Chips besteht. Einmalig ist wohl, daß er sich mittels Microcode sowohl wie ein 6502 als auch wie ein Z80 verhalten kann. Eine weitere Besonderheit besteht darin, daß er zwar wesentlich leistungsfähiger als der bekannte Gigatron-TTL-Computer ist, aber günstiger in der Beschaffung.

Und - obwohl komplett aus TTLs - ist er SymbOS fähig. Mittels in Microcode realisiertem Blitter läuft das Z80-8bit-Multitasking-Betriebssystem verdammt gut auf diesem 70er Jahre basiertem Minimal-System, in dem es ausser den TTLs keinen einzigen typischen Chip der 80er Homecomputer gibt.

Zitat von Toast_r

EDIT:
Ich glaube, ich bin hier im falschen Thread. Hier geht's wohl um den CPC.
Was ich hochgeladen habe ist BonnyDOS 286.

Wobei das auch ein cooles Projekt war

Zitat von Steckschwein

Das lag in dem Fall wahrscheinlich daran, dass unser Pacman den V9958 im NTSC-Modus und mit einigen Hacks, um auf die nötige Auflösung zu kommen, betreibt. Damit war der Beamer wohl überfordert. Oder der Scart - HDMI - Konverter dazwischen.

Hauptsache eure Podcast-Aufnahme mit unserem Golem-Martin mwo Golem war gut? Freu mich schon auf die Folge mit euch!

Fänd ich ansonsten schön, euch wieder auf der CC oder sogar XzentriX zu sehen!

Klappt mit meinem Android alles super.

Auch die Infos hinter den /table/xx Links sehen alle komplett aus.

Ah danke für die Klarstellung, Hans, und sorry für die falsche Vermutung! Dann hatte ich wohl durch die Sofort-Übernahme des Bildes darauf geschlossen, daß das bei anderen Eingaben auch so wäre.

hans, erstmal super vielen Dank für dieses coole neue Datenbank-.System mit Web-UI!!

Zitat von fachat

Kleines nitpick (jammern auf hohem Niveau): wenn ich mal Save gedrückt habe und dann nochmal was ändere an einem Exponattext wird der Save button nicht mehr aktiv. Ich muss dann den Text kopieren, Seite neu laden, Text pasten und dann nochmal Save drücken...

Hallo Andre, der Save-Button ist deshalb nicht aktiv, weil das nach der "modernen" Vorgehensweise auch für Deppen funktioniert, bei der man Änderungen nicht mehr bestätigen muss, sondern diese sofort gespeichert werden (Ursprung dieser Philosophie kam IIRC von Apple in den 2000/2010ern?). Gibt also keine "Cancel" Möglichkeit mehr, wird einfach alles immer sofort übernommen, auch wenn man quatsch eingegeben hat.

Das ist die "modern" angesehene Vorgehensweise bei UIs (die ich selber komplett bescheuert finde, aber irgendwann dann auch von Microsoft übernommen wurde usw.), aber das hat nichts mit Hans zu tun, sondern ist so heute leider anerkannt.

hans, was ich allerdings übertrieben finde:

Wenn ich von dem Exponate-Editor-Fenster mal kurz in ein anderes Fenster auf meinem Windows PC wechsele (z.B. um weitere Daten zum Exponat nachzuschlagen), dann verdächtigt mich der Editor direkt, daß ich einfach abhauen und meine Eingaben verwerfen will, und ob ich das wirklich vorhabe.

Das ist extremst nervig, ist schon schlimm genug, wenn andere Websites Terror machen, wenn man mal den Mauszeiger aus dem Fenster rausbewegt. Sowas muss man nicht wirklich auch bei sowas einbauen? Ich denk mal, daß das eine Standard-Einstellung von dem Baukasten-System ist, den Du benutzt? Kann man das vielleicht abstellen?

Danke für dieses megatolle Projekt, der CPC war in Sachen interner Speichererweiterung (mal abgesehen von ganz damals Vortex) ein kompletter Aussenseiter, jetzt haben wir sowas dank Dir auch endlich, ich finde das total super und extremst nützlich!

Danke yalsi , das war wieder ein super tolles nettes sympathisches Treffen, ich war total begeistert!

Vielen vielen Dank daß Du das wieder möglich gemacht hast!

Ich hatte einen tollen Austausch mit echt super Leuten, angefangen von Retro-Maschinen, 8bit, Z80, Multitasking bis hin zu BEVs, als wir mal draussen rumstanden, das war ziemlich cool wieder

Mein zweites Hannover-Yalsi-Treffen, ich komm wieder, keine Frage. Nun freu ich mich jedenfalls auf die nächsten Events in diesem Jahr.

Das funktioniert ja wunderbar!

Der Einbau in den 664 war auch viel einfacher als in den 6128, weil viel mehr Platz, kein Schutzblech usw!

Soweit klappt alles wunderbar, vielen Dank eto für diese super Hardware!

Jetzt hab ich ein paar Todos vor mir:

- Software mit #C3 mode testen

- PALs ohne #C3 mode testen

- Floppy Riemen muss auch mal wieder neu

- Tastatur-Folie ersetzen (gehen ein paar Tasten nicht, typisch 664)

Oh gut, dann sollte es ja halbwegs passen, oder?

D.h.

MarkL

nalkem

jpsaf

kriegen noch einen Tisch? Wie gesagt, ich kann noch einen Klapptisch mitbringen, wenn das noch irgendwie in den Raum passt, dann hätten ja sogar alle einen.

Vielen Dank, freu mich voll!

Sorry Georg für die kurzfristige Anmeldung und die Umstände! Das kam jetzt etwas spontan, und der Axel ist das schuld Habe das jetzt jedenfalls fest eingeplant, hoffe, es passt noch irgendwie.

Ich kann auch noch nen Klapptisch mitbringen.

Zitat von nalkem

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

Zitat von gnupublic

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:

https://youtu.be/0FEoEv5Kpes

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...

Zitat von tofro

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.

Zitat von TFM

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)"):

MSX I/O ports overview

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
[...]

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.

Zitat von funkenzupfer

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

Zitat von funkenzupfer

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?

Zitat von tofro

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.

Zitat von tofro

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

Zitat von horo

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)