Νέος σχεδιασμός κασέτας: ROMBA π

[doragasu]

Κάποιοι ίσως θυμούνται το ROMBA, μια πλακέτα (cart) που κυκλοφόρησα πριν από σχεδόν 10 χρόνια, που ήταν ένα Rombox με ορισμένες περιορισμένες δυνατότητες DMA. Όσο καθόταν εκεί, ο καιρός περνούσε, ήρθε ο COVID, το CPLD που χρησιμοποιεί εκείνη η πλακέτα πήγε από κάτω από 2€ το κομμάτι σε πάνω από 10€ το κομμάτι, και οι ελάχιστοι άνθρωποι που ενδιαφέρονταν για την πλακέτα έχασαν το ενδιαφέρον τους.

Καθώς φαίνεται ότι η τιμολόγηση των CPLD με μεγάλο αριθμό I/O δεν θα πέσει ποτέ ξανά στα επίπεδα που ήταν, πριν από λίγο καιρό άρχισα να σκέφτομαι τη δημιουργία ενός νέου σχεδίου με στόχο, για άλλη μια φορά, το χαμηλό κόστος κατασκευής, προσθέτοντας παράλληλα μερικά επιπλέον χαρακτηριστικά. Γνωρίστε το ROMBA π (ή ROMBA 3.14):

Ο σχεδιασμός βασίζεται στον RP2350B, έναν μικροελεγκτή «pi-pico2» αντί για CPLD. Αυτοί οι μικροελεγκτές είναι φθηνοί, με άφθονα 5V-tolerant pins και υποστηρίζουν έως και 16 MiB φθηνής μνήμης flash QSPI. Η πλακέτα συνδέεται στη θύρα επέκτασης (expansion port) και, όπως συνέβαινε και με την παλαιότερη πλακέτα μου ROMBA, μπορεί να συνδεθεί απευθείας χρησιμοποιώντας έναν edge connector ή μέσω μιας πλακέτας MX4 χρησιμοποιώντας έναν DIL connector.

Η χρήση ενός MCU αντί για CPLD/FPGA για τη διασύνδεση παράλληλου διαύλου (parallel bus), σε συνδυασμό με τη χρήση flash QSPI αντί για παράλληλη NOR flash, έκανε το εγχείρημα αρκετά δύσκολο ώστε να λειτουργήσει ως Rombox, λόγω των καθυστερήσεων (latencies) που συνεπάγεται το polling του διαύλου και η ανάγνωση από το τσιπ QSPI, αλλά επιτέλους τα καταφέραμε!

Τα χαρακτηριστικά που έχουν υλοποιηθεί μέχρι στιγμής είναι:

• Χωρητικότητα Flash ROM έως 16 MiB (128 megabits). Το μεγαλύτερο μέρος είναι αξιοποιήσιμο ως μνήμη ROM για τον CPC, με εξαίρεση το μέγεθος που καταλαμβάνει το firmware (το οποίο επί του παρόντος είναι περίπου 48 KiB, αλλά αναμένεται να αυξηθεί εάν προστεθούν περισσότερες δυνατότητες).
• Θύρα USB host. Επί του παρόντος έχει υλοποιηθεί υποστήριξη ποντικιού, αλλά θα μπορούσαν να προστεθούν και άλλες περιφερειακές συσκευές USB.
• Η υποστήριξη ποντικιού περιλαμβάνει παραμετροποιήσιμη κλασματική κλίμακα (fractional scaling) για τη ρύθμιση της ευαισθησίας από την πλευρά του CPC, με ανεξάρτητη ρύθμιση για X, Y και τροχό κύλισης.
• Συμβατό με Amstrad CPC Romboxes (έως 256 θέσεις/slots).
• Hardware DMA που μπορεί να χρησιμοποιηθεί για την αντιγραφή δεδομένων από τη ROM στην εσωτερική RAM (1 byte ανά μικροδευτερόλεπτο).
• Ο μηχανισμός DMA μπορεί να κάνει αντιγραφή σε linear mode και σε 2D mode, επιτρέποντας την αντιγραφή tiles στη μνήμη της οθόνης χωρίς να χρειάζεται να ανησυχείτε για τις ιδιομορφίες του CRTC και του GA.
• Ο μηχανισμός DMA σε 2D mode υποστηρίζει επίσης επιτόπιο καθρεφτισμό πλακιδίων (on the fly tile mirroring) και για τα 3 γραφικά modes.

Η υποστήριξη για τις παραπάνω λειτουργίες είναι σταθερή, αλλά δεν θα θεωρούσα το firmware ολοκληρωμένο ως προς τα χαρακτηριστικά του όπως είναι τώρα (περισσότερα για αυτό παρακάτω). Το hardware επιτρέπει επίσης την προσθήκη υποστήριξης για τα ακόλουθα:

• Μετατόπιση εικονοστοιχείων (pixel shifting) για tiles.
• Μάσκα εικονοστοιχείων (pixel masking) για tiles (προς το παρόν υλοποιημένη, αλλά μόνο σε επίπεδο byte granularity).
• Υποστήριξη Lower ROM.
• Πιο σύνθετη χαρτογράφηση μνήμης (memory mapping).
• Επέκταση RAM (ο MCU διαθέτει 512 KiB RAM, και το μέγεθος που δεν χρησιμοποιείται από το firmware θα μπορούσε να χρησιμοποιηθεί ως CPC RAM).
• Δυνατότητες ήχου (FM δυνατότητες, αναπαραγωγή δειγμάτων PCM).
• Αποθήκευση δεδομένων σε Flash.
• Προγραμματιζόμενη γεννήτρια NMI.
• Υποστήριξη για DMA από την εσωτερική RAM του CPC στην εσωτερική RAM του CPC (προς το παρόν υποστηρίζεται μόνο από ROM σε RAM).

Εδώ μπορείτε να δείτε την υποστήριξη ποντικιού στην πράξη:

ROMBA π USB mouse support (Amstrad CPC)

Ο SyX έχει προσαρμόσει (patchάρει) μια σειρά από παιχνίδια για να υποστηρίζουν ποντίκι και θα έπρεπε να κάνω ένα βίντεο και για μερικά από αυτά . Με βοήθησε επίσης πολύ σε θέματα όπως η κατανόηση της διάταξης της μνήμης βίντεο, καθώς και με μερικά snippets κώδικα και προγράμματα για δοκιμές.

Και εδώ μπορείτε να δείτε τις δυνατότητες 2D DMA σε δράση:

ROMBA π 2D DMA capabilities (Amstrad CPC)

Αυτό το sprite είναι 32x64 pixels (mode 0) και το DMA χρειάζεται περίπου 1 ms για να το σχεδιάσει (σχεδιάζει δύο pixels του mode 0 ανά μικροδευτερόλεπτο). Ο μηχανισμός 2D DMA κάνει επίσης καθρεφτισμό on the fly μέσω hardware και διαχειρίζεται το screen clipping και masking (αλλά στην τρέχουσα έκδοση όλα γίνονται μόνο σε επίπεδο byte, άρα δύο pixels του mode 0).

Τόσο το hardware όσο και το firmware κυκλοφορούν ως Open Source. Η τεκμηρίωση σχετικά με τον προγραμματισμό για αυτά λείπει προς το παρόν, αλλά σκοπεύω να την προσθέσω αργότερα.

Τώρα, σχετικά με την τρέχουσα «ημιτελή» κατάσταση του firmware. Ήθελα να προσθέσω τα περισσότερα (αν όχι όλα) τα χαρακτηριστικά που αναφέρονται παραπάνω και δεν έχουν ακόμη υλοποιηθεί. Φαίνεται όμως ότι ένα μεγάλο κομμάτι (ίσως η πλειοψηφία;) της κοινότητας του CPC ενδιαφέρεται μόνο για επιτεύγματα σε επίπεδο λογισμικού και βλέπει αυτές τις επεκτάσεις hardware ως «anti-features», ως «αυτό δεν είναι πια CPC» και άλλα παρόμοια. Οπότε, αντί να ρίξω περισσότερη προσπάθεια σε αυτό, σταματώ την ανάπτυξη μέχρι να δω πραγματικό ενδιαφέρον για την πλακέτα. Δηλαδή κάποιον που να ενδιαφέρεται πραγματικά να προγραμματίσει για αυτήν την πλατφόρμα αξιοποιώντας αυτές τις δυνατότητες. Διότι, αν πρόκειται να είναι το δεύτερο σχέδιό μου για τον CPC που θα καταλήξει αχρησιμοποίητο, θα προτιμούσα να αφιερώσω τον χρόνο μου σε άλλα hardware projects που ίσως βοηθήσουν άλλους devs.

Εσείς λοιπόν τι πιστεύετε; Έχει ενδιαφέρον κάτι τέτοιο; Υπάρχει κανείς που να ενδιαφέρεται να αναπτύξει λογισμικό για αυτές τις φθηνές και ικανές πλακέτες; Ή μήπως η προσθήκη οτιδήποτε άλλου εκτός από μνήμη θεωρείται «ζαβολιά» και πρέπει να θαφτεί;

[XeNoMoRPH]

Ως λάτρης του hardware του CPC, θα ήθελα πολύ να ολοκληρωθεί το project, αν και δεν είμαι προγραμματιστής και δεν μπορώ να φτιάξω τίποτα.

[SagaDS]

Αν αυτό είναι φθηνό και χρήσιμο (προσθήκη ROM / RAM / Ποντικιού / κάποιου είδους γρήγορου χειρισμού sprite), δεν βλέπω γιατί να μην έχει ενδιαφέρον…
Τα παιχνίδια τύπου populous / god games θα μπορούσαν να χρησιμοποιήσουν το ποντίκι ως έναν ευκολότερο τρόπο χειρισμού. Ακόμα κι εγώ, μπορώ να τροποποιήσω το παιχνίδι ναρκαλιευτή μου για να το χρησιμοποιεί
Με το Vespertino να ζητάει μια πλακέτα των 4MB για να μπορεί κανείς να το παίξει, υπάρχει περιθώριο για καλά παιχνίδια με λίγη βοήθεια από άποψη υλικού . Και χρησιμοποιούν πολύ ROM αν δεν κάνω λάθος.

Όσον αφορά τη μελλοντική σου υποστήριξη, θα έλεγα κατά σειρά προτεραιότητας:

• Επέκταση RAM (είναι πάντα ευπρόσδεκτη σε νέο hardware)
• DMA CPC RAM σε CPC RAM για γρήγορη μεταφορά μνήμης
• Μετατόπιση / απόκρυψη pixel (pixel shifting / masking) για tiles
• Δυνατότητες ήχου (τα samples με μικρή επιβάρυνση στην ταχύτητα/μνήμη είναι ωραία προσθήκη
• Αποθήκευση δεδομένων σε Flash
• Υποστήριξη Lower ROM

Για τα υπόλοιπα σημεία, δεν μου είναι αρκετά ξεκάθαρα ώστε να δώσω feedback (πιο πολύπλοκη χαρτογράφηση μνήμης / Προγραμματιζόμενο NMI). Δεν βλέπω πού θα μπορούσα να τα χρησιμοποιήσω.

[Gryzor]

Μου κίνησες το ενδιαφέρον!

[SoftDevil]

Βρίσκω την παρουσίασή σου (doragasu) εξαιρετικά ενδιαφέρουσα

… εδώ και λίγο καιρό πειραματίζομαι φτιάχνοντας ένα «GOD GAME» (παρόμοιο με το Populous). Ό,τι κι αν δοκιμάσω, αντιμετωπίζω συνεχώς πολύ σοβαρά και εξίσου επίμονα προβλήματα απόδοσης (performance bottlenecks). Θα ήθελα πολύ να δοκιμάσω το νέο υλικό (ROMBA π για sprites καθώς και ποντίκι), μόλις είναι διαθέσιμο. Τα sprites θα μπορούσαν να βοηθήσουν με τα «ανθρωπάκια που κινούνται ασταμάτητα» (=software sprites) στον χώρο του παιχνιδιού.

Η προσωπική μου πρόκληση: Δεν έχω πια CPC. Κάποτε αναγκάστηκα να τον πουλήσω. Πλέον δουλεύω μόνο με εξομοιωτές (emulators).

Ιδέα: Αν εσύ (doragasu) μου δώσεις τις προδιαγραφές (specs), θα ρίξω μια πιο προσεκτική ματιά στον CPC εξομοιωτή Caprise32, για να δω αν μπορούμε να επεκτείνουμε σε επίπεδο λογισμικού τον Caprise32 ώστε να υποστηρίζει το υλικό σου. Εναλλακτικά, θα μπορούσε να δημιουργηθεί μια πλακέτα-προσαρμογέας (adapter board) για να χρησιμοποιηθούν οι θύρες GPIO ενός Raspberry Pi ως θύρα επέκτασης (expansion port) του CPC. (Κάπως τρελό, αλλά ταυτόχρονα και ενδιαφέρον). Δεν έχω κοιτάξει ακόμα τον κώδικα του Caprise32, αλλά ίσως όλοι μαζί (η κοινότητα) να βρούμε μια κατάλληλη ιδέα…

[eto]

Ακούγεται ενδιαφέρον. Ειλικρινά, εξεπλάγην που πήρε τόσο καιρό μέχρι να χρησιμοποιηθεί το RP2350B για μια τέτοια επέκταση πολλαπλών δυνατοτήτων.

Ένα πράγμα που θα σκεφτόμουν: αν συνδεθεί ταυτόχρονα μια άλλη επέκταση που περιέχει RAM, είναι πολύ πιθανό να υπάρξει διένεξη, καθώς θα λειτουργούν πάντα παράλληλα. Π.χ. ένα DDI-5 εξακολουθεί να έχει νόημα παράλληλα με τη δική σου επέκταση. Ίσως θα έπρεπε να προστεθεί ένας διακόπτης για την απενεργοποίηση της RAM για τέτοια σενάρια.

[doragasu]

Ευχαριστώ για το ενδιαφέρον.

@SoftDevil Θα γράψω τις προδιαγραφές αργότερα, μόλις βρω λίγο χρόνο. Η διεπαφή του ποντικιού θα πρέπει να θεωρείται οριστική ως έχει. Ως μια πρώτη γεύση, δείτε πώς λειτουργεί. Χρησιμοποιεί τις θύρες I/O $F990 έως $F993:

Θύρα	Ανάγνωση	Εγγραφή	Προεπιλογή
$F990	STAT	N/A	N/A
$F991	WHEEL_BTN	WHEEL_SCALING	64 (1.0)
$F992	X_AXIS	X_SCALING	32 (0.5)
$F993	Y_AXIS	Y_SCALING	32 (0.5)

• STAT: το bit 0 είναι 1 εάν το ποντίκι είναι συνδεδεμένο, 0 εάν δεν είναι συνδεδεμένο.
• WHEEL_BTN: τα 5 υψηλότερα bit είναι η διαφορά ανάγνωσης του τροχού (από την τελευταία ανάγνωση) σε συμπλήρωμα ως προς δύο, θετική για κίνηση του τροχού προς τα πάνω, αρνητική για κίνηση προς τα κάτω. Τα χαμηλότερα 3 bit είναι η τρέχουσα κατάσταση των κουμπιών: M, R, L.
• X_AXIS: διαφορά στον άξονα X (από την τελευταία ανάγνωση) σε συμπλήρωμα ως προς δύο των 8-bit. Θετική για κίνηση προς τα δεξιά, αρνητική για κίνηση προς τα αριστερά.
• Y_AXIS: διαφορά στον άξονα Y (από την τελευταία ανάγνωση) σε συμπλήρωμα ως προς δύο των 8-bit. Θετική για κίνηση προς τα πάνω, αρνητική για κίνηση προς τα κάτω.
• WHEEL_SCALING: κλασματικός συντελεστής κλίμακας του τροχού.
• X_SCALING: κλασματικός συντελεστής κλίμακας του άξονα X.
• X_SCALING: κλασματικός συντελεστής κλίμακας του άξονα Y.

Όταν διαβάζετε τον τροχό και τους άξονες, λαμβάνετε τη διαφορά από την τελευταία ανάγνωση και η τιμή επανέρχεται στο 0. Οι τιμές φτάνουν στον κορεσμό στο μέγιστο/ελάχιστό τους (15 έως -16 για τον τροχό, 127 έως -128 για τους άξονες) εάν μετακινήσετε το ποντίκι γρήγορα ή αν μεσολαβήσει πολύς χρόνος μεταξύ των αναγνώσεων.

Οι συντελεστές κλίμακας επιτρέπουν τη ρύθμιση της ευαισθησίας του ποντικιού. Είναι σε μορφή σταθερής υποδιαστολής Q1.6 (1 bit προσήμου, 1 bit για το ακέραιο μέρος, 6 bit για το κλασματικό μέρος). Για να πάρετε την τιμή κλίμακας, πρέπει να διαιρέσετε με το 2^16 = 64. Έτσι, ένας συντελεστής κλίμακας 64 αντιστοιχεί σε 1.0, μία κλίμακα 32 σε 0.5, μία κλίμακα 20 σε 20/64 = 0.3125 και ούτω καθεξής.

Η χρήση αρνητικών τιμών κλίμακας έχει ως αποτέλεσμα την αναστροφή του άξονα (π.χ. αν ορίσετε τον άξονα Y σε 0xE0, που αντιστοιχεί σε -0.5, εκτός από τον συντελεστή κλίμακας 0.5, η κίνηση προς τα πάνω θα σας δίνει αρνητικές τιμές και η κίνηση προς τα κάτω θετικές τιμές). Η χρήση του 0 ως τιμή κλίμακας ουσιαστικά απενεργοποιεί αυτόν τον άξονα.

Κάθε άξονας μπορεί να ρυθμιστεί ξεχωριστά. Αυτό είναι χρήσιμο για παράδειγμα για την αναστροφή συγκεκριμένων αξόνων όπως εξηγήθηκε παραπάνω, αλλά και επειδή μερικές φορές χρειάζονται διαφορετικές τιμές για κάθε άξονα. Για παράδειγμα, το mouse patch του Operation Wolf παίζεται πολύ καλύτερα με την κλίμακα X ρυθμισμένη στο 16 (0.25) και την κλίμακα Y στο 32 (0.5), παρά με την ίδια κλίμακα και για τα δύο.

Όσον αφορά το DMA, δεν έχω χρόνο αυτή τη στιγμή να εξηγήσω όλους τους καταχωρητές, αλλά θα το κάνω αργότερα. Επίσης, εάν η ανάπτυξη του firmware συνεχιστεί, αυτό αναμένεται να αλλάξει. Πάρα πολύ. Βρίσκονται από το $FC00 έως το $FC0F:

enum rdma_reg {
	RDMA_REG_DMASRCL = 0,
	RDMA_REG_DMASRCH,
	RDMA_REG_DMASRCU,
	RDMA_REG_2D_MASK,      // Για λειτουργία 2D, δεν αντιγράφει αν η μάσκα ταιριάζει
	RDMA_REG_DMADSTL,
	RDMA_REG_DMADSTH,
	RDMA_REG_DMALENL,
	RDMA_REG_DMALENH,
	RDMA_REG_SCR_WIDTH,    // Σε χαρακτήρες, π.χ.: 40
	RDMA_REG_SCR_HEIGHT,   // Ύψος γραμμής - 1 και ύψος σε χαρακτήρες: lllhhhhh (π.χ. 0xF9)
	RDMA_REG_2D_W,         // Σε bytes. ΣΗΜΕΙΩΣΗ: το ύψος προκύπτει από το LEN
	RDMA_REG_2D_X,         // Σε bytes, με πρόσημο
	RDMA_REG_2D_YL,        // Σε γραμμές, με πρόσημο
	RDMA_REG_2D_YH,
	RDMA_REG_DMACTRL2,
	RDMA_REG_DMACTRL1,
	__RDMA_REG_MAX
};

// Μάσκες καταχωρητή DMACTRL1
enum rdma_reg_dmactrl1 {
	RDMA_DMACTRL1_START_LSB = 0,    // Εκκίνηση DMA όταν είναι 1
	RDMA_DMACTRL1_SRCINC_LSB = 1,   // Ενεργοποίηση αυτόματης αύξησης SRC
	RDMA_DMACTRL1_DSTINC_LSB = 2,   // Ενεργοποίηση αυτόματης αύξησης DST
	RDMA_DMACTRL1_2D_MASK_LSB = 3,  // Ενεργοποίηση μάσκας 2D όταν είναι 1
	RDMA_DMACTRL1_2D_XMIR_LSB = 4,  // Ενεργοποίηση κατοπτρισμού στον X
	RDMA_DMACTRL1_FULLADDR_LSB = 6, // 0: χρήση bank, 1: διεύθυνση 24 bit
	RDMA_DMACTRL1_MODE_LSB = 7,     // 0: τυπικό, 1: 2D
	RDMA_DMACTRL1_START_MASK = BIT(RDMA_DMACTRL1_START_LSB),
	RDMA_DMACTRL1_SRCINC_MASK = BIT(RDMA_DMACTRL1_SRCINC_LSB),
	RDMA_DMACTRL1_DSTINC_MASK = BIT(RDMA_DMACTRL1_DSTINC_LSB),
	RDMA_DMACTRL1_2D_MASK_MASK = BIT(RDMA_DMACTRL1_2D_MASK_LSB),
	RDMA_DMACTRL1_2D_XMIR_MASK = BIT(RDMA_DMACTRL1_2D_XMIR_LSB),
	RDMA_DMACTRL1_FULLADDR_MASK = BIT(RDMA_DMACTRL1_FULLADDR_LSB),
	RDMA_DMACTRL1_MODE_MASK = BIT(RDMA_DMACTRL1_MODE_LSB),
};

// Μάσκες καταχωρητή DMACTRL2
// ΡΥΘΜΙΣΗ ΚΑΤΟΠΤΡΙΣΜΟΥ:
// 0b00: χωρίς κατοπτρισμό
// 0b01: κατοπτρισμός mode 0
// 0b10: κατοπτρισμός mode 1
// 0b11: κατοπτρισμός mode 2
enum rdma_reg_dmactrl2 {
	RDMA_DMACTRL2_XMIRR_LSB = 0, // Κατοπτρισμός στον άξονα X
	RDMA_DMACTRL2_XMIRR_MASK = 0x3,
};

Ουσιαστικά, κατά την αρχικοποίηση πρέπει να ρυθμίσετε μια σειρά από παραμέτρους που σχετίζονται με τη γεωμετρία της οθόνης, τη θέση της μνήμης βίντεο, τη διεύθυνση προέλευσης του sprite κ.λπ. Στη συνέχεια, γράφετε τα flags X, Y και mirror όπως χρειάζεται, και ξεκινάτε τη συναλλαγή DMA γράφοντας στο DMACTRL1. Εάν αυτό εξελιχθεί, η ιδέα θα ήταν να υπάρχουν αρκετά προρυθμισμένα sprites, αλλά προς το παρόν έχετε μόνο αυτό το σύνολο καταχωρητών, οπότε για παράδειγμα, για να σχεδιάσετε ένα δεύτερο sprite, θα πρέπει να σχεδιάσετε το πρώτο, στη συνέχεια να αλλάξετε τη διεύθυνση προέλευσης για το νέο sprite, τις διαστάσεις αν αλλάζουν κ.λπ., και μετά να το σχεδιάσετε.

Σχετικά με όσους θέλουν να αποκτήσουν μια πλακέτα (cart) για δοκιμές: εάν υπάρχει αρκετό ενδιαφέρον μπορώ να φτιάξω μερικές, αλλά ίσως χρειαστώ κάποιες συμβουλές για πράγματα όπως τα μεταφορικά, καθώς είναι κάτι που δεν έχω ξανακάνει. Ζω στην Ισπανία, οπότε ίσως η αποστολή εντός Ευρώπης να μην είναι προβληματική, αλλά εκτός ίσως να αποτελεί πρόβλημα.

[SagaDS]

Γεια σας, ενσωμάτωσα υποστήριξη ποντικιού στον κλώνο μου του ναρκαλιευτή (minesweeper clone) (χωρίς κλιμάκωση X/Y προς το παρόν, αλλά έχω προετοιμάσει τον κώδικα).

Φαίνεται όμως ότι το winape επιστρέφει bit0 = 1 στη θύρα F990 και έτσι είναι ενεργοποιημένο (ON) από προεπιλογή (και οι τιμές για deltaX deltaY είναι -1 από προεπιλογή), οπότε ίσως το 0xFF όταν δεν απαντά τίποτα σε μια θύρα να είναι «φυσιολογικό» (δεν γνωρίζω καθώς δεν χρησιμοποιώ πολύ hardware).

Έχετε κάποιον άλλο τρόπο για να διαπιστωθεί εάν το ROMBOX pi είναι παρόν, ώστε να ελέγχεται η θύρα μόνο όταν είναι δυνατόν; Ή ίσως να αντιστραφεί το bit 0 ή να δοθεί μια συγκεκριμένη τιμή για έλεγχο (όχι μόνο ένα bit) όπως 142 ή 155;

Αν θέλετε να το δοκιμάσετε με την κάρτα σας και να μου πείτε αν όλα είναι εντάξει, θα σας το στείλω με προσωπικό μήνυμα (DM).

[CPC-International]

Σωστά. Καλύτερα να ξεφορτωθούμε το DDI5 εξ αρχής και να βάλουμε την προσομοίωση δίσκου (disk emulation) στην ίδια κάρτα Ο RP2350 μπορεί να χειριστεί και τα δύο https://youtube.com/playlist?list=PLa1DevUxKDmU&si=sxcJhFYr4qiDhYtl Πιθανότατα θα προσθέσουμε επέκταση RAM πέρα από τη ROM και την προσομοίωση δίσκου για την επόμενη αναθεώρηση του PCB. Αυτή εδώ δεν έχει τα απαιτούμενα pins. Κάπου πρέπει να γίνει ένας συμβιβασμός. Από την άλλη βέβαια, υπάρχουν διαθέσιμες εξαιρετικές επεκτάσεις RAM, όπως του Revaldhino. Αλλά μια συσκευή όλα-σε-ένα είναι σίγουρα ελκυστική.

Σε κάθε περίπτωση, ο RP2350 ΕΙΝΑΙ ΦΟΒΕΡΟΣ!!