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

[skeezix]

edit: Got a website up now:

http://www.zikzak.ca/

'first post' is waaaay out of date now; hit up the wiki site for somethign useful, but here is a photo of the finished(?) thing .. Dec 2014:

edit: I've not been updating the first post(s) so you'll want to trail along at the end of the thread; don't worry if you skip the first 90% of the pages, its okay.. Iv'e shifted through a half dozen or more revisions/designs over time, trying varying levels of complexity and features out, but the end of thread is where things are happening

Schematic as of mid-November (still in flux as we figure out how retro, what things to include etc):

Spoiler

--

A few folks have shown interest in this crazy project of mine so I thought I'd open a thread about it; if people keep showing an interest (!?!) then I'll add a few bits here or there as they come! Comments, questions, thoughts are welcome.. but no negative criticism or flames here. Its a personal project, for fun, and to learn, and I know I'm doing it the most boneheaded way possible. (But hey, I get to use an oscilliscope, which makes me smile!)

So, yeah, screw it -- I'm going to make an early '80s style 8bit computer and game console, from scratch, using more or less the same kinds of parts as available back then. I've done SoC modern chips, where one chip is the whole computer; I've fiddled with FPGAs and so on.. thats all great, and thats how you work now, but its _cheating_. No, I want to put something together with cheap parts. The whole computer has to cost maybe $20 in parts, and be able to run a game like Pacman or Zelda and I'd like to reach even further. Lets see where I can go! I'm sure this is all first day EE class stuff, but I'm a software guy. I'm quite a good software guy.  I've even done low level hardware and embedded software and worked on kernel drivers for obscure machines no one has heard of. Great. But hardware, thats something I'm blind at.

And hey, if I do my job right, my kids are going to want to build a robot. My dad is an airplane nerd, builds model aircraft. If I play my cards well, I'll see if I can make a quadropter drone with my old man, and with my kids.. or at least a lilne following little car... But first things first.. this little computer is not going to make itself!

I've been wanting to do this for years.. like, 10+ years ... and finally gotten around to doing it. Somehow, when I get the smallest amounts of free time, I get the biggest urge to get things done and to take on new projects.. andreally kill myself. Character flaw.. but if you're going ot be up all night and sleep deprived to hell with babies.. your brain is _on_, like it or not; its a messe dup brain, but its still alive. First kid got BattleJewels done. These guys, compo4all and now Zikzak, as well as unreleased RPG game engine   Such is my way! Anyway I've always been a fan of general electronics .. my father is a machinist and general do-it-yourselfer so I've picked up a few things, but not much (sadly.); I'm one of those 'mostly useless' people .. software is great, but it doesn't fix the dishwasher or build a chair, you know? But I'll try anything.... make up for lack of skill with spirit and sweat! Anyway, in school I picked up some house-wiring classes (back when highschools _did_ that sort of thing.. a real shame they've mostly given up on shop classes ;/), and I've always had some interest in electronics... (building shit, and blowing shit up, good times..) but with so many other interests higher on the pole this hobby never got much attention. Still, years later I was one of the earliest emu authors and used to work over arcade machine schematics trying to figure out how they ticked .. I was working on Space Invaders emu, Phoenix emu, Galaxian emu, stuff like that, before most people (long before MAME ever existed) so that helped clue me into some basic digital electronics (figuring out how the banking worked, how multiple RAMs were hooked up, that sort of thing.) I used to do repair work on old PCBs as well, as I'm an avid arcade machine collector.. most of the old classics (Pacman etc) would come in rough shape, so you'd have to restore the cabinet a bit, and often tune up the pcb.. fix the audio, or some screwy graphics in one part of the screen.. lines on the display.. replacing caps in the monitor, etc. So I picked up a few things. But only general knowledge, nothing you could say was actually concrete. I couldn't design a circuit if my life depended upon it, but I knew enough to poke an audio probe into a cpu to see if it would squeel (so you knew power was getting to the cpu, say, or if it was crashed or working..)  Being a software guy makes you ruthlessly logical, so debugging is a strength, and the same skills apply to electronics debugging (or automotive debugging, housewiring, etc.) Honestly, a lot of the same principles apply everywhere.. I've always thought it interesting how my father thinks through a project.. his machine and tooling perspective is much the same as a software guys, at some level. Anyway.

If theres one thing I want my kids to pick up from me is .. _never stop learning_. Sure, read comics, watch tv and movies, get tatooed up like your ol' man, but never ever stop absorbing information, and trying shit out.

Goal: The ZikZak

Features planned so far (this is a design in progress.. feel free to suggest things. Who knows, if people like this (christ only knows why , I may even build a dozen of them to sell )

- 120 wide by 240 height on colour VGA (currently getting about 40x240 fairly stable, but as I refine the GPU components (heavy in progress) I should be able to get to 120x, or possibly even 200x240 sort of resolution. (VGA baseline which is 480lines, so going to 240 with line-doubling is pretty easy. Its the X where you get some play, but with conventional 8bit chips its hard to drive a VGA without getting more clever than I can handle _right now_)

- cartridge slot (YEEEESSSSS!) .. I could do SD pretty easily, and may do, but I really want to go old school here

- 4bit or 8bit audio (I'm not big on audio development, so its not a high priority of mine. Still, need to have some Atari 2600 level of audio ability, right?)

- 16K of fast RAM in current design (cheating a little)

- multiple banks of 'slow ram' (traditional RAM, external to CPU. Old school!) <- currently aiming for  hardware double buffered framebuffer, so dual 64k buffers

--> some of this ram may be reserved for sprite-lists andbasic effects (lighten/darken), but that may be a bit down the road. VGA is very demanding spec, so keeping my chips busy already!

- at least one joystick port, maybe two (or maybe expandable via cartridge slot) <- Atari 9-pin style. Your old amiga, atari, commodore sticks work fine

- not sure yet: small 2-text-line LCD panel for debugging or basic messages

- currently, 9V battery driven; maybe I should make it take 120VAC mains, or a wall wort; we'll see. Very low power, a 9V battery will last for aggggges.

- 128k flash for storing firmware (possible bootloader or a game or menu or something; for now, I just flash code right into the chips on the board, saves me dicking around with eproms in and out of sockets every few seconds.)

- 8bit cpu (currrently an avr 8bit, but could be swapped in with a 6502 or 6809 or z80..)

- 8bit gpu (currrntly an avr 8bit, but could cut over to a ubicom sx28 for speed, or even some faster chip entirely.. but hoping for now to stick with avr's since I'm a fan, and awfully convenient to keep to fewest number of chip families.. limited time here, lets not fight 3 different flavours of assembly at a time shall we?

Originally I went for a 6502 (or varient thereof) as target, since I love the old Commodore line (like Vic-20 and C64); but 6809 was such a great chip, and even the ol' Z80 has a special place in my heart. Or a 68000...... well, I schematiced out some of these guys in basic designs, and start fiddling on breadboard with a 6502 system.. and its very doable, but day-zero it was a lot to bite off. With these old guys you have to at least have a SRAM for RAM, and a flash or eeprom for ROM, and do a reasonable amount of software to get going; sorting out all those wires and supporting logic was a bit much, so I backed away from that (I'll be back soon!); ende dup fiddling with a Ubicom SX28 that I had lieing around (a few of, in fact, since I expected to burn/brick some .. its a very fast chip, so hobbyists use it quite a bit. (Chip can run 1-80MHz or so stably), though its not quite 1 cycle per instruction, and has no built in peripherals etc. Still, at that high speed, you can fake a lot of peripherals support.. interupts that can drive VGA and serial and so on direct, nice! But turns out a breadboard can't do high MHz without getting into all sorts of business I didn't know about then and do now. (The tie-points of a breadboard act a lot like capacitors when high speed is going on, causing all sorts of mischief, etc.)  So having to go right to sockets and perfboards and so on, for the GPU, seemed like it was getting to be a bit much (I waqs making a lot of mistakes, and having to take hours to fiddle around with the soldering station was slowing me down; I have _very little_ free time, so wanted to spend it wisely.. I can change as I go, but want to have solid momentum, not bog myself down.)

So I have fallen back to old reliable Atmel avr 8bit chips; they're cheating a bit, since they they generally come with some build in RAM and flash space, so you can bring them up on a minimum of wiring; they're also 'slow' (usually 8/16/20mhz, no more); the built in RAM is very limited (usually a few K only), though the flash is fairly generous (a few K, to 128K on the bigger ones.) Available in various packages from DIP (big pins you can stick into a breadboard) to TQFA (quad flatpack, the surface mount style chips you think of, with tiny little fairline thin wires.) I was afraid to get into surface mount chips early on, but turns out they're actually _easier_ to solder to a designed board than DIP .. with some easy but unexpected techniques (look up 'drag soldering'); you can solder a 100pin SMT part in like 2 minutes, and it freaking works! -- but only if you've got a nicely etched board; when you're designing from scratch, usually best to stick with DIP or through-hole parts... or little adapter boards that have SMT packaging on one side, and DIP on the other, so you can use modern SMT parts on a prototype.

Anyway, I figure the atmels are great supported chips, that still feel very retro (8bit and all); its great to have thriving communities around these guys, but not be 'cheating' much. (Note the Arduino uses an Atmel avr chip, and that is a huge community; but the Arduino people are only half into hardware tinkering.. its more of a way to get 'up and going fast', so its all about cheating; you get ready to use 'shield' pcboards to stick onto your arduino, and ready to use library code, and so on; its all about glueing stuff together to get things done. So its great fun, and very encouraging to newbies, but its not where I'm going. I want to go from scratch and learn the details. Turns out there snot much to an arduino, I can build one from scratch myself, so I don't much see the point in arduino myself, but I totally get who its for.. and its a great project. Check it out.)

I also still have some schematics for my 6502 design, 6809 design and so forth; I'll dig them out for you one of these days.

AAAAANYWAY, all that said (sorry, up late as always, and had a few drinks after doing fireworks with the oldest kid, so I'm rambling..) -- what have I got _so far_? and pictures, thought process, etc?

I'll get to that next update. Just wanted to get this out, see if anyone likes how and what I'm writing about.

I will leave you with these pics for lulz; these are mostly the GPU-side of things in test form; the main cpu isn't in these test pics; the cpu and gpu are both microcontrollers, but they have separate responsibilities; the cpu is where game logic runs, and it controls the double buffering, reads joysticks etc; I may add a third chip, an I/O specialist chip, but for now aiming for a two microcontroller arrangement, plus all the ram and buffers and shifters and other supporting ICs.

LCD:

Spoiler

http://www.skeleton.org/zikzak/zikzak_lcd_test_001.JPG

NTSC test:

http://www.skeleton.org/zikzak/zikzak1-ntsc-mono-line-001.jpg

VGA tests:

Spoiler

Very minimal GPU test, to see if this 8bit avr could drive VGA fast enough for monitor to deal with it:

http://www.skeleton.org/zikzak/zikzak2-vga-002-colour1.jpg

Doing a 1x240 (yes, 1 giant full width pixel, by 240 lines) colour test:

https://fbcdn-sphotos-c-a.akamaihd.net/hphotos-ak-ash3/6762_574814512550859_306771953_n.jpg

SRAM test; this is driving VGA while also talking to external (out of chip) RAM:

Spoiler

https://fbcdn-sphotos-a-a.akamaihd.net/hphotos-ak-prn1/943045_576770859021891_45500924_n.jpg

Links to later posts with topics..

- software (CADs): http://boards.openpandora.org/index.php/topic/13166-zikzak-crummiest-8bit-consolecomputer-ever-but-im-making-it/#entry248588

- tools (anti-state mat, solder iron or station, pliers, etc etc)

- parts and ordering (speed, timings, quality, family..)

- common ICs you should stock up on

- the power supply

- the overall plan

- peripherals

- revisions planned

- the programming and debugger interface

- the cpu

- the cpu

- the hardware double buffering and switching

- joystick inputs

- cartridge slot

- audio outputs

- oscilliscopes are awesome

- boardhouse to spit out a pcb

 

[skeezix]

And before anyone gets into it -- yes, I know theres a pile of chips with VGA-out, or HDMI-out, and all sorts of built in codecs and so forth; thats cheating, I don't want to do that. Theres a groovy Parallel chip with somethign like 8 cores in it, but still fairly old schoo.. thats grea,t but it has video-out support... no way I'm 'bit banging' all my own stuff.

Hell, I'm using 40pin chips so far, which means I only have limited set of pins to work with; just doing a 16bit address line set, 8bit datalines, and a few control lines.. all needed to control a RAM chip/bus, exausts the entire pin count of a chip; so I'm forced to either go for a higher pin count avr (like the 64pin or 100pin versions), but that means moving to SMT parts (fine, for these really), and slower (16MHz instead of 20 .. though 20 is pushign it on a breadboard already.. and I really like working on breadboards ; these high pin count chips do have an 'XMEM' interface for having the chip use an external SRAM as local RAM, but theres a number of issues with that (small ram, holes in the address space, etc), but again.. its cheating. The 6502 didn't have a 100pin edition back in the day..

.. so instead, I've been doing tricks like using the same pins for low-address lines as data-lines (save 8 pins, lose a few cycles when accessing RAM) and shift registers (being able to push some pins into it, one at a time, but 'latch' them so it remembers which are set, and can present them when asked to. So you can use 1 pin, plus a 'clock' pin, to shift data bit by bit into the register, and then have it present; doing that, you can use say 2 pins to get you 8 effective address line pins, but at 'enormous' cycle cost; so if you're willing to trade performance for more pins, you can.

You will notice I'm doing reoslutions less than 256x256 ... both because its practical given the speed of chips I'm working with and the current build constraints, but it also means you can use a single 8bit value to store each resolution compoennt; ie: something can be at 200x100 pixel, and thats 2 bytes to refer to; nice!

So I can do soemething like 17bit address-space (128K), and at the beginning of each video line, use some spare time in the horizontal sync time, to 'shift in' the high address lines, and then on the low 8 address lines, show them on the pins, have a buffer chip copy them and then present them to the address 'bus' to the SRAM, and then use the same pins to ge the value back from the SRAM; in this way, you end up with (say) 2pin for high address, 8pin for low address, and same 8 pins for data; what was 24pin suddenly becomes 10pin, for example.

You can do a lot of nifty tricks in hardware, but then you're stuck living with them

 

[sswam]

currently getting about 40x240 fairly stable

hehe nice one, none of those fancy square pixels for the Zikzak!


has a nice range of colours there I see


if I pre-order, can you have it ready in 2 months?

I just saw some info about Uzebox on wikipedia, that looks like a nice system, maybe similar to Zikzak is some ways...

are you getting some inspiration from Uzebox?

 

[mindlord]

I can tell you right now that if you go for the 6809 you won't be sorry. It's a workhorse. There's a rabid group of enthusiasts who love programming for the thing wherever they can find it.

 

[moxie]

You're mad. In the most excellent of ways, of course

 

[levi]

8MHz is slow now?  Blimey, I'd have killed for an 8MHz CPU in 1985!

 

[WizardStan]

You're using a CPU? That's cheating! You need to get a couple million transistors and build the logic gates by hand.

 

[TrashyMG]

Awesome project!, I thought I was cool with my Raspberry Pi ADC project.. this is a whole new level of coolness.


Also that's one 16x2 LCD screen full of wisdom.

 

 

[Asiyura]

This kind of projects always get my attention, since I've wanted to make my own gaming hardware for a long time.

So I'll follow this topic with interest.

 

[levi]

Out of interest, what's up with the hsync on that 1x240 shot?  Left hand of the coloured rows of the bottom looks a bit messy, looking a bit like you're still faffing with setting the colour after hsync's started and entered the screen area.  Since it's VGA you're driving vsync and hsync manually, presumably?  Guess it's not a calibration issue then.

 

[skeezix]

Will write more later but .. At 20MHz each cpu cycle is 2pixels of time at 800x600 mode I was using (convenient timings.) you have to be cycle exact and doing -anything- on cpu has to be careful.. Keeping hsync perfect is hard :/ still trying to work out.. You can see the colour transition cycles throw off my sync will worry more about it later

 

[levi]

Ah, fair enough - I forget how long horizontal flyback takes, and I dunno how much overscan you've programmed in, but at two pixels per tick it's going to be easy to miss your mark and end up in visible space.

 

[ZXDunny]

Just out of interest, would a very simple video-circuit be out of the question? One whose sole job is to take values from RAM and bang them out to video... Kind of like a Speccy?

D.

 

[skeezix]

Theres two options I'm going for ..


Sram -> gpu -> video


This lets you do some light/dark or panning etc, but assumes your chip is faster than vga (ouch)


Gpu ticking -> sram -> video


This has gpu just driving ram with the ram data lines sent to cideo DAC .. Much leas cycles used (and therefore higher resolution) but you can do no effects; theres more to it of course but I'm switching gears to this approach for now.. Do my limited effects in pure hw logic


I'll post some basic schematics so-far and upcoming as i get time..

 

[skeezix]

Oh one idea I keep having is.. Working out a 320x240 lcd colour panel.. Zikzak mobile edition :0

 

[Binky]

Wouldn't the purist thing to do be to hack a CRT oscilloscope to get the "small" screen, and to drive it directly with analogue signals in monochrome?

None of this newfangled vidium car-fix harry  nonsense

 

[levi]

The latter option sounds more like what most old 8-bit computers did (or at least the ones with a screen buffer).  The video chip pulls data off the ram in real time.  You can do scrolling by starting the video chip (can't really classify these as GPUs) at a higher point in RAM than usual and let it wrap round when it hits the top of the actual video memory. I guess you're using a colour depth which uses at least a byte per pixel, which means you have to be busy in the v-sync period and at least start rewriting the pixels on the boundary at the top before the first line gets written.  On my old BBC micro you'd often be busy calculating and rewriting these bytes as the video RAM is being scanned, and only just keeping ahead of the old cathode ray - meaning you only had the vertical flyback interval to do all the rest of your game calculations.

I wonder if your fancy GPU could be coerced into pulling the bytes out of a buffer and blitting them to the approproate places in the video RAM as it goes.  That'd make writing games a lot easier.

 

[skeezix]

if I pre-order, can you have it ready in 2 months?

I just saw some info about Uzebox on wikipedia, that looks like a nice system, maybe similar to Zikzak is some ways...

are you getting some inspiration from Uzebox?

Two months? At the amount of time I get now, it'll be two months before I get the double buffered ram switching schematic going, let alone plugging it into a breadboard

I need to think out a few things.. how to proceed; ie: I'm using a 'large breadboard', which is really 3 'full size' breadboards stuck together with some 'power bus rails' around it; its a good size, but not likely enough for Zikzak in full.

- buy a bunch of breadboards of the same kind and stick them together on a sheet of wood or clipboard or something; like, buy 6 or 9 or 12 or something, make some big ass breadboard

- keep each main component separate, and once tested, build into a perfboard (ie: semi permanent); then only the current component being worked on is in BB and the rest are little boartds hanging off the side. -> really, is any component ever done 'enough' for perdboarding? Well, my little power supply yes, and ISP programming interface yes, but the rest is too much in flux..

- design it all in schematics and then go to a boardhouse to knock out a few boards, and see how it goes -> yeah right, I'm not that confident in my design ability to go right from CAD to pcb, like real EEs are

I can tell you right now that if you go for the 6809 you won't be sorry. It's a workhorse. There's a rabid group of enthusiasts who love programming for the thing wherever they can find it.

6809 are like Amiga people; frothing at the mouth, even though its been 30 years I went 6502 -> 68000 as my line, and the 6809 is sort of a precursor to the 68k there. Its a great chip, I wrote an emulator of the processor a billion years ago (mostly even worked, too!), but its not a passion of mine. Still, swapping between 6502, z80 and 6809 is not too hard. they're all more or less simialr at the schematic design level. Just different in the code level (and by extension, the hw design making the code easier or harder.)

8MHz is slow now?  Blimey, I'd have killed for an 8MHz CPU in 1985!

8MHz is plenty fast enough, depending what your'e doing and how much support; I'm aiming for a 'cpu' and 'gpu' (and maybe a 3rd as I/O master); so if the main chip is 4MHz, hell, that could be fast enough it all its doing is updating a sprite-list or pushing artwork from flash or SD or cart into an external RAM array. I've no idea how to add hardware blitting or the like at all (except by cheating.. drop a really fast chip in there, and have the cpu signal that chip to do the work; but thats how the Atari ST Blitter worked, so maybe its not cheating..), but really, the main cpu doesn't need otbe too fast; now, the gpu I'm building is an avr atmega644 with a 20MHz crystal on it, and thats chasing a VGA signal which is usually say 25MHz and up; so when you're already slower than the signal you need, when 1 cycle of cpu time is a few pixels of output, life is hard Generally they used some dedicated video hardware, and that is at this time way beyond me. (I've no idea where to even start, there; is okay, maybe I'll get there.. gotta start somewhere, so I start at the beginning

Now, I started by doing NTSC .. just 'assumed' it would be easy since the Atari 2600 and Vic-20 and so on did it; it was the de facto of the time (and PAL of course, which is similar.) Turns out NTSC is a flipping nightmare.

See here: http://www.skeleton.org/zikzak/zikzak1-ntsc-mono-line-001.jpg

After significant amounts of time (like _months_, as my very first attempt at this at all), I got a white line more or less straight (and as you see, not straight -- it was tricky to get timings right, since I was wrestlign with being clueless about hardware, clueless about DACs, clueless about the assembly coding on that chip, etc and so on. Lots of battles at once, but I got 'there'. (I'm not suing a DAC chip, I'm using an R2R ladder.. a bunch of resistors that essentially act as a DAC, very cool and simple and cheap.)

Anyway, I fiddled with various chips, and using high speed chips and low speed chips both can handle NTSC.. great! But not using NTSC hardware, you have to do some insane gymnastics to get _colour_. Black and white is eay in NTSC ("easy"), but adding colour is a nightmare.

At the time, that was Zikzak1, which was my first attempt and aiming more to be like an Atari 2600.. rendering the display in real time, no framebuffers or anything; coding it woudl be hell, and timing was a bitch, but its doable.

But really, the only NTSC display I have anymore is an old C64 monitor We all have VGA, DVI, HDMI now, and VGA adaptors to DVI and HDMI are not hard to come by. So then I thought screw it, lets figure out VGA and it turns out protocols like that are _much easier_ to work with; the only problem there (since there is always somethign to make your life hell) is the high speed demands needed.. use discrete hardware, or use a high speed chip. Now, I could drop some ARM chip in or the like, but again, thats cheating

I do have some Ubicom SX28's and the like though, which can run very fast, so I can do the avr8 cpu, a sx-28 gpu, and an attiny for I/O (say), or something, but I'm trying to keep with one family.. limit my battles.

Its funny.. given I'm putting artificial constraints (what is cheating? what is in/out?), I'm in an awkward place, but ultimately its all about being retro styled because I like that, and because it keeps it within reach; aiming too high is demoralizing. So I'm doing things in braindead ways that would no doubt make Mike Weston pee himself in shame, but you have to start somewhere. So doing things in a way I can do, probably the wrong way

This kind of projects always get my attention, since I've wanted to make my own gaming hardware for a long time.

So I'll follow this topic with interest.

Its not nearly as hard as I thought; steep curve up front, but even then.. I've not actually learned as much electroncs as I'd like, but I've learned a lot of tricks; my father calls these things 'cheats'... 'hmm, this pipe has ot go behind this cabinet, and the cabinet is flush against the wall; the Right Way is to open up the wall and reroute the pipe, but we have limited time and your mother would freak out; so lets just cut into the cabinet in such a way as the pipe fits, the cabinet fits, but you can't see anything; if we have to mvoe the cabinet later, we accidentally destroy it, and no one will know' So I have learnt.. you wrap caps around in parallel whenever tthere is power ("decoupling capacitors"), to smooth out the signal; since cpu power draw changes every cycle base deon what its doing, you just throw caps around and it keeps the voltage signal clean. okay. The breadboard environment puts a limit on how fast you can go or else 'noise' makes everythign funky; true story. Run slow.. can't use 40MHz chips here! .. Ohms Law, got it, need ot know voltage drops and so on. But really, once you get your power supply up (a 7905 say, with some caps around it to smooth the voltages again), then you just start throwing chips down. They pins have well define dhigh/low, and that makes it easy.. like Lego. Don't be afraid, you will only pop a few at firs,t and they're 50c each. Another trick, always buy lots of a chip; shipping is brutal in terms of wait time and cost, so when y buying 50c or $1 chips, buy lots of 5 or 10 of them, and buy th 30 chips you'll likely need over the next few years .. iut doens't add up to that much, and better to have them on tap then suddenly have to wait 3-6 weeks for a delivery from China...

Tools, I'll do a post about, but you dont' need all that many; its _nice_ to have an oscilliscope, but its purely optional; an ISP programmer (learn the lingo! is a device to program the chip while its in the board, so you dont' need to socket and plug/unplug every 5 seconds; seriosu time waste there. An ISP for avr8 is like $40, worth 10x those pennies. A debugger is another $40; for PICs, the programmer/debugger is a combined thing, for like $50. Get.

Lots of tricks/things ot know, that you can just nod and say 'got it'; TTL versus CMOS? Well I'm using general TTL chips.. old school, well known, cheap, often available in DIP (breadbaord friendly) formats. CMOS is lower voltage usually (like a digital "1" is 3V instead of TTLs 5V, say.) But for TTL and CMOS there are dozens of chip families; a chip might be a 12345 chip, but you can get a 123LS45 .. the LS means its a fast TTL, but acts in a certain way, works nicely with plain TTL chips; you can get a 12HC345, where the HC means its a CMOS chip .. veyr fast, like TTL though, but still CMOS; often worksd with TTL chips, but oftne _not_, so be careful; same pinouts of course But you can get HCT chipds, like 12HCT345 .. the '12345' part is the same for all chips, same pinout, for the function; but the embedded letters are the family. Anyway, HCT means its an HC chip, fast, modern, but specifically made to work with TTL voltages.

So head over to digikey, look up chips in the HCT, HC, LS numbering, compare pricing; work out if you want to run at 5V or 3V, and wha peripherals you want to talk to.. LCDs, etc; you want all your parts ot be at the same logic level (3V, 5V) etc, to keep sane; you can use logic level shifter chips or other strategies so part of circuit can be in one logic level and other parts in another, but I'm trying to..

Tip #1: Keep simple Minimize complexit, fight as few battles as you can at once.

Tip #2: You can and will iterate like mad. Make a circuit,.. a blinking light or whatever.. thats hello world; then add more components, and more, and plamning ahead so you've got components in your box, not waiting in the mail; in software you can iterate like mad, no real risks, and nothign holding you back; but in hw, its all against.. the simplest order mistake gets you the wrong package (not DIP, but an SMT part), or wrong voltage levels, or wrong operating paramaters (temperature skewing the chip, etc), or any number of thousands of things

*babiues crying, all thought process destroyed*

Tip #3: Antistat mat!

So, yeah.. do it, jump in, its awesome; its _rediculously_ fun; some money down the drain, but not too much

Ah, fair enough - I forget how long horizontal flyback takes, and I dunno how much overscan you've programmed in, but at two pixels per tick it's going to be easy to miss your mark and end up in visible space.

That particular pic is from code writtne in C; honestly these days, I'm a burnt out wreck, so I'm trying to avoid writing asm in 3 different families of ASM; the timing is hell though, so you almost have to for the gpu, but if you do your gpu right, and have a framebuffer going on, your actual game coding and peripherals are not timing sensitive anymore, and life is all gravy Still, for a quick gpu hack, I rewrote my vga code into straight C (really compact too, like 2-3 pages of code I bet), and it _works_ .. but not precise enough, so get some wavies and such as you see; I bet I coudl get 1x300 or 1x240 worling tight. But trying ot do anythign more than about 30-40xY is probably not plausible in C.. but we'll see, I'm trying to do as much in C as I can, with only supporting routines in ASM; at first I was doing all asm, but its too timine consuming for me. I'm not as good at it as I was years ago.

Wouldn't the purist thing to do be to hack a CRT oscilloscope to get the "small" screen, and to drive it directly with analogue signals in monochrome?

None of this newfangled vidium car-fix harry  nonsense

Sure, I can make capacitors out of sticks of gum too (yes, you can), but I don't want to do that

The latter option sounds more like what most old 8-bit computers did (or at least the ones with a screen buffer).  The video chip pulls data off the ram in real time.  You can do scrolling by starting the video chip (can't really classify these as GPUs) at a higher point in RAM than usual and let it wrap round when it hits the top of the actual video memory. I guess you're using a colour depth which uses at least a byte per pixel, which means you have to be busy in the v-sync period and at least start rewriting the pixels on the boundary at the top before the first line gets written.  On my old BBC micro you'd often be busy calculating and rewriting these bytes as the video RAM is being scanned, and only just keeping ahead of the old cathode ray - meaning you only had the vertical flyback interval to do all the rest of your game calculations.

I wonder if your fancy GPU could be coerced into pulling the bytes out of a buffer and blitting them to the approproate places in the video RAM as it goes.  That'd make writing games a lot easier.

"fancy gpu"? ITs about as unfancy as you can go.. I'm bitbanging everything, there is no cheating at all

 

[skeezix]

oh one thing I thought it worth saying..

Maybe only cool to my brand of nerd? But even a 20MHz chip is _fast_ when you think about whats going on there. Say you want ot see whats going on in your VGA signal, and you're talking in the _nanosecond_ range of time. Not milliseconds, not microseconds, nanoseconds! If you're using an oscilliscope, you need to make sure its bandwidth is enough so you can see whats going on. ie: If you want to actually see 20MHz activity on your chip and see the details on your o-scope (if you want an o-scope at all), you need one that can see 20MHz, which means its running at 100MHz or more (so it can get a few samples in, so you can see a curve forming.. otherwise you just don't see whats going on; you might see a flat line when there was in fact activity, if your o-scope isn't fast enough to see the blip, right?) Anyway, once you learn this factoid, you start to see hwo cheap-end scopes dont' cut it.. a scope is going to cost you $300 and up, if not thouands for real EE people. Anyway, you can get them affordably, if you can afford ot burn $250 on a gizmo like that!

Anyway, the cool bit is .. my o-scope is good at seeing 20MHz and below, so works nicely with where I'm going (see, I had to work that shit out, byu the right stuff!) -- and its _freaking awesome_ to see the binary going on.

Ultimately in your code, when you're sending out 'print character S on the display', you need to see an S go out; and that means its on serial or parallel.. there are pins going up/down voltage to signal this character, this byte of code, this every single thign going on. With the scope at the right bandwidth, you can _See the binary_. Its just so mindblowingly cool.

I mean, an o-scope is like a debugger for hardware (one of a few tools you can get for this function.) I used the big old analog scopes 20 years back here or there, so I knew what they were for; and if you've never used one, the description is simple -- an o-scope shows you the wave form or voltage levels coming out of something. Okay, no big deal right?

But knowing what it does, and _seeing_ what it does, is night and day; we all know a heart beats, but imagine if you're learning how to be a surgeon and you open up a dude and see the heart muscle beating .. mind blowing, right?

So, sure, I've used a scope; but this is my own hardware design, my own signalling, I'm writing the C and assembly code to make pins go up and down so that the RAM chip will store a value or spit a value back out; and the o-scope shows the pins action, the binary, my code, bit by bit coming out.

I dunno, blows _my_ mind anyway, seeing my code dribbled out bit by bit; we coders work in serial or graphical displays, or a debugger and see the registers going on, etc; so we can go as high to as low level as we want, no surprise; we do it every day. But going from the byte level or the register level to seeing the bits going down your bus to other chips, bit by bit, its still cool, after all these years, you know?

...

I've fiddled with a few other bits and bobs; I'm going to butcher a cheapo $30 R/C helicopter and/or car one of these days, put a microcontroller on there, make it do some shit; and I know how to drive a servo, or a stepper motor, or a temperature sensor, etc now; freaking easy as pie, really.

Seeing the lines go up and down and drive that stepper motor, on your scope, in real time, thats _awesome_.

Maybe its just me. I have issues, I know

--

edit: This is the part where you're thinking 'how will this man ever get laid', and then you realize I have 3 kids, and wonder 'w-t-f'

 

[Asiyura]

skeezix, on 21 May 2013 - 05:07 AM, said: So, yeah.. do it, jump in, its awesome; its _rediculously_ fun; some money down the drain, but not too much

I just talked about that to my girlfriend and she answered.

We don't have enough space for an electronic shed here.

(she might be afraid to have my old and large analog oscilloscope back from her parent's attic to our tiny living room )


On a more serious note, I've already got a bunch of micro-controllers (PIC and MSP430), resistors, leds, led drivers, breadboards, etc.


I'm not really afraid of burning chips (I've got most of them using the "sample button" on chips makers websites).

Spoiler

I designed a really simple circuit board that allows to use arcade controls on a SNES without butchering an original joypad (a guy told me that it works fine with snes but not with super famicom, they probably swapped some lines). To be honest, my work was veeery small, the schematics were found on the web and I found the component used in NES and SNES joypads (they used 8bit parallel to serial converters, simple and effective design imho). So I only had to choose the size of the board, place the components and route the lines&hellip;


My plan was to get it to talk to a micro-controller. At first, using the micro-controller to power leds corresponding to the button pressed. Then start making simple little games using leds, eventually little lcd screens. Slowly adding parts to get a nice little gaming platform&hellip;


But life got in the way

I think that my main problem is that I can deal with the logic using "ideal logic gates", but I'm a bit lost with the reality of electronic. A bit like a square signal is more squarish than square when you look at it with an oscilloscope :huh:


EDIT : I'm dusting my "electronic parts" box, looks like I forgot to bring my capacitors with me when I moved&hellip; (there were only a bunch of tantalum ones) But my MSP430 launchpad is still working perfectly.