17 October 2016, 07:29 | #161 |
Registered User
Join Date: Jul 2014
Location: Finland
Posts: 1,178
|
I'm not sure you'd even want to do native development on something like AmigaOS.
The native development tools are all extremely primitive compared by what is the norm today. |
17 October 2016, 08:15 | #162 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 532
|
Quote:
After the build has finished, you can literally copy the disk images to floppy disks and install a blank hard drive using them (well, just creating a blank partition suits the same purpose). Don't forget to copy the AmigaOS source code to that blank partition, while you're at it. You can then load the Kickstart ROM image appropriate for your machine, reboot it and boot from the recently installed natively-compiled Workbench. You can now restart the AmigaOS build again from scratch. Some small portions are, however, not built natively. These concern printer drivers, aux-handler, mathieeedoubtrans.library and mathieeesingtrans.library. These require a cross-compiler (aux-handler is written in BCPL and needs the BCPL compiler, the math libraries need the math runtime library of the Green Hills 'C' compiler) or are so old that porting them to a modern compiler makes little sense (Alphacom, Diablo 630, Howtek Pixelmaster, Seiko 5300, Sharp JX-730, Tektronix 4693d, Toshiba P351SX, Xerox 4020, etc.). Replacements for aux-handler and the math libraries exist, and in this case work better than the originals Even with these small omissions, it has been possible for some 18 years for the Amiga operating system to fully build itself on an Amiga. Well, that was mostly my Amiga 3000UX with a 50 MHz 68060 CPU, but you get the general idea Last edited by Olaf Barthel; 17 October 2016 at 09:20. |
|
17 October 2016, 09:24 | #163 | ||
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 532
|
Quote:
When native development became possible for AmigaOS, it completely changed the operating system development culture at Commodore. Workbench/Kickstart 2.0 did benefit enormously from native development. It was not just "eating your own dogfood", the native development tools were considerably more powerful than the tools which had been used before. Quote:
|
||
17 October 2016, 10:24 | #164 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 532
|
Quote:
I keep wondering which setup was used before that, after having read that the early work on the Amiga hardware and the operating system was using SAGE computers, but I digress. Up until Kickstart/Workbench 1.3 the cross-compilers were still being used, and development work only moved slowly to "native development" with Lattice 'C' 4, SAS/C 5 and 6, Manx Aztec 'C' 3.6, etc. Some components were rewritten so that native compilation could be used, but some were never adapted, e.g. audio.device, intuition.library, printer.device and most of the printer drivers were still being built using the cross compiler at the time when Commodore shut down in 1994. Last edited by Olaf Barthel; 17 October 2016 at 12:00. |
|
17 October 2016, 13:01 | #165 |
PSPUAE DEV
|
|
17 October 2016, 15:34 | #166 |
Registered User
Join Date: Mar 2009
Location: New York
Posts: 552
|
Wait what, so the so-called Classic AmigaOS is going to work on the Tabor?
|
17 October 2016, 15:52 | #167 |
Registered User
Join Date: Apr 2011
Location: Stoke on Trent
Age: 52
Posts: 63
|
|
17 October 2016, 17:39 | #168 |
old bearded fool
Join Date: Jan 2010
Location: Bangkok
Age: 56
Posts: 779
|
Was holding my breath there for a while looking at the Tabor A1222 motherboard, thinking the Lattice FPGA on the board had enough speed rating and gates (logic elements) to hold the Apollo core, but doesn't seem like it, it's a LCMXO2-1200HC.
So I guess it's classic emulation in software then, not hardware. |
17 October 2016, 20:36 | #169 |
Registered User
Join Date: Aug 2007
Location: berlin/germany
Posts: 1,054
|
|
17 October 2016, 21:05 | #170 | |
Registered User
Join Date: Aug 2007
Location: berlin/germany
Posts: 1,054
|
Quote:
okay.it sounds fine but still rather complicated. im all for building system natively, still i have doubts of advantage of it if it takes hundred times longer than cross compiling. i wouldnt insist on it no matter what. actually to illustrate my workflow with aros 68k in comparison, i build or rebuild the whole os or desired module, like particular library or executable under linux crosscompiler after modification. using vmaretools feature i can simply copy the files in an instant over into a directory declared a winuae masstorage media and boot from there. when staisfied testing there i can attach an sd card or another masstorage media via usb to winuae and copy the data on that media, that i can use then to boot an actual amiga. to test the kickstart even there, you have to softkick it of course. none in their right mind would burn an eprom every time there is something to new test. i must admit i have not booted from a floppy since a while, but this is an option as well, since floppy images are being built alongside if you choose so. this as example, i think it might be beneficial to organize build process of amiga-os in a similar manner, if a bigger team was expected to be involved. if you simply build it only yourself, or with one ot two collegues who are building only specific parts and know since years how to do it, then there is no problem of course. but admittedly licensing is what is a major issue, here, not the logistics. |
|
17 October 2016, 21:39 | #171 | |
Registered User
Join Date: Jul 2014
Location: Finland
Posts: 1,178
|
Quote:
That is looking at the perspective of working on AmigaOS as a true general purpose OS which should be fit for all use and on which you expect to also run and improve your (or the third party) development tools while you are at it. Those conditions don't hold true any more. Nowadays AmigaOS has only very specific application areas and you don't expect it to have the best native development any more. As such I would see working on it far more like how you would work on a VxWorks or Embedded Linux based system. Of course this doesn't mean your system shouldn't have proper unit tests etc :-) From what I have seen from the terrible AmigaOS 'build system' and read from you're comments I would take a bit more 'brutalist' approach to getting this to work. Create harnesses for virtualised instances of all the exotic build environments and just build/populate/run/extract on the fly from you're build system. Setup would be laborious but once created it would greatly improve productivity (think of the free CI :-D) You could build all of this on a stack of {Svn,Git}/Jenkins/UAE/QEMU/etc /Fun!/ |
|
17 October 2016, 22:38 | #172 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,334
|
The main reason I think it wouldn't be technically useful is reliance on actual features of different compiler. That's also the main reason I think it wouldn't be technically feasible. It's nice to have, and taken for granted if you're doing GNU bloatware, but not always an option if your target is a 512 kB ROM and you can't just buy more address lines.
|
18 October 2016, 06:35 | #173 |
Registered User
Join Date: Mar 2009
Location: New York
Posts: 552
|
I have to say, if that's the case, the Tabor sounds more and more like something I would be interested in buying. I'm adding A/EON to the list of people to contact about this open source research and campaign.
On that note I want to echo what was said above regarding that podcast with Cloanto. Really worthwhile, and gave me an increased sense that this might not be as hard as it sounds. |
18 October 2016, 07:10 | #174 |
Registered User
Join Date: Jun 2010
Location: USA
Posts: 97
|
It's a little early to be working on build process improvements to source we don't have access to, don't you think?
That's the least of our problems at the moment and easily fixed if building a whole 4MB of binaries for a complete rebuild is an issue. wXR: Assuming Tabor can run some version of UAE or even a custom chipless 3.1, why bother with a $600 1.2GHz PPC? My 2 year old cell phone has far better specs and I can make phone calls. Focus on opening the source and I'll give you a dual 2GHz PPC Mac to port it to if that's what you're after. |
18 October 2016, 07:58 | #175 |
Registered User
Join Date: Jul 2014
Location: Finland
Posts: 1,178
|
|
18 October 2016, 11:10 | #176 |
Registered User
Join Date: Aug 2007
Location: berlin/germany
Posts: 1,054
|
i think the discussion is about that the source in question must not be kept unmaintainable and how workflow on it could be improved. but of course, possibility that something happens is in a range of promiles.
|
19 October 2016, 10:57 | #177 | |||
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 532
|
Quote:
Quote:
Does anybody reading this thread have experience in how to deal with legacy code on a platform which was developed using assembly language and 'C'? The most straightforward definition of "legacy" code I read in recent years was that it referred to program code which lacked testing mechanisms. The literature which I found on the subject was not particularly helpful, because it covered testing only in the context of object oriented programming languages. Rewriting the existing code in a language which makes this kind of testing easier seems to be a non-starter. I already received some criticism for even suggesting that assembly language has its limitations. How do you retrofit tests to this type of code? Is this even a good idea? Quote:
Each Commodore engineer was basically his own build engineer, and no two operating system components were likely to have anything in common when it came to building them. The current build system uses GNU make and, with the exception of the process which cranks out ROM images and disks, is self-configuring with regard to what needs to be built. It's documented, the complete source code to all the tools is available. It's only 18 years old, and judging from today's offerings in terms of build systems, I find it hard to discard "make". Those who do not know "make" are bound to reinvent it over and over again, poorly But then again, those who know "make" often wish they had something better instead... |
|||
19 October 2016, 11:36 | #178 |
Registered User
Join Date: Feb 2015
Location: Sweden
Age: 50
Posts: 2,953
|
@Olaf Barthel
Short question, where is the OS3.9 source (which was extensively modernized over 3.1) kept? Who manages it as we speak? Skickat från min LG-H850 via Tapatalk |
19 October 2016, 12:22 | #179 | |
Registered User
Join Date: Aug 2010
Location: Germany
Posts: 532
|
Quote:
The source code of what was sold as AmigaOS 3.5 and 3.9 is not stored in a single repository. This is because for each of these projects a number of developers came together, each of whom contributed to the resulting product. These projects were managed by Haage & Partner who themselves contributed software to the respective products. From Haage & Partner's perspective the AmigaOS 3.5 and 3.9 updates would consist mainly out of material licensed by third parties, these being Amiga International and the individual developers, respectively. When Hyperion picked up development work, it licensed the material created by the AmigaOS 3.5 and 3.9 developers, where possible (some did not license their material), as well as the Amiga operating system source code from Amiga, Inc. Haage & Partner chose not to license the code they had produced (they quit the Amiga market shortly after the AmigaOS 3.9 release was complete). This means that most of the material that was used in AmigaOS 3.5 and 3.9 wound up as the foundations on which AmigaOS4 was built. The gaps left by the material which Haage & Partner and other developers had not licensed for use in AmigaOS4 have been filled by now. And it's time to answer your questions The AmigaOS 3.5/3.9 source code which Hyperion has licensed is stored in a subversion repository, along with the AmigaOS4 source code. What exactly happened to the code outside this scope is (at least to me) unclear. Could be that it's sitting on a set of floppy disks, CD-ROMs, Zip or DAT cartridges somewhere in storage. Could be that it's been lost. To the best of my knowledge, the source code, as stored in the subversion repository for AmigaOS4, is the only copy which is being managed at all. For the time being, I am responsible for keeping it safe and sound. |
|
19 October 2016, 12:39 | #180 | ||||||
Registered User
Join Date: Jul 2014
Location: Finland
Posts: 1,178
|
Quote:
I was not saying you should compare AmigaOS in its application area to VxWorks or so. We can all agree that this whole 'AmigaOS for embedded!1' thing people whine about is stupid. What i meant is development methods. Quote:
Quote:
Quote:
Quote:
Quote:
|
||||||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
SWOS 16/17 - The official unofficial update! EDITORS WANTED! | Playaveli | Retrogaming General Discussion | 99 | 28 October 2017 19:58 |
Hyperion page does not start, is broken | vitux | Amiga websites reviews | 2 | 20 April 2013 19:59 |
Hyperion Announce AmigaOS4.1 Update 1 Now available for download | Mikey_C | News | 6 | 24 January 2010 15:04 |
Amiga Inc. Sues Hyperion VOF. | Ultron | News | 55 | 25 December 2007 23:08 |
|
|