Zikzak - crummiest 8bit console/computer ever .. but I'm making it!

[T.T.]

I'd go with just having the switch break Vcc. Usually the only time you have to break two power lines is when you are either dealing with AC, or just have multiple DC rails, but with all of those, the ground is usually left alone.

 

[skeezix]

yeah, going to do that I think.

RL work is continuing to kick my ass (what did I do to deserve this? , but hopefully over this week .. need some breathing room.

Working on the gpu mini pcb schem.. I'm hoping to get the schem together by end of week or weekend, then spend a few days routing it; need to verify some of the assumptions and choices (ie: which pins to use for what, like i2c etc).. essentially its going to be a little STM32 F2 and F4 board, with all pins on breakout headers and the decoupling caps, and exposing some busses etc. Should be handy. Once it looks solid, send it and the power pcb off to the board house to knock them out.

Thats pretty exciting (for me) .. my VGA code does the job, but with a working little standalone pcb, be nice to run some tests through it, and even set up a little game or demo driven by an atmel or something; it could be self contained entirely as well, with some code tweaks it should be able to run pretty insane itself.. (the harder part is talking to the outside world with timing intensive vga running.. any gpio hit seems to blurp on the screen, due to slowing up the mesh or something.)

Anyway.. knock out the gpu pcb next week, wait a week or so for turnaround, and hope I didn't screw up the schem; maybe in 2-3 weeks I'll be making some little graphics demo, while working on the cpu board and IO/RAM/base pcb.

Buddy gave me a VGA LCD monitor, so I can move my enormous heavy CRT out of the office; little LCD panel is maybe 2" thick.. awesome for the bench.

jeff

 

[hitbyambulance]

just saying i am going to finally get around to reading this whole thread from the beginning (again) as it's really interesting! keep it up.

 

[skeezix]

I bet 3/4 of it ids just rambling, as I waffled back and forth I only wish things moved faster, but I just dont' get the spare time I'd like. Can't believe I've been learning electronics and doing this hacking for a year now.. but most progress was in small spurts!

Still, the 'design' more or less has been 'set' for months, just finally getting a bit of time to progress again.. I'm hoping to send PCB order in late this week, or soon anyway, for the power supply pcb, and the gpu pcb, and then test those out.. then move onto the cpu pcb and base pcb ... and then if all good, merge into one big pcb and finally put a console together Exciting!

jeff

 

[skeezix]

OKay, in a rush, did a quick job of the GPU mini pcb's schematic; not routed it out yet. This is for standalone STM32 F2 or F4 board, that is meant to be used as a BoB or GPU board. ie: Good for standalone little STM32 board, could be useful.. but its really meant to drive VGA. You can leave off half the components and it'll still run fine.

See pic behind the fold.

I need to go through and verify all the connections are right (I'm rushing a few out of impatience though, might get some of the pin-multiplexing wrong.. but maybe right!) .. but it should generally work, and I'm okay popping $14 to get 10 of them to see

Features:

- power in header, marries out to the mini pcb power board (same pinout)

- power out header .. I figure, it may be you want to run some LEDs or something on this guy, from the many GPIOs; getting power on another jumper on separate pcb would be goofy and error prine.. so I provide the power pins also as outputs, a few times each, so you can daisy-chain power between a series of pcbs easily

- JTAG ISP header, for reflashing it at leisure
- Full BoB (break out board); all 64 pins are on headers .. so chip is tiny square surface mount, I'll surround it with a big square of header pins for attaching logic probes and o-scopes to .. make it much easier for little projects.. lots of GPIOs, and on .1" standard headers.. mmmm!

- on pcb reset button
- on pcb power-live LED
- 6-bit VGA out header (RGB in 2,2,2 colour space.) For v2 of the pcb I'll put in the 2 bit brightness lines but this will do for now

- console and flags header - has serial recive/send so can communicate to a PC via an FTDI chip (separate pcb.. I've got a pile of 'FTDI Basic' mini-pcbs dirt cheap from ebay, so I use them on everything . (serial <-> USB)

-     flags include vblank, so anyone talking to/from this pcb can tell if vblank is high or not

- full serial (USART) and i2c for communicating to the gpu

-     ideally we want full address/data/flags bus, but leave that for v2; if v1 goes well, maybe I'll cut over to a 100pin version of chip and get a pile more GPIOs, or something.. make it much easier to organize function; STM32F405 I'm plnning ot use, is 64pinm part, and not all _that_ many left unused.. when you need a 20-21 bit address bus, an 8-16bit data bus, and some flags.. you're down for say 30-36 pins just for the bus; youch!

-     - this is a USART too, so exposing a CK pin should the client and server want to sort out their differences
- all the decoupling caps are on pcb
- oscilator is on pcb

I figure anything else I'm missing can use the BoB headers to add some functionality. in a pinch, but any requests? anything that should be on pcb, and not left goofy on the BoB headers?

Spoiler

 

[panik]

Honest question; Is it possible to leave BOOT0 floating like this? I have a pull down resistor on mine, with a button to VDD.

My concern is that it may accidentally boot from system memory (the bootloader) if BOOT1/PB2 happens to be 0, and BOOT0 happens to be 1. I even have a pull down resistor on BOOT1, but I can imagine things working without it. I want to be able to easily switch between boot modes by pressing the "BOOT0 button" while pressing the resetbutton (= bootloader), or just pressing reset (= boot from Flash).

I've never booted it without this configuration, so I'm not saying it doesn't work. Just curious.

Considering you're flashing with JTAG, and BOOT0 has no other function (AFAIK), I figure a pull down resistor isn't in the way of anything and it makes sure it'll always boot from Flash.

More info in app note AN2606 "STM32 microcontroller system memory boot mode".

 

[Exophase]

I concur, STM32s have optional internal pull-up or pull-down for GPIOs, but I don't think that applies to BOOT0. All the documentation I can find recommends tying it to ground with a 10k pull-down.

 

[skeezix]

Yeah, fully agreed; its something I've been mulling over.. ie: some sort of dipswitch to configure BOOT0 or not, or just tie it down. In experimenting so far, its not been needed at all, but when going to print pcbs I wouldn't rely on that 'luck'; best to 10K tie it down, and I think anything else is unnecessary.

I also need to look into the flashing via serial; I'm planning on using usart1 and usart6 (the higher bandwidth ones) but still need to verify those will work with the timers and setup already planning to use for the vga generation.. but be nice if flashing via serial worked as well, to save people getting a programmer; or maybe worry about it later.

Of note is all the pins are exposed on the BoB headers, so I expect some things will just be done there, rather than build the kitchen sink into this prototype. I was getting lazy and skipping a reset button on the pcb for instance, easy enough to just do it via jtag or via a BoB jumper, but thats just silly; not hard to drop the reset on there, and I've got a baggie of 100 momentary pushbuttons anyway.. might as well use some.

Interestingly enough, in both F2 and F4 on perfboard and breadboard, it runs perfectly fine without any decoupling caps or pull up/downs .. just using external oscilator with caps to ground, and the JTAG ISP, and VGA tied to various pins, it runs fine. But I'm assuming once things get more stressed, or heated up, or conversing over more peripherals at the same time (USART for console, i2c or RAM bus for data, things will get hairy.)

I do need to look into some of these caps.. I've generally used the .1uF for decoupling, but I've seen a few in the DS suggesting to use two caps, for better impedence handling or something. Interesting.

This is still very much a WIP schematic.

Also of note, this is just for prototyping likely (though if people want some and I have spares, sure, could send 'em out); a final zikzak will be one bigger pcb.. not going to make nayone take a cpu + base + gpu + power board and cobble them together unless they really want to

..

Thanks very much for reading and for your input; awesome to know people are still hanging in!

jeff

edit: Added the pull-down for Boot0, instead of a switch; if anyone needs to fiddle with boot0 and boot1, they can use the BoB header easily enough, but I dont' anticipating fiddling with it much myself (and therefore I'll definately need to, .. ahh Murphy

edit: going to jiggle around; will add brightness 2 bit DAC now, instead of v2.. easy enough to do. (and RRGGBBXX with X for brightness, works really well; I did that on atmel if you recall, 8mo back); keeping RGBX all in one 8bit block, and PC0-7 is handy, easy to assign to. Moving PC6/7 console TX/RX to USART2 shoudl be fine.. I dont' use those pins for much now.. PA0-4, So yeah, might as well add the brightness DAC now, as its pretty easy.. and if lazy, you can just skip populating it without effecting video much. But with it, you get a full 8bit colour range, instead of 64 colours

 

[skeezix]

Aside: holy crap, Steam in-home streaming is impressive.

 

[skeezix]

If you can think of anything more I need to add onto this proto GPU pcb, let me know. Trying to keep it thin, but I could quite easily overlook something, since I'm a total noob.

Once I get the pcb routed out, I'll post the power and gpu pics for review.. I'll add drill holes and such in there for mounting.

jeff

(it is cool having my cartridge protoboard here .. once in awhile someone is hanging out having a beer and playing some arcade machine, and they spy the bench and theres always a w-t-f is that, when they see an Atari 2600 cart with a freshly made cart pcb sticking out, inserted into a bunch of wiring

 

[panik]

Maybe you'll want to double check the '2.2uF = 22pF' comment in the schematics. Typo? I have 2.2uF's on my F405 board on the VCAP pins. That is, I actually use an F103 on that board, but it also works for an F405. They're pin compatible if you replace these 2 caps for solder blobs (I just want to keep all my options open, maybe I'm going to need the extra power of the F405 in the future).

You'd have to put effort in to stopping 'flashing via serial' from working. I'm using a Raspberry Pi where the GPIO pins automatically reset the chip into bootloader mode and upload everything, with 'make flash'. This works reliably with a 64 pin F103 over USART1, because there's no USART2_RX on PD6 to worry about. AN2606:

If the USART1 is used to connect to the bootloader: the USART2_RX (PD6) pin has to be kept at a high or low level and must not be left floating during the detection phase.

And PD6 is only available on chips with a higher pin count. No worries.

On the F405 however, there are more options to connect to the bootloader (3xUSART, 1xCAN, 1xUSB), so the 4 pins related to the unused options also have to be kept in a high or low state during detection phase. This can turn into a headache if you don't want to rely on 'luck' like you did with BOOT0. For the tests I did with the F405 (over USART1 and USB) I didn't bother with the other pins and I was 'lucky' most (all?) of the time. Things often spectacularly failed of course, but that was always me being an idiot.

Anyway, it's hard to do it wrong on that front. You have all pins available on the BoB, so there's always a workaround.

Oh, and how is VBAT going to connect to VDD? With a wire or a jumper or something?

 

[skeezix]

DS lists vbat as optional and its something I've tested on F2.. Originally I tied to VDD 3.3 but I thought hey maybe I really do want a battery .. So decided to leave it for BoB.


I'll hit up ebay.. Be cool to find a big lot of linkable screw terminals with .1" spacing.. So could put header pins or screw terminals as options for some pins. I've got a shop nearby selling them for like 60c per 2pin screw terminals ... Yack :/


For the power pins that'd be the stuff though.

 

[skeezix]

OKay, I've updated the schematic just a little bit.

- added the BOOT0 pulldown

- moved console serial to PA instead of PC6/7

- added brightness to PC6/7 (so now PC 0-7 is 8bit colour palette, RRGGBBXX, with XX being brightness.)

If you've got a minute, give it a look over and see if you can spot any obvious problems. Hate to knock out a pcb and have to bodge it with jumpers and exacto cuts to work.. but hey, at least its only $15 for the batch

edit: if you are curious..

- if you try to use a single 2-bit brightness pair that feeds into the 3 colour lanes, they all feed back and mess up the image

- if you don't use the diodes, the image goes all bright and weird.. but not too bad. I disassembled that breadboard so I can't easily test it again, so putting the diodes in as good measure, but when I get the pcb back I'll try just jumping over or resistering and see how that works..

See after fold:

Spoiler

 

[panik]

Connecting VBAT to VDD is 'highly recommended'. I have no idea what 'highly recommended' means, and there's no mention of consequences if you don't (other than the RTC not running). Too vague -> probably fine I have a set of jumper pins to select power options. An extra set of VBAT/VDD pins doesn't take op too much space there in my case.

My rev. 2 board will probably have a 4.7uF cap on VDD pin 64 (I only have 0.1uF caps on each VDD pin at the moment. Works fine). You mention your board works without any decoupling caps. I'm sure it does. There's also some capacitance in the board itself probably.

Please double check ISP/JTAG connectors yourself (there's a 'TBD'), I haven't looked at it.

I don't think you're going to need an exacto knife with this one

 

[hns]

here is a link to the grand uncle of the Pyra Handheld:

http://www.goldelico.com/wiki.php?page=About%3AHistory%3AZ80

-- hns

 

[skeezix]

Connecting VBAT to VDD is 'highly recommended'. I have no idea what 'highly recommended' means, and there's no mention of consequences if you don't (other than the RTC not running). Too vague -> probably fine I have a set of jumper pins to select power options. An extra set of VBAT/VDD pins doesn't take op too much space there in my case.


My rev. 2 board will probably have a 4.7uF cap on VDD pin 64 (I only have 0.1uF caps on each VDD pin at the moment. Works fine). You mention your board works without any decoupling caps. I'm sure it does. There's also some capacitance in the board itself probably.


Please double check ISP/JTAG connectors yourself (there's a 'TBD'), I haven't looked at it.


I don't think you're going to need an exacto knife with this one

I shouldn't worry, since its i) cheap, and ii) my earlier designs were _much_ more complicated. All of this stuff is a 'redux', to try and do some good stuff with a fairly minimal chipcount, whiel still not 'cheating'. But I do worry anyway, that I'll cock up something stupid. Surely I will, given the fact I only look at this midnight-1am after finally getting kids to bed and wrapping up work and choes for the day; zombie mode isn't good for pcb design, but hey

I'll be checking the ISP connection and pin assignments later tonight hopefully, and run through some of the existing code and check the usart pins .. I find it a bit hard to tell off the top of the head, which things will work out sometimes, since so much is variable (set by code), but with a lot of dependencies. You have to go through in detail (which again, zombie brain). Still, this is a very simple circuit, so not so much to scrwe up. When I was drafting this in one big pcb, it was a lot more risk for screwups.


FWIW: Added a short-cut header to the power pcb.. say you're using a USB jack, you can just feed the +5v and GND in from this new header, and skip the 7805; or if you have a 8V+ jack, use that; or use a power supply and feed in on the header; lots of options, and you only need populate what is needed.


+ will add a 2pin header for VBAT; just drop a PC short-jumper on there to close it. Good plan. I was originalyl using a bank of dipswitches, but it seems overkill.

--> good idea

+why would you put a larger cap on VDD4? (and not all of them?) The .1uF is the recommended, but are you abusing the board hard so want to watch for power fluctuations more there?

Do you have a schematic, and a picture of your board? Just curious how they compare

Thanks for your tips!

jeff

edit: going to do a GND plane on both sides of the pcb, I think; a few extra vias to joing the two gnd planes as well.

 

[panik]

+why would you put a larger cap on VDD4? (and not all of them?) The .1uF is the recommended, but are you abusing the board hard so want to watch for power fluctuations more there?

It's another one of those recommendations from the app note. I don't know up front how the board's going to be powered and what's it going to be used for. I'm going for flexibility and don't want to take the blame for a dodgy powersupply and some dirty electromotors that mess things up. Better safe than sorry. There's room for it on the board, and I can always leave it off.

From AN2586:

The VDD pins must be connected to VDD with external decoupling capacitors (one 100 nF Ceramic capacitor for each VDD pin + one Tantalum or Ceramic capacitor (min. 4.7 μF typ. 10 μF).

The minimum is 4.7uF even. Thanks for making me look it up! I'm going to use 10uF. I think I've read somewhere else that it's supposed to go near pin 64.

Do you have a schematic, and a picture of your board? Just curious how they compare

Picture of the rev. 1 board, fitted on a Raspberry Pi:

Spoiler

Schematics of rev 2. All components are SMD now (except for the headers of course), and it has a more comfortable form factor (mini USB plug, buttons on the outside, LEDs more visible etcetera). X0,X1,Y0 and Y1 are female pin headers with GPIOs from F103 and Pi. CONN and PWR are dual row male pin headers to put jumpers on.

Spoiler

My current experiments with it involve running node.js/socket.io on the Raspberry Pi, serving an html5 file to connected clients, drawing realtime data from the F103 on a canvas. Pretty happy with how that's all going so far.

 

[skeezix]

Oooh, very nice

Most of my components are pure throughhole (diodes, resistors, caps, etc) so far .. and I'm not too worried about the cap sizes (easy to solder it whatever you like, since I'm not having it populated somewhere.) The deal with we recommend this cap + another is sort of itneresting.. I've been debating putting that on pcb and then just populating 0-2 of them as needed, but for now I've only got the one cap (marked .1uF but whatever.) I think I'll add the positions for the second cap on each, but likelt not bother.. the chip really did seem to perform solid (for my needs) without any external stuff, beyond the osc + its caps. I'm just doing serial/i2c/VGA though. Maybe using all the GPIOs, doing the full RAM bus, would drive too much amperage and need more caps...

I like your shield design; really tight little pcb there.

Hand soldered SMD components I trust.. you're not using a toaster oven to melt 'em on there?

I'm going to compare schematics later on.. thanks for that!

jeff

 

[panik]

Thanks!

Yes, it's all hand soldered. No oven. Initially used a heat gun for the F103, but drag-soldered it in the end. Caps and resitors are 0805. Just as easy to solder as throughhole. Still crazy big and scary and 'in the way' when laying them out in Eagle on zoom 500 though.

Rev 2 is a little bit bigger and fits the Raspberry Pi better. I want to use the 'standoff holes that aren't standoff holes' on the Raspberry Pi to make it all solid and sturdy with nylon standoffs, screws and bolts.

 

[skeezix]

What sort of realtime data are you collecting with the stm32?

I fiddled around with something on my robot car/tank/thing:

atmel based pcb doing the motor controlling, serving controlling, radio receiver, etc.

r-pi with usb webcam sitting on the servos, and a wifi usb dongle.

So you could use a RC remote to drive via the atmel pcb .. hook up the battery and immediately drive!

But if you wanted some fancy, you could also hook up the r-pi (and wait for 1min for it to boot and make the wifi connection and bring up the python webserver stuff), and use ssh or web based control to drive the car.. r-pi -> i2c -> atmel pcb -> motor controls/etc. So you could pan/tilt the webcam through the web app, with the atmel pcb doing the heavy lifting. Pretty neat.

The hard part was reading thw webcam on the car.. used a simple usb one, and the r-pi default linux drivers worked fine, but slow; that video2linux or whatever drivers. Anyway, so reading the webcam and streaming jpg back to connected client worked, but TCP made it nasty. Almost needed a pure-RF version.

But using an r-pi with another pcb for data collection is pretty neat.

I picked up a BBB (beaglebone black) at one point, since similar to pandora in a lot of ways, and much more powerful than r-pi (processing-wise), but never got around to fiddling with it much.

So many fun projects, so little time

jeff