Almost there....

I've spent a frustrating couple of nights trying to get my units forwarding the packets, but I've almost got it. Theres hardly any documents or pages about doing interrupt driven coms with pick so it's taken a lot longer than I'd hoped. I'm also sure that theres a compiler bug as some of the code I was trying didn't work when it should have.

However once I got that going, I was able to forward the current packet to the next unit and display it there. But when I tried to address both at once, it just didn't work. I can address the 1st one (where by it doesn't forward anything), or the second, where the data is sent via the 1st but not displayed on the 1st; however I can't sent something to the the 1st and then the 2nd in turn for some reason. It gets the 1st packet and then locks up....*sigh*

PIC programming.

You know, the more I do of this, the more I think I need a proper PIC debugger. Its a pain to debug code on a PIC, especially interrupt routines. I started to write the interrupt driven transmition routine last night, but I've been struggling with even getting it to start up properly. This is mainly because I couldn't even find out where it died! After an hour or so I was eventually able to get a clue as to which part I need to debug, and was able to use the LED's on my PIC programmer to figure out how far I'd gotten, but its far from ideal!

There has to be a better way.....

Its working!!! Scrolly delight!!

Yep! At long last (although to be fair, I dont work on it ALL the time!) I've figured out what was wrong. My theory about it overheating appears to be correct since I've attached a heatsink (pinched from an old ZX Spectrum!) and its now been running for around 10 minutes without a problem. The heat sink is hot, but not too hot to touch (perhaps a new modern one will work better), and now I can finally work on the slave to slave forwarding of the message packets!

The idea behind this is that the master will send a packet with a unit number attached (say 5), and each unit it goes to will check it, and if its not 0, decrement it and send it on. This means theres no unit "allocation" or built in ID, and they are all then addressable. The only thing Im not sure about is just how fast this will be when there are 64 units all chained together... whats that going to look like? I intend on pinching a game developement trick for this and doublebuffer the display so that every unit will get its packet, and then a "flip" will be sent to them all via a single line which they are all attached to. This should solve any ripple which might occur. The other thing which may work is to send them, last unit first. Since each forwards the last packet on, it would mean they would all get the packets almost at the same time.... I'll try this before I solder a "FLIP" commandline.

Regulation.

Well, appears I was right. My 5 Volt power regulator is failing. I dont think its a dud or anything, I just think its being overloaded. I wonder if I attach a heatsink if it would last longer. I dont know if its simply getting too hot, or if theres too much current going through it. So what makes a good heatsink anyway? Getting a bigger/better power regulator might solve it for now, but I need to have a better solution at somepoint.

I did consider making a stepdown via resistors, and then feeding that into the power regulator, but I suspect the resistors will just heat up. Anyone any ideas?

HiDef heaven....

I've been looking at the HD-DVD releases and Im pretty disappointed so far. Most are just old films that have stinking quality anyway, which are pointless to take onto HD-DVD. Sure you get some parts a little crisper, but the picture is still grainy and horrible. In fact, theres only a few films you should ever buy on HD-DVD and a couple of rules that I'm following when making a purchase.

1) Film must be bright. This might seem like an odd one but its the most important. If I buy a dark film (like a space sci-fi, or horror) I never see the extra pixels/quality as its so dark, its completely lost. This goes for all films, even those shot in HIDEF. I have Serenity on DVD and HD-DVD, and the ONLY bits you notice, are the 3 or 4 sections in bright sunlight. Every other scene could be from a DVD.

2) Dont buy old films. A DVD version is cheaper, and the quality is just as good - unless your an absolute NUT for pixels, you simply won't notice! Id say any film after 2000-2002 is a good candidate. Before that....its touch and go.

3) CG cartoons are GREAT in HiDef. Films like Shrek 2, ToyStory, Cars, Finding Nemo etc. Are all amazing looking in Hi-Def.

4) and lastly, until the price drops and you simply cant get DVD's any more.... only buy new films, don't rebuy a film just because its in HIDEF unless its a real showpiece. Its simply not worth it.

And before anyone says well Im not a film buff...I love films, but after watching a new HIDEF film on my new 50" plasma then having my wife say "I didn't see any difference", I have to agree a little at least. There are some GREAT showpieces (usually the HIDEF demos), but for the most part... DVD's (especially progressive scan) are just fine.


I had a brief play last night with my scrolly message after I'd charged up my battery and its still failing. Although now I think it might be to do with the power regulator. Its getting very hot and Im wondering if perhaps its overloading and failing. This would make sense to what Im seeing, and the fact that if I leave it alone for a while it works again for a little. I'll have to try and source a regulator with a higher thresh-hold for testing that out.

A growing problem....

I've built another module so that I can work on the communications between them. The idea being that the master PIC sends a packet along the serial wire and the 1st module picks it up, decrements the PIC number and if its not 0, sends it on. This allows me to add mode modules later, and keeps the whole thing really simple.

However, Im still having issues with it freezing up. But I'm getting more convinced that its the power supply - even though I have very little evidence to support it. The battery Im using is a 12V, 1.2Ah rechargable battery, and when I switch it on, it gives a very bright image. However, after a little while the whole thing starts to go funny. The Master PIC LED is still lit, but the scrolling stutters, stalls and then freezes on the LED Matrix. However the fact its still being displayed tells me that its running okay. I put in a power on sequence so I'd know if it had reset, and its not.

Now this tells me that either the power to the master PIC isn't holding (which should affect the rest of it), or the serial comms is losing sync somehow - but I cant think of any way to test that.

On a more positive note, I did fix the ghosting! I altered the order of PORTA and PORTB being set, and that seems to have cured it. I suspect the Transistors were not slow, but too quick, and showed the slight delay the PIC has when setting the data. Theres still a slighly glow, but because of the ways its now set, theres not much to see.

Scrolly fun...

Okay, so I decided to play with PNP's, and it looks like I can use the original 74LS138 (3 to 8 decoder) but without the invertor chip IF I use PNP's. Theres not much of a price change so I could swap back and forth depending on availability. However..... Transistors appear to have a decay rate which means I get "ghosting", and in the dark, its pretty bad. They dont switch off right away, but take a little time. either that, or they switch on a little too quickly (which I think is more likely) so you get a small echo before the column actually swaps.

I'll play with the code a little as it may be just a case that I need to pause a little before swapping data channels or something.

However, that problem aside, there does appear to be either a power, or serial issue, as the display is freezing. That is, it stops scrolling. Now since it still displays a solid image, I know the PIC is still runing (or I'd only get a single verticle line), which leads me to think its going out of sync with the serial, OR getting reset or something. its very odd whatever it is.....

Scrolly Message Progress!

I have at last figured a reasonable way forward with my scrolly message do-da. I decided to try out using 5 transistors rather than the 5 pull up resistors. These are a little more expensive, but not by much, so it should work out around the same cost as before, and allows me to keep the cheaper PIC. So next....I have to produce a new schematic using just the PIC, 4028 IC and 5 transistors. Once I've done that I can start to wire up the prototype. The only thing Im worried about is when I have a large version, theres probably going to be a lot of juice feeding it, and I might need some resitors in there to limit it a little. The LED matrix happily runs on 5V, but the number of amps needed to run the whole thing is a worry.

However, I'll cross that bridge when I get to it. For now, Im almost at the point where I can wire up the prototype, and start getting inter-PIC-slave comms going.

I've used some NPN's here, but I've been trying to find out the difference between NPN's and PNP's, and have just found out (I think.) NPN's are the way I normally thing of things, output a 1, and the switch is ON. While PNP's appear to be output 0, and the switch comes on. This might mean I could use some 74LS chips instead of 4028's, but I'll need to sww whats cheaper.....again.....

NEW TOYS!!!

How cool is this!! I finally managed to get hold of a SuperCPU from ebay! Man I just LOVE ebay! (I also spend WAAAAAY too much there - oh well). So, got the super CPU, plugged it in and tried a few programs, wow does it fly! I loaded up Driller which was always painful, and now it plays like an arcade game! very cool. I also loaded up Mercenary, and its an amazing piece of work. It actually smooths out which its switched on. Doesn't just run quick, but you appear to get smoother gameplay! Looks really really cool.

I then loaded up my download program and squirted down XeO3 (which downloaded in like 1.5 seconds!) and played with switching it on/off. wow... you'd have SOOO much time to waste with one of these. I'd be tempted to write a game which uses the bitmap but blits it on and then does stuff to it that you could never do with a C64 - like 3D baddies or something. I was looking at Metal Dust, and aside from a couple of the parallax effects, you could actually get that running on a stock C64 (pretty much). But 3D baddies...Now that would be cool.

The extra RAM would also be very handy for games. I have 16Mb here, but I hear the normal is 4Mb. Even that is a huge amount. You could pre-cache and pre-rotate everything - AND run a multiplexor. Which would allow you to have all the normal hardware sprites AND loads of software ones AND possibly some 3D effects. I think Metal Dust missed the mark a little - although I'd like to have a play with it, but I refuse to pay 30Euros for it, thats just way too much for something I'd never play.

....especially as I've just gotten a Wii!!! How cool is THAT! We're all hooked on wii sports, not to mention getting heaps of excersise into the bargan. I've also been playing Crackdown (which we did at Realtime Worlds - well, I say we...but I haven't been involved in it at all), and its fab as well. I love the building jumping stuff, great fun - as are the cars and trucks. Its a much better playground than GTA ever was.

I've just recieved a stack on transisters so Im going to try hooking up my LED displays with them rather than pull-up resistors. This should allow me to use the 40xx chip I got without anything else. I discovered that the larger pic I bought REQUIRES an external clock crystal, which would bump the price up even more. We did think about having an external clock pulse and feeding that in, but it still means even more expense. So I currently think I should just use the old way and try out the PNP's I have to see if that'll do the trick.

As Im off for a couple of days, I hope to try this out soon, then I can progress with the 5 unit prototype I was making....

XeO3: Comments

Its funny reading some of the comments about the video, many of them seem to wonder why I'm doing it - so I thought I'd answer.

When I started coding all those years ago I did it for fun, nothing to do with money or a career (although it was a distant hope), but plain old fun. Years later when I started coding profesionally, I was pretty good at at because I'd spent years getting good at optimising things and making things fun.

Now...fast forward to today. I spend all my profesional time working on high end PC's/Consoles doing the games that these people say we should be playing and something is missing. It's been brought up a couple of times on the DIGG list. Machines are so big and powerful, we just dont need to take the same care and attention that we once did. Microsoft Windows being a case in point; it swallows virtuall all power from the latest processors and we hardly ever feel the upgrade the way we used to. We've lost something.

So, aside from the huge amounts of fun I get from writing of limited systems, and remember that this doesn't JUST mean retro machines that we won't let die but things like mobile phones and whatever the latest limited system is - theres always going to be a new one. I learn lots of new things by working with these systems. If you work on systems that are hardly ever taxed, that are heavying with memory, and have huge resources, then its hard to learn optimisational tricks any more. Working with these smaller machines keeps our minds ticking, thinking and working so that we can use these tricks when we need them on real projects. These days, it doesn't take a programming god to make a game that looks okay, but still you have to be pretty good to push the machine; its just harder to know that you've reached that limit and its not that you've just turned into a lazy coder.

Necessity really is the mother of invention. If you dont really need it, you'll never discover it.