Thinking back through things we tended not to see most consoles have extra functionality baked into the silicon of the CPU. As a co-processor (be it onboard or on cart a la NES mappers or SNES special chips) or as BIOS/firmware functions then sure and I could give you loads of examples (the specs docs people use for the hardware and to refine emulators like those I linked go into great detail for a lot of them) but not baked into CPU silicon. Some lost functionality (usually that which was more concerned with business/industrial uses -- BCD is not so useful in a NES, prior to the rise of floating and fixed point though it was pretty essential for fractional numbers) or altered things slightly but it is not like you might have seen for some of the custom ARM stuff out there now. Sure I would hate to replicate the N64 (look up N64 microcode if you want some fun) but for anything you are sitting there thinking "well that is a fairly standard embedded processor... I wonder" then it is probably feasible.
http://problemkaputt.de/pandocs.htm#cpucomparisionwithz80
https://courses.cit.cornell.edu/ee476/FinalProjects/s2009/bhp7_teg25/bhp7_teg25/
Said extra stuff is often well within the realms of a moderately priced modern FPGA or CPLD as well, though have fun powering that. If they were extra instructions and you tried to bolt it on then you would probably run into latency, race conditions and bus issues, assuming you did not do some crude version of dynamic recompilation*/instruction translation anyway.
*the classic example might be from the assembler worlds -- most instruction sets will probably not allow you to stick an immediate in there the same size as the instruction (can't move a 32 bit immediate in an instruction that is 32 bits itself sort of thing) but your assembler will probably handle this all for you. Most extras would not be basic RISC design but with a crazy SIMD instruction or something as much as just a better divide or something.
"I plan to put the cloned gameboy into the original gameboy case and have it be able to play games up to the nintendo ds console"
Practically speaking I would probably get something that runs some version of android as the emulators for all of this do well. Slightly less practically the DS might be hard but simple 16 MHz ARM chips are doable in FPGA these days. I do also hear interesting things coming out of China as far as baking your silicon goes (lots of the old and past their prime processes, though processes still measured in nanometres and certainly smaller than anything the GBA era and backwards people would have available to them, are available for reasonable prices to the general world similar to the opening up on the PCB manufacture market some 10-15 years ago).
Other than the android thing* then whether I would head down that path I am not sure. That said something I have long wished to say to several clone device makers is perhaps consider making a better device -- clones tend to end up with the photocopy of a photocopy problem where trying to beat it from the outset gets better results.
*be careful if you use flash carts as they can work different ways but we have seen several devices dump games and saves into memory and feed that to an emulator, before writing it all back. I would say such a thing would be a more suitable project for a final year project or a masters thesis.
