Bits of Brain

Kernel workings

2012-01-09T21:57:00.003Z

It's been a while since I've worked on it but I've started again and I've done a bit of work on the console interface along with a few fixes to the priority scheduler.

Time to knuckle down and and fix the IPC.

The two fatal errors are caused by the lack of a CRT for the two user-mode programs.

semaphores

2011-10-17T22:06:00.003+01:00

I've been doing some more work on the microkernel and have got to the point where a user-mode application can create other processes and threads, get its priority and so on and also - semaphores!

They're counting semaphores with support for priority inheritance. Unfortunately it's still a basic round-robin scheduler so it's a little harder to test it yet but hopefully soon it'll be possible to work on some more posix-like code to try and support some BSD style services or networking like Lwip.

Of course, the driver model needs to be tweaked first as the rather limited kernel mode drivers need to be updated & IPC needs to added support user mode drivers.

I'm back.

2011-08-07T21:30:00.002+01:00

I spent a bit of time offline.

Largely due to work and also I just didn't have anything useful to post.

In the last few months I've re-started and re-written my microkernel. This time I re-designed the architecture and put some more thought into it. Now it supports device drivers, alarms, timers and pre-emptive scheduling. It even has a few syscalls already.

The idea is to progress it far enough to support a bit of newlib.

I'd also like to get it ported over to ARM and getting running on some hardware.

More to follow.

Panasonic BDT210 DLNA Working, Finally.

2011-08-07T21:23:00.002+01:00

I recently purchased a new Panasonic BDT210 Bluray player. It's fantastic. It does 3D (not that I have a television to support it) and plays everything and sound great.

However. I tried to fire up the DLNA Client with my Twonky Media Server. Fail. Even setting it to the correct profile didn't seem to keep it happy. I placed the ffmpeg binaries into c:\ffmpeg and enabled transcoding on the web server. Still, nothing.

Then I found Serviio (http://www.serviio.org)

After binding it to the correct port and giving it a reset, the player saw it. Then, I set the profile to the 'Sony Bravia' and enabled transcoding on both cores.

Tada! Serviio has ffmpeg built-in and does the transcoding to MPEG2 which is what the Panasonic BDT210 supports. I imagine with enough tinkering this would also enable you to do the same with TVersity or similar but Serviio just worked straight out the box.

Homebrew OS and Ada

2010-08-11T21:58:00.002+01:00

I've started to go back to my OS again and looking at it it'd be quite handy to write parts in Ada and possibly C++.

Hopefully I can get these two things by compiling GCC with the newlib support in there and it'll use the newlib library calls (for things like memory allocation) which'll route into the current C memory code via syscalls.

This'll be quite nice as I like Ada and having the complex parts of the OS written in Ada has some nice advantages, including generics.

We'll see!

PowerPC Simulation

2010-07-05T20:55:00.002+01:00

About two years ago I was working on a PowerPC Simulator/Emulator and got so far (where it executed a few million instructions) and then - for whatever reason - start executing a string table. Debugging said million assembly instructions put me off working on it again for a while.

I picked up the code again and got it compiling and running rather quickly and even noticed two rather large and glaring errors.

Firstly, the device I'm simulating is a Curtiss Wright (DY4) DMV-179 with a PowerPC 750 processor. The device uses a GT64130 memory controller which you can setup for big or little endian. This wasn't setup correctly so was copying from Flash memory to RAM in the wrong endianness.

Strangly enough, when said inverted instructions are executed, it goes bat-s**t crazy.

So, fixing that I've started to work on getting that fired up again and seeing if I can get it to the point where the firmware (aka bios) starts talking on the serial link. Should be interesting...

24bit OpenAL support?

2010-05-13T19:37:00.002+01:00

The OpenAL website has a new wishlist item for 24bit support, among other things.

I'm not sure when, or even if, this would get approved as OpenAL - typically used for games - doesn't really need 24bit support.

Either way, nice to see its there.

samos x86 progress

2010-03-21T21:39:00.002Z

I've been busy at work but I've started working on the x86 target and BIOS BSP. At this point it's all really early but it starts up using QEMU and prints out some very early messages before falling flat on its face.

It's fall flat on its face because there's no BSP for BIOS and therefore it can't work out how much RAM there is - all dynamic memory allocations fail and the Kernel panics.

So yeh, I need to write support for - at least - the IVT (on x86 this is the IDT), a timer and handling interrupts. The BIOS needs support for at least querying the BIOS. This should let the scheduler at least fire up.

Then we can start doing cool stuff like the MMU and PCI. Fun stuffs :)

samos update, x86

2009-12-12T09:11:00.002Z

I'm in the middle of updating SAMOS to support the x86 targets and therefore also the BIOS and the various other x86 updates such as the PIC/APIC for interrupts and ACPI for power and state.

The other thing that may be interesting is exposing the frame buffer!

The main reason is that x86 simulators are better supported (compared to PSIM) to support Ethernet devices and usually come with GDB built-in for debugging any device drivers.

So, it's quiet at the moment, but only because I'm re-building tools and porting :)

Update

2009-11-04T22:06:00.002Z

Well the remote control idea worked! I can access the phone and get it to perform remote stuffs for me like playing a sound (so I can find the damn thing) or get it to reboot. Really, this was just a small prototype to see if it was possible so the project has been put into the depths of my subversion vault but worked pretty nicely.

Of course it was also missing things, I'd of liked to have added SSL and some kind of authentication to keep the connection secure.

Either way, I've been working on another little prototype. But until it's a bit more stable i'll continue to keep it quiet. It's not that interesting.

Also, Winamp OpenAL plugin is moving on, mostly robustness testing such as fixing memory leaks and so on.

Ideas

2009-10-18T23:31:00.003+01:00

I've been a bit quiet recently as I've been working to get the Winamp OpenAL plugin more stable with its new features such as 3D and some initial effects.

I've also been shown something on the iPhone that lets you contact your iPhone over the internet, for example, incase it gets stolen or lost for example. It lets you make a little noise or wipe it completely.

I knocked up a little Java app that could accept a command to play a tune - but getting it on my HTC Touch Diamond wasn't so easy as I had problems finding the SDK to get it to work on the phone.

So, I switched over to Microsoft Visual Studio and am in the process for writing a nice little C++ application that will connect into my server at home every so often to report its [the phones] IP address. It'll also have a server that you can connect to and send it commands.

Luckily enough it can be tested over ActiveSync so there isn't a security issue yet but ultimately it'd need something like SSL and user auth.

But yeh, I like the idea of being able to talk to it and get it to play tunes when it gets lost. Of if it gets stolen - send me back it's GPS data! And of course a wipe command for email/contacts/data etc.

samos progression; newlib and operating system interfacing

2009-09-09T18:27:00.005+01:00

With SAMOS nicely looping around it's probably time to find a way for programs to access the Operating System. I've already mentioned that system calls (syscalls) are implemented and work and these now need to be expanded from just Device Driver calls.

Firstly, we'll need to provide a few calls that newlib can use (for example sbrk which is called from malloc for memory allocation on the heap). It's probably worth trying to map inbyte and outbyte too so the user can do getchar and printf and it be routed through to the Operating System.

Other things we may want (other than Device Driver read/write register/memory) is the ability for an application to do something in user-mode when an interrupt is triggered.

Finally it'd be nice to have things such as TCP/IP stacks and a method of Inter-process communication (IPC). Being a microkernel the idea is what these things will all execute in user-mode - but be managed from Kernel mode. This means we'll have a services manager that can be queried - and probably abstracted - so provide a single C header/c file to do Sockets & Pipes (IPC).

For example, the application would call:

initialise_pipes();
...
procs = get_procs();
...
proc = get_proc(proc_id);
...
pipe_to_proc = create_pipe(proc);
pipe_write(pipe_to_proc, "hello", 5);

The Pipe abstraction would do something like:

initialises_pipes() {
my_service_id = samos_get_service("pipes");
}

pipe_write(pipe, data, len) {
send_service_message(my_service_id, WRITE_PIPE_ID, pipe, data, len);
}
...

The actual Pipe service might be a process that's interrupt driven:

pipe_write_intc()
{
details = get_details();
details.recv.push_data(data,len);
}

As you can see I haven't really worked through the details and this is all off the top of my head but the point is that virtually everything (except service queries) is executed in user-mode. Sure, those Services will have to request the Kernel to setup memory mappings because two (or more) processes and maybe that'd be a hard-code Operating System call so that the Operating System (rather than a Service-provided thing). This way the Operating System is in control of checking & allowing those two processes to communicate.

This is much the same way I see the Device Driver model working. Most of the device driver will be written in user-mode with register/memory read/writes as syscalls where required and control procedures (with parameters) where a time-critical process of multiple register/memory read/writes is required.

The benefit, of course, is that the OS can detect exceptions generated during user-mode driver code and disable further access to that driver. If the exception occurs in the kernel-mode driver - because the OS has no idea what's happened - the Kernel probably has to panic.

These are just my thoughts as I develop my OS without reading any other material. My intention is to do this (develop it based on my ideas, of course some will be affected by what I've used/seen) but not to copy anything and try to create something entirely new and see how well that works. Or not!

samos - pre-empting!!

2009-09-04T21:35:00.003+01:00

Below is the startup sequence using the PSIM PowerPC simulator built into GDB. It correctly preempts and starts to execute the idle thread - which uses a System Call to write out the Serial Driver.

Of course by the time it preempts the second time something had gone wrong - hence the large amount of memory debugging.

Also, it's using newlib which is a good sign of progress. Once the preempting problem is fixed, and with the newlib C library, an ethernet/serial based serial debugger would be a next port of call. Oh and moving to Qemu or something which has an ethernet device... and an ethernet driver. Hmm... fun times!

From there - or with them statically linked - parse and load ELF images and load them in!

Anything from interrupts.c is tracing from psim.

Update:
Fixed it - update the memory management to be correct. The scheduler now loops around the idle thread!

Wooooohoo!

TARGET-PPC32: copying interrupt vectors to RAM...
KERNEL: initialising memory pool 0x0001CA90, size 0x02000000
KERNEL: initialising the scheduler...
KERNEL: initialising the kernels heap...
KERNEL: mempool at 0x0001CA90 alloc 0x00404000 at 0x0001CA90
KERNEL: initialising memory pool 0x0001CA90, size 0x00404000
KERNEL: initialising the task manager (dynamic)...
KERNEL: mempool at 0x0001CA90 alloc 0x0000000C at 0x0001CA90
KERNEL: mempool at 0x0001CA90 alloc 0x0000000C at 0x0001CA9C
KERNEL: creating kernel process...
KERNEL: mempool at 0x0001CA90 alloc 0x0000000C at 0x0001CAA8
KERNEL: creating idle thread...
KERNEL: mempool at 0x0001CA90 alloc 0x00000220 at 0x0001CAB4
KERNEL: mempool at 0x0001CA90 alloc 0x00001000 at 0x0001CCD4
KERNEL: thread (Kernel Idle) create spb=0x0001CCD4, sps=0x00001000, sp=0x0001DCD3
KERNEL: attaching the idle thread...
KERNEL: mempool at 0x0001CA90 alloc 0x0000000C at 0x0001DCD4
KERNEL: mempool at 0x0001CA90 alloc 0x00000220 at 0x0001DCE0
KERNEL: mempool at 0x0001CA90 alloc 0x00001000 at 0x0001DF00
KERNEL: thread (Kernel Scheduler) create spb=0x0001DF00, sps=0x00001000, sp=0x0001EEFF
KERNEL: mempool at 0x0001CA90 alloc 0x0000000C at 0x0001EF00
KERNEL: scheduler initialised

KERNEL: SAMOS Version 0.1
TARGET-PPC32: enabling external interrupts...
interrupts.c:464: external interrupt - cia=0x2104
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:464: external interrupt - cia=0x4cfc
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread

samos scheduler & syscalls

2009-08-22T17:42:00.001+01:00

System calls are now working and the scheduler is almost there! For some reasons some static data is getting corrupted but other than that the timers are kicking in an pre-empting a procedure which does constant syscalls.

Arduino Mega

2009-08-08T01:45:00.003+01:00

Just got my Arduino Mega in the post this morning and before popping out for the evening I did the typical hello world over the Serial connection and got some LEDs going - astonishingly easy which is always good.

Tomorrows mission is to wire up a matrix of LEDs for a Spectrum Analyser and update the Winamp Visualisation code to support the serial connection. With any luck it should be fairly easy to do, the only thing I need to really worry about is the power consumption of so many LEDs but hey ho.

Also, on the arduemu front - would it be weird to get arduemu running on a real arduino? That'd be like one of those motivational posters or something weird like that eh? I'm still trying to work through the opcodes of the arduino and it's ultamtely a question of time rather than skill - although the status flag documentation is the instruction set continues to be as helpful as a punch to the face. If you're an Arduino person and have access to sourceforge.net or an openID and want to help give me a shout!

project update(s)

2009-07-28T21:02:00.004+01:00

SAMOS is moving along nicely and I've started reading up on the ia32 architecture and ACPI ready for a target port to the 386 based family. I've also fixed the interrupt handling on the PowerPC code and need to take another look at trigger/level driven interrupt handling on the OPIC.

Wumpus OpenAL Output for Winamp, I've been working on panning, effects, 3D and XRAM stuff and thats starting to take shape (check out the SVN) so you can pan and move the mono sources around now. Stability isn't quite there yet and I'm not sure the code is as efficent as it could be but it's all moving along nicely.

Arduemu; we've started to talk about getting development up and going again. I'll probably start working again on the opcodes of the processor fairly soon and Rich is looking to start working on stuff in a few weeks time.

So yeh, all fun 'n' games.

Winamp OpenAL Effects and other things

2009-07-18T12:20:00.005+01:00

I'm in the middle of update the Winamp OpenAL plugin so that it'll split out stereo+ sources down into Mono sources that OpenAL can then use to position them and apply effects to.

This means you'll be able to do strange things like put a speaker 5 meters away and the another right next to you and pretend that you're in an aircraft hanger. Quite why you'd want to listen to your music like that is beyond me. However, instead of a hanger you could use concert halls and such if you wanted to add that live feeling. Obviously this is old-hat technology thats been part of EAX for a while but still it's nice to have the option!

Update 1
The new code supports the old non-split again and that plays fine so it should be a case of splitting up the audio and then adding effects to each channel!

Update 2
So it can split stereo down into two mono stream and change the listeners position (i.e. panning).

I've added a GUI for changing the values of the sources too if you want to move where the speakers are but that isn't working quite correctly - for now. Will look @ correcting it tomorrow.

samos progress with c library, scheduling and syscalls

2009-07-10T23:33:00.002+01:00

Over the past week or two I've been doing more work on my Operating System. As previously mentioned the scheduler now works and that means we can start to look at some more interesting things.

I found a good guide for building a toolchain on a i386 however I'm (initially) developing for a PowerPC processor. Later on I'll blog the differences incase anyone else is working with ppc32. This also means I've not got a standard C library now (newlib)!

However building an ELF program is pointless if it can't interact with the Operating System - hence syscalls.

I can now start to work on the syscall interface between programs and the operating system so that they can create new programs, write to device drivers and so on.

Finally - SAMOS will stand for [S]mall [A]gile [M]odule [O]perating [S]ystem.

samos pre-emptive scheduling, idle thread

2009-06-28T15:20:00.003+01:00

The Kernel is now firing up and the idle thread is running (prints out once every 100,000 iterations in a while loop). This is running on PSIM using it's OPIC Interrupt Controller and debugging out to an emulated Serial Device.

pre-emptive scheduling in samos

2009-06-22T19:44:00.002+01:00

In samos I've spent the last week (on holiday) working on the pre-emptive scheduling.

This has been moving on fairly well to the point where the external interrupt on the PowerPC simulator comes in and we interogate the OPIC Interrupt Controller to work out what happened. From there we work out the ISR to run which is the scheduler one and save any state of executing task. When we return from the ISR we enter the Scheduler which selects the next thread and executes it.

The last bit I'm missing is to restore that threads register values but once that's conmplete the scheduler should nicely be able to run the Idle thread all day long.

Not very exciting though so it means I can work on a debugging app for the command line. Maybe that's less exciting that I thought. Either way - interesting! It'll also offer the opertunity to start looking at newlib and CRT again for userland apps.

arduemu on hold

2009-06-22T19:42:00.001+01:00

Rich has dropped off the project and my work with my Operating System & Winamp OpenAL plugin is taking up a lot of time.

The current source code for the arduemu is online and I'd really like to carry on so if anyone has some free time and would like to help out I'd love to hear from you!

samos - pre-emptive scheduling progress

2009-05-31T00:51:00.005+01:00

I've spent most of today - well OK this evening - writing a driver for the OPIC timers to use in pre-emptive scheduling of the Kernel. I've got it counting down and generating an Interrupt but that isn't getting into the OPIC controller yet, no doubt some configuration bit on a register I've forgotten about.

Either way, once timer based interrupts can be generated and handled with an ISR the Scheduler can dump the register state into the Processes memory and chose another process to run - i.e. pre-emptive scheduling.

Of course at the moment I don't have any Processes except the Idle processes but I guess two programs that print "Hi" and "Bye" could run and should switch between them if they're set at the same priority.

Once I have pre-emptive scheduling in I can start to look at getting newlib setup correctly with CRT0 so I can write some proper test apps. It'd also be nice to abstract the PowerPC page tables in RAM so I can make best use of the MMU for proper process memory protection.

Winamp OpenAL 0.9 Beta 5

2009-05-16T10:01:00.004+01:00

I'll be working on Beta 5 over the weekend (Beta 4 is available here) to fix the MP3 VBR (Variable Bit rate) issue.

If you have any bugs with any release please post it here rather than on the blog as it's easier to track!

Ta

Update:

Well I've fixed it and it's only 11am, cracking. I'll run some tests through my collection and make sure it stands up and then do some cleaning and hopefully will check it in today.

YAU (Yet Another Update)

It's ready for download here

Winamp OpenAL 0.9 beta 3, plug-ins?

2009-05-06T22:21:00.004+01:00

Thanks to the various people who've submitted bug reports and comments for the new 0.9 beta for the OpenAL plug-in for Winamp.

I know it's been a bit of a pain but the benefit is, to some extend if you're a purist like me, worth the hassle of sorting the few issues out. On my Laptop (software rendering) and Waveout Winamp uses 3-4% but with the 0.9 Beta 3 build its virtually nothing - but that isn't me that's all down to OpenAL.

I've added a bit more info about XRAM to the configuration page so people can see why the XRAM tick is disabled. If its greyed out and you have XRAM let me know and I'll investigate.

I'm also wondering if anyone would think about extending the Plug-in (plug-ins for a plug-in?) in regards to things like Effects? I don't really have the time to invest in it but I could quite easily add a new interface for extra DLLs to be loaded in with extra functionality.

If anyone's interested and wants to write any kind of Effects plug-ins (and has a knowledge of C (you might be able to get away with VB :s, not sure though) for the DLLs then let me know.

Beta 3 is out on SourceForge for breaking... err testing.

Arduemu opcodes

2009-05-04T13:31:00.002+01:00

Nothing like writing Arduino opcodes on a bank holiday Monday! Rich is taking a break to work on his Jailbreak project but should be able to have a bunch more opcodes done today.

Update:
Lots of new opcodes added, about 46 or so in total now giving us about 35% of all the opcodes done.

Wumpus OpenAL Output for Winamp 0.9 - XRAM

2009-04-25T13:32:00.004+01:00

After giving up so nicely on WASAPI and picking up a new X-Fi card from Creative with XRAM I've managed to start work on version 0.9 of the OpenAL plugin instead.

I'm not sure how XRAM will work as it's likely I'll have to buffer the entire stream and then move it into XRAM from RAM rather than streaming it in bits. On of the things I've already done today is setup a new Subversion branch for zero-copy buffering. What this means is that I no longer do my own buffering in the plugin, as data comes in we send it straight off to OpenAL. The benefit is rather obvious - we're not moving memory around or working out how much to copy and where to!

This also removes the need for internal buffers and the temporary buffer and pointer arithmetic which although worked is slower than just giving it to OpenAL!

In conclusion - gutting the source code to a minimum for speed and trying to see what we can do with XRAM. A fun weekend indeed!

Update:
Ok it's Sunday and the XRAM & buffering update is done and works! It requires a bit more polishing bit you can expect a beta tomorrow or midweek. Right now although XRAM is in there I'm not entirely sure of it's advantages as Winamp is kinda streamed (in <8KB blocks) so I may buffer that up internally into, say, 8MB blocks and put that into XRAM to optimise for latency.

samos & interrupts

2009-04-17T18:15:00.004+01:00

I've managed to write a Device Driver for the OPIC interrupt controller and get interrupts from a Serial Device. Over the course of the weekend I'll map this into the Interrupt Controller (the Serial Device Driver will map to it) so the Serial Device Driver can read this, handle it and it can all carry on!

IntC (Interrupt Controller)
ISR (Interrupt Service Routine)

1/ Get the Interrupt into the External Interrupt Vector on the PowerPC
Serial Driver --> OPIC --> External Interrupt --> Ext Interrupt Vector --> IntC

2/ Query the BSP to query the OPIC to work out Interrupt occured
OPIC <-- BSP <-- IntC

3/ Lookup the Interrupt Handler (ISR) and execute it
IntC -> ISR -> Driver

We've handled the interrupt!

4/ The driver should remove the source of the Interrupt
Driver --> Hardware

5/ Finish off; tell OPIC we're done and it can remove the Interrupt
IntC --> BSP --> OPIC

Arduemu external devices idea

2009-04-13T10:11:00.003+01:00

I was thinking about how we'd emulate the external devices on the Arduino boards; from what I can see so far they're largely pin based although I need to dig a little deeper and see how that looks in assembly (i.e. is it bit or byte access).

However, the idea I had was that during emulation you could connect emulated devices to the emulator over Ethernet. This would mean you could connect devices as it was running to a base address (i.e. TCP port 6000) and even fire up another emulator with a different base address (TCP port 7000) and connect - for example a serial device to each and let both emulators talk to each other over Ethernet.

I'm not sure how that'll work out bandwidth wise yet with things like Ethernet devices but they're a way off - it's not like I've seen anyone connect an HDD to one yet. But even then the I/O would be Ethernet based (and on the loopback device - inside the stack - so should all be done in memory assuming that's how the Operating System works).

WASAPI and Winamp project closed

2009-04-11T10:51:00.002+01:00

I've stopped work on the WASAPI plugin as I'm just not making any progress at the moment and time is being sucked away by my OS project.

However, I'm releasing the source code under GPL here so please take a look and see if you can fix it.

If you do work out what was causing the issue (the issue is rather obvious) please do let me know.

Winamp & WASAPI weekend of code

2009-04-04T16:55:00.003+01:00

Well I've written a nice new genetic buffer (might move it into OpenAL plugin later on) but that didn't solve the problem.

Instead I think it's more an issue in the various levels of abstraction in PortAudio so I've dug out the old MSDN documentation for it and am trying to get that up to date and working.

Hopefully this will remove the dependence on PortAudio and mean I'll have more control over WASAPI.

Update:

Well I've switched over to a hard coded WASAPI implemetation and dropped PortAudio but I'm kinda back to where I was. The audio plays at like 1/8th the speed like its an LP and its slowed down.

I'm not sure why it's doing this and I'm going over the MSDN docs to try and found out why but right now I'm at a loss!

Winamp & WASAPI Exclusive mode!

2009-03-29T13:01:00.003+01:00

Well by changing PortAudio from Exclusive Mode to Shared Mode the plugin I wrote works fine (it plays but the rest is a little rusty as that's all i was doing) - and works fine with ASIO too.

I'm gonna take some time to dig into Port Audio and see if it's doing Exclusive mode correctly. When put into Exclusive mode the sound is slower and chopping, stutters. It sounds like it might be sampling rate issue but I can't be sure - if it is Exclusive mode should be able to handle it as it's done in hardware.

Update - it works!

So I've been playing with PortAudio's use of Exclusive mode and have cracked it. Winamp now plays in WASAPI Exclusive mode! Obviously this stuff is miles away a release I'm afraid but it's progress.

WASAPI and Winamp

2009-03-27T19:39:00.003Z

Someone beat me to it! No, wait, two people beat me to it (I've been distracted).

One is here and the other here.

I haven't tried either of them but if they're good and actually work (in Exclusive mode) then I'll stop working on my Plugin and leave it to these fine people!

VisualSVN

2009-03-26T23:07:00.002Z

At home I use Subversion for version control. For the project I've open sourced I use SourceForge which also uses Subversion.

The server part I've always used before was a hacked together Windows Service of svnserve.exe or the Apache plugin.

However, VisualSVN is a more ... visual? version for Windows that also integrates into the Windows authentication stuffs.

Definitely worth a look.

Memory management implementation

2009-03-24T22:21:00.005Z

Well the memory management system has been implemented, initially anyway, and seems to be working correctly. Defragmentation via the MMU is out at the moment but it'll have to go in later on so that the heap can be allocated and accessed anywhere in RAM (right now it's using BAT registers).

I've also started to draw out an initial Architecture diagram. So far I have four layers;

1/ The Core - Processes, Threads, Device Drivers and so on

2/ OSAL (Operating System Abstraction Layer) - Kernel objects, HAL to access the Device drivers and Interrupt control.

3/ newlib - a C Library implementation with extra syscalls for the extra OSAL items.

4/ Applications. This one caused me to think a bit; how will the Kernel fire up an application? Are they implanted straight into the Kernel as seperate sections? Are the ELF images stored in bss and then parsed and loaded into memory? Bit early right now but interesting stuff.

Dynamic memory management

2009-03-19T15:06:00.004Z

I've been busy working on Arduemu recently but as Richard is working on implementing the opcodes I've taken a bit of time to get back to Samos.

I've been looking (again) at the way dynamic memory is dealt with - i.e. the heap and things such as memory fragmentation. Previously I was splitting the pages into chucks and allocating that way - however if you're allocating 4 byte values (poor choice anyway but nevermind) or are just slightly over a chunk boundary then you end up wasting memory; and on an embedded system that could cost you.

Instead I'm looking to implement a block table which will reside at the top of the heap and slowly grow down to the heap base with a meta-data table at the start. Each table entry would be 64-bits (2 bytes). As you allocate memory (at the bottom of the heap) a table entry is added.

As entries are added, empty entries pad the free data or the empty entries are re-sized down and new "allocated" entries added.

This is quite close to the Buddy System but - at the cost of speed - packs the memory closer together. However, as we're running on an embedded system the result is more efficient use of our limited resource - RAM.

It's also nice to have come up with a system myself and it match what someone has already defined as a recognized system. I can see other benefits and possibilities with this system too.

1/ Fragmentation.

Assuming an MMU is not present we simply use real address values and when memory becomes fragmented we're stuck - memory allocations of a larger than available size fail.

Assuming an MMU is present, we can use the MMU to move page-aligned blocks around and update our table to move - for example - all the free entries to the end of our heap.

This way the real address we've returned becomes a virtual address and is still valid. It also means we don't have to copy any memory and our Operating System can support an MMU or not.

2/ Multiple Processors.

At present the Operating System doesn't support multiple processors. However, if it did and those processors had shared memory (as one would assume) instead of locking the entire memory down when mallocs are performed it can be tuned to just that one heap and also - possibly just one block (although how the table is synchronised is TBD).

3/ Debugging / Memory leaks

It would be possible to show all the blocks separately and record the PC so that a process or high-level library could track memory allocations and detect memory leaks and where that memory leak was started.

arduemu looping

2009-03-11T22:21:00.004Z

The arduemu has had a few more opcodes implemented now and can do basic loops.
i.e.

start:
ADD r2, r3
JMP start

It's a pretty small detail but it's nice to see some programs running for the first time and in such a relatively small time frame since we started the project. We knew the 8-bit CPU would be easier to implement then say a 32-bit RISC processor like the PowerPC and this goes a way to showing that.

As further opcodes get implemented more complex test programs can be created - might even be good to see if the Bootloader will start although I would assume that requires some external devices but we'll see.

arduemu

2009-03-08T11:49:00.003Z

Richard is making progress on the CPU for the Arduino board (the Atmel AVR) now that the decoder is done and I've started to look at the various things off the board that we can implement.

The first two ideas that came to mind were serial devices so we could get some input/output going - "Hello World" if you will. This then spawned another idea, apart from having a Serial Console device (get and put text char by char) we could also connect straight into the Windows Serial stuff and use a real serial device.

This way you could run your project on Windows or Linux and drive things out on the serial device.

The other thing I'd like to get going would be some kind of Discrete (on/off) inputs/outputs and maybe even some analogue inputs and outputs going. Obviously these could be done with a GUI front end - maybe even over TCP/IP - but implementing these as adapters to real hardware? Not sure that's possible without building drivers for specific cards like the VM110.

Either way lots of interesting things to try once the Bootloader is working. Of course that doesn't work yet because only a few instructions have been implemented but we can get it into Memory and have the source code so that should make life easier!

arduemu in Eclipse and Visual Studio 2005

2009-03-03T23:00:00.006Z

The instruction decoder for the Amtel AVR is done and the project builds nicely in either Eclipse or Visual Studio 2005 thanks for cross platform lovelyness.

Now that we've got converters (Intex Hex, S-Record etc) to raw binary and a Decoder that takes that and converts it into a structure; work can start on emulating the CPU itself.

The other part we're missing is memory mapped I/O. This is going to be a huge chuck of memory that we're just going to map everything to. This'll mean when you fire up the emulator it will program the Bootloader into the right place in memory, then the Program into the right place.

Registers and devices such as RAM and FLASH and EEPROM are also mapped into this area.

Richard - for funzies - is working on the processor so I guess my next task is to work on some of these external devices. Maybe Serial - just written a serial device driver for samos so hey! Might as well.

Project(s) update

2009-03-01T22:20:00.004Z

samos

At the moment I'm working on the interrupts - a Device Driver for the Open Interrupt Controller and the general mechanism to handle them. One of the benefits of PSIMs OPIC is that it also supports timers which can be used for preemptive scheduling later on.

The ARM tools have been built so I should be able to start creating the platform dependent code for ARM and therefore be able to switch between PowerPC and ARM quite easily.

Arduemu

I've worked out how to decode the parameters nicely so just working on that now. We're loading up S-Record, Intel Hex and Atmel Object code fine and I think Richard has started on the main loop so we should be able to start implementing some operations soon.

samvis

Kinda dropped the ball on this one; need to get hold of a PIC and get the I/O board onto a bread board.

WASAPI

PortAudio - usual story!

P.S. Prefix of sam is there because it's my name. I know it. Sometimes.

writing an operating system - ARM

2009-02-28T10:47:00.002Z

My previous entry noted how to build the tools to do cross platform development of a PowerPC Operating System (read Kernel) from Windows or Linux.

Since I need myself to port over to the ARM architecture here are the commands for building the tools for Eclipse for ARM.

binutils

./configure --target=arm-elf --prefix=/home/user/tools_arm7 --disable-nls

gcc

./configure --target=arm-elf --prefix=/home/user/tools_arm7 --with-gnu-as --with-gnu-ld --disable-nls --without-headers -enable-languages=c,c++

gdb

CC=gcc ./configure --enable-sim-arm --enable-sim-inline --enable-sim-duplicate --disable-sim-xor-endian --disable-sim-trace --disable-sim-icache --target=arm-elf --prefix=/home/user/tools_arm7 --disable-nls

Now have to learn the ARM instruction set :s

wasapi and portaudio

2009-02-28T00:49:00.002Z

Just so you know - still haven't forgotten. I'm still waiting on the PortAudio project. It may be that the issues I'm experiencing are corrected in the V19 work - may see if I can bring over the latest SVN at the weekend.

Arduemu update

2009-02-27T21:06:00.005Z

The project is going well so here's a quick status update.

1/ Instruction Decoder.

The decoder can work out the op-codes now, just need to implement a more generic way of working out the parameters.

2/ File formats.

Right now we're able to support three file formats - well will be able to - the parsers have been written.

Intel Hex - one of the default output formats of the Arduino tools

S-Record, not a default file format but the tool does squirt out ELF which can be converted over to S-Record for programming onto your device.

Atmel Object file, if you're not using the Arduino tool this is the output of some of the Atmel tools such as AVR Studio.

Arduino emulator

2009-02-23T22:16:00.005Z

My latest project is a joint one. The project aim is to create an emulator for the Arduino set of boards.

Right now we're working on decoding the Atmel AVR instruction set. This comes comes as two parts.

1/ Work out which op-code it is so we can...
2/ Work out what format it is to determine what the parameters are.

I'm in the middle of 1/ at the moment, putting together a rather large look-up table with all the bit-masks to work out the op-code.

Likely enough it's only an 8-bit instruction set so quite simple!

The project will be on SourceForge soon!

writing an operating system in eclipse

2009-02-18T20:42:00.004Z

I've been reading a websites about writing an Operating System in various IDE's such as Visual Studio. For my operating system I've been using Eclipse because it and GCC are both cross platform. This means I can write and simulate the PowerPC on a Windows box or Linux box.

1/ General - Windows/Linux

Regardless of the Operating System you'll need some basic tools to build the below. In this case we're developing for a different platform. I.e. We're writing a PowerPC Operating System on an x86 machine. We can still do this, but we need to create a cross-compiler - one that runs on an x86 machine but generates for PowerPC - for example.

With almost all Linux machines these tools, like make, automake, bison etc come as default. With Ubuntu you might want to get the buildessentials package.

Until Windows, you'll need to grab Cygwin. Install the basic build tools like GCC, make, automake and bison. You'll know if you need anything else when we try to build the Tools below and they fail.

2/ Tools - BinUtils and GCC

We now need to build the cross-compiler and tools. Initially we'll build a very basic version of the GCC compiler.

2.1/ binutils

Once you've downloaded GNU binutils extract the tar and load up a command line (or Cygwin) and execute the following.

./configure --target=powerpc-elf --prefix=/home/user/tools_ppc32 --disable-nls

then

make all && make install

powerpc-elf is the target - the machine we're going to be compiling code for.
The --prefix option sets the directory all the tools will be compiled to. We add this so this version of GCC doesn't over-write the one we have installed.

2.2/ GCC

Download GCC and extract the tar and goto the extracted directory and execute:

./configure --target=powerpc-elf --prefix=/home/user/tools_ppc32 --with-gnu-as --with-gnu-ld --disable-nls --without-headers -enable-languages=c,c++

make all-gcc && make install-gcc

Again, we specify the powerpc-elf target and add the --prefix argument. We say which tools we need and specify no headers (there's no C Library yet!) and the languages the compiler should be able to compile.

Once they're all built add the /home/user/tools_ppc32/bin directory to your Environment variables. This'll let Eclipse find the tools we've created for the PowerPC.

3/ IDE - Eclipse

Now we're in Eclipse create a C or C++ project. We then need to update the projects build settings for our new cross-compiling tools.

Under the "C/C++ Build" tab moved to the "Settings" tab. Under the "GCC C Compiler" change "gcc" to "powerpc-elf-gcc" and set the following settings.

For "Preprocessor" tick "Do not search System Directories".

Under the "GCC C Linker" set the command to "powerpc-elf-ld". Under "General" tick "Do not use standard start files", "Do not use default libraries", "No startup or default libs" and "No shared libraries".

This'll make sure we only use the libraries and headers in our Tools directory.

Under "GCC Assembler" set the command to "powerpc-elf-as".

Now when we compile our project we'll just be using our powerpc-elf-* tools. These'll generate code for a PowerPC processor even if we're on a Windows box with an Intel processor. We could also create tools for an ARM processor and then the name of the tools would be different, i.e. arm7-elf-*.

Because we're not using default start libraries we'll need to tell the compiler how to build our project. With GCC this is done with Linker Scripts.

Below is an example, it's what I've been using.

ENTRY (__kstart)

STACK_LENGTH = 0xF000;
HEAP_LENGTH = 0x400000; /* 4MB */

MEMORY
{
RAM : ORIGIN = 0x00000000, LENGTH = 0x4000000 /* 64MB */
}

SECTIONS{

/* code */
.text 0x2000 : {
*(.text)
}>RAM

/* read only data */
.rodata ALIGN (0x4) : {
*(.rodata)
*(.rodata*)
}>RAM

/* static data */
.sdata ALIGN (0x4) : {
*(.sdata)
}>RAM

/* data */
.data ALIGN (0x4) : {
*(.data)
}>RAM

/* Small Block Started by Symbol */
.sbss ALIGN (0x4): {
*(.sbss)
}>RAM

/* Block Started by Symbol */
.bss ALIGN (0x4) : {
*(COMMON)
*(.bss)
}>RAM

.stack : {
__kernel_stack_start = .;
. += STACK_LENGTH;
. = ALIGN(4);
__kernel_stack_top = . ;
}>RAM

.heap ALIGN (0x4): {
heap_start_addr = .;
. += HEAP_LENGTH;
heap_end_addr = .;
}>RAM

}

You'll notice that __kstart is the operation to execute first when the Kernel (Operating System) starts. Linker scripts are fairly complex so I won't document too much, take a read on the link instead.

Once it's created, go back the "GCC C Linker" tab and open the "Misc." tab and add the following text:

-T linker.ld

Linker.ld is the name of the file - above.

4/ Debugging - GDB

Now we've got a program that compiles and links with our linker script we should have an ELF program. This is an executable that'll run on the target but we might not have access to a target so we'll need a simulator.

Download GNU GDB and extract it and navigate to the path. Once there execute the following:

CC=gcc ./configure \
--enable-sim-powerpc \
--enable-sim-inline \
--disable-sim-smp \
--enable-sim-duplicate \
--enable-sum-endian=big \
--disable-sim-xor-endian \
--enable-sim-env=operating \
--disable-sim-reserved-bits \
--disable-sim-assert \
--disable-sim-trace \
--disable-sim-icache \
--target=powerpc-elf \
--prefix=/home/user/tools_ppc32 \
--disable-nls \
--with-cpu=750 \
--with-cpu=603e \
--with-cpu=7450 \
--enable-altivec \

make CC=gcc

make CC=gcc install

We now have a version of GDB that will let us simulate a PowerPC processor and execute the ELF file we've created. Of course we need to tell it what our image is and how to run the simulator.

We need two files, gdbinit and a device_tree.

gdbinit is a file that tells GDB how to start up. An example is given below:

target sim -e bug -E big -r 134217728 -f debug_ppc32\\device_tree
set architecture powerpc:750
file c:\\development\\samos\\debug_ppc32\\samos
load

This creates a simulator in PowerPC OEA mode (-e bug) in Big Endian mode with 128MB of RAM. -f Specifies the device_tree which we'll discuss later.

We set the architecture and load the file to debug.

The device_tree file contains information about the target hardware to simulate.

An example is given below:

/#address-cells 0x1

#device te cpu
/cpus/cpu@0
./cpu-nr 0

#setup the initial MSR
/openprom/init/register/msr 0x3000
/openprom/options/oea-interrupt-prefix 0x0
/openprom/options/oea-memory-size 0x8000000

#ensure we're in real mode
/options/real-mode? true

# Set up the initial stack pointer
/openprom/init/register/sp 0x51722

# define the stack type
/openprom/init/stack/stack-type "chirp"

# print out the device tree once it's loaded
/openprom/trace
/openprom/trace/print-device-tree 0x1

/chosen
/chosen/memory */memory

#
# I/O Bus
#
/iobus@0x80000000
./name psim-iobus
./reg 0x80000000 0x20000000

#
# OpenPIC
# hz == 10 ^3/ms, us = 10^6/ms
# 1Hz = 1s
# 10Hz = 100ms
# 100Hz = 10ms
# 1000Hz = 1ms
# 10000Hz = 100us
# 100000Hz = 10us
# 1000000Hz = 1us
/iobus@0x80000000/opic@0x80000000
./name interrupt-controller
./device_type open-pic
./compatible psim,open-pic
./reg 0x80000000 0x40000
./timer-frequency 1
./interrupt-ranges 0 256

# map the interrupt controller to the cpou external interrupt
/iobus/opic > intr0 int /cpus/cpu@0x0

/iobus@0xf00002F8
./name psim-iobus2
./reg 0xf00002F8 0x108
/iobus@0xf00002F8/com@0xf00002F8
./reg 0xf00002F8 8
/iobus@0xf00003F8/com@0xf00003F8
./reg 0xf00003F8 8

/nvram@0xf4008000
./reg 0xf4008000 0x8008

/eeprom@0xfff00000/reg 0xfff00000 0x80000'
/eeprom@0xfff00000/nr-sectors 8'
/eeprom@0xfff00000/sector-size 0x10000'
/eeprom@0xfff00000/byte-write-delay 1000'
/eeprom@0xfff00000/sector-start-delay 100'
/eeprom@0xfff00000/erase-delay 1000'
/eeprom@0xfff00000/manufacture-code 0x01'
/eeprom@0xfff00000/device-code 0xa4'

The format of the file is quite complex and there's little documentation on it. Lots more detail about PSIM - the PowerPC simulator can be found here.

Finally, we create a debug configuration in Eclipse. Do so for an application and set the program as the one we've linked together.

We set the "GDB Debugger" option to "powerpc-elf-gdb" and "GDB Command Line" option to "debug_ppc32\gdbinit" (depending on where you've stored the file!). We can also update the start procedure to our Kernel's entry point - the case above "__kstart".

Hopefully you can now get going!

HP Mini (2133)

2009-02-15T19:04:00.002Z

I don't usually review something because I don't often read review's. I skip to the end and read the conclusion or focus on one lil' bit. So I'll do that for the HP Mini.

What I'm using it for? Music and Coding. For music the sound is great and I hope to develop (well code - it isn't Vista) and work on the Operating System. For that Visual Studio and Eclipse are perfect - the high resolution screen - although small is fine and great infact for pictures.

So the good? Decent performance and looks and cheap. The Bad, SUSE 10 - it crashed during an update and now I've had to put XP back on there due to Recovery disks.

WASAPI and Winamp update

2009-02-15T10:01:00.003Z

Right now I'm waiting for the PortAudio guys to finish off their implementation of their WASAPI stuffs. Considering I can talk to it using the ASIO code then I'll use the same driving code (as that works).

Based on the fact that WASAPI does sample rate conversion on the hardware in exclusive mode I'd probably start out with this and then get some sample rate conversion code in there later on for people who want to use shared mode.

Samos progression

2009-02-08T16:23:00.002Z

Back from holiday and it was awesome. The operating system has a bit more structure now with working dynamic de-allocation working, thread management and the serial device driver works (well it works with PSIM anyway).

Next i'll look at porting it over to ARM and getting newlib compiled so that I can write some test applications.

Further samos work

2009-01-30T11:55:00.004Z

I'm off for 8 days of holiday but this should give me a bit of time (night train!) to work on some of the OS so that when i return hopefully I can simulate a simple PowerPC board with a single RS232 device for input and output.

So far only the RS232 device driver supports the proper architecture I'm going to use but then the only other driver I have is an RTC at the moment.

Once that, dynamic memory and the new Process Thread management code is in the API between applications and the Operating System can have some work done.

Initially the idea was to use newlib and that will still be the case. The difference is that there will be a few extra calls for device drivers so that application layer code will be able to perform reads and writes.

I have some degree of confidence that the above can be done during my Ski trip. The goal is that from here I can port the PowerPC stuff over to ARM7 or something and get a cheap eval board to get it all up and running - hopefully much like PSIM (PowerPC Simulator) has been integrated into GDB there will also be an ARM version.

PIC vs D-Type

2009-01-26T22:39:00.002Z

One of the problems with my initial hardware design for samvis is that it will require constant refreshing - much like a frame rate for a game - that will need to be driven by the software (Winamp plugin).

This would most likely sit in another thread which operates on a shared bit of memory - also used by the Winamp thread when Spectrum data is ready.

If it becomes an issue that can't be resolved by software I can see two easy ways around the issue.

1/ PIC. Use a simple 8 in 8 out PIC on the I/O board which buffers the data and sits in a tight loop (move the intensive part from software to hardware).

2/ D-Type flip flops arranged to buffer each axis.

I'd lean towards the PIC because its a single additional chip whilst I'd need multiple D-Types all with data, clocks and enables - lots of wires - not fun.

Dynamic memory and Process/Thread management

2009-01-26T22:31:00.003Z

One part of the OS that currently, but didn't, reply and dynamic memory was process and thread management. Previously, this was statically defined but with 255 processes and 255 tasks this resulted in around thread 65,000 entries. Each entry containing all the registers from context switches and some state. When linked it was around 14MB of data in the BSS section.

That's fine if you're running on a 1GB machine, much quicker and simpler than dynamic memory but if you're running on a 4MB ARM7 processor - less helpful.

This probably means that the thread and process management will have to follow suit behind the memory management. That is be broken into two models depending in the Memory Management model being used.

Typically with Embedded systems Threads and Processes are, once created, rarely created or destroyed to ensure (well it's good practice anyway). This means that dynamic memory deallocation isn't necessarily required as the chance of it being deallocated it slim and will yield small results anyway.

Therefore there will probably be two Process Management models that will be directly linked and derived from the Memory Management model.

1/ Dynamic Allocation & Dynamic De-allocation = Heap based Process Management
2/ No dynamic memory = Statically defined maximum number of processes and tasks.

To tune the memory the maximum number of threads and processes could be defined by the BSP so it was tailed to the memory requirements of the board.

Dynamic Memory

2009-01-25T22:29:00.002Z

I've been playing with dynamic memory a lot and settled on an idea.

Three models; no dynamic memory, non-de-allocatable memory and de-allocatable memory.

1) No dynamic memory would simply return zero. It would be there for systems and environments where dynamic memory isn't used. This would keep the code line count down and the complexity also. All memory would need be defined at compile time, either in the [s]bss or on the stack.

2) Non-de-allocatable memory would allow for dynamic memory allocation but it wouldn't be possible to de-allocate the memory.

3) Simple memory allocation and deallocation using the Free List method. Its kept simple for simplicity sake and to reduce the overhead.

dynamic memory [de]allocation, processes and tasks

2009-01-17T00:39:00.002Z

For the last two days I've been working on dynamic memory allocation, process and tasks.

Originally processes and tasks were all statically defined but this caused the slight issues of requiring 24MB of RAM in the bss section. Not great if you're on an ARM processor.

Normally I prefer statically defined stuff - especially as its the Kernel doing this stuff and a cock-up with memory would be bad. I moved to implement a heap and dynamic memory allocation; that's pretty easy. What's more difficult is memory deallocation.

Do I keep track of this; I.e. virtual memory and can the MMU help at all? I mean I know it has BAT registers (PowerPC) and they're all setup. I need to work out the MMU, I don't want to work out the damn MMU.

Stablility in an OS

2009-01-13T22:22:00.006Z

I've been doing some work on the Device Driver part of the OS trying to reduce the possibility of a Driver crashing the kernel. They're likely to be executed much like a normal task; they'll have to state which areas of memory they're using so the MMU can open them up. Also, it means any Interrupt (read Exception) caught whilst executing the Driver can be caught and handled.

The idea would be to stop the driver and disable it rather than the exception stopping the kernel.

I'm not sure how this'll be implemented yet as only parts are in place but it should be interesting. I guess the hardest part is the memory management - ensuring that each driver only operates on a set part of memory.

Also; the interface to the drivers should be fairly well defined. Quite how applications and device drivers will communicate is still up in the air too. It may be that in the lower levels they're enumerated and in the higher levels classed into different types so they're easier to query.

If that was the case then the lower-levels would need that classification anyway; which gives rise to the question of if it's needed.

It may be that the BSP provides an enumeration which will make it possible for a set of core device drivers to be known statically. Then also possible to load new drivers at runtime - returning an identifier so the dynamic code can access it or be found through enumeration of the device manager.

samvis decoder board design

2009-01-10T14:39:00.004Z

The initial design for the 8bit to 64 LED decoder board is complete.

The 8bit will be split into:
x0, x1, y0, y1, z0, z1, clock, enable

x0, x1, y0 and y1 will pass into 4, 74154N, 4 to 16 Demuxs (one for each layer)
z0 and z1 will pass into 2 to 4 Demux (not sure which one yet) which selects the layer.
enable sets if the LED is on/off.
clock syncs everything.

Might give it a whirl tomorrow!

samos

2009-01-07T23:29:00.000Z

The OS is coming along quite nicely; using PSIM I've been able to simulate some hardware (Serial) and have written a few drivers and the assembly to handle interrupts.

So far the thing boots up and the interrupts are handled correctly and Serial input works fine.

I'm putting it off for a while (I usually swap projects around) to go back to the samvis and WASAPI projects for a bit; mainly due to lack of hardware. I do have a G4 with PPC32 in there but its main input method is USB so I'd have to write a USB Device Driver and simple stack - I'd rather to that with at least one of the two other projects done I think.

Also considering getting a simple ARM7/9 board to create a small port for that; something with Serial, USB and Ethernet maybe just to get the core OS up and running.

WASAPI and NAudio

2009-01-07T23:24:00.000Z

I forgot to post it but I've updated the WASAPI plugin to be able to be build on either the PortAudio or NAudio libraries.

I got distracted by a few other projects but NAudio is interfacing with WASAPI much better than PortAudio was and reflects the actual WASAPI implementation quite nicely which makes reading about it a bit easier.

NAudio is also managed (C# library); I'm not sure what advantages that has from C++ but the code does look quite intuitive which is helpful.

If memory serves correctly all that is missing is a buffering mechanism (I'm sure C# offers one that can be brought into C++) to take data from Winamp and pass to NAudio.

One of the other nice things is NAudio's ability to work in either Exclusive (Winamp sound only - Hardware does sample rate conversions etc) and Shared (goes through software mixer) Mode. Obviously I'm aiming for the Exclusive Mode but some may wish to pop it back into Shared Mode when gaming.

samvis

2009-01-07T23:19:00.000Z

Yeh; started work on another project (hey - I'm single and had an insane amount of free-time over xmas!).

The idea is to create a 4x4x4 cube of LEDs that act as a Visualisation to Winamp.

Initially I've got the plugin written for a 8x1x0 array and updated that to be 4x4x4 is fairly easy (software's done really - woot!).

The next part is the hardware, using a VM110 interface card over USB at the moment and that'll drive the Cube. I'm still undecided on the hardware (Demuxs & D-types, PICs) etc but so far it's pretty promising. The plugin drives the 8 LEDs on the VM110 no problem.

Operating System (Microkernel really)

2008-12-21T11:05:00.000Z

I've started to move more towards embedded devices after using them at work for the last two and a half years; from using bare-board programs upto multi-tasked RTOS stuff. What its kinda inspired me to do is create my own Operating System, or rather Microkernel as an entire OS is a bit too big. I've been working on parts of it over the last few weeks - just trying to see what I could get out of it really.

So far it looks like creating a small, portable, Microkernel is possible. The goal is to having it running on my G4 Mac (using Gentoo rather than OSX) running on its PowerPC chip. The initial work was done for my x86 laptop but since then everything has been ported over to PowerPC.

Right now I can write and compile it on the x86 laptop and even debug it using PSIM. Right now I'm in the middle of debugging the interrupt vectors so I can handle interrupts - including the external interrupt for other device drivers and hopefully a clock for pre-emptive scheduling.

So yeh, this is taking time away from the WASAPI project (which can now be compiled to use either PortAudio or NAudio) but that's fine - most people aren't using Vista yet anyway - it'll be the introduction of Windows 7 which a lot of people move from XP that the project will become more important.

Noise

2008-12-07T18:57:00.001Z

Well audio is being generated - it isn't quite right hey...

One of the nice features of PortAudio is that it's asynchronous too so that should remove a lot of the buffering issues that the OpenAL plug-in suffered.

However - right now WASAPI doesn't work and ASIO only works (but does work!) at 48,000Hz (default for the Card).

Still it's progress...

2008-12-04T21:45:00.000Z

I'm getting really tired of the smart-arses who figured out Linux. Well done. No seriously, well done - kinda.

It's things like this that don't help though. Mac users used to be the same and now Apple are saying you should have 1 to 3 anti-virus programs on your Mac.

The same will happen with Linux as it grows in popularity and interestingly it is often NOT the technology that it the let down but infact the users. Often when a dialog pops up and the user doesn't even read it and clicks "OK" or does read it and it's a fake anti-virus program they're in trouble.

Yes - these are more targeted towards Windows users but that will change. Firefox has security holes. Safari has security holes.

I have Vista, XP and Linux installed on various machines, all for different reasons, so *please* stop trying to convert the world to Linux. Windows works and works damn well if that's what you need.

Rant over.

2008-11-30T19:31:00.000Z

I've decided to use Port Audio this time to abstract WASAPI. This also gives me the benefit that ASIO can be offered for free because that also is abstracted by the library.

It looks like Port Audio doesn't use the Exclusive mode but the source code can hopefully be modified to add it as it's just a constant change. Not sure how yet though.

2008-11-30T03:04:00.000Z

Well initially with a couple of MSDN articles I can enumerate all devices and actually get one started up in a test app. Next step is to try and get some dummy audio in there. Then try and move that over into Winamp!

Easy.

2008-11-29T13:30:00.000Z

Already WASAPI is sounding interesting.

An MSDN Article suggests that endpoint support is in there and that in exclusive mode it can be chucked right out to the hardware.

This interests me for mainly one reason - SPDIF. On my media machine it'd be nice for Vista to do nothing with the audio - just pump it straight out to the external decoder. Of course the chance of Winamp having the input for this is generally low - however some users may be using high sample rate audio (96Khz).

One other good thing is 32bit floating point support - OpenAL is limited to 16bit.

Again the downside is kinda obvious - Vista and higher only :(

WASAPI and Winamp

2008-11-29T12:17:00.001Z

Earlier this year I started work - and successfully created - an OpenAL Output Plug-in for Winamp.

See:
SourceForge Page
Winamp Plug-in Page

However I've noticed that there is another API for Windows Vista called WASAPI. I also suspect that this API will be in Windows 7 whereas OpenAL support is becoming more hit and miss these days.

Will be starting work on it this weekend. Ideally the OpenAL work would have been a good base but as this is a different architecture and the OpenAL plug-in was never designed to be properly re-usable I doubt that will work.

Stay tuned!

Theory of Bad Decisions: Weighting

2008-08-12T21:25:00.000+01:00

As mentioned in my second to last post we discussed bad decisions. Today I shall make a few notes weighting.

We could assume that each the Brain, "Heart" and Genitals have an even weighting of 1.0. This is not true. For example, Brain is generally inversely proportional to happiness.

For example - Eat cake:
B(1.0) | N
H(0.5) | Y
G(0.1) | Y

It is also very important with MBS in determining just how fudged up certain peoples decisions are.

Another good example is horny people have a higher weighting to Genitals.

Also, when making certain decisions e.g. financial decisions the other "drivers" will generally admit sure - the Brain knows more.

That is all.

My Theory of Bad Decisions

2008-08-10T13:25:00.000+01:00

Due to recent events I decided to analyse why I make bad decisions.

There are effectively 3 drivers for making a decision. Your brain (B), genitals (G) and "heart" (H). Of course "heart" is actually a part of the brain but we'll let it off. For any given decision we have the below:

Eat a cake
--------------
B | N(o)
H | Y(es)
G | U(nknown)

In this situation there is a problem, the brain knows you shouldn't eat the cake but you really want to. Your genitals don't care. Here the brain and heart will fight until one wins - aka willpower.

Hit on "Susan"
--------------
B | N
H | U
G | Y

In this situation we have the stupidity factor. If the brain is strong enough over the genitals then we're safe.

However, there is a problem. Alcohol. This effectivily shuts down your brain but to ensure that all decisions are still made it will default to a "Yes" response. Therefore:

Hit on "Susan"
--------------
B | Y
H | U
G | Y

And there you go. It can also be applied to other things done when under the influence.

Eat enough cake to be sick
--------------
B | Y
H | Y
G | U

And there you go - you're sick.

The above applies for males. For females we have the additional "Mad Bitch Syndrome" to deal with. Therefore back to the cake example:

Eat a cake
--------------
B | N
H | Y
G | U
M | U

With this extra confusion the decision becomes (apparently) much more confusing. Instead they're likely to talk about it for 3 hours and then forgot all about the cake and instead buy a hat or something. Interestingly a hat scenario is below:

Buy a lovely hat
--------------
B | Y
H | Y
G | Y
M | U

The same, one would imagine, applies to shoes also.

There are also other special cases.

For a "Chav" we invert the standard Brain response, have no "heart" and always have genitals.

Eat a cake
--------------
B | Y
H | N
G | Y

Hit on "Susan"
--------------
B | Y
H | N
G | Y(es)

This explains why "Chav" population figures (and belly sizes if we refer to the cake example) are so high and why they always seem disgruntled with each other.

In conclusion; if you're a women all decisions are influenced by MBS. The weight of this in decision making when fighting other drivers has an inverse correlation between testosterone levels.

If you're a man and consume alcohol remember to be aware of your surroundings, to survive embarrassment an emergency Red Bull of Coffee is an excellent way to bring Brain back online.

Flyer people

2008-08-07T21:48:00.000+01:00

On recent conversation led to the discussion of people who hand out flyers.

I found that it is virtually impossible not to offend these young chaps. Reason? Simple. Either you're offered whatever they're trying to get rid of and say no or take one and throw it away (they look, watch cry).

Or, they don't offer you one. I have myself been in this position and been slightly offended. Why shouldn't i have a flyer for ultra-hat-and-wiggling night at the Dark Dungeon? However, you say this to the young vendor and get one... oh and then your back to the beginning... "Hmm, yeh not for me"

Vendor cries.