NKC Forum
Registrieren | FAQ | Suche | Wer ist online? | Mitgliederliste | Heutige Beiträge | Einloggen



Autor Thema: Bankboot mit größeren ERPROM
UR1968
Kennt sich schon aus
**
ID # 171


  Erstellt am 29. März 2017 21:42 (#1)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Hallo,

macht es irgendwie Sinn bei der Bankboot statt der 2x8K EPROM und RAM jeweils einen 16K EPROM und RAM einzusetzen?

Tschüß
Uwe

Beiträge: 74 | Mitglied seit: Februar 2017 | IP-Adresse: gespeichert
m.haardt
Fühlt sich wie zu Hause
***
ID # 93


  Erstellt am 29. März 2017 21:57 (#2)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Ich hab's so gemacht: http://schuetz.thtec.org/forumdrc/index.php?mode=viewthread&forum_id=1&thread=115

Michael

Beiträge: 401 | Mitglied seit: April 2008 | IP-Adresse: gespeichert
Creep
Fühlt sich wie zu Hause
***
ID # 169


  Erstellt am 29. März 2017 21:58 (#3)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Hallo,

für mich persönlich würde für ein 27128 EPROM sprechen, daß es noch leichter erhältlich ist.

Beim RAM sehe ich heute den damals eingeplanten 6116 als überflüssig an und würde nur für 6264 etc. designen. 16k RAM? Da müssen sich die Experten äußern.

Gruß, Rene

Beiträge: 408 | Mitglied seit: Januar 2017 | IP-Adresse: gespeichert
DerInder
Voll in Gange
Seitenadmins
***
ID # 2


  Erstellt am 30. März 2017 11:43 (#4)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Moin Rene,

nen 27128 würde ich nicht nehmen.

Eine häufige Bestückung bei der SBC3 (also die Bankboot davon) ist:

0000-1fff - Flomon
2000-3fff - ZEAT0
4000-5fff - ZEAT1
6000-7fff - RAM

Also im Grunde genommen eine halbe ROA.

-----------------------
Gruß
-=jens=-

Beiträge: 772 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
hschuetz
Administrator
Seitenadmins
******
ID # 3


  Erstellt am 31. März 2017 07:19 (#5)  |  Zitat Zitat   PN PN   E-Mail E-Mail   HP HP
Hallo,
oder auch
0000-1fff - FlomonCG
2000-3fff - FlomonCG
4000-5fff - RAM
6000-7fff - RAM
wer's denn ausprobieren möchte
Gruß
Hans-Werner

-----------------------
Ob 8bit oder 16 oder 32 ist doch egal, Haupsache selbstgebaut!

Beiträge: 788 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
m.haardt
Fühlt sich wie zu Hause
***
ID # 93


  Erstellt am 31. März 2017 08:41 (#6)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Ich denke man sieht, dass man ruhig ab 0000h 16K EPROM nehmen kann, wobei ich zu 32K EEPROM, von dem die Hälfte nicht benutzt wird, rate. Die sind billig und leicht zu bekommen. Hier würde ich auf jeden Fall ausreichend große Bohrungen für einen ZIF-Sockel benutzen. Bei der FLOMON Entwicklung hat sich das bei mir bewährt.

Ab 4000h würde ich zwei Sockel für jeweils 8k nehmen, wahlweise RAM oder EPROM.

Im Grunde ist die BANKBOOT ein einziger Murks. Man hätte für CP/M zwei ROA64 nehmen können, eine mit ROM (evtl. teilbestückt) und eine mit RAM. Zusammen mit einer MMU wäre so eine effiziente RAM bzw. EPROM Floppy möglich. Die Konstruktion der BANKBOOT verschwendet nämlich bei CP/M immer die obersten 4 K jeder Bank, weil dort in jeder Bank Code zum Speichertransport zwischen Bänken stehen muss, der als Zwischenspeicher das RAM der BANKBOOT benutzt. Das ist Speicherverschwendung und langsam. Außerdem verhindert die Architektur CP/M 3. Die vorgeschlagene Schaltungsänderung der BANKBOOT für CP/M 3 verschwendet auch Speicher, nur anders.

Der 68k braucht gar kein Banking, d.h. dort hätte man direkt zwei ROA64 benutzen können, statt die BANKBOOT zu modifizieren. Wegen 16 Bit braucht man sowieso zwei.

Damit entfiele auch die Notwendigkeit für das BANKEN Signal.

Das Gute ist: Wenn man FLOMON und das BIOS ändert, kann man das immer noch so umbauen und als Nebeneffekt kann man BANKEN für ein A20 benutzen und bekommt 2 MB Adressraum. :)

Michael

Beiträge: 401 | Mitglied seit: April 2008 | IP-Adresse: gespeichert
DerInder
Voll in Gange
Seitenadmins
***
ID # 2


  Erstellt am 31. März 2017 11:33 (#7)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Moin Michael,

zur Bankboot am 68k muß ich dir wiedersprechen.
Das Grundprogramm der 68k läuft zwar auf jeder beliebigen(geraden) Adresse, aber die 68ks erwarten auch ab Adresse 0 ein (Start-)Programm. Dieses sucht dann das GP und startet es, oder aber es kopiert das GP erst ind RAM.
Für CP/M-68k ist auch RAM ab Adresse 0 nötig.

Mit der MMU hast du zwar prinzipell Recht, aber dann müsst jemand beigehen und (sämtliche) Programme anpassen. Ich glaube, das wird eher nicht mehr passieren.

Übrigens ist bei den 68k eine MMU eigentlich überflüssig, da man Programm komplett relokativ schreiben kann. Für mein Geschmack ist das nur eine Bequemlichkeit oder Krankheit aus der 80er Schiene, die in die 68k Welt getragen wurde.

Ach ja ZIF-Sockel, der ist ja eigentlich nur für (System-)Entwickler interessant. Da wird es aber kaum noch welche geben ;)

-----------------------
Gruß
-=jens=-

Beiträge: 772 | Mitglied seit: Juni 2004 | IP-Adresse: gespeichert
m.haardt
Fühlt sich wie zu Hause
***
ID # 93


  Erstellt am 31. März 2017 12:56 (#8)  |  Zitat Zitat   PN PN   E-Mail E-Mail
Ach, der 68k startet an Adresse 0, aber CP/M 68k braucht dort RAM? Nicht klug, aber ok, dann würde auch dort so eine Speicherkarte reichen, die auch ein ROM hat und das ausblendet, sowie darauf geschrieben wird. Das spart gegenüber einem IO-Port Hardware.

Bzgl. der MMU stimme ich Dir zu: Außer für Unix braucht der 68k nicht unbedingt eine. Will man eine haben, so gibt es dafür externe Chips.

Was eine MMU an 8/16 Bit CPUs angeht: Da muss gar nichts in den Programmen angepasst werden. Speicherkopien zwischen Bänken laufen über FLOMON oder die Software versucht gar nicht erst eine. Soweit ich weiss, laufen GP und BASIC auch nur mit einer passend bestückten ROA64 ohne BANKBOOT, d.h. sie wollen nur an den richtigen Adressen ihr Programm und RAM sehen.

Nur FLOMON müsste angepasst werden, und wenn man mit der RAM-Disk alles nutzen möchte, noch das BIOS. Außerdem geht dann CP/M 3 und man könnte mal über MP/M und Fuzix nachdenken. :-)

Michael

Beiträge: 401 | Mitglied seit: April 2008 | IP-Adresse: gespeichert



| NDR Computer | Boardregeln


Tritanium Bulletin Board 1.6
© 2010–2016 Tritanium Scripts


Seite in 0,312217 Sekunden erstellt
21 Dateien verarbeitet
gzip Komprimierung ausgeschaltet
1033,70 KiB Speichernutzung