I've been told that the earlier, grittier StuChats were more enjoyable than the later more organised ones. So, not being one to treat criticism with contempt, this one is about as disorganised as I can manage :-) It's been hacked together over the last few days - normally whilst waiting for some silicon based process to end - please excuse the disjointed (and sometimes out of date) nature...
3rd January 1997.
Happy New Year!
So, what's been happening? Well I've been working predominantly on Eddie for the 4.16 release due any day now. It's been through at least three beta releases, two internal and is on the final internal release before going for the final beta.
To be honest, for the last three months ALL I've been working on is Eddie whilst Rob has been "compilering". To say I've had enough of it would not be an overstatement.
My (self imposed) brief for the last half of the year was to get "the front end" as sorted as possible. This doesn't just mean producing code that runs correctly, but code that is modular, well documented and easily maintainable.
For the 416 release, there have been very few changes to Fantasm - just some bits to make mixed ISA working easier, and a few minor bugettes stomped.
So, lets rewind back a few months and see what we did. I remember the first task (as it was the most griped about feature) was to provide normal Mac caret movement. This was a relatively quick task, seeing as the code had been written long before - so just cut , paste and test - no probs.
Next was fix all the reported bugs which didn't take long at all, then searched out many unreported bugs. Finally after the bugs had been killed I got round to adding the final feature set for Eddie as we know it. I had no idea of what features were needed - just added as I went along :-)
By far the wackiest feature is the CD random play mode - this seems to have a mind of it's own. I started off by reading the audio CD database - tracks can be shuffled by most audio CD players and the current shuffled play list is stored in a resource in the database. This was OK, but terrifically boring. So ditched that and went for a complete random play generated from QD's random call. Now the weird thing is that it does have code to prevent the same track playing twice - it still sometimes does it.
You can't just ask the CD player to play "random" - you have to hand hold it every step of the way. And then there are the incompatibilities between drivers - heck some third party drives don't even accept the SCSI Eject command, and yet throw no error. How am I supposed to get round that? I decided the best option was just to stick to Apple's driver (currently 5.1.7 I think) and program to that.
The other niceties include:
Most operations that involve searching now highlight the target when found. Highlighting is outlined when Eddie is not the FG app. Added a Save all changed files command. Eddie can now open files from locked volumes - i.e. CD's. When creating a new file the user has the option of having the version control box pop up, and then that data being pasted into the start of the file as a commented out header. Completely rewrote the memory manager. The status display is now much prettied up and is controlled much better, and the general visual interface is now a lot neater - for example, when resized, windows no longer completely redraw unless they really must.
(TIP here - the status line now dynamically calculates three colours from the current window background colour. The maths was calculated to be spot on when using the BG colour from the colour set "A good one 256". Hence if you use this colour set there are no palette translations to be calculated and Eddie runs just a smidge faster :-)) Err, only when in an indexed colour mode obviously - 256 colours or below.
All window positions are saved, and dynamically cropped to the monitor size when reopened. Changed the gopping default installation colours to something more sensible. Some minor changes for Un*x files and such like - no EOF character is ever tagged on. (This follows what must be one of the longest "discussions" in the history of computer program design - do Un*x editors need an EOF or not??) Improved bookmark operation and word select logic.
Now handles bad disk insert events. Mouse cursor is now hidden whilst typing. Added a new "special" menu containing such commands as reboot machine, quit finder etc.
Unfortunately time beat us on a lot of things - for example multiple multi file searches have been removed as it's just not tested. My hope is that there are very few bugs in this release. I've had to remove all the native code as there was a really obscure bug causing crashes that nobody could pinpoint which is very annoying - but that's life.
Sometimes it's best to let these things simmer in the background.
My biggest gripe came about from the Special menu - to safely shutdown ones Mac you send an Apple Event to the Finder. Now, Inside Mac says to create the descriptor for the Finder from it's signature, given as "FNDR". This simply does not work. First I wrote the Apple event sender code - didn't work - kept coming back with an Connection Invalid error. So I tried the high level event approach - exactly the same error. So now I'm reduced to writing a client/server pair of apps and it works fine!?! So I think that the only thing it can be is the Finder's signature is wrong - yup. "MACS" works just fine. I really wouldn't mind but that was at least 6 hours solid work which should have been just ten minutes.
So. I've just finished the last "addition" - I thought that if we can quit the Finder from Eddie, then we should really have a way of launching apps as well. As it turns out, quitting the Finder is quite a handy little feature, 'specially if you get a global memory error from Fantasm. Simply quit Fantasm, then quit the Finder, and you have 500k more system memory for the next Build.
What I do have is a huge list of stuff for V5 - so many things that are already done but hidden. You'll notice this version of Eddie uses a new preferences file - this is to hold all the project stuff in. There was really no need to put them in this version, but I thought it gets it out of the way.
I'm really hoping this is the last ever version of "Eddie" - what the next front end will be called I don't know - probably something really exciting like "Lightsoft Project Manager" - I don't think so! :-) I am really looking forward to the back end work. We have lots of code to plug in - indeed I'm really looking forward to Fant5 - just having linker errors tracked to the source will be wonderful. Having the project manager in the front end will be wonderful. Having free form and transportable projects will be most useful. Having a faster back end will be my dream come true. Having an Eddie that works isn't too bad either :-)
Well, I'm completely cream crackered. What with all the socialising this week it's been difficult finding time to actually code. I should be in bed. I'll add some more stuff later today...
Well, this then is the big day. Yes, tonight I'm attempting to download MkLinux DR2 through my trusty old MultiTech modem. Currently I'm 3 megabytes into the 78 Meg download and am getting 3k a second. Now assuming British Telecom can actually hold the line together for the next few hours I estimate I have about seven hours left - eek. I mean, it's not as if I can go "surfing" with Netscape 'cause I need this box to stay crash proofed for the download.
What am I going to do for the rest of the night? Well, I trust Eddie to remain stable, so I can carry on with this piece...
416 was sent out for a final test yesterday, which makes me happy. It's nice to actually finish something. IMHO Eddie should be revved to version 2, but that wouldn't make much sense so it goes out simply as 1.6. Hopefully 416 (both versions) should be published this week as simple updaters to 415. I guess the best way to view it is simply as a polished 415.
V5
Well, a lot of discussion has taken place about v5. Interestingly V5 is a mix of 68k assembly language, PPC assembly language and C. We hope to get Fanta_C running at least well enough to write some of the shell with. You may ask why don't we just use CodeWarrior or Symantec? The answer is simply that we find them too slow, the debuggers are not particularly good and I'm not terribly impressed with the code produced by any of them. Besides, none of them support "easy" PPC assembly language creation.
Having said that, some of the actual C compiler is written in C, but then that's built under Borland on a Wintel box.
Much of our discussion on V5 has centred around the project management. We've finally settled on "free form" projects; that is you don't need a specified project "tree" or hierarchical structure to the files that make up said project. For example you're standard headers may reside on a "server" somewhere on the network under control of a supervisor.
This does not mean you can't use a standard "tree" layout, and indeed, if you intended "mailing" the project somewhere else, it would be the best way of organising it.
For V5, the CD menu disappears out of the front end, to be replaced with a nice pop up CD controller. The back end becomes a plug in tool. The project manager and build move to the front end. The front end provides all I/O services which is a nice abstraction that really helps seeing as OS's are changing more rapidly than a really rapidly changing thing.
As a Mac user, I must admit, I am really peeved at Apple from their most recent PR. It looks to me as if the first release of the "new" OS isn't going to be very Macish at all. I like the way my Mac looks. I don't want it looking like an old NeXT box! All I really want is System 7 with the nice modern features. As a developer we knew that it was to "all change" pretty soon, but I really didn't think it would be such a dramatic change!
Currently, I'm seriously thinking about a new Mac - I really, really like the 7600. The way Apple is currently speaking, I'm not so sure and way deep down inside, a little bit of me is saying "convert to something else before it's too late.". Don't worry, it won't happen, but I do know that most of our stuff is so well abstracted now, that the conversion to another format would not be such a dramatic step as it once would have been. For example, take Eddie 1.6 - change it's name to Finder, change the type and creator to FNDR and MACS and throw it in your System folder as the Finder - tadaah - one mini Finder. That's right, it contains enough bits to run you're Mac from (in a limited capacity obviously). It needs a file system, a windows and menu driver and very little else.
Anyway, the point is, I hope Apple get it sorted and that the "New" OS really does look like it's a Mac O.S. when released and not something completely different. If I wanted a completely different O.S. I'd go buy Wintel now.
But then again, maybe not. I hate Windoze, I spit on 80x86, and they can't go on for ever with that architecture surely? I have a 486dx80 - it's not used - well it is, it's on the Ethernet for backups - we put frozen releases on it. It runs win3.11 and it's horrible. Windows '95 is horrible. I like Mac. I liked ST's and I sort of liked Workbench (on the Ameaba). I simply do not like DOS boxes. I like PowerPC's and Macs.
13 Megs...
Actually I just tried a little test - I unzipped a 4 Meg file on the P.C. and then I did the same on this Mac (yes, whilst it's downloading) and although the P.C. is running at 80 Mhz (this is a 7200/75) it took three times as long to unzip the file. Good.
Well, MkLinux downloaded just fine, as did all the other bits. Took nearly eight hours but it was well worth it. I must admit it came as a bit of a shock being faced with a real operating system again. Having said that, it is truly a very powerful and nice system. Or at least it will be when I find fvwm for X.
Today I have been sorting out the final build of PowerFantasm for the 416 release. just a few very minor changes were necessary after the final test. The only change worthy of note is the ability to cancel long multi file search, which really wasn't a change; just enabling a flag.
Ok, so Linux hacked together just fine, TkDesk, fvwm and xlock :-) = happiness. It's great that Apple are doing this. If for nothing else, it shows my daughter, Jessica, how to use a "real" operating system. And it's fast too.
I now see that Apple have stated that the new OS will be a Macintosh OS after all, and there's really no need to panic. Cool. Stu is happy again.
Today, or yesterday, I started work at 10 P.M. and it's now 00:30 some twenty six and a half hours later - over worked and underpaid is not the expression.
Earlier today I was faced with a real harsh decision - 7600 or not? Today was the day. After about 5 minutes consideration I decided not; this 7200 is less than 18 months old. Instead I went out and got 512k of cache (yes, the third one in 9 months - lost two, literally, but I don't want to talk about that) and 16 Mbyte of R.A.M. Good decision. Firstly I'm lots of money better off, and secondly the 7200 is really flying now! The difference is staggering. O.K., so I'm using a third party "speed" emulator as well, but it has cut complete rebuild times in half! Even with the MOD player at 44 KHz builds are still some 20% faster than they were with no MOD player previously.
A complete Eddie rebuild now takes 80 seconds compared with the previous 145. Unfortunately I'm down to about 30 Megs of free on-line storage, but that's because MkLinux is temporarily hogging loads of space waiting for Rob's HD at the weekend (we need the PPP server in Birmingham).
Also today I built and froze Fantasm68k 4.16. It was a little weird in that we didn't actually have a Fantasm 415 to create the 416 patch from! This was because Fantasm68k stopped selling ages ago, and we decided we'd only create a package if someone actually ordered it - no one did. So, I had to get the 415 source off the PC, build it and then create the updater from this! Please God, no more 68k builds?!?
Hopefully tomorrow I'll be able to actually get on with some V5 stuff - suitably abstracted for possible future Apple wavering! We've actually decided that we can vector (for plug ins) some front end server/client routines as we'll probably state a vary fast 030 for V5. I mean, Elsie (LCII) complains badly if I change a branch to a long branch. Fair enough, it's a 16MHz 030 which is fine, but I don't think we can get V5 running suitably fast on such hardware - it'll run, but not as fast as on a Power Mac which will be running native code.
I am so looking forward to getting on with it - the number of ideas we've floated about in the last year (internally) are very exciting from a speed point of view. I have the code just waiting to paste in. I wasn't willing to really start on it until we got the 416 release out of the way. I can't handle two entirely different code sets at the same time. I mean that Fantasm really gets ripped apart for this one - not the actual assemblers, but all the surrounding stuff
Right, the last thing I'm going to do before falling off this chair is paste this up.
So, till the next time...
Code on!
Stu.