AMIGA RACER!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

QuikSanz Quote:

I really think your correct. There are only a few choices to move on. Change to different Architecture, and all code is obsolete and is a very expensive move, 10's or 100's of millions $. Emulation is ok if you want percentage of increase. traditional accelerators are good but for a limit. Still A bit better than 100 MIPs on Vampire. Next choice after that is when ready, Asic that FPGA to at least 1Ghz, Now, we're talking MIPs May not be pretty, but we can club the OS into submission, Instantly, then we have something!

Exactly. I would rather spend $10 million on hardware than $10 million porting the AmigaOS to a new architecture only to leave users and software behind. A 68k ASIC could be useful for other retro devices and embedded applications where a $10 million ARM port of AmigaOS is useless to anyone else if not successful. Hardware generates excitement that software never will too.

QuikSanz Quote:

At that point with this skinny OS we can blow any old system away....

Even new OSs with as many standard features as the AmigaOS are rarely as lean as the Amiga.

Carl Sassenrath Quote:

Well, back in those days, most multitasking systems were pretty large. They were on IBMs and DEC machines, etc. What we needed to do was create something that was very efficient. So, I came up with what I guess was one of the very first micro-kernel designs for a multitasking kernel. It's very thin, very lean and mean to get the job done quickly.

Most other OSs feel cramped with 512MiB or even 1GiB of memory but that feels like overkill on a 68k Amiga.

agami Quote:

From a hardware standpoint, I agree. But the goal of the revival is not just the return of a "pulse", it also needs a raison d'être to sustain itself in the broader computing context. In parallel, there needs to be a software component to the revival initiative.

I would like to see the 68k AmigaOS improve in its current form as well as a much improved next generation AmigaOS but we need hardware. The 68k AmigaOS is serviceable with modern updates and bug fixes and adequate for nostalgia. I feel like a lot of development money could be wasted for the AmigaOS without helping a product much. Maybe it would be better to be more open with the source and allow contributions. It's not practical to charge for an OS anymore so big development costs will likely be included in the hardware cost. Granted, enough hardware sales would provide more software funds.

agami Quote:

In the late '90s it was all about virtualisation: Write Once, Run Anywhere. It makes sense from a pure business aspect. Running applications on as many hardware platforms with minimal repeated (billable) work. So it's no surprise that part of Amiga Inc's plan was to have a highly portable framework.

Moore's law came to an end and efficiency matters again.

agami Quote:

Nowadays most people familiar with e subject know that it is about the developers. When the developers are happy, then the development community grows. And a growing happy development community is good for business. The Future Amiga platform software + Updated SDK + IDE to entice new developers + Optimisation for a specific easy-to-learn programming language (like what Apple did with Swift)

I would stick with C as the primary language. It gives the best performance and tightest code of any language and that is what the AmigaOS is primarily coded in. I would say vbcc is close to becoming a replacement for SAS/C but it lacks C++ support which is an important secondary language. Volker Barthelmann was looking at supporting EC++ at one time which uses a subset of C++ for better performance but it has failed to gain much support. Apple uses an even more restrictive subset of EC++ though. In any case, full C++ support and GCCisms will continue to be important for porting software to the Amiga which means GCC support is in order even though it is not Amiga friendly. Some easier language support would be nice but it may be better off coming from 3rd parties, perhaps included but not supported directly.

agami Quote:

+ Updated OS with 64bit and threaded processes support

Partial 64 bit support with the AmigaOS mostly using 32 bit memory addressing should be possible but full 64 bit would require a next gen AmigaOS. The AmigaOS doesn't really have the concept of a thread but every process is like a thread in Unix and Windows because they share the same memory. Multicore SMP support while maintaining compatibility would be challenging while AMP should be no problem. Parallel processing could be efficiently done by a HSA GPU from a hardware standpoint but OpenCL software lacks efficiency and would be another big program to port.

agami Quote:

+ Inclusion of graphics APIs in OS, e.g. Vulkan

Vulkan would be a good fit for the Amiga but there are other options. AmigaOS 4 is using OpenGL4ES with Nova to also get to Spir-V bytecode not that that software would necessarily be available. Honestly, I'm not sure what do about a GPU. A 3D GPU is likely to take up at least half of a SoC and it may be better to leave it out at first to avoid feature creep and get to market quicker with a cheaper product. Saving the GPU for a 2nd generation could allow a better GPU with HSA and ray tracing features rather than licensing a ready made GPU. I would expect Hans De Ruiter and Alain Thellier would have some good input on what they would like to see. The chief CPU architect I was hoping to get has professional 3D GPU chipset experience too.

agami Quote:

+ Software portal for developers to commercialise their work

Aminet isn't good enough or are you afraid they wouldn't be able to handle the traffic?

agami Quote:

Then to kick things off, it will go a long way for the revival team to write a few cool apps on the revival Amiga HW + OS, using the SDK, and sold through the portal. To show what is achievable. NeXT/Apple did this repeatedly. Before you know it, we can have our first 68k21C dev conference.

The first hardware testers should be developers.

@matthey
Quote:

Most other OSs feel cramped with 512MiB or even 1GiB of memory but that feels like overkill on a 68k Amiga

Not really, most other OSs have SOFTWARE that runs away with RAM - software that doesn't exist on Amiga - software Amiga users keep pining for constantly - software like modern web browsers, "electron apps", and office software.

Also, most other OSs have built in capabilities that AmigaOS simply doesn't exist on Amiga. Like being able to deal with very large filesystems and large files. Like having modern protocol stacks and services. Like properly supporting unicode.

And even on Amiga, if you REALLY use an Amiga for the type of work it is most famous for - animation and TV production - 512MB is also quickly gone once you start throwing together animations and audio of certain quality.

Quote:

Aminet isn't good enough or are you afraid they wouldn't be able to handle the traffic?

How much of what's on Aminet is...
* really 68k specific software?
* really useful software worth downloading?

Personally I find this number very low, and it doesn't help that quite a few "current" developers aren't even using aminet for their software, you need to track discussion forums and personal homepages for updates.

Last edited by kolla on 10-Feb-2022 at 01:39 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

Quote:

I would like to see the 68k AmigaOS improve in its current form as well as a much improved next generation AmigaOS but we need hardware. The 68k AmigaOS is serviceable with modern updates and bug fixes and adequate for nostalgia. I feel like a lot of development money could be wasted for the AmigaOS without helping a product much. Maybe it would be better to be more open with the source and allow contributions. It's not practical to charge for an OS anymore so big development costs will likely be included in the hardware cost. Granted, enough hardware sales would provide more software funds.

In my parallel software stream for revival, I did cover both Day 1 and Day 100+. I agree that in the onset the OS costs need to be reigned in, and initially improvements to Amiga OS 3.x would be sufficient, if we can get access to the source code (which is what I attempted to do 4-5 years ago). Otherwise we're making those improvements to AROS 68k.


Quote:

Moore's law came to an end and efficiency matters again.

Ain't that the truth.


Quote:

I would stick with C as the primary language...

For the pro's, naturally. But you don't make friends with salad. Again, not needed Day1, but strong support for a "gateway" programming language would go a long way in attracting a new generation of developers.


Quote:

Partial 64 bit support with the AmigaOS mostly using 32 bit memory addressing should be possible but full 64 bit would require a next gen AmigaOS...

Similar to the Mac revival at the turn of the millennium, soon after bringing to market revived 68k HW with Amiga OS 3.x (System 8/9), work should commence on a next gen Amiga OS (OS X). Roadmaps and forward paths are necessary for growing a development community, and for investors. Last thing I'd want to see is a mass exodus to running Linux on the revived 68k hardware.

Inclusion of GPU in SoC/SoP is something to be determined later, but either way it would be good to port graphics API(s). Then Day 100+ we can have ports of game engines such as Unity.

And then (this is for @MEGA_RJ_MICAL) we can have Amiga Racer ported, and get that Tracks issue fixed


Quote:

Aminet isn't good enough or are you afraid they wouldn't be able to handle the traffic?

Aminet serves a purpose, but as @kolla mentioned, it is not 68k specific, and discoverability is non-existent.

I see it needing to be a modern App portal which marries features of the Mac app store, Discord, and Patreon. I want developers and their customers to be able to communicate and collaborate. Clear visibility of consumer software and development components, what's commercial and what's free, software dependencies and licensing terms, developer/team profiles, beta testing signups, feature recommendations and voting, gaming section with player/multi-player stats, user-created mods and levels (tracks ).

So No, Aminet is not good enough.

New hardware is definitely the first step, but the right software bits to compliment it are a very close second. Call it "first and a half".

_________________
All the way, with 68k

@agami

Quote:

I would like to see the 68k AmigaOS improve in its current form as well as a much improved next generation AmigaOS but we need hardware. The 68k AmigaOS is serviceable with modern updates and bug fixes and adequate for nostalgia.

I, friend agami, as former creator of the earliest AmigaOS incarnation, very frankly agree with what you say here.


Quote:

And then (this is for @MEGA_RJ_MICAL) we can have Amiga Racer ported, and get that Tracks issue fixed

This, however, will unfortunately require a ARU unit that, at the moment, no Amiga hardware has included yet.

/MEGA!!!!




ps. I am truly saddened to acknowledge through your avatar's evolution, what heavy toll the toils of Amigaworld took on you.

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@kolla

a lot is worth downloading from aminet

I should know because it was main resource for my distribution

Expecially useful are even very small programs like cli based converters or players that I could easily integrate in my distribution (using the filetypes defining context menues in magellan). Example was one small program (CLI based) that converts lots of atari image formats in PNG. So I could directly support lots of atari image formats. I have another aros based converter that converts between datatypes. That made it possible that you can convert a atari image by right-click in PNG and then the PNG in any datatype supported format including IFF. So yes very worth of donwloading ;)

Demonstration of this:
http://www.aros-platform.de/images_english.html

Resources there (besides using datatypes of course) small hollywood components, the rest was from aminet

@agami

Aminet is not pure 68k but most of the software is 68k (I estimate between 70-80%). You must use search anyway because it is so huge. Another problem is not everything runs everywhere. That is expecially the case for lowlevel stuff but also the case for software. The cli based tools mostly work everywhere (more or less) but utilities with GUI or bigger applications (f.e. players or viewers and other stuff) must be tested. 68k on amiga is a wide spectrum, on aminet there are uploads from 80s that have requirement 1.3 or 2.0, not all stuff works on modern environments. You must do a lot of testing. I did that with my ditribution. Several months investing a lot of time.

Last edited by OlafS25 on 10-Feb-2022 at 10:39 AM.
Last edited by OlafS25 on 10-Feb-2022 at 10:33 AM.
Last edited by OlafS25 on 10-Feb-2022 at 10:28 AM.
Last edited by OlafS25 on 10-Feb-2022 at 10:25 AM.
Last edited by OlafS25 on 10-Feb-2022 at 10:12 AM.

kolla Quote:

Not really, most other OSs have SOFTWARE that runs away with RAM - software that doesn't exist on Amiga - software Amiga users keep pining for constantly - software like modern web browsers, "electron apps", and office software.

It is natural that computer users want to run newer software they are familiar with. The same problem happened on the Raspberry Pi that started out with 256MiB of memory. People still bought it because it was cheap but wanted more memory. The move to 512MiB opened up more modern software even though it still felt cramped for people wanting to use it like a desktop. The 68k AmigaOS uses significantly less memory than most Raspberry Pi OSs leaving more free for software.

https://www.jeffgeerling.com/blog/2022/its-official-raspberry-pi-os-goes-64-bit Quote:

And for most people running a 64-bit OS won't cause any problems, except for maybe gobbling up a little extra RAM. You might not realize it, but 64-bit memory addresses actually take up a little more space than 32-bit addresses, meaning you have a little less free RAM when you run a 64-bit OS. It's not a huge difference, but I tested both Lite images on my Pi Zero 2 with its measly 512 MB of RAM, and I saw 66 MiB used on the 64-bit OS, but only 48 MiB on the 32-bit OS. That's a 32% difference! So if you run heavier apps, the total memory usage will be a little higher when you run it on a 64-bit OS. I think that's the main reason why the 32-bit Pi OS is still listed first—Raspberry Pi doesn't want people running out of memory on their newest Pi, the Zero 2 W, which only has 512 MB of RAM!

Raspberry Pi OS (formerly Raspbian) uses 48MiB for the 32 bit Lite version and 66MiB for the 64 bit Lite version (32% more memory used and those 64 bit address pointers take up twice as much memory). Raspberry Pi OS Lite versions do not include a desktop GUI either. For 48MiB of memory wasted the reward is a "raspberrypi login:" prompt.

Raspberry Pi OS Setup with SSH (Raspberry Pi 4 booting Raspberry Pi OS Lite with no GUI)
https://youtu.be/O8AIuD_QAgE?t=459

Most 68k Amigas don't even have as much memory as the Raspberry Pi OS Lite wastes. The new 64 bit AArch64 is average at best for code density which a 64 bit 68k64 architecture can easily beat. I believe a semi-64 bit AmigaOS can save memory, retain 32 bit compatibility and gain the majority of the advantage from 64 bit. The Raspberry Pi market is diverging into a 32 bit embedded market that prefers a minimal footprint and good code density with Thumb2 and a 64 bit low end personal computer market requiring more resources like memory. I believe a 68k64 Amiga could use a single product which does both better.

kolla Quote:

Also, most other OSs have built in capabilities that AmigaOS simply doesn't exist on Amiga. Like being able to deal with very large filesystems and large files. Like having modern protocol stacks and services. Like properly supporting unicode.

The AmigaOS really should have better networking capabilities and P96 RTG included but options exist at least. Unicode variable length UTF-8 support should be a top priority. As I recall, the AmigaOS uses some fixed length unicode internally for fonts and the official Japanese AmigaOS support which was never released used variable length Shift JIS (still 2nd most popular encoding in Japan?) and self rendering fonts which likely contain some of the same enhancements required by UTF-8.

kolla Quote:

And even on Amiga, if you REALLY use an Amiga for the type of work it is most famous for - animation and TV production - 512MB is also quickly gone once you start throwing together animations and audio of certain quality.

Modern resolutions would required more memory and huge drives for sure but it was amazing what Toaster users were doing with so little memory. For the Video Toaster 4000, a 68030@25Mhz and 10MiB RAM (2MiB Chip + 8MiB Fast) were recommended. I doubt many users had more than 128MiB of fast memory on their accelerator.

Last edited by matthey on 10-Feb-2022 at 10:23 PM.
Last edited by matthey on 10-Feb-2022 at 10:19 PM.

agami Quote:

In my parallel software stream for revival, I did cover both Day 1 and Day 100+. I agree that in the onset the OS costs need to be reigned in, and initially improvements to Amiga OS 3.x would be sufficient, if we can get access to the source code (which is what I attempted to do 4-5 years ago). Otherwise we're making those improvements to AROS 68k.

Matthew Leaman has shown that it is possible to develop Amiga software on a budget and keep developers satisfied. Development just doesn't make sense for such a small niche fragmented market. I could handle AROS 68k components on top of an AmigaOS 3.1 base if Amiga Corporation wants to do more but I would really like to see at least some Amiga related parties cooperate before going forward with a plan. I failed to even get the Apollo team, Gunnar, interested in a more professional endeavor. Sometimes things are just too hard, the situation is undesirable or the timing is wrong and potential opportunities are not worth investing in. It is sad to see the slow Amiga death.

agami Quote:

For the pro's, naturally. But you don't make friends with salad. Again, not needed Day1, but strong support for a "gateway" programming language would go a long way in attracting a new generation of developers.

At one time when the Amiga was the center of innovation, the Amiga was a source of programming language development with Modula 2, Amiga E, AMOS, BlitzBasic and Hollywood (the programming language of Hollywood). Some of the old compilers are open source now. Most language development has moved to being a front end of a big cross-platform compiler today. The advantage is more developed and optimized compilers supporting more languages in the front end and more platform targets in the backend but the disadvantage is they are often big and bloated with many dependencies. I don't think I would push Basic even though it is retro. Newer easy scripting languages are becoming more common like Python and Lua but I like ARexx which worked so well during the Video Toaster days. ARexx could use some updating and the multiple languages could use the same interface to programs which use regular Amiga ports.

agami Quote:

Similar to the Mac revival at the turn of the millennium, soon after bringing to market revived 68k HW with Amiga OS 3.x (System 8/9), work should commence on a next gen Amiga OS (OS X). Roadmaps and forward paths are necessary for growing a development community, and for investors. Last thing I'd want to see is a mass exodus to running Linux on the revived 68k hardware.

I don't think there would be any mass exodus on the lowest end hardware where AmigaOS is a better choice. To try to move up into the low end desktop market like the Raspberry 3 and 4 are doing the AmigaOS would need more competitive desktop features so lots of AmigaOS development. The 68k CPU would likely need to move to OoO which is more expensive to develop and uses several times the area per core on a chip increasing ASIC production cost. In-order 68k CPU cores are relatively simple to design for professional architects and I'm confident they could outperform in-order RISC cores which are notoriously poor performance (see my post in the RISC-V thread). I would put improved 3D hardware support on the roadmap before 68k OoO CPU cores. I believe the 68k architecture can provide very powerful OoO cores competitive with x86 but development costs increase from millions of dollars to tens of millions of U.S. dollars. If the initial product was highly successful, maybe an IPO or partnership with a bigger player would be in order. Just a simple little in-order 68k Amiga SoC ASIC should be cheap enough to keep the risk under control. I see greater risk in staying in a declining and fractured niche Amiga market without competitive hardware.

agami Quote:

Inclusion of GPU in SoC/SoP is something to be determined later, but either way it would be good to port graphics API(s). Then Day 100+ we can have ports of game engines such as Unity. And then (this is for @MEGA_RJ_MICAL) we can have Amiga Racer ported, and get that Tracks issue fixed

We could probably do something temporary for basic 3D hardware acceleration in the first product. I would like to have some FPGA capabilities on board and 3D acceleration in FPGA can have more performance than CPU cores in FPGA. Where the CPU core performance of the Apollo/Vampire hardware is worse than emulation on commodity hardware, the Amiga chipset and 3D performance can be quite good although much of the FPGA space needed for 3D is taken up by the Apollo core. Chipsets in FPGA provide flexibility for a retro device. I would love to see Achronix Speedcore eFPGA blocks in the ASIC but the largest chip process it is available for is TSMC 16FF+ which is likely expensive.

https://www.achronix.com/sites/default/files/docs/Speedcore_eFPGA_Product_BriefPB028.pdf

The Raspberry Pi 4 SoC is using 28nm technology now though so maybe possible with a larger investment.

agami Quote:

I see it needing to be a modern App portal which marries features of the Mac app store, Discord, and Patreon. I want developers and their customers to be able to communicate and collaborate. Clear visibility of consumer software and development components, what's commercial and what's free, software dependencies and licensing terms, developer/team profiles, beta testing signups, feature recommendations and voting, gaming section with player/multi-player stats, user-created mods and levels (tracks ). So No, Aminet is not good enough. New hardware is definitely the first step, but the right software bits to compliment it are a very close second. Call it "first and a half".

I had thought about an advanced store which leads to the need for better web browsers and standard networking capabilities including WiFi. I have also though about chat support. We really need mic support in hardware, preferably without requiring a USB mic, and AmigaOS prefs support as standard. Standard networking and mic support has been a weak point for the Amiga and that needs to change.

Last edited by matthey on 11-Feb-2022 at 01:44 AM.

@MEGA_RJ_MICAL

Quote:

MEGA_RJ_MICAL wrote: @agami Quote: I would like to see the 68k AmigaOS improve in its current form as well as a much improved next generation AmigaOS but we need hardware. The 68k AmigaOS is serviceable with modern updates and bug fixes and adequate for nostalgia. I, friend agami, as former creator of the earliest AmigaOS incarnation, very frankly agree with what you say here.

Thanks, but that statement that you and I wholeheartedly agree with, is written by @matthey


Quote:

This, however, will unfortunately require a ARU unit that, at the moment, no Amiga hardware has included yet.

Yes, but if we have an FPGA on board alongside the 68k ASIC, we can have the ARU logic in there. Or maybe just the ATU logic.


Quote:

ps. I am truly saddened to acknowledge through your avatar's evolution, what heavy toll the toils of Amigaworld took on you.

It's a hard knock life.

_________________
All the way, with 68k

@OlafS25

Quote:

Aminet is not pure 68k but most of the software is 68k (I estimate between 70-80%). You must use search anyway because it is so huge. Another problem is not everything runs everywhere.

Don't get me wrong, I love Aminet. I think it is an excellent resource, but surely you can acknowledge that it is only a portion of the kind of modern software development and consumption marketplace I am talking about.

I would not be looking to duplicate anything that is already there. I'd crawl and index the Aminet repo to create better visualisation for applicability, dependency, and compatibility information.
Search is not the same as discoverability. Aminet doesn't even have the simplest of heuristics to show that people who downloaded x also downloaded y.

_________________
All the way, with 68k

@matthey

Quote:

I would really like to see at least some Amiga related parties cooperate before going forward with a plan.

10-4


Quote:

I don't think I would push Basic even though it is retro. Newer easy scripting languages are becoming more common like Python and Lua but I like ARexx which worked so well during the Video Toaster days. ARexx could use some updating and the multiple languages could use the same interface to programs which use regular Amiga ports.

I agree.


Quote:

I would put improved 3D hardware support on the roadmap before 68k OoO CPU cores. I believe the 68k architecture can provide very powerful OoO cores competitive with x86 but development costs increase from millions of dollars to tens of millions of U.S. dollars. If the initial product was highly successful, maybe an IPO or partnership with a bigger player would be in order. Just a simple little in-order 68k Amiga SoC ASIC should be cheap enough to keep the risk under control. I see greater risk in staying in a declining and fractured niche Amiga market without competitive hardware.

Read you loud and clear.


Quote:

We could probably do something temporary for basic 3D hardware acceleration in the first product. I would like to have some FPGA capabilities on board and 3D acceleration in FPGA can have more performance than CPU cores in FPGA ... Chipsets in FPGA provide flexibility for a retro device.

100%


Quote:

I would love to see Achronix Speedcore eFPGA blocks in the ASIC but the largest chip process it is available for is TSMC 16FF+ which is likely expensive.

She is a beauty.
TSMC 16FFC would have to be reasonably cheaper than 12FFC and 7nm FinFET.


Quote:

We really need mic support in hardware, preferably without requiring a USB mic, and AmigaOS prefs support as standard. Standard networking and mic support has been a weak point for the Amiga and that needs to change.

So overdue.

_________________
All the way, with 68k

@matthey

Quote:

Raspberry Pi OS (formerly Raspbian) uses 48MiB for the 32 bit Lite version and 66MiB for the 64 bit Lite version (32% more memory used and those 64 bit address pointers take up twice as much memory). Raspberry Pi OS Lite versions do not include a desktop GUI either. For 48MiB of memory wasted the reward is a "raspberrypi login:" prompt.

I know - I have MANY pi systems with exactly that, and that is EXACTLY what I want from them - and is does this "wasted memory" used for?

* A mostly posix compliant system
* Full modern IP stack
* Full 802.11 stack
* Full USB stack
* Full i2c stack
* modern screen resolutions
* utf8
* large storage device support
* RAID0/1/5/6/10 support
* multiple filesystem, journaling, TRIM support, multiple network filesystems
* ....
* ...

And AmigaOS What of the above? Have you ever run large filesystems on Amiga? Tried to apply meaningful buffer sizes? And then what happens to your RAM?

Quote:

Raspberry Pi OS Setup with SSH (Raspberry Pi 4 booting Raspberry Pi OS Lite with no GUI)

But it actually has SSH - where is the native 68k ssh daemon for AmigaOS?!

Quote:

Most 68k Amigas don't even have as much memory as the Raspberry Pi OS Lite wastes.

I have Amiga systems with hundreds of megabytes, and I managed to "waste it" all, and just like with the pi - or any other system, really - it is rarely about the software, it is about what you FEED the software, and what you tell the software to DO that eats RAM.

Quote:

kolla Quote: Also, most other OSs have built in capabilities that AmigaOS simply doesn't exist on Amiga. Like being able to deal with very large filesystems and large files. Like having modern protocol stacks and services. Like properly supporting unicode. The AmigaOS really should have better networking capabilities

Really, now.

Quote:

and P96 RTG included

P96 RTG should be redundant, the OS itself should just "do it right" on its own - the very term RTG should just vanish.

Quote:

Unicode variable length UTF-8 support should be a top priority.

It for sure isn't.

Quote:

As I recall, the AmigaOS uses some fixed length unicode internally for fonts

Really.

"Based on experiences with the Xerox Character Code Standard (XCCS) since 1980,[13] the origins of Unicode date to 1987, when Joe Becker from Xerox with Lee Collins and Mark Davis from Apple started investigating the practicalities of creating a universal character set"

https://en.wikipedia.org/wiki/Unicode#History

Quote:

and the official Japanese AmigaOS support which was never released used variable length Shift JIS (still 2nd most popular encoding in Japan?) and self rendering fonts which likely contain some of the same enhancements required by UTF-8.

Quote:

kolla Quote: And even on Amiga, if you REALLY use an Amiga for the type of work it is most famous for - animation and TV production - 512MB is also quickly gone once you start throwing together animations and audio of certain quality. Modern resolutions would required more memory and huge drives for sure but it was amazing what Toaster users were doing with so little memory. For the Video Toaster 4000, a 68030@25Mhz and 10MiB RAM (2MiB Chip + 8MiB Fast) were recommended. I doubt many users had more than 128MiB of fast memory on their accelerator.

The Video Toasters (and the Flyer) essentially use dedicated disks on their own controller instead of RAM, it was not a general solution for Amiga software. If for some strange reason didn't have access to Video Toasters, because of economy or simply NTSC/PAL issues, and instead did animation/presentation work using just LightWave, DPaint, SCALA etc. more RAM was crucial - and when there wasn't enough, VMM to the rescue. Or in case of LightWave - screamernet, and a whatever other hardware you can get it running on.

Last edited by kolla on 11-Feb-2022 at 09:01 AM.
Last edited by kolla on 11-Feb-2022 at 09:01 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@agami

I can guess what you think of but that would be very time consuming. You need quality management test everything and sort it in. That is much more work than now for sure. It would be interesting of course if more new software is developed and you have f.e. only two target platforms like Aros and AmigaOS 3.2. The aminet has a long heritage, there is even software from the 80s depending on 1.3 or similar. For beginner a "app" making it easy to download and install (or buy and install) new software would be nice. Someone without much amiga knowledge (people returning f.e.) will feel lost in aminet. But for those distributions like mine are designed. You get a big package with all preinstalled and preconfigured.

@agami

They should have added a PCIe 16 slot in Vampire, a FPGA never be as fast as ASIC, and the space you need for 680x0 core. As for the mic thing, already support in AHI, not sure how many sound source it supports, but one mic is all most people need.

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

@kolla

Bullet fonts works fine for UTF8/16/32, not an issue, it’s just encoding / decoding part that’s missing in the OS, I already wrote utf8.libary it does the job, also you need some kind font cache system, as one font don’t include all symbols in the world, so if you string with English, Thai and Chines, it need to change font depending on glyph number to display.

The old bitmap fonts are too limited.

Adding UTF8 support in the OS is not as complicated, can be idea to add asc code 1 in the start of string to tell the OS its UTF8, or something like that.

Now displaying and typing utf8 strings are two different things, the typing part is more complicated, as that requires changes in lot programs. or gadget classes.

Last edited by NutsAboutAmiga on 13-Feb-2022 at 09:57 PM.
Last edited by NutsAboutAmiga on 11-Feb-2022 at 11:23 AM.
Last edited by NutsAboutAmiga on 11-Feb-2022 at 11:21 AM.
Last edited by NutsAboutAmiga on 11-Feb-2022 at 11:20 AM.
Last edited by NutsAboutAmiga on 11-Feb-2022 at 11:19 AM.
Last edited by NutsAboutAmiga on 11-Feb-2022 at 11:15 AM.

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

Quote:

Rose wrote: @LadyJane Quote: That's another strange claim to make. If he was his friend, why is he backing the lawsuits against Cloanto and Amiga? AP is A-EON contractor so no surprise that he tries to spin anything negative...

I am no "A-EON-contractor", I am just an AmigaDeveloper/Enhancer-betatester. But anyway, if you and LadyJane prefer to think that Trevor is the big villain in the background just g on with it, I don´t care.

_________________
AmigaOne X5000/40, 2.2 Ghz, 4 GB RAM, Radeon R9 280X, M-Audio Revolution 5.1, 240 GB SSD

kolla Quote:

I know - I have MANY pi systems with exactly that, and that is EXACTLY what I want from them - and is does this "wasted memory" used for? * A mostly posix compliant system * Full modern IP stack * Full 802.11 stack * Full USB stack * Full i2c stack * modern screen resolutions * utf8 * large storage device support * RAID0/1/5/6/10 support * multiple filesystem, journaling, TRIM support, multiple network filesystems * .... * ... And AmigaOS What of the above? Have you ever run large filesystems on Amiga? Tried to apply meaningful buffer sizes? And then what happens to your RAM?

For POSIX compatibility, there is Frank Wille's PosixLib.

http://aminet.net/package/dev/c/vbcc_PosixLib

It's a link library for vbcc but includes source and could be turned into Amiga shared libraries (Frank is usually open about improvements which help the Amiga). It works well enough except for the mess and conflicts caused by POSIX include files. The code itself is minimal compared to a BSD emulator.

I don't start an IP stack in my Amiga startup but it only takes maybe 3-5 seconds to start it and some of my internet programs will start it automatically if it is not online. I'm not using WiFi, USB, or i2c so no reason to have drivers wasting memory for something not being used. My Amiga setup supports high resolutions with P96 and my monitor up to nearly 2k pixels horizontal even though I rarely use over 1k pixels horizontal.

My CSMK3 uses a MAXTOR Atlas 18.4 GB 15K Ultra320 SCSI drive. I use PFS with extra buffers compared to FFS for my multiple partitions as recommended. This setup has amazing performance with just a few extra MiB of memory used. Amiga filesystems have decently high limits.

FFS
2TiB partition max
2GiB file size max

PFS3AIO
1.6TiB partition max
128GiB file size max

SFS
1TiB partition max
2TiB file size max

Max drive size with a 64 bit extension like TD64 should theoretically allow 16 EiB (Exabytes) drives (2^64=18,446,744,073,709,551,616).

CF / SD and large drives FAQ
http://eab.abime.net/showthread.php?t=61666

The newest PFS3AIO limits have not been updated. Yea, no manual TRIM support, no raid support, etc. but large drive support is not that bad.

The AmigaOS can boot into a full high resolution GUI desktop using adequate drive buffers with a fraction of the memory used by the Raspberry Pi OS Lite without a desktop.

kolla Quote:

But it actually has SSH - where is the native 68k ssh daemon for AmigaOS?!

There are at least 6 different versions for the Amiga.

http://linuxmafia.com/ssh/amiga.html

I know you want a more up to date version though. Compile everything yourself is the Unix way but that is too much of a pain?

https://forum.amiga.org/index.php?topic=53644.msg830824#msg830824

Software has a tendency to not get updated on a practically abandoned platform like the Amiga. The Amiga needs a larger user base to encourage developers and that requires competitive mass produced hardware.

kolla Quote:

I have Amiga systems with hundreds of megabytes, and I managed to "waste it" all, and just like with the pi - or any other system, really - it is rarely about the software, it is about what you FEED the software, and what you tell the software to DO that eats RAM.

I have run my 68k Amigas out of memory before with more than the average amount of memory for an Amiga. More memory is desirable especially if increasing the CPU performance. The Vampire hardware is all 512MiB of memory now which seems about right for a base enhanced Amiga spec. There still is the problem of wasting memory though. Any memory the OS wastes is less to feed the software. Pre-loading too much software into memory leaves less memory for other programs and can become slower. Keeping code small (68k good code density), modular and shared along with quick disk access allows loading as needed saving memory. This is one of the reasons why the 68k Amiga saves so much memory even though most disk access performance on the Amiga has been poor but this can change with new hardware.

kolla Quote:

P96 RTG should be redundant, the OS itself should just "do it right" on its own - the very term RTG should just vanish.

Right. That is what AmigaOS 4 did with P96 which is to integrate it.

kolla Quote:

Really. "Based on experiences with the Xerox Character Code Standard (XCCS) since 1980,[13] the origins of Unicode date to 1987, when Joe Becker from Xerox with Lee Collins and Mark Davis from Apple started investigating the practicalities of creating a universal character set" https://en.wikipedia.org/wiki/Unicode#History

It looks like it was the Bullet scalable font engine which was added later yet very early in the Unicode history.

https://aminet.net/package/dev/src/BulletExamples Quote:

We need to get historical here. The Bullet engine was written at a time when the Unicode standard was at version 1.0, and these ligatures are in fact located in the Unicode 1.0 Private Use Area (U+E800-U+FDFF).

I remember the QNX floppy disk demo that would load up a OS and web browser on a 1.3mb floppy, dam impressive, I think ram requirement where low too.

I get optimising is important and less use should alway be the goal, but I think Amiga users shouldn’t worry about ram usage until we get the software that requires huge amounts of ram, which in the 68k platform isn’t very many.( I wonder what is the most ram demanding software for 68k? I guess a browser can eat up ram.)

Quote:

I'd crawl and index the Aminet repo to create better visualisation for applicability, dependency, and compatibility information. Search is not the same as discoverability. Aminet doesn't even have the simplest of heuristics to show that people who downloaded x also downloaded y.

Agreed, Aminet is great, but that would be handy info.

_________________
AmigaNG, YouTube, LeaveReality Studio

@matthey

Isn’t the topic here your hypothetical 68k strawberry pi rather than your 25 year old cyberstorm powered classic, and isn’t your target audience embedded market in addition to old amiga users? So, an embedded board with no wifi and no i2c, no usb and instead uw scsi to hook up ancient disks, and what… amiga keyboard and mouse? Or ps/2? Because that’s what your system has, and who would need anything else?

Please, can you keep your arguments on one track and stop jumping all over the place?

And - I was not talking about ssh clients, I specifically wrote ssh daemons… maybe you are unfamiliar with the term «daemon» (but I’m sure you can provide a solid handful of links to youtube videos about the origins on daemons on unix and other mostly irrelevant stuff, like you so often do - please don’t - this patronizing besserwissery is tedious).

If you think building modern ssh suite for 68k AmigaOS is such a breeze, then a skillful and resourceful developer as yourself should have no problems - just use vbcc and the posix library you referred to, and AmiSSL just had another release -many have tried and failed, but you can do it!

Last edited by kolla on 12-Feb-2022 at 03:47 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Whether it's our place to say what a company or associated individuals should or shouldn't be doing, I'm sure most of us can agree that the current situation is untenable.

Irrespective of the poll results, and not to single out Cloanto, I'd like to think that all parties could be doing more. Not just in the pure academic sense that we all could be doing more.

Whatever the motivation of the various personalities that drove them to bring to market and commercialize offerings which tap into the existing and old Amiga user base for their success, they inadvertently take on a moral responsibility to not destroy the Amiga user base.

Could we users be nicer? Of course, but nothing we do can or should excuse anything that those with a stake of the broader Amiga landscape do. In the current situation, when a specific party wins, we Amigans do not all win. And it's in this exact area that the camps and camp leaders could be doing more. Considering the end game would be a good start. Communicating their view of the "day after" would also be very helpful.

Have mindful Monday.

_________________
All the way, with 68k