Posts by 2ee

Hallo ThoralfAsmussen

als Grafik Befehle hatte ich mir jetzt einfach SCREEN (zum Umschalten zwischen verschiedenen Text/Grafikmodi), PIXEL, OVAL, RECT, LINE und COLOR reserviert. Zuerst hatte ich auch überlegt, den Farbparameter direkt im jeweiligen Befehl (also z.B. PIXEL x,y,color) anzugeben. Fand dann aber die Variante mit eigenem Farbbefehl besser, da ich dann nicht so viele Parameter übergeben muss, sich die Farbe vermutlich auch nicht ständig bei einem LINE Befehl ändert und da ich es einfach beim Apple II Basic auch so kannte. Einen LINETO Befehl könnte ich mir auch noch gut vorstellen, da dies zum Vektor Zeichnen natürlich klasse ist. Fand ich bei Turtle Grafik auch immer sehr schick. Ich wollte aber auch erst mal nur die wichtigsten Befehle schon einbinden, da ich evtl. noch ein, zwei Befehle für Sprites brauche (möchte). Bei den Grafikbefehlen wollte ich auch unbedingt direkte Aufrufe, eben wegen der Geschwindigkeitsproblematik.

Ich habe jetzt in EhBasic alle noch zur Verfügung stehenden Token bereits mit Res1, Res2,... vordefiniert, um eben weitere Verschiebungen (wegen der Save/Load Problematik) zu vermeiden. Da stehen jetzt noch zwei für Schlüsselwörter und drei für Funktionen zur Verfügung. Das ist auch der Grund, weshalb es jetzt dann doch keine Befehle für Datum und Uhrzeit gab. Die könnte man aber mit den CALL XYZ Befehlen nachlegen, genauso wie für die Sound Ausgabe und den oben erwähnten noch fehlenden SPRITE Befehlen.

Bei genauer Betrachtung könnte man ja den Befehl SCREEN ja auch via CALL machen, der ist ja nicht zeitkritisch .

Quote from ThoralfAsmussen

Dort gibt es mit "USR" dann auch schon gleich eine Lösung für das "beliebiges codefragment starten können" Thema/Wunsch von klaly.

Der USR Befehl kann in EhBasic (und meines Wissens nach auch bei TRS80 Basic) leider nur eine einzige spezielle Unterfunktion aufrufen, deren Vektor ich in der Zero Page bei $0B,$0C abspeichere. Somit disqualifiziert sich USR eigentlich, da ich hier ja auch immer erst mal den Vektor Poken (oder Doken) muss.

Quote from ThoralfAsmussen

Kamillentee mit Honig wird irgendwann auch lecker.

Ist jetzt schon mein "Lieblingsgetränk". Der Mittagskaffee hatte nämlich nicht wirklich gut geschmeckt . Liegt wahrscheinlich auch an den (hoffentlich nur) temporär ausgeknipsten Hirnzellen .

Quote from klaly

Zum Ausstig in den Monitor wäre es nett eine extra Befehl, wie z.B. MON oder SYS zu haben.
OK wenn der natürlich (auch bei Diektbefehl) einen Token verbraucht, dann ist das schlecht.

Man kann mit CALL den Befehlssatz noch erweitern. Dann könnte man z.B. mit CALL MON den Monitor aufrufen.

Auf diese Art möchte ich auch später DOS Kommandos unterstützen, da auch hier die wenigen verbleibenden Token ein Problem darstellen. Dabei hatte ich im speziellen aber auch über einen CALL alias namens DOS nachgedacht, um dann eben DOS DIR oder DOS CD nutzen zu können. Ist aber alles noch völlig offen und hier diskutabel.

Quote from klaly

Mir würde es sehr gut gefallen, wenn man diese "verdammte" Baudraten Erkennung abschalten könnte, notfalls würde ich sie einfach raus patchen. Evtl. könnte man eine Art Setup machen, wo man Baudrate und auch anderes abspeichern und in den Clock Chip legen könnte.

Das war tatsächlich bereits eine Überlegung von mir, bei vorhandener RTC die aktuelle Baudrate im gepufferten RAM abzulegen und die "verdammte" Erkennung erst wieder laufen zu lassen, wenn das Terminal dann nicht adäquat antwortet.

Ich muss aber erst mal meinen grippalen Infekt auskurieren, den ich mir am Wochenende zugezogen habe, dann werde ich mich mal dransetzen. Gerade sind dazu nicht genügend funktionsfähige Hirnzellen eingeschaltet .

Quote from HansOtten

Enhanced 6502 BASIC – Retro Computing (hansotten.nl) may help with EHBasic.

Vielen Dank Hans , den Link auf deine Seite kannte ich noch nicht. Sehr hilfreich vor allem die gegenüber dem Handbuch stark erweiterte Liste der Hilfsroutinen . Da werde ich mich mal schlau machen.

Hallo klaly

Quote from klaly

1. welcher IO-Bereich sollte an den Lötjumpern gesetzt werden: K2/K3/K4 ?

nimm einfach K2.

Quote from klaly

2. Was ist EhBasic eigentlich ?

Enhanced Basic wurde von Lee Davison entwickelt, der leider bereits 2013 im Alter von 49 Jahren verstorben ist. Sein Basic wurde seit dem nur wenig weiterentwickelt. Ich habe mich für sein Basic entschieden, da es gut (auch im Source Code) dokumentiert ist. Die EhBasic Dokumentation hatte ich jetzt in meiner letzten ZIP leider nicht dazugepackt, was ich jetzt aber hiermit nachhole.

HansOtten hat auf seiner Seite auch einiges dazu gesammelt. http://retro.hansotten.nl/6502-sbc/lee-davison-web-site/

Ich habe übrigens gleich den Patch für Groß-/Kleinschrift mit eingepflegt. Zu beachten ist hier, dass Variablen somit case sensitive sind. M und m sind also verschiedene Variablen.

Ich habe mir auch erlaubt, die bestehende Version 2.22 auf 2.23 zu erhöhen, um einen Unterschied zu den im Inernet erhältlichen anderen Versionen zu verdeutlichen. Ich hoffe Lee verzeiht mir das.

Quote from klaly

3. Gibt es dort auch PEEK und POKE ?

Ja gibt es. Und ebenfalls DEEP und DOKE für 16 Bit Werte.

Quote from klaly

4. Mit welchem Befehl komme ich zum Monitor zurück ?

Du kannst entweder die ST(op) Taste auf dem Junior drücken, oder im Basic CALL $E003 eingeben, was den Kaltstartvektor des Monitors aufruft. Um dann ohne Datenverluste wieder zurück zum Basic zu kommen springst du zu Adresse $0000 in dem du 0G am Prompt eingibst. Wenn du Basic aber komplett neu starten und initialisieren möchtest gibst du B000G ein.

Übrigens ist leider ein Nachteil von EhBasic, dass die Befehls Token ab dem Wert $80 beginnen und somit nur 128 Befehle möglich sind. Ich habe jetzt bereits einige Befehle für eine zukünftig geplante Grafikkarte reserviert und eingefügt, damit sich bei den Token später nichts mehr verschiebt, sonst sind gespeicherte Programme nicht mehr startbar, da diese nicht im Klartext sondern tokenized gesichert werden. Man muss da leider für die Befehle, Funktionen und Operatoren eine bestimmte Reihenfolge einhalten, sonst könnte man einfach nach dem letzten Befehl einen weiteren dranhängen.

Wie auch immer, jetzt sind leider nur noch eine Hand voll freier Token übrig, so dass eine weitere Befehlsvergrößerung fast unmöglich wird.

Ein weiterer Nachteil ist, dass EhBasic leider manchmal Murks macht, wenn eine Zeile mit den Pfeiltasten editiert wird. Ausserdem war (ist) von mir geplant, noch einen MOD(ulo) Operator einzufügen, was sich leider als höchst kompliziert herausgestellt hat, da man, wegen verschiedener Ergebnistypen nicht so einfach im Assembler Code verschiedene Befehle (+ / * Int() ) aneinander reihen kann. Ich werde mich da aber noch irgendwie durchbeißen.

Hallo klaly und natürlich auch alle anderen,

dein (euer) Wunsch wure erhört. Ich gebe jetzt die erst mal letzte Version des Junior ][ BIOS und des erweiterten EhBasic raus. Dann wird es wohl für dieses Jahr eine kleine Pause geben, bevor ich mich an die SPI Schnittstelle und somit der SD-Karten Unterstützung mache.

In der Zip-Datei sind jetzt wie gehabt eine 8K und eine 32K Version des BIOS Version 1.0.1 (ehemals Print Monitor).

Quote from klaly

U2 27256 auf Junior Computer ][ Board: was in welcher Version muss da rein ?

Wenn vorhanden, nehmt dafür ein 28C256 EEPROM. Ich möchte eigentlich von der 8K Version für 2764 EPROMs langsam weg, so dass in Zukunft nur noch eine Version gepatcht werden muss.

Quote from klaly

U8 28C256 auf IO-Board: was in welcher Version ?

Hierfür liegt die EhBasic Version 2.23 in der Zip.

ACHTUNG: Das IO Board wird mit der aktuellen BIOS Version 1.0.1 nur mit der aktuellen EhBasic Version erkannt. Alle alten Versionen sind somit obsolet !!!

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Denkt beim IO Board bitte daran, eine Lötbrücke für die Basis-Adresse zu setzen. Welche ist egal, nehmt aber vielleicht einheitlich K2. Auf der Junior Hauptplatine muss der DIP Schalter auf $80 = ON, $A0 = OFF, $C0 = OFF stehen, sonst startet der Rechner mit eingesteckten IO Board nicht.

Wenn $80 nicht auf ON steht, verschwendet ihr in Basic 8KB RAM, falls ihr ein 64KB oder 128KB SRAM eingebaut habt.

Es gibt nun im BIOS eine SWITCH_TO_RAM und eine SWITCH_TO_ROM Routine, um das Language ROM aus- und einzublenden. Somit kann für Maschinenprogramme das durch das ROM überdeckte RAM wieder vollständig nutzbar gemacht werden. Ich habe auf diese Art und Weise auch den Basic Interpreter erweitert und getestet.

Da vermutlich alle noch ein IO Board der Revision 1 oder 1A haben:

-------------------------------------------------------------------------------------------------

Lötet bitte eine 1N4001 oder 1N4004 zwischen die (K1) Relais-Kontakte 1 und 7 mit der Kathode an Pin 1, sonst klebt euch der Schließerkontakt nach ein paar Schaltvorgängen. BITTE NICHT VERGESSEN !!!

Quote from klaly

Dann wäre noch eine Adressübersicht für JC ][ und auch IO-Board sehr schön sowas zu haben.

Ich hab die bereits vorhandene (Hardware) Adressbelegungsliste nochmals mit in die Zip-Datei gepackt. Für das IO Board gibt es Aufgrund der frei wählbaren Basisadresse sowas (vorerst) nicht. Die BIOS Routinen greifen auf die einzelnen Bausteine mittels Y-Register Indexed Indirect Befehlen (LDA/STA (IOBase),Y ) zu. Ihr solltet deshalb die entsprechenden Routinen nutzen. Für die User VIA könnt ihr aber auch die einzelnen Register auf die eben genannte Art und weise lesen und schreiben, wobei IOBase die Zeropage Adresse $0014 ist und der Wert des Y-Registers mit den in der Nachfolgend erwähnten Liste mit VIA_ beginnenden Konstanten geladen werden muss.

Also z.B.

LDY VIA_PORTA

LDA (IOBase),Y

um das Port A Datenregister zu laden.

Für die BIOS Routinen habe ich jetzt mal eine (wenig bis noch garnicht kommentierte) Liste der Einsprungadressen zusammengestellt.

Die hinzugefügten EhBasic Befehle sind ebenfalls in der Zip-Datei. Ihr könnt jetzt mit mit einem Befehl ( PORT ) sowohl die zwei 8-Bit VIA Ports A und B, als auch die I2C Schnittstelle ansprechen.

Ich werde da auch noch ein paar kleine Demo-Basic-Programme bereitstellen.

Weiterhin sind wie ja bereits erwähnt die LOAD und SAVE Befehle, sowie ein LOCATE für die Cursor Positionierung und ein DELAY Befehl hinzugekommen.

Im Monitor gibt es jetzt wie ebenfalls schon erwähnt die Befehle LT (Load from Tape) und ST (Save to Tape). Eine ergänzende Beschreibung für diese Befehle muss ich noch für ein paar Tage schuldig bleiben, ich werde aber jetzt fleißig alles vervollständigen und zusammenschnüren.

Viel Spass

Jörg

So, nach etlichen Versuchen, EhBasic die Geheimnisse seiner Parameterabfrage zu entlocken, bin ich nun endlich so weit, dass EhBasic nun auch Load und Save komfortabel beherrscht.

Das ganze hat auch dazu geführt, dass ich mir Gedanken über ein einfaches Treiberkonzept machen musste, um verschiedene Laufwerke anzusprechen, denn der bisherige Ansatz war da einfach zu monolithisch. Das wiederum hat zu einer völligen Umkrempelung des Codes geführt, weshalb nun mal wieder kein altes Programm ohne Änderung läuft.

Aber es hat sich gelohnt.

Z.B. können jetzt von zukünftigen Erweiterungskarten direkt aus dem dortigen ROM Treiber Deskriptoren geladen werden, die dann jeweils eine Input, Output und Command Routine besitzen. Dadurch wird die Ansteuerung neuer Hardware wesentlich flexibler. Das ganze ist noch nicht ganz fertig, wird aber den bisherigen Code nun nicht mehr ändern oder verschieben.

Daher ist die Liste der bisherigen Standardroutinen und deren Einsprungpunkte nun auch gerade von mir in der Mache.

In Basic können nun mit

Load [device] [ , "Filename" ]

und

Save [device] [ , "Filename" ]

Programme geladen und gespeicher werden.

Dabei ist Device 0 der XModem Treiber und Device 1 der Datasettentreiber. Da XModem keinen Dateinamen braucht, ist dieser für Device 0 verboten.

Es geht also nur Load 0, bzw. Save 0. Ausserdem kann bei Device 0 die Nummer gänzlich weggelassen werden, somit ist Load und Load 0 identisch.

Bei allen anderen Storage Devices muss der Dateiname angegeben werden. Dieser kann aber auch Leer sein oder einen Stern beinhalten, was das gleiche bedeutet.

Ich werde jetzt noch ein paar Befehle für I2C- und VIA-IO, bzw. Lesen und Setzen der Uhrzeit und des Datums in den Basic Interpreter einfügen. Sobald das fertig ist, gibt es dann von mir die neuen ROMs (Version 1.0.1 und EhBasic 2.23), die dann auch ausschließlich miteinander arbeiten.

Apropos Uhrzeit. Norbert hatte mich zu Recht gefragt, ob es Möglich ist die Uhrzeit schon jetzt zu ändern, schließlich war ja mal wieder eine Zeitumstellung.

In der BIOS Version 1.0.0 geht das im Monitor mit E27E G für die Uhrzeit, E281 G für das Datum oder E27B G für Datum und Uhrzeit.

In der neuen Version hat sich das leider wie gesagt alles geändert. Dafür ist der Code nun viel aufgeräumter und optimierter.

Soweit erst mal die Info für das kommende ROM Update.

Cheers

Jörg

Im Software Bereich hab ich jetzt gerade mal die Version 1.0 des Junior BIOS bereitgestellt.

Hier nun die finale Version 1.0 des Junior System ROMs.

Die einzelnen Systemaufrufe bin ich euch leider immer noch schuldig. Die werde ich aber ab morgen zusammenschreiben und nacchliefern.

Die wichtigste Neuerung ist jetzt die vollständige Datasettenunterstützung. Da ich bzgl. Handbuch auch noch nichts erneuert habe, hier nur die Lade- und Speicherbefehle als Kurzbeschreibung:

Speichern auf Band mit dem Befehl ST - Save Tape

startadresse . endadresse ST ["Filename"]

Der Dateiname kann weggelassen werden, nur leere Anführungszeichen ("") oder ein Asterisk ("*") sein, dann wird die Datei jeweils als "*" gespeichert.

Also z.B.

2000.2100 ST "Hexdump"

2000.2100 ST

2000.2100 ST ""

2000.2100 ST"*"

Das schließende Anführungszeichen kann auch weggelassen werden, dann geht der Dateiname bis zum Zeilenende.

Laden von Band mit LT - Load Tape

LT ["Filename"]

Der Dateiname kann wie beim Speichern weggelassen werden, nur aus leere Anführungszeichen ("") bestehen, oder ein Asterisk ("*") sein, dann wird die jeweils nächste auf dem Band gefundene Datei geladen. Der Asterisk kann auch zum Teilmaskiere genommen werden, also z.B. "Test*", was dann die erste Datei lädt, die mit Test beginnt.

Also z.B.

LT

LT ""

LT "*"

LT "File*"

LT "File_1"

Sowohl beim Speichern, als auch beim Laden wird der eingegebene Dateiname in Großbuchstaben umgewandelt.

In der angehängten ZIP Datei befinden sich nochmals (mit angepassten Adressen) die Sound Demo und die LED Laufband Demo, die dann zum Testen mal gespeichert werden können. In der jeweiligen Help Datei stehen dann auch die Speicheradressen drin.

Als weiteren Test kann auch mal das EhBasic aus dem ROM gespeichert werden:

B000.DFFF ST "EhBasic"

danach könnt ihr das Basic ROM mit dem Befehl

E049 G

deaktivieren und das RAM zwischen B000 bis DFFF wieder einblenden.

Dann ladet ihr das Basic mit

LT "EhBasic"

in das RAM und startet Basic mit

B000 G

Basic werde ich dann in den nächsten Tagen hoffentlich auch ein paar neue Befehle, wie LOAD und SAVE beibringen.

So weit erst mal viel Spass beim Probieren

Hier ist jetzt mal die (hoffentlich) finale Version der Tape Routine, bevor sie in das System ROM eingepflegt wird.

Laden der Test.bin Datei mit LM und starten mit 0200G. Beim Speichern und Laden muss jetzt eine Zahl (1..9) oder das Asterisk Zeichen * eingegeben werden. 1..9 erzeugt beim Speichern eine Datei mit Namen FILENAME_N, * eine unbenannte Datei. Die Namen können natürlich später an der Kommandozeile eingegeben werden.

Beim Laden wird mit * wie gewohnt die nächste gefundene Datei geladen und mit 1..9 wird solange gesucht, bis die Datei FILENAME_N gefunden wird.

Beim Speichern wird nun gerade der 1KB Adressraum $2000..$2200 gespeichert. Wenn dort also bereits ein Programm eingegeben oder geladen wurde, könnt ihr das mal zum Testen nehmen. Ich hab da einfach die Sound Demo (auch nochmal in der ZIP Datei enthalten - laden mit LM und starten mit 2000G) dort hin geladen und dann die Dateien 1..3, *, 4..6 gespeichert.

Nach dem zurückspulen kann dann wie oben gezeigt z.B. die Datei FILENAME_4 gesucht und geladen werden.

Mittlerweile habe ich die Pulse Timings auf 240uS und 120uS heruntergesetzt, somit komme ich im Schnitt auf etwas 456 Byte/s oder 3652 Baud. Mehr wäre zwar sicherlich möglich, ich möchte jetzt aber nicht die Geschwindigkeit weiter auf Kosten der Schreib-/Lesequalität erhöhen.

Um Tests von euch und eventuelle Rückmeldungen wäre ich dankbar. Ansonsten werde ich dann den Code in das System ROM einfügen und hoffentlich nächste Woche veröffentlichen.

Cheers

Jörg

Quote from gpospi

Zunächst wollte ich als Ersatz eine alte Quantum/Apple 270 MB SCSI Platte einbauen. Leider konnte ich diese Platte nicht korrekt formatieren,

Die Apple Platten hatten ein anderes ROM als die jeweils vom Hersteller verkauften HDDs. Eventuell ist das der Grund, warum du diese Platte an der NeXT nicht formatieren konntest.

...und schon das erste (und erst mal letzte) Update. Da war noch ein Fehler bei den logischen Operatoren drin.

Quote from ThoralfAsmussen

Ich würde die Reihe ja dann nicht GO (das gibt es schon), sondern GoLD nennen.

Hab es gerade gesehen, ein in GO geschriebener Lisp Interpeter. Da war ich aber trotzdem früher dran, denn die erste Sprache war mein GoLogo Interpreter, den ich vor > 25 Jahren noch in Turbo Pascal unter DOS geschrieben hatte. Da gab es die GO Mutter Google noch nicht mal.

Vor ein paar Wochen war bei mir die folgende Situation: Frau übers Wochenende nicht da, keine Lust am System des Junior ][ weiter zu machen, keine aktuellen Hardware Basteleien und mal wieder richtig Laune, was an und für sich sinnfreies zu programmieren.

Also hab ich mich hingesetzt und einfach eine weitere klassische Programmiersprache meiner selbstgestrickten Go Reihe (steht für Good Old) zu schreiben.

Diesmal ist es GoLisp geworden, weil LISP einfach klasse ist und ich es schon lange mal selber programmieren wollte. Allerdings bin ich an dem besagten Wochenende nicht ganz fertig geworden. Und da meine Frau auch dieses Wochenende nicht zu Hause ist, ging es gestern Nacht also weiter.

Hier also mal die vorerst finale, unvollständige, aber durchaus brauchbare Version 0.1 zum rumspielen. Da das ganze in 2 1/2 Tagen entstanden ist, übernehme ich jetzt mal keine Garantie auf Fehlerfreiheit. Ich bin aber für Rückmeldungen immer offen.

In der Zip sind neben den Quelldateien eine "Lisp Test.txt" mit kleinen Beispielen und unter "GoList Help.txt" eine Auflistung der bisher implementierten Befehle, bzw. Funktionen. Das ganze ist in Delphi geschrieben, allerdings völlig Objekt frei und sollte sich problemlos auch in FreePascal Compilieren lassen.

Da das ganze eine Konsolenanwendung ist, liegt der Haupt Code in der Datei "Lisp.dpr", der Rest in den *.pas Units. Weitere Infos zur Programmierung von LISP findet sich natürlich im Netz.

Z.Zt. sind leider weder Long Integers, noch Loop etc. implementiert, was aber irgendwann noch kommt.

Mit (free) können die unbelegten Cons Cells abgefragt werden und mit (collect-cells) kann der Garbage Collector manuell aufgerufen werden, der aber auch automatisch bei Low Mem durchläuft. Die Anzahl der zu Begin verfügbaren Zellen habe ich mal auf 65536 festgelegt, was aber natürlich auch problemlos z.B. auf das 100 fache gesetzt werden könnte.

So weit mal die Erläuterungen. Viel Spass beim Lispen .

Jörg

Quote from rechnerfreak

Macht es Sinn einen SCSI-Rechner aufzubauen, nur weil ich alle möglichen Komponenten im Keller „gefunden“ habe? Wenn ja worauf wäre zu achten? Wo läge der Vorteil zum „normalen“ IDE-PC?

Ich bin durch ein auf der 68000 CPU aufgeklipptes SCSI Board im 128K Macintosh zu SCSI gekommen und hab es sofort geliebt. Schon allein durch seine universalität - Festplatten, Wechselplatten, Scanner, Drucker... - quasi der Vorläufer des USB einfach genial. In meinen ersten PCs hatte ich immer einen Adaptec Controller, an dem neben der Systemplatte auch irgend ein Wechselmedium wie das SyQuest SQ555 44MB Wechselplattenlaufwerk, ZIP Disk oder auch Bandlaufwerke hingen. Der Vorteil war eben auch, dass die (meiste) Hardware sowohl am Macintosh, x86 PC als auch später an der NeXT Station, bzw. meinem NeXTSTEP x86 PC lief. Ausserdem war ein Rechnerwechsel z.B. unter Window NT 4.0 am einfachsten mit SCSI möglich. Die Terminierungsproblematik bei SCSI ist natürlich immer ein Thema gewesen, ich hatte aber nie Probleme, bloss weil da mal mehr als 3 Geräte am Bus hingen.

Wenn du die (damals sau teure) Hardware eh schon im Keller rumfahren hast, lohnt es sich auf alle Fälle damit was zu machen, vor allem, wenn du ein Multibootsystem mit z.B. DOS, OS/2, Windows NT und NeXTSTEP aufbauen möchtest.

Hallo Dietrich vielen Dank für die Datei. Wenn ich den Code vor 4 Wochen schon gehabt hätte, wäre ich nicht im Traum darauf gekommen, da selber was zu stricken. Mittlerweile bin ich aber so weit, dass ich die meisten Dinge fertig habe und alles fehlerfrei läuft, so dass ich bei meinem Code bleiben werde. Ich hoffe, du bist mir da nicht böse.

Bei der Geschwindigkeit könnte ich natürlich auch noch was drehen, da ich mit meinen Timings recht hoch angesetzt habe. Allerdings habe ich gerade eine 100% Rückleserate, die ich durch höhere Geschwindigkeiten gerade nicht gefährden möchte. Ich werde dann für den finalen Code aber auch noch ein wenig damit experimentieren, 3600 Baud sind da sicherlich locker drin, dazu müsste ich wohl bloss von 255/128uS auf 240/120uS runter gehen.

Jedenfalls läuft die Übertragung ja schon mal wesentlich schneller als bei der Original Commodore 1541 Floppy, wo es ja meines Wissens nach nur 300 Bytes/s waren.

Gerade bin ich mit dem Datasetten Code so weit gekommen, dass ich Start- und Endadresse der zu Sichernden/Ladenden Daten angeben kann. Somit konnte ich jetzt zum Testen mal das EhBasic von $B000 mit seinen 12KB auf Kassette speichern und an $2000 wieder laden.

Davor hatte ich jetzt am Wochenende schon fortlaufende Blocknummern vor jedem 256 Byte Block und eine durch XOR erzeugte fortlaufende Prüfsumme, die nach jedem Block geschrieben wird eingefügt, womit eigentlich eine recht gute Fehlerprüfung vorhanden ist.

Da vor der Datei jetzt gerade 6x256 Bytes Synch Marker geschrieben werden kamen also insgesamt 13920 Bytes auf das Band. Bei einer Schreib-/Lesegeschwindigkeit von 37 Sekunden kommt man somit auf 376 Bytes/s oder 3008 Baud, was jetzt für die Datasette garnicht so übel ist.

Jetzt fehlt nur noch der Header vor den Daten (Dateiname, Start-/Endadresse, evtl. Folgedateien), den ich irgendwann diese Woche noch einfügen werde. Der Rest ist dann hoffentlich auch bald getan, so dass ich dann demnächst eine ROM Version 1.0 bereitstellen werde. Wie schnell ich dann noch die Load und Save Befehle im EhBasic integriert bekomme kann ich jetzt allerdings noch nicht sagen. I will do my very best...

Quote from Freak

Ich habe übrigens auf der Unterseite einen 3,3 k-SMD-Widerstand zwischen Pin 1 und Pin 2 von JP1 gelötet. So spare ich mir den Jumper, der normalerweise auf JP1 1-2 sitzt...

Das hatte ich in einem früheren Post auch schon mal vorgeschlagen, aber wieder vergessen. Ich denke, den Pulldown Widerstand werde ich auch gleich noch im Layout unterbringen, dann kann auch eine Zusatzplatine nach Bedarf die Adressdekodierung vornehmen.

Bzgl. LED, eine 0603 müsste eigentlich problemlos lötbar sein, da die Pads etwa 0,6mm auseinander liegen.

Sieht echt schick aus mit SMD Tastern. Ich muss wohl doch noch ein Board so aufbauen.

Passt jetzt der Einschalter bei dir bündig zum Rand, oder steht der noch leicht über?

Edit: Vieleicht sollte man noch für die STEP LED zusätzlich eine SMD LED vorsehen.

Quote from Freak

Wenn man sich die Platine nun genau anschaut, dann geht die Leiterbahn von rechts oben kommend zwar auf den Anschluss links unten, aber auch der Anschluss rechts oben wird durchfahren und verbindet die Anschlüsse rechts oben mit links unten!

AUTSCH !!!!

Ich hab das soeben im Layout geändert!

Ist aber echt seltsam, dass das Layoutprogramm diese Verbindung zugelassen hat. Sollten ja eigentlich verschiedene Netze sein.

Vielen Dank Thomas !!!

Poste doch bitte mal ein Vollbild von deinem Junior mit den SMD Tastern. Bin gespannt wie das aussieht.

Alles gut.

Quote from detlef

Sollte das eigentlich ein Scherz sein? Natürlich ist das Aufzeichnungsformat kompatibel.

klaly fragte, ob das von mir für den Junior ][ geschriebene Aufzeichnungsformat mit dem PET, C64 oder VC20, etc. kompatibel ist. Ist es nicht. Kann ich guten Gewissens so sagen, hab es ja schließlich selber gecoded. Was sollte also daran jetzt ein Scherz sein?

So, der Fehler ist - zumindest bei Norbert - behoben. Ein Interrupt hatte sich beim Schreiben soz. durch die Hintertüre eingeschlichen. In der Schreibroutine hatte ich aus versehen die Interrupts der VIA nicht komplett abgeschaltet, sondern nur vom Tick-Interrupt auf den Bit-Read-Interrupt umgeschaltet. So konnten beim Schreiben der Bits, die über den Lesekopf zeitgleich wieder eingelesenen Signale weitere Interrupts auslösen und das Schreibsignal modifizieren. Da war Norberts Laufwerk offensichtlich für so etwas empfänglicher als meines, denn bei mir ist der Fehler nie aufgetreten.

Ich habe jetzt also am Beginn der Schreibroutine die Interrupts mit einem SEI Befehl vollständig deaktiviert, so wie ich es auch in den XModem Routinen machen werde.

Jedenfalls habe ich jetzt wohl auch verstanden, warum beim C64 beim Laden/Schreiben von/zu Datasette der Bildschirm deaktiviert ist, der wird da wahrscheinlich auch durch einen Interrupt refreshed und der ist ja, wie Toast_r schon gesagt hat, hier dann eben auch disabled.

Ansonsten habe ich die Routinen noch etwas aufgeräumt und so nochmals ein paar Byte eingespart. Falls außer Norbert noch jemand die Routinen testen

kann und mag, wäre das Klasse.

Quote from NorbertJ

Ach ja, bei STOP läuft die Datassette weiter.

Das ist bemerkenswert. Denn an dem Punkt , an dem es bei dir nicht weiter geht, sind nur zwei Dinge passiert.

WAITPLAY    LDA    CASS_SENSE    ; Check sense line status
                BNE    WAITPLAY    ; If <> 0, wait if Datasette key pressed down
                LDA    #'.'
                JSR    COUT        ; Print '.' as a detection signal
                JSR    CASSRW_ON    ; Turn off key detection interrupt and turn on Bit read interrupt
STARTSYNC    LDA    #$00
                STA    STATUS        ; Initialize Bit arrival flag
WAITBIT        LDY    #PORTB        ; Set index to Port B
                LDA    (IOBASE),Y    ; Load Port B
                AND    #$20        ; Test cassette sense line at PB5
                BNE    BREAKSYNC    ; If sense line is high, PLAY key is no longer down -> exit.

Erstens, durch ein JSR zu CASSRW_ON, wird der 1/60 Sekunden Interrupt zum Abfragen der Datasettentasten deaktiviert und der Interrupt zum Erkennen der Bitflanken aktiviert.

Danach wird in einer Schleife die Bit Status Variable abgefragt. Direkt am Anfang der Schleife liegt die Abfrage der Datasettentasten, die jetzt manuell erledigt werden muss, da ja der 1/60 Sekunden IRQ deaktiviert ist. Sobald hier erkannt wird, dass keine Taste mehr gedrückt ist, beendet die Read Routine mit der Meldung "Break", abschalten des Motors und wieder umschalten der IRQs. Das funktioniert bei mir immer, auch wenn beim Lesen kein Signal ankommt, weil z.B. die Kassette garnicht eingelegt ist. Hier läuft bei dir der Motor ja einfach stur weiter.

D.h. also, dass in deinem Fall der Rechner entweder in der CASSRW_ON Routine (unwahrscheinlich) oder der dann laufenden Bitflankenabfrage in der Interrupt Routine hängen bleibt.

Ich melde mich heute Mittag nochmal bei dir und wir probieren mal eventuell ein paar Code Varianten aus, wenn du Zeit und Lust hast.

Hallo Norbert, ändere mal bitte bei dir nach dem Laden von Test.bin an der Adresse 0348 den Wert von 03 auf z.B. 06. Die Zahl minus Eins gibt an, wieviel 256 Byte Sync Blöcke als Vorspann auf Band gespeichert werden. Bei einem Wert von 06 solltest du dann beim Wiedereinlesen "Press PLAY......" sehen, bevor dann der Text gelesen wird. Der erste Punkt wird ja bei dir noch angezeigt, was signalisiert, dass das Drücken der PLAY Taste erkannt wurde. Die restlichen 5 Punkte sind dann jeweils für die erkannten Sync Gruppen. Werden weniger als 256 Syncs erkannt, fängt das Synchronisieren von vorne an.

Interessant ist deshalb, dass bei dir aus dem ersten Punkt sonst nichts mehr angezeigt wird.

Stoppt den die Datasette, wenn du nach dem Load Befehl die STOP Taste drückst, oder läuft dann der Laufwerksmotor auch noch weiter? Das wäre dann ja ein Zeichen dafür, dass die Routine bei dir vollkommen abgeschmiert ist.

Auf dem IO Board besteht ja die Möglichkeit, rechts neben dem Datasetten-Anschluss die Signale per Pin Header abzugreifen. Ich hatte da zum Testen jetzt immer mein Oszilloskop am Anschluss CR (Cassette Read) hängen um die gelesenen Signale mitschneiden zu können. Wenn du den oben genannten Wert dann mal auf 80h stellst, dann solltest du mit einem Speicheroszilloskop problemlos den Sync Wert 2E (sorry, ich konnte da leider nicht widerstehen ) also binär 00101110 sehen können, der dann wie folgt aussieht

Das letzte Bit ist bei mir wegen der nach einem vollständigen Byte folgenden Abfrage der Key_Sense Leitung von 256us auf 322uS gestreckt. Der Messpunkt für ein sicheres Eins Bit liegt bei Werten größer 384uS. Eventuell reicht da bei dir auch die Zeit nicht aus, weil dieses letzte Null Bit womöglich länger als 384uS dauert.

Du könntest dann mal den Wert an Adresse 0379 von 4E auf 4F oder 50 ändern, um da nochmal 8, bzw. 16uS dazuzugeben.

Hallo Norbert,

wahrscheinlich hat die Load Routine nicht genügend Sync Bytes gefunden. Wenn du etwas weiter zurückspulen kannst, sollte das eigentlich kein Problem sein. Als kleine Anzeige wird einmal nach dem Drücken von PLAY und dann jeweils nach 256 gelesenen Sync Bytes ein Punkt auf dem Terminal ausgegeben. Du solltest also mindestens zwei Punkte angezeigt bekommen, besser drei. Falls das nicht der Fall ist, läuft das Band einfach weiter und sucht nach genügend Syncs. Drücken der STOP Taste sollte das wie gesagt natürlich abbrechen. Falls du am Anfang des Bandes aufnimmst, achte bei normalen Bändern auch auf das Vorlaufband, auf dem ja nichts aufgenommen werden kann. Bei Computerkassetten gibt es das ja im Normalfall nicht. Eventuell waren da bei dir noch ein paar cm Vorlaufband unter dem Schreibkopf. Ich werde trotzdem mal weitere 256 Bytes Sync zusätzlich mit abspeichern, um da mehr Sicherheit beim Lesen zu haben.

Spule am Besten für deine Aufzeichnung mal zB. auf 020 und beim Abspielen auf 018 oder 019, dann sollte das klappen.

Hallo Klaus,

ich nehme immer den A65. Der läuft unter Windows.

Nach Toast_r s für mich erhellenden Erklärung, wie der C64 (und vermutlich auch PET und VC20) mit den Tasten der Datasette umgeht, hab ich jetzt mal in dem angehängten Demoprogramm eine Timer IRQ Abfrage wie beim C64 im 1/60 Sekunden Takt eingebaut. Aufgefallen ist mir, dass bei dauerhaft laufender Abfrage, die XModem Routine öfter Schreib-/Lesefehler produzierte. Deshalb muss ich dann in der endgültigen Version bei XModem Übertragung den Timer Interrupt vorrübergehend deaktivieren.

Wie auch immer. Das kleine Programm kann jetzt mal beliebig auf Datasette den "schnellen braunen Fuchs" schreiben und lesen.

Nach dem Laden der Bin Datei via XModem, einfach mit 200G starten. Wenn das Programm läuft, startet der Motor dann automatisch beim Drücken einer der Tasten PLAY, REW und FWD, und stoppt natürlich dann auch wieder nach drücken der STOP Taste. Ihr könnt jetzt also beliebig hin- und herspulen.

Durch drücken von S wird der Text aufgenommen (128x128 Byte), mit L geladen und Q beendet das Programm, womit auch die Interrupt Routine beendet wird, und die Tasten der Datasette dann nicht mehr reagieren. Wärend dem Speichern oder Laden (dauert ca. 45 Sekunden) könnt ihr jederzeit, durch drücken der STOP Taste auf der Datasette, den jeweiligen Vorgang abbrechen.

Es wäre super, wenn alle, die schon ein IO Board und auch eine Datasette haben, das Programm mal auf Herz und Nieren testen könnten, um eventuelle Fehler zu finden. Einzig mir bekannt ist bisher, dass es jetzt noch nicht NMI fest ist. D.h. drücken der ST Taste auf dem Junior hinterlässt gerade noch einen unaufgeräumten Zustand, was natürlich noch behoben wird. Ich bin gespannt, was ihr noch alles findet.

Im nächsten Schritt kommt jetzt der Datei Header dran und echte Daten sollen dann geschrieben und gelesen werden...

Danke euch allen.

Quote from klaly

Inwieweit ist die Datasetten Aufzeichnung "eigentlich" noch Commodore (PET2001) kompatibel ?

Völlig inkompatibel. Und auch ein völlig anderes Aufzeichnungsformat.

Quote from klaly

Gibt es da eigentlich dazu schon eine kurze Anleitung wie schreiben, bzw. lesen mit Datasette funktioniert ?

Ich mache jetzt erst mal alles soweit fertig, dann gibt es mit der neuen ROM Version natürlich auch eine Erweiterung des Handbuchs bzgl. Datasette.

Übrigens werden die bisherigen Routinen nun doch nicht verschoben. Ich habe die kleine Routine zum Anzeigen des Prozessorstatus, welche direkt hinter der Haupt Interrupt Routine stand jetzt einfach weit nach hinten geschoben. So hab ich noch Platz, um die Main IRQ Routine bei Bedarf zu erweitern, und ich kann die Prozessorstatusanzeige dahingehend ändern, dass statt eines einzelnen Hex Bytes für die Anzeige des Prozessorstatusregisters die einzelnen Flags noch angezeigt werden also z.B. (NV-BDIZC).

Hier mal der neueste Stand bzgl. Schreiben und Lesen auf/von Datasette.

Etwas aufgehalten hatte mich jetzt ein ständiger, sehr nerviger Lesefehler, der immer bereits während der Synchronisation auftrat. Nach ein wenig Vorspulen und neuaufzeichnen waren dann alle Fehler weg. D.h. das Band hat an mindestens einer Stelle vermutlich eine schlechte Magnetisierungsschicht, was eventuell auch die vorherigen Probleme verursacht hatte.

Wie auch immer, das Lesen klappt jetzt völlig Problemlos und ohne Datenverluste.

Die Daten werden oben direkt von Band gelesen und ausgegeben. Die Aufzeichnung habe ich jetzt 30 mal, jeweils ohne Fehler wieder eingelesen. Ich gehe also davon aus, dass das jetzt auch keine Zufallstreffer sind.

Für die Aufzeichnung nutze ich nun für Nullen 128uS High- und 128uS Low-Phasen. Bei Einsen jeweils 256uS H/L. Für den obigen Testtext mit 128 Zeichen, den ich 128 mal aufgenommen habe (also genau 16KB) lag die Durchsatzrate bei 341 Byte/s, also 2728 Bit/s. Das könnte man zwar eventuell noch etwas beschleunigen, aber ich denke, so ist die Aufzeichnung ziemlich fehlertolerant.

Die Leseroutine ist, wie bereits erwähnt, jetzt als Interrupt Routine realisiert, welche bei einer fallenden Flanke ausgelöst wird. Fallend daher, weil die Datasette beim lesen das invertierte des augezeichneten Signals wiedergibt. Beim Eintreten in die IRQ Routine wird zunächst ein Zähler abgefragt, welcher bei einer Null (256uS Laufzeit zwischen zwei Flanken) noch nicht und bei einer Eins (512uS) bereits abgelaufen ist. Danach wird der Zähler wieder auf seinen Wert von 384uS gesetzt. Das klappt extrem fehlertolerant und gibt genügend Zeit zwischen den Interrupts zur Verarbeitung der Daten.

Ich möchte jetzt die Schreib-/Leseroutinen so umbauen, dass ich sie eventuell direkt mit den XModem Routinen nutzen kann. Dann würde ich zum Einen einiges an Code sparen, zum Andern kann ich dann gleich die CRC Prüfsummenberechnung von dort für die Datasette übernehmen.

Heute hab ich mich dann doch mal wieder dem KIM-1 Clone von ralf02 gewidmet, bei dem ich ja zuerst annahm, dass evtl. ein oder mehrere SRAM Bausteinchen defekt sein könnten. Da joshy auf der CC22 so nett war, mir eines seiner tollen KIM-1 Handbuch Nachdrucke zu schenken (nochmals vielen Dank !!!), war aber nach kurzem Einlesen klar, warum mein KIM-1 sich nicht gerührt hat. Genauso wie bei meinem Junior ][ (und natürlich auch dem Original Junior) muss Pin 12 (D) des 74LS145 BCD-Decoders auf Masse gelegt werden, um die Onboard Adressdecodierung zu aktivieren. Da ich nicht über Ralfs IO Board die Spannungsversorgung angeschlossen hatte, war der Port Anschluss A-K (Decode Enable) natürlich offen. Nach Verindung mit Masse läuft der kleine nun wie eine Eins. Super Projekt von dir Ralf !!!

Nachher wird gleich mal damit gespielt.

Quote from Reinhard

ach ein JMP mehr (3 Bytes) macht sooo viel aus?

Irgendwie verkehrte Welt, es sei denn die dahinter liegenden Codestücke haben weniger als 30 bytes ...

...ohne Worte...