ROM ও ফ্ল্যাশ মেমরি

১ · ROM — Non-volatile মেমরি

L43-এ দেখা SRAM ও DRAM দুটোরই একটি সাধারণ দুর্বলতা আছে — পাওয়ার বন্ধ হয়ে গেলে সংরক্ষিত সব ডেটা মুহূর্তেই হারিয়ে যায় (এদের বলা হয় volatile মেমরি)। কিন্তু একটি কম্পিউটার প্রথম চালু হওয়ার মুহূর্তে — যখন এখনো কোনো অপারেটিং সিস্টেম লোড হয়নি, RAM-ও এখনো প্রস্তুত হয়নি — তখন প্রথম নির্দেশনাগুলো কোথা থেকে আসে? এই প্রশ্নের উত্তরই ROM (Read-Only Memory) — এমন মেমরি যা পাওয়ার ছাড়াও ডেটা ধরে রাখে (non-volatile)। ঐতিহাসিকভাবে মাস্ক ROM প্রস্তুতকালেই স্থায়ীভাবে প্রোগ্রাম করা হতো — উৎপাদনের পর একেবারেই পরিবর্তনযোগ্য ছিল না। এই non-volatility-ই এর একমাত্র গুরুত্ব নয়, বরং সবচেয়ে গুরুত্বপূর্ণ বাস্তবিক গুণ — যা দিয়ে বুট/ফার্মওয়্যার কোড নির্ভরযোগ্যভাবে সংরক্ষণ করা যায়, যা কম্পিউটার চালু হওয়ার প্রথম মুহূর্তেই প্রস্তুত থাকতে হয়।

২ · রিরাইটেবিলিটির দিকে বিবর্তন — PROM, EPROM, EEPROM

মাস্ক ROM-এর "একবারই তৈরি, কখনো বদলানো যায় না" সীমাবদ্ধতা কাটিয়ে ওঠার জন্য ধাপে ধাপে উন্নতি হয়েছে —

• PROM (Programmable ROM): উৎপাদনের পর একবার প্রোগ্রাম করা যায় — এরপর আর বদলানো যায় না।
• EPROM (Erasable PROM): UV আলোর সংস্পর্শে এনে মোছা যায় (আক্ষরিক অর্থে একটি ছোট স্বচ্ছ জানালা দিয়ে UV আলো ফেলে), তারপর নতুন করে প্রোগ্রাম করা যায়।
• EEPROM (Electrically-Erasable PROM): কোনো বিশেষ যন্ত্রপাতি বা UV আলো ছাড়াই, শুধুমাত্র বৈদ্যুতিক সিগন্যাল দিয়েই মোছা ও পুনরায় লেখা যায় — আধুনিক ফ্ল্যাশ মেমরির সরাসরি পূর্বসূরি।

৩ · ফ্ল্যাশ মেমরি — আধুনিক non-volatile স্টোরেজ

ফ্ল্যাশ মেমরি EEPROM-এর মতোই সেল ব্যবহার করে, কিন্তু একটি গুরুত্বপূর্ণ ডিজাইন পার্থক্যসহ — একক বাইট নয়, বরং বড় ব্লক একসাথে দ্রুত ইরেজ/রাইট করার জন্য অপ্টিমাইজড (একক-বাইট ইরেজ EEPROM-এ ধীর হতো)। এই ব্লক-ভিত্তিক নকশাই ফ্ল্যাশকে USB ড্রাইভ, SSD এবং এমবেডেড ডিভাইস স্টোরেজে ব্যবহারযোগ্য করে তুলেছে — যেখানে বড় পরিমাণ ডেটা দ্রুত লেখা/মোছার দরকার হয়।

একটি গুরুত্বপূর্ণ বাস্তব সীমাবদ্ধতা: প্রতিটি ফ্ল্যাশ সেল সীমিত সংখ্যক রাইট/ইরেজ সাইকেলের পর নষ্ট হয়ে যায় — কারণ প্রতিটি ইরেজ সাইকেল সেলের ভেতরের ইনসুলেটিং স্তরের উপর প্রকৃত ভৌত চাপ ফেলে, যা সময়ের সাথে সাথে জমতে থাকে। ../operating-systems/ কোর্সের SSD পাঠে এই সীমাবদ্ধতা মোকাবিলার সফটওয়্যার-স্তরের সমাধান (wear leveling — লেখা সব সেলে সমানভাবে ছড়িয়ে দেওয়া) কভার করা হয়েছে; এখানে আমরা শুধু বুঝছি কেন এই সীমা আসলে অস্তিত্বশীল — এটি একটি হার্ডওয়্যার-স্তরের সত্য যা সফটওয়্যার সমাধানের প্রয়োজনীয়তা তৈরি করে।

# চারটি মেমরি টেকনোলজির তুলনা -- volatile/non-volatile পার্থক্যটাই সবচেয়ে গুরুত্বপূর্ণ কলাম
memory_types = {
    "ROM":   {"volatile": False, "rewritable": "না (বা EEPROM/ফ্ল্যাশ ভ্যারিয়েন্টে সীমিতভাবে)", "typical_use": "বুট/ফার্মওয়্যার কোড"},
    "Flash": {"volatile": False, "rewritable": "হ্যাঁ (ব্লক-ভিত্তিক, সীমিত রাইট-সাইকেল)",         "typical_use": "USB ড্রাইভ, SSD, এমবেডেড স্টোরেজ"},
    "SRAM":  {"volatile": True,  "rewritable": "হ্যাঁ (সীমাহীন, পাওয়ার থাকা পর্যন্ত)",             "typical_use": "ক্যাশ (L1/L2/L3)"},
    "DRAM":  {"volatile": True,  "rewritable": "হ্যাঁ (সীমাহীন, পাওয়ার থাকা পর্যন্ত)",             "typical_use": "মেইন মেমরি (RAM)"},
}

print(f"{'ধরন':<8}{'Volatile?':<12}{'Rewritable':<45}{'সাধারণ ব্যবহার'}")
print("-" * 95)
for name, props in memory_types.items():
    flag = "হ্যাঁ (পাওয়ার ছাড়া ডেটা হারায়)" if props["volatile"] else "না (পাওয়ার ছাড়াও ডেটা থাকে)"
    print(f"{name:<8}{flag:<12}{props['rewritable']:<45}{props['typical_use']}")

print()

# ফ্ল্যাশ সেলের সীমিত জীবনকাল -- একটি সরল সিমুলেশন
class FlashCell:
    def __init__(self, max_erase_cycles):
        self.max_erase_cycles = max_erase_cycles
        self.erase_count = 0

    def erase_and_write(self):
        if self.erase_count >= self.max_erase_cycles:
            return "লেখা ব্যর্থ! সেল ক্ষয়প্রাপ্ত (max_erase_cycles ছাড়িয়ে গেছে)"
        self.erase_count += 1
        return f"সফলভাবে লেখা হলো (মোট ইরেজ সাইকেল: {self.erase_count}/{self.max_erase_cycles})"

cell = FlashCell(max_erase_cycles=3)
for attempt in range(1, 5):
    print(f"চেষ্টা {attempt}:", cell.erase_and_write())