It doesnt really matter when my PPC is still much faster at executing code (68k or PPC) than a real 68060.
Even an affordable FPGA 68k CPU core can be faster at executing integer code than a 68060. It just shows how old the 68060 design and fab process is. The most modern PPC processors blow away the original Pentium processor but we know the PPC vs x86 situation today.
With 68k code you dont save tens of MBs. You could port the latest OWB to 68k and it still would not run well with 128 MB. 68060 is still too slow to run the latest webkit engine, 128 MB is still too little to run the latest webkit engine.
With smaller memory then less memory is saved. I would add 1GB-2GB to a 68k standalone board as it is relatively cheap. The AmigaOS (mostly code) overhead must be counted in determining free memory for applications and this is substantially higher for the PPC as I have shown.
But the small footprint is just due to lack of features. Lack of Unicode support, no built-in USB stack, rudimentary GUI toolkit (unless you install MUI but then it is not small footprint anymore), lack of text antialiasing and truetype font support, simple 4 colour icons (versus true color PNG icons) i.e. it is stuck in 90s.
The AmigaOS uses shared libraries which can be dynamically loaded and flushed as needed. The AmigaOS allows many settings (preferences) which can reduce memory use. I use a 800x600x16 RTG Workbench with AmigaOS 3.9, use PFS with lots of partitions and buffers, use Peter K's icon.library which allows planar, Glow, PNG and AmigaOS 4 style icons, have a system friendly truetype engine, use MUI and ReAction GUIs, etc. but only a few MB of memory are taken at boot and I can use most of the features above together in 16-32MB of memory.
I dont see point in new super 68k but I get your idea. The PPC is obviously stuck in year 2005 forever.
A new clean 64 bit 68k like big endian CISC ISA could allow easier Amiga 68k and PPC migration while improving processor efficiency. The x86_64 ISA and processors would probably be close enough for migrating to if big endian was supported. ARMv8 is similar to PPC and bi-endian but the hardware is usually customized for customers which license and control their synthesizable FPGA code in a similar way as I have proposed for the Amiga but with a processor team developing CPU cores (instead of paying license fees to ARM). There are many advantages to this route as I have pointed out but it requires investment and quantity production.
Not sure where you get your 60 MB number from but:
3.1 plain backdrop 4 colour icons. 24 pixels square icons, really small HD at most with few disk buffers and no caching
4.1 full colour backdrop 32bit icons 64 bit square, potentially teratbytes of HD space, many more disk buffers per partition, other caching (SFS has write through caching I think FFS2 has cache hooks that may be enabled) etc etc.
For the AmigaOS 4.0 "at least 64 MB RAM" requirement, my reference was:
http://www.vesalia.de/e_amigaos4.htmMost later versions of AmigaOS 4.x are for specific hardware and do not list a minimum memory requirement. Your comparison compares a minimal AmigaOS 3.1 setup to a well equipped AmigaOS 4.1 setup. The minimum requirement mentions "200MB free hard disk space" so disk buffers aren't going to be outrageous. Can AmigaOS 4.x use 8 bit gfx without a backdrop at least? What happened to the advantages of a scalable AmigaOS with a small footprint?
According to the AmigaOS 4 developer "Cyborg", lack of FPU is a problem, they will fix it with emulation, it will be slow but they have a plan to eventually speed it up a lot with a JIT emulation. Sounds sensible. Maybe we can stop arguing now?
Emulation (and especially JIT) of FPU instructions instead of trapping should substantially improve floating point performance but it is a complex solution prone to errors. How much development time is going to be wasted by using a non-standard FPU? How much processing power and memory usage will JIT take for a low end motherboard? Limited Amiga software development would benefit from standardized and reduced hardware options but we seem to be headed in the other direction.
Listen, trollmaster...statements such as this do not contribute anything of value to this discussion. Give it a rest. Don't you have something more constructive you could be doing?
I could do some constructive Amiga work but the Amiga situation takes away my motivation.
I'd like to steer this conversation back towards reality for a moment... If someone buys a dual-core PPC32 machine and expects to be running Blender on it, well, that's just crazy. This isn't a machine for that. The recommended hardware for Blender at the moment is a 64-bit, quad-core CPU with 8GB RAM. This is not the type of hardware you would EVER seriously consider running Blender on.
Let's get back to reality then and remember that AmigaOS 4 only supports one CPU core and can't take advantage of 64 bit addressing without breaking Amiga compatibility. I guess you should tell Andy to forget his AmigaOS port of Blender then.
