@@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 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?
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 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.
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.
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.
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 RU-vid 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.
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.
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. 😅
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.
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!
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!
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.
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.
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.
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.
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.
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...
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.
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.
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.
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
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 ?
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.
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.
