• Please review our updated Terms and Rules here

I decided to take a few steps back and decided to create a 80188 CPU computer instead

80186 Enthusiast

Experienced Member
Joined
May 18, 2023
Messages
53
(WARNING: LOST OF TEXT AND IMAGES)​

In my previous post, I learned that if I wanted to make a 16-Bit 80186 CPU Computer, I would've needed 16 bit wide memory and use the HBE pin. So I decided to make a 80188 Prototyping system before making a 16-Bit system. I'll also go over the details of this project in depth in this post.

Why start with an 8-Bit system? Simple! so I can develop the essentials for this project! The 80188 ended up being easier for me to wrap my head around.

Here are some of the details of this current project:
Name: Sea Otter I188 Environment Prototyping System
RAM: AS6C4008-55PCN (512k SRAM)
ROM: Windbond W27C512-45Z (64k EPROM)
CPU: 80c188

I won't be creating an address decoder that's capable of bank switching until I require it in later prototype designs and I learn more about Bank Switching.

This design is intended to connect jumper wires to a breadboard that has the Hardware that I'll be testing with to add to the next Prototype revision. I've based the CPU side of the schematic off of Slador's YouTube Tutorials and Official Intel documentation. For my system, I'll be using the Multi-Master Bus to Interface to several Bus Masters such as a 8279 Keyboard Controller, a Raspberry Pi Pico for VGA video Output, and a 8255 PPI to read and write data from an SD Card to be used for a cartridge slot and for SNES controller slots.

Here is the schematic and PCB design (with no ground planes so all of the traces are visible) I've made for this project (I'll provide higher quality images in a reply to this post):
Schematic_SO 8-Bit Prototype Computer 2_2023-05-24.png
PCB_PCB_SO 8-Bit Prototype Computer 2_2_2023-05-23.png

As I stated, this board is used for testing the Multi-Master Bus and interfacing to hardware on a breadboard.
Why use a Raspberry Pi Pico for VGA Video? So I can program a Video Controller that's more or less exactly what I need for this project!

If any of you guys see any errors I've made in the schematic or PCB design, please tell me.

As for the future of this project. After creating a PCB that has all of the hardware that I've tested with and having an Address Decoder that's actually good, I'll build a finalized 8-Bit System. As for the OS for this machine, that's something a Friend and I are making together. the OS is called SOOS (Sea Otter Operating System) and that will be inspired by MS-DOS and Early Versions of Windows. I'll make mock-ups of what the OS will look like soon. I Do not plan on adding a Mouse to this Computer because It'll be a headache trying to find a PS/2 Controller IC that supports Mouses and then coding for that, Unless I can use a Raspberry Pi Pico to make that easier, but even then, that's more coding I don't want to go through. SOOS will be controlled only by the Keyboard and SNES controllers as I'll make it extremally easy to interface with, without a mouse. for future 16-Bit prototypes, I may experiment with adding a Mouse due to having a wider Data Bus and overall better capabilities.

as for the address Decoder, I'll make it more and more complex as I make more and more complex designs that have other Bus-Masters on the Multi-Master Bus. Only an LCD screen and the Memory Chips will be on the CPU local Data and Address Bus.

That's it for this post detailing this project, I'll defiantly create more posts about this project as I continue to keep working on it!
Your feedback and advice will be thanked in advanced! Thank you for reading my post here!
 
A few things to start with.

I would put a diode across R1 (with the diode pointing 'upwards' to +5V).

I think ARDY and SRDY should be HIGH and not LOW. I have seen one of the two deliberately pulled LOW - but then the other one is used to generate the appropriate READY signal from external logic.

I will need to check whether ALE directly driving the latches you have chosen is the correct sense. It does work for the INTEL latches - but I vaguely remember having to include a 7404 inverter when I used the non-INTEL 74 series latches. However, the ones you have chosen may latch on the correct edge. I may also be confusing the INTEL part with the ZILOG Z8... EDIT: The '573 looks OK.

I am not entirely sure why you have /S2 gated with the RAM /CE signal. When A19 is LOW, the RAM /CE is LOW also. When A19 is HIGH and /S2 is HIGH this signifies a memory access (or no bus access = passive). So I am not sure what this is bringing to the party. You may want to use /S2 to INHIBIT the RAM - if an I/O transfer is being performed.

What are DRQ0 and DRQ1 tied to?

Why is TMR_IN_1 not connected? It should be connected in a similar manner to TMR_IN_0.

Ah, I see you have included the complication of the 8288 and 8289 in the next schematic. OK, I will have to look through that one later... I would now assume that you would need to incorporate the ARDY signal now to account for 'slower' devices on the external bus.

EDIT: I see you have incorporated /LCS into the logic for the bus arbitration. However, you are not using /LCS for the local RAM but A19 being LOW. Perhaps you should be including A19 instead of /LCS?

Dave
 
Last edited:
Just found this little nugget in the Intel manual:

1685474424040.png
After a reset, the /UCS signal will wait for an external ready automatically. If the external ready never activates - it will never work...

Dave
 
I am not entirely sure why you have /S2 gated with the RAM /CE signal. When A19 is LOW, the RAM /CE is LOW also. When A19 is HIGH and /S2 is HIGH this signifies a memory access (or no bus access = passive). So I am not sure what this is bringing to the party. You may want to use /S2 to INHIBIT the RAM - if an I/O transfer is being performed.

I was puzzled here too, but...
Ah, I see you have included the complication of the 8288 and 8289 in the next schematic. OK, I will have to look through that one later... I would now assume that you would need to incorporate the ARDY signal now to account for 'slower' devices on the external bus.

I guess now I'm really confused. I guess my first question is why are these devices included if this is supposed to be a "simple" 80188-based computer? The 80188 has a subset of the 8288 built into it and supplies most of the necessary arbitration signals itself (and the few it doesn't you can replicate pretty easily), and the 8289... that's a really complicated moving part that, again, why do you need it? The chip has its own HOLD/HDLA signals built into it if you just need another device to be able to halt the main CPU. I have to be a little blunt maybe, but... if the 80186 is "too confusing" because it has an HBE pin it seems a little ambitious to jump straight into MultiBus.

I'm going to leave the 8289 completely aside for now and concentrate on this memory select thing: I guess the reason the system is gating RAM with /S2 is because they're not using LCS as a direct device select and thus, since the 80188 doesn't have separate I/O and RAM read/write signals, you do need to gate on something or it *is* going to activate RAM during port I/O. I guess what I find a little baffling is why there's this separate gating on the RAM CE line when, if the system is incorporating an 8288, there are separate memory and I/O read/write signals coming out of that? (The schematics only show the I/O lines from the 8288 being used; if you're going to spend the money on it why not use them memory R/W lines too?) If the 8288 were not present and you had already decided against basing the memory select on the LCS/MCS lines then you're going to need something like this, but here's the problem: As drawn out here this isn't going to work. Here's a quote from section 3.1.6.1 of the AP-186 user manual:

Note that the 80186 does not provide separate I/O and memory RD signals. If separate I/O read and memory read signals are required, they can be synthesized using the S2 signal (which is low for all I/O operations and high for all memory operations) and the RD signal (see Figure 11) It should be noted that if this approach is used, the S2 signal will require latching, since the S2 signal (like S1 and S1) goes to a passive state well before the beginning of T4 (where RD goes inactive). If S2 was directly used for this purpose, the type of read command (I/O or memory) could change just before T4 as S2 goes to the passive state (high). The status signals may be latched using ALE in an identical fashion as is used to latch the address signals (often using the spare bits in the address latches).

In short, if you don't want to use the 8288's outputs to universally supply separate read/write signals you're going to need to latch S2 on ALE. That's fine, you have spare gates for that on one of your 74LS573's... but, if you're going to do that you might want to reconsider using the 8288 at all? The 80188 has its own DT/R, DEN, and ALE (and can supply INTA with one of its programmable internal interrupt controller pins) signals. I'm not sure what it's really buying you.

Also: Why a 74LS05 open-collector inverter? The schematics don't show a pull-up on the output side, so this has the potential to behave badly. An open-collector is only needed if you have multiple outputs that might potentially want to pull down the same input. (IE, a wire-OR.)
 
My thoughts on the 8288 and 8289 exactly (at this stage of the game).

One thing that is missing is a means of talking with the beast! You need a USART, and then you can use one of the timers as a baud rate generator.

Nice spot with the 74LS05 - I assumed it was an 04 (without checking).

Dave
 
My thoughts on the 8288 and 8289 exactly (at this stage of the game).

Yeah. If I were doing this I'd probably do one of these two things to interface the memory and skip the 8288:

A: If I were *sure* I just wanted 512k of RAM I'd use a multi-input AND on LCS and two MCS lines for RAM CE and just program them appropriately to fill the bottom half of the memory space. (One 256K chunk and two 128K) That would take care of the IO/memory qualification.

B: Whip up my own little decoder to turn S2/RD/WR into separate I/O and memory R/W signals. This makes bus interfacing nice and friendly, and there's a schematic for doing it in '186 manual that would just need the 1 bit latch, a quad OR gate, and an inverter.
 
A few things to start with.

I would put a diode across R1 (with the diode pointing 'upwards' to +5V).

I think ARDY and SRDY should be HIGH and not LOW. I have seen one of the two deliberately pulled LOW - but then the other one is used to generate the appropriate READY signal from external logic.

I will need to check whether ALE directly driving the latches you have chosen is the correct sense. It does work for the INTEL latches - but I vaguely remember having to include a 7404 inverter when I used the non-INTEL 74 series latches. However, the ones you have chosen may latch on the correct edge. I may also be confusing the INTEL part with the ZILOG Z8... EDIT: The '573 looks OK.

I am not entirely sure why you have /S2 gated with the RAM /CE signal. When A19 is LOW, the RAM /CE is LOW also. When A19 is HIGH and /S2 is HIGH this signifies a memory access (or no bus access = passive). So I am not sure what this is bringing to the party. You may want to use /S2 to INHIBIT the RAM - if an I/O transfer is being performed.

What are DRQ0 and DRQ1 tied to?

Why is TMR_IN_1 not connected? It should be connected in a similar manner to TMR_IN_0.

Ah, I see you have included the complication of the 8288 and 8289 in the next schematic. OK, I will have to look through that one later... I would now assume that you would need to incorporate the ARDY signal now to account for 'slower' devices on the external bus.

EDIT: I see you have incorporated /LCS into the logic for the bus arbitration. However, you are not using /LCS for the local RAM but A19 being LOW. Perhaps you should be including A19 instead of /LCS?

Dave
DRQ1 and 2 are tied to 2 pins on a pin header.
S2 is gated with A19 to let the RAM know when the CPU is reading, writing or fetching an instruction from memory.

according to Slador, the YouTuber I linked in my post, that timer pin gets pulled low to use the CPU's clock as the Clock Generator.

For the RAM, i am using A19 though?

Thanks for the Feedback, Dave! :)
 
My thoughts on the 8288 and 8289 exactly (at this stage of the game).

One thing that is missing is a means of talking with the beast! You need a USART, and then you can use one of the timers as a baud rate generator.

Nice spot with the 74LS05 - I assumed it was an 04 (without checking).

Dave
I'll defiantly add a USART of some kind, That'll be on the Multi-Master Bus Interface!
 
Yeah. If I were doing this I'd probably do one of these two things to interface the memory and skip the 8288:

A: If I were *sure* I just wanted 512k of RAM I'd use a multi-input AND on LCS and two MCS lines for RAM CE and just program them appropriately to fill the bottom half of the memory space. (One 256K chunk and two 128K) That would take care of the IO/memory qualification.

B: Whip up my own little decoder to turn S2/RD/WR into separate I/O and memory R/W signals. This makes bus interfacing nice and friendly, and there's a schematic for doing it in '186 manual that would just need the 1 bit latch, a quad OR gate, and an inverter.
so you're saying I should've used the other gate on the 74LS20 for an address decoder for the RAM??? why didn't I think of that-
 
I was puzzled here too, but...


I guess now I'm really confused. I guess my first question is why are these devices included if this is supposed to be a "simple" 80188-based computer? The 80188 has a subset of the 8288 built into it and supplies most of the necessary arbitration signals itself (and the few it doesn't you can replicate pretty easily), and the 8289... that's a really complicated moving part that, again, why do you need it? The chip has its own HOLD/HDLA signals built into it if you just need another device to be able to halt the main CPU. I have to be a little blunt maybe, but... if the 80186 is "too confusing" because it has an HBE pin it seems a little ambitious to jump straight into MultiBus.

I'm going to leave the 8289 completely aside for now and concentrate on this memory select thing: I guess the reason the system is gating RAM with /S2 is because they're not using LCS as a direct device select and thus, since the 80188 doesn't have separate I/O and RAM read/write signals, you do need to gate on something or it *is* going to activate RAM during port I/O. I guess what I find a little baffling is why there's this separate gating on the RAM CE line when, if the system is incorporating an 8288, there are separate memory and I/O read/write signals coming out of that? (The schematics only show the I/O lines from the 8288 being used; if you're going to spend the money on it why not use them memory R/W lines too?) If the 8288 were not present and you had already decided against basing the memory select on the LCS/MCS lines then you're going to need something like this, but here's the problem: As drawn out here this isn't going to work. Here's a quote from section 3.1.6.1 of the AP-186 user manual:



In short, if you don't want to use the 8288's outputs to universally supply separate read/write signals you're going to need to latch S2 on ALE. That's fine, you have spare gates for that on one of your 74LS573's... but, if you're going to do that you might want to reconsider using the 8288 at all? The 80188 has its own DT/R, DEN, and ALE (and can supply INTA with one of its programmable internal interrupt controller pins) signals. I'm not sure what it's really buying you.

Also: Why a 74LS05 open-collector inverter? The schematics don't show a pull-up on the output side, so this has the potential to behave badly. An open-collector is only needed if you have multiple outputs that might potentially want to pull down the same input. (IE, a wire-OR.)
The reason why I'm not using the Memory Read and Write Pins on the 8288 is because I don't want to use Memory on the Multi-Bus, only I/O Controllers like Video and Keyboard Controllers.

The datasheet for the 80186/188 shows what the multi-master bus interface looked like, and reading through the Introductory manual, I knew this interface would be exactly what I need for this computer. I'll have several I/O Controllers on board, and I believe the Multi-Master Bus will be needed to help interface to all of those I/O Controllers with strict rules and guidelines on when each I/O Controller, acting as a Bus Master can have access to the Data/Address Bus. It was that level of control that sold me on the Multi-Master Bus Interface.

So I need Resistors on the Output sides on the inverters? Got it!

Thx for the feedback!
 
>>> So I need Resistors on the Output sides on the inverters? Got it!

Or use a 74LS04 inverter instead - this device is not open collector and, therefore, doesn't require the resistors.

I am not convinced that you require a MULTI-MASTER bus interface personally. You may require a data bus buffer to prevent loading on the data bus - but most (if not all) of your peripherals should work on the local bus. This is how our 286 MUTIBUS cards operate at any rate.

Dave
 
A few things to start with.

I would put a diode across R1 (with the diode pointing 'upwards' to +5V).

I think ARDY and SRDY should be HIGH and not LOW. I have seen one of the two deliberately pulled LOW - but then the other one is used to generate the appropriate READY signal from external logic.

I will need to check whether ALE directly driving the latches you have chosen is the correct sense. It does work for the INTEL latches - but I vaguely remember having to include a 7404 inverter when I used the non-INTEL 74 series latches. However, the ones you have chosen may latch on the correct edge. I may also be confusing the INTEL part with the ZILOG Z8... EDIT: The '573 looks OK.

I am not entirely sure why you have /S2 gated with the RAM /CE signal. When A19 is LOW, the RAM /CE is LOW also. When A19 is HIGH and /S2 is HIGH this signifies a memory access (or no bus access = passive). So I am not sure what this is bringing to the party. You may want to use /S2 to INHIBIT the RAM - if an I/O transfer is being performed.

What are DRQ0 and DRQ1 tied to?

Why is TMR_IN_1 not connected? It should be connected in a similar manner to TMR_IN_0.

Ah, I see you have included the complication of the 8288 and 8289 in the next schematic. OK, I will have to look through that one later... I would now assume that you would need to incorporate the ARDY signal now to account for 'slower' devices on the external bus.

EDIT: I see you have incorporated /LCS into the logic for the bus arbitration. However, you are not using /LCS for the local RAM but A19 being LOW. Perhaps you should be including A19 instead of /LCS?

Dave
These images show where the DRQ pins are. I apologize for the low quality PCB image before.

Screenshot (124).pngPCB_PCB_SO 8-Bit Prototype Computer 2_2_2023-05-31.png
 
>>> So I need Resistors on the Output sides on the inverters? Got it!

Or use a 74LS04 inverter instead - this device is not open collector and, therefore, doesn't require the resistors.

I am not convinced that you require a MULTI-MASTER bus interface personally. You may require a data bus buffer to prevent loading on the data bus - but most (if not all) of your peripherals should work on the local bus. This is how our 286 MUTIBUS cards operate at any rate.

Dave
After reading about the Multi-Bus in the AP-186 Introduction to the 80186 PDF, I knew that's the interface I'd need for all of my I/O Controllers. Having more Control for when each I/O on the Multi-Bus is what I needed, especially for the Video and Keyboard Controller I plan on using. Having strict rules and guidelines on when each Bus-Master has access to the Data/Address Bus is something I need for this project. For the future of this project, I will have many, many bus masters and the Multi-Bus from what I understand is the best way to unify all of them together under a single System Bus while preventing bus contention and Bus Masters conflicting with each other.

I apologize if I seem aggressive, mean or rude in this reply. I didn't mean to come off as such!
 
Thanks.

I never like things like DRQn inputs floating. I think they can be disabled in software anyhow (so shouldn't affect the operation of the CPU). I would check any pin that claims to be an input and ensure that floating is an acceptable state.

You need to be aware that each MULTIBUS bus master requires a similar bus interface logic to the CPU for accessing the MULTIBUS. You can use either serial bus arbitration (there are timing constraints with this) or parallel bus arbitration (requiring a centralised arbiter comprising of an 8:3 priority encoder and a 3:8 priority decoder wired back-to-back). Each bus master will also require address, data and control bus buffers. The overhead of using this for something as simple (IMHO) as a video and keyboard controller doesn't seem logical to me. But then I don't know what your ultimate goals are.

I use MULTIBUS at work - lots of 80286 CPU boards, multiple intelligent communications controller cards and an I/O sub-system interfacing the computers to analogue, digital and other I/O cards for process control and monitoring. I won't tell you what my software controls... The CPU and intelligent communications cards are packed with logic chips. There is no spare space on any of the boards. In this case, I wouldn't be designing my own - I would be purchasing the cards. (I have been running a recent project to get a number of these cards remanufactured. Not a cheap enterprise...).

If you are going down the line of using MULTIBUS, then I would suggest getting a copy of the MULTIBUS specification and designing your cards around that. I would also be downloading the Intel manuals using the 80188 reference design as the basis for your development. As stated above, MULTIBUS will require that the ARDY line is used to suspend the CPU until it has access to the bus. What happens if it doesn't gain access to the bus? It will hang forever! The design should incorporate some mechanism for timing out a failed bus transaction and alerting this fact to the CPU (e.g. a bus timeout interrupt).

If you want to start off simple by getting a working 80188 design to start with and then learn from that and move on to the next step - then I would just stick with an 80188 CPU, a couple of address latches, an ERPOM, 512KB RAM, an 8251 serial USART and an 8255 parallel port. Add the bare minimum of support logic to get a working system. Find the source code for a debug monitor, and get that to run within the EPROM. Most of this could be built on prototyping board and then disassembled when you are ready to move on. You will learn an awful lot doing this - and it may put you off as a result.

>>> I apologize if I seem aggressive, mean or rude in this reply. I didn't mean to come off as such!

No problem. I just want to save you a big headache down the line!

The other slight 'niggle' I have is that the 80186 (and 80188) are really designed (IMHO) for embedded controllers (although our ETHERNET cards use them as the intelligent processing element in conjunction with the 82586 ethernet coprocessor). Don't forget that the internal peripherals within the 8018x are limited and you may have to expand them externally if you are planning a large system. This may outweigh the use of the 8018x in the first place.

Again, just my view... Happy to help out in your venture...

Dave
 
You need to be aware that each MULTIBUS bus master requires a similar bus interface logic to the CPU for accessing the MULTIBUS. You can use either serial bus arbitration (there are timing constraints with this) or parallel bus arbitration (requiring a centralised arbiter comprising of an 8:3 priority encoder and a 3:8 priority decoder wired back-to-back). Each bus master will also require address, data and control bus buffers. The overhead of using this for something as simple (IMHO) as a video and keyboard controller doesn't seem logical to me. But then I don't know what your ultimate goals are.

Yeah. I think for anyone to really make informed comment on this design we need a lot more information about *why* there "needs" to be such a complex and heavyweight bus arbitration system; it's not "normal" for video processors and keyboard controllers to need to be busmastering peers of the CPU, and even if you *do* need, say, video, to be a "busmaster" (like, say, if your video system is directly accessing a bank of RAM shared with the CPU for video refresh or direct copy/transfer operations) there are lighter ways to handle it. (The 186/188 has HOLD and READY mechanisms to allow an external device to request the bus or to handle if an I/O or memory request has unpredictable latency, so... again, why it Multibus a requirement here?)

The other slight 'niggle' I have is that the 80186 (and 80188) are really designed (IMHO) for embedded controllers (although our ETHERNET cards use them as the intelligent processing element in conjunction with the 82586 ethernet coprocessor). Don't forget that the internal peripherals within the 8018x are limited and you may have to expand them externally if you are planning a large system. This may outweigh the use of the 8018x in the first place.

I think it's probably a "fine" choice if one is looking to recreate an early-80's vintage home computer, even if it included a lightweight GUI or whatever. (The "Mindset" computer is probably the perfect example of what you *could* do with it; that machine was in concept and execution pretty close to what you'd end up with if you took an Amiga and swapped an 80186 for the 68000. Maybe the Mindset is also an instructive example here because it did *not* utilize either the 8288 or 8289 but it was brimming with coprocessors, including a pair of intel 8042s (one as a "supervisory" CPU and the other programmed as a sound generator) and a complex video processor.) Two DMA channels and four interrupts (if you're using it internal master mode instead of cascading 8259A's off it) isn't super generous, but it's 2 and 3 more respectively than a lot of home computers had.

But sure, if this design is really intended to be a "large" system (MultiBus systems are usually "telco rack" sized) and bristling with I/O using the 80186/188 makes very little sense. If you're going that big you might as well chuck a 286 or better CPU in there.
Having strict rules and guidelines on when each Bus-Master has access to the Data/Address Bus is something I need for this project. For the future of this project, I will have many, many bus masters and the Multi-Bus from what I understand is the best way to unify all of them together under a single System Bus while preventing bus contention and Bus Masters conflicting with each other.

Again, could you be more clear about this? How are the peripherals you've named so far "bus masters"? Are you intending for the keyboard controller to regularly grab control of an I/O-port-only bus segment and send things directly to the video controller? (Which would actually raise an obvious question about why, if you're using a Pi Pico, you don't just hang the keyboard directly off it; there are PS/2 and USB libraries already cooked for that. Or do a private bus on the RPI to a dedicated controller if you really don't want to internalize it? Then just use a common "terminal" interface forfor the Pi->186 connection?) This isn't usually how personal computers work, so helping us understand the overall architecture of this system might help us in trying to evaluate it.

so you're saying I should've used the other gate on the 74LS20 for an address decoder for the RAM??? why didn't I think of that-

In that other thread about your 186 computer I suggested AND-ing all the LCS/MCS lines together but you didn't like the fact that it limited you to a maximum of 768k using the internal decodes only. (IE, 256K from LCS and 128K from each MCS line.) And thus discussions moved to not using those lines and doing it externally. Which all no longer makes sense if you're using just one 512K chip in an 8 bit configuration.

I'll defiantly add a USART of some kind, That'll be on the Multi-Master Bus Interface!

Why? A USART isn't an intelligent busmaster, it's a simple slave peripheral that at most just wants an interrupt. How does it make any sense to treat it like this verses just slapping it on the local bus and assigning it to one of the '188's PCS lines for the decode? The whole point of the 186/188 is to allow building small computers with almost no additional glue.

So I need Resistors on the Output sides on the inverters? Got it!

Just to sanity check: where should those resistors go?
 
Why do you need a USRT, The 80188 has a serial in and out. If you used a 5V one from a USB converter, you can talk to is from a laptop or such. ( might need an inverter but don't recall).
Someplace, I may still have a Forth for the 80188/186, with serial implemented.
It has been some time so I'd need to go looking.
It will help a lot doing I/O fiddling and such.
Dwight
 
Why do you need a USRT, The 80188 has a serial in and out. If you used a 5V one from a USB converter, you can talk to is from a laptop or such
Are you sure you’re not thinking of the 8085? I’m looking at the datasheet and I don’t see serial lines. The application notes talk about using one of the built in timers as a baud rate generator for an external UART…
 
Back
Top