Any tutorials/articles on OS-ports ?

[Einstein]

Hello again, Elvis has entered the building ..


Issue: ports

I need tutorials/articles/help on these OS ports, what are these things ? my "Amiga Machine Language" (from abacus) is a good book to learn some OS programming but unfortunately it includes some ports in the source codes without A SINGLE explenation on what these are and when to add them.
I've written some code for disk-sector reading/writing etc. but whenever I run it kinda works the first time, the secong time I run it (even after reassambling) nothing happens, does this have to do with ports ?

[Cymric]

This is almost impossible to answer without the assembly source at hand. These things being notoriously big, can you post a link to them so us helpful blokes can take a peek? :-)

[Einstein]

source goes here:

opendev:
   lea   trddevname,a0
   lea   diskio,a1
   moveq   #0,d0         ; unit = 0
   moveq   #0,d1         ; no flags (?)
   move.l   4,a6
   jsr   -444(a6)      ; OpenDevice()
   rts

closedev:
   lea   diskio,a1
   move.l   4,a6
   jsr   -450(a6)      ; CloseDevice()
   rts

motoron:
   moveq   #1,d0         ; motor on
   bra   motOnOff

motoroff:
   moveq   #0,d0         ; motor off
   bra   motOnOff

motOnOff:
   lea   diskio,a1
   move.w   #9,28(a1)      ; command: motor..
   move.l   d0,36(a1)      ; ..on/off
   bra   sendio

read:
   lea   diskio,a1
   move.w   #2,28(a1)      ; command: read
   move.l   #512*2,36(a1)      ; length
   move.l   #readbuff,40(a1)   ; pointer to read-buffer
   move.l   #512*0,44(a1)      ; disk offset
   bra   sendio

sendio:
   move.l   4,a6
   jsr   -462(a6)      ; sendIo()
   rts

trddevname:
   dc.b   'trackdisk.device',0
   even

diskio:
   blk.l   20,0

readbuff:
   blk.b   512*2


** END_OF_CODE **

it's ment to be an include file !

[Piru]

@Einstein

How do you initialize the io request (diskio)? It must be initialized properly. Usually this is made with CreateMsgPort + CreateIORequest (cleanup with DeleteIORequest, DeleteMsgPort).

Also, from look of the code, I think you should use DoIO (-456) instead of SendIO (-462). SendIO is asyncron, so you'd need to WaitIO manually to sync. DoIO does this for you automagic.

[Einstein]

Thanks for the reply.

Believe me, I WOULD do it proper if I only knew what I was doing, forexample this ports, I really want to know what these are, yesterday I was browsing threu an old CU Amiga mag from 1992, a page came up, it was the third part of an arexx tutorial, it briefly explained a few stuff about ports, something My asm-book (Amiga Machine Language) fails to even consider doing, it was very logical as far as I got it, and as I understand it ports are:

pieces of code that handle the (event) messages one is waiting for, so ones program (task) may "sleep" and "wake up" when the port is called (in order to free the OS from the task that would otherwise do nothing but wait for the message).

I am on the right path ?

Also It would really help alot if you had any link that would explain this so I could get a 100% accurate understanding of what I'm actually doing.

Thanks again.

[Piru]

pieces of code that handle the (event) messages one is waiting for, so ones program (task) may "sleep" and "wake up" when the port is called (in order to free the OS from the task that would otherwise do nothing but wait for the message).

I am on the right path ?

Well, basically.

Here's some code using input.device .. there I set up the msgport and iorequest structures manually (and the structure fields are commented, too). It's far from proper explanation of things, however.

Developer CD 2.1 (which includes RKRM manuals) has nice docs about stuff, at least.

[Einstein]

Thanks, but I hate all those standard includes you've got there  :oops: , any version without'em ?  :-P

[Piru]

@Einstein

No. Use of includes makes the source code much more readable and easier to understand. The includes can be found from NDK3.9.lha.

[FluffyMcDeath]

Um. Excuse me being way OT here but,

is this sort of thing really worth writing in assembly or is this for personal edification. Making a bunch of OS calls can be done more easily (less typing) in C and will be easier to port to PPC that way. Why not keep all this stuff in C and do all the fancy pants number crunching and whatever really needs optimizing in assembley?

Anyway, just to drag myself back to near the topic ...

have you been here?
Might have something useful.

[Einstein]

So piru, what does those includes contain besides symbols ?
and thanks for that link.

[Einstein]

@FluffyMcDeath, I dont do much C (frankly nothing at all for the moment), so asm is my prime choice for now. thanks for that link though, going to take a look.


*EDIT*

DO one need to BUY resources to learn to program the old 1.3 kickstart ? I need to learn the exec- and device-programmming inside & out, is it ILLEGAL to publish articles teaching those areas ?

[Cymric]

FluffyMcDeath wrote:
Why not keep all this stuff in C and do all the fancy pants number crunching and whatever really needs optimizing in assembly?

Even number crunching is not really recommended in assembly these days, provided your compiler is decent enough. The effort you must put in in order to get a meaningful increase in speed is so big that the somewhat less efficient C-code will still give you the answer quickest. Assembly is good for one thing: when memory is exceedingly tight, when you are talking directly to the hardware (device drivers, OS booting, some arcane topics in OS design), or when no compiler is available.

[FluffyMcDeath]

Cymric wrote:

FluffyMcDeath wrote:
Why not keep all this stuff in C and do all the fancy pants number crunching and whatever really needs optimizing in assembly?

Even number crunching is not really recommended in assembly these days, provided your compiler is decent enough.

Depends. Though I usually write the thing in C and then take a look at the optimised assembly for ideas. Some clever solutions those optimzers come up with occassionaly. Sometimes though, the compiler doesn't understand what you're really trying to do. Rewriting the C can help but from time to time you just have to get in there and clean it up by hand. For almost anything you do on a fast machine though, it makes so little difference it's a waste of human resources.

[Einstein]

Hey dudes, could you give a list to the prime books concerning exec-, device-, task- and port-programming ? the books need to approach the respective areas with some (slight is enough) pedagogic point of view !
help me out here please !  :-)


*EDIT*

I'm browsing through this:

http://www.amazon.com/gp/reader/020156775X/ref=sib_rdr_zmin/103-4493694-5644624?%5Fencoding=UTF8&p=S001&j=1#reader-page

I wish I had the book in my hand right now ..  :-(