Join the channels Discord: discord.gg/jmf6M3z7XS You can support the channel on Patreon: www.patreon.com/JamesSharman

i love the schematic visuals on the side with you walking through your design decisions and logic so clearly. keep up the great work!

From a CPU to a game console, great work !

Don't think I've said anything about it yet, but those schematics you're animating as the bread board goes together have been extremely helpful. As someone who easily loses track of his own breadboard projects, it makes the build much easier to follow. 👍

Nice! But why didn't you choose for say 2 times 6 bits ordered in a way that makes sense and then use the 8th bit as a marker like you are using it now?

You could pull the 2 upper bits high, because it's physically impossible to press left and right at the same time.

This is a good solution to read 16 bits with only one control line. I think I would have changed the interface a bit to free up bit 8 free on both bytes to be used purely for identification so you would always be able to guarantee which byte has been read just by testing bit 8. I know exactly where you are coming from trying to keep the variety of components to a minimum, even if it used a couple of extra chips overall working with fewer different chips is less head space.

Nice one James, this is shaping up really well.

You are getting better at this video editting thingy too! I like how you added the circuit in real-time while patching the wires! Keep up the good work.

Great work James! 👏

At first the controller looked (to me) like a minor accesory, but now I see that it made the computer fully independant of any other device. Congratulations! And it's awesome how smooth the first steps in expanding the ssytem are going. Just before you said it I was (we all were?) rooting for a Controlled Supported SNEK! Thanks for all the great content :)

Awesome progress! Nicely done! I may have used all 4 bits of the MSBs to hold a pattern to test, but the single MSB works well enough! 👌👏

I really like the synced view on breadboarding vs easyeda. Good one, James!

Great circuit james! I like it! Cant wait to see snek on vga. 😎

Oh my God, this project is amazing 👏🏻👏🏻👏🏻

I feel like having six on each bit would be a better idea, so you know that the MSB is always the high/low bit flag. I actually made a hex keypad using a very similar counter and demux selector and dlatches this week. Nice to see others have used the same route.

Hi James, I followed your comments below and it seems that everyone feels a little unhappy with the ambiguous MSB as an indentifier -- maybe including yourself. However, I also understand that you need the D-pad not to be split, as you pointed out to Reinoud. I think, not "reordering the bits" is also a valid argument -- in software, at least, because it costs time. But what if you actually used the line buffes for the reordering of your shift register outputs? I see no reason, why the original bit sequence from the controller is in any way relevant in later software or the processor itself. You could even choose a more sensible layout for the data. For example: Stick the D-Pad into the low nibble of byte 0 and the four ABXY into the low nibble of byte 1 (so they're not split anymore); the sholder buttons and Start/Select each find their place in bits 4 and 5 and the MSB could then identify the multiplexing of the data unambiguously. And if, one day, you choose to add a second controller, you have another spare bit for the controller port ID (as I am not the first one to point out, either, and I think, you should absolutely add a second controller anyway). Please let the hardware do its magic. :-)

James, I love your videos! I would be very interested in seeing some of the "logistics" of building that you use in your projects. For example, your extensive use of EasyEDA; your soldering setup for SMD (i.e. temps and speeds that you use on your hot air gun/iron). I have used EasyEDA in the past, but I am nowhere nearly as proficient in its utilization as you are, a demonstration/narration of how you align, rename, wire, etc. would be invaluable, in my opinion. Also the manual routing that you do, how you decide where tracks should be; doing the turns; etc.

The circuit looks so simple, yet I am having a hard time wrapping my head around how the shift registers work in practice. I mean, I understand how they work in theory, but for some reason all the control lines keep confusing me! ;-) Thanks again for the past two video's. I am looking forward to part 3.

Nice. I'm glad to see I managed to guess how it would be integrated, *and* what the first demo would be. :P At this point, I think the only thing missing for a proper VGA port of snek is the tilemap so you can do text. I might start porting my version over to VGA, and see about integrating my music tracker... just need to find a reasonable track to use. I think Nyancat on loop would just drive people insane...

Do you publish the schematic for this circuit, anywhere. You make it look so easy! Great job!

Very nice! Could you use only 1 of these to read the state of two controllers alternately?

Cool :D. Just wondering why not use the write line to reset the flip flop so to read the controller you can just write then read read to get the data?

Did you just call me out at 7:40, James? :) Reducing the part count is completely valid, but I look to chips that do the job better/easier. However, I am just some guy on the Internet with opinions, I am nearly irrelevant. I just like to point out different ways to do what you did. For instance, I would have split the line to 6 and 6, that gives one bit to unerringly identify high/low part of the controller data, and the option to add a second controller. But again, I am not the one building this fabulous computer and making the neat videos, I am just the opinionated asshole living in the comments :D Thanks for another great one! The circuit is very clever!! Any plans for a second controller? There are unused bits in the high byte that could be used for ID. I wish I could support you on Patreon, but living on a fixed income sucks. I will continue to cheer you on from the sidelines, as it were.

Nice. Small question: what did you use to draw your diagram at 3:00?

you could shuffle the bits over a little to free the high bit on the other register to be permanently low

Another option rather than having the MSB pulled to VCC to work out hi/lo byte is to have some time function (maybe even a 555) do the work for you. The first byte being read is the low byte. If another byte is read before an n millisecond time-out period then it is the hi byte. It also might be an idea to not clock in the SNES data constantly if you ever want to use some old school wireless controllers. Some of those would freak out if they did not have a rest between clocking.

To avoid a miscreant holding the button down to fool the circuit: could you switch the wire going from the top bit of the lower byte shift register, into a spare bit in the upper byte output? So only 7 bits are ever set on the lower byte.

I thought I saw somewhere that at least one of the old nintendo controllers (nes or snes, maybe both) have a nub under the directional pad that made pressing opposite directions impossible. If the snes controller has that feature, you could do left/right or up/down pair of lines to force forever high on the high byte and avoid any edge cases entirely.

13:00 - is that why it was (for a while) common to have a "game port" (aka joystick connection) on PC sound cards?

as you will be reading both to get the controler data, can't you move the lower 8 bit signal to the upper port where you have 3 spare bits and then set bit 8 low. then you will have bit 8 defining the port being read.

Could you feasibly use the reset line to hold the shift register's enable pin in a disabled state until the processor finishes booting? That'll make sure the controller is ignored during powerup, and holding any of the buttons won't do anything

I personally think at this time stamp 4:10 you could move the Right D-pad to the other 74xx541 and then you could pull it down to ground and with that you'll be able to deferient the high byte from the low byte enven if we presse any button

Why not add the AB Buttons to the bottom of second byte and have the d-pad & start/select on the lower byte and the 6 game buttons on the upper byte. then use the top two bits of each byte for byte and controller identification? like using bit 7 for byte select and bit 6 for controller ID or reverse it so bits 6&7 would be a accending number from 1-4 (if you wanted to use two controllers). That would remove the need for discarding data. - Wes Hedden

you could have just started the state on power up to have the low byte asserted. This is also how the NES/SNES interface with the PPU for example. What actually happens for the controller is that the CPU manually has to shift in the bits. And to latch new data the CPU has to write to one of the controller port. You could have done something similar, let the CPU decide with the write line when to latch data and use assert to read it. This also avoids an issue when the CPU reads the data while it is being updated.

That bus tester is cool, is that your own design?

Is there a way to do presence detection on a SNES controller?

personaly i would choose to make bit 7 follow the flipflop this limit the lower byte to to 7 input lines ( bit 7 is alway 0) and then use 5 inputs on the higher byte where (bit 7 is alwas 1) , this way we alway know if we reading the lower or upper part off the joystick input.

So for identifying the flip flop state, I think I found a solution only using the two upper bits of the high byte: make bit 8 of the high byte be the NAND of left and right, and bit 7 be the XOR of left and right. It results in a truth table that can tell which one is which because there's no conflict. So you can compute the two bits in software, and when you read the next byte you can tell which way it is based on whether it matched or not. Buttons - low high - high low None - 00 10 - 10 00 Right - 10 11 - 11 10 Left - 01 11 - 11 01 Both - 11 00 - 00 11 It's probably not worth the chip(s?) just for that though. Might as well tie them both high and if somehow the player manages to press both right and left at the same time, yell at the player to stop it so controller detection works. The only other solution that I can think of would be to add more flip flops to have a third state where it returns all 1s and could probably be done with just one existing chip, and would also be fairly cheap on the software side but kind of gross and wasteful compared to a one-time init at start of the program :/ Thanks for the videos! Really ties up how all those parts work together to make an actual computer! Also makes for pretty nice brain teasers trying to solve problems like this one.

yep, James, a lot of comments ;) Good thing as it means we're a bunch following your adventures ;) Bad thing as it means there's a flaw in what you did and we're all eager to help ;) guess what ? yep ;oD myself included. Oh boy, another one. Gimme a rope... :) So I understand you wish to do close to none mods if possible. But still we have 2 bytes to distinguish and a single bit to do it. The +5v is at the same pos as the Right, correct? So let's say instead of a single bit, you use 4. All up. I suppose we my have less chance to have the LRUB buttons all pushed at the same time. Narrowing down then the risk of error. If what I'm saying is completely silly, please, forgive me. I'll shut up forever and after ;) btw, thank you very much for you work. Amazinlgy entertaining

What if the controller is fault with a stuck button even if the computer is running software that does not use the faulty button is all of the controller not going to work?

my first thought for compression was to take advantage of the fact that the d-pad is a single piece and thus can't have opposing directions pushed simultaneously to try and save bits by encoding, but then I realized that doesn't save enough bits to reduce to a single byte, and if you can press two adjacent directions or none at all, might not save *any* bits.

Why not do 6 bits per line driver then you could do a top bit to identify the state of flip flip. You'd even have a spare bit to identify a second controller port so 24 bits 6 bits per driver then 2 bits yo identify the byte. Then a single port on bus could drive 2 controllers with 4 reads.

Why not just map both bytes to a different memory address? Memory mapped Io? Seems much simpler. Maybe the answer is obvious but with so many interesting projects to follow i cannot fully know every single one.

You have left & right on bits 6&7, why not make the flipflop test be for both bits 6&7 high? this would be unambiguous as you would never have l&r pressed at the same time. At least not without a very broken controller..!

Hi James, have you considered to use timing to reset the flip flop? I have seen that trick sometime when two quick successive reads just reset the flip-flop sometime at the beginning of your code, while "normal" code will probably never just read the same port twice. You could use just simple timer (probably some clever construction with 555) if you will have fixed clocks, but in your case you would better count main CPU clock pulses or something like that. Hope you understand my idea, seems to be "cleaner" to me without dependency on input state of the top bit like you have here.

Right, Left, Down, Up, Start, Select Me: That isn't the Konami Code...

component re-use in design is always a good thing, why buy 1 of loads, when you can buy loads of 1.

18:42 Couldn't you pull up all four of the lines on the upper byte? Then you'd have U/D/L/R all set at once, a physically impossible input on an SNES controller

Just saw Adafruit is sporting LED noodles.

Is it Doom? ;)