PDP11 KL11 SLU in altem CPLD?

Holm T. schrieb:
> kann Jemand bitte in etwa abschätzen ob und wie das klappt den
> vorhandenen VHDL Code von Sytse van Slooten (PDP2011) mittels einem
> alten 5V CPLD in einen funktionierenden Peripheriechip zu verwandeln?
Habs mal ausprobiert: in keines der 5V Xilinx-CPLDs passt das Design 
(die Toolchain hat es ausprobiert bis zum XC95288 im BG352 Gehäuse:

1

...

2

Considering device XC95288-10-BG352.

3

Re-checking device resources ...

4

ERROR:Cpld:837 - Insufficient number of macrocells. The design needs at least

5

   356 but only 288 left after allocating other resources.

6

Device 95288352 was disqualified.

7

...

Es wird in diesem Design einfach zu verschwenderisch mit den Ressourcen 
(Flipflops) umgegangen...

Das hier ist auch sehr suspekt und kurios:
      have_kl11 : in integer range 0 to 1;
      have_kl11_force7bit : in integer range 0 to 1;
      have_kl11_rtscts : in integer range 0 to 1;
      have_kl11_bps : in integer range 1200 to 230400;
Hat der Originalbaustein tatsächlich Integer Eingänge für die 
Baudrate?

Aber auch sonst: dieses Design hat laut Report 88 Eingänge und 29 
Ausgänge. Ist das nicht ein wenig zu viel?

Holm T. schrieb:
> Die Baudrate wird IMHO über Jumper eingestellt
Wie viele Jumper sind das?
Gibt es da nur die "Standardbaudraten" und damit nur 3..4 Eingänge?

> mit integer haben die natürlich Nichts zu tun.
Dieser  have_kl11_bps mit seinem range 1200 to 230400 "verbraucht" 
immerhin 18 "Eingangsleitungen"...

Holm T. schrieb:
> Wenn 288 Makrozellen nicht reichen
Für die skizzierten Anforderungen dürfte das tatsächlich schon ein wenig 
sportlich werden. Mit einer passenden externen Taktfrequenz könnte es 
aber wieder gehen.
> Das eigentliche Device hat 16 Bit Daten und gemultiplext Adreßeingänge
> sowie 4 Register (Sende/Empfangsdaten sowie Status lesen/schreiben) pro
> Kanal...und 2 Kanäle.
Das sind gerade mal 4x8 Bit, wobei offenbar das RX und das TX Register 
nochtmal gepuffert sind. Also ergo 48 Flipflops. Dazu noch ein paar 
interne Flags und ein paar kleine FSM. Das wären dann z.B. 80 Flipflops 
pro Kanal. Der Bus braucht auch nochmal 30 Makrozellen. Fazit: das müsst 
eigentlich bei durchdachter Beschreibung schon gehen...
Immerhin bekomme ich eine komplette RS232 IO in ein 36er CPLD:
http://www.lothar-miller.de/s9y/archives/60-RS232-IO.html

Aber der verlinkte Code sieht sowieso ein wenig, naja, "laienhaft" aus, 
denn die Sensitivlisten sind allesamt falsch: sie enthalten zu viele 
Signale.  :-o
Das ist für mich ein ernstes Warnzeichen...

> Wie kann ich das selber ausprobieren
Neues Projekt --> neues VHDL-Modul --> dort hinein den Quellcode 
kopieren --> Settings bei Device-Option auf XC9500 Serie und Device auf 
"Auto"

Holm T. schrieb:
> Edit: Hier ist noch so ein Ding:
> Wie sieht das damit aus?
Da ist mehr Arbeit nötig, weil selbstdefinierte Typen verwendet werden 
slbit, slv2, slv8 usw...

Mit russischen IC kenn ich mich nicht aus aber ich habe hier ein M8047 
IO-Modul und da ist für die Console ein Intersil 64S004B in DIL40 
verbaut.

ps. Das komplette Multi Modul hat insgesammt nur 50 Pin.

Holm T. schrieb:
> Oder soll ich besser Dein Zeug verwenden?
Sagen wir mal so: wenn ich nur eine serielle Schnitte bräuchte, dann 
würde ich an eine meiner SIO an einen gemultiplexten Bus koppeln.

Und die Sache mit dem Hardware-Handshake und dem Interrupt bei 
Gelegenheit oder Not dazubasteln...

Als Basis für dieses Interface wäre vermutlich das hier geeigneter:
http://www.lothar-miller.de/s9y/categories/42-RS232

Ein DC319 wäre zwar ideal, denn der implementiert ein DLV11 in einem 
chip, aber die sind sehr schwer zu finden. Nicht einmal digital hat sie 
standardmässig auf allen DLV eingesetzt. Ich stand vor dem gleichen 
Problem als ich meinem DCJ11 (J-11) vor 2 Jahren leben einhauchen wollte 
und bin dabei auf folgende Seite gestossen

http://www.cs.ubc.ca/~hilpert/e/pdp11hack/index.html

und habe mehr oder weniger das gemacht, ausser dass ich statt dem TTL 
Hühnerfutter ein GAL genommen habe. Ganzen unten auf der Seite gibt es 
noch Infos zu meiner ersten Version. Für ODT reicht das. Der zentrale 
Baustein für den UART ist ein CDP6402 der auch oft auf DLV11 von digital 
und Dritthersteller zu finden ist. Den CDP6402 findet man auch öfters 
noch angeboten. Im Moment plane ich den Ausbau von meinem Projekt und 
möchte den J-11 via CPDL (ATF1504AS) mit dem CDP6402 verbinden und so 
die fehlende Interrupt Logik nachbauen. Sollte kein Problem sein.
Es gibt übrigens DVL11 mit programmierbarer Baud-Rate DLV11-E und -F 
können über Bit12:15 im XCSR (Transmitter Control und Status Register) 
die Baud-Rate setzen. Es muss also nicht immer ein serieller Multiplexer 
sein.

http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/qbus/EK-DLV11-OP-001_DLV11-E_and_DLV11-F_Asynchronous_Line_Interface_Users_Manual_Jun77.pdf

Gruss

Peter

Viele ältere Versionen brauchen noch -12V oder -9V, der AY3-1013 braucht 
noch eine negative Spannung. Der AY3-1015 braucht keine. Ich habe mir 
dazumal den CDP6402 zugelegt weil er erstens nur 5V braucht und zweitens 
schafft er auch 115200baud.
Eine programmierbare baud-rate ist tatsächlich nebensächlich, ich wollte 
nur bemerken, dass es das sehr wohl gab.
Im Moment habe ich das Projekt gerade wieder aufgegriffen. Bin gerade 
daran die GLUE Logik in ein CPLD zu packen. Vor einem Jahr hatte ich 
schon mal Byteweises Schreiben in den Speicher hinzugefügt aber jetzt 
will ich noch BUS Timeout, Interrupt ACK, DV Signal und DMA support für 
ein einziges IO Gerät hinzufügen. Mit GALs und TTLs Bausteinen wird das 
alles viel zu unübersichtlich, ein kleines CPLD ist da super.

Gruss

Peter

Also hier mal der erste Entwurf des CPLDs. Zuerst aber ein paar Worte 
zur Wahl des CPLDs und der Tools. Ich habe erst vor kurzem mit CPLD 
Design begonnen. Die Hauptanforderung für mich waren 5V Unterstützung 
und sie sollten Designs mit drei bis fünf GALs ersetzen. Und da gibt es 
eben nicht mehr sehr viele, meines Wissens produziert nur noch Atmel 
(oder sollte ich schon Microchip sagen) 5V CPLDs. Damit war auch schnell 
klar dass ich als Toolchain WinCUPL nehmen musste, die anderen kosten 
leider viel zu viel für das was ich sie brauche. Für die GLUE Logik 
eines J-11 scheint aber schon ein ATF1504 zu genügen. Ein Schema dazu 
ist am entstehen.

Gruss

Peter

Hallo Holm,

für die ATF1504 brauchst du dann auch ein entsprechendes 
Programmierkabel, am besten eines mit USB, das ATDH1150USB. Damit kann 
man die ATF15xx via WinISP von Atmel  via ISP programmieren. Wichtig 
ist, dass man im Design File auch die ISP Variante angibt sonst benutzt 
WinCUPL die IPS Pins u.U. als IO pins, aber danach kann man die ATF15xx 
nur noch mit einem sehr proprietären Protokoll programmieren. Atmel gibt 
sich da sehr bedeckt.

Im Moment bin ich auch daran den Code für ein weiteres CPLD zu 
entwickeln damit aus dem CDP6402 (oder irgendeinem anderen 
funktionsgleichen Chip den du hast) so etwas wird, dass es vom J-11 als 
DLV11 benutzt wird mit Interrupt und und allem. Für den Testaufbau auf 
dem Breadboard. Man kann ja den J-11 auch "nur" mit 8-10MHz betreiben, 
wobei der erste Testaufbau auch mit 18MHz stabil lief. Vorausgesetzt das 
RAM hat eine Access Time von 70ns oder weniger. Ich werde für den 
nächsten Test AS6C4008-55 nehmen, die gibt es als DIP-32 Version, liegen 
bei mir herum und sind mit 55ns schnell genug. Für den Aufbau im 
Breadboard verwende ich Adapter für die ATF1504 in TQFP-44 (siehe Bild)

Gruss

Peter

Holm T. schrieb:
> Parallelport-Version?
Siehe den alten Beitrag "ATF15xx Programmer"

Hallo Holm,

ja da sieht man's. Ich habe einen Mac und dort sind die Aussichten auf 
einen Parallelport düster bis dunkelschwarz. Daher habe ich überall die 
USB Versionen im Einsatz.
Natürlich wenn man einen Windows PC mit Parallelport hat dann erweitert 
sich das Angebot stark. AtmIPS (die ISP download software von Atmel) 
unterstützt die Parallelportkabel ByteBlaster, ByteBlaster II und 
ByteBlaster MV. Das kann man auch selbst bauen, ein 74LS244 reicht ja.

Danke für das Angebot. Ich habe selbst eine ganze Schachtel ATF1504 und 
ich arbeite lieber mit TQFP-44, da spart man dann auf der Platine 
richtig Platz und mit meinem Adapter ist das auch auf dem Steckbrett 
sehr platzsparend. TQFP-44 löten geht auch ohne Vorkenntnis, bei mir hat 
das auf Anhieb geklappt. 0.8mm Pinabstand ist locker handhabbar, auch 
wenn ich dazu eine Lupebrille tragen muss. Wichtig ist gutes Licht und 
viel Flussmittel. Und dann geht das auch mit einer 2.4mm Meisselspitze.

Ich habe mir gerade ein zweites Steckbrett zusammengestellt um die 
Version mit den CPLD aufzubauen. Wobei diese Woche wird das nichts mehr 
und danach geh ich 2 Wochen in die Ferien. Wird wohl eher März bis ich 
dazu komme.

Gruss

Peter

Ja das habe wohl missverstanden. Ich komme gerne auf dein Angebot zurück 
wenn mein Prototyp mal äuft. Im Moment warten bei mir drei J-11 auf eine 
Aufgabe und als erstes will ich mal ein Proof of Concept mit den 
vorgesehenen ATF1504 machen. Also ein vollständiges Memory Interface und 
eine DLV kompatible Console. Neulich bin ich auf diese Webseite 
gestossen

http://www.chdickman.com/qbus_ide/

Das wäre vielleicht die Lösung für den Massenspeicher, da ich ja keinen 
richtigen Q-Bus implementiere ist es vor allem der IDE Driver, weil das 
ganze ist ja nichts anderes als ein durchreichen des ATA Register Files 
zum Q-Bus und da das Daten Interface von IDE auch 16-bit muss ich nur 
einen Teil seiner Logik umsetzen. Wenn man dann anstelle einer IDE Disk 
eine CF Card nimmt und noch eine LTC baut könnte man damit vielleicht 
eine PDP-11 mit minimalen Abmessungen und Stromverbrauch bauen (der J-11 
wird bei 15MHz nur Handwarm). Die CPLD dürften dann die grössten 
Stromfresser sein.

Genau wegen den Lochrasterplatinen und den Steckbrettern habe ich ein 
paar ATF1504 im TQFP-44 auf diese Adpaterplatinen gelötet. Das braucht 
weniger Platz als die üblichen Adapter, ausser evtl. diese hier,

http://www.technologicalarts.ca/shop/store/category/55/adapters/plcc.html

die sind was den Platzbedarf auf Steckbrettern anbelangt für die Anzahl 
der herausgeführten Pins natürlich unschlagbar.

Wie machst du das jetzt mit der Programmierung der CPLD? Ich benutze 
eine virtuelle Maschine mit Windows XP auf dem Mac. Einen ISP Programmer 
für ATF1504 der unter Linux funktioniert ist mir noch nicht begegnet. 
Ich denke auch unter Linux dürfte die virtuelle Maschine das einfachste 
sein und dann empfiehlt sich wieder der USB Adapter, denn USB ports kann 
man in VMs meist durchreichen.

Gruss

Peter

Hallo Holm,

ja ich dachte mir schon dass du einen K1801VM2/3 meinst, vor allem mit 
dem aus Russland inspirierten IDE Adapter wäre was eine schöne 
Kombination. Das Steckbrett ist auch nur vorübergehend. Dass die 
Schaltungen dort bleiben ist bei mir eher nicht. Dort geschieht nur das 
Proof of Concept. Das liegt daran, dass mir während der Entwicklung 
immer wieder neue "Vereinfachungen" einfallen und die dann jedesmal 
löten zu müssen überleben die Lötpads von Lochrasterplatinen nicht 
immer. Das Ziel bei mir ist ein Funktionsfähiger PDP-11 und mindestens 
Unix oder RT-11 muss darauf laufen. Einen RSX-11M+ Driver für den IDE 
Adapter zu schreiben dürfte mehr Aufwand sein. Wenn ich Zeit habe klemme 
ich mich dahinter, schliesslich habe ich vor 30 Jahren selbst 
Hardwaretreiber für RSX-11M/M+ entwickelt.

Ich dachte mir fast, dass du noch einen alten Windows/XP PC hast. Ja 
dann ist definitiv die Lösung mit dem 74LS244 die günstigeste, die Atmel 
Software ist ja eh nur auf alten Windows Versionen funktionsfähig, auch 
ich habe in der VM nur XP. Wenn das Altera Parallekabel ein Byteblaster 
ist dann musst du gar nicht weiter suchen/basteln. Die Atmel ISP 
download software unterstützt ganz offiziel Byteblaster, Byteblaster II 
und Byteblaster MV Parallelkabel von Altera.


Gruss

Peter

Hallo Holm,

Interrupts haben so ihre Tücken, vor alle sollte man den Stack Pointer 
auf einen gültigen Wert setzen wenn man mit Interrupts arbeitet. Aber 
das "DLV-11" aus ATF1504AS und CDP6402 macht Fortschritte. Man könnte 
sicher auch ein grösseres CPLD nehmen und den UART gleich integrieren, 
aber zum Testen ist ein funktionierender UART weniger fehleranfällig.
Folgendes Progrämmchen produziert für 030 (dezimal 24) Zeichen ein Echo 
auf der Console und dann ist wie vorgesehen Schluss

1

RCSR  = 177560

2

RBUF  = 177562

3

XCSR  = 177564

4

XBUF  = 177566

5

  .asect

6

  .=60

7

  .word  rxirq

8

  .word  340

9

  .word  rxirq

10

  .word  340

11

12

rxirq:  mov  @#RBUF, @#XBUF

13

  inc  @#rcount

14

  rti

15

txirq:  inc  @#tcount

16

  rti

17

  .=660

18

  .word  0,0,0,0,0,0,0,0

19

stack:

20

  .=1000

21

22

start:

23

  mov  #stack, sp

24

  clr  @#tcount

25

  clr  @#rcount

26

  bis  #100, @#RCSR

27

10$:  mov  @#rcount, r0

28

  cmp  r0, #30

29

  blt  10$

30

  halt

31

  halt

32

33

rcount: .word  0

34

tcount: .word  0

D.h. das CPLD generiert einen receive character interrupt und antwortet 
beim IACK mit der richtigen (060) Vector Adresse. Jetzt muss ich noch 
den transmit interrupt einbauen und testen, dann poste ich mal das 
Projektfile des CPLD.

Gruss

Peter

Hallo Holm,

ich glaube du musst die Baustelle hervorkramen. Der TX Interrupt läuft 
jetzt auch. Der code (label txtest) im folgenden Code spuckt ein "Hello 
World" im Interrupt Handler aus.

1

RCSR  = 177560

2

RBUF  = 177562

3

XCSR  = 177564

4

XBUF  = 177566

5

  .asect

6

  .=60

7

  .word  rxirq

8

  .word  340

9

  .word  txirq

10

  .word  340

11

12

rxirq:  mov  @#RBUF, @#XBUF

13

  inc  @#rcount

14

  rti

15

  nop

16

  nop

17

18

txirq:  inc  r4

19

  movb  (r1)+, r0

20

  bne  txcont

21

  bic  #100, @#XCSR

22

  rti

23

24

txcont:

25

  mov  r0, @#XBUF

26

  rti

27

28

  .=660

29

  .word  0,0,0,0,0,0,0,0

30

stack:

31

  .=1000

32

33

start:

34

35

  mov  #stack, sp

36

  clr  @#tcount

37

  clr  @#rcount

38

  clr  r4

39

  br  txtest

40

41

rxtest:

42

  bis  #100, @#RCSR

43

20$:  mov  @#rcount, r0

44

  cmp  r0, #30

45

  blt  20$

46

  bic  #100, @#RCSR

47

  halt

48

  halt

49

50

txtest:

51

  mov  #text, r1

52

  bis  #100, @#XCSR

53

10$:  bit  #100, @#XCSR

54

  bne  10$

55

  halt

56

  halt

57

58

rcount: .word  0

59

tcount: .word  0

60

text:  .byte  012,015

61

  .asciz  /Hello World/

62

  .word  0

Der Aufbau ist im Moment auf einem Breadboard. Der Micro Cycle Decoder 
ist extrem einfach gehalten und in einem GAL22V10 implementiert und 
stammt noch von einem Vorgängerprojekt aber tut hier seinen Zweck. Ich 
hänge mal die WinCUPL Design Files des GAL und des CPLD als auch ein 
Schema hier an.

Vielleicht ein paar Anmerkungen

Das Projekt implementiert ein eigenes Bus Protokol, Q-BUS ist sicher 
machbar aber dann reichen die PINs des ATF1504AS nicht mehr aus. Man 
könnte natürlich Bits 12..15 des RCSR in ein externes Bauteil auslagern 
(74HCT257) dann dürfte es wieder reichen.

Das Memory wird direct vom Micro Cycle Decoder angesprochen (/MREQ) und 
es findet keine Überprüfung auf non-existant RAM statt, das RAM ist also 
gespiegelt.

Der IO Bus wird über ALE, /IORD, /IOWR und /IACK gesteuert, das ist dann 
wieder ähnlich dem Q-BUS, aber es fehlen /RPLY, /WTBT  und ein bus 
timeout, auch ist der IO Bereich nicht byteweise schreibbar (ich wüsste 
kein Device das das braucht).

Der 74HCT541 ist nötig für das Boot Register, sonst ist es nur Zufall 
wenn der J-11 sauber initialisert. Steht auch im DCJ11 Manual und dort 
hat es auch ein Beispiel, natürlich mit weniger modernen Bauteilen, wie 
man das machen sollte.

Als nächstes nehme ich das CPU CPLD in Angriff aber für die geplanten 
Funktionen DMA, Bus-Timeout, asynchroner IO Bus reicht ein ATF1504AS 
definitiv nicht, da werde ich also auf ein ATF1508AS umsteigen müssen.

Und zum Schluss habe ich noch eine Idee für das Projekt. Anstelle 
weitere CDP6402 und ATF1504AS für weitere serielle Schnittstellen zu 
nehmen habe ich mir überlegt ein "VT-100" am IO Bus zu bauen. Dazu 
verwende ich fast das gleiche CPLD wie für die Console aber anstelle des 
CDP6402 nehme ich ein 74HCT652 als bidirektionaler Buffer und hänge 
daran einen ATmega328P der ein VT-100 Terminal emuliert mit VGA output 
und PS/2 input. Ich habe in meinem Fundus ein altes Projekt mit einem 
ATmega328 und einem 74HC166, das ungefähr so etwas wie ein VT-100 
emuliert. Zwar nur den Output (kein PS/2) aber da ich keine serielle 
Schnittstelle sondern den 74HCT652 als Eingang verwende wird der UART 
wieder frei und daran kann ich dann die PS/2 Tastatur anhängen und via 
74HCT652 den ASCII Code an den PDP-11 senden. Für den DCJ11 ist sieht es 
wie ein DLV-11 aus.


Gruss

Peter

Ups das war ein bisschen spartanisch. Da fehlten ein paar Verbindungen. 
Die habe ich nachgeführt. Auch den Baud Clock Generator. Ich habe einen 
ATtiny45 genommen, der lag rum und habe den so programmiert dass der den 
Systemtakt entsprechend teilt. Je nach Quarz und Baud-Rate muss man 
einfach den Timer0 programmieren und den Ausgang OC0A toggeln lassen. 
Auf dem Schaltplan fehlen jetzt nur die Abblockkondensatoren, Die Power 
LED und das TIL311 das ich beim ersten PDP-11 Hack zum debuggen brauchte 
um anzuzeigen welchen Microcycle (AIO0..3) der J-11 gerade durchführt. 
Aber jetzt für diese Projekt habe ich es nicht gebraucht, aber entfernen 
wollte ich ihn auch nicht. Ja und alles läuft auf dem Steckbrett.

Wie der K1802VM2 funktioniert weiss ich dafür nicht und ich habe auch 
keine Datenblätter von dem Teil. Gibt es die überhaupt auf englisch oder 
deutsch? Aber ich vermute stark, die haben sicher viele Gemeinsamkeiten 
mit dem DCJ11.

Gerade wegen dem Platz fand ich das eine gute Idee mit dem VT-100. Fast 
alle meine Microcomputer haben VGA Ausgang und PS/2 Eingang. Klar haben 
sie auch eine serielle Schnittstelle aber ich finde es praktisch wenn 
ich meine Computer auch ohne PC oder Mac benutzen kann. Etwa wenn meine 
Frau den Mac beansprucht. Ein 15" LCD Bildschirm und eine PS/2 Tastatur 
nehmen nicht so viel Platz in Anspruch. Es war auch nur eine Idee und 
nur als add-on, die Console ist eine echte serielle Schnittstelle, den 
Teil lasse ich wie auf dem Versuchsaufbau.

Wie du sagst, wenn man intelligente Peripherie zulässt dann könnte der 
ATmega natürlich auch andere Schnittstellen abbilden, etwa eine V.24, 
dann würde ich aber gleich einen ATmega mit 2 USARTs nehmen, dann kann 
er auch gleich zwei serielle Interfaces abbilden.

Noch etwas zum IACK signal, so wie es im Moment vom GAL erzeugt wird 
funktioniert eine Daisy Chain nicht IACK muss nach IORD aktiv werden und 
nicht noch schon vorher wie jetzt. Das werde ich aber im CPLD 
berücksichtigen welches das GAL ersetzen soll.

Falls noch etwas unklar ist gib mir Bescheid.

Gruss

Peter

Holm T. schrieb:
> Englische Dokumentation ist mir nicht bekannt, ich habe aber davon schon
> etliches durch einen Online-Translator geleiert und es ist prinzipiell
> klar was das Ding macht.
> Er hat keinen internen ODT aber einen SEL Ausgang mit dem ein Zugriff
> auf einen externen Speicherbereich gesteuert wird (also so nicht im
> PDP-11 Adreßraum liegend) in dem sich ein Firmware-ROM befindet der den
> Monitor-code enthält. Das Image und ein kommentiertes Reassembler
> Listing für diesen ROM gibt es. Außerdem sind in diesem Adreßbereich ein
> paar Arbeitszellen im RAM notwendig.
> Nach dem Einschalten liest die CPU von einem "Adreßfreien Register" die
> Bootkonfiguration, auch auf welcher Adresse der Einsprung in diesen
> Monitor liegt.. Der Rest sollte so ziemlich kompatibel sein. Der VM2 ist
> recht schnell und arbeitet mit 10Mhz Takt (extern 20Mhz).
>
Ja das addressfreie Register hat auch der DCJ11, das Boot Register wird 
via
GPREAD Zyklen gelesen, das ist bei mir der 74HCT541. Das mit SEL 
interessiert
mich, d.h. er kennt intern dass er im ODT ist aber das Program dazu muss 
man
liefern?
Zur Geschwindigkeit, wieviele Taktzyklen benötigt der VM2 pro Memory 
Read? Der
DCJ11 braucht 4 Taktzyklen pro Cache Read, wenn wie bei mir das ganze 
RAM so
schnell ist wie er es vom Cache erwartet, dann ist jeder Memory read 
exakt
4 Zyklen, bei 16MHz (aktuell bei mir, aber er funktioniert auch mit 
18MHz) läuft
das Ding recht flott.

> Ich verstehe Dich an dieser Stelle nicht.. Ich habe da noch olle 486er
> Schlapptops rumliegen die das besser können als jeder Eigenbau und da
> kann man im Notfall eine Ersatz11 oder einen SIMH drauf laufen lassen
> oder PDP11GUI..
> Wozu das also selber basteln?
>
Basteln vor alle daher, bei mir liegen keine alten Laptops herum, ich 
habe zwei
MAC. Und wie gesagt, die Console bleibt bei einer echten V.24 schon 
alleine
wegen PDP11GUI. Und der 15" LCD samt Tastatur liegt bei mir immer auf 
der Werkbank
wegen den anderen Projekten.

> Spannend wird  es dann bei Controllern deren lokale Intelligenz aus
> Bitscheiben besteht :-)
Ich habe da noch ein paar Teile aus einer alten Plessey CPU herum 
liegen, ein
dual-higth 9-slot Chassis, eine PDP-11/23 LSI CPU und dann jede Menge 
Peripherie,
darunter einen Diskcontroller, einen Floppy Controller und ein Tape 
Controller
auf denen Tummeln sich etliche 2901. Leider habe ich absolut keine Doku 
dazu. ODT
läuft, d.h. das ganze würde sicher auch funktionieren.
> Allerdings macht es mich immer ein Bisschen traurig wenn halt z.B. an
> einen Z180 unbedingt ein Atmel angespaxt werden muß um den Z180 zu
> booten..das ist irgendwie Quatsch.

Nicht unbedingt, ich habe bei mir einen kleinen W65C02 SBC gebaut, 
genannt ROMulus 1st,
und der setzt einen Atmel ATmega1284P ein der dient als Bootloader, VGA 
und PS/2
interface, den W65C02 betreibe ich bei 12.5MHz, da findest du kein ROM 
mehr das da
mitmacht. Gut primärer Grund ist VGA und PS/2, der Bootloader war ein 
Add-On.

Im Moment stehe ich bei meinem DCJ11 Projekt auf dem Schlauch, irgendwie 
möchte ich
es in eine definitive Form bringen aber ich habe noch gar nicht alles 
getestet. Das
Steckbrett ist für laufende Änderungen eben gar nicht so schlecht. 
Eigentlich würde
ich gerne einen sauberen Bus mit 3 oder 4 Steckplätzen für die IO Geräte 
haben. Das RAM
und die Console würden auf der CPU Karte Platz.

Gruss

Peter

Hallo Holm,

natürlich da registert nichts, es heisst nur BOOT Register und der 
74HCT541 führt auch nur zu DIP switches (bei mir noch Steckbrücken) und 
bei einem GPREAD liest der DCJ11 die bits und entscheidet dann wie er 
bootet. Wenn man ein 16-bit Wort liefert dann kann man auch noch eine 
boot Adresse mitliefern. Eine andere Option ist die Standard 
Boot-Adresse 173000. Im Moment ist es fest auf ODT gesetzt.

Bei VGA und PS/2 da ist nichts mit stöpseln für das gibt es KVM.

Das CY7C291 war mir völlig unbekannt, das ist natürlich eine 
Alternative.
Ja der 6502 war im Brotkasten, im BBC Micro und im Apple II. Wird heute 
noch als IP zu Millionen eingesetzt.

Backplane, ja das wird es wohl werden, aber es sollte einfach bleiben. 
Ich denke die nächste Zeit werde ich über noch nicht getestete 
grundsätzliche Funktionen und die Backplane nachdenken.

Gruss

Peter