Atlantis wrote:
Chromatix wrote:
Your biggest challenges will be...interfacing the 65xx bus correctly to DRAM, including generating adequate refresh sequences.
This is what I expected, but 6502 rather do not require large amounts of RAM.
The size of RAM makes no difference to the interface (unless scaled dramatically); refreshing one byte of RAM is more or less the same as refreshing a megabyte. Compared to SIMMs, using modern static RAM is probably going to be more retro (as in, using hardware more similar to that available to contemporary designers) than using SIMMs since the interface is the same as old static RAM, the only difference is in the size and cost. (The earliest microcomputers often used static instead of dynamic RAM, anyway; dynamic RAM was used only for cost reasons back in the day and that is no longer an issue for hobbyists even with enormous RAM sizes such as 256 KB.)
(In case it's not clear, throughout this post I use "contemporary" to mean, "contemporary to the retro period in question," i.e., the late 1970s or early 1980s or whenever the original system you're cloning was built.)
Quote:
What about other CPU families? For example 68k? Does some of them have required circuitry already present inside silicon?
Generally not. Note, however, that there's no need to use hardware to refresh RAM; you just need to ensure every row is accessed regularly, and this can be done by the CPU itself. The 68000-based
Sun 1 workstation released in 1982 worked this way. The designer did admit that it was a bit tricky, not just making sure that the RAM refresh interrupt was set up and operating early enough in the boot process that the RAM it was using to boot didn't fade away as it was preparing to load and loading the OS, but also in that it made setting breakpoints when debugging more interesting. :-)
Quote:
1) For me it doesn't feel right to use modern microcontroller in retro design. I did it once, while building devive designed by someone else - modern recreation of Polish DIY computer from the eighties. It uses ATmega as a PS/2 keyboard interface. Original project utilized expensive matrix keyboard with reed switches, which would not be practical but using AVR feels weird. :)
Well, pretty much
every keyboard uses a scanned matrix, then and now, and whether you use "reed switches" (by which I think you mean something different than
the standard definition of the term) or not makes no difference since you scan any kind of switch in a matrix in the same way.
If the system could use an ATmega for the keyboard interface without significant changes to the system's design and ROM code, the original system was already using a microcontroller or a custom keyboard scanning chip in the keyboard anyway, making the ATmega and PS/2 keyboard together a single system replacing just the keyboard assembly in the original system, with the ATmega being just a protocol converter. Unless you feel that the PS/2 keyboard itself is somehow closer to period-correct than an ATmega, you probably went just as "non-retro" with that. However, you could always replace the ATmega with a more period-correct microcontroller such as an
8042, which was used in computer keyboards
as early as 1979, if that makes you feel better. But you'd definitely be more period correct and avoiding modern microcontrollers if you took the controller off the keyboard PCB as well and built your own system for scanning the matrix on that PS/2 keyboard.
To gain a better understanding of this topic, I suggest you study carefully until you reach full understanding the schematics and theory of operation for both a CPU-scanned keyboard, such as the TRS-80 model I, Commodore PET or Commodore 64, and an externally scanned keyboard, such as the Apple II. Once you understand these well, you will probably revise your rule to be better align with the design principles in use here.
Quote:
2) I'd rather use CF card instead SD in my designs. Yes, it is not strictly "retro" (I mean it was not available while 6502/Z80/8080 systems were in common use) but it is compatible witch technology of that era. You can connect it directly to the system bus.
I see the SD card approach as being a little more retro. In both cases you have what is from a contemporary point of view a "magic memory device" attached to the system, but in the SD card case you can talk its serial protocol through a standard contemporary interface such as a 6821 PIA, so the magic hardware starts on the other side of that protocol. Similar systems were used in contemporary consumer microcomputers: both the 1977 PET and the 1979 NEC PC-8001 did pretty much exactly this for their external drives, right down to using a PIA as the computer end of the interface between computer and storage device.
With the CF card, though, you've now got the magic device directly on your bus, emulating a peripheral chip with a kilobyte of independently updated address space, something that never existed back in the day as far as I'm aware, though I suppose someone could have built such a system with dual-ported RAM. At any rate, that interface was not nearly as widely used as the "smart device on the other side of a PIA" interface.