Thread
my vision for 68k/ early ppc macs
There's actually a lot of point in developing Classilla - any Mac running OS 9 these days could be called "classic", hell Apple even calls the Mac OS 9 environment in OS X "Classic". Classilla is the first web browser to developed in the past 5 years that supports any OS 9 system at all.
Actually, iCab 3.0 was released for Mac OS 8.6 and up within the past couple of years. This version greatly improved the renderer.
Unfortunately, with iCab 4.0, the unique iCab renderer was dropped in favor of WebKit.
Unfortunately, with iCab 4.0, the unique iCab renderer was dropped in favor of WebKit.
If only there was a better browser for 68k than Netscape 3/4, IE 3/4. and iCab 2…
It will probably never happen though.
It will probably never happen though.
You never know, someone may very well program one sometime (if any programmers are thinking of RetroChallenge ideas, here's one for you). After all, who would have expected Classilla to be released many years after Apple stopped selling Macs that boot into OS 9?
There is work on a 68k port of Haiku in the works, http://www.haiku-os.org/blog/mmu_man/2008-07-21/getting_to_the_kernel_68k_way .
I think some kind of NeXT like environment for 68k Macs would be really cool. I wouldn't know where to start. A long time ago when I looked at the source code for early Darwin before version 1, there were still alot of code references to 68k and I486.
As for as newer browsers and other software, if Atari and Amiga users can do it then we should be able to port it without having to write it from scratch. maybe we are spoiled as Mac users where as they have to keep going or they loose there entire platform.
I think some kind of NeXT like environment for 68k Macs would be really cool. I wouldn't know where to start. A long time ago when I looked at the source code for early Darwin before version 1, there were still alot of code references to 68k and I486.
As for as newer browsers and other software, if Atari and Amiga users can do it then we should be able to port it without having to write it from scratch. maybe we are spoiled as Mac users where as they have to keep going or they loose there entire platform.
I know it was posted on page 1 of the thread, but if had the cash, I would totally buy this.
Hard to believe they still want actual money for it.
They want USD, so it's not real money.
This bit is even better:
And installing Mac OS X on a G3/G4/G5/Intel Mac doesn't? :lol:
MachTen predates OS X by quite a bit.
I realise that, but you'd think they'd update the page...especially if they still want to make an impression that they're still in business.
How come it looks exactly like Nextstep??
I think one of the problems with 68K browsers now is that modern webpages are just too demanding of the computer.
Take a look at an average bank website, for instance. You will find the following features used:
- SSL/TLS
- JavaScript
- CSS
- Dynamic HTML (combination of JavaScript and CSS)
- AJAX (combination of JavaScript, CSS, and XMLhttpRequest)
We already have SSL on 68K, so that's not a big problem as long as sites continue to support SSL 3.
The next problem is interpreted JavaScript. Sites use thousands of lines of JavaScript now and interpreting this is slow.
CSS is another problem. Such things as: translucency, dynamically resizing boxes, etc. It requires thousands of inter-dependent calculations to lay out a page.
Basically - more and more work is slowly being shifted to the browser. Imagine a bank website in 1997:
- Basic HTML 3.2 or 4.0 design. Perhaps a simple table based layout. Complex text, etc. is probably loaded in as a GIF image.
- Basic SSL v2 40-bit may have been used.
- No JavaScript. The login form is sent to the server as-is. The server must determine if enough characters were entered, etc.
- You see your online check book and want to view more information about a transaction. You click the transaction and the server sends an entirely new page.
- You want to add a note to a transaction. Clicking add note loads an entirely new page using target _blank. Seeing the note in the transaction requires refreshing the entire page.
Compare to the modern bank site:
- XHTML 1.1 with CSS2. No tables used in the design. The appearance may even be similar to or the same as the 1997 version, but it's much harder to render due to the used of CSS.
- Banks have disabled 40-bit and SSL v2 for security reasons. Minimum is now 128-bit SSL v3 or TLS.
- Heavy JavaScript used. Pre-validate all forms on the entire site.
- Transaction information is shown in-line using a hidden CSS box and AJAX to retrieve the information.
- Adding notes is done with AJAX.
Take a look at an average bank website, for instance. You will find the following features used:
- SSL/TLS
- JavaScript
- CSS
- Dynamic HTML (combination of JavaScript and CSS)
- AJAX (combination of JavaScript, CSS, and XMLhttpRequest)
We already have SSL on 68K, so that's not a big problem as long as sites continue to support SSL 3.
The next problem is interpreted JavaScript. Sites use thousands of lines of JavaScript now and interpreting this is slow.
CSS is another problem. Such things as: translucency, dynamically resizing boxes, etc. It requires thousands of inter-dependent calculations to lay out a page.
Basically - more and more work is slowly being shifted to the browser. Imagine a bank website in 1997:
- Basic HTML 3.2 or 4.0 design. Perhaps a simple table based layout. Complex text, etc. is probably loaded in as a GIF image.
- Basic SSL v2 40-bit may have been used.
- No JavaScript. The login form is sent to the server as-is. The server must determine if enough characters were entered, etc.
- You see your online check book and want to view more information about a transaction. You click the transaction and the server sends an entirely new page.
- You want to add a note to a transaction. Clicking add note loads an entirely new page using target _blank. Seeing the note in the transaction requires refreshing the entire page.
Compare to the modern bank site:
- XHTML 1.1 with CSS2. No tables used in the design. The appearance may even be similar to or the same as the 1997 version, but it's much harder to render due to the used of CSS.
- Banks have disabled 40-bit and SSL v2 for security reasons. Minimum is now 128-bit SSL v3 or TLS.
- Heavy JavaScript used. Pre-validate all forms on the entire site.
- Transaction information is shown in-line using a hidden CSS box and AJAX to retrieve the information.
- Adding notes is done with AJAX.
That's why we need a server that parses all the big-bad stuff and outputs the html to our macs. Don't they have something like that?
Alas, a responsive *nix GUI on a 68K Mac is an unlikely proposition. Mac graphics cards are designed to display QuickDraw and have drivers (in ROM or INIT) that accelerate QD. 68K Macs have used literally dozens of graphics processors, most of which are proprietary. The NeXT family have graphics interfaces and drivers that optimise Display PostScript. PowerMacs sometimes get reasonable X11 graphics, but only if they the right graphics card.
A modern X11 Server for 68K and low power PPC Macs, that uses all of the wonderful goodness of classic Mac OS, makes more sense to me.
Is some kind of Quickdraw wrapper out of the question?
Probably not, but whether anyone is going to code it is questionable.
As for NouveAUX or whatever it is, let's make it.
As for NouveAUX or whatever it is, let's make it.
I don't know about designing apps but I could write a 68K Mac website with news and downloads.
I have NetBSD running on one of my SE/30's. Here is a page with pictures of it from a number of years back:
http://sasteven.multics.org/MacSE30/MacSE30.html
The 68K port of NetBSD is alive, if not very active.
I put a current copy of NetBSD on one of the slot-loading G3 iMacs I bought a few weeks ago. It's nice, with a modern browser, etc.
http://sasteven.multics.org/MacSE30/MacSE30.html
The 68K port of NetBSD is alive, if not very active.
I put a current copy of NetBSD on one of the slot-loading G3 iMacs I bought a few weeks ago. It's nice, with a modern browser, etc.
that almost brought a tear to my eye
please do make a new post with all the juicy details
please do make a new post with all the juicy details
NetBSD on m68k Macs is doing quite well. Lots of people use it, it works on most m68k Macs (I'm hard pressed to think of any on which it doesn't work), and I, for one, run it on lots of Macs. We even have a distribution which works on Macs with FPU-less LC040 processors with broken trap handling, so all of those machines which until now couldn't run any Unix (A/UX or free) can now run NetBSD just fine.
It's not going away any time soon. Aside from the compiler tools, it's actually gotten faster over time - NetBSD 5 is definitely noticeably faster than NetBSD 4. The compiler is a different story - for obvious reasons, it gets bigger and slower because of the new features and optimizations possible. But if you spend most of your time running stuff and not much compiling it, it's nothing to worry about.
It's not going away any time soon. Aside from the compiler tools, it's actually gotten faster over time - NetBSD 5 is definitely noticeably faster than NetBSD 4. The compiler is a different story - for obvious reasons, it gets bigger and slower because of the new features and optimizations possible. But if you spend most of your time running stuff and not much compiling it, it's nothing to worry about.
I have two NetBSD 68Ks, a IIci and a Q605 (with a full '040). They have uptime that is so long that the only time I reboot the IIci, which is the apartment DNS and print server, is when it chews through a cache card (it seems to blow every three years -- this system has been running since 2000).
This is exactly an example of the strong points of Unix on m68k Macs or Macs in general - good quality hardware will run forever.
NetBSD is actively developed, and if people here know details about QuickDraw accelerating NuBus video cards, then X under NetBSD can be accelerated using whatever hardware acceleration is available. It's been added for all sorts of other obscure hardware including video cards for VAXen, so why not NuBus video cards?
One of the reasons that X on m68k NeXT machines was so fast was that those machines had hardware acceleration as well as hardware-based PostScript rendering, which was pretty cool. The philosophy was correct - push more work to hardware designed to do it and free up the main CPU for other things, not too unlike OpenCL nowadays. It just goes to show how long it takes for good ideas to get widespread acceptance sometimes.
In any case, if anyone is interested in getting NetBSD running on any of their machines, I'd be glad to help, particularly for anyone who'd like to get some use out of an LC040 system.
NetBSD is actively developed, and if people here know details about QuickDraw accelerating NuBus video cards, then X under NetBSD can be accelerated using whatever hardware acceleration is available. It's been added for all sorts of other obscure hardware including video cards for VAXen, so why not NuBus video cards?
One of the reasons that X on m68k NeXT machines was so fast was that those machines had hardware acceleration as well as hardware-based PostScript rendering, which was pretty cool. The philosophy was correct - push more work to hardware designed to do it and free up the main CPU for other things, not too unlike OpenCL nowadays. It just goes to show how long it takes for good ideas to get widespread acceptance sometimes.
In any case, if anyone is interested in getting NetBSD running on any of their machines, I'd be glad to help, particularly for anyone who'd like to get some use out of an LC040 system.
Just need to get the "real" X server working on mac68k, instead of the old 1-bit or OSFA color ones we have now. IIRC, there was a spurt of work last(?) year with the mac68k framebuffer that looked promising. Dunno what happened with that.
I currently don't have any 68k NB boxes (with the AV SCSI issues, I retired my Q840), but as soon as I get my CC operational again, that's what I'll be running on it.
Yeah, one of these weekends, when I have the whole weekend with nothing to do, I'm going to put NetBSD on both my quad-socket, 16-thread Itanium server, and on my SE/30 that sits on top of it. Then I'll have the SE/30 acting as the X server for apps running on the Itanium, MUAHAHAHA!
(I also need to get a good piece of serial terminal software for the Apple II so I can use my Apple IIc as a serial terminal for the server.)
(I also need to get a good piece of serial terminal software for the Apple II so I can use my Apple IIc as a serial terminal for the server.)
yea i need opinions on that as well, eventho i guess anything would work but im a now proud owner of a //c i got from tmtomh, anyway need to pop into the apple 2 forum and see if theres any threads about this and see whats out there
Back on the new/old OS idea: Usual disclaimers apply, I am not a coder, pie in the sky, etc. But how about this for older 68ks?
Take MachTEN's design approach. Make the "new" OS a virtual machine: a process that seizes the CPU from the co-operatively multitasking Mac OS/System software, and runs pre-emptively and with memory protection within itself. All screen drawing and other peripheral device handling is dumped back to the OS/Quickdraw, saving having to write new drivers for everything, and allowing native video acceleration, etc. Once the peripheral task is completed, the CPU is handed back to the VM. So System 6 (for example) acts as the "kernel".
eCos would be a possible candidate, whether using the above approach or running natively. (Yes, I have brought this up elsewhere. Pardon the cross-post; I couldn't find this thread at the time). For starters, there's already a 68k port, albeit for later embedded 68ks, and it is currently developed, supported, and deployed. Given the memory requirements, perhaps (disclaimer above) it could even run on a 128k.
http://en.wikipedia.org/wiki/ECos
The only M68k port I can find is for the Coldfire. As I understand it from others' comments here, the Coldfire ISA is a subset of that for 680x0s, so my very rough guess is that a backport would be feasible. To run natively, I guess there would be a lot of custom coding involved to get peripheral device support (ethernet, serial, video, SCSI etc)
Take MachTEN's design approach. Make the "new" OS a virtual machine: a process that seizes the CPU from the co-operatively multitasking Mac OS/System software, and runs pre-emptively and with memory protection within itself. All screen drawing and other peripheral device handling is dumped back to the OS/Quickdraw, saving having to write new drivers for everything, and allowing native video acceleration, etc. Once the peripheral task is completed, the CPU is handed back to the VM. So System 6 (for example) acts as the "kernel".
eCos would be a possible candidate, whether using the above approach or running natively. (Yes, I have brought this up elsewhere. Pardon the cross-post; I couldn't find this thread at the time). For starters, there's already a 68k port, albeit for later embedded 68ks, and it is currently developed, supported, and deployed. Given the memory requirements, perhaps (disclaimer above) it could even run on a 128k.
http://en.wikipedia.org/wiki/ECos
eCos Porting Guide
The only M68k port I can find is for the Coldfire. As I understand it from others' comments here, the Coldfire ISA is a subset of that for 680x0s, so my very rough guess is that a backport would be feasible. To run natively, I guess there would be a lot of custom coding involved to get peripheral device support (ethernet, serial, video, SCSI etc)
The original 68k Palms were actually Coldfire CPUs. They were programmed with CodeWarrior. If you look at the internals of PalmOS you can see it's Macintosh heritage.