Hi guys, I have processed a lot of data to generate out my database of vintage SIMM and SIPP DRAM chips and modules:

[url]http://martenelectric.cz/simm-sipp-ram-chip-database.html[/url]

This should be handy for those brewing at home :)

I once played around with the idea of providing DRAM over I2C with just a low-pin-count PIC and a PAL chip: never actually did it, and I haven't looked up SDRAM interfacing, but I expect an FPGA to be something of overkill.

At any rate, this is definitely bank-switching territory. And for MS-DOS, at least, there were standards for bank-switching control... Also, context-switching would presumably be handled by hooking the standard timer interrupt with a TSR. Other hardware (e.g. network adapters) starts to get tricky, though.

If you felt fancy, some battery backup + patched OS + SD card would allow "always on" behavior for the programs (or even multiple invocations of a single program).

Supposing that you also use old video cards, a way to interface THOSE to SDRAM would be useful: I understand most of them to have been restrained by the absence of optional memory expansions.

The nifty-ist stuff could only be done with a custom computer though, since otherwise you wouldn't be able to have mesh routing for dedicated DMA & such :(

ahh, now hardware/peripheral [re]configuration is something I hadn't considered in the whole (what I called) "context" switching idea... (not to be confused with actual context-switching in the OS/realtime-tasking-level, which I assumed to be *way* beyond this thing's abilities). Yeah, that'd be quite an ordeal :/

Simple simple E.G.... switching between one "application-space"/memory-bank which is using graphics-mode and another using text-mode. Now we'd need not only to hack the OS(s) to backup/restore internal CPU registers, but also have to hack the "drivers" to backup/restore other hardware's configuration-states/registers... (And, of course, a lot of those old applications access the hardware directly...)

So, I guess, you're right, it probably wouldn't be an even remotely simple task to do with an otherwise regular computer and otherwise regular software... the whole thing'd have to be ground-up and designed for this purpose, including the software... yeuchk. At that point, mightas well actually implement real-time context-switching, and everything else... Hey Threads at 1.2MHz!

I don't actually consider this a particularly compelling reason NOT to do it. Basically you just need to do a little hacking on the OS (for MS-DOS, you're looking at hooking a TSR into the interrupt dispatch table), and to create some "context swap" drivers. You're already doing hardware design with this as is, so just design it so that being loaded into the extra memory in the first place requires a correct set of hardware interactions: a library and (for those programs using only common hardware) an executable that both do this should be enough.

Then you just need drivers: a small number of common pieces of hardware (e.g. ADLIB/SoundBlaster, MGA/HGA/CGA/EGA, hardware commonly found on IBM-compatibles) are all that the actual project would likely have reason to support. There's lots of other hardware, yes (e.g. the IBM PGC, Gravis Ultrasound, random serial & parallel port hardware, WinModems/software-modems(not likely to be supported by anything in DOS), hardware-modems, network cards), but I think that just open-source graphics & sound would get you far, since it would let everyone else work out whatever they need.

Essentially, the wide variety of hardware that context switching would be needed for doesn't matter: the only think that matters is some common-utility examples, and a sufficiently generic mechanism for others to be hooked into the same system. On MS-DOS the old bank-swap apis are the correct starting point, and you'd just add some extensions (I believe they were specifically designed to play nice with everything else). On everything else it might vary, but the generalities would be the same: default to limited functionality, and provide a set of hardware registers or whatever else to control extended functionality.

Remember, the greatest weakness is identical with the greatest strength: you can bit-bang all of the hardware in the system, and do all sorts of powerful yet dangerous things. Just cover a few common cases with a hookable & documented interface, and it'll be fine.

Actually, I'd originally thought of this re: older machines than PC's; Z80s, whatnot.... but there's some great info here regarding doing something with e.g. an 8088/8086 running DOS... further contemplation in the works ;)

Actually, I'm mentioning IBM-compatible hardware only because I already know the basics of how to do it there. I don't know that other platforms have such things, but I wouldn't be surprised (in particular, I wouldn't be surprised if the x86 stuff ports mostly-directly to Z80). And if they don't, then it should be possible to just adapt the PC stuff. The basic model (provide bank swapping & a "hook interface", + some common example stuff) should apply everywhere, everything else is just a matter of adaptation.

The basic model of memory, control registers (on some platforms (like x86 for SOME hardware) on a distinct bus, for other platforms (like x86 for OTHER hardware) hooked into the memory bus), and interrupts is MOSTLY universal (without the first two you can't do very much, without the third you have poor performance for generic usage). I actually have an old book that mentions the S100 bus: it was one of the old standards, and probably one of the things you should look into.

As I said... I don't really know much about what the draw is to retro-computing... if it's about running old software, then the x86 world is set, right...? Anything that ran on an 8086 will run on a Pentium, no? (Albiet, maybe a bit fast... P4s with Turbo Buttons?) And nearly anything that would run on DOS 3.3 would run on DOS 6.2, or even Win98's DOS... And then, of course, those can use EMM386, etc... 

That's why I figured most of the retro-computing world runs on pre-x86 systems...

As it stands, it seems the concept is certainly doable, regardless of the architecture, with a bit of work. That's cool. Guess I'm just kinda surprised it hasn't become "a thing" in such crowds, considering the masses of unused SDRAMs out there, and the numbers of retro-hackers...

I assume that they just normally use lower-end components. At any rate, the retro hardware is a good deal more Arduino-level (though not Arduino-simplicity) than modern stuff: about the time of PCI it became hard to home-brew your own interface cards. If you were crazy you could probably do minor ISA interfacing with discrete transistors. Also, the "rabbit holes" are more exposed, so there's a good deal more novelty in exploration than with the newer stuff.

I assume that they just normally use lower-end components. At any rate, the retro hardware is a good deal more Arduino-level (though not Arduino-simplicity) than modern stuff: about the time of PCI it became hard to home-brew your own interface cards. If you were crazy you could probably do minor ISA interfacing with discrete transistors. Also, the "rabbit holes" are more exposed, so there's a good deal more novelty in exploration than with the newer stuff.

I don't think such a huge amount of RAM on an old computer would be that useful.  You can't address it, unless you do bank switching which is something unlikely for old software to exploit out of the box.  If you write a custom os (or extension)  bank switching may provide a primitive ' virtual memory' interface, letting multiple applications think they have the full address range.  IO and framebuffer would also need special handling.  If you want to make the extra RAM usable for existing apps, probably the easiest that would be creating a  huge disk cache.  Even with SD cards emulating floppies, the old disk interfaces tend to be slow.  A special disk driver that knows how to bank switch your custom setup would give extremely fast access. You could even cache multiple floppies at once. You may even be able to read a cartridge image off of disk (or sd card) and map your expanded ram to where ROM would normally be.  Even with all I just said above, a cheap 512k static ram would be plenty for, say a C64.

Thanks, that's the kinda insight I was wondering about... I personally don't have much knowledge of the RetroComputing realm, what the general draw is to it, what people do with it... It sounds, from what you're saying, that most people use it for retro-software... in which case, yeah, I could see that it'd take a pretty significant overhaul to most systems to make use of the extra RAM in any way... Like you eluded to, even if the hardware side of "bank switching" was implemented, and even if it was nothing more than rotating a BCD switch, there'd have to be a software component... if retro-computer-users are running apps off "floppies" that boot straight into the app without a common underlying OS, then there's really not much can be done without hacking each and every app... Doubtful most would want to go through all that! (Maybe a ROM hack, dedicated interrupt, pushbutton?)

The disk-cache idea... I'm not sure how something like that'd be implemented... I'm assuming most (floppy) disk-access is pretty low-level at the processor-side, itself... (e.g. rather'n having a memory-mapped I/O chip that converts memory location accesses to floppy-accesses) otherwise those SD-card interfaces wouldn't interface at the floppy-controller-side, but bypass that altogether... SD-cards would probably be plenty-fast if they were interfaced to the CPU rather'n the floppy-controller. And non-volatile, as a floppy should be... (My recurring TI-82 experiences with battery-backed program-storage suggested to me long-ago that non-volatility is *much* preferable for such things)...

Again, this is all theorizing from the perspective of someone who's only ever taken-apart retro-computers (maybe once or twice turning one on)... (and has a bit of experience with SDRAM, knowledge enough to probably implement the hardware-side of a translater)... so I'm all-for new insight/ideas, or even being told I'm totally mistaken :)

This be about brainstorming!

How low-level it is really depends on the computer, AND the software.  For instance, the Commodore computers abstract I/O through the 'kernal' (they misspelled it, lol).  All devices had a number, so theoretically a simple ROM patch would let a piece of software pretend to be one of these devices.  The key here is ROM patch: If you wanted to add on an SD card without taking your computer apart to replace the ROM, and you want a device anyone can plug in (not just for hardware hackers), you will use the existing physical interface.  It's also possible that some software titles didn't bother to use ther kernal routines, and just talked to the disk raw.

I have pretty much given up on using DDR memory as it is a bit more involved than SDRAM.  You pretty much have to use 4 layer PCB to meet the impedance and matching tracks lengths + terminations, but at what cost/performance if you can get it at all?  Most of the non-BGA packages do not have hard-macros for the DDR.  Yes you can implement DDR on your own softcore.  Is it worth the effort when you can't use the memory bandwidth?

DIMM or SODIMM have x64 bus width.  It gets very tricky to meet timing for a wide bus.

The pinout of SODIMM SDRAM on the other hand is easy to wire the x64 memory into x32.

Dunno about DDR, but SDRAM definitely runs down into the low MHz, in my experience...

For a retro-computer + translater, seems entirely doable without worrying about timings, etc...

DDR's a beast, sounds like you've done some exploring. Any insight on whether it can run slower than 85MHz, and/or whether it can run with the "DLL" disabled?

DQMs and Chip-Selects, my friend... x64->x8 :)

Synchronous Data RAM (SDRAM) and Double Data Rate RAM (DDR/DDR2/DDR3) are more of a pain to interface to for a CPU that has a 16 bit address space (64kB) and an 8 bit data bus. Both of these types of RAM are synchronous. 

These old processors used two types of RAM: Dynamic RAM (DRAM) that was asynchronous and most often used in Video RAM (VRAM) and on earlier retro computers and Static RAM (SRAM) that is also asynchronous and more often used on the later retro computers. 

Most of the retro computers had from 1 or 2 kB RAM  up to about 128 kB RAM. You can buy a 128 kB SRAM chip for a couple of dollars. It would cost you more for the extra chips to interface a SD/DDR RAM chip even if the SD/DDR RAM is free.

If you are going as far as to use a modern FPGA then you have the resources to implement a SD/DDR ram interface but modern FPGA is so large that you may as well just code the CPU in as well and forget about a hardware CPU altogether and that sort of takes away the whole point of building something that is "retro". 

There are other reasons as well. The pin layout on a SIMM / DIMM is all wrong for an old CPU and there are too many pins. These old CPU's only had 40 pins in total and a SIMM / DIMM has more that four times that. 

The individual chips from a SIMM / DIMM would probable be more useful than the SIMM / DIMM itself but the pin densities are too high for most people to solder.

I have heaps of old RAM and I would use it if I could find a purpose for it. The most useful would be the chips on the 31 pin SIMS of yesteryear but I don't have any of those.

Thank you for the details for the memory-types-uninitiated, as well as the insight into the retro-computer world... Would be a bit misleading to come across this post thinking somehow an SDRAM could be soldered in place of a DRAM/SRAM. No, we're definitely talking about some sort of translation-circuitry...

Hah, I've *plenty* of them 31 pin SIMMs, and also *plenty* of raw DRAM DIPs from old 8088/286's, if you want any, I'll be happy to send for the cost of shipping, DRAMs are too much work for most my needs. Also quite a few 256k SRAM DIPs which were cache on old 486's... Quite Handy, you can't have those ;)

But, the SDRAMs... yes... they're a different beast altogether (but not too bad once you get used to 'em). The "converter" I'm envisioning would be basically useless if it's only used at 64k, but if something like context-switching could be implemented... we're talking a heck of a lot of contexts.

Some contemplations of translater-implementations (maybe even with an AVR) on another comment...

Your mention of VRAM got me thinking, too... I don't know how most vid-cards are implemented in cases like these systems, but if their memory is attached directly to the same bus, it might be possible to use the same SDRAM for both system and video memory...

DDR contemplations, I'll leave for those more fluent... 

(And, yeah, I don't quite understand the use of FPGAs with such systems, but I'm sure it'd be a great learning experience, and those old CPUs in their ceramic and gold cases are quite pretty...).

Perhaps copy the contents of an SD card over to RAM on bootup and use it like a ROM/memdisk? Not that I would have any clue HOW to do that, it just seems like a logical idea.

CPUs are a bit beyond me, more a uC-guy, so at first I thought "nah, why do that when you can just run off the SD? Not like, at these clock-speeds, it'd be any slower...", but that's probably part of the answer, there... the Floppy->SD interface is likely no faster than the floppy->diskette interface.

And the other answer, which took some (albiet less) time to pop into my head: This'd allow for using programs on-disk which also write *to* the same disk, without damaging the original "disk"...

I'm curious if a RAM-Disk has other uses in such a case... again, the whole concept of these older systems is vague in my mind.

Especially when working with an SD card or other forms of flash memory, any time you can offload the high read-write count operations to RAM and then just write back to the flash when done will save wear and tear on the flash memory, theoretically speaking. However, in most cases this isn't really needed as the actual life span of the flash memory is well beyond anything you'd actually run up against.

I can't stress enough that I have no idea whatsoever how to do any of this. I just think it's really cool.

Ah yeah, there might be quite a bit of R/W, good call.

I think an old-CPU-style memory-interface to an SDRAM would be not too difficult... Am thinkink even one of those high-pin-count AVRs (or certainly an FPGA) could handle that translation at nearly the same speed (maybe faster?) than the SRAM/DRAM those CPUs were spec'd for...

It's just a weird idea that popped into my head... Always trying to find uses for old junk that exists in high quantities for free... Again, I have no idea how to code something like switching "contexts", at the CPU (vs AVR) side... And, without that, this converter would be nothing more than a really complicated 64k(?) SRAM.

Hah, yeah! It might be an interesting retro-computer task to set one up running doing nothing but writing a SD card over and over again and see how long it takes to start failing... I keep hearing they run at something like 1MHz, could take centuries!

HaD covered a couple projects which attempted to destroy on-board flash or EEPROM by repeated writes.

http://hackaday.com/2011/05/16/destroying-an-arduinos-eeprom/

http://hackaday.com/2010/05/28/russian-roulette-for-eeprom/

External SD card destruction may take much, much longer given the large size and internal wear-leveling mechanisms.