And this is what I've come up with:

http://www.coderscauldron.com/pub/misc/fred.zip

It's very very very simple at the moment, and the reason that I'm releasing it in this state is because it doesn't want to work with the shared C library. Full details and stuff are included in the .zip - any help would be appreciated

Seriously, if you don't do anything then you won't learn. With me games were a great way of learning to program, but modern games are now more complex and I'm older too and so expect more from a game. This means it may be a bit too late for you to learn to program by writing games for yourself

Have a shot at writing a simple platformer or something, and aim to have all of the code written by you - i.e. not relying on other peoples sprite plotters.

Practice makes perfect.

*smiles into mirror next to computer*

Well what do you expect if you go to uni to do a computer course and then don't learn anything?

A fair enough point. I was mainly using my lack of knowledge to fawn over your coding skills rather than complain about the lack of my own I've got ideas... but thanks for the tips.

Good. Glad to help

Have a shot at writing a simple platformer or something, and aim to have all of the code written by you - i.e. not relying on other peoples sprite plotters.

Sorry Jeff I don't agree with this one little bit.

IMHO it's far better to take a project that will be managable and that you will learn one or two new things from, and learn them well. Then make use of every reusable library you can laid your mits on to make the learning process easier.

Practice makes perfect.

Absolutely.

BTW about pre-emptive multithreading. Maybe you'd like to try and get your head around Martin Piper's library for Unixlib. It's in a TBAFS archive at rozilla.com. It seems to work but is lacking any kind of thread synchronisation primitives. I personally don't have the necessary knowledge about RISC OS' internals to take something like that on myself.

Um, expect some more fred stuff tomorrow. has requested some more detailed info on how it works for newbie-ish assembler/C type people, so that'll be occupying me most of tonight. I'll check the PRMs for the hardware vector stuff though.

Maybe this isn't quite the tomorrow I had in mind

I've uploaded some info on how APCS/Fred works to http://www.coderscauldron.com/pub/misc/fredinfo.html It's a bit of a rush job, but it should be OK.

About the hardware vector stuff: It does look like I should be able to write my own code to replace the standard interrupt handler and catch on to the Fred specific ones. However, Acorn neglected to include a SWI to find the address of the IOC data in memory - despite the fact the PRM states to use SWIs and things to read/write the data instead of accessing the memory directly I'll have a poke around and see what I can come up with.

BTW about pre-emptive multithreading. Maybe you'd like to try and get your head around Martin Piper's library for Unixlib. It's in a TBAFS archive at rozilla.com. It seems to work but is lacking any kind of thread synchronisation primitives. I personally don't have the necessary knowledge about RISC OS' internals to take something like that on myself.

Thanks - I'll have a look for that.

[Edited by Phlamethrower at 19:26, 28/5/2002]

(Should really be on Coder's Cauldron, but TIB's firewall seems to have blocked me )

(Should really be on Coder's Cauldron, but TIB's firewall seems to have blocked me )

Er, no. How would you be able to get into one site and not the other, seeing as they're on the same server?

Using a cunning file upload script built into ROIW, so I don't have to give the FTP details to anyone I don't have to

Anyway, it's up on CC now (Changed the link to point to the right place too). I'll sort out some proper web pages & stuff on CC some time soon.

I've just remembered an idea I had for the preemptive multithreading - A combination of my own interrupt handler and a standard callback.

The callback (Registered via OS_CallAfter/CallEvery) would set a flag in memory saying 'Switch threads at the next possible moment'. The custom interrupt handler (Which gets called before RISC OS's one) would then check that flag, so it can pick up ASAP whenever a thread needs switching. Ideally I could just call OS_ReadMonotonicTime in the custom handler, but calling a SWI for every interrupt could be a bit slow.

Also I've thought of a pitfall to avoid: The thread switch must only occur if the processor was in USR mode, to avoid thread switching in the middle of a SWI (which would crash the computer due to stack confusions and things). This means that the custom handler must ignore the 'switch threads' flag for as long as needed until the processor re-enters USR mode. Exactly how much time passes between the switch request and the actual switch may be large or small, I have no idea - if it turns out to be quite large (i.e. more than a centisecond) then I may have to look for another way.

I think that's all the problems that need taking care of (Apart from the shared C library)... the next question will be the implementation. For now I think I'll stick with the AOF version, but I'll probably have to move to a module version at some point to make sure it works OK in the WIMP.

I'll try and get some code done this week - exams are looming

Been working on a version which makes a big step towards pre-emptive multithreading, by storing every single register. Except that it locks up the computer at the moment... I think the registers stored are OK, but I can't seem to get them to load back in....