Nicht Retro, aber eindeutig Retrobezug:
Gibt es die DOS bzw Foren Sticker eigentlich noch?
Ich habe noch einige. Kann dir ein paar mal in einen Brief stecken.
Nicht Retro, aber eindeutig Retrobezug:
Gibt es die DOS bzw Foren Sticker eigentlich noch?
Ich habe noch einige. Kann dir ein paar mal in einen Brief stecken.
Naja, auslöten muss man eh alles.
Wieso? Der Schaden ist doch örtliche total beschrenkt auf die RCT, wenn der Ram nicht erkannt wird, würde ich erstmal dort nach Ursachen schauen muss ja nichtmal mit der Batterie zusammen hängen...
Ne, ich meinte wenn man eine Replik aufbaut muss man eh alles auslöten. Klar kannst du auch das Original restaurieren. Geschmackssache. Ein frisches PCB ist vermutlich einfacher.
Leider sind die Chips nicht gesockelt, ich würde glaube ich erst mal versuchen die Platine zu reparieren...
Naja, auslöten muss man eh alles. und zur Not kriegt man ja auch neue DRAMs. Aber ich finde es cool so eine originalgetreue Erweiterung zu nutzen.
Es gibt in der Tat für die R5 auch Replika zu kaufen: https://www.ebay.com/itm/185005265288
EDIT: und R6 ebenso: https://www.ebay.com/itm/185633460414
Es gibt Sprachen mit mehr Sonderzeichen schätze ich.
Ja, und variablen Buchstaben, die zusammengesetzt werden, und rechts nach links, und und und...
Proportionalschrift nennt sich das. Viel Spaß bei der Implemetierung. Ist für Deutsch sogar halbwegs übersichtlich. Habe ich vor vieeeeelen Jahren auch mal handgeklöppelt.
Dienstag 16. Januar 2024 um 20:00 Uhr gibt's mal wieder einen Stream -- eine Lesekopftransplantation!
Von der A501+ gibts PCBs: https://www.pcbway.com/project…_A501__RAM_Expansion.html
Vielleicht auch von der A501, oder die sind austauschbar…?
Bei so was ist es gut, wenn die abgedunkelten Farben durch einfache Bitshifts erreichbar sind. Das geht zB wenn die Palette nach Helligkeit sortiert ist.
Ich glaube du hast vermutlich irgendwo durch den Speicher geschrieben mit deinem Programm. Das ist unter DOS sehr leicht möglich. Erst unter Windows, Linux und Co geht das nimmer so leicht…
Von den Machern des The64 Mini und A500 Mini:
Leider ohne funktionierende Tastatur (wie üblich bei den Mini Varianten), was bei der Folientastatur des Originals echt keine Kunst gewesen wäre.
Ja, wenn du mehr als 64K Texturen hast wirst du irgendwo mal ein Segment umschalten müssen. Aber ist das so wild? Eventuell ist es doch jetzt langsam mal sinnvoll einen Texturcache zu programmieren, der 64k hält und nach Bedarf und LRU Texturen nachlädt (aus einem anderen Segment, EMS oder con Platte) mehr als 64k kannst du pro Bildschirm ja eh nicht darstellen. Sind ja nur 320x200 Pixel…
Nach einigen Monaten Wartezeit ist es endlich angekommen: (Version für den C64)
Hast du den Satz mal alleine ausprobiert? Läuft der gar nicht? Respektive Module einzeln quergetauscht?
Ja ist ein einzelnes Modul, das in allen kombinationen nicht funktioniert...
Die Frage ist jetzt wo da genau der Fehler zu Suchen ist...
Eventuell ist dann im Transit ein Chip Hops gegangen...
CPU ist ok, aber MS empfiehlt mehr RAM.
root_42 wie realistisch ist ne Fehlersuche um den 2. 16bm Satz zum laufen zu bekommen? Bei dir hatte der ja ursprünglich funktioniert...
Hast du den Satz mal alleine ausprobiert? Läuft der gar nicht? Respektive Module einzeln quergetauscht?
DirectX kannst du vergessen.
Wenn man googled findet man Hinweise auf DX7 für NT4. Ist da was dran?
Ich würde gerne nochmal den Code insgesamt reviewen. Nur weil der Compiler keinen Fehler meldet, heißt das noch längst nicht, dass man nicht zum Beispiel undefiniertes Verhalten triggert, oder andere Fehler hat. Oftmals gehen dann solche merkwürdigen Fehler weg, wenn man solche Sachen aus dem Code rausklopft.
Markus ich glaube du hast da nen Knoten wegen Arrays und Pointern in C/C++. Eigentlich kannst du flat alles rausschreiben und auch wieder reinlesen. Dass du ein zweidimensionales Array gebaut hast dient ja nur dem einfacheren Zugriff. Foo[x][y] liefert ja den datentyp selber, Foo[x] hingegen einen Pointer auf den Datentyp. Eigentlich musst du eh nur Foo bei fwrite/fread angeben und als Anzahl Elemente x*y sowie sizeof(Datentyp) als Größe. Damit kannst du dein Array dumpen bzw. wieder einlesen. Vielleicht kann ich dazu morgen mal ein Beispiel schreiben…
...funktioniert leider alles nicht korrekt bei dem kompiler, es produziert genau die selben fehler.
Manchmal kann es nur 201 bytes lesen manchmal meckert er 0 bytes dabei sind die Dateien sogar mit 200 texturen gfüttert und haben alle 200kb.
Werde ich wohl weiterhin alles byte für byte einlesen.
Die Variante mit fopen / fread funktioniert nicht? Kann ja aber nicht Sinn der Sache sein, dass du einfach die lahmste Version nimmst, nur weil wir den Fehler nicht gefunden haben. Da gibt's ja gewiß eine logische Erklärung für.
fopen / fread
Wenn ihr da ein schnelles gutes Beispiel für hättet würde ich das gerne verwenden, dann muss ich nicht so oft umbauen. und testen.
Aus dem Kopf:
#include <stdio.h>
int main()
{
FILE *f;
char *buf[1026];
size_t bytes;
f = fopen("foo.dat","rb");
if(f == NULL) {
printf("Couldn't open file\n");
return 1;
}
while(!feof(f)) {
bytes = fread(buf,1,1026,f);
printf("%lu bytes read.\n", bytes);
}
fclose(f);
return 0;
}
Alles anzeigen
Also mit fopen öffnen, "rb" steht für "read binary", dann solange nicht ende im gelände mit fread einlesen (Zeiger auf Puffer, Größe der Elemente in Bytes, Anzahl Elemente, dann pointer auf File). Der fread Call liefert die Zahl der tatsächlich gelesenen Elemente(!) zurück. Am Ende dann die Datei mit fclose schließen.
Hach, C++ vor ISO C++98 ist einfach eine Pein. Gutes altes fopen und fread wäre vermutlich leichter...
Man müsste mal nachschauen, was die Borland Implementierung von istream so anbietet.