@pixie

Workbench f.e. uses Blitter whereas Wanderer is bujild up pixel by pixel. Try a different desktop like Magellan. Or Scalos perhaps. But I only use it on UAE or perhaps in future on Apollo V4 or Pistorm. Original hardware with just 68ß20 is no realistic option.

@Hypex

Set Path "`Echo $Drawer`"?

What is that strange? You set a local variable named path?

I just tested my requestfile

RequestFile >env:drawer DRAWERSONLY did nothing

RequestFile env:drawer DRAWERSONLY opened a requester. Do I understand something wrong?

Last edited by OlafS25 on 26-Apr-2024 at 05:22 PM.

@jPV

Done some tests confirming what I reported, the problem "output.txt" empty, as I had suspected is the fault of LHA native AROS version.

I tried running the command c:lha *>ram:output.txt on "AROS 68k" with two LHA versions, one Native and one AmigaOS

LHA (Native AROS) -> Generate output.txt "Empty"

LHA (Native Amiga v22) -> Generates output.txt "output Corrected "


EDIT:

Done other test on AROS x86 with This version of LHA, output.txt is saved correctly !

Last edited by AMIGASYSTEM on 26-Apr-2024 at 05:58 PM.
Last edited by AMIGASYSTEM on 26-Apr-2024 at 05:38 PM.

_________________
AROS One Home Site
AfA One Amiga OS 3.9

@Hypex

Quote:

Where someone also commented that RISC is inside CISC. The beat goes on.

yep, that’s another misconception, micro-opcode, is not a full RISC instruction, its tiny part of a instruction.

Quote:

And also, x86 is already dead

more precisely its emulated on top of x64 design. We should not be talking about x86, or Intel of the yesteryears, it’s not really relevant, “movbe� got me think about when did x64 designs became the norm.

Last edited by NutsAboutAmiga on 26-Apr-2024 at 09:12 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@OlafS25

AROS:
AGA-NOT-THEMED-JIT | AGA-NOT-THEMED-NO-JIT | RTG-NOT-THEMED-JIT | RTG-NOT-THEMED-NO-JIT
AGA-THEMED-JIT | AGA-THEMED-NO-JIT | RTG-THEMED-JIT | RTG-THEMED-NO-JIT

AMIGAOS
AOS-NOT-THEMED-JIT | AOS-NOT-THEMED-NO-JIT
SYSINFO-JIT | SYSINFO-NOJIT


UPDATED:
I forgot to do on AmigaOS RTG, the PNG appear correctly and they are snappy af, even when no JIT. This system is not the best, but my main one who had no problem with the icons render didn't had mouse wheel working. So normally the icons don't render black on AGA but speed wise it's the same.

AROS VISION
RTG-DOPUS5-NO-JIT
RTG-DOPUS5-JIT

@Video Folder

Indeed it seems way faster, even double the resolution.
But since AROS is using RTG why does it do pixel by pixel?

Last edited by pixie on 26-Apr-2024 at 07:10 PM.
Last edited by pixie on 26-Apr-2024 at 06:57 PM.
Last edited by pixie on 26-Apr-2024 at 06:54 PM.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

agami Quote:

I hope you're not referring to me. I don't wish that Jay Miner chose the 286, I was more just wondering since the essentials of the Amiga is more in the OS & custom chips than it is in the CPU, could the A1000 not be achievable with another 16-bit CPU, such as the 286 (were it available in the same time-frame) or the Z8010.

When the Amiga was developed, there really weren't many good choices for a CPU that would allow the Amiga to be as dynamic and expandable as Jay Miner wanted. There was only the 68000 and 32016 that were dynamic enough and it comes down to addressing which I hinted at earlier and I'll explain more below. Microprocessors were single chip CPUs which integration and mass production allowed to become cheaper than many components of earlier processors. However, there was very limited silicon space at first so early microprocessors were accumulator architectures which use the least amount of silicon. As more silicon space became available, CISC CPUs were introduced with larger and more complex cores but they reduce the number of executed instructions, minimized code size, reduce memory traffic and have more registers which increases performance and saves memory (as well as caches). RISC CPUs were being developed in California universities in 1980-1985 and early commercial implementations starting arriving to market in 1985-1990 so they were too late for the Amiga. They had easy to develop, simple and small CPU cores with the silicon savings usable for larger integer datatype sizes like 32 bit (inferior RISC performance traits vs CISC would be compensated for with pipelining, caches and higher clock speeds). The MC68k and NS32k were the CISC architectures that laid the foundation of a highly orthogonal architecture with flat 32 bit address space that became so popular for RISC CPUs. Modern so called RISC architectures have abandoned many RISC philosophies and have adopted many CISC like features leaving practically only load/store memory accesses as the distinguishing feature. It's too bad that good CISC architectures like the 68k and 32k were abandoned as being too complex and not RISC enough when RISC later moved closer to them than the original "classic" RISC that was very simple and weak performance as a result.

Addressing and address spaces are very important to understand in regard to the dynamic Amiga. Today, 64 bit computers have taken over for high performance CPUs even though 64 bit pointers are slower and waste large amounts of cache and memory. There was a minimal performance gain for general purpose data manipulation with 64 bit datatype sizes so the push to 64 bit CPUs was almost entirely for a larger flat address space (flat meaning linear continuous addresses). There were memory paging extensions used before 64 bit addresses like x86 PAE, ARM LPAE and whatever the PPC version is called that is used in AmigaOS 4 called ExtMem.

https://blog.hyperion-entertainment.com/breaking-the-memory-barrier-2/ Quote:

Downsides of the ExtMem system If you think now that this all sounds suspiciously like bank switching, then you are right. The method has been used way back in the Home computer age, and even earlier. The Sinclair ZX Spectrum 128K was equipped with twice as much memory as the Z80 CPU could address; the upper 16k of the machine could be swapped between different chunks of the rest of the memory. Similarly, the Commodore 64 used bank switching to address a larger memory than its 6502 CPU could handle. It was the only possibility at the time to add more memory. This method we employ now is basically the same (with a bit more added comfort). Obviously, the method is a compromise. A “real� 64 bit system would be better, and much more transparent to use. However, as I already outlined in the beginning, there is a lot of work involved to make AmigaOS 64 bit compatible, and with the method of ExtMem objects, breaking the barrier is possible now as opposed to years down the road.

https://en.wikipedia.org/wiki/Bank_switching

Bank switching is one name for address paging or segmentation. There is an address and a page or segment register that combine to access an address. It's actually not too bad with a 32 bit address giving up to 2^32 or 4GiB address pages. Each process can have up to 4GiB of address space using non-shared memory with process isolation but shared address space reduces this. Each process accesses the same page/segment so the page/segment register is changed infrequently on context switches. It's really large amounts of GPU memory for high performance systems that creates a problem as it is preferred that all the GPU memory is mapped into a flat address space at once. Before all this trouble to transition from a 32 bit to 64 bit flat address space, there was a transition from a 16 bit to 32 bit address space and from 8 bit to 16 bit address space.

32-bit 2^32 4GiB
16-bit 2^16 64kiB
8-bit 2^8 256B

The 68000 and 32016 use 32 bit addresses (pointers) giving a single 4GiB flat address space. Most other 16 bit CPUs used 16 bit addresses with a 16 bit page/segment register to give multiple pages/segments of 64kiB address pages. The address and page/segment can be combined in memory and accessed together with two accesses and multiple operations. The 68000 and 32016 reduced the number of operations, added 32 bit integer datatypes to better handle 32 bit addresses and prepared the way for later 32 bit CPU upgrades after recognizing that 64kiB pages/segments of address space were too limiting for a high performance general purpose CPU. A single 64kiB address space was adequate for most embedded use though unlike very limiting bank switching on some early 8 bit CPUs where only 256 bytes of address space per bank/page/segment was used. The IBM PC decision caused upgrade issues as a transition from 8 bit to 16 bit to 32 bit to 64 bit was required. The 808x/x86 had EMS, LIM EMS, EEMS, XMA, AWE, PAE, etc. competing and sometimes incompatible standards for essentially bank switching. The 68k Amiga had 32 bit addressing and a 32 bit flat address space from inception thanks to Jay Miner realizing that the 68k was very important to his goals of an expandable and dynamic Amiga. Other CPU choices were certainly possible for the Amiga but the 68000 was the perfect choice and the Amiga would not be as good today with any other choice.

Last edited by matthey on 27-Apr-2024 at 12:25 AM.
Last edited by matthey on 27-Apr-2024 at 12:00 AM.

@pixie

I did not invest the source codes so cannot compare. But as far as I have been reported Wanderer works relative inefficient. Something not visible on a fast PC.

@matthey

Quote:

matthey wrote: Hammer Quote: 80286 had MMU, hence functional Xenix 286. https://archive.computerhistory.org/resources/access/text/2013/04/102723262-05-01-acc.pdf Page 119 of 981 See page 564 of your Dataquest link above for historical prices. year | 80286 | 68000 | 68020 1985 $72.00 $10.40 ? 1986 $48.00 $9.50 $184.00 1987 $47.00 $5.25 $125.00 1988 $32.00 $4.30 $106.50 1989 $16.37 $3.24 1990 $9.37 $3.32 1991 $6.54 $3.81 The launch price of the 80286 in 1982 was $150 and the 68020 launch price in 1984 was $487 according to various sources. The 68EC020 didn't come until 1991 so no lower priced option until then. Atari considered the 68000 to be too expensive for a video game machine in the early 1980s at around $100. When Amiga development was in the early stages of 1983-1984, the 80286 was likely over $100 while the 68000 was $15 in 1984. The 80286 price may have been acceptable for a high end PC for the classes but it was expensive for a video game machine with custom chips designed to offload the CPU for the masses. The 68000 was still competitive with the newer 80286 and was superior in several ways.

Wholesale price for the CPU is only a part of the product's final pricing.

68000 is superior in flat memory address model and inferior in memory clock cycle efficiency and missing MMU.

286 guaranteed MMU and Unix (e.g. Xenix) option for every PC from 286. 386's MMU guarantee enables the development of memory-protected operating systems and mass deployment. Without Intel's x86 MMU, NEC's 8088/8086 clones were left behind.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey

Quote:

The 68000 is not a 32 bit CPU. 68000 16 bit ALUs and internal data paths 16 bit data bus 24 bit address bus (32 bit addresses in registers and memory) 32 bit registers (16x 32 bit GP registers) 32 bit max integer datatype size The classification of a CPU is based on data bits not addressing bits making this a 16 bit CPU. Motorola called it a 16/32 bit CPU because it is clearly more powerful than a typical 16 bit CPU and the 32 bit ISA makes a 32 bit CPU upgrade easier and higher performance. We can compare to the 80286 which some people wish Jay Miner had selected instead. 80286 16 bit ALUs and internal data paths 16 bit data bus 24 bit address bus (16 bit addresses + 16 bit offset/segment) 16 bit registers (7x 16 bit GP registers) 16 bit max integer datatype size

80286 has a standardized MMU which is missing on 68000.


Quote:

The IBM PC designers messed up selecting the 8 bit 8088 which is inferior to the 80286 when the 68000 could have easily been used. Jay Miner did not make the same mistake. The 68000 was greater than 80286 but IBM was greater than CBM even with IBM's poor CPU selection for the IBM PC. IBM made several mistakes with the IBM PC but CBM was too incompetent to take advantage. Jay Miner was a great visionary who foresaw integration making the 68k Amiga possible and competitive technology into the future while CBM ignored him and was only focused on cost reducing the Amiga down to a C64 replacement and when it finally got there it was obsolete and CBM was bankrupt.

8086 has 16 bit front-side bus bus and IBM selected 8088's 8-bit front-side bus version. PC clones selected the faster 8086 until IBM PC/AT's 286 CPU.

During OS/2 development, IBM resisted 32-bit 386 to protect their higher-priced non-X86 computer business. This enabled Compaq to take the lead and define the 386-based PC.

IBM attempted to re-control the PC with 16-bit / 32-bit MCA (Micro Channel Architecture) and it failed.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@ppcamiga1

Quote:

ppcamiga1 wrote: @Karlos We amiga users use ppc amiga because it works like amiga from commodore only better because hundreds or even thousand times faster. accept that. if you want to switch to pc which means x86 or arm provide something worth of use on pc something no more than 10 years behind windows macos android. stop trolling and start working

ARMv8 supports Big Endian mode and it runs on Emu68.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@pixie

I would have expected some slow down from being fully portable and not using an ASM. I wonder what is used to compile it? AHI is best at v4 for 68K as it's ASM and v5 and above were considered too slow.

Perhaps the graphics library isn't optimised for it but that is planar centric. It's quite possible to write software using common routines. But the OS routines need to be optimised like the Amiga ROMs were.

@Hypex

Quote:

Hypex wrote: @agami Quote: I agree, porting it to high-performance 68k would not make the OS any better, but it would make it available to a user base orders of magnitude larger. What would constitute as a high performance 68K? PiStorm? Fast x64 Emulation?

Yes. I would start with these as the low hanging fruit. Especially when one takes into consideration the logistics of the current OS4 development team.

After what I estimate to be better sales performance than that of the Hyperion Amiga OS 3 updates, someone might have that old idea anew and develop an Amithlon/Umilator style hypervisor layer for AmigaOS 4 on x64, or even ARM64.

And maybe one day the Apollo Team moves the 080 core to faster FPGA or realise their ultimate goals and tape out an 080 1GHz+ ASIC.

How many AmigaOS 4 developers would there be after all or most that? At least a few more I'd venture.

_________________
All the way, with 68k

@OlafS25

Quote:

Set Path "`Echo $Drawer`"? What is that strange? You set a local variable named path?

Yes but it was a simplified example. I couldn't use the direct output from RequestFile as quotes were saved to the variable.

But in fact I was wanting to combine paths. That's where I got into trouble. There were quotes inside the path!

Quote:

RequestFile >env:drawer DRAWERSONLY did nothing RequestFile env:drawer DRAWERSONLY opened a requester. Do I understand something wrong?

That's strange. No looks like you understood it fine. I checked a working script last night from OS3.9. The first line should immediately open a requester.

I wanted to do this:
RequestFile >ENV:Drawer DRAWERSONLY
Set File "Test"
Set Path "$Drawer$File"
Echo $Path

But it kept messing up. Choosing a dir should merge the two together. So if you chose Workbench: as drawer it should print Workbench:Test in shell. But on MOS the Path was messed up.

So I had to do this after experimenting:
RequestFile >ENV:Drawer DRAWERSONLY
Set File "Test"
Set Path "`Echo $Drawer`$File"
Echo $Path

It took me ages to figure it out. Don't know why I didn't put RequestFile in back ticks. That may have solved it and I preferred not to redirect into ENV.

@Hammer

Quote:

Hammer wrote: 8086 has 16 bit front-side bus bus and IBM selected 8088's 8-bit front-side bus version. PC clones selected the faster 8086 until IBM PC/AT's 286 CPU.

Very few clones used 8086, and most of them weren't much faster because they still used the 8 bit expansion bus.

But that doesn't mean IBM screwed up. The 8088 was much cheaper than the 68000, and would make the motherboard cheaper too. More importantly, Intel could supply enough of them for acceptance testing. IBM was very risk-averse and did not want to commit to an unproven CPU. Another reason for choosing the 8088 was that it offered an easy path from 8080/Z80 CP/M code. They also wanted something to counter the Apple II. Its 'killer app' was VisiCalc, and IBM wanted that on the PC to kill Apple. The base hardware specs of the PC were remarkably similar to the Apple II, apart from the CPU - which was still 8 bit but with an address space of 1 MB without bank switching.

Neither the 68000 nor the 8086 fitted IBM's plan for cheap computer to rival 8 bit desktop computers. A 16 bit bus would cost a lot more, as we found out with the PC-AT. But why would anyone buy such a poorly performing machine? 3 letters - I. B. M.

Quote:

During OS/2 development, IBM resisted 32-bit 386 to protect their higher-priced non-X86 computer business. This enabled Compaq to take the lead and define the 386-based PC.

Not sure where you got this idea from. Compaq did not 'define' the 386. It used the same 16 bit bus as the PC-AT. On release there was no software that could use it in 386 enhanced mode. Microsoft Windows didn't go 32 bit until V3.0 in 1990, 4 years later.

IBM released the PS/2 Model 80 in April 1987, 7 months after the Compaq 386. It featured a 16-25MHz 386 CPU, VGA display, up to 4MB RAM onboard (expandable to 16MB with option board), 64k SRAM cache, 320MB SCSI hard drive, 1.44MB floppy drive, mouse port, and the 'new standard' 32 bit Micro Channel bus.

Quote:

IBM attempted to re-control the PC with 16-bit / 32-bit MCA (Micro Channel Architecture) and it failed.

True. The genie was out of the bottle and no attempt to stuff it back in would work. The clone industry didn't want to pay a dime in royalties, even if it meant developing other 32 bit buses with iffy prospects or just sticking with the crappy 16 bit ISA bus.

Last edited by bhabbott on 27-Apr-2024 at 07:33 AM.

Hammer Quote:

Wholesale price for the CPU is only a part of the product's final pricing. 68000 is superior in flat memory address model and inferior in memory clock cycle efficiency and missing MMU.

Sure. Many support chips were required for CPUs back then. Still, the 68000 was a small fraction of the price of the 80286 for the years the Amiga was being developed. This gives a big advantage to the 68000 over the 80286.

The 80286 (and even 8086) execute some instructions in fewer cycles than the 68000 and may access memory faster. The 68000 is a microcoded CPU which reduces performance. The 68000 was still considered a high performance CPU when it was introduced even though it has mediocre performance compared to what is possible with the silicon space and what was developed later. The 68k was generally considered to be higher performance than the 80286 at the same clock speed. Where the 80286 may have had better instruction "clock cycle efficiency" the 68k had better system efficiency due to fewer instructions, less memory traffic and better code density from a cleaner ISA, better orthogonality, more GP registers, a flat address space, etc.

Hammer Quote:

286 guaranteed MMU and Unix (e.g. Xenix) option for every PC from 286. 386's MMU guarantee enables the development of memory-protected operating systems and mass deployment. Without Intel's x86 MMU, NEC's 8088/8086 clones were left behind. 80286 has a standardized MMU which is missing on 68000.

An on chip MMU is a very good idea which significantly increases performance and saves a lot of logic. However, the 80286 added a MMU which performs paging to a CPU using segmentation which are also like pages. There are different sized pages and segments with only 16 bit address pointers. It was the 80386 which introduced a 32 bit flat address space with a MMU that was much more popular for MMU using OSs like Unix than the 80286 kludge MMU.

Hammer Quote:

8086 has 16 bit front-side bus bus and IBM selected 8088's 8-bit front-side bus version. PC clones selected the faster 8086 until IBM PC/AT's 286 CPU. During OS/2 development, IBM resisted 32-bit 386 to protect their higher-priced non-X86 computer business. This enabled Compaq to take the lead and define the 386-based PC. IBM attempted to re-control the PC with 16-bit / 32-bit MCA (Micro Channel Architecture) and it failed.

The IBM PC 8088 and AT 80286 were the cheap throw away consumer PC line. Indeed, IBM didn't want their cheap 808x and x86 PCs to take market share from their higher end professional computers with better CPUs like the 68000 based System 9000.

https://en.wikipedia.org/wiki/IBM_System_9000

IBM had no idea what their PC would become or how much trouble it would be to upgrade it. The following is an educated post about IBM choosing the 68000 instead.

https://forum.vcfed.org/index.php?threads/what-if-ibm-didnt-choose-the-intel-cpu.36113/post-442850 Quote:

IBM was a major chip manufacturer at the time. If they needed to second source the MC68000 from Motorola to meet production demands I am confident they could have negotiated a good deal similar to the one they had with Intel at the time. IBM had enormous resources that dwarfed anything that Apple, Amiga, Atari, Apollo, Sun, etc could ever hope to muster. Production capacity can be ramped up over time with enough resources I think they could have done it easily. Instead of the plodding development of the Intel 8088 -> 80386 with all its broken architecture I think we would have seen an accelerated 68000 to 68020 to 68030 and beyond on a similar time line if not sooner. The key would be adding an MMU into the mix early. The major difference is IBM would have used VERSAbus instead of the awful 8 bit ISA bus on the PC. The next logical progression would have been VME which is highly suited for the MC68000 and a hugely *much* better bus than the 16 bit AT ISA bus ever could hope to achieve. Modern VME bus systems are still in production and with the middle connector are at least comparable to PCI if not better. It is all speculation in any event but I maintain IBM really screwed up by not adopting the 68000 when they had a chance. Put a decent Sys V or BSD derivative OS on it (Xenix or AIX) and it would have smoked any competition. I think IBM lost 10 or more critical years trying to remediate the deep brokenness of the IBM PC legacy architecture. Even today, it's effects are still lingering in the background. We'll probably never be completely free of it unless we migrate to ARM or something equally drastic. Instead Apple semi-led the adoption of the 68000 and so screwed it up with the Mac it basically killed the architecture. I had a bit of hope for them after they fired Jobs and released the Mac II line but they managed to kill that too. And the PPC clones. Its amazing to me Apple is even still in business after the mess they made in the 1990's. Just think, we could have started with 6U chassis VME based 68K CPU boards with full 32 bit support from day one. I think it would have been a better world. Oh well, I guess it was never meant to be.

His post pretty well sums up the x86 disaster and the advantage of the clean 68k 32 bit ISA.

@Hammer

Quote:

Hammer wrote: 80286 has a standardized MMU which is missing on 68000.

But the 8088 didn't, so the standard on the PC was no MMU. An MMU was only useful for a multi-user OS. 8088 was still the best selling CPU until 1989, 5 years after the PC-AT was introduced.

Motorola introduced the 68010 with external MMU in 1982, 2 years before the PC-AT. But Amiga chose the 68000 because it was cheaper and an MMU wasn't needed. 39 years later my A1200 works perfectly without MMU, which I only activate to catch software bugs (same functionality could have been provided with simple memory protection circuit like the ST has).

@agami

amiga os on x86 or arm should be just amiga gui and graphcics on top of unix.
it should be done by these who want to switch.

@Hammer

As I remember it only support BE integer, not BE float, same is true for x64, in any case, another case having to reinvite everything is underway with System56, or what ever its called.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@OlafS25

Quote:

OlafS25 wrote: And yes running amigaos on fast hardware not solves the problems. You would need a new rewritten modernized OS but that would hardly differentiate from other platforms and would be a big investment.

Yes, it is possible that a re-written OS which embraces contemporary standards could end up not all that different from other platforms, but it is not a foregone conclusion.

How much an operating system differs from it's contemporaries is a matter of architecture and design choices.
So it is perfectly possible to support industry standards and simultaneously create differentiating developer and user experiences.

_________________
All the way, with 68k

@agami

Yes but user experience is in first line desktop. You can perfectly do something with the look & feel but sitting on top of something else. Also you could create layers that hide the different stuff (like linux) and make supporting or transition easier. A little like Apple did when they changed ISA to X86. I see no sense in the try to create another "modern platform" by reinventing all wheels. Besides we do not have the money for that.