JC II System Adressen

[CC2ee]

Du hast in deinem BIOS Code die Routinen SD_RD_LBLK_BUF und SD_WR_LBLK_BUF zum Lesen und Schreiben genommen. Die Adressen hierzu $F458 bzw. $F48B stimmen leider nicht (mehr).
SD_RD_LBLK_BUF = $F45F
SD_WR_LBLK_BUF = $F492

Allerdings lesen, bzw. schreiben diese beiden Routinen vom/zum Standard Buffer an Adresse $0600.

Besser ist es, wenn du die Routinen

SD_RD_LBLK = $F462
und
SD_WR_LBLK = $F495

nimmst. Hier kannst du zuvor über die beiden Zero Page Variablen BLKBUFL, BLKBUFH an $DC, $DD den Ziel Buffer Vektor angeben und somit z.B. gleich in die Adresse $2000 schreiben. Nach dem Schreiben/Lesen eines 512 Bytes Sektors steht dann in BLKBUFL, BLKBUFH gleich der Pointer auf die um 512 Byte folgende Adresse also im Beispiel oben bei $2400. Somit kannst du kontinuierlich den Speicher lesen und schreiben.

[Dietrich-L]

Danke für die Info. Ich werde die Adresssen gleich korrigieren.
Ich benutze absichtlich den Standard Buffer, da CPM-65 mit 256 Byte Blöcken arbeitet und ich daher die 512 Byte von der SD eh puffern muß. Ich brauche dann keinen separaten Puffer vorsehen - spart Platz im oberen Speicherbereich.

Für den Bootloader werde ich SD_RD_LBLK = $F462 und SD_WR_LBLK = $F495 benutzen, um den Code direkt an Ort und Stelle zu beamen.

Dietrich

[Dietrich-L]

Noch eine Frage:
Wie muss die LBA im Speicher liegen?
LSB, LSB+1, LSB+2, MSB?
oder anders herum, also MSB zuerst?

Dietrich

[CC2ee]

Hallo Dietrich,

in der Zero Page liegen die SD-Karten Parameter Bytes SD_PB3..SD_PB0 an $DF..$E2.
Hier wird auch die LBA abgelegt. Format ist hier MSB..LSB, da das die SD-Karte so braucht.

Wenn du einen 32 Bit FAT LBA Pointer einlesen möchtest, der üblicherweise im Format LSB..MSB vorliegt, solltest du aber die die Routine LOAD_LBA an Adresse $F462 nehmen.
Diese macht nicht nur das notwendige Byte-Swapping, sondern auch das Bit Shifting, das evtl. notwendig ist. Je nach Kartentyp kann die Addressierung der SD-Karte nämlich entweder Byte- oder Blockweise sein.
Vor dem Aufruf von LOAD_LBA läds du in das X Register das Low Byte der Addresse, an dem der LBA Pointer liegt, und in das Y Register das High Byte. In der ZP Variabe SD_TYPE an $EE steht nach dem Initialisieren der SD-Karte entweder eine 0 für Bit/Byte Mode oder <> 0 für Block Mode. Daher sollte $EE nicht überschrieben werden.

Bsp:

LDX #LOW LBA_POINTER
LDY #HIGH LBA_POINTER
JSR LOAD_LBA

danach kannst du mit SD_RD_LBLK_BUF, bzw. SD_WR_LBLK_BUF den gewünschten Block an $600 lesen oder schreiben.

[Dietrich-L]

Ok, alles klar. $EE ist eine Komplikation, da dieses Byte im BDOS verwendet wird. Ich habe das im BIOS gepuffert.

Dietrich

[CC2ee]

Hallo Dietrich,
da ich eh noch einen Fehler in der LOAD_LBA Routine gefunden habe, habe ich auch gleich die Variablenadresse SD_TYPE von $EE auf $1A umgezogen. ich hoffe, dann ist sie nicht mehr im Weg.
Ich würde dann heute das neue JC II BIOS zusammenstellen und im Forum samt Code posten.

[Dietrich-L]

Hallo Jörg,

das finde ich natürlich extrem nett, dass du $EE freimachst. Leider ist $1A nur unwesentlich besser.

Das ZeroPage- Konzept von CPM-65 sieht vor, dass alle Adressen ab $E0 für das Betriebssystem reserviert sind und alles darunter den Anwendungsprogrammen zur Verfügung steht. Meine Programme fangen dann bei $00 an und arbeiten sich nach oben. Das Speicher-gierigste Programm ist BASIC - es braucht $00 - $7F. Bei den Speicheradressen unterhalb $7F muss ich dann also bei jedem einzelnen Programm prüfen, ob eine Kollision vorliegt. Bei meinem Apple II Port habe ich das kurzerhand so gelöst, dass ich vor jedem Aufruf einer Apple-ROM-Funktion die betroffenen Speicherzellen in einen Puffer swappe und die Werte fürs ROM wiederherstelle. Nach Rückkehr aus dem ROM wird zurückgeswapt - nicht sehr elegant, funktioniert aber.

Um zu erreichen, dass die Zeropage möglichst geschont wird, habe ich einen Haufen Systemvariable, die im BIOS gebraucht werden, in ein Scratch-RAM verlegt. Bei mir ist das der 128 Byte-Block des 6532, wie bei dir auch. Weitere lokale Variable sind im Bereich des Codes der Module BIOS, BDOS und CCP untergebracht. Das geht bei ROM-Code natürlich nicht. Ich schlage vor, für solche Daten, z.B. die DEVLIST, Speicher unterhalb des ROMs oder in $200 - $7FF zu reservieren. 1 Page plus Platz für die BLOCK Buffer sollte auch langfristig genügen. Du wirst den für die FAT-Treiber brauchen.

Ich hoffe, ich bringe da bei dir nicht alles durcheinander. Aus Erfahrung plädiere ich aber dafür, die Speicherorganisation früh zu regeln und dann einzufrieren. Dann müssen nicht ständig alle möglichen Programme angepasst werden. Aus demselben Grund benutze ich in BIOS , BDOS und CCP zentrale Einsprungpunkte an fixen Adressen. Bei meinem Apple II Port musste ich nur den BOOTcode und das BIOS neu schreiben. Alle anderen Programme einschließlich BDOS und CCP wurden lediglich für die neuen Startadressen aufgrund der geänderten Memory Map neu assembliert. Ausnahme: DEBUG wegen der Nutzung des BRK Befehls und der notwendigen Anpassung an den IRQ-Mechanismus des Apple II.

Das alles ist natürlich deine Entscheidung. Was immer du tust - ich werde mich darauf anpassen und nicht nörgeln - versprochen.

So und nun brauche ich etwas Zeit, deinen neuen Code zu studieren. Wahrscheinlich muß ich dann doch meinen SD-Card Adapter in Betrieb nehmen, um auf meiner Seite mehr testen zu können. Dein Code sollte da sehr von Nutzen sein.

Gruß

Dietrich

[CC2ee]

Hallo Dietrich,
ich nutze im Normalfall nur die Adressen ab $DC..$FF und diese im gesamten ROM teilweise mehrfach belegt, da sie meist nur temporär für die gerade genutze Funktion gebraucht werden. Auch diese Adressen musste ich schon mit EhBasic teilen. Alles unterhalb $DC ist vollgestopft mit EhBasic Adressen. Der einzig kontinuierlich freie Bereich war dort noch $14..$5E, den ich eigentlich nicht anlangen wollte. Durch die Forums Entscheidung, die Startadresse der IO-Karten flexibel zu gestalten, musste ich dann doch dort ($14..$19) ein paar Adressen abgreifen, über die dann meine Basisadressen zu den IO-Karten via Y Indirekt Indizierter Adressierung zusammengebaut werden. Diese sind fix und können auch nicht mehr geändert werden, ohne im ROM Chaos anzurichten.
Die einzigen festen Adressen, die ich als Variable sonst noch benötige sind eben SD_TYPE, da diese sich nach der Initialisierung der SD-Karte nicht mehr ändern darf, und VIA_STATUS an $E4, welche den aktuellen VIA Port IO "einfriert". Ich dachte nun, SD_TYPE nach $1A zu schieben, wäre dann zumindest dort wo die anderen festen Adressen noch liegen gut aufgehoben, so dass man leichter drum herum manövrieren kann. Soll ich lieber wieder auf $EE zurück gehen? Noch scheinen nicht viele das neue ROM geflashed zu haben.

Im RIOT RAM ist bei mir alles belegt und in Stahlbeton gegossen. "Normale" Speicherbereiche zwischen $200..$7FF wollte ich so weit wie möglich für das DOS aufheben und werden zumindest zum Booten auch schon benutzt.

$0600..$7FF ist der Standard Block Buffer.
$0400..$5FF beheimatet die maximal 16 Volume Deskriptoren (hier eventuell auch nur $0400..$041F für die SD-Karte) - kann in CPM-65 auch woanders abgelegt werden, bzw. wird dann sowieso nur noch teilweise gebraucht (Partition Start 4Bytes an $400, Start Cluster 4 Bytes an $410).
$0200..$3FF hält beim Booten den aktuellen Directory Block im Speicher. Danach sollte hier der FAT-Buffer liegen. Also beides für CPM-65 irrelevant.

Ich werde mich jetzt auch etwas intensiver mit deinem Code beschäftigen und dann mal ausprobieren, wie weit wir schon auf der realen Maschine mit dem Booten kommen.

[Dietrich-L]

Hallo Jörg,
aus dem Bauch heraus glaube ich, dass es günstig ist, in deiner Systematik zu bleiben - dein System ist schließlich das Basissystem. CPM-65 sitzt da drauf und muß sich anpassen. Also ist langfristig $EE besser - glaube ich zumindest ...

Gruß

Dietrich

... der diese Woche wenig Zeit haben wird ;-)

[Dietrich-L]

Ich habe jetzt meinen SD Kartenadapter in Betrieb genommen. Da ich deine Zusatzlogik für die SPI-Schnittstelle nicht habe, mußte ich SPI am Port B meines VIA per Bitbanging realisieren. Geht gut mit etwa 60 kHz. Aus deinen ROM-Routinen und einem Diskeditor von CPM-65 (DUTIL.COM) habe ich dann einen Sektoreditor für die SD-Karte gebastelt. Ich kann nun jeden Sektor gezielt lesen. Ob Schreiben auch geht, muß ich noch testen.
Die SD-Karte habe ich auf 1,8 GB partitioniert und mit FAT formatiert. Sollte damit FAT16 sein. Ich bin mit allerdings da nicht ganz sicher, da der MBR doch im Detail anders aussieht als erwartet. Ich habe dann mein Image auf die SD kopiert und war in der Lage das Image zu finden und zu lesen. Gute Nachricht: erwartungsgemäß liegt das Image auf lückenlos aufeinander folgenden Sektoren.
Als nächstes erstelle ich eine CPM-65 Spezialversion, die auf dieser Konfiguration von SD bootet. Wenn das läuft, mache ich die Version für den JC II.
Im Moment sind in meinem Code noch etliche Fehler. Du brauchst also noch nichts damit probieren. Ich gebe Bescheid, wenn ich eine entfehlerte Version fertig habe.

Dietrich

[Dietrich-L]

Ok, Schreiben geht jetzt auch. War ein Stück Arbeit, weil im Code ein paar Fehler waren - die meisten auf meiner Seite.
Einen Fehler sehe ich noch in deinem Code - beim single block write folgt das result byte unmittelbar auf den CRC. Erst danach kommt die busy phase. Mein Code sieht jetzt so aus - du wirst ihn wiedererkennen ...

*****************************************************************************
; Write Single Data Block
; Input:  SD_PB3..SD_PB0 = 32 Bit CommandBlock Address
; Output: C = 0 Error, C = 1 Read OK
;	  A = Error Code
; *****************************************************************************

SD_WR_BLK	LDA	#CMD24			; send CMD24 (blk write)
		JSR	SD_SEND_BLK_CMD
		CMP	#$FE			; is card ready for block write?
		CLC
		BNE SD_WR_END
		JSR	SPI_OUT		; write data token
		LDX	#$01			; initialize page counter
		STX XBUF
		LDY	#$00			; initialize byte counter
SD_WR_BLK0	LDA	(BLKBUF),Y		; read next byte from buffer
		STY YBUF
		JSR	SPI_OUT		; and write it to the card
		LDY YBUF
		INY				; increment source pointer
		BNE	SD_WR_BLK0		; pointer overflow? No, write next byte
		INC	BLKBUF+1			; yes, increment block buffer page
		DEC XBUF
		BPL	SD_WR_BLK0		; two pages written? no, write next byte
		JSR	SPI_BIN		; yes, send a (dummy) CRC ($FFFF)
		JSR	SPI_BIN	
		JSR	SPI_BIN			; read response byte
		PHA
SD_WR_BUSY	JSR	SPI_BIN			; read next byte
		TAX
		BEQ	SD_WR_BUSY		; check if busy ($00)
		PLA
		AND	#$1F			; mask result bits
		CMP	#$05			; data accepted?
		CLC
		BNE	SD_WR_END		; no, exit with C = 0
		SEC				; yes, exit with C = 1
SD_WR_END	RTS

Dietrich

[CC2ee]

Hallo Dietrich, bei meinen Recherchen zum SD-Karte via SPI Schreiben musste nach der CRC ein dummy Byte ($FF) geschickt werden, bevor ein Response zurückgesand wurde, um eventuell fehlende Bits noch in den Empfänger zu schieben. So war das jedenfalls auch auf dem Logic Analyzer zu erkennen. Das Schreiben funktioniert mit dem Code bei mir problemlos.
Meine Zusatzlogik beschränkt sich übrigens auf ein Shift-Register 74LS165 am IO-Port der VIA. Ein Aufruf von SPI_READ sendet immer $FF auf der MOSI Leitung, da das Shift-Register (Ausgaberegister) mit jedem Schritt am Shift In Eingang eine 1 "zieht". Erst nach den (beliebig vielen) Dummy Bytes sendet der Slave dann seinen Response.

Ich wollte anfänglich das ganze auch per Bitbanging machen, war aber da schon unzufrieden mit der Geschwindigkeit. Dann bin ich über die beiden genialen VIA Modis Shift In/Out via PHI2 gestolpert, womit ich bei einer Bitrate von PHI2/2, also im Junior Fall mit 500KHz die Daten zur/von der SPI schieben kann.

[Dietrich-L]

Hallo Jörg,

deine Lösung mit VIA Shift mode & LS165 ist natürlich mit Abstand die beste. Ich hatte nur gerade keinen LS165 im Vorrat und für Testzwecke reicht Bitbanging allemal. Ich werde wahrscheinlich nachrüsten, wenn ich die Zeit dafür finde.
Bezüglich des Schreibens in meinem Setup bin ich darüber gestolpert, dass dein Code mit meinem SPI-Treiber bereits das 3. Byte als $E5 zurückgibt. Ich habe mich dann eingelesen und diese Quelle benutzt: http://elm-chan.org/docs/mmc/mmc_e.html

Ich denke nicht, dass da jetzt Handlungsbedarf besteht. Dein Code funktioniert ja und meiner ist nur für mich und funktioniert auch. Wir sollten nur wissen, dass da etwas unklar ist, falls uns das irgendwann auf die Füsse fällt.

Gruß
Dietrich

[Dietrich-L]

Ich habe jetzt eine Testversion eines Bootloaders fertig, der CPM-65 von einem Disk Image in den Speicher lesen kann, sofern die Position von Block 0 des Images bekannt ist.
Als nächstes präpariere ich eine Version von CPM-65 mit einer Adressenlage für meinen Junior Computer und dem SD-Karten-fähigen BIOS und daraus ein Disk Image. Das werde ich dann versuchen zu booten.
Wenn das gelingt, kommt als nächstes der Mechanismus, ein Disk Image im BIOS zu mounten, wenn man dessen block 0 Adresse kennt.
Und dann kommt die JC II bootbare Version.

Endlich Licht am Ende des Tunnels

Dietrich

[Dietrich-L]

So, ich kann nun von SD booten und die Speicherbelegung ist schon JC-II konform - hoffe ich...
Den LBA des Images habe ich derzeit im Bootloader von Hand eingetragen. Da brauche ich noch einen Mechanismus von dir, im FAT-System ein File zu finden. Mein BIOS hat dann eine MOUNT-Funktion mit der man bis zu 4 Images mounten kann.
Den Bootloader könnte man als File aufrufen oder beim Booten selektieren und laden - was dir lieber ist.
Wenn dieser Schritt getan ist, können wir den Betatest beginnen.

Dietrich