@@weirdboyjim I would love to hear your thoughts on that! ;-) Also it's going to be great to see your computer driving some interesting peripherals. I'm really excited to see what you will come up with. And have you thought about adding an ADC?
@@weirdboyjim compared to the others, yes. Its simple. But its a good addition to the CPU to have a basic interface. This makes it way more flexible. espacially for prototyping or testing of other components. Nice video, as always.
I have been following you for 5 years, and you have produced an enormous amount of extraordinarily interesting videos. It must be very challenging to document everything with this level of detail and clarity. I am developing a system similar to yours, but focused on computational chemistry. Your work is an inspiration to me, and I just wanted to thank you for sharing it with us. Thank you.
Like your method of showing the schematic alongside the breadboard. As well as that you show actual gate function rather than just black boxes like some RUclips channels...
On some videos it wasn't possible to show the schematic but I'll continue to do it where I can. I try to put the information on screen that's needed to understand the circuit as I'm building it.
Thanks James. I thought basic GPIO would be faily easy to implement. I enjoyed this one a lot because I could understand everything you did. Take care.
Interesting as always. And I'm kind of impressed by how well you've tamed your assembler code base. You were able to expose the GPIO pins and add new functions so quickly I was honestly amazed. LOL
I love how much circuitry is there just to show some different LEDs when you press a single button. It reminds me of people implementing CPUs in Minecraft - emulating simple devices using much more complicated ones. There's just something satisfying to all that complicated stuff being used to implement the basics that it started out with. Something akin to bootstrapping your own programming language in the same language.
We are truly blessed. On the same day as James uploads a video on connecting to the outside world, Ben Eater is uploading a video on connecting his 6502 breadboard computer to the (serial) world.
I remember on the BBC Micro, we had the User Port 'cus I don't think anyone said GPIO back then... But some of our teachers loved it, because it was the route to connecting all manner of exotic cr... erm stuff up to the computer.... ... yeah, you gotta have some GPIO.
As always, thanks for sharing. Just out of curiosity: Instead of using a combination of a 74LS574 and a 74LS04, you could have used a single 74LS373 as well. That chip is especially designed for that kind of application. What was your reason not to go that route?
Well I favor the 574 because it's pin ordering is really convenient for breadboard work, and I have a bunch of them already. The 573 would be a good choice but having a board with both a 573 and 574 on it is just asking for me to make a soldering mistake!
Hi James, I very much enjoy this whole series and pick some of your designs and techniques for my own build. Regarding this GPIO circuit this would „only“ be a in- AND an output port because each pin is either in or out but not generally usable in both directions (hence the name GPIO) for this there must be an 3rd register to set the direction, and the pins of the in port an the out port have to be multiplexed by this register and an analog switch - or so I always thought. Anyway I think the point here being simplicity that’s the way to go and as a bonus there are 16 lines 8 in and out each. Wish you and everyone happy Easter!
I would not agree that pins must be bi directional to call it GPIO. A "pin that is gpio" implies that it can do both, referring to something as gpio just implies that both features exist. Micro controller devices make the pins configurable to increase utility in a fixed package size. I'm not as space limited so I'd only make a bi-directional line if I had need of it.
@@weirdboyjim sure,that’s of course absolutely the privilege of the designer and saves logic, space and power. And if you never need both functionality on the same pin/ line it absolutely makes sense. Maybe I was tempted to nudge you in that direction because it may make sense for others ( knowing me and how little time I have I probably some day implement it in verilog into one of my small ice40s rather than solder up all those boards ) or for a specific use case later to have configurable functionality without using an fixed i/o-chip like an 8255 or an serial GPIO expander. 😅
This might be a simple video, but opens up to all kinds of interesting possibilities. One possibility that comes to mind is access to an SD Card which suddenly gives you access to a couple of GB of storage.
It's crazy how far you've come with this computer. I like the idea of adding more connectivity like the GPIO and UART. Do you think it would be possible to go further and add some sort of primitive networking like 10base-t with LLDP? It seems like it would be possible combining the designs you used for the VGA and UART.
It would be possible but I'm not going that way. My plan is to finish this build fairly soon and then start on a new system that takes things a big step forward. I'd spend too much time fighting the limitations of this design. 10base-t's transfer rate really doesn't suit a system with only 64k!
Suggestion: Add a mass storage (Compact Flash, most likely) interface; Make a simple filesystem driver (Any basic, optionally hierarchical file system should work); Write a text editor that can read and write files on that drive, as well as an assembler and runtime program that act on files on the drive This should make the computer entirely self-serving, provided you have a serial terminal [or an emulated version of one], since you can write files on the computer, compile them in-situ, and run them right then and there. Maybe even lays the groundwork for a full rework of the firmware, where the ROM doesn't have the assembler/disassembler/etc. anymore but gets a 'boot from HDD' option that loads and runs the boot sector.
My plans already include a bit of storage, I will be able to move some features from the monitor to executable programs on the storage. There are limits to how far I'll go with this though, nobody wants to watch me spend the next year programming utilities.
thats DOPE , i have a question . the name of the cpu/computer is jam-1 , how much more are you planing to do with it before you move on to jam-2 or something like that ? what would you like to chande with jam-2 ?
You are changing the load signal after the output enable! which could cause problems if you were running at the limits of the chips but in this case your get away with it I expect. As the /OE only one propagation delay before the latch signal.
I noticed this as well, but then I realized that it doesn't really matter, since the only timing that matters is when the read happens are the other end. If the read is too early in this implementation then you could get old data, but if the OE is delayed then an early read would just get all zeros from the pull-downs, which it's still bad data. In the end it's probably better to not introduce more delay, and if it needs to push the limits then just figure out the settling time like you would with a ROM or etc.
@@khatharrmalkavian3306 it depends if the read is on the falling edge of the signal or the raising edge. But i think that's it's better to latch the data in before enabling the output, i always feel the data should be stable before you present it to the bus. even if it's just to stop noise on the bus. I suppose that if the assert signal is basically just an address select and the read signal is used to read the bus then it is not a problem as long as there is a delay between the two events. Looking forward to see how close we get to a PIA of days of old.
It's very difficult to build circuits and not have the off thing delayed by an inverter. Chances are if you dig into the implementation of these chips there may be subtle timing differences between the response to the load and the enable.
Yeah, you can interface to just about anything with gpio. The LCD modules like mine that talk serial protocols usually have a little board on the back. The next video in this series (should be out in a few days) talks about SPI.
The MCUs I've used so far seem to have more than one port. Do you have any future plans for Dev 13? The possibility of not needing an adapter board to run a 16-bit device could be useful. How hard is it to develop plug-and-play code? That could be a great topic for either this series or the next. If so, would it make any sense to add standard connectors like PS/2 or D-sub to the final GPIO board as connectivity options?
Plug and play code isn't really that tough. You just need to be robust enough to tolerate weird things happening, there might need to be some effort put into making the circuits more tolerant as well though.
At around 7:00 you have the pinout for the 74xx541 shown which you aren't using. Great video though! It's a great day, a James Sharman video and a Ben Eater video release around the same time!
@@weirdboyjim Ok. The schematic had '574s on it and I thought you had finished talking about the '541 earlier and went on to use a second '574 at that point. No worries, I just figured I'd point out something that might have confused others.
This is a nice start, would be cool to add a little state engine and a buffer to this so you can emulate some serial interfaces without having to bit bang using the processor.
Well, I'm mostly going to do some bit banging with this but I may add the odd support component where it makes sense. Obviously I have the UARt series as an example of going all the way in the other direction.
@@weirdboyjim Yes, but with a little effort on the GPIO side you could potentially replace the UART and have something really quite unique in the DIY processor space. Thinking UART, SPI, I2C etc. and it would be a solid series of content to.
No, micro controllers do that for a variety of reason, not least they can they can often add hardware more easily than they can add pins to the package. I could make lines work like that but it would take me extra circuitry and ultimately it would be more restrictive than having the uart on a separate header.
very interesting , especially the part about a switch program being the baintent underutilization of resources you have or was it overutilization .. me english not so good in technical. anyway as you stated blink program on arduino is making something overcomplicated to perform simple tasks i bet your cpu is not up to the task i am trying to shoehorn atmega8 ic in place of arduino :] and that being a dcc decoder for a train layout ...well if you could run at 16 mhz your cpu probably would be up to task of controlling model trains or being a train too but that is just the clock frequency for commonly used atmel and pic microcontrollers by the way happy easter
congrats for "success at the first try". Do you want to protect those GPIOs somehow from strange handling / abuse, or is this something you put away for jam because you consider it kind of a controlled environment?
@@weirdboyjim no. Much more was I interested in how to protect a gpio. Seems to me such a protection could be quite a task, because of so many usecases.
One way I've seen is to have 5v zener diodes on the input. Anything over 5v and the zener clamps the voltage to 5v (might want to include a resistor to limit the current). Also has the advantage that it protects against negative voltages on the input as well.
What is the piece called that you are using to short all the led array's output pins together? Currently I am only able to short the pins if I have an individual wire for each output pin. Tried looking but haven't been able to find it.
Will there be more CPU updates? Or is it in its final state? Maybe some new cool functionality like GPR banks or an arithmetic coprocessor for hardware multiplication and division? Or will it only be peripherals from now on? Also, would like to get a separate video on instruction set, what instructions there are and how are they encoded and why where they chosen, because it's been so long and all in separate videos I've already kinda forgot what instruction set limitations there are... Also would be interested to know about some cut features, something you've wanted to add to your build but decided not to...
I can see the utility and the need for GPIO, but honestly not a very exciting video series to me. That doesn't mean I won't watch, comment or enjoy them, just that it isn't very exciting to me.
Join us on Discord: discord.gg/jmf6M3z7XS
Follow me on Twitter: twitter.com/WeirdBoyJim
Support the channel on Patreon: www.patreon.com/JamesSharman
Oh no, GPIO. That means the computer will be able to connect to the world. Now the robot uprising is upon us and we're all doomed!
Hmm, maybe I should do a video on Roko's basilisk one day.
@@weirdboyjim I would love to hear your thoughts on that! ;-)
Also it's going to be great to see your computer driving some interesting peripherals. I'm really excited to see what you will come up with. And have you thought about adding an ADC?
@@olavl8827 I’ll show 2 different methods of analogue input in this series.
One of my favourite episodes, looking forward for the next few: how the CPU makes friends
Thanks for that! I was worried people might find this one a bit simple.
@@weirdboyjim compared to the others, yes. Its simple. But its a good addition to the CPU to have a basic interface. This makes it way more flexible. espacially for prototyping or testing of other components. Nice video, as always.
@@weirdboyjim It's actually eight bit simple.
I have been following you for 5 years, and you have produced an enormous amount of extraordinarily interesting videos. It must be very challenging to document everything with this level of detail and clarity. I am developing a system similar to yours, but focused on computational chemistry. Your work is an inspiration to me, and I just wanted to thank you for sharing it with us. Thank you.
I'd never really thought about how GPIO might be implemented in hardware on microcontrollers. Very interesting to see how simple & elegant it is!
I'm going to cover a few of the fundamental IO features in this series. Maybe analogue input next.
Like your method of showing the schematic alongside the breadboard. As well as that you show actual gate function rather than just black boxes like some RUclips channels...
On some videos it wasn't possible to show the schematic but I'll continue to do it where I can. I try to put the information on screen that's needed to understand the circuit as I'm building it.
Every computer needs some GPIO pins, and you deserve something a bit simpler to recover a bit between the VGA stuff :)
Thanks Frank! I do need something to break things up a bit, there is a lot of pcb work in the builds future!
Thanks James. I thought basic GPIO would be faily easy to implement. I enjoyed this one a lot because I could understand everything you did. Take care.
Glad you enjoyed it! Most of the circuits in this series should stay very simple.
Interesting as always. And I'm kind of impressed by how well you've tamed your assembler code base. You were able to expose the GPIO pins and add new functions so quickly I was honestly amazed. LOL
Thanks Steven! Some of the way that was put together was based the needs I knew I would have later on.
I love how much circuitry is there just to show some different LEDs when you press a single button. It reminds me of people implementing CPUs in Minecraft - emulating simple devices using much more complicated ones. There's just something satisfying to all that complicated stuff being used to implement the basics that it started out with. Something akin to bootstrapping your own programming language in the same language.
Hopefully you'll see with the future videos how must stuff can be added with just those simple controls.
We are truly blessed. On the same day as James uploads a video on connecting to the outside world, Ben Eater is uploading a video on connecting his 6502 breadboard computer to the (serial) world.
Of course I already had a UART in my build, might be able to make them talk if they were ever in the same location.
I remember on the BBC Micro, we had the User Port 'cus I don't think anyone said GPIO back then... But some of our teachers loved it, because it was the route to connecting all manner of exotic cr... erm stuff up to the computer.... ... yeah, you gotta have some GPIO.
I was always frustrated that my zx spectrum didn't have a user port, of course I could have added one easily enough with the knowledge I have now.
@@weirdboyjim ooh... if we could take "now knowledge" back to then... ... ....
That was smooooth! It really shows how mature the system is.
I can't wait for the next videos.
Thank you very much for the awesome content.
Thank you very much!
Making a EPP/ECP parallel port would take a lot of parts. ;)
Yes, but not anything fundamentally different.
As always, thanks for sharing. Just out of curiosity: Instead of using a combination of a 74LS574 and a 74LS04, you could have used a single 74LS373 as well. That chip is especially designed for that kind of application. What was your reason not to go that route?
Well I favor the 574 because it's pin ordering is really convenient for breadboard work, and I have a bunch of them already. The 573 would be a good choice but having a board with both a 573 and 574 on it is just asking for me to make a soldering mistake!
Hi James, I very much enjoy this whole series and pick some of your designs and techniques for my own build. Regarding this GPIO circuit this would „only“ be a in- AND an output port because each pin is either in or out but not generally usable in both directions (hence the name GPIO) for this there must be an 3rd register to set the direction, and the pins of the in port an the out port have to be multiplexed by this register and an analog switch - or so I always thought. Anyway I think the point here being simplicity that’s the way to go and as a bonus there are 16 lines 8 in and out each. Wish you and everyone happy Easter!
I would not agree that pins must be bi directional to call it GPIO. A "pin that is gpio" implies that it can do both, referring to something as gpio just implies that both features exist. Micro controller devices make the pins configurable to increase utility in a fixed package size. I'm not as space limited so I'd only make a bi-directional line if I had need of it.
@@weirdboyjim sure,that’s of course absolutely the privilege of the designer and saves logic, space and power. And if you never need both functionality on the same pin/ line it absolutely makes sense. Maybe I was tempted to nudge you in that direction because it may make sense for others ( knowing me and how little time I have I probably some day implement it in verilog into one of my small ice40s rather than solder up all those boards ) or for a specific use case later to have configurable functionality without using an fixed i/o-chip like an 8255 or an serial GPIO expander. 😅
Fascinating project!! And it looks awesome 👌
Thank you!
Always nice to take a break on a complex project and work on something simple.
Some of what I'm doing will get quite complex, but more in the software side of things.
This might be a simple video, but opens up to all kinds of interesting possibilities.
One possibility that comes to mind is access to an SD Card which suddenly gives you access to a couple of GB of storage.
Indeed, I'm going to interface a few things in this series, some temporarily as examples but others to be new features in the build.
Awesome brainpower at work
Kind of you to say!
I am so happy that you made your thumbnail cleaner😅
Thumbnails are an art form and I'm not much of an artist. ;-)
Ive been watching for your new video.
Hope it didn't disappoint.
@@weirdboyjim It did not.
It's crazy how far you've come with this computer. I like the idea of adding more connectivity like the GPIO and UART. Do you think it would be possible to go further and add some sort of primitive networking like 10base-t with LLDP? It seems like it would be possible combining the designs you used for the VGA and UART.
It would be possible but I'm not going that way. My plan is to finish this build fairly soon and then start on a new system that takes things a big step forward. I'd spend too much time fighting the limitations of this design. 10base-t's transfer rate really doesn't suit a system with only 64k!
Suggestion:
Add a mass storage (Compact Flash, most likely) interface;
Make a simple filesystem driver (Any basic, optionally hierarchical file system should work);
Write a text editor that can read and write files on that drive, as well as an assembler and runtime program that act on files on the drive
This should make the computer entirely self-serving, provided you have a serial terminal [or an emulated version of one], since you can write files on the computer, compile them in-situ, and run them right then and there.
Maybe even lays the groundwork for a full rework of the firmware, where the ROM doesn't have the assembler/disassembler/etc. anymore but gets a 'boot from HDD' option that loads and runs the boot sector.
My plans already include a bit of storage, I will be able to move some features from the monitor to executable programs on the storage. There are limits to how far I'll go with this though, nobody wants to watch me spend the next year programming utilities.
thats DOPE , i have a question . the name of the cpu/computer is jam-1 , how much more are you planing to do with it before you move on to jam-2 or something like that ? what would you like to chande with jam-2 ?
I have a plan that takes me to end of Jam-1, trying to avoid distractions now.
Brilliant. I'll be most likely using 573 in my design (due to timings), this looks like The Way To Do It. Thanks.
I may switch to one of those if I can get a few.
I mean: 573 and 574 is The Way, depending on the needs and timings (and on when data is stable / needs to be stable) 🙂
You are changing the load signal after the output enable! which could cause problems if you were running at the limits of the chips but in this case your get away with it I expect. As the /OE only one propagation delay before the latch signal.
I noticed this as well, but then I realized that it doesn't really matter, since the only timing that matters is when the read happens are the other end. If the read is too early in this implementation then you could get old data, but if the OE is delayed then an early read would just get all zeros from the pull-downs, which it's still bad data. In the end it's probably better to not introduce more delay, and if it needs to push the limits then just figure out the settling time like you would with a ROM or etc.
@@khatharrmalkavian3306 it depends if the read is on the falling edge of the signal or the raising edge. But i think that's it's better to latch the data in before enabling the output, i always feel the data should be stable before you present it to the bus. even if it's just to stop noise on the bus.
I suppose that if the assert signal is basically just an address select and the read signal is used to read the bus then it is not a problem as long as there is a delay between the two events.
Looking forward to see how close we get to a PIA of days of old.
It's very difficult to build circuits and not have the off thing delayed by an inverter. Chances are if you dig into the implementation of these chips there may be subtle timing differences between the response to the load and the enable.
The LC display can also be controlled with GPIO.
Or you implement an I2C bus. This then gives you access to many sensors.
Yeah, you can interface to just about anything with gpio. The LCD modules like mine that talk serial protocols usually have a little board on the back. The next video in this series (should be out in a few days) talks about SPI.
super chill
Thanks twobob!
The MCUs I've used so far seem to have more than one port. Do you have any future plans for Dev 13? The possibility of not needing an adapter board to run a 16-bit device could be useful.
How hard is it to develop plug-and-play code? That could be a great topic for either this series or the next.
If so, would it make any sense to add standard connectors like PS/2 or D-sub to the final GPIO board as connectivity options?
Plug and play code isn't really that tough. You just need to be robust enough to tolerate weird things happening, there might need to be some effort put into making the circuits more tolerant as well though.
At around 7:00 you have the pinout for the 74xx541 shown which you aren't using. Great video though! It's a great day, a James Sharman video and a Ben Eater video release around the same time!
But I am showing one and taking about it. It was deliberate but I didn’t mean to be confusing.
@@weirdboyjim Ok. The schematic had '574s on it and I thought you had finished talking about the '541 earlier and went on to use a second '574 at that point. No worries, I just figured I'd point out something that might have confused others.
This is a nice start, would be cool to add a little state engine and a buffer to this so you can emulate some serial interfaces without having to bit bang using the processor.
Well, I'm mostly going to do some bit banging with this but I may add the odd support component where it makes sense. Obviously I have the UARt series as an example of going all the way in the other direction.
@@weirdboyjim Yes, but with a little effort on the GPIO side you could potentially replace the UART and have something really quite unique in the DIY processor space. Thinking UART, SPI, I2C etc. and it would be a solid series of content to.
wow, interesting, thanks
Glad you enjoyed it
I wonder if your gona go down the same route RPI did where their UART runs on the GPIO header?
No, micro controllers do that for a variety of reason, not least they can they can often add hardware more easily than they can add pins to the package. I could make lines work like that but it would take me extra circuitry and ultimately it would be more restrictive than having the uart on a separate header.
very interesting , especially the part about a switch program being the baintent underutilization of resources you have or was it overutilization .. me english not so good in technical.
anyway as you stated blink program on arduino is making something overcomplicated to perform simple tasks i bet your cpu is not up to the task i am trying to shoehorn atmega8 ic in place of arduino :] and that being a dcc decoder for a train layout ...well if you could run at 16 mhz your cpu probably would be up to task of controlling model trains or being a train too but that is just the clock frequency for commonly used atmel and pic microcontrollers
by the way happy easter
Glad you liked it, I don't know enough about your dcc decoder to know it's performance requirements.
congrats for "success at the first try". Do you want to protect those GPIOs somehow from strange handling / abuse, or is this something you put away for jam because you consider it kind of a controlled environment?
Do you have any suggestions for protection? Mostly the 574's sitting between test circuits and the main cpu should protect the cpu at least.
@@weirdboyjim no. Much more was I interested in how to protect a gpio. Seems to me such a protection could be quite a task, because of so many usecases.
@@peter.stimpel Yeah, "protect against what" is the big question.
@@weirdboyjim If you wanna attach different peripherrals, maybe you would ask for a certain impedance, and protect against some overvoltage as well.
One way I've seen is to have 5v zener diodes on the input. Anything over 5v and the zener clamps the voltage to 5v (might want to include a resistor to limit the current). Also has the advantage that it protects against negative voltages on the input as well.
What is the piece called that you are using to short all the led array's output pins together? Currently I am only able to short the pins if I have an individual wire for each output pin. Tried looking but haven't been able to find it.
That's a resistor array. It has 8 resistors all tied to a common pin that I'm connecting to ground. You don't want to short the pins!
What's the software you're using to make your schematic? I've googled quite a bit but I can't find any program that looks like the one you're using.
That is “EasyEda”, it’s a free online system.
Will there be more CPU updates? Or is it in its final state? Maybe some new cool functionality like GPR banks or an arithmetic coprocessor for hardware multiplication and division? Or will it only be peripherals from now on? Also, would like to get a separate video on instruction set, what instructions there are and how are they encoded and why where they chosen, because it's been so long and all in separate videos I've already kinda forgot what instruction set limitations there are... Also would be interested to know about some cut features, something you've wanted to add to your build but decided not to...
There will be a few more videos finishing the series of, but for big architectural differences you'll need to wait for the sequel series.
Fun :-)
Thanks!
I hope you add a thermal printer. It would be extremely trivial, but would be neat nonetheless.
I’m going to have to admit, that is not one I considered!
a lot of soldering, reminds me of raspi or doing several pico, which was still less than here ...
Then try not to think about all the soldering I did on the rest of the build!
@@weirdboyjim I'm still trying not to think about Pink Elephants! ;-)
a newbie here. maybe you can replace the two 555s with a single 556? excellent videos! keep it up!
You posted this exact comment on the analogue in video, I’ve answered it there.
"This isn't DOS dufus!" LOL!😆
One day it might do something real!
I can see the utility and the need for GPIO, but honestly not a very exciting video series to me. That doesn't mean I won't watch, comment or enjoy them, just that it isn't very exciting to me.
Well I hope you find something more to your taste in the later videos in this series.