You didn't get lucky. You worked the problem and understood that you needed a delay. The delay only has to be a few thousands of a second. I watched older Ben Eater videos and learned that the delays are honestly needed for all signals to get to the right place at the right time. Your doing good, keep it up!
@IAMSolaara
Жыл бұрын
I love how you're getting slightly more unhinged with every part XD
@stevedonkers9087
Жыл бұрын
A Zener diode is a diode with a very specific reverse breakdown voltage. I'm sure you know your regular diodes - current flows one way but not the other EXCEPT when the voltage is higher than that diode's rated reverse breakdown voltage. Zener's are just controlled versions of that designed to be used in reverse. You can use them to clamp voltages to specific values and such.
@nunes1907
Жыл бұрын
14:02 you're very wrong sir! that's exactly why we're here for... 😀
@PlumGurly
3 ай бұрын
A Zener diode is a diode used for voltage regulation. So it clamps when the voltage gets so high. You wouldn't use those for rectification or signal diodes since they don't conduct unless the voltage reaches the specified amount. (You can sometimes use regular ones this way, but that's more for very small voltages such as in audio circuits.) I've always pronounced that as Zeener. The E is long. And for the timing problems, you might need flip-flops/latches to delay things by a cycle (or a half). That is true of most of the x86 CPUs, though for different reasons. Not everyone knows about T-states.
@Symplegades
Жыл бұрын
I feel ya on the breadboard issue...over the last year, I've bought boards from 3 or 4 different sources and it doesn't matter where you get them from, they all still seem to be garbage. it's infuriating to cobble something together on the board, have it not work, spend an hour or 2 checking and rechecking the schematic only to find out, usually by accident when your finger grazes a random resistor or cap, that the issue all along was a faulty contact in the board itself. /boardrage Great work, though, and keep it up.
@Fox-Tech
Жыл бұрын
Hopefully the busboard boards work out. They cost a bit more, but seem to keep the contacts better so far. Have to see how it works out when I get everything moved over.
@shinypb
Жыл бұрын
I love these videos. Thank you for making them!
@PardusRain
Жыл бұрын
Nice seeing this motherboard and I can relate to the coding talk, timing loops are strange creatures, particularly in a multi core environment.
@RogerioMachadoM
Жыл бұрын
I think you can delay on a single line(write enable) instead of delaying the address bus! Cascading an 74hc00 can do the job. An inductor or resistor + logic gates can be used to delay the signal too. Adding some decoupling capacitors can prevent future headaches even running the CPU at low frequency
@Fox-Tech
Жыл бұрын
The problem is that the write enable is already active from the previous cycle when the address changes. Delaying it won't help as it's already asserted. There are a number of decoupling caps on the breakout board (hidden in the space under the socket, to stay close) but I should probably start adding them to the breadboard as well.
@MichalTulacek
Жыл бұрын
Thank you!
@rileyfaelan
Жыл бұрын
A Zener diode is the strange kind of diode that doesn't break if current flows 'backwards' through it, and it lets current through backwards past at a rated voltage difference. They are useful to protect hot-pluggable circuits against static discharges, even so much so that there's even readily available arrays designed specifically to protect chips living close to USB cables against voltage shots upon plugging, they can be used for voltage regulation (with some caveats), and if you feel a wee bit naughty, you can even use one to do simple signal level translation (at the cost of leaking power during operation).
@veneroso3337
Жыл бұрын
Hey you're doing well keep it up
@scotts-tech
Жыл бұрын
That was an interesting an unexpected problem. It would be interesting to see exactly what that would look like with an oscilloscope. I want to start something like this, I actually ordered a 486 breakout board myself, along with a breakout board I designed for a xc2c128 cpld. I've been studying and doing a lot of research on the 486 cpu. On table 7-7 on page 7-19 of the 1990 edition of the Intel i486 Hardware Reference manual, it shows a table of bus cycle definitions that you can decode from M/IO, D/C AND W/R. It is intended to use this to generate the MEMR, MEMW, IOR, IOW and INTA signals. You'll notice the combination where W/R = 1, D/C = 0 and M/IO=1 is "reserved". I don't remember off the top of my head what you said you're doing with the M/IO and D/C signals but I was wondering if perhaps that "reserved" cycle is what happens right before ADS is asserted. I want to try connecting those 3 signals to a 74x138 address decoder, using ADS as the output enable and using the outputs of that decoder for MEMR, MEMW, IOR and IOW. Perhaps this will catch the invalid bus cycle. Seems strange that the book doesn't mention anything about this problem and there's not a "valid bus cycle ready" pin or something. I haven't read the Intel i486 datasheet cover to cover though so maybe there's stuff about it in there.
@Fox-Tech
Жыл бұрын
Actually, what you said about the 74x138 is exactly what I'm doing to generate the control lines. I don't see the reserved cycle unless I get the pins turned around. As for what the reserved cycle is, In the Nov 1989, section 6.2.5 (Bus Cycle Definition) says this on the second paragraph. "Note there is a difference between the 486 microprocessor and 386 microprocessor bus cycle definitions. The halt bus cycle type has been moved to location 001 in the 486 microprocessor from location 101 in the 386 microprocessor. Location 101 is now reserved and will never be generated by the 486 microprocessor." So, the reserved cycle used to the be the halt cycle on the 386. It was probably changed as on the 486 it's actually a special cycle, of which halt is the most common if everything is working right,. You are supposed to use the BE0-3 pins (And A2-A3 on later chips) to see exactly what special cycle it is.
@hans429
Жыл бұрын
Zenners have a defined "Breakdown" voltage, lik Reverse Bias 6.6 or 12.6 or 3.3V or sth lk tha....used vor voltage stabilisation. A Ordinary Diode holds up to some hundret Volts backwards and no body knows how mouch percisely.
@Jackpkmn
Жыл бұрын
Huh its almost like a breadboard isn't the best media for this type of project. If only there was a better media for prototyping complex circuits like this I thought there was but I cant quite wrap my wire around it...
@TomStorey96
Жыл бұрын
I see what you did there...
@gameboyv1790
Жыл бұрын
Wow
@eh___1449
Жыл бұрын
Found any solution on how to implement the READY# line? I’m planning on building something similar to yours, just using a 386sx, and i found no way to implement the READY# signal other than using a fixed delay.
@Fox-Tech
Жыл бұрын
Pretty much either keeping it asserted at all times (which is what I do when I'm running everything slow) or using a delay counter like I build in part 4.5.
@kakosnonos4541
Жыл бұрын
Cool!
@scotts-tech
Жыл бұрын
I'm trying to do this exact thing with a 486sx right now. Could you share what combination of cpu control settings you used to make it work? What did you set KEN, smiact, stpclk to and stuff? Also, what resistor and capacitor values are you using in order to generate a 50% duty cycle square wave of 6hz or faster on the 555 timer? Mine is close to a 50% duty cycle but not quite. I haven't figured out how to get mine to work. I have an oscilloscope and can see what's happening on output pins. As soon as I power it on, ADS immediately goes high, then low for 1 clock cycle and then it goes high and stays high indefinitely. It doesn't seem to respond to reset, it does the same thing whether reset high or low. I'm doing NMI and INTR tied to gnd, BRDY high, RDY low, SMI high and SPTCLK high, all using 1k ohm resistors. Sometimes an address pin or 2 goes high but it's obvious the cpu isn't doing anything based on M/IO, D/C and R/W
@Fox-Tech
Жыл бұрын
The model I have is a very early one, so it doesn't have SMIACT, STPCLK or the debug pins. For that I would have them all pulled to whatever in the inactive state is for them. As for resistors, I'm using a 10k oms. On the 555 I'm using 10uF on the Trigger, 10nF on the Control, 330 ohm on the Discharge, and 1k + 10k pot on the Threshold. It's not exactly 50%, but it seems to be close enough. I also have 8 10nF caps stuck under the CPU to provide decoupling. For my board, I have IGNNE#, BOFF#, EADS#, KEN#, FLUSH#, A20M#, BRDY#, BS8# and BS16# pulled to high, and HOLD, AHOLD, RESET, RDY#, INTR, NMI pulled low. Which matches what you said you are doing (and you won't have to worry about the IGNNE# pin of course) You didn't say what you were doing with the AHOLD, HOLD and BOFF# lines, also, are you setting the SRESET line? That has mostly the same effect as RESET does. I would also check if you have the debug pins (which looks to have been added to the SX2). The same goes for the UP# pin (though if that was the problem it would be floating everything). Also be aware that the SX has the NMI on a different pin then the DX/SX2 chips, so double check you have that right, otherwise it might be floating. If the AHOLD is asserted, the CPU will start in self test mode, which can take a very very long time if you're running at 6hz. As it is, reset take about 200 clocks normally, where as the self test runs at 2 to the 20th clocks.
@scotts-tech
Жыл бұрын
@@Fox-Tech I didn't realize that the sx has NMI in a different spot. I also didn't know the reset self test takes ~200 clocks, I guess I missed that when reading the datasheets. It seems to take around 200 clock cycles for stuff to start happening whether I'm asserting AHOLD or not but when stuff "starts" happening, it seems to perform only a few operations before giving up. I think 1 time I actually got it to do normal-looking continuous activity on the 555 timer. Other than that, if I connect a 1mhz clock oscillator to it and power cycle and reset it over and over, maybe 1 out of every 100 attempts, it starts doing normal continuous operation but that's not quite reliable enough to do anything with. I have 6 0.1uF and 2 1uF capacitors under the pga168 socket on mine. I'm also having weird power issues. All my atx psus keep triggering their short circuit protection on this thing but there's no actual short circuit anywhere, nothing gets hot (or even warm), there's never been magic smoke, the 5 volt rail stays at 5 volts +/ 0.03 volts the entire time, power draw from the ac plug is under 20 watts. They can run the system for anywhere from 2 seconds to 5 minutes before shutting down. What are you using to power yours anyway? Does your breadboard confuse atx psus also? I've been using atx power supplies for random diy projects for years and I've never seen this behavior before. Edit: I found a 2006 dell psu that works no problems as long as I have 3 pairs of 5 volt/gnd wires connecting to the breadboard.
@Fox-Tech
Жыл бұрын
About the only thing I can think of is one of the reset lines aren't correctly pulled to ground. Otherwise I'm at a loss without being able to go hands on with it. As for power, I'm just using a breadboard power supply that provides a solid +5v and can also do +3v. It's probably not powerful enough to run everything at full speed, and I'm planning for whatever backplane I make to have an ATX power connection so I can use a modern power supply.
@scotts-tech
Жыл бұрын
@@Fox-Tech Ok so I solved my power supply issues more or less. I've done a lot of troubleshooting and reworking of stuff in the last several days but the thing I'm stuck on now is that upon startup and then reset, the cpu runs its 200 or so clocks, reads 16 bytes (well actually 11 bytes, every 2 bytes it reads, it skips the 3rd one and then proceeds to read the 4th byte) and then stops doing stuff. Now I've improved signal integrity a lot in the last few days (i.e. making square waves square, getting rid of ringing, voltage drops, etc) but this has me kind of stumped. Did you encounter anything like that? Reading the first 16 bytes and then completely stopping until reset gets pressed again? I would think that even if its not receiving valid data, it would at least do random undefined stuff for more than 1 16 (actually 11) byte read cycle. I'm connecting BS8 to ground, I've also tried BS8 tied to ground with a 10kohm resistor and BS8 to ground with a 1kohm resistor but it seems to be the same. BE0-3 is supposed to only have 1 of them go low at a time in 8 bit mode but that's not what happens for me. I tried connecting each BE line to an or gate and used the inverse of ADS as the second input and then used each corresponding output of that as the OE (pin 19) on each of my 245 transceivers. This still doesn't work because although it reduces bus contention by only activating a transceiver when there is data on the bus, more than 1 BEn pin goes low at a time which messes everything up. So tl;dr: my problems right now are 1. that more than one byte enable goes low at a time despite BS8 being asserted and 2. the cpu stops doing stuff after the reading the first 16 bytes (except it's not a 16 byte read cycle it's 11 because it skips the next byte for every 2 bytes it reads). At least i'm closer than I was a few days ago lol. I'll post oscilloscope and logic analyzer screenshots on the homebrewcomputer subreddit's discord server
@Fox-Tech
Жыл бұрын
A cache line is 16-bytes, and it seems like the CPU will read all of them before starting to execute. It's something I've really noticed when running it slowly as it will read the 16-bytes, then pause for a number of cycles (but not a huge amount, maybe 10-20) to execute. As for why it's stopping there, my guess would be that it's ended up in a shutdown state, but you would usually see more activity then that. As for the BE0-3 lines. The CPU will assert all the bytes it wants even if BS8 is active. With BS8 it will only use the lowest byte, then redo the cycle with that byte disabled (IE, if you were reading a DWORD A byte at a time, the BE0-3 lines would look like 0000 1000 1100 1110 for all four cycles). The Datasheet provides the logic needed to generate the A0-A1 lines from the BE0-3 lines. This is a priority encoder, so the generated A0-A1 will always represent the lowest byte. You would then need to send the A0-A1 though a 2-4 decoder to generating your output enable lines for your transceiver.
@samplesandtests
Жыл бұрын
i spend more time editing out my um's and my uh's of my videos, and i don't get all of them.
@zorbahls
Жыл бұрын
I don't think you need latches. Maybe you should simply read or write to memory on rising edge of CLK
@Fox-Tech
Жыл бұрын
That was my first thought, but it didn't work. Wait states can cause a read or write cycle to take multiple clocks, and the cpu can sometimes insert its onw wait states due to the pipelining. The net effect is that sometimes you end up writing the same data multiple times, which can cause problems if something happens on the write, such as having the data sent over the UART.
@zorbahls
Жыл бұрын
@@Fox-Tech I see, how about reading or writing on rising edge only when ADS# is low etc. (i mean when all necessary signals shows that everything is ready to read or write)
@Fox-Tech
Жыл бұрын
Sadly, the data bus doesn't appear to be valid until ADS# is high (running it slow enough, you can see the cpu changing data right before ADS# going high) so that won't work either. It's a good idea, and I'm sure it's workable with a few more support chips and logic, but I don't really have the know how yet to do that myself. So I end up with more of a brute force solution for the time being.
@zorbahls
Жыл бұрын
@@Fox-Tech I'm sure you figure out it. I'm looking forward to next videos. Great project
Пікірлер: 40