Time flies!

Apparently! well it must, they have clocks on aeroplanes after all…

anyway, I really should try to scribble here more, so much has happened of late in so many different ways in my life and I didn’t blog any of it!! (although some of that would be a conscious decision to not blog it 🙂 )

Coding wise, my work on the Sound Engine has progressed beyond my hopes! it isn’t complete and I have so many exciting ideas to add to it still, but there is a beta release out there!  Most exciting of all is that people are using it!  It’s an awesome buzz to see the logo for a project you have worked on stuck in someone elses project, reading reviews where people are complimenting the music of that project and thinking “My code is playing that!” brilliant.

Life wise has also been amazing, I have met an amazing woman (literally!)  and things are going better than I could have hoped in that regard also!  One of the many positives she has had on my life is rekindling my interest in cycling, so much so I am now cycling to work (not enough, but getting there), twice this week, would have been three times, except I was feeling pretty lazy this morning 🙂 (and have a lot to do tonight). As well as cycling, I have started to take Skiing lessons, hoping to make use of my new skills with my new lady later in this year or early next year 🙂

So, in super summary, interesting stuff on the Jag, amazing woman in my life, lost a load of weight (20+Kg!), getting fitter, learning to ski, oh and embedded electronics and system development fun!  See a lot has happened..

Now I just need to try and manage all this and get some sleep in too!

Brocade fabric switch error (AD VF conflict)

Just had this error on an ISL link between two switches, my initial Googling didn’t yield too much of use so I thought I may as well blog it and the solution (I used) here, hopefully be of help to others.

The scenario: Connecting a new Brocade 5100 switch with no configuration to an existing Brocade 5000 based fabric that uses Administrative Domains (AD).  Both the new 5100 and the 5000 are running the same release of FabOS, the 5100 has nothing but the barest of bare configurations (it’s IP address and authentication credentials).  With the ports connected, a switch show on the switches yields the following for the ISL port between them:


LS Attributes:    [FID: 128, Base Switch: No, Default Switch: Yes, Address Mode 0]

Index Port Address Media Speed State     Proto
  0   0   0a0000   id    N4   Online      FC  LS E-Port  segmented,(AD VF conflict)


Address Mode:    0

Index Port Address Media Speed State     Proto
  0   0   030000   id    N4   Online      FC  LS E-Port  segmented,(AD conflict)

I have included the last line of the information block as it gives a clue, the 5100 has additional lines here and more features, FID relates to Virtual Fabrics, a feature not supported on the 5000 in this case (I suspect not supported at all on the model but am not 100% sure of this).

The big clue for me is the “(AD VF conflict)” a bit of Googling revealed that it is not permissible to use Virtual Fabrics and Administrative Domains, I believe VF is the new AD, and hence mutually exclusive.  So the fix?

Simple, disable one or the other.  Now as the established fabric in this case is utilising AD, I am not going to disable that (as much as I would love to bin it 🙂 ) so disabling the VF on the new 5100 is the order of the day.  This is thankfully simple enough to do.

Use the command

fosconfig --show

to list all configured VFs and remove all but the default ones.  If you haven’t configured any, you won’t have any.

fosconfig --disable vf

will prompt you to confirm you wish to disable VF, this will require a reboot of the switch you are on, and a full reboot it is too, it will stop passing frames.  Once the reboot has completed, the switch should come back up and happily merge with your existing fabric.

Hopefully this will be of use to someone else, and as with anything I write on here, use this information at your own risk, I am not going to accept responsibility if you wipe out your companies fabric, or set fire to your gran doing this.

So, what happened to that sound engine?

Oops! yeah I kind of forgot to post anything here didn’t I!  My bad.  Well it certainly didn’t stop, in-fact several versions of it have been released and the current revision is well underway.  It has been adopted as the Sound Engine of a rapid game development engine (RAPTOR) written by the group Reboot (which for me is a great honor!), and their continued support and help with its development has pushed it along in leaps and bounds.

The core of the engine has been fully converted to the RISC based DSP on the Jaguar, with only support setup functions being called by the 68000.  Improved code has reduced it’s size and increased it’s accuracy, as well as removing the need for any look-up tables at this time (I have a suspicion I may not be able to maintain this for full module playback compatibility.. time will tell).

The latest release being worked on (0.18) has a completely rewritten sound rendering core, reducing code size whilst increasing performance and efficiency and also tolerance for bus latency!  Working in systems as ‘limited’ as these gives you a far greater appreciation for the finite capabilities of the machine.  Modern machines have so much slack available to them in terms of bus speed and memory buffers that these considerations just don’t enter in.  In the case of the Atari Jaguar the single memory bus shared between 5 processors running at 25MHz, you have to take into account that what you ask for from main memory may not arrive for quite awhile, adding buffering to absorb these delays is an absolute requirement, unless you want horrible distorted sound.  Of course these buffers are limited to only a few KB as you need this limited RAM for your program code and variables.

So, progressing and with plenty of ideas in the pipeline.

New year, get on that bike

Not a new years resolutions, more an organic desire driven by the number of cycling related friends I have and watching the Revolution highlights on Monday.  Revolution wasn’t as bad as I thought but still not my thing, to give an example of what is more appealing to me (I don’t typically do spectator sports) I found two YouTube links Street Descent in Brazil, and Street descent in Chillie  (the Chillie one is my fave).  Neither of these are my riding style or skill level I must add! 😀

But watching those clips stirred the long slumbering desire to ride my bike again!  As she has been unused so much since having my original bike stolen in 2006, which really killed my buzz, I have decided to give her a full service and shock maintenance.  Extra handy as Evans are only across the road and the ONLY authorized Scott shock maintainer in the UK (license to print money? at £95 a shock, I think so 🙁 ).

Last night I started the bike service of 2012 and have removed the shocks ready to take over to Evans tonight after work, during the 2 weeks that should take before I get them back I am hoping to have a good go at cleaning up the rest of the bike, ready for riding in 2012 :D  Going to be uploading pics to the gallery here for anyone interested in pictures of a bike being tinkered with and cleaned 😀

I am mostly pleased with my alternative solution to pad spreaders (which I forgot to buy when in Evans).. cone spanners & cable ties! 🙂

SoundEngine.. complete.. mostly!

It’s been quite a while since my last post and so much has been learnt and changed since then.  So much so that I have now completed the first release of my sound engine.  100% RISC assembly too! it has even recieved some very very nice compliments from my peers in the community, so I am pretty pleased with myself 🙂

Anyone interested in having a look (fully documentated too! with example code!) it can be downloaded here

100% on test Mod!

At last! 100% of the way through my chosen starting module (Theme tune to Alf by Trash).  Although I am a little sick of hearing it now oddly enough it mostly sounds (to me) as it should do.  Other ears have heard some tuning issues, but only in some places and I suspect this may be due to the rather speedy coding of some of the effects.

As the code to read the actual pattern data was so bodged and crufty and incomplete (anything that used more than 15 samples was never going to work), I decided to completely rip it out and rewrite, but adding in hooks for various bits along the way and knowning now what I didn’t know when I 1st wrote it.

Took me longer than I planned originally, but the final result was certainly worth it!  Adding effects to this new build is super simple.  There are 15 primary effects, with a further 15 sub effects.  For now I am concentrating on the primaries.  I therefor have a list of Addresses of the code to produce the desired effect.  To select the correct effect code the effect number is added as an offset to the address of this list, the program counter is then jumped to the address stored there (not before pushing the desired return address on the stack for the RTS at the end of the effect) and thats it.  When I come to write a new chunk of effect code I simply write it and then update the list of pointers.  Jobs done.

I still have around another 21 effects to code, I am quite pleased with the pitch slide effects I have coded tonight despite me being suspicious that these may be the cause of the out of tune behaviour and also being incredibly simple 😀

To further the work on the player I have a more complex effect rich module to work through now, one of my old favourites back in the day.  It has already identified and helped me resolve a few bugs I wasn’t aware of.  Really enjoying this project 🙂

Moar success!

I cannot believe how well this is going!  not only did my plan for volume adjustment work perfectly, I managed to write the whole thing in RISC on the DSP without any screwups!  Even managing to craft a procedure call with appropriate return 1st time!  Rather pleased with myself.

Some more cracks are starting to show in the less well planned code 🙂 it is like building a wall ontop of a badly done foundation, the more you build the more the foundation crumbles and needs bodging to keep up.  The re-write to RISC will be fresh at least, all though lovely extra registers to play with should make this run even sweeter.

In addition to my volume success I finally twigged on the period values being used within the tracker files, and believe I have actually tuned this to play at the correct pitch now, making it sound even better!  I tried a different tune and this highlighted a load more bugs I need to fix (ignoring the additional effects it uses for now), and yet more crumbling code as well as illustrating a possible need for multiple format detection.

Going to finish up early tonight as I want more sleep and I also need to build a VTES deck for playtime tomorrow 🙂


I really do like to test myself :/

My plan (coding wise) for this weekend was to get stuck into some effects in the playback of the tracker.  I added a simple jump and also sample looping quite easily (although they have both proven how code and fix is a terrible development methodology 🙂 a re-write is on the cards.. but still a prototype 🙂 ).  For my next feat I though adding volume adjust in would be easy enough, plus the module I am working with features a gradual volume increase over a looped sample at the start of the tune, so a good test.

The volume setting for modules is a range, 0-64, 0 being off and 64 being full volume, 0-100%.  My initial thoughts were a lookup table, so for any sample value I would have a table of all 64 volumes, (I’d ommit 0% and 100% for obvious reasons), alas this would end up with a table of around 16KB, which whilst not a huge amount of RAM, is more than double the cache RAM of the RISC CPU, which as this is where I want this code ro reside and I don’t want it faffing about on the main bus any more than it needs too, pretty much rules that option out.  I thought on it a bit more, and played with some excel spreadsheets (spent most of my coding time playing with numbers in excel and drawing line graphs etc!).  I could half the table if I only considered samples of 0-127 and then used this for negative values also, I could possibly shrink it further if I only consider 33-63 as the values of interest as I could use a right shift to give me 50%.. these solutions all seemed workable, but that lookup table was still around 1KB at the most reduced size I could think of, more than I was hoping it could be.

So machine off and some PS3 time, films and Dead Space 2 (both relaxing and stimulating 🙂 ).  I then had an idea, which on paper looks like it will work perfectly, and given the range 0-64 makes perfect sense!  I am probably coming at this backwards but figuring this stuff out for myself is the one thing I do this kind of thing for, its where the buzz starts, ending with the implementation of working code.  Quite simply using arithmetic right shifts on the sample, I can generate 6 volume levels easily (7 if you count full volume), 50%, 25%, 12.5%, 6.25%, 3.125% and 1.5625%  now 6 doesn’t sound at all like 64 levels of volume adjust… however, if you combine those 6 in the appropriate combinations you can produce any of the valid volume levels in the range of 0-64!  But how to determine the combination? simple, the binary of the volume level value indicates which of those volumes need to be added together to produce the desired final volume!

So 61 would be 95.3125% in binary 61 is 111101 so we add together 1.5625+12.5+25+50 = 95.3125   HURRAH! 😀

Of course this will require the original sample is processed a maximum of 6 times (with the output of each pass being added together), but this is not a huge amount of processing, even for multiple channels.  I may yet find a neater approach, but this one feels right to me at the moment.  Now I just have to wait until after work tomorrow before I can implement it! curses! 🙂


I had a day off following the Computer Club at The Lass on Wednesday, my sole plan for the day, to sort out my tracker distortion issues and make some progress.  It was a very successful day!

I attempted a few different approaches to resolve the distortion, having the playback routine count how many samples it had played, and the render code then generating that number of samples.  Which worked to a point, but just simply delayed the occurrence of the distortion by a chunk of time, and also increasing its duration.  It was clearly a slow drift between the two functions.  I tried having the render code monitor the playback position and pause or halt if it caught it up, this generated some weird audio effects or maxed out the 68K to 100% as it effectively spent all its time sat behind the playback trying to generate sufficient samples for the next VBI.

Thankfully Cyrano Jones popped up on IRC and whilst discussing stuff he suggested trying a double buffering technique.  I wasn’t convinced, but it was something I hadn’t tried.  After some battling and issues due to make not assembling all the files when it should of (I now use make clean a lot more 🙂 ) This proved a perfect solution!  As long as the output buffers are suitably sized for the maximum number of samples per VBI at the given refresh rate and playback rate all is good!  I must have spent 10 minutes listening to the same pattern play listening for the distortion, it didn’t come!

With the distortion issue fixed I now needed to get the other 2 channels in the mix.  Due to the way I am heavily using CPU registers for render variables, this was a little more complex and hacky than I would have liked, but this is a prototype so meh, I am looking forward to having the full 64 32bit registers of the DSP to abuse 🙂

The way I am writing the sample data to the DSP buffer is as a single 32bit long, (4x 8bit channels, handy).  This allows the DSP code to pick up all 4 channels from a single load, which also gets around the limitation that the DSP can only make 32bit loads and stores when addressing it’s own cache RAM.

As each pass through the render code generated 2 8bit channels at a time, it seemed logical to simply write these 16bit words to the DSP RAM, (improving efficiency as the DSP and 68K only have 16bit data bus width) skipping over the 16bits for the next 2 channels free for when those channels were computed later.  Or so I thought…. All hail the wacky hardware bug and all it’s glory :/  I soon discovered that DSP RAM should only be written to as 32bit longs from the 68K! otherwise it has a habit of corrupting the other half of the long!  This means the first two channels are written in the high end of a long write, then the last two channels are or’d into the low half of the long :/  so many wasted ticks!

With all 4 channels going, as well as all this 32bit long memory accessing wastage CPU usage is back up to around 40-45%.  At least its less than 50% and I am sure with a lot of optimization I would be able to claw some of that back.

However I now need to start working on the code that reads the actual song data and adding the effects, which is proving another challenge due to the way I have written some of the render code.  A fresh start may be needed based on what I have discovered.  I am completely psyched with the fact this thing actually plays a mod from start to finish and sounds like what it is supposed to! 😀

Of course I have found a few issues in there too which will be fun to fix, but its all progress 😀

Still going

Been a little bit lax with the updates, but I am going to put that down to there not being much to write.  Although progress and changes have been made to my code.

I have moved the mixing of 4 channels of 8bit audio over to the DSP, as well as the output buffer into it’s cache RAM.  I believe I know what the distortion is now, looks like the output is missing samples for short periods, I suspect this is either the CPUs fighting over RAM or catching each other up.  The actual render code is working as intended, I took some dumps from RAM of it’s output, no distortion before playback, distortion added after playback.

Moving to the RISC did highlight a bug that had me scratching my head.  I had erroneously operated the interrupt latches within the DSP, and hence not cleared the correct one, unbeknown to me this was preventing the DSPs main loop from running, a main loop that accessed main RAM to count a fair amount.. so when I fixed the latches, the DSP went on a mad bender of RAM access, almost halting the 68K from running at all.  Once fixed all ran as I had hoped.  Alas the distortion persisted, but the new changes have reduced the amount of time the 68K spends on the job, probably now down to around 5-10% CPU utilization on the 68K, amazing what shaving a few instructions from within a loop will do 🙂

Once I have conquered the distortion issue I will focus more on getting four channels working and playing through a whole module, rather than looping a single channel.  Tonight is the Computer club at The Lass, so no code tonight, but hopefully the day off tomorrow will have plenty of coding time in it 🙂

Getting there

Whilst the new approach was mostly working it had had a negative affect also, the introduction of some hideous distortion.  I have tried a few different things to isolate the causes of this and a solution but was rapidly losing hope at finding the problem.

Thankfully I decided to take a break from it and my latest attempts at solving it, and not more than about 20 minutes into the film (V for Vendetta if you are interested), it struck me!

The production of the sample data during the VBI was fine, however I realised that whilst it was generating this sample data it was also blocking all other CPU based interrupts, which would of course block the 8kHz feeder interupt that is feeding the sample data to the DSP!  I managed to resist the urge to stop the film and try it there and then.. which meant I got to enjoy the rest of the film, but try my idea out at well past coding o’clock.

The result? near perfect success! Instead of running the whole sample rendering routine within the VBI, I simply triggered it from the VBI and bingo!  This is lest than ideal of course, but as this is prototyping at this point it’s not really a concern.

I did also try clearing the interrupt latches earlier in the VBI handler to allow other interrupts whilst the sample render ran, but this didn’t seem to work too well, I shall investigate further, I suspect it may be due to the processor having not yet returned from the exception, possibly making it less tolerant of other interrupts.  Quite pleased with myself 🙂

A different approach

Despite heavy optimisation it seems that my current approach simply will not work the way I have implemented it.  There are too many cycles wasted to updating variables to make it feasible, it may be possible with the DSP due to it’s high speed local cache, but 68K and DRAM nope.  So time for a change of plan.

An alternative approach mentioned a while ago by Zerosquare was to simply write out the sample data to a circular buffer, and play this, only updating during the VBI.  The size of the buffer obviously has to contain sufficient sample data to maintain constant playback for the period between VBI but this is typically a very small time period (20ms for 50Hz or 16.6ms for 60Hz), which translates to only needing quite a small buffer for sample data (8kHz with 60Hz VBI is around 134 samples, double that for 16kHz etc).  Triggering the code less frequently also means less time is spent saving and restoring CPU state between interrupts, the more complex the code the more you have to save/restore, so doing so less frequently is a saving in time also.  More time doing actual work and not the associated ‘paperwork’ around it.

One additional big advantage to this approach is no need to save incremental updates to counters for every sample, instead these counters can be held in the CPU’s data registers for the duration of the processing and only written at the end, reducing the number of memory calls made by the CPU significantly.

So last night, after much mulling over on the sofa, I started this rewrite already past my stop coding deadline (if I code much past 21:00 at night it becomes hard to shut down the brain and get some sleep 🙂 ), I was quite pleased that I have a very rough working version of this code already and in under an hour of fairly half arsed hacking.  I have mostly repurposed my existing code, so it is still horrifically inefficient, however it has already demonstrated significant time saving even in it’s current form.  With this working base reworking it to take full advantage of the new benefits of this technique shouldn’t be too difficult.

Hopefully if I get home tonight with sufficient time I will have an opportunity to try.


I am working away on something I have always wanted to write, a tracker mod player.  Many years ago I mentioned to Tyr that I wanted to write one that resided entirely within the DSP of the Jaguar, and this is my current plan.  Of course rather than try and learn both the RISC CPU and how to write a tracker player I have decided to prototype the design on the 68K.  This should be challenging enough, however I am very pleased with my initial progress, which I have left to fester for a while due to frustrations and having other things I need to do.

The main issue seems to be that I simply cannot squeeze sufficient time out of the 68K, which is crazy given it’s faster than the one in an Atari ST, and there are rather quick players on the ST.  I for some reason have been struggling to push more than one channel past 8kHz which is pretty naff (although I am most chuffed in the general code, just it needs more work and optimisation)

This evening I decided to try out one of my ideas, I pondered that perhaps by ignoring the object processor if it had perhaps gone into a sulk mode and decided that if it wasn’t to be played with it would steal some of the bus bandwidth and sulk.  So I gave it something to do.. no difference.. bollocks…

I decided to try some other things before I reach “stop coding o’clock” (if I code past that time, I simply will not sleep! 🙂 ).  So I decided to look at how much time my code was taking on the CPU, as well as see if I could fire the interupt faster than I presently was doing.  To achieve this I removed my playback routines from the interupt handler and simply replaced them with 2 instructions.  One to change the background colour blue at the start and one to change it black at the end, with nothing between them.  This produced some nice small blue lines on the screen, perfect, I can now SEE how long it takes the CPU to perform these 2 simple tasks (long than I thought too!).

For my next trick I re-introduced my playback code, but crippled it to simply just the portion of the routine which checks for new samples to play, and re-ran it.  There was now a LOT of blue on the screen! although the amount of code was quite small. hmmm clearly the code is less than optimal time wise, naturally as I am coding a prototype I have not been as stringent as I would for a final.

My thoughts at this stage are that I am asking the 68K to access main RAM too much, as it has no instruction cache of it’s own, its instructions, and most of the data have to be dragged from main RAM, in the case of 32bit data that alone will require 2 fetches.  To test the effects of reads on main RAM I removed my playback routine from the interupt handler again and replaced it with 10 nop instructions.  Running the test again, I get slightly longer line than with nothing between the colour changes..  OK, I added ten 16 bit memory reads instead of the NOPS, the amount of blue increased GREATLY, it is hard to tell but instead of being only about 6cm of blue it now seems to wrap across whole scanlines!  Changing this to ten 16 bit moves from one internal data register to another reduces the line back down to a much nicer 8cm sized line…

So.. it looks like I am going to have to figure a way of doing this without the simplicity and comfort main RAM was giving me.  Good job I do this for the fun of the challenge really 🙂

RISCy endian

B’dum tish 😀


The Jag coding continues, I finally cracked my audio issue last night.  Sounding somewhat like white noise at least was pleasing in that I was getting noise out of the PWM DACs, however it wasn’t the noise I was .. erm.. looking for..  Much faffing and nothing, no change.  However whilst confirming the sample properties for the umpteenth time it struck me (no not the sample!).. ENDIANESS!  Those pesky chaps at Intel went and picked the wrong one! (Motorola having picked the right one, so sayeth me).. and as the sample was 16bit, this all made sense!  A quick bit of byte swapping fun and bingo, audible sound!

So what has this to do with RISCs? 68K isn’t one for starters, but the DSP is.  After eventually spotting a few more rookie errors and clearing the correct latches I have the DSP happily playing a sample from RAM all on it’s billy.  Nothing amazing I know, but step one in me both learning RISC assembly and writing my own multichannel sound routines and tracker.

Once again quite pleased with myself, so thought I should have a scribble here :)… now, back to the code.


It’s been a week and thought I should scribble some stuff down here to cover what happened, and what I can remember (there wasn’t much sleep to be had).

Alas the trip there was a bit of an epic jaunt.  Gaz popped up to mine with plans to head off early to collect Kev and Mike en route.  To kill off time Thursday evening we decided to go for a curry and a pint in Manchester, meeting up with Rich we had a rather nice curry and a few more beers than we first planned, then sat nattering over a bottle of Cider until 2AM.. so early start, not meaning a lot of sleep.

The drive there was a bit horrific, the roads knew I was tired, traffic and delays the whole way 🙁 so despite booking a later ferry we only JUST made it in time.  We did get the chance to get mine and Kev’s laptops setup and ready to code and develop on the ferry.  The drive in France was a lot easier and we even found the hotel with minimal trouble! huzzah

The event was awesome from the moment we arrived, largest I have ever seen, tables everywhere, quite a lot empty, but over half the room already full.  We located the other guys entering the coding competition and setup there.  Where most systems had one monitor/tv each (some more systems than monitors) this wasn’t the case where we were, each system had at least 2 screens 🙂 as well as laptops etc.

Once the competition had begun, I was now fully facing the prospect of writing a Tetris like game, from scratch, with power-ups (these were the competition requirements) on the Atari Jaguar (my retro system of choice 🙂 ).  I had been thinking about this for a while, the Tetris aspect had already been made known, but it was still pretty daunting to sit there looking at a directory with nothing in it but a make file and system setup routines.  Of course once the ball was set rolling the code did fly, Kev quickly crafted some graphics to get me started and it began.  My biggest regret, not enough sleep :)  We stayed there hacking away until around 2AM before deciding to get SOME sleep.

Sunday we were back at the event a little later than I hoped, with the coding to finish before 15:00 I set about crafting in the code I had written in my sleep 🙂 and Kev crafting more of the pixels.  It was a great motivation to overcome one of the bugs in the system within a few minutes of starting for the day (all hail coding in your sleep).  Kev’s graphics really made it shine also.  15:00 came around damn quick, game not finished, but resembling Tetris, and looking good, so I was pleased anyway.

So 21-24 hours later and about 1700 lines of assembly code, 1.1MB of graphics we produced the startings of a game called Reactris.  Thankfully some kind souls in internet land and part of the Atari Jaguar scene have crafted a lovely youtube video of it:

Youtube Reactris video

(thanks to ZeroSquare for the capture, and Sauron for the upload)

Post event, I slept, having had about 15 hours in the last 3 days and driven for 10 hours :)  Of course my travelling companions likened my appearance to that of a Zombie :).. Thankfully the drive home was a lot less troublesome, well except for the muppet that flipped a trailer in front of us blocking the main route out of Meaux.

Look forward to going next year 🙂 now I just need to finish off this game… 🙂

AC2011 draws closer

Not long now (April 16th – 17th) and I will be elbows deep in a 24 hour coding competition at AC2011 🙂  I am actually really looking forward to the challenge!  Creating something from scratch in such a limited time frame, whilst enjoying the event and socialising should be an interesting challenge, something I have always wanted to do since I was a kid.

This years theme is ‘Tetris’ but not just writing another Tetris clone, that’s the theme.. I have a plan and thankfully the backing of a skilled code party veteran pixel painter.  So I am sure whatever abomination I code, it will look pretty 🙂

Only a couple of weeks to get my laptop ready for the event too, and my libraries ready.. that in itself is a challenge, one that is absorbing all of my free time 🙂  having far too much fun with all this 🙂

C++ argv just getting first character

Plugging away at a untility to help with my Jag dev stuff and hit upon a snag.  Using what looked like pretty standard argc, argv processing code all I could get would be the ‘-‘ preceeding the command, or the 1st character if there was no -.  It turns out that this is due to Visual Studio 2008/2010 defaulting to Unicode with projects, so if you are trying to work with them as standard chars you are not going to have much luck due to the endianness terminating the 1st character effectively.

Simplest fix.. Bring up the project properties, select Configuration > General and on the right hand side under “Project Defaults” change “Character Set” to “Not Set”, bye bye unicode.

That has been doing my head in all night, hope its of help to someone else.

Blit o this, Blit o that

More fun and games with the blitter tonight, and mostly a success too.  Painting a 32×32 image into a 320×200 screen, getting the painting to not overwrite the background image, stuff like that.  In the process got to learn a lot more about the blitter and experienced some interesting effects which it may be nice to play with when I get to write something a bit more substantial 🙂

Tried my hand at blitter fading too, actually got it to work eventually as well! alas it seems to cane the system and there simply isn’t enough bandwidth to do what I had hoped.  Although as is the way I have had an idea or two how I may be able to improve the effect I was after and speed the process up too!  But that is something to play with tomorrow 🙂

As well as some full screen scrolling I hope too.

Evil apparently!

Second day of trying to get my head around the blitter on my Jag.  Not going as well as I hoped and much head scratching was being had.  Thankfully chatting on IRC with some helpful fellow Jag coders got me sorted.  Some handy snippets of blitter set-up code, commedy drivel and me finally spotting a rogue BSS section in one of my source files soon had me right.

Apparently the use of and users of the blitter are “Evil” and the cause for much suffering according to some 🙂

So far I am just using it to clear a chunk of RAM, tomorrow post work should see more progress in the blitter side of the force.  Hopefully then I can start bringing all these bits and pieces together and make something prettyish to look at 🙂