Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Topic started by: deadwood on October 14, 2010, 06:30:30 PM
-
The Kickstart ROM Replacement (Phase I) bounty has been assigned to Jason McMullan. The bounty aims at enabling AROS to build for m68k Amiga system. This part does not include binary compatibility with existing m68k Amiga applications. The deadline for this work is 31st December 2010.
Jason has been working behind the sceenes for some time and now he has started adding compatibility changes directly to AROS source code tree. For the time beeing he built the kernel and now is working on getting OCS driver implemented.
The bounty details and donate page can be found here (http://www.power2people.org/projects/profile/5)
-
This is great news. Not complaining, just asking, isn't this the second or third time this bounty has been assigned? Hopefully this time Jason will have better luck completing it.
Good luck Jason and thanks! Aros on 68k would be awesome!
Steven
-
Awesome?
A new kickstart will be interesting for amigaos 3.x, i dont see aros running under 030 and aga.
-
More details from the AROS dev mailing list:
Finally, after 3 weeks, first light on my m68k port of AROS to m68k-amiga.
Doesn't work, crashes pretty soon, but I have gotten path the 'compile it',
'compile it with Amiga ABI', and 'get into Exec Init' phases. Very happy.
Other than the giant pile of AROS patches I'll be committing as soon as I
get SVN access, I also have a (tiny) GCC patch that is needed to match
the Amiga ABI, and a e-uae patch to enable serial.
Against current AROS tip, gcc v4.5.1, and e-uae tip:
http://www.evillabs.net/AROS/AROS-2010-10-09-m68k.tar.gz
Also includes a pre-compiled A1200 ROM image, which boots
(and crashes).
---------- ROM Layout -------------------
400K Text, 34K Data, 78K Unused
(You can ignore the .sysbase, .stack, and .bss placeholders,
they take up no ROM space, they're just there for linking)
~/private/AROS $ m68k-elf-objdump -h bin/amiga-m68k/AROS/aros-amiga-m68k.elf
bin/amiga-m68k/AROS/aros-amiga-m68k.elf: file format elf32-m68k
Sections:
Idx Name Size VMA LMA File off Algn
0 .sysbase 00000008 00000000 00000000 00002000 2**0
ALLOC
1 .stack 0000fff8 00000008 00000008 00002000 2**0
ALLOC
2 .bss 000013d0 00010000 00010000 00002000 2**4
ALLOC
3 .text 0006363a 00f80000 00f80000 00002000 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
4 .rodata 00008b80 00fe363a 00fe363a 0006563a 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
---------- From my UAE session ----------
(NOTE: This is a stock Amiga 1200 (2M) simulation,
the output below the '=======' is from the UAE
simulated serial port)
Building CPU function table, 45674 opcodes (2 0 0).
Resetting frame rate hack
Using 24 bit visual, 32 bits per pixel
Using MIT-SHM extension.
reset at 0
PAL mode, 50Hz (h=227 v=312)
chipmem cleared
SERIAL: period=368, baud=9600, hsyncs=16 PC=f80d2e
====================================================
[reset]
[bss clear]
gdb stub[prep SysBase]
peb SysBase: 0004040e
PrepareExecBase [ret]: 0004040e
[init SysBase]
RomTagScanner: Start = 00f80000, End = 01000000
Resident modules (18) (addr: pri version name) at 0x40870:
+ 0x00feae1e: 127 3 "kernel.resource"
+ 0x00fe3ade: 105 41 "exec.library"
+ 0x00fe8822: 103 41 "utility.library"
+ 0x00fe6006: 102 41 "aros.library"
+ 0x00feb08e: 99 2 "processor.resource"
+ 0x00feabde: 92 1 "hiddclass.hidd"
+ 0x00fe72ba: 65 41 "graphics.library"
+ 0x00fe9c0a: 50 41 "timer.device"
+ 0x00fead6e: 45 41 "battclock.resource"
+ 0x00fe9f12: 44 41 "keyboard.device"
+ 0x00fe95fe: 40 41 "keymap.library"
+ 0x00fe9d3e: 30 41 "input.device"
+ 0x00fe89de: 15 50 "intuition.library"
+ 0x00fea062: 4 41 "console.device"
+ 0x00fe611e: -120 41 "dos.library"
+ 0x00fe675a: -123 41 "LDDemon"
+ 0x00fea4ee: -124 41 "con.handler"
+ 0x00feaabe: -125 41 "nil.handler"
[start] InitCode(RTF_SINGLETASK, 0)
[start] InitCode(RTF_COLDSTART, 0)
[libcall Exec Init]
[exec] GO GO GO!
################################################################################
# Software Failure! #
# Task 00000000 - --task not found-- #
# Error 81000005 - Corrupt memory list detected #
################################################################################
reset at f80ec0
And more news:
- Jason McMullan has now SVN access to the AROS tree
- ABI issues appear to be fixed (native)
- library init successful up to graphics.library and intuition.library
- working on OCS single-plane HIDD
-
Hmm... I don't wish to appear to be too negative, but what advantage would you get from running AROS on a 'classic' Amiga, over WB3.1?
Wouldn't it be better to concentrate more effort to improving AROS drivers and compatibility with x86 systems?
Just wondering...
Cheers,
Mike.
-
People need to stop thinking that what is to them "pointless" things to work on will somehow take away development from other parts of AROS! this is one guy who wanted to do this particular bounty, if he didnt work on this one, chances are he wouldn't work on anything else in AROS either, and this is true with a lot of bountys and other AROS related work. People come or join in to work on stuff they want and quite a few stop contributing to AROS once they reached they're goals whatever they may be.
Hmm... I don't wish to appear to be too negative, but what advantage would you get from running AROS on a 'classic' Amiga, over WB3.1?
Wouldn't it be better to concentrate more effort to improving AROS drivers and compatibility with x86 systems?
Just wondering...
Cheers,
Mike.
-
Benefits would be:
1. Working "out of box" Amiga clones, wihout needing permission from anyone
a) minimig
b) natami
c)...
* Minimig could be mainstream product with this
2. No need to build custom kickstart yourself
a) CD-rom boot, maybe rtg support build in
b) Possibility to manufacture and sell replacements kickstarts
3. Future developement
a) Projects like natami would get big benefit of this and theory maybe even coldfire accelerators.
b) ...
4.
-
....benefits once the binary compatibility phase is completed too, right?
-
Benefits would be:
1. Working "out of box" Amiga clones, wihout needing permission from anyone
a) minimig
b) natami
c)...
* Minimig could be mainstream product with this
2. No need to build custom kickstart yourself
a) CD-rom boot, maybe rtg support build in
b) Possibility to manufacture and sell replacements kickstarts
3. Future developement
a) Projects like natami would get big benefit of this and theory maybe even coldfire accelerators.
b) ...
4.
Then this idea isnt for real amigas, then another way to add to, mos, os4 and aros
-
Finally took the time to find out what on earth AROS was all about, basically to me it's just like MorphOS, WarpOS or OS4.x.
After all the posts I've seen here on Amiga.org with people praising AROS, I can only say that I'm kinda disappointed, was hoping to find that it was something that would be useful to me on my various A1200s, or have I missed the point about AROS... :confused:
-
Besides giving MiniMig and the like a compatible OS to run out of the box, it would also allow AROS x86 to be backward compatible with original Amiga software. With the UAE integration that has happenened, 68k software running on AROS x86 looks pretty good. The achillies heal of this it the fact that to legally run this you have to buy a commercial product. So, AROS x86 is backward compatible, but the backward compatibility is not open source like the rest of the OS.
If it helps you appreciate it, just think of it as Amiga68k.hidd.
-
Ignore....double post.
-
Then this idea isnt for real amigas, then another way to add to, mos, os4 and aros
No, it's for real Amigas. The point is to run AROS in 68k Amigas without having to rely on the Commodore licensed ROMs and to have an AROS user interface.
-
Finally took the time to find out what on earth AROS was all about, basically to me it's just like MorphOS, WarpOS or OS4.x.
After all the posts I've seen here on Amiga.org with people praising AROS, I can only say that I'm kinda disappointed, was hoping to find that it was something that would be useful to me on my various A1200s, or have I missed the point about AROS... :confused:
Unless I'm completely off the mark (it's been years since I help push this bounty into reality), the initial reason for this is to move forward on a FOSS kickstart ROM. Once someone picks up and completes Phase2, then there will be zero need for any commercial software (kickstart or WB) in UAE.
Can this be ported to individual Amigas for native running? With alot of work, I don't see why it would be impossible. AROS can be the life line for Amiga68K as future kickstart/wb upgrades. Life for your old friend may not have to stop at 3.9, just takes a huge amount of work is all. ;-)
-
No, it's for real Amigas. The point is to run AROS in 68k Amigas without having to rely on the Commodore licensed ROMs and to have an AROS user interface.
And to take advantage of a system that is being still developed, and has some neat modern features that AmigaOS for classics never had.
-
I'm not sure why this isn't exciting to Real Amiga owners.
New Kickstart
Potential for CD-Rom boot
Potential replacements for all outdated OS parts
Standards for drivers
Standards for RTG
Standards for PCI access
Most importantly, developers can finally develop RTG and other drivers, bypassing the assholes in control of Picasso, Cybervision and proprietary PCI buses. (If anyone has hurt the 68k cause, it's those guys)
And nobody can sue this project out of business, it's open source so it can live forever.
Once it is ABI compatible, this will be the biggest thing for Amiga since OS3.1!
-
Sounds good. Does anyone have a feel for how difficult the binary compatibility part will be to achieve? Also, how high-powered will your classic Amiga have to be in order to run AROS?
-
That's yet to be seen.
There is more to Aros than OS3.1, but then most of us don't run 3.1 as it shipped either.
I'm sure it will take more RAM, but with care there is no reason it can't have similar speed.
I'm sure initially it will be slower, but that can be fixed with enough skill and time.
It's incredibly hard to make binary patches for an OS you don't have the source code for, yet people have patched many improvements into the older AmigaOS.
It's possible that with the source code readily available to more developers, Aros could even be faster than 3.1 someday.
-
I'm sure it will take more RAM, but with care there is no reason it can't have similar speed.
Once it stabilizes, one can mix and mingle, and optimize further - no reason really that it must take more RAM, really :)
Great to see this finally going somewhere.
-
I dont see aros running under 030 and aga.
It already does in parts, you do know that there is AROS code in OS3.9, right?
-
Finally took the time to find out what on earth AROS was all about, basically to me it's just like MorphOS, WarpOS or OS4.x.
Maybe you should take the time to find out what WarpOS is also then :lol:
The point of AROS is to have an open source, portable AmigaOS clone that is "source compatible" with OS3.1. AROS running on m68k Amiga systems is supposed to be binary compatible with OS3.1. However, most of the effort till now has been on x86, since that's the most obvious system to work on, allthough thanks to people like MSchulz there's also AROS for PowerPC systems (SAMs), x86_64/AMD64 and ARM. There is also AROS for m68k since long (AfA), bits and pieces even found the way into OS3.9 (the oh so famous colourwheel, maybe more?), but the goal is to totally replace OS3.x on real m68k Amiga systems, just like the various MiNT incarnations replaced TOS on Atari.
On a side note, it would be interesting to know how far apart AROS on PowerPC is from MorphOS and OS4 in terms of binary compatibility.
-
Between using C instead of assembly and having many more (sorely needed) features, I'd bet on more RAM.
Probably less RAM than 100 different third party additions, but certainly more than 3.1 used.
-
People need to stop thinking that what is to them "pointless" things to work on will somehow take away development from other parts of AROS! this is one guy who wanted to do this particular bounty, if he didnt work on this one, chances are he wouldn't work on anything else in AROS either, and this is true with a lot of bountys and other AROS related work. People come or join in to work on stuff they want and quite a few stop contributing to AROS once they reached they're goals whatever they may be.
Not only this, but a working, binary compatible version of AROS on real Amiga's is pretty much the holy grail for determining how compatible AROS is with real AmigaOS.
I did a bunch of work to the console.device and console handler in AROS recently, and to debug incompatibilities with AmigaOS I had to spend a lot of time getting really old AmigaOS example code compile with AROS on x86. With AROS running fine on m68k Amiga's, I could've gone straight to running Amiga apps as test cases.
Getting it running should help us fix a lot of bugs and incompatibilities that will benefit AROS as a whole
-
As Vidarh just said this will help polish AROS and iron out bugs so we get an even more compatible "Amiga" OS out of AROS. I can only see good things come out of this.
@vidarh
Thanks for updating the console handler, it was very much needed.
-
it would be interesting to know how far apart AROS on PowerPC is from MorphOS and OS4 in terms of binary compatibility.
Very far apart.
-
Not only this, but a working, binary compatible version of AROS on real Amiga's is pretty much the holy grail for determining how compatible AROS is with real AmigaOS.
I did a bunch of work to the console.device and console handler in AROS recently, and to debug incompatibilities with AmigaOS I had to spend a lot of time getting really old AmigaOS example code compile with AROS on x86. With AROS running fine on m68k Amiga's, I could've gone straight to running Amiga apps as test cases.
Getting it running should help us fix a lot of bugs and incompatibilities that will benefit AROS as a whole
Indeed. MorphOS started with creating a static 68k emulation and running the original KS ROM. Then each module were replaced one by one with PowerPC native versions. This allowed us to run original 68k apps and identify and fix bugs and incompatibilities instantly. This is something AROS hasn't been able to do before (except in limited fashion thru AfA).
There's no question that AROS has thousands of issues that never have been fixed before. Hopefully the author won't get too frustrated.
To help avoid the frustration I'd recommend using the same method MorphOS used: Take original KS ROM and replace components one at a time. This will help debugging a lot. You can easily switch between original and replacement modules to see where some issue might originate. Eventually you wil be able to get rid of the original KS ROM completely and run on your own.
-
And to take advantage of a system that is being still developed, and has some neat modern features that AmigaOS for classics never had.
Which sounds great, as long as existing software runs on it and does n't take one look at the "new" OS and replacement ROM and decide to Guru.
If it does then stick to OS3.x and make OS3.x versions of any new AROS apps.
-
Hmm... I don't wish to appear to be too negative, but what advantage would you get from running AROS on a 'classic' Amiga, over WB3.1?
Wouldn't it be better to concentrate more effort to improving AROS drivers and compatibility with x86 systems?
Just wondering...
Minimig, FPGAArcade and Natami immediately come to mind.
Also the changes to make it more Amiga compatible can surely only benefit the project as a whole, making it more Amiga-like ultimately.
I don't know what a monochrome Aros will look like for the OCS driver! I think someone needs to get cracking on a monochrome theme for AROS Zune.
-
Very far apart.
Compatibility with MorphOS and/or OS4 binaries on PPC AROS would be the holy grail I imagine. :)
-
@vidarh
Thanks for updating the console handler, it was very much needed.
Thanks. I was desperate :D There's still lots to do there, though - I'm hoping to get some time to do more with it later. Work + ironing out bugs in the AROS FrexxEd port is holding me up at the moment.
-
Minimig, FPGAArcade and Natami immediately come to mind.
I don't know what a monochrome Aros will look like for the OCS driver! I think someone needs to get cracking on a monochrome theme for AROS Zune.
you can test ot for yourself, just turn don the color depth to minimum on your afa screen. i have written a small gadgets rplacement for =<8bit afa screens (fat from perfect but works) and tested it on all screen depths. well, i think it looks way cool. a little like ur olde apple finder;).
To help avoid the frustration I'd recommend using the same method MorphOS used: Take original KS ROM and replace components one at a time. This will help debugging a lot. You can easily switch between original and replacement modules to see where some issue might originate. Eventually you wil be able to get rid of the original KS ROM completely and run on your own.
@piru: i think it is quite important point worth to repeat again and again. the same technique applies to afa, thats why it works reliably. but i trust if someone has got already as far he will know that for himself
@thread: this bounty has maybe been taken and fallen many times already, but now it looks serious. also that it was assigned first after the coder has apparently made a proof of concept and the short assignment itself. if this is giong to be confirmed i will make some further funds loose for this, and am willing to test.
-
@wawrzon
After watching the dev-ml for the last few weeks I was starting to wonder if Jason actually slept. =D
If I recall he was posting patches for a week or so before he even mentioned he would be going after this bounty.
All in all this is great news =]
-
And to take advantage of a system that is being still developed, and has some neat modern features that AmigaOS for classics never had...
...partially because of limitations due to business reasons the CBM Kickstart authors were working under. Kickstart had to fit in the 512K ROM, period; no CD-boot, etc. I remember postings from them about developer meetings to try and reorganize code to squeeze in an extra 2 bytes(!) into the ROM. Let's go for a whopping 1 Meg !
-
I'm not sure why everything must go in ROM anyway, it seems very limiting if you aren't stuck with double-density floppies only.
Get the machine reading the drives, then load the rest from disk.
It's much more flexible and it's more easily fixed in the field, especially if CDRoms and USB are supported as boot media.
-
What like the original A1000 then
-
I didn't think of it that way, but yes, that could definitely work.
I was thinking more like my 4000T that has workbench.library on disk for a similar reason.
-
I'm not sure why this isn't exciting to Real Amiga owners.
New Kickstart
Potential for CD-Rom boot
Potential replacements for all outdated OS parts
Standards for drivers
Standards for RTG
Standards for PCI access
Most importantly, developers can finally develop RTG and other drivers, bypassing the assholes in control of Picasso, Cybervision and proprietary PCI buses. (If anyone has hurt the 68k cause, it's those guys)
And nobody can sue this project out of business, it's open source so it can live forever.
Once it is ABI compatible, this will be the biggest thing for Amiga since OS3.1!
Then you are talking of some Amigas, a new os oriented for rtg people isnt the real world talking of classic amigas.
-
I'm not sure why everything must go in ROM anyway, it seems very limiting if you aren't stuck with double-density floppies only.
Get the machine reading the drives, then load the rest from disk.
It's much more flexible and it's more easily fixed in the field, especially if CDRoms and USB are supported as boot media.
ROM usage for storing OS components was a good idea back in the times of slow and constrained space storage media, like floppies, early harddrives, and tapes (do you remeber tapes dont you?). As they were slow, rom was "the very best thing" they could use, and having portions of the OS over there, not only allowed faster operation, but they also enabled you to save precious storage space.
Times have changed: Rom is not that fast now compared to actual hardrives that are pretty quick and efficient. So a kickstart today, has really no sense to be in rom, it should be on a drive.
Only the bootstrap code should still be kept in rom.
-
Then you are talking of some Amigas, a new os oriented for rtg people isnt the real world talking of classic amigas.
Why do you think it would be "oriented for rtg people" just because it'll make it possible to replace drivers for those who want it?
The point of AROS being open source is that it means people can take it in whatever direction they want - those that want just original hardware can stick with that and still get enhancements; those that want to use all kinds of expansions can get them better integrated with the core. And those who want different hardware altogether can still enjoy an AmigaOS like OS.
It's not either/or.
-
>So a kickstart today, has really no sense to be in rom, it should be on a drive
?!???!??!??
-
Please ignore the dumbasses :lol:
-
Then you are talking of some Amigas, a new os oriented for rtg people isnt the real world talking of classic amigas.
ok, point taken, but if it stays reasonable compatible to these olde amigas (assume 500 sorts, which were anyway equipped with appropriate kickstart and os and probably cannot be expanded much beyound that) it is good to have an alternative to proprietary kickstart/os. even better if support for the amiga chipsets might be incorporated at some point.
-
>So a kickstart today, has really no sense to be in rom, it should be on a drive
?!???!??!??
Yes, definately, on a modern system.
Another advantage is that rom is of course read-only. You may use an eeprom, but then you will have to add complexity to the system for just reprogramming it.
To modify a file on a harddrive it is pretty easy and fast.
But hey, if you are still using floppies on an A500, then just keeping your old rom there, as it makes sense, as mentioned in my other post.
-
kickstart rom has an advantage that the system critical files cannot be easily deleted or modified by malicious software or simple oversight.
i am totally happy with the huge flash the deneb provides that can be used for this. the only complaint was that i would prefer to have all single modules loose in a plain directory instead still have to include a bootable kickstart image along. updating would be simple then.
-
kickstart rom has an advantage that the system critical files cannot be easily deleted or modified by malicious software or simple oversight.
i am totally happy with the huge flash the deneb provides that can be used for this. the only complaint was that i would prefer to have all single modules loose in a plain directory instead still have to include a bootable kickstart image along. updating would be simple then.
I agree that the Deneb is an elegant solution for having a rewritable kickstart rom. But then it is only available for Zorro Amigas! And it is not a cheap or simple solution (technically speaking) and what about the other non Zorro Amigas?
-
kickstart rom has an advantage that the system critical files cannot be easily deleted or modified by malicious software or simple oversight.
i am totally happy with the huge flash the deneb provides that can be used for this. the only complaint was that i would prefer to have all single modules loose in a plain directory instead still have to include a bootable kickstart image along. updating would be simple then.
Just out of interest, is there a site that hosts various modules that can be loaded into the Deneb?
Personally, I don't make much use of it ("No IDE" is about it), but I probably should.
-
It would be nice if one of those DIY programmable kickstart replacement boards could be turned into products one could buy :)
-
@darrin: no, i suppose there is no official sites you can download kickstart modules from for copyright reasons. also not every module fits every machine. so the best thing is get romsplit and remus utilities along with the patches they provide, disassemble your kickstart, patch modules and assemble again. if something went wrong, you can always start clear of your chnges mit denebs romoff option.
@kola: there were several projects like that, cosmos seems to be doing somthing alike and also on a1k there was an already tested project that never went into distribution. just as thor(r) says on natami.net the most difficult is not to design something but to produce and sell.
anyways individual computers have had a flash module product that fits into zorro slot, but dunno if this is bootable. elbox have had another similar, but i have never got it to boot. and finally i dont understand why not to get deneb instead, while you get both: a flexible flash and an usb controller all in one. the price couldnt be better. a1k diy solution had a target price of over 50 eut afair.
edit: typos, as always
-
@darrin: no, i suppose there is no official sites you can download kickstart modules from for copyright reasons. also not every module fits every machine. so the best thing is get romsplit and remus utilities along with the patches they provide, disassemble your kickstart, patch modules and assemble again. if something went wrong, you can always start clear of your chnges mit denebs romoff option.
Cheers. I'll add it to my huge "to do list". :)
It is a handy feature of the Deneb though, to be able to experiment and then shut it off if you make a dog's dinner of it.
-
it is not too difficult (if i managed) and obviously an underrated feature. dont forget to include powerwindows module into your custom kick.
-
i think deneb is a cheap *and quality* solution in comparison to anything that you could buy from some freak that solders it at home. none would ever bend his finger for less than 50 bucks. and this is just reasonable. also am i wrong that the clockport usb controllers from eab also have some flash? surely it would be enough for non zorro amigas.
-
Jason added another batch of codes to the AROS repository today. It is now possible for everyone to build AROS rom image for UAE - aros-amiga-m68k.rom. It does not do much yet, but progress is visibly made :)
If you are interested in supporting his work, you can donate using this link:
http://www.power2people.org/projects/profile/5
-
Progress update from Jason:
General:
* Added M68K exception handling
* Added Paula interrupt handling
* Debugged (mostly) task switching (Whew! That was *annoying*!)
Todo:
* Debug the Scheduler until it is working correctly
(currently the Frankenrom input.device is stealing all the cycles)
* Get Frankenrom to ask for a Workbench disk.
Current status by build type:
--target=amiga-m68k-eabi
- Untested for the last week. Probably broken
--target=amiga-m68k
- ALERT from input.device's task due to no keyboard device
amiga-m68k/Frankenrom
- input.device is stealing all the CPU cycles
-
@deadwood
Great!
Thank you for the updates, keep them coming.
-
Update:
______________________________________________________________________
I have successfully loaded my first disk block using Frankenrom with KS 3.0!
With Toni's help, I realized that I needed to enable DMA (DUH!) early
on after IRQs have been enabled, and KS 3.0 + AROS Exec will now get
to the point where it *sucessfully* loads the first disk block.
However, the screen is still black.
______________________________________________________________________
BTW when he mentions Toni, he is speaking of Toni Wilen, the author of WinUAE, who is now cooperating with Jason on this bounty.
-
Yup, Jason is progressing quite nicelly and with Toni's help we already got some low level drivers for Amiga.
Please remember that biunty is still open for donations!
http://www.power2people.org/projects/profile/5
-
Yup, Jason is progressing quite nicelly and with Toni's help we already got some low level drivers for Amiga.
Please remember that biunty is still open for donations!
http://www.power2people.org/projects/profile/5
Done :)
-
will do as soon as home again.
thanks for good news.
-
More updates from Jason:
Toni has had me put in the following M68K drivers while he waits for SVN access:
* keyboard HIDD
* mouse HIDD
* trackdisk.device
* cia/cib resource
* drive.library (supports trackdisk.device)
* potgo.resource
Also, I've un-unmaintained the M68K ASM utility.library functions.
I'll start bringing in stuff from the M68K 'unmaintained' exec and layers
libraries tonight.
-
from Jason...
First trackdisk-loader ADF that was able to run on AROS M68K is:
EXILE!
http://www.evillabs.net/wiki/index.php/AROS_m68k-amiga#Nov_16.2C_2010:_AROS_.28no_KS.29_ROM
Screenshot and AROS ROM image available. As always, A1200 'stock' configuration.
NOTE: This will *NOT* load any 'standard' DOS loading ADFs, only ones which have
custom non-DOS bootloaders.
But its a start.
-
Wow...
-
from jason...
First trackdisk-loader adf that was able to run on aros m68k is:
Exile!
http://www.evillabs.net/wiki/index.php/aros_m68k-amiga#nov_16.2c_2010:_aros_.28no_ks.29_rom
screenshot and aros rom image available. As always, a1200 'stock' configuration.
Note: This will *not* load any 'standard' dos loading adfs, only ones which have
custom non-dos bootloaders.
But its a start.
:D
-
from Jason...
First trackdisk-loader ADF that was able to run on AROS M68K is:
EXILE!
http://www.evillabs.net/wiki/index.php/AROS_m68k-amiga#Nov_16.2C_2010:_AROS_.28no_KS.29_ROM
Screenshot and AROS ROM image available. As always, A1200 'stock' configuration.
NOTE: This will *NOT* load any 'standard' DOS loading ADFs, only ones which have
custom non-DOS bootloaders.
But its a start.
Hmm, correct me if I'm wrong but doesn't UAE have a built-in KS ROM replacement being able to do exactly the same?
-
Yes, Toni Wilen(mr. WinUAE himself) has helped him get that far. Next/last step is booting standard DOS volumes (disc or HDD ... or CD?) I'd imagine. The future is bright.
-
Yes, Toni Wilen(mr. WinUAE himself) has helped him get that far. Next/last step is booting standard DOS volumes (disc or HDD ... or CD?) I'd imagine. The future is bright.
Very... :)
Back in the days we were so proud of our AutoConfig (TM still?) protocol over ISA/PCI early stuff, but since the end of 90s, I always think of a "shame" about not being able to boot from CD.
Good job!
-
Very... :)
since the end of 90s, I always think of a "shame" about not being able to boot from CD.
Which is no problem for CSPPC/CS III owners.
-
Hmm, correct me if I'm wrong but doesn't UAE have a built-in KS ROM replacement being able to do exactly the same?
Sure, from little acorns do big oak trees grow! I think the take home here is that systems which used to just guru now actually do something.
It should be noted that Toni actually beat Jason here and booted a floppy before him :)
-
Sure, from little acorns do big oak trees grow! I think the take home here is that systems which used to just guru now actually do something.
Not much yet, however. It gets really messy around the time dos.library gets into the picture. If good compatibility is desired there's a lot to do there.
Now that the easy part is over the real work can begin.
-
Not much yet, however. It gets really messy around the time dos.library gets into the picture. If good compatibility is desired there's a lot to do there.
Now that the easy part is over the real work can begin.
The DOS.library changes were already slated for the AROS ABI version 1.0 branch. That suggests that there will be some teamwork involved as well.
It will be work but it'd be a lot easier if some of the team could grant SVN access to the repositories. Toni Wilen is still waiting and so am I. It's a shame that the AROS team encrypted the SVN so that nobody could browse or download anonymously.
-
The DOS.library changes were already slated for the AROS ABI version 1.0 branch. That suggests that there will be some teamwork involved as well.
It will be work but it'd be a lot easier if some of the team could grant SVN access to the repositories. Toni Wilen is still waiting and so am I. It's a shame that the AROS team encrypted the SVN so that nobody could browse or download anonymously.
If I remember correctly the blame for that lies at the feet of Mr Fleecy Moss Esq.
-
It will be work but it'd be a lot easier if some of the team could grant SVN access to the repositories. Toni Wilen is still waiting and so am I. It's a shame that the AROS team encrypted the SVN so that nobody could browse or download anonymously.
So am I...
-
It will be work but it'd be a lot easier if some of the team could grant SVN access to the repositories. Toni Wilen is still waiting and so am I. It's a shame that the AROS team encrypted the SVN so that nobody could browse or download anonymously.
If you look on the Evillabs.net page, the very top of the page shows
how to get the GIT anonymous clone of the repo. Just ignore all
the SVN parts after the initial clone.
-
Not much yet, however. It gets really messy around the time dos.library gets into the picture. If good compatibility is desired there's a lot to do there.
Now that the easy part is over the real work can begin.
Well, I've said this before, why not join the Dev mailing list and watch the progress :)
I'm pretty sure you will find the current discussion about the BCPL interface interesting (both Jason and Toni seem keen on ensuring 1.3 compatibility :) ) and if there is a question or two which you can answer then your input would be a great help... Go on, ya will, ya will ya wil
-
Well, I've said this before, why not join the Dev mailing list and watch the progress :)
I'm pretty sure you will find the current discussion about the BCPL interface interesting (both Jason and Toni seem keen on ensuring 1.3 compatibility :) )
Actually I don't. Trying to do the BCPL interface in C isn't my idea of "fun". I'm sure it is possible, but IMHO certainly not worth the effort.
-
Actually I don't. Trying to do the BCPL interface in C isn't my idea of "fun". I'm sure it is possible, but IMHO certainly not worth the effort.
Well, I found that interesting... Though others on the list also feel it's not worth the effort.
Still can't hurt to take a peek, no?
-
This looks interesting: how can I join the mailing list ?
-
http://aros.sourceforge.net/contact.php#mailing-lists
-
Update:
Nov 12, 2010: AROS Shell
Yep, that's right. The AROS Shell prompt. Whee!
Capable of running:
* AROS Shell
* A number of trackloading games
Not yet:
* DOS loading games (no in-ROM shell to run their startup scripts)
What's horrible:
* Had to change the ABI to the Graphics/*LayerRom routines to use A4 instead of A5, due to GCC issues. That's in the EVIL.patch
* Doesn't boot if we're not strobing the serial port.
* It's a 1M ROM set.
ROMs + E-UAE configs + AROS System Floppy + EVIL.patch
AROS-r35388-EVIL.tar.gz
-
Well, I found that interesting... Though others on the list also feel it's not worth the effort.
Still can't hurt to take a peek, no?
BCPL-style pointers make me shudder.
-
Actually I don't. Trying to do the BCPL interface in C isn't my idea of "fun". I'm sure it is possible, but IMHO certainly not worth the effort.
After seeing both 'BCPL' and 'fun' in the same sentence, I had to read slowly to make sure Piru hadn't lost it :)
Martin Richards, who unleashed BCPL and Tripos on the world, is still around, retired, and apparently active:
http://www.cl.cam.ac.uk/~mr10/
He might enjoy the challenge, so perhaps someone could invite HIM to mess around with the BCPL mess? Sort of like a penance ...
-
After seeing both 'BCPL' and 'fun' in the same sentence, I had to read slowly to make sure Piru hadn't lost it :)
Martin Richards, who unleashed BCPL and Tripos on the world, is still around, retired, and apparently active:
http://www.cl.cam.ac.uk/~mr10/
He might enjoy the challenge, so perhaps someone could invite HIM to mess around with the BCPL mess? Sort of like a penance ...
Go on then, ask him! :)
-
Is doing the BCPL interface in C the only practical way to get 1.3 compatibility?
I think 1.3 compatibility is really important in the long run, even if just getting the current AROS running is the focus for the time being.
-
That is awesome!!
I've never noticed a section in a changelog before called
What's horrible:
:-)
desiv
-
I uploaded a video of AROS booting in UAE:
http://www.youtube.com/watch?v=xe5mrES3qXo
-
Is doing the BCPL interface in C the only practical way to get 1.3 compatibility?
I think 1.3 compatibility is really important in the long run, even if just getting the current AROS running is the focus for the time being.
yup.
-
I uploaded a video of AROS booting in UAE:
http://www.youtube.com/watch?v=xe5mrES3qXo
That is HOT!!! I like my pr0n geeky and that is GEEEEKY!!!! ;)
-
That is HOT!!! I like my pr0n geeky and that is GEEEEKY!!!! ;)
Put the sock down Matthew! Step away from the sock! ;)
-
Kickstart Bounty Phase I is completed!
http://aros-exec.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=5410&forum=4
Screenshot:
http://img508.imageshack.us/img508/9582/20101114.png
The first nightly build is available at:
http://www.aros.org/download.php
-
Kickstart Bounty Phase I is completed!
http://aros-exec.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=5410&forum=4
Screenshot:
http://img508.imageshack.us/img508/9582/20101114.png
The first nightly build is available at:
http://www.aros.org/download.php
YAY!!!!!! :)
Congratulations to all involved! :)
-
Put the sock down Matthew! Step away from the sock! ;)
Lol!!! So many here will have no idea what you are talking about... Oh and AROS on 68k, yay... MUTHA FRICKIN' YAY!!!!!!
-
It's awesome work by Jason (and Toni)... As soon as I get some time I'll start optimizing some of my code for it. Hope we will start seeing a flurry of updates from various other people now that it's possible to test.
-
Lol!!! So many here will have no idea what you are talking about... Oh and AROS on 68k, yay... MUTHA FRICKIN' YAY!!!!!!
I spend three years away and it's like I never left! :)
Colour me stupid but i just tried it with e-uae on Linux and get nowt but a purple screen. :/
-
Great news! :)
I guess it will get faster as Toni is improving the HIDD. For now most of the things are drawn using PutPixel()... By reading the mailing list it seems a lot of progress is beeing made.
About the BCPL: what's wrong with 1.3/BCPL ? Anyone with enough knowledge could explain ? :)
-
Lol!!! So many here will have no idea what you are talking about...
The old guard remember.
-
I spend three years away and it's like I never left! :)
Colour me stupid but i just tried it with e-uae on Linux and get nowt but a purple screen. :/
It's a serious pain to get it working at the moment, but you MUST have your settings identical to an A1200!
-
It's a serious pain to get it working at the moment, but you MUST have your settings identical to an A1200!
Will it kickflash on a real 1200 I wonder?
-
Great news! :)
understatement of the decade! The Amiga is now ours :) We are in control, we have our machine in our own hands.
Opensoure hardware and software! I can't tell you have happy I am!!
I guess it will get faster as Toni is improving the HIDD. For now most of the things are drawn using PutPixel()... By reading the mailing list it seems a lot of progress is beeing made.
About the BCPL: what's wrong with 1.3/BCPL ? Anyone with enough knowledge could explain ? :)
A lot of the old 1.3 software used to old TripOS function call system, which is based on a programming language called BCPL. Jason needs to implement that in order for these 1.3 programs to run... BCPL was heavily depreciated in 2.0.
-
BCPL is the work of the devil! lol
-
Can the Kickflash support 1meg roms?
-
BCPL is the work of the devil! lol
Actually the more I read about it, the more I like it... And let's be fair it did lead to C, so it was a very good thing (tm)
-
Can the Kickflash support 1meg roms?
Good question. :)
-
Kickstart Bounty Phase I is completed!
http://aros-exec.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=5410&forum=4
Screenshot:
http://img508.imageshack.us/img508/9582/20101114.png
The first nightly build is available at:
http://www.aros.org/download.php
I can't believe I've waited so long to see this... I hope everyone understands the enormity of what this means!
-
I can't believe I've waited so long to see this... I hope everyone understands the enormity of what this means!
The spoken lyrics in the intro to Primal Scream's 'Free' say it perfectly! :)
-
understatement of the decade! The Amiga is now ours We are in control, we have our machine in our own hands.
It means free, as in "freedom" :)
Even though the road may still be long to have a full working kickstart/os replacement (it's only a proof of concept here, compatibility wasn't part of the phase 1 bounty), it's great indeed.
Seeing how fast it was since the bounty has been assigned, I'm wondering why it took so much time for someone to get assigned to the task... People weren't interested maybe ?
From reading the mailing list, it seems some people aren't interested at all about NG stuff, while some on the contrary are only interested in NG stuff.
-
It means free, as in "freedom" :)
Even though the road may still be long to have a full working kickstart/os replacement (it's only a proof of concept here, compatibility wasn't part of the phase 1 bounty), it's great indeed.
Compatibility not required by bounty... But HUNK loading does work already and Jason has tested this with a few shell commands, so big thumbs up there!
Seeing how fast it was since the bounty has been assigned, I'm wondering why it took so much time for someone to get assigned to the task... People weren't interested maybe ?
I think getting the AROS source to build in gcc for the 68k was both boring and difficult... Jason (and Toni), stuck with it and made it happen!
From reading the mailing list, it seems some people aren't interested at all about NG stuff, while some on the contrary are only interested in NG stuff.
Well, AROS on 68k is where NG meets classic... You really can have the best of both worlds now :)
-
I can't believe I've waited so long to see this... I hope everyone understands the enormity of what this means!
Frankly I don't see the enormity. It gets interesting if/when Phase II gets completed.
-
Frankly I don't see the enormity. It gets interesting if/when Phase II gets completed.
The tyranny of Amiga Inc. is now over! This exists and it can't unexist :)
Toni has been instrumental in getting the 68k drivers this far, I have little doubt he will
succeed with phaseII and even if he doesn't, people will improve AROS 68k over time anyway :)
-
I'm sure Toni has the compatibility part covered although there are a lot of overall AROS changes that need to happen to get him there.
AROS is just somewhat source compatible, not remotely binary compatible.
I'm pretty sure we'll end up with 1.3 and 3.1 compatible ROMs plus AROS ROMs if we want any added functionality from AROS. I just don't see how both in one ROM could work.
This is really awesome news though, it's a huge step forward.
-
I'm sure Toni has the compatibility part covered although there are a lot of overall AROS changes that need to happen to get him there.
The latest version of gcc is being a pain, but Jason wants to replace that with LLVM... What else is there that have I forgotten?
AROS is just somewhat source compatible, not remotely binary compatible.
Careful not to FUD here, from Jason's statement:
3. Initially binary compatability isnt needed with amigaos (not until atleast you can get the thing working again)
**- Met and exceeded. AmigaOS HUNK loading appears to work for several
** *trivial 'C' compiled AmigaOS 3.x routines (ie Echo, Dir, etc)
So actually it is "remotely" binary compatible...
I'm pretty sure we'll end up with 1.3 and 3.1 compatible ROMs plus AROS ROMs if we want any added functionality from AROS. I just don't see how both in one ROM could work.
This is really awesome news though, it's a huge step forward.
Possibly the biggest step after the MiniMig/UAE freed us from ageing hardware :)
-
I'm pretty sure we'll end up with 1.3 and 3.1 compatible ROMs plus AROS ROMs if we want any added functionality from AROS. I just don't see how both in one ROM could work.
Do you have anything specific in mind? For the most part care has been taken to keep structures the same etc., and the only really major incompatibility I'm aware of that impacts "normal" user-level apps is the dos packet vs. device interface incompatibility which is slated to be fixed for 1.0; other than that there's a bunch of bugs and currently unimplemented bits and pieces of course, but that's a different matter.
Of course any code that relies on specific ROM offsets etc. to work will fail miserably, but most of that type of code started failing already with 1.3.
-
I wasn't trying to FUD, I'm a huge supporter of AROS on both 68k and x86.
I suppose I was a bit too harsh in saying "not remotely binary compatible", but having just a few cli commands is far from loading up a real application. Those haven't even touched the UI yet.
There is a lot in AROS that wasn't in OS3.1, for example the HIDD, that are required to be in the ROM. I'm not sure what the plan is, to support HIDD in ROM or have an OS3.1-like hardware banging arrangement, but shrinking it all down to 512k with HIDD seems unlikely.
Toni wants to make a 1.3 and 3.1 ROM for use with WinUAE and old games. Anything that is added will use more ROM space and push it further from 100% compatibility.
As much as our goals overlap, make no mistake, Toni has stated a free WinUAE ROM as his target which makes sense given his primary project.
As vidarh noted, ABI 1.0 will alleviate several of the problems I indirectly referenced, but we're not there yet. It will take more than just the ROM to get it functional.
I'm just saying that it's still a lot of work from all involved, not just Toni, but I'm extremely confident that he can pull off his part.
-
I wasn't trying to FUD, I'm a huge supporter of AROS on both 68k and x86.
I suppose I was a bit too harsh in saying "not remotely binary compatible", but having just a few cli commands is far from loading up a real application. Those haven't even touched the UI yet.
As usual the subtleties of language are generally lost on a web forum :) The ABI for the graphics library does use the wrong address register at the moment so in that regard there are binary incompatibilities, but these will be fixed.
It's important not to get the wrong message across, best to stick with the facts as they stand.
There is a lot in AROS that wasn't in OS3.1, for example the HIDD, that are required to be in the ROM. I'm not sure what the plan is, to support HIDD in ROM or have an OS3.1-like hardware banging arrangement, but shrinking it all down to 512k with HIDD seems unlikely.
A bare minimum should be possible with a 1Meg rom...
Toni wants to make a 1.3 and 3.1 ROM for use with WinUAE and old games. Anything that is added will use more ROM space and push it further from 100% compatibility.
That is up to Toni, there are plenty of ways to save ROM space if need be, as you say direct hardware control rather than using the HIDDs. But that is up to whoever is building the ROM :)
As much as our goals overlap, make no mistake, Toni has stated a free WinUAE ROM as his target which makes sense given his primary project.
As vidarh noted, ABI 1.0 will alleviate several of the problems I indirectly referenced, but we're not there yet. It will take more than just the ROM to get it functional.
I'm just saying that it's still a lot of work from all involved, not just Toni, but I'm extremely confident that he can pull off his part.
I am too.
-
I wasn't trying to FUD, I'm a huge supporter of AROS on both 68k and x86.
I suppose I was a bit too harsh in saying "not remotely binary compatible", but having just a few cli commands is far from loading up a real application. Those haven't even touched the UI yet.
There is a lot in AROS that wasn't in OS3.1, for example the HIDD, that are required to be in the ROM. I'm not sure what the plan is, to support HIDD in ROM or have an OS3.1-like hardware banging arrangement, but shrinking it all down to 512k with HIDD seems unlikely.
I don't think the HIDD adds all that much - the code to bang the hardware needs to go somewhere. The HIDDs just adds a tiny bit of indirection. Some work might be needed to allow excluding generic versions of the code paths, though, and I'm sure there'll be other optimization work along similar lines to selectively reduce the code generated.
Also it doesn't necessarily all need to fit in 512k. First of all most Amigas can take 1MB kickstarts if you're first going to replace the ROM (and for Toni's needs this works fine for most uses anyway, as UAE handles 1MB ROMs). Secondly for most purposes it only needs to bootstrap and load the rest from a device, though of course this wouldn't be great for Minimig's or classics with just a floppy (but how many would leave their classic unexpanded and still want to use AROS on it?) and not ideal for UAE either.
The current x86 kickstart is 1.5MB, so 1MB doesn't seem too impossible, worst case by pushing various AROS-specific functionality to on disk modules. 512k might be a stretch. I might agree with you that if specific software has problems with that, then creating a custom 1.3 compatible kickstart might be worthwhile but I don't think you'll need to split 3.1 vs. "full AROS" as I don't think much software that works on 3.1 will make assumptions that can't be accommodated.
In terms of compatibility, there are some bits I know will cause minor problems (AmigaOS ConClip for example won't work with AROS console handler, and uses undocumented library calls, - but it'll be easy enough to prevent it from doing any damage by stubbing them out for cases where it's included on boot floppies etc.). I'm sure there are many others that I'm not aware of, so of course it'll be a lot of work, but since AROS is by no means set in stone and everything is set up for quite a bit of API breakage in AROS for 1.0 anyway, I think it'll get fixed.
The nice things about having the m68k port now is that we can start using real AmigaOS apps as test cases - that alone will probably make things progress a lot faster. For my console changes for example I wasted a lot of time cleaning up old console example code to get it to compile under AROS to compare with how it behaved under UAE, while with the m68k port I can hopefully soon run this code directly, side by side with two different UAE configs.
-
I doubt many would want AROS on an unexpanded classic (Although I could be wrong), I think that it will be a big deal for systems like the MiniMig. A lot of us want to be able to buy brand new classic Amigas. Given how poorly AInc has behaved, many of us would rather they become a footnote denoting the dark time between Commodore and AROS.
You point out that most Amigas can take 1MB kickstarts. Is there any case where we should not be able to use a 1MB kickstart in a MiniMig?
-
Not all Minimigs have enough memory to be very usable that way. Also the current firmware doesn't support 1MB kickstarts AFAIK, but that ought to be easy enough to fix (or work around by having a 512KB kickstart that loads the rest as part of bootstrapping.
The FPGA Arcade cards or Natami are probably better suited... But we'll see how far down in size Toni and Jason manage to squeeze the ROMs..
It also depends on what you want to use it for. For trackloading hardware banging games a minimal kickstart would likely be enough. For system friendly harddisk images it won't matter too much if it'd need to load additional modules from disk. ADF images for games that are sort-of system friendly might be the biggest hassle, as they might rely on more of the kickstart and not have enough space to start messing with them to add additional modules.
EDIT: Despite the lack of 1MB kickrom support at least on my Minimig, I tried to just load the first 512K ROM anyway to see how far it got in the boot process - unfortunately it just went to a blank purple screen. Not too surprising, but I just had to give it a go anyway :)
-
Would the extra memory from the memory upgrade make it possible to have as much free usable memory as a non-upgraded MiniMig?
-
ADF images for games that are sort-of system friendly might be the biggest hassle, as they might rely on more of the kickstart and not have enough space to start messing with them to add additional modules.
What is the problem if you install those to hard disk using whdload? Also, I do not think there will ever be a 1.3 compatible aros kickstart, but then again, whdload solves the problem quite nicely.
-
What is the problem if you install those to hard disk using whdload? Also, I do not think there will ever be a 1.3 compatible aros kickstart, but then again, whdload solves the problem quite nicely.
I'm sure there will be, do not underestimate the genius that is Toni Wilen! :D
-
I'm sure there will be, do not underestimate the genius that is Toni Wilen! :D
And Jason's dedication to getting BCPL calls working ;)