Project Nimbot (aka Dodo on steroids)

[Alarm Siren]

The moment I saw Peter Noyes' excellent Dodo Gaming System, I was inspired. Using his system as a template, I wanted to see how far I could take the hardware whilst still maintaining the "retro" feel (FPGAs are cheating! )

To that end, I unveil the circuit schematic for The Nimbot:
(The forum won't let me upload SVG files so I'm linking to my GitHub instead)
Nimbot Schematic, Colour
Nimbot Schematic, Monochrome (for BDD )

Key Features / Differences:

• Using surface mount parts and rear-mounted components to increase miniaturisation, eliminating the need for a second PCB
• Two RS-232 UARTs - one DCE debug/programming port at proper RS-232 levels, one DTE link port at TTL levels for connecting to a second Nimbot for multiplayer play or to an accessory gadget.
• Increased base clock to 1.8432MHz, almost doubling the base speed of the system. System clock and UART clock are now derived from eachother, eliminating one oscillator entirely.
• Two SPI Cartridge Slots, electrically compatible with the Dodo cartridges. Left/Primary cart will contain game, Right/Secondary cart could be an accessory, helper ROM or allow players to make copies of save games between carts. Carts will be 32KiB, divided into four 8KiB sections of which the programmer can have any two in RAM at one time.
• Eight input buttons instead of six, and all buttons contain integrated LEDs under programmer control (Simon-Says or rhythm games, anyone?). Software debounce eliminates many passive debouncing components.
• 3-voice Square Wave sound system with headphone support
• 32KiB RAM, 31.75KiB ROM (Dodo is the other way around).
• ISO-8859-15 based font providing native support for 31 languages

You'll probably notice that many of the answers to my recent questions have been incorporated into this design, for which I am extremely grateful to you all. As always all comments, suggestions and criticisms are welcome.

[GARTHWILSON]

Alarm Siren wrote:

The moment I saw Peter Noyes' excellent Dodo Gaming System, I was inspired. Using his system as a template, I wanted to see how far I could take the hardware whilst still maintaining the "retro" feel (FPGAs are cheating! )

To that end, I unveil the circuit schematic for The Nimbot:
(The forum won't let me upload SVG files so I'm linking to my GitHub instead)
Nimbot Schematic, Colour
Nimbot Schematic, Monochrome (for BDD )

What kind of software should I have to be able to see these? Wikipedia says, "All major modern web browsers—including Mozilla Firefox, Internet Explorer, Google Chrome, Opera, Safari, and Microsoft Edge—have SVG rendering support," but I'm using Firefox and all I see is this kind of thing:

Code: Select all

<?xml version="1.0" standalone="no"?>
 <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
 "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> 
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" 
    width="41.9989cm" height="29.7002cm" viewBox="0 0 165350 116930 ">
<title>SVG Picture created as Nimbot.svg date 2017/08/07 23:56:05 </title>
  <desc>Picture generated by Eeschema-SVG </desc>
<g style="fill:#000000; fill-opacity:1;stroke:#000000; stroke-opacity:1;
stroke-linecap:round; stroke-linejoin:round; "
 transform="translate(0 0) scale(1 1)">
</g>
<g style="fill:#000000; fill-opacity:0.0; 
stroke:#000000; stroke-width:-10; stroke-opacity:1; 
stroke-linecap:round; stroke-linejoin:round;">
</g>

etc.

Quote:

• Increased base clock to 1.8432MHz, almost doubling the base speed of the system. System clock and UART clock are now derived from eachother, eliminating one oscillator entirely.

You might be able to go twice or four times the speed, and scale the UART bit rate accordingly, like setting it for 2400bps to get 9600. Or, still using a single oscillator, you could still start with a higher speed for the processor and divide it down to 1.8432MHz or 3.6846MHz with flip-flops. A single 74ACT74 has two sections, so you go from 14.7456MHz to 3.6864MHz or from 7.3728MHz to 1.8432MHz. These are all standard frequencies available off the shelf in oscillator cans.

I have long been intrigued with the idea of putting parts on both sides to increase density. I have only done a small amount of that in my work, putting only a few parts on the back. Recently I thought I was going to get to do a board with both sides densely populated, but the boss decided against letting me, because he was afraid that if any re-work were ever needed, the SMT rework equipment in our main facility was not made for it. You can even do parts on both sides with thru-hole, by staggering the rows of IC pins. You can also put ICs under ICs on the same side; in fact, I have a 3U VME-bus board with a 68K processor in a 64-pin DIP with a half-dozen ICs underneath it, four being thru-hole and two being SMT. The 48-pin DIPs have 4-5 SMT ICs under each, all on the same side of the board.

[Alarm Siren]

GARTHWILSON wrote:

What kind of software should I have to be able to see these? Wikipedia says, "All major modern web browsers—including Mozilla Firefox, Internet Explorer, Google Chrome, Opera, Safari, and Microsoft Edge—have SVG rendering support," but I'm using Firefox and all I see is this kind of thing:[snip]

You're right, its not working in Firefox (I use it too). I also, on investigation, know why - Github isn't setting the Content-Type header properly... Most irritating.
Try these links instead:
Nimbot Schematic, Colour
Nimbot Schematic, Monochrome

GARTHWILSON wrote:

You might be able to go twice or four times the speed, and scale the UART bit rate accordingly, like setting it for 2400bps to get 9600. Or, still using a single oscillator, you could still start with a higher speed for the processor and divide it down to 1.8432MHz or 3.6846MHz with flip-flops. A single 74ACT74 has two sections, so you go from 14.7456MHz to 3.6864MHz or from 7.3728MHz to 1.8432MHz. These are all standard frequencies available off the shelf in oscillator cans.

I'm already scaling down from a 7.3728MHz can through a 74AHC74 (though you wouldn't know that, having been unable to open the schematic! ), to give me my 3.6846 for the UART and 1.8432 for PHI0. I have a strong feeling that bumping PHI0 up to 3.6864 would entail using wait states on at least some of the hardware, though I've not investigated it thoroughly.

Quote:

I have long been intrigued with the idea of putting parts on both sides to increase density. I have only done a small amount of that in my work, putting only a few parts on the back. Recently I thought I was going to get to do a board with both sides densely populated, but the boss decided against letting me, because he was afraid that if any re-work were ever needed, the SMT rework equipment in our main facility was not made for it. You can even do parts on both sides with thru-hole, by staggering the rows of IC pins. You can also put ICs under ICs on the same side; in fact, I have a 3U VME-bus board with a 68K processor in a 64-pin DIP with a half-dozen ICs underneath it, four being thru-hole and two being SMT. The 48-pin DIPs have 4-5 SMT ICs under each, all on the same side of the board.

Probably not going to go quite that overboard, but that's the general idea

[Alarm Siren]

Upon receiving the tactile buttons I'm using for the controls, I have discovered that despite being in the same series, they have wildly varying brightness for the same current depending on which colour of LED is in them; in particular the green ones are extremely dim, the red LED running at 1.5mA has the same brightness (subjectively, not measured) as the green one at 10.5mA.

For subjectively the same brightness, you need the following currents on each LED colour...
Yellow: 3mA
Red: 1.5mA
Green: 10.5mA
Blue: ? (on back order)

Most irritating.

I could (as my original intention) run them all at ~6.5mA, which for all eight is 52mA, well within the '595's upper current limit of 70mA, but then they'll look terribly mismatched. So instead I've got to assign them all current limiting resistors such that the total is <70mA (60 to be safe), but also gives them all roughly similar brightnesses.

---

I've also added an (optional) bass-boost circuit to the LM386 amplifier, modified a few resistor/capacitor values slightly to better reflect real-world availability, and I realised I forgot to put any pull-ups on to the RS-232 Link port's RX, CTS and DSR inputs - which of course would otherwise have been floating when not connected to another machine! d'oh!

[GARTHWILSON]

I think red has always been more efficient than the others, and I remember 20 years ago green was the least efficient. Different colors of LEDs will require different resistors because of different voltage drops too though. The voltage drop is roughly proportional to the inverse of the peak wavelength; so for a given series resistance, a red LED will get a lot more current than, say, a greed one, or especially a blue one.

[Alarm Siren]

Yes, I had calculated the resistors beforehand to give roughly the same current through each colour given the different forward voltages, but I had not anticipated different efficiencies. Luminous intensity is completely absent from the datasheet, infact.

[Alarm Siren]

Oh, and a big change that I missed! Exar has End-of-Life'd the XR88C192 UART part, so swapping out for the pin-compatible NXP SC26C92C1B. Only downside I can see is it uses 10mA instead of 1.5mA, and has a smaller FIFO.

[Alarm Siren]

And now that i've changed my order to the NXP part, Mouser tells me the Exar one will be back in stock in four days. Well that's just lovely.

So that got me thinking, what happens if in future I need to replace any parts due to supplier issues? The Exar and NXP parts, for example, may be pin compatible but they're not completely interchangable in software terms - the NXP part having an 8 byte FIFO and the Exar a 16 byte FIFO. I decided to use some of my unused GPIO to put in four jumpers switches, so by putting in a link I give the firmware four "feature flags" - obviously three are for future proofing for now, but one will be to indicate an NXP vs Exar UART, as I would still like to use the Exar part in any future, non-prototype Nimbots as they use a tenth the power.

---

Upon starting to do the PCB layout, it very quickly became apparent that even with mostly SMT parts and on both sides, there's no way I'm going to fit everything on a reasonable sized board for a handheld device. The parts alone would just about fit, but it'd leave no room routing. So it looks like I'll be taking a page from the Dodo and using two stacked boards...

[BigDumbDinosaur]

Alarm Siren wrote:

And now that i've changed my order to the NXP part, Mouser tells me the Exar one will be back in stock in four days. Well that's just lovely.

In the future, I suggest you use the NXP 28L92, which has 16-deep FIFOs.

[Alarm Siren]

Hmm. Its a good £3 more expensive than the 26C92, and uses 25mA where the 26C92 uses 10mA and the Exar part 1.5mA. The main attraction to the Exar was the tiny power draw, in a handheld device every milliamp counts! As best I can tell the Exar and the 28L92 are functionally identical, save for the Exar not having the Motorola bus interface mode (though Exar do offer a seperate chip with that interface - the XR68C192). Hence, supplier issues asside, the Exar seems the better choice.

Surprised, however, that the 28L92 didn't come up on Mouser in the UARTs section.... it was actually what I was looking for when I got the 26C92 instead.

[BigDumbDinosaur]

Alarm Siren wrote:

Surprised, however, that the 28L92 didn't come up on Mouser in the UARTs section.... it was actually what I was looking for when I got the 26C92 instead.

It's there.

[Alarm Siren]

I know it is, searching for it by name now I got it straight away. What I mean is when I didn't search by name but instead went into the UARTs category and filtered by desirably characteristics, I got the Exar and the 26C92 but not the 28L92 - hence my surprise.