Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: MskoDestny on November 09, 2005, 04:30:59 AM
-
I'm writing an operating system and I'm thinking about doing my initial development on it targetting the Amiga (specifically my A4000). So I'm looking for information about two things:
1) How to gain complete control over the processor (get into system mode basically)
2) How to control the basic Amiga hardware without any help from the OS libraries/kickstart ROM.
Since the idea is to replace Amiga OS once the new OS is loaded, there's no need to be system friendly (beyond being able to boot after workbench has loaded). Also the Amiga won't be the primary target(well unless a bunch of weird Amigans want to run a PalmOS clone on their Amigas for some reason) in the long run (it's just a fun and accessible place to start) so making the bootloader flexible isn't a big requirement. It just has to work on my Amiga.
-
No offense meant, but you asking these questions (esp. 1) kind of leaves me in doubt that you're really up to the task...
If you don't target the Amiga as primary system, but just use it as a development platform, there's no need for 2) since you leave it to normal Kickstart to setup the hardware (RAM, caches, IDE, video, ...) and then take over the machine much like most games do it or other OSes.
If you're going to ask 'Then how do I take over the machine?' you're definitely not up to it, sorry.
Furthermore, writing a modern OS is nothing one single person can do in his lifetime...
-
To get you started the following might be of interest:
movea.l 4.s,a6 ;Execbase
jsr _LVOForbid(a6) ;Disable multitasking
lea $dff000,a5 ;Custom chip base
move.w #$7FFF,intena(a5) ;Disable interrupts
move.w #$7FFF,dmacon(a5) ;Disable DMA
..... You can now do what you like :)
If you are running on 68010+ your VBR will be 0 at this point.
This code can be on a bootblock. But of course if you disable everything then you'll need to make your own raw trackloader. (Isn't that hard).
-
..... You can now do what you like :)
If you are running on 68010+ your VBR will be 0 at this point.
Are you sure? LVODisable does not change VBR, and I never heard that forbid does...
-
@MskoDestny
hwstartup.asm (http://www.iki.fi/sintonen/src/hwstartup/hwstartup.asm)
The code does a bit more than is really needed, and also includes cleanup code, but at least it should give you some idea what needs to be done.
-
@msh5150
movea.l 4.s,a6 ;Execbase
jsr _LVOForbid(a6) ;Disable multitasking
lea $dff000,a5 ;Custom chip base
move.w #$7FFF,intena(a5) ;Disable interrupts
move.w #$7FFF,dmacon(a5) ;Disable DMA
Forbid is not enough, you must Disable.
If you are running on 68010+ your VBR will be 0 at this point.
There is no guarantee of this. Better not assume anything about the initial VBR value.
-
Even though you don't return to the OS, you really should first call LoadView(NULL), followed by two WaitTOF()s. This is so that if the user launches your OS after AmigaOS has booted, any graphics card screens are guarranteed to be switched out.
-
When in a bootblock I've never had my VBR be anything other than 0. But to cover all bases then use _LVOSupervisor() to do a VBR read.
Is a need to call Disable()? I've killed interrupts in hardware with the intena write surely?
@xeron
Yes, he probably should :-D (Hi BTW - was there ever another Fast Intro Comp on #amigascne? Or a sequel to DotMatrix? 8-) )
-
Hey Musashi, no there never was another #amigascne fast compo. I've done the following scenish things since then:
http://www.pouet.net/prod.php?which=12044
http://www.pouet.net/prod.php?which=16349
http://www.pouet.net/prod.php?which=18905
http://www.pouet.net/prod.php?which=16308
-
Could be a good idea to have a look at the NetBSD for initialization purposies and hw interface. BTW, if you do not plan to use the MMU (by far, a complicated task), could be a good idea to target the A500 or A600. A lees complicated processor. Try to use UAE to run your soft, that will save you plenty of time ;-)
As was already demostrated several times, a modern kernel can be done by one person. A modern OS is a bit more than a kernel. But a working shell should be your safe bet milestone.
-
you're definitely not up to it... just give up and start on a easyer project...
________
Ford Falcon (Argentina) Specifications (http://www.ford-wiki.com/wiki/Ford_Falcon_(Argentina))
-
Zac67 wrote:
No offense meant, but you asking these questions (esp. 1) kind of leaves me in doubt that you're really up to the task...
Well I could just poke the vector table (either the reset vector or some interrupt I know is going to happen soon), but I figured it would be wise to ask here the best approach in case there were any gotchas I should worry about. For all I know the vector table could be in ROM and you can't exactly muck about with VBR in user mode. Heck on many operating systems you can't even poke around in the vector table because it's protected with the MMU (though as I understand it that's not the case on the Amiga).
If you don't target the Amiga as primary system, but just use it as a development platform, there's no need for 2) since you leave it to normal Kickstart to setup the hardware (RAM, caches, IDE, video, ...) and then take over the machine much like most games do it or other OSes.
It's difficult to write a proper pre-emptive scheduler that runs in user mode. Besides, part of the reason I'm targetting the Amiga is to better understand how the hardware works.
If you're going to ask 'Then how do I take over the machine?' you're definitely not up to it, sorry.
Okay Mr. Bad Attitude.
Furthermore, writing a modern OS is nothing one single person can do in his lifetime...
AtheOS was written by a single person. It's now maintained by several people as Syllable, but it was a complete modern working operating system as AtheOS. I've already written an implementation for most of the functionality in the Palm OS memory manager (though once I tackle the MMU, I need to tweak the memory allocator so that two processes can't allocate memory in the same page and to deal with fragmentation using the MMU) and that probably took about a days worth of effort, two at the most.
movea.l 4.s,a6 ;Execbase
jsr _LVOForbid(a6) ;Disable multitasking
lea $dff000,a5 ;Custom chip base
move.w #$7FFF,intena(a5) ;Disable interrupts
move.w #$7FFF,dmacon(a5) ;Disable DMA
But that will leave me in user mode won't it? Is code in the bootblock of a floppy started in system or user mode? Is there a guide on the format of the bootblock somewhere?
From hwstartup.asm:
; if full interrupt control is desired, _main must _LVODisable,
; save intenar and disable all interrupts by writing $7fff to
; intena. to restore, write $7fff to intena, or $8000 to saved
; intenar value and write it to intena, and finally _LVOEnable.
So I'm guessing intenar is the read version of intena and that intena is used to control the interrupts generated by the hardware?
Could be a good idea to have a look at the NetBSD for initialization purposies and hw interface.
Reading driver source code to figure out how the hardware works is a bit of a pain. I suppose the bootloader might be useful, but the code Piru posted seems to have set me in the right direction.
BTW, if you do not plan to use the MMU (by far, a complicated task), could be a good idea to target the A500 or A600. A lees complicated processor. Try to use UAE to run your soft, that will save you plenty of time
Well I do plan to use the MMU eventually and unfortunately neither the A500 or UAE have an MMU. One of my goals in this project is to bring memory protection to classic Palm OS and I will need to deal with memory fragmentation and I'd rather not use the hackish mechanism Palm OS 5 and below use to deal with that.
-
Well I do plan to use the MMU eventually and unfortunately neither the A500 or UAE have an MMU. One of my goals in this project is to bring memory protection to classic Palm OS and I will need to deal with memory fragmentation and I'd rather not use the hackish mechanism Palm OS 5 and below use to deal with that.
Are you sure? I'm could have sworn that the 040 emulation in UAE does support the MMU...
-
A quick google shows mention of a preliminary MMU patch, but I haven't seen any evidence this was integrated into the main source tree. It also looked like it might not be working 100%.
Frankly, I've had bad experiences in the past testing code on emulators so I'd rather not do it now.
-
"But that will leave me in user mode won't it? Is code in the bootblock of a floppy started in system or user mode? Is there a guide on the format of the bootblock somewhere?"
Yes it will. If you want to be in supervisor mode use the exec call _LVOSupervisor() and then take over the machine after that.
The bootblock is 1K long. The first 4 bytes are 'DOS' and then a number. Usually 0, but can be others. You can also use the word 'BOOT' for the first 4 bytes (I think).
The next 4 bytes are the checksum. Amiga won't boot your code unless this is correct.
The next 4 bytes are a block pointer to the root block (this can be ignored as you are making your own system and don't need to adhere to AmigaOS specs).
You can find more info about it here:
http://amiga.emugaming.com/adfaq.html
IMHO you might be best off doing some 'oldskool' hardware bashing code first to learn about the hardware (like trackloaders or copper/blitter effects). Then try to build on this experience later. I'm sure most people reading this topic will have gained thier experience that way.
-
IMHO you might be best off doing some 'oldskool' hardware bashing code first to learn about the hardware (like trackloaders or copper/blitter effects). Then try to build on this experience later. I'm sure most people reading this topic will have gained thier experience that way.
Well that was the basic plan. I doubt I'll write anything too intersting demo-wise in the near future. The immediate goal is just to figure out how to setup an appropriate screen mode, write some pixels to the screen (since the Palm OS graphics primitives are largely based around the assumption of a dumb framebuffer) and talk to the mouse and keyboard.
At the moment, I'm still having trouble finding decent information on the hardware itself. I don't really need anything beyond OCS level at the moment, but I haven't found a good resource for that kind of info.
-
Get yourself the 3rd revision of the Hardware Reference Manual - that should help a lot! I still use mine quite a bit :-D
Also this might be of interest on some other bits:
http://www.mways.co.uk/amiga/howtocode/
This should point you in the right direction :-)
The first things I ever coded on the Amiga was some copper bar type stuff - this will teach you how to work with setting up the display.
-
msh5150 wrote:
Get yourself the 3rd revision of the Hardware Reference Manual - that should help a lot! I still use mine quite a bit :-D
Tracking down an out of print book is a bit more trouble than making an Amiga port of my little OS is worth to me.
Also this might be of interest on some other bits:
http://www.mways.co.uk/amiga/howtocode/
I found that via google, but by itself it's not very useful. It sort of assumes you already have the hardware manual. A lot of it also geared at using OS functions to get things done.
-
@MskoDestny
Tracking down an out of print book is a bit more trouble than making an Amiga port of my little OS is worth to me.
Buy the Amiga Developer CD 2.1, it has full Hardware Reference Manual included (among other priceless documentation). It seems to be available for about 25 eur (or ~30 usd).
Hardware Reference Manual really is essential for programming the HW directly.