AROS World Exec
Development => AROS Software Development => Topic started by: miker1264 on April 08, 2023, 06:02:54 AM
-
This topic will cover Workbench Replacements such as Wanderer, Magellan, Scalos, Workbook and standalone file managers such as Dopus4 and FileMaster and AROS development in general associated with these programs.
-
From a development perspective I really like the simplicity of Wanderer while at the same time I appreciate the full features approach of something like Scalos or Magellan. It's possible to have both and allow the user to make a choice.
Rather than add the more specialized features that "seem" to be missing to Wanderer I would do just the opposite. I would merely remove Name View since it makes Wanderer seem unfinished. It doesn't do much and it looks primitive. So then Wanderer will be free to do what it does best. It's a Graphical User Interface that deals only with Icons much like the original Amiga Workbench.
In some respects Workbook attempts to re-create the functionality of Wanderer on a smaller scale without using Zune. That's a good concept yet Workbook doesn't work. It's good that it doesn't use Zune. I don't like the word "Zune" mostly because it seems out of place and it gives erroneous results when doing a web search. Microsoft has appropriated the name for some reason and it also is an old music player from the 1990's. At one point Apollo Team was working on updating Workbook to use with AROS 68k.
Also I don't like the complicated nature of MUI or Zune as far as programming. I much prefer the Classic Amiga programming approach such as with MultiView (no MUI or Zune). Magellan and maybe Scalos also use the Classic Amiga approach to programming which can at first seem very overwhelming and less structured than MUI or Zune. But it is also much more flexible and easily extensible.
So Wanderer will come in two parts and more if you want additional menus or icon docks, etc. It should consist of Wanderer itself and the text based file manager of choice such as Dopus4 or FileMaster or something else. I have been working with FileMaster trying to update it to make it more stable and to combine all the various sources into one program to make it a combined source update. Lots of work. :'(
From a conceptual perspective from time to time I wonder if it's worth the effort to develop a totally new Workbench Replacement based on the full features of Magellan that works on all flavors of AROS in a more compatible way. What would we call it? Voyager maybe since it's based on Magellan but not to be confused with the web browser or the spacecraft. :)
So what do I use personally? When Magellan is available I use that. When it isn't I use Wanderer but mostly I use shell commands to do whatever I need. I have used FileMaster.
The best way forward would be to give the user a choice between the simplicity of Wanderer or the more specialized features of something like Scalos. Why Scalos and not Magellan? Magellan can't be compiled easily. It requires a dedicated team of developers and it seems to be too large and overly complex as far as source code. Scalos seems much easier to work with though it needs much more work.
-
As far as AROS development in general there is something that I feel we really need.
We need a basic text editor with syntax highlighting that works inside AROS. I've looked at JanoEditor and it seems very efficient at plain text. One of my favorite text editors for Amiga was and still is TurboText. JanoEditor (or just Editor) can fill that role easily. But what about something more?
I've also looked at Annotate to give some ideas about a simple text editor. I especially like the xml code definition modules that use pen colors for various keywords. Scintilla gives a more complex example of syntax highlighting but the more simplistic approach may work well for AROS.
I would start with the basic text editor that would be completely written in C wth a minimum number of code files to make updates easier. Once basic text editing works then add syntax highlighting and some other features.
The basic text editor with syntax highlighting would eventually become part of an integrated IDE combined with gcc that works inside AROS. What would we call it? "A.ROS B.asic Synt.ax H.ighlighting Editor" (Absynthe) or "Experimental Simple Colorized Intuition-based Text Editor" (Ex-Scite). I kinda like the last one. 8)
-
As far as AROS development in general there is something that I feel we really need.
We need a basic text editor with syntax highlighting that works inside AROS. I've looked at JanoEditor and it seems very efficient at plain text. One of my favorite text editors for Amiga was and still is TurboText. JanoEditor (or just Editor) can fill that role easily. But what about something more?
I've also looked at Annotate to give some ideas about a simple text editor. I especially like the xml code definition modules that use pen colors for various keywords. Scintilla gives a more complex example of syntax highlighting but the more simplistic approach may work well for AROS.
The basic text editor with syntax highlighting would eventually become part of an integrated IDE combined with gcc that works inside AROS. What would we call it? "A.ROS B.asic Synt.ax H.ighlighting Editor" (Absynthe) or "Experimental Simple Colorized Intuition-based Text Editor" (Ex-Scite). I kinda like the last one. 8)
Although it hasn't been updated in ages, it is still a very good text editor with decent syntax highlighting (EdiSyn by ALB42) https://blog.alb42.de/programs/edisyn/ (https://blog.alb42.de/programs/edisyn/)
-
As far as AROS development in general there is something that I feel we really need.
We need a basic text editor with syntax highlighting that works inside AROS. I've looked at JanoEditor and it seems very efficient at plain text. One of my favorite text editors for Amiga was and still is TurboText. JanoEditor (or just Editor) can fill that role easily. But what about something more?
I've also looked at Annotate to give some ideas about a simple text editor. I especially like the xml code definition modules that use pen colors for various keywords. Scintilla gives a more complex example of syntax highlighting but the more simplistic approach may work well for AROS.
The basic text editor with syntax highlighting would eventually become part of an integrated IDE combined with gcc that works inside AROS. What would we call it? "A.ROS B.asic Synt.ax H.ighlighting Editor" (Absynthe) or "Experimental Simple Colorized Intuition-based Text Editor" (Ex-Scite). I kinda like the last one. 8)
Although it hasn't been updated in ages, it is still a very good text editor with decent syntax highlighting (EdiSyn by ALB42) https://blog.alb42.de/programs/edisyn/ (https://blog.alb42.de/programs/edisyn/)
Thanks. EdiSyn looks like it has all the basic features I need such as go to line number, show line numbers, search functions and of course syntax highlighting. Those are the only features that I use routinely in VSCode Editor. I like to use SciTE as well for Windows and Linux but not as much.
For the visual style I prefer the looks of DevCPP. The white background makes it easier to see the text with syntax highlighting so being able to change the color is a nice feature.
I will give EdiSyn a try.
-
miker, "EdiSy" is the best choice for a developer, but it easily crashes if you use some functions such for example try to do a "Search" in the source file.
Among other things "EdiSy" doesn't show the text when you try to write something in the Search (reported to ALB)
On AROS One x86 "EdiSy" is pre-set a button on Dopus4, one click is enough to open a document with
"EdiSy."
On AROS One x86 as a Text Editor there would also be the excellent "NoWinED," the only Editor that allows you to directly drag a file onto the Editor.
"NoWinED" has only one problem, when you run it the text under the menu icons have a black bar, this vanishes if you enlarge or shrink the GUI, this could be an AROS problem, it also happens with other Applications.
On AROS One x86 there is also "Ciannamon Write" but it is not the best solution for source files.
About Wanderer, I would like to point out that it does not only deal with Icons, Wander Preferences handles Themes, Backgrounds, Fonts (distances and type), Transparencies, icon shift modes, Navigation method, automatic arrangement of windows and icons, and other little things, all functions things that didn't exist on Workench but also on Replacements
-
On AROS One x86 as a Text Editor there would also be the excellent "NoWinED," the only Editor that allows you to directly drag a file onto the Editor.
"NoWinED" has only one problem, when you run it the text under the menu icons have a black bar, this vanishes if you enlarge or shrink the GUI, this could be an AROS problem, it also happens with other Applications.
On AROS One x86 there is also "Ciannamon Write" but it is not the best solution for source files.
About Wanderer, I would like to point out that it does not only deal with Icons, Wander Preferences handles Themes, Backgrounds, Fonts (distances and type), Transparencies, icon shift modes, Navigation method, automatic arrangement of windows and icons, and other little things, all functions things that didn't exist on Workench but also on Replacements
NoWinEd sounds interesting. I will try it to see what features it has. Certainly drag-n-drop on the editor window to open a text file is a nice feature. Open in hexadecimal view is also a nice feature for viewing all other file types. Sometimes I use Notepad to open binary files to search for ASCII text. Having the ability to see true hex values would make things easier. Being able to search for ASCII strings or Hex strings like HxD is better.
Is it better to develop a text editor with syntax highlighting to be integrated into a complete IDE for use inside AROS or keep them separate giving the user more choices?
That way if they are separate we could use the editor of choice to edit source files inside AROS or on another OS then use something like Murks IDE to compile and run it. If Murks were updated with more development features it might become a good IDE for compiling and testing code, better than it is. ;)
I believe deadwood has done some work updating Murks. Maybe I can do some testing with some source files in Murks to put together a wish list of features. Does Murks use project files like DevCPP to quickly load all the source files and can it use makefiles like the AROS cross-compilers aka Build System?
@AMIGASYSTEM
Where did you get the AfA sample about project? That looks a little nicer to test with than "Hello World" though that works. ;)
I have a few small source files also and some larger single source file apps to test compiling inside Murks IDE in AROS.
-
I specify that NoWinEd does not support File Binary, that is why on Dopus4 there are "Read" integrated to Dopus4, ZapHod, Hex2.
Specifically what are you referring to "AfA sample about project" ? to that shown in the screenshot !
-
I specify that NoWinEd does not support File Binary, that is why on Dopus4 there are "Read" integrated to Dopus4, ZapHod, Hex2.
Specifically what are you referring to "AfA sample about project" ? to that shown in the screenshot !
It was some sample project with a red boing ball about AfA OS.
As far as reading binary it isn't a necessity for a text editor. There are other ways to do that as you mentioned.
-
It was some sample project with a red boing ball about AfA OS.
Could you attach a screenshot !
-
It was some sample project with a red boing ball about AfA OS.
Could you attach a screenshot !
This one.
-
This is the same Logo that I posted above of AROS One, in prartica it is a project of "Amiga_C_MUI_Examples
09" OS3 version, where for testing I modified the source in both the AROS and OS3 versions:
OS3:
http://aminet.net/package/dev/mui/Amiga_C_MUI_Examples
AROS:
http://archives.aros-exec.org/?function=showfile&file=development/example/mui_examples.i386-aros.zip
-
This is the same Logo that I posted above of AROS One, in prartica it is a project of "Amiga_C_MUI_Examples
09" OS3 version, where for testing I modified the source in both the AROS and OS3 versions:
OS3:
http://aminet.net/package/dev/mui/Amiga_C_MUI_Examples
AROS:
http://archives.aros-exec.org/?function=showfile&file=development/example/mui_examples.i386-aros.zip
Thanks. I will try that. :)
How did you get gcc to work in a shell in Amiga OS 3.9?
-
From a development perspective I really like the simplicity of Wanderer while at the same time I appreciate the full features approach of something like Scalos or Magellan. It's possible to have both and allow the user to make a choice.
Rather than add the more specialized features that "seem" to be missing to Wanderer I would do just the opposite.
I agree: it's the only reasonable solution. Adding all missing features to Wanderer will make the life too much complicated.
I would merely remove Name View since it makes Wanderer seem unfinished. It doesn't do much and it looks primitive. So then Wanderer will be free to do what it does best. It's a Graphical User Interface that deals only with Icons much like the original Amiga Workbench.
Fine as well for this.
In some respects Workbook attempts to re-create the functionality of Wanderer on a smaller scale without using Zune. That's a good concept yet Workbook doesn't work. It's good that it doesn't use Zune. I don't like the word "Zune" mostly because it seems out of place and it gives erroneous results when doing a web search. Microsoft has appropriated the name for some reason and it also is an old music player from the 1990's. At one point Apollo Team was working on updating Workbook to use with AROS 68k.
Also I don't like the complicated nature of MUI or Zune as far as programming. I much prefer the Classic Amiga programming approach such as with MultiView (no MUI or Zune). Magellan and maybe Scalos also use the Classic Amiga approach to programming which can at first seem very overwhelming and less structured than MUI or Zune. But it is also much more flexible and easily extensible.
The problem with MUI & Zune is the same general problem of all BOOPSI-based GUI applications: it's one of the worse OOP implementation. BOOPSI really sucks at simulating OOP using C-like languages AND it's absolutely inefficient (both memory and CPU/performance-wise).
Unfortunately it's very spread on the Amiga land, because it's part of the o.s..
On the other hand non-BOOPSI (AKA "classic") is much easier (that's what I've used on my tools, at the time) but extremely limited.
It's very difficult to take a decision. However if Scalos and/or Magellan are MUI/Zune-based, then there's no alternative that to use it.
So Wanderer will come in two parts and more if you want additional menus or icon docks, etc. It should consist of Wanderer itself and the text based file manager of choice such as Dopus4 or FileMaster or something else. I have been working with FileMaster trying to update it to make it more stable and to combine all the various sources into one program to make it a combined source update. Lots of work. :'(
I only use DiskMaster (a veeeery old application :D) for this. Never tried FileMaster, but if it's MUI/Zune-based then it'll be a pain to update it (as usual).
From a conceptual perspective from time to time I wonder if it's worth the effort to develop a totally new Workbench Replacement based on the full features of Magellan that works on all flavors of AROS in a more compatible way. What would we call it? Voyager maybe since it's based on Magellan but not to be confused with the web browser or the spacecraft. :)
It's like reinventing the wheel and feature-wise it'll require A LOT of time. Not worth the very big effort...
So what do I use personally? When Magellan is available I use that. When it isn't I use Wanderer but mostly I use shell commands to do whatever I need. I have used FileMaster.
The best way forward would be to give the user a choice between the simplicity of Wanderer or the more specialized features of something like Scalos. Why Scalos and not Magellan? Magellan can't be compiled easily. It requires a dedicated team of developers and it seems to be too large and overly complex as far as source code. Scalos seems much easier to work with though it needs much more work.
Indeed. It looks like the best candidate. Some missing feature could be borrowed by Wanderer to make it a full replacement for the latter.
Honestly I wouldn't target the original machines or something like that: they are too much limited and this will become THE burden that limits the future Workbench Replacement.
-
As far as AROS development in general there is something that I feel we really need.
We need a basic text editor with syntax highlighting that works inside AROS. I've looked at JanoEditor and it seems very efficient at plain text. One of my favorite text editors for Amiga was and still is TurboText. JanoEditor (or just Editor) can fill that role easily. But what about something more?
I've also looked at Annotate to give some ideas about a simple text editor. I especially like the xml code definition modules that use pen colors for various keywords. Scintilla gives a more complex example of syntax highlighting but the more simplistic approach may work well for AROS.
The basic text editor with syntax highlighting would eventually become part of an integrated IDE combined with gcc that works inside AROS. What would we call it? "A.ROS B.asic Synt.ax H.ighlighting Editor" (Absynthe) or "Experimental Simple Colorized Intuition-based Text Editor" (Ex-Scite). I kinda like the last one. 8)
Although it hasn't been updated in ages, it is still a very good text editor with decent syntax highlighting (EdiSyn by ALB42) https://blog.alb42.de/programs/edisyn/ (https://blog.alb42.de/programs/edisyn/)
Thanks. EdiSyn looks like it has all the basic features I need such as go to line number, show line numbers, search functions and of course syntax highlighting. Those are the only features that I use routinely in VSCode Editor. I like to use SciTE as well for Windows and Linux but not as much.
For the visual style I prefer the looks of DevCPP. The white background makes it easier to see the text with syntax highlighting so being able to change the color is a nice feature.
I will give EdiSyn a try.
The problem with development is the usual one: having good tools that are comfortable and maximize productivity.
That's why the best way for this would be a cross-dev environment. You're already used to VSCode, which is one of the most flexible and productive IDE.
For the original machines there's a VSCode extensions that was added and used by several developers, that allows to build, compile, launch and debug Amiga o.s. (68K) applications: maybe something like that could be done for AROS development.
Some shared folder with virtual machines could be used to make the file exchanges much easier. Or an hosted AROS version, perhaps.
Just some ideas.
-
The problem with MUI & Zune is the same general problem of all BOOPSI-based GUI applications: it's one of the worse OOP implementation. BOOPSI really sucks at simulating OOP using C-like languages AND it's absolutely inefficient (both memory and CPU/performance-wise).
Unfortunately it's very spread on the Amiga land, because it's part of the o.s..
On the other hand non-BOOPSI (AKA "classic") is much easier (that's what I've used on my tools, at the time) but extremely limited.
Have you have ever tried Feelin (https://feelin.fr/)?
-
The problem with MUI & Zune is the same general problem of all BOOPSI-based GUI applications: it's one of the worse OOP implementation. BOOPSI really sucks at simulating OOP using C-like languages AND it's absolutely inefficient (both memory and CPU/performance-wise).
Unfortunately it's very spread on the Amiga land, because it's part of the o.s..
On the other hand non-BOOPSI (AKA "classic") is much easier (that's what I've used on my tools, at the time) but extremely limited.
Have you have ever tried Feelin (https://feelin.fr/)?
No, but at first sight it looks tags-based, like BOOPSI.
-
How did you get gcc to work in a shell in Amiga OS 3.9?
on Aminet I searched and downloaded everything about the "C" language and installed it.
Initially I was getting errors on assignments, then thanks to my Amiga experience by monitoring with Snoopdos I was able to get GCC working and I think C++ works too (not tested)
I can't tell you how correct the installation was and if everything works fine, but some simple source I managed to compile.
-
Speaking of "Replacements" a new version of the su Icon.library MultiOS has been made by PeterK.
The package you can find on Aminet includes Icon.libraries for various OS3, special versions for OS3 RTG, AROS 68k and a specific one for Dopus5 Magellan.
The package also includes many interesting softwaredeveloped by Peterk and third parties (Bonus)
I attach a review by PeterK himself:
On DOpus5 framed icons were displayed with a width too large for the gray background (rounded to words).
In rare circumstances the inner drawer data was being used for deficons and sometimes even set as defaults.
This was an attempt to overwrite my library code.
Added two experimental WBStartup commands under bonus.
An attempt to avoid icon pen allocation in the WBStartup drawer at system startup. The two commands
ColorIconsOff and ColorIconsOn should be started as the first and last program in the WBStartup drawer.
Improved handling of ApolloOS on Aros by correctly detecting the Aros port of cybergraphics.library and using FastMem for icons.
Using FastMem for icons by default.
Reduced the size of icon.library by removing some elements.
-
Library replacements for AROS and Amiga count too!
-
This is a fundamental Library also for AROS 68k, and especially free to use on Free Distributions.
miker, if you need, I have prepared an AfA One version Lite with working GCC, PortabLe also works, for converting ".e" sources to ".cpp" sources, PortabLe also works well on AROS x86
-
Miker, as you requested, I sent you in PM "AfA One" with the GCC and PortabLe working.
As mentioned the MP, do not change some App settings of WBStartup, Startup-sequence and user-startup, otherwise something will not work as it should.
Among the settings mentioned, there is moving windows off-screen, image thumbnails, and more
Don't change WinUAE's settings either otherwise you might get errors, WinUAE is set up with 060 and the "Map ROM Emulation" which are for moving windows, and take advantage of 060 native libraries and Apps.
If you encounter problems let's discuss them on the thtread dedicated to AfA One:
https://ae.amigalife.org/index.php?topic=403.msg13769#msg13769
-
Recently I purchased a Pi Storm32 Lite from Amikit. I also bought a Raspberry Pi 3A+ to go with it. By comparison I own a Vampire V2+ for my Amiga 500. The Pi Storm32 will be for my Amiga 1200.
But what does new Amiga hardware have to do with AROS ?
On the Pi Storm32 Lite I intend to install Caffeine OS which uses Magellan as it's workbench replacement to try it out.
-
I would say that the new hardware centers with AROS, since AROS 68k could run on it discretely, although to date the best solution for AROS 68k is WinUAE
Caffeine like CoffinOS are systems I would not recommend, they are mix systems (as well as include commercial software), already this is enough to encounter many incompatibilities and strange Guru.
-
I would say that the new hardware centers with AROS, since AROS 68k could run on it discretely, although to date the best solution for AROS 68k is WinUAE
Caffeine like CoffinOS are systems I would not recommend, they are mix systems (as well as include commercial software), already this is enough to encounter many incompatibilities and strange Guru.
The Pi 3A+ has a 1.4Ghz ARM CPU that gets about 860 MIPS in SysInfo which is astonishing! As with all new Amiga related hardware it has some small issues. It can't access Chip Ram efficiently. Maybe Pi Storm32 could remap Chip Ram to the faster DDR3 like Vampire does.
I have no problem using "mixed systems". In fact AfA OS is a mixed system in that sense. If we develop an app for AROS 68K then use it on Amiga OS3.x is it then a mixed system? On the other hand if we use Amiga OS3.x apps on AROS 68k does that mean that they won't work or that there are so many incompatibilities that it isn't worth the effort?
I disagree. The purpose of AROS 68k is not to have it run only in WinUAE but it is intended to be used on real 68k compatible hardware. But AROS 68k has difficulty running on stock Amigas without beefy accelerators. Apollo OS (Caffeine OS) runs without the hardware abstraction layer of AROS 68k which I assume makes it more stable and more responsive. What is the purpose of making AROS 68k to be binary compatible with Amiga OS3.x if are afraid to run such Amiga apps on AROS 68k. If that's the attitude then why not just run Amiga apps in UAE on AROS x86 or in WinUAE and forget about the rest.
Each combination of hardware and software has it's advantages and it's shortcomings. WinUAE is great for playing some nostalgic games like Pirates or Centurion. It's also great for partitioning and formatting and for testing. Vampire accelerators are good for a fast RTG experience with Amiga modes supported as well. Pi Storn32 will provide a super fast RTG experience, much faster than Vampire 68080 + SAGA. But to play Amiga games I would remove the Pi Storm32. Pi Storm32 uses micros sd cards which are very inexpensive. So I'd like to try Amiga OS3.9 and AfA OS and AROS 68k with Dopus Magellan or Scalos workbench replacements.
-
By Mix systems I mean something else, AfA One is a "pure" OS 3.9 BB4 with the addition of AfA OS libraries (AROS For Amiga), when you try it you can verify this.
Systems like Coffin include libraries and system files that belong to various OSes and this results in incompatibilities
Mixing OS 3.1 or OS 3.2 with OS 3.9 runs into many incompatibilities, many of which have been discussed many times.
Regarding AROS 68k, no AROS 68k software can run on OS3, as you know AROS 68k executables are "ELF"
Caffeine I don't know the latest version, but it is supposed to include AROS 68k and OS3 libraries and files, this of course is a mix that I particularly dislike, because then it is no longer a true AROS 68k
-
By Mix systems I mean something else, AfA One is a "pure" OS 3.9 BB4 with the addition of AfA OS libraries (AROS For Amiga), when you try it you can verify this.
Systems like Coffin include libraries and system files that belong to various OSes and this results in incompatibilities
Mixing OS 3.1 or OS 3.2 with OS 3.9 runs into many incompatibilities, many of which have been discussed many times.
Regarding AROS 68k, no AROS 68k software can run on OS3, as you know AROS 68k executables are "ELF"
Caffeine I don't know the latest version, but it is supposed to include AROS 68k and OS3 libraries and files, this of course is a mix that I particularly dislike, because then it is no longer a true AROS 68k
For sure mixing OS libraries and components indiscriminately could cause problems but I'm sure the talented development team at Apollo Computers has taken that into consideration and there is extensive testing for that.
Using Caffeine OS or my own version of AROS Vanilla 68k on Pi Storm32 Lite on my Amiga 1200 would help to test Magellan and Scalos on real "native" hardware. It would also come very close to fulfilling one of my lifetime goals of writing software for my Amiga! If I could compile IconClone and some of my other apps for AROS 68k and see them running on my Amiga 1200 via Pi Storm32 that would be great. I'm interested in the possibilities for future development.
Using Pi Storm32 as an Amiga accelerator has another advantage in RTG mode. No graphics driver is needed for AROS 68k. The HDMI output is generated by the Pi 3A+ so it can be displayed in 1080p on a 32" LCD TV. Having a good RTG experience is important for graphics program development. I recently bought a new mini-itx board and processor for my mini PC to run AROS x86 because the new board has Intel HD 2000 graphics chipset. In addition to the Pi Storm32 HDMI graphics I have an Indivision AGA scandoubler that will output Amiga modes through HDMI on a different LCD monitor. Next week the fun begins when the new hardware arrives! :) :) ;)
-
Compiling IconClone or your other software for OS3 would be very nice, hopefully my AfA One will allow you to compile your software for native OS3 ! probably many Amiga users would be happy about that.
Even if you won't be able to do it on real Hardware, there is always WinUAE, which besides being more powerful than any "modern" Amiga board, is also more compatible with a real Amiga of these cards.
-
Compiling IconClone or your other software for OS3 would be very nice, hopefully my AfA One will allow you to compile your software for native OS3 ! probably many Amiga users would be happy about that.
Even if you won't be able to do it on real Hardware, there is always WinUAE, which besides being more powerful than any "modern" Amiga board, is also more compatible with a real Amiga of these cards.
I'm perfectly willing to do some speed comparisons between Caffeine OS in WinUAE and Caffeine OS on Pi Storm32 on my Amiga 1200. In RTG mode prepare for WinUAE to get demolished. ;)
I also look forward to trying Amiga OS 3.2.2 but I haven't bought it yet. I bought Amiga OS 3.1.4 with ROMS and Amiga OS 4.1 FE. I don't mind supporting Amiga or AROS software development by buying products.
AROS development in general lacks motivation to attract the attention of talented programmers. Money in my opinion is a great motivator. If pre-packaged AROS products such as IcarosDesktop or AROS One were offered Pre-Installed on CF card were available for sale I would buy them for the simplicity of not having to do anything especially if the profit of such sales goes to benefit AROS bounties for future development. I bought such a CF card from Amiwell with AROS One x86 Pre-Installed. I use it on my mini PC. I must say I'm very pleased.
-
I'm perfectly willing to do some speed comparisons between Caffeine OS in WinUAE and Caffeine OS on Pi Storm32 on my Amiga 1200. In RTG mode prepare for WinUAE to get demolished. ;)
It will be very difficult to surpass WinUAE in power and compatibility, especially the latest versions that take even more advantage of powerful PC Hardware :)
I don't have experience with Pi Storm32, but I have a lot of experience with WinUAE, plus it is the same "sincere" Wampire and Pi Storm32 users who have always confirmed the difference in power and compatibility compared to with WinUAE.
Anyway I am glad you can demolish WinUAE, this will probably push me to buy Pi Storm32 !
-
I'm perfectly willing to do some speed comparisons between Caffeine OS in WinUAE and Caffeine OS on Pi Storm32 on my Amiga 1200. In RTG mode prepare for WinUAE to get demolished. ;)
It will be very difficult to surpass WinUAE in power and compatibility, especially the latest versions that take even more advantage of powerful PC Hardware :)
I don't have experience with Pi Storm32, but I have a lot of experience with WinUAE, plus it is the same "sincere" Wampire and Pi Storm32 users who have always confirmed the difference in power and compatibility compared to with WinUAE.
Anyway I am glad you can demolish WinUAE, this will probably push me to buy Pi Storm32 !
There is a YouTube video demonstrating the speed and power of Pi Storm32. There is a Lightwave model that on an Amiga 4000 with 68060 it takes 10 minutes to render.
On Pi Storm32 the same rendering takes 30 seconds at 860 MIPS. The Pi Storm32 with Pi 4 is rated at 2200 MIPS.
The immense power and speed on Pi Storm is because Emu68 developed by Michal Schutz uses a partition on the SD card as a hard drive. It has a disk speed of 20MB/s. It interprets 68k code to ARM code that runs extremely fast on a 1.4 Ghz CPU.
Imagine what an Apollo accelerator with 68089 and SAGA could do when combined with a 2Ghz ARM compressor.
-
You might see the difference by using for example RNOTunes and clicking on the various MP3s, VMA, FLAC, or use "FPlay" and view MP4 videos at a resolution starting from 640x480.
Or you might notice the diference by running 3D Games such as Quake3, or Warp3D Games or Applications, this is sure only WinUAE can do because of the PC Hrdware he uses !
-
And on cm4 it will also be able to use Nvme, the thing is WinUAE can also do the same thing, direct access to disk, there's no one being destroyed here sir, not today! :P
-
Only time and facts can prove things, maybe in the future there will be an Amiga that will surpass WinUAE, I have been hoping for 30 years, theories often read on forum, let's leave them to those who just like to talk, without ever having tested anything !
-
It can't access Chip Ram efficiently. Maybe Pi Storm32 could remap Chip Ram to the faster DDR3 like Vampire does.
I don't think so. And wow could it be possible? The (original) chipset can only access the memory from the internal bus.
Each combination of hardware and software has it's advantages and it's shortcomings. WinUAE is great for playing some nostalgic games like Pirates or Centurion. It's also great for partitioning and formatting and for testing. Vampire accelerators are good for a fast RTG experience with Amiga modes supported as well. Pi Storn32 will provide a super fast RTG experience, much faster than Vampire 68080 + SAGA.
WinUAE does it as well.
But to play Amiga games I would remove the Pi Storm32.
You don't need so. If you can disable the "CPU acceleration" on PiStorm32 and use your Amiga 1200 as it is (I don't know if hard disk emulation, Fast Mem, RTG, etc. work: it would be very very good, in case!).
In addition to the Pi Storm32 HDMI graphics I have an Indivision AGA scandoubler that will output Amiga modes through HDMI on a different LCD monitor.
There's WiP for "redirecting" the AGA graphic to the RPi in order to use both native and RTG graphic on the same HDMI output.
I'm perfectly willing to do some speed comparisons between Caffeine OS in WinUAE and Caffeine OS on Pi Storm32 on my Amiga 1200. In RTG mode prepare for WinUAE to get demolished. ;)
Then be prepared for a big delusion. :-D
I also look forward to trying Amiga OS 3.2.2 but I haven't bought it yet. I bought Amiga OS 3.1.4 with ROMS and Amiga OS 4.1 FE.
I don't support Hyperion, especially for their AmigaOS 3.1.4 and 3.2.x and future 3.x products.
AROS development in general lacks motivation to attract the attention of talented programmers. Money in my opinion is a great motivator.
There are already several bounties, with good amount of money for some of them, but there's lack of talented developers working on them.
If pre-packaged AROS products such as IcarosDesktop or AROS One were offered Pre-Installed on CF card were available for sale I would buy them for the simplicity of not having to do anything especially if the profit of such sales goes to benefit AROS bounties for future development. I bought such a CF card from Amiwell with AROS One x86 Pre-Installed. I use it on my mini PC. I must say I'm very pleased.
That's what I, as I user, like: a completely configured system, which requires no tinkering.
And on cm4 it will also be able to use Nvme, the thing is WinUAE can also do the same thing, direct access to disk, there's no one being destroyed here sir, not today!
Indeed.
And BTW, a purely 68K + RTG emulator like PiStorm is possible also on PCs. I mean: without emulating the entire chipset, but just some small part to let the system work (like the Draco system). This way there's no PiStorm or Vampire that could ever reach its performances (which will outclass even the very good ones of WinUAE).
-
Amithlon anyone?
I have to admit that I fell in love with the Amithlon over the winter and after experimenting with a core2 system I purchased a brand new (sort of) x58 mobo from our Chinese friends. I now have an i7 Amithlon! It makes me chuckle :)
-
Amithlon is a very good Amiga operating system, which takes advantage of the hardware power of the PC, too bad there are no updates, some time ago on VM I had created "Amithlon AfA OS", see some of my attached videos :)
https://www.youtube.com/watch?v=Xf7oegRmBo0
https://youtu.be/0wprhfbxvw4
-
hehe! lovely :)
Edit; Its great to see Bernie is on line again; https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=44854&forum=8&start=0&viewmode=flat&order=0
Although rumor has it that he's parked up his VW mico-bus in the Aussie outback and stealing opal from the local mine.. ;)
-
I didn't get a chance to try Amithlon but I read a few positive reviews. That was before I became interested in Amiga again.
My first computer was an Amiga 500. It was new in the box and I bought a new 1084 monitor for it. Over the next few years I bought many games and applications all on diskettes which I still have including Pirates, Patrician and Centurion. A few years after I bought my A500 it quit working. I thought for sure there was little hope for it to run again. But having spent so much time and money on it I just put it and all the games in a closet.
Fifteen years later when I had finally accepted the PC as a daily computer I became curious about the old Amiga 500.
Having taken my PC apart many times I decided to disassemble my Amiga to find the problem. But I took off all the cables and ribbons and didn't find anything wrong. So I put everything together again. But before I put it back in the closet I decided to try one more time . Surprise! This time the Amiga worked. It must have been a loose ribbon.cable.
A few years after that for some reason I felt the need to buy another Amiga computer. There was much talk then about Amiga Inc. and Amiga OS4 and how great it would be for PPC owners. But I was only interested in Classic Amiga 68k. I had lots of old Amiga game diskettes. So I went to a place called Merlancia to buy a new old Amiga 1200 made by Amiga Technologies. I still use it today. I don't know what happened to my original Amiga 500. I bought an old A500 to use with my Vampire v2+ a few years ago.
Rather than justify the expense of another Apollo accelerator for my A1200 I spent 1/3 of that on Pi Storm32. Five years ago is when I decided to try programming for Amiga. At first I thought about contributing to ReactOS but it didn't seem very promising as an OS. It had many issues. So I discovered AROS. At first even AROS didn't seem very interesting but writing and compiling software seemed well documented. So I tried it first on AmiDevCPP just for fun. Now I use the Build Systems.
I wanted to do something that would benefit the most people in the AROS community as possible. So I decided to update picture datatypes and eventually MultiView. Work on datatypes other than TGA, PCX and TIFF is nearly complete. Save As IFF for picture.datatyoe is complete. You are using it now. :) Updates to MultiView are still a work in progress. As I'm much older now I am less motivated. Sometimes I work hard every day programming for AROS then I take a few weeks off or months at a time. Then I start again.
Maybe Pi Storm32 for my Merlancia A1200 will help to keep my interest long enough to do something useful for AROS/Amiga.
-
More all Amiga users have gone down the same path.
I started playing with a C16 that was given to me as a gift, then I decided to buy a C64 for my son, arrived at the store, was told that the C4 was obsolete and that the future computing was AMiGA, so I bought an A500Plus.
When I got home after assembling and testing it, I put it back in the box to take it back to the store where I bought it, reason ... was because it did not write in Italian, that is, the keys did not match the keys on the keyboard pressed.
The shopkeeper smiled and told me that I had to configure it .... in the future that shopkeeper will call me to fix all software problems on Amiga.
Having gained some experience (I was using AMiGA more than my son), I began to tinker with the floppies attached to Amiga magazines, slowly I began to create compilations of Little Games for my two sons, adding soundtracks, screenshots and titling or modifying menus found in magazines.
Soon after I bought an A600 HD and 1 A1200 HD for myself, later to become a 030, then again an A4000/060, 2 CD32s one expanded with SX32, all these Amigas and others that were given to me have been sleeping in the garage for almost 30 years.
These are my first free Games compilations :o
https://youtu.be/OvQtiNDwveA
-
AMIGASYSTEM
Thanks for sharing.
The only time I remember using Scalos was in WinUAE in AIAB (Amiga in a Box).
I'll try to get a customized Amiga OS 3.9 with gcc and maybe Scalos running in Pi Storm32 on my A1200.
My other option is to use AIAB in WinUAE. I wanted to test how Scalos and FileMaster behave in Amiga OS so that on AROS x86 or x86-64 I will know what it's supposed to do and if it is misbehaving. Of course WinUAE could be used too.
Besides with Amiga OS running full screen on real hardware I will be more likely to develop Amiga compatible applications that can also be used on AROS or other Amiga-like OS's.
Most of all I was tired of the colorless OS 3.1 with the low quality, low color icons that I was presented with each time I switched on my Amiga 1200. I wanted to run Amiga OS 3.9+ in full screen (1080p) and in full color with RTG. That would surely be more interesting for my Amiga workbench.
Additionally I have my mini PC in a Morex 557 case for AROS development. It's running AROS One x86 v1.6 so I will need to get gcc working in the shell for that along with a basic text editor with syntax highlighting.
-
Amithlon anyone?
It was an awesome solution which was well conceived at its time and target to squeeze absolutely the most possible from the host system, but it was (and is) also quite difficult to implement and maintain.
Nowadays we've so much computational power available that we can sacrifice a small piece of it to implement a much simpler solution like WinUAE but with one CPU core which is fully devoted to emulate the 68K and another one taking care of "bridging" host and guest plus emulating the small & minimal part of the chipset which I was talking about before.
So and to simplify, the most important thing is getting the main core out of being interrupted to handle & emulate the rest of the system.
However and to get back on topic, this would be of limited use without a modernized o.s.: the "colorless o.s. 3.1" made its time and as well the very limited Workbench.
-
Miker i am familiar with AIAB, among my installed systems is the latest version of AIAB + Scalos + AfA OS (see screenshot), and I must say that on WinUAE it is blazingly fast if 060 and related libraries are used, even the Scalos version is quite stable.
In any case even on WinUAE you can use a full screen and it is like being on a real Amiga.
(https://ae.amigalife.org/index.php?action=dlattach;topic=1104.0;attach=4764;image)
-
I'm not sure what version of AIAB with Scalos I was using in WinUAE. I will have to verify that. I have a Shuttle X for which I bought a newer motherboard a few months ago. I intend to use it for my new Drawbridge Floppy Drive and for running WinUAE for various AROS 68k and Amiga versions.
Amithlon seemed very interesting and fast at the time. I wonder what it could have become if it were still being developed.
As for workbench replacements AROS and to some extent Amiga OS4 will not be able to reach their full potential without modern browsers and office applications.
Wayfarer for MorphOS is showing how it can be done though it requires more resources than many OS4 boards or even Vampire accelerators can handle. Minimum 1.5Ghz CPU and 1GB Ram. More modern browsers are demanding when it comes to CPU speed and available memory.
Maybe when Pi Storm32 advances enough to use the Pi wifi, Ethernet and USB devices a newer, more modern browser will be available for Amiga-like OS's. We can use pcmcia wifi now but modern browsers aren't available.
-
The versions of AIAB do not differ much from each other, there have been some updates over time between cul AfA OS integration, but it remains an obsolete OS.
https://aiab.ultimateamiga.co.uk/
Best solution on OS3 remains OS 3.9 BB4 and OS3.2, much more stable but in some ways less advanced than OS 3.9 (OS 3.2 is an update of OS 3.1)
Amithlon is not easy to run because it uses non-native OS3 software that has never been updated.
Wayfarer runs well on MorphOS, but if this OS continues to run on old MACs it will go more and more into the niche, a move to x86 could be a major breakthrough.
If I have to be honest I don't like Ambient, which is then nothing more than an evolution of Magellan.
I liked it very much OS 4.1, but then when I saw that part of the system became Linux, I lost the taste to use it.
-
Wayfarer runs well on MorphOS, but if this OS continues to run on old MACs it will go more and more into the niche, a move to x86 could be a major breakthrough
Like aros using AxRuntime? (moving aros to x64 that is) ;)
Don't get me wrong, aros 32bit is my goto amiga os. But with lots of the drivers in need of an update, its probably an impossible task. It wont be to long before we have to re-cap the graphic cards! :)
-
As I've always said I like native systems, AxRuntime is like a native system.
I don't like host systems, if I have to use an application through a host system, I might as well use an application directly with the host system, you do it faster and you do it better.
-
I don't like host systems, if I have to use an application through a host system, I might as well use an application directly with the host system, you do it faster and you do it better.
I know what you mean, but its a good place to start unless the user prefers a vm. It just works.
I'm pretty hyped about AxRuntime at the moment, it took me a long time to realize just what it means for the future.
-
I don't like host systems, if I have to use an application through a host system, I might as well use an application directly with the host system, you do it faster and you do it better.
I know what you mean, but its a good place to start unless the user prefers a vm. It just works.
I'm pretty hyped about AxRuntime at the moment, it took me a long time to realize just what it means for the future.
I'm still not sure what the capabilities or use cases are for AxRuntime. What can it do that an x86 or x86-64 system can't ?
I've read the documentation but some type of demo or explanation would be helpful.
Until recently I have been using AROS Hosted or Native inside VM's like VirtualBox or VMWare. But I must say it's more satisfying using real software on real hardware. AROS One x86 Native is installed on my Morex 557 mini PC. It's great.
-
@Miker:
VM:
Feels like native, especially when you have seamles mode activated (mileage may vary based on your host system and used VM software).
For instance there are special drivers for VMWare that offer better hardware support in AROS.
I also consider the isolated nature of a VM a pro (not for development but more for experimenting).
Hosted:
That will run AROS natively but using the Host API to 'emulate' AROS. This is my preferred way for development as it allows you to use both AROS and host applications at the same time. So for instance I can use my preferred Linux code editor, gimp graphics editor etc and directly access the AROS (dedicated) directories.
imho the con there is that there is not actually a seamless integration. AROS runs in a single separated process (the whole AROS operating system) and it can be/work confusing at times.
AXRuntime:
Runs AROS applications natively on the hosted platform. It is using direct host calls to 'emulate' the AROS look and feel. This allows for seamless integration (requires more work) and allows you to mix host applications and AROS applications as they both run (directly) on the same host.
The pro there is that you can use the AROS/Amiga API to create applications that runs natively on Linux (with a bit of help from some libraries and some basic setup files being present). The ideal situation would be for a special window manager that is targeted towards AROS/Amiga style of operation effectively being able to replace whatever desktop.
Seamless does mean (at times) the same confusion as hosted but as an additional Pro you can develop applications using AROS/Amiga API on your host which also means that you could use AX to start developing drivers for your particular hardware using already existing (host) libraries (it becomes a hybrid AROS/Linux executable). As a second step you could then start re-writing the calls to the existing hardware API to talk to the hardware directly (and thus be able to write an actual native AROS driver for the hardware).
So in case AROS API does not offer enough for your application to be able to work (too difficult, coder being lazy or short with time) then you are able to fall back to using Linux API calls as an easy replacement (you could then always decide to later rewrite the Linux specific API to something more AROS native and thus expand AROS itself). This is imho the best idea ever for easy improvements for/in AROS' codebase although afaik it has not really been put to practice yet)
add: I forgot to mention another pro of AXRT: debugging. You can use the host' debugging tools.
Native:
The pro there is to have a real separate AROS system. It is the closest to running AROS as if you were to run the workbench on an actual Amiga (but with the additional horsepower if you are lucky enough to have compatible hardware). The con there is that you do need to have hardware that is supported by AROS drivers (and that can be difficult to come by).
I'm sure I forgot to mention a lot of other things that are either pro or con but basically I consider the above to be the gist of it.
-
As I've always said I like native systems, AxRuntime is like a native system.
It's not. It's still a host system which is capable of executing AROS executables.
It's something more like WINE.
I don't like host systems, if I have to use an application through a host system, I might as well use an application directly with the host system, you do it faster and you do it better.
I agree, but here it's different. Normally we're missing the ability to run AROS applications, but AxRuntime allows it in a relatively transparent way.
I'm still not sure what the capabilities or use cases are for AxRuntime. What can it do that an x86 or x86-64 system can't ?
I've read the documentation but some type of demo or explanation would be helpful.
See above. Plus AxRuntime, having Linux as base the kernel, avoids all the burden about hardware compatibility.
Plus, each AROS process is completely independent, so it cannot crash the system neither other applications. It's sort of "safe" SMP/AMP for AROS applications.
Until recently I have been using AROS Hosted or Native inside VM's like VirtualBox or VMWare. But I must say it's more satisfying using real software on real hardware. AROS One x86 Native is installed on my Morex 557 mini PC. It's great.
Native experience is awesome, but if the Linux kernel used by AxRuntime could be reduced to the minimum then it could give a good experience to AROS users (once a good Workbench replacement is available, of course).
-
The Raspberry Pi 3A+ arrived. It's so small. 8)
Just waiting a few days for the Pi Storm32 Lite from Amikit.
Then let the configuring and OS testing begin with an initial emphasis on workbench replacements such as Magellan and Scalos and although not a workbench replacement some testing of 68k versions of FileMaster file manager.
-
Why do you like File master so much ?
File Master (all versions) I used it many years ago, I also used DirWork, but without a doubt the best Filemanager is Dopus4, simple configurability and great functionality.
-
Why do you like File master so much ?
File Master (all versions) I used it many years ago, I also used DirWork, but without a doubt the best Filemanager is Dopus4, simple configurability and great functionality.
Dopus4 is nice if you know how to configure it correctly.
FileMaster has great potential. I have collected all of the sources for all the different versions intending to make a combined source version for AROS x86 & x86-64 ABIv11.
Currently FileMaster runs on AROS x86 & 68k. My version also runs on x86-64.
https://ae.amigalife.org/index.php?topic=845.msg9510#msg9510
-
An alternative to Dopus4 is fine, we all have our own tastes, Filemaster is easier to use, but more complicated to set up like Dopus4.
That thread of my tests to the many FileManagers was very successful (https://sites.google.com/one-n.co.uk/amiga-guides/amiga-file-managers), many Amiga users did not know them, I attach that old SlideShow of mine here in direct view :D
(https://i.ibb.co/nwwwGJt/File-Manager.gif)
-
Wow. I had completely forgot CLIMate: the first one which I've used. ;D
Nice slideshow, thanks!
-
An alternative to Dopus4 is fine, we all have our own tastes, Filemaster is easier to use, but more complicated to set up like Dopus4.
That thread of my tests to the many FileManagers was very successful (https://sites.google.com/one-n.co.uk/amiga-guides/amiga-file-managers), many Amiga users did not know them, I attach that old SlideShow of mine here in direct view :D
(https://i.ibb.co/nwwwGJt/File-Manager.gif)
Damn, that's an all ecosystem! Nice work.
-
It was not easy to find all the software, to complete I reviewed all my CDs and Floppies I have in the garage.
I also did the same SlideShow for "Music Programs" and "Copiers," again lots of screenshots
-
The Raspberry Pi 3A+ arrived. It's so small. 8)
Just waiting a few days for the Pi Storm32 Lite from Amikit.
Then let the configuring and OS testing begin with an initial emphasis on workbench replacements such as Magellan and Scalos and although not a workbench replacement some testing of 68k versions of FileMaster file manager.
If you have questions about Magellan or Scalos in future then ask here. I have plenty of experience with magellan and currently work on a distribution based on Scalos
-
The Raspberry Pi 3A+ arrived. It's so small. 8)
Just waiting a few days for the Pi Storm32 Lite from Amikit.
Then let the configuring and OS testing begin with an initial emphasis on workbench replacements such as Magellan and Scalos and although not a workbench replacement some testing of 68k versions of FileMaster file manager.
If you have questions about Magellan or Scalos in future then ask here. I have plenty of experience with magellan and currently work on a distribution based on Scalos
Thanks. That's good to know. :)
Scalos and Magellan can be difficult to understand as for configuration.
-
Scalos and Magellan can be difficult to understand as for configuration.
Yes Scalos and Magellan are similar in configuration, which are then also similar to the configuration of Dopus4,the latter however simpler and more intuitive.
If you have to develop and test software OS3, I would advise you to do it with the standard Workbench 3.1/3.9/3.2, this is to have maximum compatibility.
-
The Raspberry Pi 3A+ arrived. It's so small. 8)
Just waiting a few days for the Pi Storm32 Lite from Amikit.
Then let the configuring and OS testing begin with an initial emphasis on workbench replacements such as Magellan and Scalos and although not a workbench replacement some testing of 68k versions of FileMaster file manager.
If you have questions about Magellan or Scalos in future then ask here. I have plenty of experience with magellan and currently work on a distribution based on Scalos
Thanks. That's good to know. :)
Scalos and Magellan can be difficult to understand as for configuration.
If you know how not :) they are way more powerful than workbench or wanderer
-
The Raspberry Pi 3A+ arrived. It's so small. 8)
Just waiting a few days for the Pi Storm32 Lite from Amikit.
Then let the configuring and OS testing begin with an initial emphasis on workbench replacements such as Magellan and Scalos and although not a workbench replacement some testing of 68k versions of FileMaster file manager.
If you have questions about Magellan or Scalos in future then ask here. I have plenty of experience with magellan and currently work on a distribution based on Scalos
Thanks. That's good to know. :)
Scalos and Magellan can be difficult to understand as for configuration.
If you know how not :) they are way more powerful than workbench or wanderer
That depends on the version of wanderer you run
-
If you know how not :) they are way more powerful than workbench or wanderer
When we test AROS x86 software here, we do it with the reference Build, this is for the correctness of the test.
Same thing on OS3, testing is done with the system for which OS3 software is born, ScaloS or Magellana may have "better" or "worse" variants, but they are not the most appropriate tools for testing software correctly.
Many ClassicWBs use Scalos, there are numerous discussions on EAB about how many applications or games do not work as they should.
https://classicwb.abime.net/classicweb/bugs.htm
-
But if you are running AROS, then it doesn't matter: Workbook, Wanderer, Scalos, Magellan, they are all the same level, because they are all Workbench replacements and they were born from scratch from independent (from Commodore & co.) developers.
-
Yes but you cannot test a new AROS buil "designed" with and for Wanderer, with Magellan Scalos that have not been updated (libraries) for decades !
-
The Raspberry Pi 3A+ arrived. It's so small. 8)
Just waiting a few days for the Pi Storm32 Lite from Amikit.
Then let the configuring and OS testing begin with an initial emphasis on workbench replacements such as Magellan and Scalos and although not a workbench replacement some testing of 68k versions of FileMaster file manager.
If you have questions about Magellan or Scalos in future then ask here. I have plenty of experience with magellan and currently work on a distribution based on Scalos
Thanks. That's good to know. :)
Scalos and Magellan can be difficult to understand as for configuration.
If you know how not :) they are way more powerful than workbench or wanderer
That depends on the version of wanderer you run
how many versions are there?... if you talk about Kalamatees secret version on his harddrive I can only use or judge what is available
-
If you know how not :) they are way more powerful than workbench or wanderer
When we test AROS x86 software here, we do it with the reference Build, this is for the correctness of the test.
Same thing on OS3, testing is done with the system for which OS3 software is born, ScaloS or Magellana may have "better" or "worse" variants, but they are not the most appropriate tools for testing software correctly.
Many ClassicWBs use Scalos, there are numerous discussions on EAB about how many applications or games do not work as they should.
https://classicwb.abime.net/classicweb/bugs.htm
if you want to test fresh compiled software it makes sense to test it on a basic system. Scalos and Magellan are alternative desktops for high-motivated users and distribution creators
-
@OlafS3
"if you want to test fresh compiled software it makes sense to test it on a basic system. Scalos and Magellan are alternative desktops for high-motivated users and distribution creators"
That's true. It would also be best to have more than one test environment. And if you're testing Scalos or Magellan then you must run Scalos.or Magellan.
It's a good idea to setup more than one computer for development and testing. For example I recently spilled coffee on my programming laptop, the only laptop I use for AROS and C# programming! Luckily not much harm was done and it's still working. How's that for "Caffeine OS" ?!
I was reading the blogs about Emu68 development. It seems that Michal Schultz is doing a great job! But one day he accidentally fried his CM4 module he was testing. I wouldn't be surprised if he spilled homemade beer on it. (Just kidding - but that's another story).
So that's why I constantly make backup copies of all my source files ( 4GB+ ). I'm also setting up more computers for testing and development rather than a single laptop.
Source files and development tools and any type of valuable test equipment is a terrible thing to lose!
-
"how many versions are there?... if you talk about Kalamatees secret version on his harddrive I can only use or judge what is available"
Hehehe!
Wanderer the way it is now is perfect in my opinion. Just remove Named View so it is more like the original workbench. It's already highly compatible and relatively fast. It also gives us the option of using our favorite text-based file manager whatever that may be.
Wouldn't it be great if we could simply launch our chosen file manager from the Wanderer menu using "File Manager" option? Just store the path in the tooltypes of the Wanderer app icon. Wanderer will do the rest. I'd like to try that. 8)
We don't especially need a newer, better Wanderer but we do need more drivers for graphics, sound, internet, USB, Nvme, etc. A new driver for the graphics chipset for Intel Atom motherboards would be great.
Someday maybe we will have a new driver and a library of functions and a user interface for AROS to use Rob Smith's Drawbridge Amiga Floppy reader/writer. So why do we need to be able to read and write Amiga floppies on AROS ? Anything that makes AROS more attractive to new users is a good thing. Besides Drawbridge just lacks OS support.
When you plug in the floppy drive in an AROS PC it is detected as "USB UART DEVICE". I suppose UART means it uses Com Ports. So we can detect the hardware. It just needs a driver and a way to access the data from the Com Port. Someday maybe...
-
If you haven't noticed I'm excited about the possibilities of Pi Storm32 Lite and Pi Storm32 for the CM4 with the expansion module. For RTG operation it would be great and super fast.
We are at an exciting time for AROS/Amiga/MorphOS development for hardware and software. It seems like old Amigans are getting older and wiser. More and more people are deciding to do great things for 68k development especially. It's the revival of 68k. New accelerators, graphics cards and other modern hardware appears almost daily.
The Apollo Team has done some great work with their FPGA accelerators. Imagine if they added an ARM co-processor to their accelators. It would add hardware FPU, super fast RTG performance and lots of horsepower!
Better yet if Apollo Team made a small 68080 compute module with other small support components on a board the size of a RPI 3 equipped with a 68080 FPGA CPU as a drop-in replacement for the dwindling and ever more expensive 68060 CPU's - wow! Sell those to vendors who are interested in making new 68080 accelerators. 8)
So what does that have to do with AROS development? AROS runs quite happily on the 68080 CPU.
-
Yes but you cannot test a new AROS buil "designed" with and for Wanderer, with Magellan Scalos that have not been updated (libraries) for decades !
Why not? You're saying that Magellan and Scalos have outdated libraries, so why not updating them and solve this problem?
-
We don't especially need a newer, better Wanderer but we do need more drivers for graphics, sound, internet, USB, Nvme, etc. A new driver for the graphics chipset for Intel Atom motherboards would be great.
Actually creating AROS drivers for new devices looks like a bigger challenge than creating or updating a Workbench replacement...
-
The Apollo Team has done some great work with their FPGA accelerators. Imagine if they added an ARM co-processor to their accelators. It would add hardware FPU, super fast RTG performance and lots of horsepower!
Well, actually the FPGA that they have chosen has at least one ARM processor (I recall having two, but I'm not 100% sure now), but they (which means Gunnar: the project lead) don't want to use it.
They are "orthodox": anything which isn't "68k" is... heretic!
Better yet if Apollo Team made a small 68080 compute module with other small support components on a board the size of a RPI 3 equipped with a 68080 FPGA CPU as a drop-in replacement for the dwindling and ever more expensive 68060 CPU's - wow! Sell those to vendors who are interested in making new 68080 accelerators. 8)
PiStorm has already severe problems interfacing with the slow (in terms of operating frequencies) Chip Mem, so I don't think that a drop-in replacement for 68060 could be feasible, since it works at higher frequencies.
So what does that have to do with AROS development? AROS runs quite happily on the 68080 CPU.
Yup. Because it supports 68k, and 68080 is almost fully compatible, so it's easy.
-
@cdimauro
"PiStorm has already severe problems interfacing with the slow (in terms of operating frequencies) Chip Mem, so I don't think that a drop-in replacement for 68060 could be feasible, since it works at higher frequencies."
The V4SA uses modern faster memory as chip mem. So Pi Storm32 and other accelerators with a 68060 replacement cpu (68080) will have to wait for a Re-Amiga 1200 carrier board or something similar with new old custom chips, modern peripherals and DDR3 chip mem on the board. :)
But we are at an exciting time for AROS/Amiga/MorphOS with new re-manufactured boards and new accelerators and add-on boards/adapters becoming available at regular intervals.
-
@miker1264: yes, FPGA-based solutions have better chances to become drop-in replacements.
But PiStorm, since it's RPi-based, I still don't think so.
-
@miker1264: yes, FPGA-based solutions have better chances to become drop-in replacements.
But PiStorm, since it's RPi-based, I still don't think so.
And still, the PiStorm for A500 or A600 are drop in replacements for the 68000.
-
@miker1264: yes, FPGA-based solutions have better chances to become drop-in replacements.
But PiStorm, since it's RPi-based, I still don't think so.
And still, the PiStorm for A500 or A600 are drop in replacements for the 68000.
Not yet. As already report here, a few posts before:
PiStorm has already severe problems interfacing with the slow (in terms of operating frequencies) Chip Mem, so I don't think that a drop-in replacement for 68060 could be feasible, since it works at higher frequencies.
So, it's not able to fully replace even a simple 68000, due to that.
Let's talk once this issue is removed. ;)
-
The Raspberry Pi 3A+ arrived quickly but I'm not sure when the Pi Storm32 Lite adapter will arrive. In the meantime I'll just use WinUAE for Testing Amiga and AROS apps including Scalos and some others.
I'd like to start compiling and testing some small apps for Amiga OS 3.x. I believe IconSplit CLI that I wrote a few weeks ago should work. It uses all internal methods to split an Amiga Glow Icon into two ILBM images. And yes I will be testing FileMaster on Amiga. ;)
But in order to do the WinUAE testing I need to setup a new development PC. I'm probably going to use my new mini ITX core i5 PC but I'll need to buy a new mini ITX case. The Morex 557 case has AROS x86 in it already for AROS testing. It looks good on a 26" LCD TV. More room for editing / graphics.
I'd like to try adding a menu items to Wanderer as well for "File Manager" that uses the Wanderer Icon Tooltypes to load a text based file manager. It seems redundant but maybe worth a try to see how well or if it works. Of course adding a few updates for AROS MultiView would also be nice. The coding has been completed but I haven't submitted any official changes mostly because my Build System was outdated. It's a long story.
So much work = so much fun! 8)
-
After a few days of sending messages Amigakit finally replied.
The Raspberry Pi 3A+ itself which I bought separately arrived in three days. The Pi Storm32 won't arrive for two more weeks.
But if you order a Pi Storm32 Lite from Amigakit expect a delay of up to 20 days from the date of purchase till it arrives. I suppose that's fast delivery in the Amiga world. :-\
I still need some time to set things up before I can start testing software. The new development PC using the mini ITX core i5 board needs to be setup too. Lots of work to do!
-
::) ::)After some searching for a new mini ITX case I decided to order a second Morex 557 case for my new development PC based on the mini ITX core i5 3.1Ghz main board that I have. It is identical to the case I use for my AROS testing machine which uses an Intel Atom board with AROS One x86 on a 60GB SSD. So I can put a sticker on the new case to distinguish the two PC's. I wish I had an AROS sticker for the AROS test PC.
After a recent accident with "caffeine OS" where I spilled coffee inside my Toshiba P775 laptop that I use for all my AROS programming I felt a second development PC was needed and full backups of all the source code which I luckily store on SD cards and flash drives so no problem with that. Luckily the laptop still works! But it's better to have a backup.
The Pi Storm32 adapter was shipped late last week by Royal Mail so I'm not sure when it will arrive to start assembling some AROS and Amiga test OS'es on my Amiga 1200. Maybe some AfA OS as well. :)
-
miker if you need any particular configuration, on any Amiga OS, just ask ;)
-
miker if you need any particular configuration, on any Amiga OS, just ask ;)
Thank you. I may need a few things in a week or two.
But I have some hardware to assemble first. ;)