Change of direction.

So with Christmas comming up it's almost time for my anual direction change. I was hoping that my ATmega devkit would arrive in time, but its looking less likely as time goes on - pooh. Oh well. I've pretty much completed what I wanted to do with Minus4j, although I'd like an option to pick a file fom the ZIP to switch to or load, but until Plus4world allows real access to ZIP files, this isn't that important. I'll probably wrap up what I've got into another release and leave it there for now, although I've yet to look at the sid filters but that may also be defered until later.

As to what project I'll do at Christmas time, well I'm not sure. I'd love to get back into electronics a little, but theres also my debugger and getting it running on a C64 and emulator. I'm also starting to think I need to restart RetroEdit. When I started it I hadn't done much C#, and over the years I've learnt how to do things properly. This means I could make a real stab at a proper system but as i've seen with the debugger, this means some serious effort. That said, I'd love a very simple interface so that I could draw tiles/graphics for myself.

I also really need to get a basic MAP editor togther even if its a very simple interface so that we can make levels for Xeo3. The old one works but is a little crude in paces - it would be nice to fix that.

So I have a few things I'd like to play with, I guess time will tell if I actually GET to...

Vista x64 upload working!

I've managed to get the upload program working once more with the x64 driver, however I now need to press F8 whenever the machine is booting up so I can disable driver signing. Stupid stupid stupid vista! I wonder how much it costs to sign a driver. This is a VERY popular driver, so it may be possible for everyone to club together and pay for it.

There used to be a work around where you could just switch it off, but Microsoft in their infinite wisdom disabled it. Its thing like this which will drive folk to other operating systems. (Course... MAC doesn't HAVE a parallel port...)

I think one of the things on my to-do list should be a simple USB to parallel wire. Now I know there ARE some, but I'd love to have a proper one that acts EXACTLY like a parallel port and does all the crap for you. I imagine this would sell pretty well, particually if it could get signed properly. Oh well... another one to add to the list.

Still, for now its working and means I can now test Plus4 code again. The original uploader hasn't changed, but I now have a new DLL and SYS file that I use on VISTA.

So what else is new; well I've added basic SID support to Minus4j but its a bit pooh to say the least. The lack of filter support really sucks and since most music/fx uses them, they just dont sound right at all.Attila has kindly sent me the core of the SID emulator from YAPE and I'll see if I can wedge that in. It's very much like trying to put a square peg in a round whole though as YAPE and Minus4j are not only very different langauges, but have very different design philosophies. Still, its worth a go! With any luck I'll get it added and we can get some good sounds playing in demos.

Speaking of demos, I noticed that many appear to over run their rasters, and I think I've finally figured out why. I dont think Minus4j (or Minus4w) are letting them have a whole scanline. Basically the "newline" function is being called at the start/end of a scanline (HBLANK) but thats not where the timing is working from. The horizontal dot clock is being reset by the newline function and losing clock ticks. This means you dont get all your processing cycles, and would also be the cause of my inability to load tapes. Tape loading is in fact VERY easy (once you have a good sample), all you do is set a bit on/off as it plays, and at the right time. But if the CPU timing is out, it'll never work - explains a few things.

It may however be a nightmare to fix, so I'll have to look into it. It would be great to be able to load PRGs, D64s and TAPs into Minus4j, but I'll wait and see how everything else goes. I really really don't want to get sucked wasting all my time on emulators again...I have bigger fish to fry.

EDIT: Oh, and if anyone else does want to use the uploader on Vista64, then let me know and post a ZIP with the new drivers and installation instructions.

Cool Electronics things....

So first a couple of links:-


http://www.belogic.com/uzebox/index.htm
http://www.ladyada.net/make/fuzebox/


Now whats this got to do with anything? Well have a look at these videos




Very cool indeed, more so because its not a particually expensive chip. So I was wondering what more you could do with it, and I've been having a look at some videos, and the specs. Now I've always used PIC Microchips, but I've noticed an increasing number of projects using these ATmega things and after looking at the datasheets, I can see why. The assembler is actually pretty nice! It looks normal! PIC stuff is okay, but I'm not a fan where as the ATmega has 32 registers, hardware multiplys, and most instructions take a single cycle! Now that IS interesting! Now have a look at this video....





This guy does various demos with it, and he gets some pretty cool results for such a small little device. So, I've ordered myself a little kit to playwith, and I might try hooking it up to a VGA monitor (I'm still struggling with PAL colour output, this phase shift stuff is a tad confusing). The other thing this little chip can do that PIC's simply can't, is address external RAM without having to do all the work yourself! Thats awesome! It means you could have megs of addressable SRAM (in the same way a Plus/4 could) without any speed loss, where as a PIC would really struggle as you have to set address lines, read and write data lines et..

What I would really like to try is making a GPU for a plus4. If I use dual port RAM, I could get the plus4 to write into the ATmegas ram, then get it to use it as a frame buffer and render things. This means you could switch the plus4's screen off (saving lots of CPU time), and then output the signal from the cartridge's ATmega chip. You could then add sprites, sound and all the rest without too much effort. if you really wanted to, you could have multiple chips each doing a different job - one for 10 channel SID emulation (or something), another for pure sample playback, and perhaps one to deal with chatacter maps, and another could add sprites etc... kinda like an arcade machine does.

Course...that won't happen. but i'd love to try and hook one up to a Plus4 and see what it would be like. Having already done a RAM expansion without opening up the plus4, I don't see why something like this couldn't be done - it'd be neat!

Happy New Year!!!

I've given up on trying to get each LED unit passing on the packet from the previous one if its intended for a unit further up the stream. For some reason, it just isn't working, and I really just can't put my finger on it. I could build some special hardware with mini screens or something to pin it down, but I really dont want to do that; way too much effort.

So, I've gone the lazy route and assigned each unit an ID at compile time. This means each unit will have to have its own compiled version, a pain but not un-livable with. It also makes the code much MUCH easier....

Still, since the hardware design doesn't change, if I ever figure it out, I could change it later. The Master code doesn't change either, its just how the serial line is passed on It may be I have to boost the serial signal as it'll have to go quite a ways. This would mean it has to pass through some sort of AND or OR gate just as a booster, I'll wait and see.

If anyone out there has experiance with PIC's and want to look at the unworking source, let me know..... No idea why its not working - it was pretty elegant as well....

Anyhow, I've created a 3 unit board and Im busy drilling all 261 holes! (eak!) I'm about 1/2 way through, and I'll finish it off tomorrow and then solder it all up, that part shouldn't take long, although I do have to solder 24 jumper wires along with the actual components. I think once this is working, I'll replicate the design in another package, and then see about getting some real baords made!

On a little side note....Its almost a YEAR since I started this project - looks like another one thats gonna run and run. Where HAS this year gone!!!!

Led Scrolly

I've been playing with electronics stuff again. Just before stopping for the Christmas break, Russ was moaning that I still hadn't finished my big scrolly message board, so I thought I'd have a crack at making a real life board using some some printable solder mask I got a while back. It took me a while to get things right (and I had to go and buy a cheap disposable Iron for it too), and the nerve to break out the chemical solution for the copper board, but once all that was done, I mananed to get a reasonable 1st attempt at a board.

It's taken a little bit of time to get it all working, as I'd made a right hash of some of it, so I had to cut some tracks and solder in wires to bypass mistakes. However, its working now, so in theory, I could now think about sending off to get real boards made!

I still need to work on the master PIC side, along with the PC comms. The idea is I'd use a TCP/IP or UDP interface (perhaps even wireless) and allow simple bitmaps to be sent. The mastr pic would then send this to the correct module.

I do have the basics working just not the PC comms side. The image on the right is the finished (one sided) PCB, and as you can see it still has quite a few jumpre wires. I dont want to make double sided boards at home, way too hard. If I ever get my milling machine, then I might give that a go - in fact I simply expect that to work.

Still, its nice seeing the actual PCB in all its glory, and I may end up making a board that can hold 3 modules just to see what it looks like!

One thing I would say, is that with the software Im using just now, it really doesn't route very well, and I do end up putting a lot in by hand. It could just be because this is a cheap bit of software.... I dont know.

SD/MMC+Clockport Prototype

So here we go again....I've started the SD/MMC+Clockport interface. While it should be fairly simple, I've not connected a clockport before, and I need to decode the lines pretty much down to the byte this time; for both the clock port and the MMC interface. This means the board is pretty full so I won't be able to add the RAM to this test one,but if I was making a proper board, theres nothing saying I couldn't do it on that. While I couldn't see any real use for a RAM only interface, this one I can (with or without the extra RAM). Having an MMC card slot and a clockport on a card would be pretty cool, and allow all manner of C64 apps to be ported, along with allowing the +4 onto the Net - or simply better comms to the PC. But best of all really is that anything that someone makes for the C64's Clockport, would be usable on the Plus4 (with a little relocation - something +4 guys are pretty good at!).

Of course, if I added some RAM (128k,256k or 512k extra) it would mean that any clockport applications (like a TCP/IP stack or game) could make use of it, since you'd know everyone else running it would have the extra RAM as well. The only thing that worries me is the physical size of the interface. The C64 one is full of surface mount stuff - professionally done, but I guess this wouldn't be....

Oh well... first things first - lets get a working prototype and then worry about the rest of it!


Edit: Oh! And the little voltage regulator at the top, was just to see if I could solder one on without making a complete hash of it!

Getting orginised.

Yup, not been doing much.... A load of chips/parts have arrived so I've spent a couple of days sorting out my parts bin into some sort of order. I got fed up with not having the chips I needed/wanted, so I'm slowly trying to buy a few of everything (common chips at least), buit this means making some space for things.

I've also managed to source some pin headers for the clockport stuff, so Im going to start wiring up a SD/MMC+Clockport interface for the Plus4 next then I can start to have some REAL fun!!

I still need to finish doing the basic directory on the MMC, but that shouldn't be a big issue, and then loading a file should simply be a matter of getting the inital cluster from the directory entry, and reading it in.

I'm kinda looking forward to playing with the clockport the most, as it could mean some cool off the shelf toys for folk. The ethernet contoller looks the most fun, and I have the UDP slave source here to try out. Could be good!!!

I'm off to SigGraph in SanDiago next friday (3rd Aug), so I'll be back on XeO3 at that point, and I hope to get some stuff done on the plane again; but as usual it depends on how close the bloody seats in front are!

MMC Success!!

And here you go!! The ROOT directory in all its glory! I'm not parsing past the end of the 1st sector, but thats okay for now. I can now plug in any card (I have 3; 32Mb, 256Mb, 2GB - all FAT16) and I can display the ROOT directory of each of them. I guess the next thing to do is load a file from it..... or I could finish displaying the root directory, and sub directorys of course. But loading a file is pretty exciting stuff :)

I dont really want to get too far into it, as the main goal is to do a Plus4 version, not a C64 one. Although the code will be identical so its not wasted work.

Another big thanks to TNT for helping be get started with this....

Memory Mapped LED - Phase 2!

If you remember a while back when I was doing my Plus4 LCD screen, I spent a lot of time simply mapping a BYTE into the Plus4 memory space(Blog HERE). Well, I finally found something that will assemble source files for my GAL's, so I decided to play with trying to get my RAM expansion idea working. The first thing I had to do yet again, was map a byte into memory, but this time it was FAR easier!

You can see from the pictures that theres a LOT less, and even less soldering! Fantastic! This is the one bit that really puts me off doing any hardware stuff, I really dont like soldering that much. Well, with these GAL's, a whole array of chips have collapsed into 1! Not only that, but theres a lot more pins available, so I can add even more functions, and reprogram it as need be! Brilliant!

I did know what they were able to do before, but I was unable to make them until today when I found a program called fgal.exe, which is basically a GAL assembler. Now I can simply assemble this line...

     WR = A15* A14* A13* A12* A11* A10* A9* /A8* PH2* /RW

.... and I've done all the work of those 4 other chips! Great stuff. Now I can actually try out the external 256k RAM pack idea I had, where I dont modify anything internally... could be neat if it works!

One thing that would be very cool, is a pass through connecter, but from what i hear, you dont get these edge connectors any more... pitty.

I'm thinking of saving up for a milling machine so I can cut/make my own PCB's easily, this would mean that once I design it, I can (more or less) press a button and get a prototype board out! These are pretty expensive, but I think it'll be great fun so I hope to have one by the Christmas holidays...I hope.

Plodding on....

I'm still slowly progressing with wiring up the prototype, and I thought I was getting on well until I decided to finish one of them off - just to see how much more I had to do, and it turns out; LOADS! Oh well.... Onwards and upwards and all that.

I've been coding up a demo for Luca's new competition, and Im struggling a bit to fit it in. The original size was supposed to be 64 bytes(!) so I started working on that only to find out they had increased it to 128! DOH! Oh well.... Its nothing special, but I do prefer these smaller demos to the larger ones as you dont have to do very much, and it doesnt have to look too pretty.

I've also been speaking to Luca about the level2 on XeO3, so I may pick that up again soon. But once again, I've left it in a horrible state! Its got a pretty serious bug in there somewhere (probably the new sprite cache) which causes the whole thing o slowly get corrupted and crash. Bugger.

The wiring begins!

Nothing much new, except I've started the long boring process of wiring up my prototype. I've been dreading this as its going to be really dull, and take AGES! I've decided that rather than wire up one at a time, I'll do them all at once, this means I'll get the correct connection from the schematic, and then wire that wire 5 times. It should save going back and forth all the time so it'll be quicker, but even more boring! Oh well....

The scrollys a foot....

After putting the display on a timer interrupt as well, I've managed ti get the whole thing going. So now the whole thing is interrupt driven. I optimised the IRQ routine so that the delay between each packet has been reduced and the overall update increased to around 20ms (rather than 100). So I've now started to wire up the prototype I started a while back but it'll take a while.

I put a new nib on my soldering Iron, but its already starting to lose its heat conductivity. Im not sure why but I think I may have it too hot and its losing its "tip", but I dont really know - this is the 1st time I've used an iron this long!

Alas poor scrolly, I knew him well..

I can't beleive how stupid I was last night. Banging my head off the wall trying to debug by just reading the source over and over without any feedback at all when suddenly today, I got one of those DOH! moments. I realised that I already HAVE a simple way of debugging (well...simpler). I can display an 8x5 pixel graphic! Or numbers and letters! What an idiot. So, I built the numbers 0 to 9 and then was able to find out the flow the program was taking (much like you'd do with PRINT's in your code). So, after an hour or so I've finally got it to run - more or less. It does work, but at the same time it doesn't. Theres still something wrong with the interrupts as if I get 2 packets very quickly, then the whole thing locks up. But if I delay 1ms between each packet, then all is well. This sounds like its getting a buffer overrun error (or I cant read it quick enough error). However, for testing, a 1ms delay is fine, particually as I have 100ms between displays to waste. This gives 64ms to send the whole row of pixels - fine.

But alas no.... Because of the system Im using I can actually test what it would be like to send 64 packets, and the load on the first units is far too heavy. It spends soo much time doing comm's, it has zero time left for anything else - like displaying the image. It flickers like mad! This isn't good. It simply can't handle passing on that many packets in an interrupt.

So, it looks like I'll have to try and reverse things. I'll put the comm's in the main loop, and the display in the interrupt. The display is VERY VERY simple, and will consist of a timer IRQ where by it sets 2 port variables - and thats it. This means when it does interrupt the comms, (which only happens every 3ms) it won't be in there for long.

*sigh*....its never easy.

EDIT: actually... it might not be all that bad.... The reason for the flicker could be that the delay in the main loop is being extended hugely due to the comms taking up more time. (the delay is a simple CPU loop). So before changing everything, I'll try using a timer for the counter instead which will of course be independent of CPU delays....

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.....