In this article I decided to just look a bit through my retro style console / microcomputer design's sources. That is, what and from which old computers and consoles inspired me in laying down the concepts, and designing further my system. A bit of RRPGE history also follows.
First thing: The processor
I don't much know whether ideas for the processor or the graphics hardware came first, in the case of the currently evolving RRPGE system the CPU was which materialized first, so I take that first.
In old sources (dating before 2008 or so) I was even thinking of having an ARM (32 bits) in the system. The source of my interest in ARM first materialized getting to know the Acorn Archimedes, an interesting early 32 bit machine which didn't get as successful as it should have been, probably for poor marketing strategies. But that was the first computer using an ARM processor, the early version of that ticking in many of today's handheld devices. Even for later custom processor designs I mostly held the ARM's instruction set as a reference to start from.
Why I fell back to 16 bits then for the final system? A very little this decision also came from the ARM concept. Originally the ARM was a 32 bits processor with a 32 bit instruction size (Thumb came only later), it is simple to access the code area efficiently. However 32 bits are too much for a compact instruction set (as Thumb proved that later for ARM). Since otherwise I didn't see strong reasons to have 32 bits, I decayed to 16 bits, ending up with a similar concept to the original ARM in this regard (16 bits processor with 16 bit instruction size).
Most other aspects of the CPU's instruction set were rather own inventions trying to navigate to a result which I though would be reasonably easy to emulate. What I used up were the multi-word instruction format I observed in PICs (to have second etc. words of instructions interpreted as NOPs when standing alone), and skip instructions observed in the same (PIC), 8 bit AVR's, and maybe other processors.
The most important of these "own inventions" is the lack of flags. I figured having flags would demand lot of calculations probably even mandating conditionals from an emulator, while most of the time they would go unused.
Paging and large memory access
The concept of memory paging which I am currently removing (as of alpha specification 00.010.000) from the RRPGE system came primarily from the Enterprise 128K. That 8 bit computer was capable to address up to 4 Mbytes of memory (or memory mapped peripherals on it's expansion bus) by a paging system working with 16 KByte pages of which 4 were visible in the CPU's address space any time.
What I am changing over to also has a source, although something very rare. It is a 256Kb Summatech REU for the Commodore 64. This is not a "true" REU clone, rather a simple Hungarian variant with an interesting feature of having an own Basic capable to utilize the extra memory. This REU provides access to it's RAM by a single register with an automatically post-incrementing address. By this the program running on the C64 would be able to efficiently "stream in" or "stream out" data. This is not as "shiny" as the DMA offered by the "true" REU (which could be utilized to mess with the VIC), however it is a very useful feature for any type of sequential data processing. Especially so since the data in this REU is 256 KBytes which it can entirely "walk" through in this manner!
Second: The graphics hardware
While for the current RRPGE system the processor might have came first, it is certain that graphics was one of the components I was thinking about since very early on.
Even now I can retrieve archives from 2009 with concepts for a Commodore VIC II based graphics component. Originally I went into this direction, then when starting realizing the current system, I dropped it entirely. With the original display list concepts I mostly followed the Nick in the Enterprise 128K. That graphics hardware operated based on a display list, however it neither had scrolling or sprites: all those had to be realized by the CPU (smooth scrolling mostly considered impossible). They probably went for simplicity and business use with the decisions. In RRPGE's case it wasn't the latter of course, rather that emulating a traditional sprite system is rather complex.
I was looking for some other method to get around without the need for hard sprites, something more flexible. The inspiration for the solution a bit came from Commodore Amiga, which had a blitter. The RRPGE system on it's opening (1st April, 2014) contained only the Accelerator roughly with the features as of today, operating asynchronously, but had no dedicated unit to feed it with operations like Amiga's copper. Later, inspired especially by the Amiga's copper, a simple FIFO was introduced and became a fixated part of the RRPGE system.
The RRPGE system by design didn't replicate the raster precise features of the Amiga for the complexity of emulation. I rather took a higher level path where the implementation's timing may be left more relaxed, and adapted only features useful for this approach.
At last, the audio
The audio part of RRPGE is rather simple, and truly it ended up not much following anything I know to exist apart from that it provides digital sample based output like more "modern" system. However it had sources originally.
The GameBoy. Especially it's waveform output feature which I liked. My concept was to realize a similar system at higher level where waveform based instruments could be mixed. For the instruments the original concept was that supported by the Enterprise computer, which provided a very flexible ADSR envelope like concept. Initially (long before the release) these requirements wound up in quite complex designs which were simplified away.
Other notable systems of interest
For some part the Gameboy Advance was also influential showing a design over an ARM processor, however not much. For the display list based concepts in graphics, I took a look at Atari's microcomputers which utilize this, and to some degree behave quite similar to the Enterprise's Nick.
From console designs the cartridge based concept was taken initially (the original paging system partly grew from this), however since this with large cartridge sizes becomes problematic to emulate for memory constraints, and today could become an actual show-stopper for any attempt at real hardware implementation, it was dropped very soon.
The IBM PC. Well, of course it is always around, impossible to be left out. In the case of RRPGE, this architecture was important as a target, to run the RRPGE emulator on. Originally a quite far-fetched goal was to realize RRPGE so it is possible to be emulated on a 3.86 or so. This, even introducing compiling the RRPGE CPU instruction stream to native code, would most likely be impossible now. The VGA compatibility of RRPGE's graphic however was retained which may be useful for home-brew operating systems or DOS based emulators.
Otherwise nothing much was used up from the IBM design. When creating graphics engines for the VGA I even realized they messed up the byte order of that thing (The VGA is Big Endian while the 3.86 is Little Endian, making it necessary to endianess convert almost anything done in 32 bits before copying into the display memory in 16 colour modes). And this is just one of the problems there.
Maybe the decision for making my system Big Endian came thanks to the IBM PC, that my experiments with that system shown why Little Endian might not be a good idea.
To be true, I looked up several other computer's designs during the years RRPGE materialized, although apart from the Commodore 64, the (original) Gameboy, and obviously the old 16 bit IBM PC I did not experiment a lot with any. Along those omitted above were the various MSX and MSX2 computers, the Amstrad CPC (which shows that the Motorola 6845 can actually produce graphics unlike what IBM did to this poor IC in the CGA...), and the NeoGeo for the design of a very efficient 2D system.
So all in all, sources! It was (and is) quite an interesting trip to study some of these old computers, how they got around the age's limitations, how they accomplished what they wanted. Too bad after about the early 90's we practically only had the IBM PC with all it's quirks.