Quote:
Originally Posted by kerravon
If I target 68K, will my 32-bit OS and 32-bit applications still work on PPC? If so, that's everything I want.
|
As I understand it, the current OS 4.0 solution to this problem is to call an emulator to run the 68K application. I have no idea what happens if you want to run another OS this way.
Quote:
|
Good question. My understanding is that the Raspberry Pi comes with a BIOS on disk that gets loaded before the OS. I need to start somewhere. In the case of the say Amiga 500, Kickstart is in ROM, and I think it is quite legitimate to put in a floppy labeled "PDOS" and boot it and get a command prompt where you can type in "dir" and say "yep, that's an OS". Kickstart itself won't do a "dir".
|
Right, I see what you mean. The issue I'm getting at here is more along the lines of 'how does Kickstart read tracks/sectors from disk for you".
Quote:
|
Perhaps I can be selective in which Kickstart functionality I use? Remembering that I'm making a beeline to get GCC to recompile itself, and that I already have code to read/write FAT, all I really need is a Kickstart function that reads a 512-byte sector from a disk. And even that can be replaced at a later date.
|
Well, you can - to a point. You are not required to use all of Kickstart when booting from floppy. However, that might still not be as helpful as you'd hope.
Essentially, the issue as I understand it is that the trackdisk device in the Kickstart (which you'd need to use to read sectors from disk at the lowest supported level) is not built to be independent of the rest of the OS. Basically, the trackdisk device relies on the kernel for memory allocation and
probably runs as a task under Exec as well. If you want to stay compatible with that, you might have to define areas of memory that you can't interact with. And that'll get tricky as one of the areas Exec requires to properly function is the interrupt vector table and secondly, Exec does not guarantee that memory it allocates will be at certain addresses (so the trackdisk.device can end up allocating buffers at essentially a random address).
Basically, the issue is that for the Amiga, the BIOS and the OS are essentially intertwined to a high degree and that there is no official way to bypass this and just say, read a sector from a disk. This is one of the reasons why many Amiga games and demos (those that ditched the OS) back in the day usually had their own, custom made, trackloader to read from disk.
Quote:
|
Don't worry, I'm inoffensible. :-)
|
That's a useful attribute to have, but I'll still try to be friendly though
