Beiträge von alx

Moin,

beim versuch den FIBR auf dem sd2iec zum laufen zu bekommen ist mir ist da was aufgefallen:
irgendwo beim einlesen des Verzeichnisses ist ein Fehler aufgetreten (ich kann nicht sagen wo genau) - so weit so gut, haett' mich auch fast gewundert wenn es so einfach wäre.
aber als ich dann (mangels Monitor/Debugger) einfach in die Verzeichnis lese Routine an acht stellen eingebaut habe das die farbe von acht char erhöht wird (um raus zubekommen wo da eine Differenz ist) klappt es?!
also den debug code rauskommentiert und: es ging wieder nicht...

kann es sein das das sd2iec da etwas pingelig ist? und wo genau?

Ciao, ALeX.

EDIT: der C64 hat nur JiffyDos.

Zitat

Original von Roland
was punkt 2 betrifft, sollte das aber gehen... einfach den $01 wert ändern!
mit:
B36
setzt du den $01 wert auf #$36 (also basic rom aus)
mit kernal rom geht es auch (b35)

Ja, das mache ich auch, aber SMON ueberschreibt $01 immer mal wieder...

Zitat

und was punkt 3 betrifft...hab ich noch nie probiert, sollte aber doch auch kein
problem sein, da der SMON ja nix fest nach $0400 schreibt, sondern die standard
ausgaberoutinen verwendet.

Ja, das ist richtig, aber wie aendere ich das, bzw. kann SMON nicht (selber) auf 0400 umschalten, und nachher wieder zurueck? (da mein screen ja mal auf c000 und mal c400 ist)

Gibt es hardware module die das koennen?

Edit:
das mit dem $0288 probiere ich heut' abend mal, aber muss auch gucken wie ich zuertst das ueberschreiben von $01 "abschalte".

Moin Jungs und Mädels,

ich bin jetzt dabei den FIBR auf dem echten C64 zu testen, aber da gibts ein paar probleme...
und habe da nun eine frage: welchen monitor kann ich verwenden?

und hier ein paar einschraenkungen:
- am besten per sortfware...
- muss code "unter dem baisc rom" abarbeiten koennen
- muss auch mit anderen screens als 0400 auskommen koennen (mein screen liegt auf c000/c400, char c800)
- liegt wenn moeglich zwischen 0400 und 7fff

bis jetzt habe ich nur SMON probiert, der die punkte 1 und 4 erfuellt, aber die beiden anderen leider nicht...

gibt es da hoffnung?

Ciao, ALeX.

Zitat

Original von sauhund
? wie kommst du mit 8 bit auf mehr als 2^8 möglichkeiten ? du meintest warscheinlich die periodenlänge oder?

Ja, erst nach 64k kommen die gleichen muster wieder (die gleiche zahl haeufiger) also das koennte man wohl periodenlaenge nennen...
die periodenlaenge war mir wichtig, da die schnellen periodischen zufallszahlen sich alle 256 zeichen wiederholen (sogar einige 16bit randoms wiederholen sich alle 256!!).

Hi,

fuer den fall das das heir jemanden interessiert, ich hab' mal 'ne routine geschreiben, die 8bit zahlen liefert, die sich erst alle 64k wiederholen, nicht soo schnell ist, aber es ist halt wie ueblich ein seed, der dann immer die selben "zufallszahlen" liefert, was manchmal sehr praktisch seinen kann. bei interesse suche ich sie heraus, und poste sie hier.

Ciao, ALeX.

Hi,

Retrofan hat jetzt ein neues problem mit seinem mmc2iec:
- wenn man (speeddos) "@" eingibt, kommen alle antworten ohne zeilenumbruch
- wenn man (speeddos) "@UI" eingibt, kommt "0" (auch ohne zeilenumbruch) und ein paar mal danach gibt "@" nix aus, bis dann wieder 00,ok.
- "@$" (auch speeddos) gibt immer zwei eintraege in einer zeile aus (wobei zwischen den zwei eintraegen "char-muell" ist.
- ein "normales" load (file/dir) klappt (speeddos/original)
- exakt das speeddos macht im emulator keine macken (siehe 1-3)

ist das reparabel?

Ciao, ALeX.

Hi,

ich vermute mal, das man den dtv auch an den fernsehe anschliessen kann, also PAL liefert.
Der monitor muss also folgendes darstellen koennen:
- hsync 50 Hz
- vsync 15,x kHz
- sync on green?? oder fbas an csync?
aber das koennen nur seeehr wenige monitore, aber wenn er das kann: einfach rot, gruen, blau zusammenloeten...

Ciao, ALeX.

Moin,

Zitat

Original von Unseen

Müsste ich noch implementieren, das verwendete FAT-Modul kann es aber wohl.

klingt gut - aber wie gesagt, wird nicht jeder brauchen, aber einige?

Zitat

Wenn es auch zwischen m2i/d64 und FAT funktionieren soll wird es allerdings kompliziert, meine bisherigen Planungen gehen eher dahin, dass während eines Zugriffs auf eine mountbare Datei der Zugriff auf (nicht schon vorher geöffnete) FAT-Dateien nicht möglich ist.

da sehe ich kein problem drin

Zitat

Da fände ich es sehr toll wenn es schon ein existierendes Format geben sollte das man nachbauen kann statt schon wieder was eigenes zu machen.

ide64 hat soetwas, aber keine ahnung wie, was, warum...

Zitat

PETSCII-Wandlung? Welche PETSCII-Wandlung?

wie gesagt, nur wenn auch kleine buchstaben ins spiel kommen

Zitat

sd2iec konvertiert bisher nur das C64-Pi in ~, die Namen passen zufälligerweise weil FAT ohne LFNs nur Grossschrift speichert und das C64-Kleinbuchstaben sind.

also petscii (unshiftet) und ascii sind von 0x20 bis 0x5b und in 0x5d identisch - also in der regel kein problem, und was die pi-~ konvertierung betrifft, da muss ja nix gemacht werden, da die auf dem selben zeichen liegen - also vorausgesetzt, das alle doppelten petscii zeichen (>= 0xc0) auf die originale umgewandelt werden.

Ciao, ALeX.

Zitat

Original von sauhund

die ist btw zur erkennung des laufwerks nur bedingt geeignet.... zumindest bei 154x/7x/81 sollte man noch zusätzlich ein paar signifikante stellen im rom checken, sonst stolpert man schnell über einen der zahlreichen floppy speeder.

Ok, aber systeme die "00,OK" oder aehnliches liefern sind auch nicht so pralle, und ich kann nicht direkt bei jedem geraet auf's rom zugreifen, da das noch lange nicht ueberall emuliert wird, oder?

P.S.: kann mir trotzdem jemand auf meine urspruengliche frage bzgl. iecata antworten?

Hi,

aus sicht eines file browers programmierers haette ich gerne:
- ordendliche antwort auf "UI"
- in verz. wechseln
- in uebergeordnetes verz. wechseln
- in root verz. wechseln
- optional: in relatives/absolutes verz. wechseln ("a/b" / "/c/a/b")
- verz. erstellen
- verz. loeschen
- move (wie rename, aber auch zw. verzeichnissen) [auch wenn soetwas im FIBR nicht vorgesehen ist]
- optional: "long listing" welches folgendes ausgibt: name, groesse (bytes), erst. datum, ...

bei unterstuetzung von kleinen buchstaben ist auf eine moeglichst gute umwandlung zu petscii zu achten (optional: kleinschrift ein/ausschaltbar, oder nur in "ll")

so, das war's fuers erste...

Ciao, ALeX.

Hi,

wenn wirklich jeder nur EINE hardware da hat, waere es viel einfacher, richtig.
aber ich bin mir sicher, das mal jemand was von seinem ide64 auf eine 1541 kopieren will (zwei hardware!) oder auf seinem mmc2iec in ein "d64" gehen will (fast wie 2 hardware).
also macht es nach meiner auffassungsgabe keine sinn nur fuer eine hardware zu programmieren.
und wenn ich schon mehrere (und wenn es nur 2 sind) unterstuetzte, so ist der unterschie auch noch ein paar mehr zu unterstuetzten sehr gering.

Ciao, ALeX.

Hallo,

ich wuerde gerne das IECATA im FIBR untestuetzten, brauche dafuer aber noch ein paar infos:

was liefert das IECATA zurueck, wenn man den befehl "UI" sendet?
(Ich hoffe so was wie "73,IECATA,00,00")

welche befehle machen folgendes:
- in ein verz. wechseln ("CD:dir" ?)
- zurueck gehen ("CD<", "CD:<" ?) [< = linkspfeil]
- in das root verz. gehen ("CD:/" ?)

was muss ich machen, um das geraet z.B. nach einem karten wechsel zum neu laden zu bringen? (einfach das root verz. neu laden, oder "I", oder ... ?)

Ciao, ALeX.

P.S.: was muss ich machen, damit er nicht ← sondern das zeichen darstellt? (ich hab das zeichen direkt eingegeben, und er wandelt es um, aber zeigt es nicht an...

Hi,

ich weiss, das es hier bereits mehrere solcher threads gibt, aber evtl. sollte man alles mal sammeln?

Ich interessiere mich im speziellen fuer freie ZP's, wenn man BASIC gar nicht benutzt, und solche die wenn ich gerade nix kernal maessiges am laufen habe, frei sind.

drch das scannen des kernals (von http://www.ffd2.com/fridge/docs/c64-diss.html ohne basic) habe ich folgendes herausgefunden:

Ok, so weit so gut, an dieser stelle wuerde ich mich freuen, wenn ihr mir helft die liste zu vervollstaendigen.

Ciao, ALeX.

Hi,

natuerlich will ich einen fehler im programm nicht auschliessen...
aber wenn ich nicht die 1541 routine sonder z.B. die power64 routine (welche problemlos mit verzeichnissen mit <11 eintraegen klar kommt) nehme, tritt der fehler trotzdem auf.
also ist es was, was speziell mit der 1541 zusamenhaengt, nur wo bzw. wie oder waum?

Ciao, ALeX.

Nachtrag: ich ignoriere diesen bug bis auf weiteres, solange keiner keiner eine idee hat. (in der beta kann ja jeder testen...)

Moin,

ich schreibe ja grad' den FIBR (siehe thread in Neue Hardware) und hab' da einen sehr komischen bug, den ich mir nicht erklaeren kann...

also, was so passiert (oder auch nicht):
- das programm ist per >LOAD "FIBR.PRG",8< zu laden
- dann mit >RUN< starten
- an dieser stelle wird etliches im speicher initialisiert, das basic-rom abgeschaltet, das programm umkopiert, ein zeichensatz umkopiert, der vic auf bank 3(c0-ff) gestellt, der screen(c4)&charset(c8) eingestellt
- hier wartet das programm auf ein taste (*)
- noch mehr initialisierung
- identifizieren des letztgenuztenlaufwerks mit "UI" (**)
- lesen des verzeichnisses "$"
- lesen (fast) aller load-adressen (also die ersten 2 bytes [fast] aller dateien, 0.1s pause vor jedem lesen)
- anzeigen!
- optional: disk wechseln oder nicht - bei ** wieder beginnen

(alles ab hier passiert nur im emulator vice & power64, 1541-emu: fast & full getestet)
wenn ich das programm direkt (also aus einem verzeichnis) lade, klappt alles!
wenn ich das programm in eine d64 packe und lade klappt bis * alles, danach gibt's komische bugs (s.u.)
wenn ich das programm in eine d64 packe, lade und bei * die disk wechsle oder rausnehme oder ... klappts!

zu den fehlern:
- (ich schalte immer zwischen 2 screen um) der falsche wird angezeigt
- die farben passen nicht (z.B. [fast] alles schwarz)
- das charset wird geschrottet (tritt aber nur an einer bestimmten stelle auf)

speicherplan (grob)
- 1k "wie immer" (ausser, das ich so einige zero pages nutzte)
- 32k (4 bloecke a 8k) fuer verzeichnis listings
- 7k daten (nicht voll genutzt)
- 8k programm (nicht voll genutzt)
- 2k screen (2 screens)
- 2k char rom
- rest (ab d000) unveraendert

beim lesen des verzeichnisses achte ich (bis jetzt) nicht auf die laenge, es koennte also schaden verursachen, aber nur wenn es ueber 31.5k lang ist(!)

ich habe nach dem laden (vor dem run) zwei memory dumps gemacht (verz. und disk laden) und der bereich, in dem das prog ist, war identisch.

wo kann der fehler liegen?

Ciao, ALeX.

P.S.: gibt's irgendwo eine liste von bugs, die zu beachten sind?
{beispiel: jmp ($xxff) klappt nicht wie gewuenscht}
P.P.S.: wie schalte ich die smilies aus? (s.o.)

Moin,

so Jungs, haltet mal den Ball flach.

Noch kann es nicht auch nur annaehernd so viel wie es spaeter mal solte.
Dauert also noch ein bisschen...

Fuer die erste "public beta" ist folgendes geplant:
- durch verzeichnisse gehen
- starten von prorammen
- evtl. preferences
mit folgender hardware:
- 1541 (und alles was sich so verhaelt)
- mmc2iec
- ide64
- evtl. iecata (muss mir mal die doku anschaun)
- verzeichnisse in vice und power64 (seehr praktisch zum testen)

und wenn das grundsystem dann passt, geht's weiter.

ich melde mich wenn's was gibt, oder ich alpha-tester brauchen sollte.

Ciao, ALeX.

Moin,

und nun ist ein weiteres problem aufgetaucht:
ich oeffne jede datei (eins verzeichnisses), lese ein bisschen, und schliesse sie ohne alles zu lesen.
wenn ich alle fehler still uebergehe, klappt das erste mal, und dann nicht mehr.
wenn ich fehler ausgebe kommt da "DEVICE NOT PRESENT" und nachdem man bestaetigt hat klappt die naechste wieder, aber dann wieder fehler und so weiter...
wie immer auf retrofan's hardware gestetet.
(selbst die voll-floppy-emulation hat damit keine probleme)

Ciao, ALeX.

Hi,

Zitat

Originally posted by UnseenWarum liest du eigentlich genau 8 Byte in der inneren Schleife? Wenn du damit alles vor dem Dateinamen überspringen willst: Das klappt schon mit einer 1541 nicht, vor dem Dateinamen werden je nach Blockanzahl mehr oder weniger Leerzeichen gesendet, damit die Namen im Listing untereinander stehen und nicht bei >10/>100 Blöcken verschoben sind.

Ich wollte sehen, was genau das mmc2iec antwortet, und 8 bytes kann man schoen per zeile darstellen, und dann halt 20 zeilen - alles nur zum testen - nix sinnvolles.

ach ja, danke fuer die antwort.

Ciao, ALeX.

Moin,

Zitat

Originally posted by Unseen

Mindestens MMC2IEC kennt kein M-R. sd2iec wird es demnächst kennen, aber mehr oder weniger zufällige Daten zurückliefern.

Also bis jetzt klappt die identifikation ueber "UI" gut... mehr demnachst.

Ciao, ALeX.

Moin,

hier ein kleines basic programm, was auch emuliert super laeuft, aber auf'm mmc2iec einen device not present in zeile 30? schmeisst, wie retrofan berichtete. eigentlich brauche ich das programm auch nicht mehr, aber wuerd' mich trotzdem interessieren, woran es liegt?

Ciao, ALeX.