@kamelito

Quote:

http://obligement.free.fr/files/devcon93.pdf

It's a funny read - they were going for an omni-present Amiga menu akin to the Apple menu, and menus that can be pinned and moved around like in NeXTStep... maybe just as well that this never happened :D

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Mobileconnect

For Amiga Hombre, it was software test cases for texture-mapped 3D acceleration.

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

@kamelito

Quote:

I remember a doc that Hyperion made public that Cloanto asked to be removed, I son’t remember what was in there.

https://pdf.ac/3cAJLO

@Rob @all

Thank you, interesting read, both PDFs

@kolla

I dont understand was Hyperion simply not aware of WB 3.14 and 3.2 existing
as they were never publicly released betas OR they choose existing names
to make moot even dirtier

_________________
OS 3.x AROS and MOS supporter, fi di good, nothing fi di unprofessionalism. Learn it harder way!
SinclairQL and WII U lover :D
YT http://www.youtube.com/user/rasvoja

@Rob

Hyperion AAA, HP RISC... What the hell is this?

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

@vox

Quote:

@kolla I dont understand was Hyperion simply not aware of WB 3.14 and 3.2 existing as they were never publicly released betas OR they choose existing names to make moot even dirtier

There was an 3.2 (v42-43) by ESCOM in the 90s that never really materialised and that was shown with the Walker prototype. There's no previous 3.1.4... I don't know where you see this? There's only the Hyperion 3.1.4 (v45-46) and then Hyperion 3.2 (v47).

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@pixie

Ignore Hyperion's claims to ownership of the document.

It's obviously an internal Commodore document that was probably written towards the end of 1993. Post CD32 release and prior to the Mpeg module becoming a real piece of hardware.

pixie Quote:

Hyperion AAA, HP RISC... What the hell is this?

More evidence of a challenge to Amiga IP ownership by Hyperion?

Rob Quote:

Ignore Hyperion's claims to ownership of the document. It's obviously an internal Commodore document that was probably written towards the end of 1993. Post CD32 release and prior to the Mpeg module becoming a real piece of hardware.

Most likely real but a fake can't be ruled out. I have never seen this particular CBM doc before but there are many others floating around from various engineers like Dave Haynie. One source with many documents is the following.

https://archive.org/details/@dave64wayback

The "Future Product Options" doc doesn't look like any other CBM docs I have seen. Most hardware related docs are "hardware engineering" docs where this is a "A Software Perspective" from and perhaps for software engineers. There is only one date given which is a future 1994 for a product. This is the only document I have seen that mentions a particular 68k CPU, "68020-class", for the 68k Amiga SoC and hints that Motorola cooperation (with license?) and development was underway for a 68k SoC. There is no mention of the AA+ chipset anywhere with major enhancements like chunky and 16-bit audio instead referring to the SoC chipset as AGA. The AGA Alice and Paula were still NMOS and a full CMOS chipset was required for the 68k Amiga SoC which is what AA+ brought. The estimated cost savings of "US$100" is mentioned though perhaps because of budget cuts which were likely felt more in software engineering than hardware engineering. A 68k AA+ SoC was a game changer as the cost of the Amiga 1200 and CD32 were $226 and $235 according to the "Commodore Post Bankruptcy" docs. CBM could have created a 68k Amiga SoC years earlier and they would have likely still been healthy. The doc mentions the low power embedded market the CMOS 68k Amiga SoC opens up including the CD^I/O for CD32 embedded use, CD^32modular for misc portable and battery operated devices (the iPod may have saved Apple), interactive television (set top boxes) and home automation (IoT). Low cost, low power and a small footprint opens up a world of embedded opportunities beyond PC and gaming consoles. CBM didn't quite make it to 68k Amiga SoCs and the RPi Foundation using ARM SoCs has taken their place today. The "Essence" software in the doc is an easier game/software menu like THEA500 Mini and A600GS uses today for ARM SoCs, lacking lower cost, lower power and smaller 68k Amiga SoCs.

AAA was disparaged in the doc more than in other CBM docs I have read. It lacked the compatibility of AA+ and was too expensive. It wasn't a total loss as there are plenty of good ideas in the chipset that could be brought over to the more compatible, practical and finally also fully CMOS AA+ chipset. This did not come as a surprise to me even though some other CBM docs still showed it before Hombre. AAA was then dropped and the 68k Amiga SoC was included with Hombre for Amiga compatibility. There was no window for AAA with CBM financial problems. The 68k AA+ SoC may have saved the business if it was available in 1992-1993 though. The doc makes it sound like Hombre was the largest potential savior for CBM but the PS1 and low quality fixed point 3D could have meant a short lifespan for Hombre. Licensing the 68060 and a 3D (3dfx?) chipset may have been a more Amiga compatible and higher quality 3D option by the late 1990s. The 68060 could still be used today for embedded use with incremental upgrades including silicon while 3D hardware changed to unified shaders but old low power 3D hardware is still used for embedded sometimes like the RPi VideoCore GPU (no fixed point 3D anymore though).

https://www.gregdonner.org/workbench/wb_b32_40.html Quote:

Some gadgets are also of v42.x compile. V40 was the ECS/OCS + AGA -> RTG merge version, with Japan dual-byte character set being worked on in V41, and they were building the foundation for a V42 release some time later, but the groundwork had begun.

Did the CBM software engineers get laid off before the hardware engineers?

Darren Greenwald was one of the software engineers working on Japanese support and who is mentioned in the "Future Product Options" doc. RIP.

https://www.reddit.com/r/amiga/comments/f42v8c/in_memoriam_darren_greenwald/

Some features of the Amiga Japanese support in February, 1993.

o uses EUC with JIS and Shift-JIS conversion utilities
o fonts are associated with a codeset
o self rendering fonts with dynamic loading and expunging (fast rendering, fonts included)
o bitmap font scaling and aspect adjusted bitmap scaling (not so pretty)
o other multi-byte language support possible
o Japanese mostly working in console but some languages not possible like Arabic
o front end processor (FEP) for input uses a fep.library but not complete

This was a big job requiring a long time. Some of the support here is obviously applicable to UTF-8 support.

Last edited by matthey on 30-Sep-2024 at 12:23 AM.

@Rob

Quote:

Rob wrote: @kamelito https://pdf.ac/3cAJLO

Oops, I guess the Commodore folks didn't get the memo that only a programming language can be object oriented, because objects only exist in OO programming languages and not within computing environments such as the planned Athena.

Thanks for sharing.

_________________
All the way, with 68k

@matthey

AAA scales from DRAM to VRAM. AAA is register compatible with ECS.

A 68020 with AA+ SoC wouldn't be a game changer since texture mapped 3D PS1 would have crushed it on "next gen" gaming experience while SNES covers the low cost strong 2D 16-bit gaming experience.

PS1 is backed by Japanese texture mapped arcade game developers.

During 1992 to 1994, gaming PC moved texture mapped 2.5D/3D gaming experience that is above SNES's strong 2D 16-bit gaming experience. Gaming PC's texture mapped 2.5D/3D games are backed by North American game developers. The US market has $1000 USD as mainstream gaming PCs during Xmas 1992 to 1994.

During 1993, the Amiga 4000/040 wasn't competitive against $1000 486-based gaming PCs.

The Amiga's mainstream SKU wasn't able to follow fast 386DX-33/386DX-40/486SX-25 minimum 2.5/3D gaming PC. Sony made sure PS1 attracted Europe's game developers for PS1 during 1993.

MIPS R3000A and SuperH2 CPUs are poor man's 68040 @ 28 Mhz class CPUs.

You're not factoring what gaming experience is being delivered for the consumer.

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

@agami

Quote:

agami wrote: @Rob Quote: Rob wrote: @kamelito https://pdf.ac/3cAJLO Oops, I guess the Commodore folks didn't get the memo that only a programming language can be object oriented, because objects only exist in OO programming languages and not within computing environments such as the planned Athena. Thanks for sharing.

I don't know if you are sarcastic or not, because... yes: OOP could be done with any programming language (even in assembly).

@agami

This clearly refers to implementing something akin to OLE on Windows or OpenDoc on Mac, so it's perfectly reasonable for the time period to be suggesting this. Imagine something like Reaction, except instead of individual widgets, it's entire application engines - a word processor, a spreadsheet and so on.


Fortunately hindsight tells us that was a dead end - it adds nothing the end user wants while adding massive complexity to the developer. Apple abandoned OpenDoc in 1997. Microsoft still supports OLE, but when was the last time you used that feature, or used that feature and thought 'man, this still sucks after 30 years' like when you try to edit an Excel chart from Powerpoint.


It would have been far too ambitious for CBM's limited resources to build such a thing, we didn't even have anything close to MFC that would be a necessary starting point. We just had BOOPSI and a half baked set of basic UI controls.

_________________

@Mobileconnect
I've started adding the code in the Miscellaneou >> Free for All channel:
https://amigaworld.net/modules/newbb/viewforum.php?forum=4&81523
I wasn't sure where else to put it?

The code incorporated move classes as watchers, and zone classes.
Zones were interested in the mouse being over them.
Watchers were interested in the mouse in general.
Watchers could include icons, or groups of icons that follow the mouse.
Watchers could also include things like "eyes" or "magnifier" or extended selection, etc.
I thought I rewrote autopointer to work with it as well?
But, I can't presently find any evidence of that.
So I am not sure if that's true or not or within the possibilities...

Last edited by gonegahgah on 30-Sep-2024 at 08:56 AM.

@Mobileconnect

For automatisation OLE is useful. Problem is, it also opens chances to misuse it, f.e. by maleware.

@Rob

as I understand it, most documents with future plans were written for investors Commodore urgently needed at its end time around 1993 to survive economically. In my view, if really realized, I doubt that it would have been a success. There were reasons why both INTEL and Microsoft were interested to stay compatible to old software.

Hombre would have been something completely new

@OlafS25
Quote:

For automatisation OLE is useful. Problem is, it also opens chances to misuse it, f.e. by maleware.

That is of concern to me too.

Last edited by gonegahgah on 30-Sep-2024 at 08:59 AM.

@pixie

Quote:

Hyperion AAA, HP RISC... What the hell is this?

It was planned CBM route for "AmigaNG", also WindowsNT drivers for it
as NT4.x PA RISC existed at time :D

As @OlafS25 I doubt it would succeed, even with advanced 2D and mentioned 3D.

So, in some strange turn of events, now AROS/MOS/OS4 present does not seem so bleak :D

Amiga did outlive even CBM vision of doom! :D (but cannot survive current console and
new gen gaming and user demands!)

@hammer

Not to mention A4000-040 with monitor in 1993 costed waay more then top 486 with
best gfx, sound card and monitor of the time.

@matthey

While m68k plus Hombre chipset could give Amiga boost and compatibility,
it was never planned by CBM, or any m68k other by 060 by Motorola.

However, FPGA of today is able of such experiments.

Last edited by vox on 30-Sep-2024 at 04:36 PM.
Last edited by vox on 30-Sep-2024 at 04:35 PM.
Last edited by vox on 30-Sep-2024 at 04:33 PM.

_________________
OS 3.x AROS and MOS supporter, fi di good, nothing fi di unprofessionalism. Learn it harder way!
SinclairQL and WII U lover :D
YT http://www.youtube.com/user/rasvoja

Mobileconnect Quote:

This clearly refers to implementing something akin to OLE on Windows or OpenDoc on Mac, so it's perfectly reasonable for the time period to be suggesting this. Imagine something like Reaction, except instead of individual widgets, it's entire application engines - a word processor, a spreadsheet and so on. Fortunately hindsight tells us that was a dead end - it adds nothing the end user wants while adding massive complexity to the developer. Apple abandoned OpenDoc in 1997. Microsoft still supports OLE, but when was the last time you used that feature, or used that feature and thought 'man, this still sucks after 30 years' like when you try to edit an Excel chart from Powerpoint. It would have been far too ambitious for CBM's limited resources to build such a thing, we didn't even have anything close to MFC that would be a necessary starting point. We just had BOOPSI and a half baked set of basic UI controls.

Soft-Logik HotLinks added OpenDoc like support to the Amiga. An Amiga program "Edit" menu example shows the following options.

Edit
---
Cut
Copy
Paste
~~~
Erase
~~~
Subscribe...
Publish...
Update
Break Link
Information...
~~~
Undo
Redo

A single "Hotlinks" edit menu option with a submenu was another "preferred" menu layout.

o Subscribe loads data made available by another HotLinks application.
o Publish makes data available to other HotLinks applications.
o Update rewrites the updated edition file and causes HotLinks to modify other applications of the updated edition.
o Break Link severs the link between the edition and a specific copy by canceling further update notifications.
o Information provides notes, access and revision information on an edition.

IFF FORM DTXT for text and ILBM for bitmapped graphics are supported in 1.0. There are 24 functions in the hotlinks.library.

HLSysInfo (), HLRegister(), UnRegister(), AllocPBlock(), FreePBlock(), SetUser(), ChgPassword(), FirstPub(), NextPub(), RemovePub(), Notify(), PubStatus(), GetInfo(), SetInfo(), LockPub(), OpenPub(), ReadPub(), WritePub(), SeekPub(), ClosePub(), GetPub(), PutPub(), PubInfo(), NewPassword()

I didn't find any date in the docs but it was with dev docs from the early to mid 1990s. The docs mention Unicode support. It looks like a simple and light weight enough implementation. Reasons for failure could be lack of supported data formats, lack of networking hardware and support on the Amiga, CBM bankruptcy (bad timing), 3rd party implementation (Soft-Logik well respected though), chicken and the egg adoption problem, not useful enough, etc.

https://pagestream.org/?id=1236 (HotLinks introduced in 1992)
http://de.aminet.net/aminet/text/dtp/pgs2ptch.readme (pgs2ptch.lha is from 1992-08-15)
https://wiki.amigaos.net/wiki/HLID_IFF_Hotlink_Identification

https://en.wikipedia.org/wiki/PageStream Quote:

PageStream 2.2 for Amiga and Atari ST was released in 1992 with support for the HotLinks Editions publish-subscribe system which was bundled with the PageLiner text editor and BME bitmap image editor.

I would think CBM would be interested in HotLinks and turning it into more of an Amiga standard with more datatypes support. I would think it could fit with datatypes.library, Japanese support and IFF development at the time. It does require some effort from developers and is business oriented where the Amiga was lacking. Maybe it wasn't worth it for the few users that would use it.

OlafS25 Quote:

as I understand it, most documents with future plans were written for investors Commodore urgently needed at its end time around 1993 to survive economically. In my view, if really realized, I doubt that it would have been a success. There were reasons why both INTEL and Microsoft were interested to stay compatible to old software.

In addition to current investors, CBM was appealing to businesses and investors interested in buying or bailing them out. They needed a white knight.

https://en.wikipedia.org/wiki/White_knight_(business)

If CBM PA-RISC hardware had been further along for Windows NT, Microsoft may have been the white knight for CBM instead of Apple. Apple made plenty of mistakes too. From the "Future Product Options" doc, they had similar plans to expand into other markets including embedded where the iPad may have saved Apple and the iPhone made them the most valuable business in the world.

OlafS25 Quote:

Hombre would have been something completely new

There were many ways to deploy Hombre.

RISC/3D desktop/PC
CD^3D Console
3D graphics card (for Amiga, PC clones, etc.)

vox Quote:

It was planned CBM route for "AmigaNG", also WindowsNT drivers for it as NT4.x PA RISC existed at time :D

Windows NT was an OS option for the desktop market (Windows isn't cheap and is fat further preventing already fat architectures like PA-RISC and x86-64 from scaling lower). The "Future Product Options" doc suggestions creating another OS for the low end which would likely be based on the AmigaOS if not a port.

vox Quote:

While m68k plus Hombre chipset could give Amiga boost and compatibility, it was never planned by CBM, or any m68k other by 060 by Motorola. However, FPGA of today is able of such experiments.

Hombre with 68k AA+ SoC was planned as an option to retain 68k Amiga compatibility (see the "Commodore Post Bankruptcy" docs toward the end). The 68020 class AA+ SoC would have likely cost $40-$60 USD to produce at introduction and would have dropped quickly from there. If you share memory with Hombre, it would become very cheap to include the 68k SoC so there was a large library of Amiga games on introduction instead of a few 3D games. The Sega Saturn initially outsold the Sony PS1 because the PS1 lacked games. This was even with Sega losing Mega Drive/Genesis compatibility because of a lack of OS but the Amiga CD32 has the AmigaOS and can be upgraded to a 68060 and even a full computer with relatively good compatibility (some games need WHDLoad but still work).

None of the docs I have found talk about the 68060 but it was likely still a big mystery unless they found out preliminary info from partnering with Motorola for the 68k SoC. Some CBM employees were worried about the 68k based on lack of 68040 competitiveness and thought they should bail to RISC ASAP. See a "Blue Sky Proposal" by Randall Jesup where he expects MIPS or 88k would be the winners of the RISC war. Motorola was sending "indications" that the 68k family was reaching the end of its lifetime and that the '050 and successors would only be minor improvements. Intel did the same thing at least twice, once early and once later when trying to switch to the Itanium before AMD64 stayed on the 808x/x86 upgrade path mostly because of compatibility. Compatibility was important for the Amiga too which is why the 68k remained and remains the correct path and AA+ was due to be deployed instead of the less compatible AAA. The 68060 ended up being a very good 68k CPU for the plans of the "Commodore Post Bankruptcy" doc. This is my observation and analysis but planning is required well ahead of lagging development and deployment where CBM lacked vision.

Last edited by matthey on 30-Sep-2024 at 10:47 PM.

@cdimauro

Quote:

cdimauro wrote: @agami I don't know if you are sarcastic or not, because... yes: OOP could be done with any programming language (even in assembly).

Yes, I was being sarcastic.

Because in reality anything that has a concept of objects can be "object oriented", including operating environments, but I was given a lecture by more than a few purists who insist the concept of being "object oriented" can only ever apply to programming languages.

_________________
All the way, with 68k

@Mobileconnect

Quote:

Mobileconnect wrote: @agami This clearly refers to implementing something akin to OLE on Windows or OpenDoc on Mac, so it's perfectly reasonable for the time period to be suggesting this. Imagine something like Reaction, except instead of individual widgets, it's entire application engines - a word processor, a spreadsheet and so on.

I am intimately familiar with the concept.

Quote:

Fortunately hindsight tells us that was a dead end - it adds nothing the end user wants while adding massive complexity to the developer. Apple abandoned OpenDoc in 1997. Microsoft still supports OLE, but when was the last time you used that feature, or used that feature and thought 'man, this still sucks after 30 years' like when you try to edit an Excel chart from Powerpoint.

Poor implementations of a concept do not necessarily mean that it is a bad concept.

Last edited by agami on 01-Oct-2024 at 01:56 AM.
Last edited by agami on 01-Oct-2024 at 01:55 AM.

_________________
All the way, with 68k