The site has been largely unmaintained for a year. I've been getting interested again in the whole atari thing and I'm quite happy I didn't make the decision to sell my stuff when I lost interest a year ago. I fixed all the user accounts, deleted the spammers and deleted the spam comments. I hope to update the site more often so check back soon.

Hey guys,

Apparently my ccache build has some issues. It's not even my fault I don't think, but the command line arguments are built up with malloc and memcpy and at some point it gets a bus error with memcpy (which drills down to some asm code in the mintlib of bcopy16). I don't know what is to blame just yet but just to let you know ccache won't work properly for builds with very long commandlines, freemint being one of them!

Hello all, some more Coldfire news. The coldfire boards are in and the donations have been set in stone. The lucky recipients are Didier Mequignon of Aniplayer fame. He will be patching TOS to run on the Coldfire and will be working on Video and keyboard/mouse. This is of course of utmost importance! Alan Hourihane will be receiving one and will be working on linux video stuff which can hopefully be reworked for TOS. Olivier Landemarre will be working on MyAES, TOS and whatever else comes along. Finally we have Nicholas Steele whose generous credentials and time should yield some good Atari stuff.

Back again, and this time with an agreement from Freescale to donate a few M5484LITE development boards to our community. I'll be using one, and I'm going to try to get some other guys to take some but there'll be one or two left. The key things we'll need from someone who takes the boards are getting the USB and a PCI video card working on the device. Which means the freemint kernel will need the integrated PCI bios, and USB 2.0 high speed support in order to boot the rest of the system. All this must fit in the 4MB of flash. The systems have 64MB of DDR memory which is for the most part enough to work with GCC.

It's been a little while since I really updated anyone on anything. I have so many projects, so many things going on so what have I been working on? Well besides a super huge project at work ;), what I've been doing. Well GIM is fairly stable and has had no complaints (and perhaps no users ;) ). The new sparemint site seems to have a lot more interest and that's been consuming my time. Lately the most time has been spent on adding an automatic build system and completely revamping the package upload process. Now there's build farm functionality provided by simplistic shell scripts so other users can contribute. Make sure to read more ;)

Sparemint Dev Site: I suppose some people around here really don't know me. There's not too much to me really. I suppose there's one thing that can really sum up my complete lack of *professional* programming skills - poor planning. The sparemint site was pretty decent but due to some serious errors in the database schema things were pretty limited. An RPM package consists of the following parts. A source rpm, which when built generates one or more binary rpms. I made several assumptions in the code which were very bad. 1. The binary name will always be a derivative of the source name.

Well guys, the DB problems have been fixed... Permanently. Sorry they ever existed... I'm lazy ;)

I managed to pry myself away from Anarchy Online tonight to work on GEM. I've been getting somewhat obsessed with this online game which is probably a bad thing ;) Anyway, tonight I did 99% of the code for updating via the GUI interface. This puts the sparemint updater ready for a 0.1 release, and it'll make it functional and ready to switch the dev website to live. Pretty cool.

Maybe my life is boring, but I encountered what I feel to be a major problem. The new sparemint site is designed to be 100% community controlled, perhaps with a web administrator to handle db emergencies and such, but it's designed such that so long as a few people are around, sparemint can progress. Not to say Frank Naumann will disappear at any point in time, but I firmly believe bringing the community into the process will help to germinate a growth in MiNT. Because of this, one of the most complex parts of the website is the package upload section. The way this works is that a user will upload a package to a specific dir on the atari-source.com ftp server. Once they do, they will show up in a directory listing provided for the user when he hits "upload a package". Now just to make sure it picks the right ones, it asks the user to select his packages residing in this folder (rather than guessing). All packages have at least a source and binary rpm. Some packages have multiple binary rpm's. This creates an interesting management issue. Do you allow users to vote for whether or not individual portions of an upload are correct or the entire thing? I chose the entire thing, and as such, when a user uploads for instance curl, curl-devel and curl.src.rpm, the site has to make heads or tails of what the user is providing to it. The source is easy to figure out, but how do you figure out the "primary" binary package. Well that's easy just use "curl" .. the base name. "curl-devel" and "curl-docs" will be "child" packages. Simple enough until today. libungif has two binary packges. libungif-devel and libungif-progs. Do you see the problem? ;) No primary package was selected due to no package having the name "libungif" and hence two primary packages were shown! I decided that what will work best is to simply use the first package in a db return as the "primary" package and make any other packages dependent. The effect that making this kind of decision provides is that when a user logs in and sees packages to approve or disapprove, he will see one approve/disapprove option for "python", and it will show all the child packages "python-devel", "python-libs" etc.

Well today I worked a lot on SUM and during the last few days I've been attempting to get GCC compiled. Now a lot of people have succeeded in "compiling" the gcc 3.3x branch but as far as I know, nobody has produced a working g++ compiler. Now, we can't move on in sparemint without it in my opinion because there's almost certainly a few package in our current repository that are C++ or have C++ in them. In addition, this is a pretty basic foundational package - we can't move on without it.

Thus we're stuck with gcc 2.95.3 right now, and all we could really do is compile a sparemint for -m68020-60, however the gcc 2.95.3 optimizations for this are somewhat minimal I think.