4 ms·
In the days before MMU's and fancy DRAM controllers and newer DRAM chips the CPU had to do memory refresh during "idle" time.
by tibbydudeza 4y ago
In the days before MMU's and fancy DRAM controllers and newer DRAM chips the CPU had to do memory refresh during "idle" time.
- tyingq 4y agoDepends on what point in time you warp back to. There was a point where most home computers had static RAM.
- randombits0 4y agoOh, look at Mr. Moneybags over here!
- tibbydudeza 4y agoYep but cost and when memory starting exceeding 64K.
- Tuna-Fish 4y agoEr, when? Apple II was sort of the first big successful home computer, and it had DRAM (The CPU and the display accessed the ram on alternate cycles, and Woz placed the display buffers so that most of the refresh was "free"). As far as I can tell, all the actually widespread successful computers after that have used DRAM too.
- shadowofneptune 4y agoIt's earlier than that, dating to the time of the Altair clones. Refresh hardware didn't come with those machines so adding it yourself complicated the memory board.
- tyingq 4y agoYes, before the widespread successful bit, almost by definition, since SRAM was expensive.
- Someone 4y agohttps://en.wikipedia.org/wiki/Static_random-access_memory#In_computers https://en.wikipedia.org/wiki/Static_random-access_memory#In...: “SRAM was used for the main memory of most early personal computers such as the ZX80, TRS-80 Model 100 and Commodore VIC-20.” It wouldn’t call it “widespread successful”, but he Macintosh Portable also had SRAM (https://en.wikipedia.org/wiki/Macintosh_Portable https://en.wikipedia.org/wiki/Macintosh_Portable)
- dragontamer 4y agoYou are scaring me. Please, I need to be able to sleep later tonight. Warn before posting such a horror story!!!
- segfaultbuserr 4y agoAnother horror story - I heard that a trick some software copy-protection (DRM) used back on the IBM PC is disabling the DRAM refresh interrupt. Every time you trigger the protection, you computer just crashes randomly.
- Cerium 4y agoI don't believe it. A quick search seems to indicate that the IBM PC 5150 triggered memory refresh via timer hooked up to an interrupt which would trigger the refresh hardware without cpu support.
- tibbydudeza 4y agoThere were computers before the IBM PC you know :).
- Cerium 4y agoDo you have one in mind? I'd love to read some.
- tasty_freeze 4y agoThe Apple II used DRAM (4KB was the minimum initially). There was no refresh logic. The CPU was slow (just a bit more than 1 MHz), and DRAM could perform two complete RAS cycles in that time. That allowed the design to perform one memory operation per CPU cycle and do one DRAM read for video display per cycle. The mapping of logical addresses to DRAM rows was designed such that during normal video display every row was touched frequently enough that it met refresh requirements. Z80 CPUs had DRAM refresh logic built in. The first two clock cycles it would read the primary opcode byte, and the next two clock cycles it would do a refresh of the next row and then increment the row counter ("R"). That worked well because the minimum instruction took four clock cycles to complete. The timing was a bit surprising though -- it would seem to take four cycles to fetch the first byte of an instruction but only three clock cycles for each subsequent memory transaction. Unfortunately, the R counter was only 7b wide, which was fine for 16Kbit DRAMs, but became a problem for 64Kbit DRAMs which needed to refresh 256 rows, not just 128. Some Z80 based designs would decode the refresh cycles and either mux in their own 8b count value, or they ignored the Z80 and just stall the Z80 every so often to perform a refresh cycle.
- lanstin 4y agoI had an Ohio Scientific Challenger 1p (not totally sure on the numbers and letters) which I am pretty sure had 8K static RAM for main memory and a 1K video RAM for character addressable graphics. Microsoft BASIC in ROM and a tiny hex monitor for doing assembly. https://www.pcjs.org/machines/osi/c1p/ https://www.pcjs.org/machines/osi/c1p/
- Pulcinella 4y agoA absolutely great visualization of this (or at least how the execution of an instruction by the CPU is affected by memory refreshing) is this video about the SNES. Video link has timecode, but it should be at 8:23. https://youtu.be/Q8ph2OVqZeM?t=504 https://youtu.be/Q8ph2OVqZeM?t=504 I find it really gives you some context. Memory is refreshed many, many times a frame, roughly once per scan line on a CRT. Edit: Though it's unclear to me if it's the CPU actually doing the refreshing or if the CPU is just waiting until the refresh is complete.
- bogomipz 4y agoInteresting. I understand why the CPU would have needed to do that in the absence of integrated DRAM controller but how does the absence or presence of an MMU relate to this?
- themulticaster 4y agoI know you're referring to ancient architectures, but the question of when to run refresh commands is still surprisingly interesting and relevant for DRAM controllers today. Just to clarify, with DRAM controllers I mean the piece of hardware inside a CPU/SoC/Chipset that receives memory read/write requests and talks to the actual RAM via DDR2/3/4/5. The later standards get progressively more complex so I'm not familiar with them, but for DDR2/DDR3 you have a window of a few thousand memory clock cycles in which you need to issue a certain number of refresh commands IIRC. Since those refresh commands take a while (relatively speaking), it can be a good idea to run them when the number of outstanding commands is low - or some other strategy depending on context. There are some more optimizations that DRAM controllers can perform. As part of reading a certain address, you first need to open a bank. This is not a free operation, it can take a while (relatively speaking). After the first read in a bank, you can read other addresses inside the same bank for free, without having to open the bank again. This means it makes sense for a DRAM controller to process reads out of order: Instead of processing a command sequence like A1 B1 A2 (A/B are banks here) in order, it saves time to process them out of order, i.e. A1 A2 B1. Disclaimer: It has been a while since I last looked into DRAM controllers, so I hope I didn't miss anything. But the general ideas should be correct.
- rowanG077 4y agoThis is true and one of the reasons it's still not out of the question for bespoke memory controllers to be written for specific accelerators. There really isn't a one size fits all memory controller.
- ur-whale 4y ago> do memory refresh during "idle" time. Or in some real ancient case (ZX81), generate a video signal for the display (TV) - except in "fast" mode, where the screen would just show noise.
- fsckboy 4y ago> the CPU had to do memory refresh during "idle" time the CPU had to do memory refresh during busy times too! The Z80 would do it automatically