@TRIPOS

Quote:

Yes to you the AmigaOne "is" Amiga.

Well it is right now because it runs an AmigaOS with which I'm typing this on.

But I have said it before that if I take the HD out of my AmigaOne there's noithing Amiga about it except some sticker on the board.

Quote:

Announcing updated Workbench 3.1 (October 30, 2014): http://www.amigaforever.com/news-events/classic-support-3-1/

From a company that makes an Amiga emulator so not exactly the real thing here.

Quote:

The whole OS is called Workbench. Maybe this will change in some future (which I very much doubt), but if it isn't - Deal with it! It explicitly can not be called "AmigaOS". The only thing called "AmigaOS" is that PPC OS published by Hyperion (not running on Amiga computers ).

I don't need to deal with anything. Whoever can call the OS what they like. But Workbench isn't the whole OS. It's just a user interface. Even if all the files are stoted on a Workbench volume. Boot into a shell and what do you see? It's isn't Workbench!

DOpus. ScalOS. DOpus 5 Desktop. What are they running on? It's isnt Workbench!

This is like saying that the Mac OS isn't called Mac OS, it's called Finder. Finder is the Mac OS. LOL.

Okay getting down to brass tacks and looking at this seriously. Kickstart. What does that say? Which incidently Workbench runs on.

AMIGA ROM Operating System and Libraries.

That's what Workbench runs on and that's the answer to our question. The Amiga OS isn't Workbench or AmigaOS.

It's AMIGA ROM OS!

And BTW, OS4 does run on an Amiga computer, it just happens to run on the CPU expansion card plugged in. The same as OS3 runs on my CyberStorm. Oh there's the obvious in front of us all along. OS1.x. OS2. OS3. We just dropped the Amiga.

@cdimauro

Quote:

UBoot is an open source support, so RDB support was added by some Amiga.

Yes by some AmigaOS4 developers. That part is closed sourced. Like the rest.

Quote:

But this does NOT make an UBoot machine an Amiga, otherwise even a PC can be named as Amiga.

Why, does a PC machine have firmware that can understand RDB? I didn't know that.

And of course, reading RDB doesn't make an AmigaOne an Amiga, since I didn't say it is an Amiga.

Last edited by Hypex on 22-Aug-2015 at 05:45 PM.

@Hypex
Quote:

Quote: UBoot is an open source support, so RDB support was added by some Amiga. Yes by some AmigaOS4 developers. That part is closed sourced. Like the rest.

Really? I doubt that. Being able to read the disk geometry is a rather central part of U-Boot, which can hardly be argued to be a standalone loadable module; Pretty much by definition, it needs to be linked into the U-Boot binary.

And you don't get to link closed-source stuff against U-Boot code and then distribute the resulting binary to users without at least offering them all the sources that went into that binary.

At least not legally....

Last edited by umisef on 21-Aug-2015 at 08:18 PM.

@umisef

RDB structure is not precisely a secret.

Last edited by NutsAboutAmiga on 21-Aug-2015 at 08:35 PM.
Last edited by NutsAboutAmiga on 21-Aug-2015 at 08:34 PM.

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

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @umisef RDB structure is not precisely a secret.

I am not sure I get your point. Hypex suggested that the code that was added to U-Boot to read RDB is closed source. So I am questioning whether the source code is a secret, not the structure it deals with.


(Off-topic: Oh, and while it has been a loong time ago, I seem to recall that what the minor details of an RDB (and the other linked-from-it structures) actually look like, as opposed to how they are documented to look like, was one of those little bits of insider knowledge that Olsen generously shared back when I was working on getting Amithlon to deal with RDB disks.Even more off-topic: I still can't believe that RDB parsing isn't part of the base 3.x kickstart, and that every single friggin disk driver had to reimplement it. Sparta!)

Last edited by umisef on 21-Aug-2015 at 08:59 PM.

@umisef

512 bytes per block, I remember recovering floppy disk on Amiga 500
anyway, I figured it out by just looking at raw data, it's not precisely rocket science.
my RDB code is part of Basilsik II.

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

@umisef

Fact refresher from December, 2007:

Where is UBoot for MicroA1?

and the link within that thread from November, 2007:

New UBoot ?

As Geri has stated, he made improvements but could not get the tools from Hyperion to integrate with the radeon.

Quote:

Hyperion didn't deliver these tools with the U-Boot source code, so I hope we can write our own.

In a thread lasting a year and 1/2 beginning in January, 2010:

AmigaOne uboot update project

I must state that the information given in this thread in not entirely accurate historically:
U-BOOT 1.1.1 or 1.1.4 or 1.2.0 ?!

Given the information before the last link is about an independent effort made long after Hyperion was working on uboot. In fact, it is stated in the above threads by @Rogue that he was no longer working on it anyway. @Geri, and others, however, were.

#6

Last edited by number6 on 21-Aug-2015 at 09:29 PM.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

ah, nevermind as well

Last edited by wawa on 22-Aug-2015 at 11:27 AM.
Last edited by wawa on 21-Aug-2015 at 10:59 PM.
Last edited by wawa on 21-Aug-2015 at 10:59 PM.
Last edited by wawa on 21-Aug-2015 at 10:58 PM.
Last edited by wawa on 21-Aug-2015 at 10:58 PM.

@KimmoK

Quote:

KimmoK wrote: @cdimauro >adding dsp to decode audio needed just a file in a folder etc.. >Like for audio, you required ad-hoc applications to use such DSP, since the o.s. had not even knowledge about it. IIRC, all mpega.library supporting apps were able to USE the DSP without knowing it. So OS provided library system. >>There have been amiga audio station with 4...7 sunries industries multichannel audio cards. Worked fully in sync with paula + housefull of MIDI HW. (at the time CBM died, so the audio station was scrapped) >See above: with dedicated applications All audio applications that supported retargetable audio/MIDI & asyncio.library.

I don't remember such libraries as part of the os. When were they been introduced?
Quote:

>>Initially, in late 80's, it was normal that only some application(s) did their output via some selected GPU card(s). >An application doesn't need to select a GPU for its output. ... But in late 80's (or y1990) the situation was like I said. To use accelerated 24bit graphics you used special applications for dual monitor output on Amiga.

Indeed. The o.s. haven't support for it.
Quote:

>>3 cards + AGA has been the max amount of display outputs I have seen myself on a big box 68k Amiga. >Can you use all of them at the same time? Yes. One example with three monitors: http://saku.bbs.fi/lehti/online/uusi/ajankohtaiset/kuvat/20v_vk09_3piv.jpg

I see (a weird Amiga 4000 also ). I think it works with the special apps that you have talked before, right?
Quote:

>>We have been talking many times about reimplementing AGA in SW, so that it's effects can be generated by using some modern fast CPU or via HW acceleration using modern GPU. >That only works on the CPU side, if you want an accurate emulation. I would want the effects not accurate emulation. ((actually I'm not THAT interested in old AGA, JanusUAE way is pretty OK)) (if CPU+chipset is not inside one emulator, like UAE, it's not accurate anyways)

Let's say this: if you only need to accelerate the conversion of an Amiga screen at o.s.-level (read: the application had setup such screen using only the o.s. APIs), than the planar-to-packed conversion can be offloaded to the GPU (albeit using the Copper APIs will be tricky to be emulated by the GPU).

Otherwise you need to emulate the chipset.
Quote:

UPDATE: This is the maximum of GPUs spotted on an 68k Amiga: CV64+CV643D+Picasso IV+Retina+CVPPC + AGA "All in a big tower with 7 Zorro 3." https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=7475&forum=11

I see. So RTG apps seems to have some way to select the proper monitor from the list of available ones.

@Massi

Quote:

Massi wrote: @cdimauro Quote: the video section of my Amiga 1200 stopped working at all A real Amigan would have repaired it That time reparations were possible, at least in Rome.

After more than 3 years from the Commodore demise, a realistic amigan which also saw:

- ESCOM's bankrupt;
- an uncertain future from the new owners;
- a destroyed Amiga market;
- all other competitors which were far away in terms of software and hardware;

sadly realized that the dream was ended, and didn't make sense to pure more money on a archaic system (68EC020@14Mhz with only 2MB and an obsolete chipset)...

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: UBoot is an open source support, so RDB support was added by some Amiga. Yes by some AmigaOS4 developers. That part is closed sourced. Like the rest.

UBoot is GPLed, so I expect that the changed sources will be made available, to let other users build it on their own.
Quote:

Quote: But this does NOT make an UBoot machine an Amiga, otherwise even a PC can be named as Amiga. Why does a PC machine have firmware that can understnad RDB. I didn't know that.

Why not? Linux, for example, supports the FFS.
Quote:

And of course, reading RDB doesn't make an AmigaOne an Amiga, since I didn't say it is an Amiga.

@number6

Rouge stated it was bad idea to compile U-BOOT, because you brick your AmigaONE.
Geri was working on a ROM switcher (hardware), so you work on ROM safely.
http://sourceforge.net/projects/uboot-amigaone/files/?source=navbar
Geri did not however upload or share any work on the ROM.

So from this point of view, now it is possible to fix u-boot, or make it better, add drivers and stuff to it.

However ROM as bundled with Hyperion code and GPL code. There is the "boota" command that loads the SLB2 from a fixed block on hard-drive. I guess it slight modified version of the "boot" command for Linux.

Actually, I do not think UBOOT can read RDB at all, its SLB2 that loads the kickstart modules.
The Hyperion modifications to uboot should be small, and easy to replicate, for anyone who wont's to try.

Last edited by NutsAboutAmiga on 22-Aug-2015 at 11:36 AM.
Last edited by NutsAboutAmiga on 22-Aug-2015 at 10:29 AM.
Last edited by NutsAboutAmiga on 22-Aug-2015 at 10:25 AM.
Last edited by NutsAboutAmiga on 22-Aug-2015 at 10:23 AM.

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

Never mind .

Last edited by Boot_WB on 22-Aug-2015 at 10:35 AM.

_________________
Troll - n., A disenfranchised former potential customer who remains interested enough to stay informed and express critical opinions.
opp., the vast majority who voted silently with their feet.

@NutsAboutAmiga

Quote:

Geri was working on a ROM switcher (hardware)

Yes, Bill Toner and Geri discussed that in the threads I linked to.

But that makes it sound like @Geri was doing only that. Truth is he made improvements to uboot. I'm not at liberty to post on his behalf as to what he accomplished.

Quote:

Geri did not however upload or share any work on the ROM.

If you're referring to the fixes, again, I can't comment.

Quote:

The Hyperion modifications to uboot should be small, and easy to replicate, for anyone who wont's to try

I don't understand "small, and easy" here. He needed the tools from Hyperion, who constantly refused to supply them. The reasons for this are covered in the threads I linked to. HJF made it very clear as to why. It's about both the build tools AND the dongle code getting removed btw. HJF has posted that he wanted the code removed. It's not his decision to make, and that's NOT who the team contacted.

the legal argument
Obviously "rip out" and removing the dongle code equate to the same thing.

I'm not going to argue the legality issue here, just posting the story so you can follow the issue in chronological order. I'll let you and @umisef "discuss" that aspect. I only have interest in whether something gets done or not...not so much the "reasoning" behind it.

Added comment by HJF:
the dongle code was certainly not my idea
If nothing else, this should give you an indication of how long this attempt at improvement has been going on...at least 7 years.

#6

Last edited by number6 on 22-Aug-2015 at 01:27 PM.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@Kimmok:
Quote:

This is the maximum of GPUs spotted on an 68k Amiga: CV64+CV643D+Picasso IV+Retina+CVPPC + AGA "All in a big tower with 7 Zorro 3."

Additionally, you can have up to four PicassoIVs in the same box. This is actually officially supported. The PicassoIV bootmenu has a drop-down list (normally it's greyed out, because most people don't have multiple PIVs), where you can select between the four cards to configure and set some options. Just saying.

@cdimauro
Quote:

I see. So RTG apps seems to have some way to select the proper monitor from the list of available ones.

As far as I know, this has little to do with "RTG" apps. An app has to support moving its window to a custom screen or a public screen, or opening one. (Or you can use promotion by external tools.) This screen has an ID, which describes which monitor driver it's going to use, and it's actually just the same if you have ECS only, but PAL and NTSC "driver" installed, or you have multiple RTG cards. Although RTG systems usually have an RTG mode selection dialog/API, and asl.library also provides a standard requester (which even works w/o RTG), all your application gets back from them is normal AmigaOS screen ID. Of course, if you app tries to deal with a screen ID which maps to an RTG card, then the RTG system will kick in and do its magic, and the application must be aware that it doesn't necessarily render to some planar screen in chip memory. But otherwise selecting between the various screens on various monitors is plain AmigaOS stuff.

_________________
MorphOS, classic Amiga, demoscene, and stuff
"When a bridge is not enough, build a Viaduct!"
"Strip the Amiga community of speculation and we can fit every forum on a 720k floppy" (by resle)

@Chain-Q: thanks for the explanation. I only had a TV for my Amiga 1200, so I had no interesting on monitors et all.

I've only one doubt. As you said, you can have up to 4 Picasso boards in your system, and RTG screens are bound to monitor driver, which handles them. But how do you select which physical monitor to be used for a specific screen, if all RTG screens are handled by the same monitor driver?

@cdimauro

They have different ModeIDs for each card.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@umisef

Quote:

Really? I doubt that. Being able to read the disk geometry is a rather central part of U-Boot, which can hardly be argued to be a standalone loadable module; Pretty much by definition, it needs to be linked into the U-Boot binary.

Yes, really. As stated it's in the boota command for A1 UBoot. Or as it was called years ago IIRC, the "dongle" code. But what I meant was it is in the UBoot binary of the firmware. But the code is closed source that enables booting OS4.

So UBoot has the diskboot command as standard and the boota command was added to read the RDB. So boota is part of the FLB or First Level Booter than scans the UBoot booting controller device units for an RDB in the first 256 blocks. That then loads the bootloader from the RDB bootblock of sorts Which is second in command as the SLB. The SLB presenting a volume menu and loading Kickstart.

Quote:

And you don't get to link closed-source stuff against U-Boot code and then distribute the resulting binary t

Well it was flashed to the firmware and then they had updates after that. So I suppose they did release a binary of sorts even if it couldn't be examined seperately.

@cdimauro

Quote:

UBoot is GPLed, so I expect that the changed sources will be made available, to let other users build it on their own.

Sure, the changes, except for the OS4 booting stuff.

Quote:

Why not? Linux, for example, supports the FFS.

It does. But Linux isn't a firmware. Except in a router where it's loaded by the bootloader. Does EFI know what RDB is? My point was a firmware, BIOS, EFI, or whatever being able to read RDB itself.

@Hypex

Quote:

Quote: And you don't get to link closed-source stuff against U-Boot code and then distribute the resulting binary Well it was flashed to the firmware and then they had updates after that. So I suppose they did release a binary of sorts even if it couldn't be examined seperately.

Precisely. It was distributed. Someone it was distributed to requested the source (in order to improve it). Yet that someone was never given the necessary source/tools to be able to implement improvements, because, it appears, Hyperion (who distributed the updated binaries) was unwilling to provide the sources/toolchain.

Which brings up the question what license grants Hyperion the right to distributed the U-Boot authors' code. Because the GPL does not grant such a license to anyone who isn't willing to release their code on request.

(Whether the RDB reading code is actually linked into U-Boot itself is not quite clear; It could be that said code is run from flash before U-Boot (possibly even being what loads U-Boot) and merely passes along some structures describing the disk layout. Hmmm, can U-Boot handle just a limited number of file systems, or can one include filesystem code hooked from the RDB and have U-Boot use that code?
Regardless, the fact that knowledgable users have been unable to compile their own replacement U-Boot is suggesting that GPL compliance of those firmwares is rather questionable)