Mist war wohl doch nix, bzw. zu früh gefreut 
Ct180
-
-
Nun,
DRVTBL.ASM als extrn
FDHDIDE.ASM als public
LDRBIOS.ASM als extrn
-
Hallo Werner,
was mir spontan auffällt:
A/0>b:
B/0>lader3
CPM3.SYS wird mit dem lader3 von Laufwerk B: korrekt geladen.
Danach wird der CCP auf Laufwerk A: erwartet bzw. dort nicht gefunden.
Ein Problem können die unterschiedlichen Formate von Laufwerk A: und B: sein.
D.h. es wäre einfacher, du stellst beide Laufwerke auf das gleiche Format ein (AK).
Dann kopierst die CPM3.SYS, CCP.COM und lader3.com auf eine CP/M2.2 Bootdiskette
und startest den lader3 von Laufwerk A: (A/0>lader3).
PS: Das MC/NKC Format würde auch gehen, dafür müsstest du aber das CP/M2.2 BIOS auch umstellen.
Vielleicht etwas viel Arbeit für den Anfang ;-)!
Gruß
Alfred
-
Werner_8085 was ist den dein Bootlaufwerk - 3.5 oder 5.25 und welches Format?
Aus der fdhdide.prn.txt kann das Format in 22disk erstellt werden.
-
Hast du für das Bootformat ein funktionierendes Image von Alfred zum testen der 22DISk Parameter ?
-
Hallo zusammen,
damals war Speicher kostbar, und da CP/M68K nicht geplant war,
hat das AK-Format weniger Systemspuren als das NDR/MC-Format und größere Blöcke.
Evtl. hilft es, nach den Formatanpassungen in FDHDIDE.ASM das CP/M3 nochmals zu assemblieren
und GENCPM ohne Auto, quasi manuell durchzuklicken und die Werte dabei zu checken.
@Werner, das wird schon!
Gruß
Alfred
-
Hallo Werner,
das sehe ich auch so.
Wenn der CCP geladen wird und der Prompt erscheint, sollte mit dem Disksystem eigentlich alles passen.
Evtl. stimmt doch etwas mit deiner Hardware nicht (MMU/Bankumschaltung, Adressierung, Memory etc.)!?
Teste nachher noch etwas an meiner Hardware und melde mich wieder.
Gruß
Alfred
-
Bitte schön ...
-
Hier noch zwei Varianten für IDE bzw. CFC ...
-
Hallo Werner,
scheint doch die Hardware zu sein, Details siehe Anlage
-
Anbei noch einige Infos zur Hardware und Bugs, evtl. hilft das weiter ...
Gruß
Alfred
-
PS: Die ersten HD64180 CPU's hatten einige Fehler (Maske R0P), die späteren haben die Revision R1P.
-
Hallo Werner, klasse, es geht voran!
Welche Speicherbausteine verwendest du genau?
Evtl. sind die etwas zu langsam, oder passen vom Refresh nicht perfekt zum Timing.
Damals hatte ich einige Hersteller getestet, Hitachi & Toshiba waren sehr gut.
Für 6MHz sollten sie <= 120ns, und für 8MHz <=100ns Zugriffszeit haben.
1989 waren die schnellsten von Toshiba (TC51256P-70) = 70ns, die habe ich dann bei beiden Boards verbaut.
Man braucht ja Reserven für höhere Taktfrequenzen
Gruß
Alfred
-
Hallo Werner,
du könntest zum testen maximale Waits einstellen, also in BIOSDEF.MAC diesen Bereich anpassen.
von:
else ; 12,288 mhz quarz
iowait equ 0 ; keine waits
memwait equ 0 ; dto.
auf:
iowait equ 00110000b ; 4 I/O-Wait(s)
memwait equ 11000000b ; 3 MEM-Wait(s)
Rest wie gehabt!
Den Inhalt vom Register B2 (dcntl 32h+80h (iobase)) kann man dann z.B. mit DDTZ kontrollieren (60h = meine Einstellung):
ddtz
DDT/Z [8101]
> ib2
60 01100000"
>>q
?
> g0
Gruß
Alfred
-
Falls es dann funktionieren sollte, kannst du die Waits sukzessive reduzieren.
DCNTL (DMA/WAIT Control) Register auf 32h
-----------------------------------------------------------------------------------
| Bit 7 | Bit 6 | Bit 5 | Bit 4 | Bit 3 | Bit 2 | Bit 1 | Bit 0 |
-----------------------------------------------------------------------------------
| MWI1| MWI0| IWI1 | IWI0 | |
-----------------------------------------------------------------------------------
-
Schade , wäre ja zu einfach gewesen :-(!
-
Hallo Werner,
genau, in der Ruhe lieht die Kraft!
PS:
Bei der Waitgeschichte hatte ich einen kleinen Denkfehler, konnte so also gar nicht funktionieren!
Denn die Wait-Einstellungen aus BIOSDEF.MAC werden nur im BOOTLDR.MAC gesetzt:
START:LD SP,bootend ; stack
push bc ; drivecode sichern
ld a,iowait+memwait; aus BIOSDEF setzen
out0 dcntl,a
Da in deinem Fall die CPM3.SYS aus CP/M2.2 vom LADER3 geladen wird, wirkt sich das nicht aus.
Also das DCNTL (DMA/WAIT Control) Register auf 32h/b2h vom Monitor oder alternativ mit DDTZ setzen.
Viel Spaß
Alfred
-
Nachtrag: Die I/O Waits sind kritisch, wenn zu hoch, wird der FDC ausgebremst
-
Habe mich in den letzten Wochen mit meinem Utility für Systemspurbearbeitung beschäftig.
Es läuft auf dem Moppel, da dort die besseren Vorrausetzungen vorhanden waren z.B. Intel-HEX laden und Diskettenroutinen um einzelne Sektoren zu lesen und schreiben. Im Prof gibt es das Intel-Hex Ladeprogramm nicht und im ct die Diskettenroutinen unter Monitorkontrolle nicht, müsste/könnte ich natürlich auch dort einbauen. Für das Moppel-BIOS gab es die Grundroutinen dazu schon und haben sich beim BIOS-bau bestens bewährt.
Mit dem Progrämmchen werden die Systemspuren ins RAM geladen, das Diskettenformat kann über die Parameterauswahl entsprechend eingestellt werden
z.B. SS/DS, Sektorgröße, Anzahl der Sektoren per Track, Quell/Ziel-LW etc. das ganze auch rückwärts, zwischendrin kann das BIOS mit dem Intel-Hexlader ausgetauscht werden. So ähnlich wie Sysgen nur flexibler, vorallem wenn noch kein CP/M-System bereit steht.
Damit kann ich ganz komfortabel die Programme auf dem PC zusammenschrauben und direkt per Intel-Hex ins Zielsystem schieben ohne den Umweg über 22Disk.
Ziel der ganzen Übung, für den ct180/prof180 die BIOS-Erweiterung der CF-Karte...
Nun zurück zum ct180, der gibt mir immer wieder Rätsel auf:
Sobald unter CP/M2 eine Datei in LW A: angelegt werden soll steigt er mit dem Schreibschutz aus, könnte ja an den Zeigern des DPH/DPB liegen,
dann müsste er es aber immer anmeckern.
Der Schreibschutz ist natürlich nicht gesetztGibt es dafür eine einfache Erklärung ?
LG Werner
