GARTHWILSON wrote:
For my own uses, there's no threshold where below it is not fast enough and above it is; it's just that more speed opens up more possibilities of what I can do with it. My workbench computer with 4MHz parts started having problems at just a hair over 7MHz as I slowly moved the clock speed up....
Yeah, you've got a somewhat different aim with your small systems hacking than I do. For me, it's mostly about learning what I can do within certain limits, as well as just the fun of hardware hacking. If I had an application where I needed any real speed, well, for less than I'm spending on '80s chips alone I could get an SBC with an 80 MHz or faster ARM on it.
Quote:
I have about 75 R65C02's....
Or so you think. How many of them are relabeled NMOS? :-)
Quote:
...for which I have a pipe dream of being able to make an SBC for education, and have my Forth pre-installed. (I know everybody and their dog makes an SBC these days, but none have a display on them, none have Forth available upon power-up, and most have a lot of levels of software, at least in the bundled development system, which are beyond the ability of a relative beginner to understand. They're training paint-by-number people! Where are our engineers going to come from when the current crop is retired??)
Let me lend my support to that idea. I think it's a great one! And with decent software it could also well be a fine replacement for Arduinos and the like; there's no reason that things like EPROM programmers shouldn't be made with a system like yours, rather than an ATmega-based Arduino.
I think a Forth system that you can actually program
on the system itself is a much better training and hacking tool than the Arduino world of GCC and an IDE that runs only on a host machine with a thousand times the power and leaves you programming in C against massive libraries written by someone else. Of course one wants to have some sort of host capabilities to let you easily have different projects, collect up your work in Git, use a good editor, and so on, but given a basic way of moving chunks of code (in the Forth case, screens I guess) back and forth between the two, I think developers would be set.
Quote:
It sounds you're down to individual ICs, with no board. The processor board should probably have at least the clock and reset circuits on it.
Pretty close, in many cases, yeah. For 6xxx systems I don't see any reason not to use a common clock, though, but I'm not sure about the Intel-style systems where the CPU clock is basically several times the "system" clock. Some peripheral chips, such as the 6821 and 6522 usually take input from the system clock (pin 25, called "E" on the 6821 and "Φ2" on the 6522) which looks to me just like another enable pin that lets you easily qualify your enable based on the system clock, as one typically wants to do in Motorola-style systems, but I'm not sure how to translate that.
As for reset circuits, I pretty much need just one anywhere, right? The RC2014 backplanes often include reset functionality, and I'm thinking it would make sense to hack that on to my existing RC6502 backplane, too, once I start using it with something other than my 6502 board that already has a reset button on it.
Quote:
How 'bout at least a 65c51 (although you might want to go for an older one, not the WDC one that has the bug). The 6850 doesn't even have a baud-rate generator onboard. Many here would advocate for a different family of ACIA/UART altogether. One that I like is the SPI-interfaced 14-pin MAX3100.
Actually, I do have a couple of RC65C51P2 chips in my parts bin, along side nine MC68B50CP chips. I'd not realized that the '50 doesn't have the baud rate generator, which is a mild annoyance, but I do have some 1.8432 MHz oscillators coming (as well as crystals at the same frequency), so even if I don't want to cons up a divider circuit I can still run them at 115.2 kbps just by running the oscillator directly into the pin, right? I know that there are much better UARTs out there, but I'm not feeling at the moment like I can't get along with what I've got. (Except for some 8251s and 8253s on order specifically for my MSX machines.)
But all that said, yeah, once I get going if I'm not happy with my UARTs, there's nothing stopping me from building another board with different UARTs. In fact, that's kinda the whole point of the system!
Quote:
Let me recommend the 65C22. Besides having the timers and serial port onboard, there are certain things the '22 is much more agile at than the '21.
Yup, I've got three 6522s alongside the nine 6821s in my parts bin. I certainly like the former better, but I think that there are probably plenty of things where the latter will do. In fact, I'd like to be using 6526s all over the place, but those tend to be expensive these days because so many C64 owners want them.
Quote:
It may make sense to devise a backplane that has the signals for all of them, and have jumper options on the non-CPU boards for dealing with the different CPUs' bus systems.
That's a thought. Though again, it's a new bus design rather than re-using an existing one (and any design work that's been done for CPUs and peripherals on that bus), and it feels like I might be duplicating a lot of work across boards to have the conversion circuitry on the peripheral boards rather than doing it in one place on the CPU board. (Assuming it can be done just on the CPU boards that need it.)