I am trying to make my first GFX assembler code

[meynaf]

Or, with an even greater chance of success (due A2 not being trashed, as trashing registers is quite bad upon exiting an interrupt) :

 move.l level2_vector,-(a7)
 rts

Sorry i just couldn't resist

[meynaf]

Originally Posted by litwr

It doesn't work. Please help me to restore $bfed01 contents

Mixing direct hardware access with OS code is calling for trouble, and you've just got it...

[ross]

Originally Posted by litwr

Reading of $bfed01 actually disables Read. Thus I need to preserve the content of this register and restore it after the reading.

It is urgent that you understand how CIAs work.
This chip is a 8-bits legacy and (like others CIA registers) at the $d location there are two memory cells, one read-only and one write-only.

It's also the cell that cleans the IRQ once read (if you've ever used the 6502 and come from the C64, all would be very clear for you).
All I can advise you is to study its operations, there are various docs online.
Your code in those conditions will never works.

Two possibilities:
- use system and respect his rules;
- disable system and you can do what you want.

[roondar]

Originally Posted by phx

Or, with a higher chance of success:

        move.l  level2_vector,a2

Ah yes, that is indeed correct. Perhaps writing code at 1:00 am has its drawbacks

I have since noted that a2 can't be used though - considering that litwr's code jumps straight to the OS interrupt handler so it'll never get restored. In fact, any register I choose can cause issues. So:

Originally Posted by meynaf

Or, with an even greater chance of success (due A2 not being trashed, as trashing registers is quite bad upon exiting an interrupt) :

 move.l level2_vector,-(a7)
 rts

Sorry i just couldn't resist

Indeed, that is the best version of what I intended to do. Though I've never liked using rts like that, for some reason it feels a bit like a hack

However, regardless of all that I still think that jumping/returning straight to the OS handler is very bad news though

Originally Posted by litwr

@roondar Thank your very much for your very useful information. Reading of $bfed01 actually disables Read. Thus I need to preserve the content of this register and restore it after the reading. I have made the next code for my interrupt handler.

level2i:   move.l d0,-(sp)
         move.b $bfed01,d0   ;kbd

             ori.b #$80,d0
             move.b d0,$bfed01
             move.l (sp)+,d0
level2ie:    jmp 0

It doesn't work. Please help me to restore $bfed01 contents

Others have mentioned this, but the short answer is: you can't. The chip is not designed to be able to do this.

This is one of the reasons why I keep saying "either use the OS, or disable it and do everything yourself".

If you want to keep the OS alive and read the keyboard, your only 100% going-to-work choices are: use intuition, use input.device or use keyboard.device (though there are some caveats for using keyboard.device). As soon as you touch the CIA ICR register directly, you're highly likely to break the OS.

Also note that even if you could restore the CIA ICR register, the rest of your code still very probably would not work - Read() is not meant to handle keyboard input.

My advice then is either:
1) Keep the OS and do as meynaf suggested: handle keyboard input through intuition.
2) Throw out the OS and use a pure hardware banging keyboard handler. Examples of such keyboard handlers and how to kill and re-enable the OS can be found on eab.

[litwr]

Originally Posted by roondar

Also note that even if you could restore the CIA ICR register, the rest of your code still very probably would not work - Read() is not meant to handle keyboard input.

My advice then is either:
1) Keep the OS and do as meynaf suggested: handle keyboard input through intuition.
2) Throw out the OS and use a pure hardware banging keyboard handler. Examples of such keyboard handlers and how to kill and re-enable the OS can be found on eab.

It sounds like Amiga programming is a very tricky thing because even in the end of 2018 there is still no clear answer for the question how to do keyboard polling.
Is it possible to do keyboard polling and simultaneously using OS? Please help, is there an answer to the question?
Read works fine for the keyboard input with my pi-spigot...

[Galahad/FLT]

Originally Posted by litwr

It sounds like Amiga programming is a very tricky thing because even in the end of 2018 there is still no clear answer for the question how to do keyboard polling.
Is it possible to do keyboard polling and simultaneously using OS? Please help, is there an answer to the question?
Read works fine for the keyboard input with my pi-spigot...

Dude, the answer is VERY clear by all those that have interacted with you.

Either ONLY use the system functions for what you want to do, OR, hardware bang directly and DO NOT MIX SYSTEM CALLS TO SIMILAR FUNCTONS.

i.e. don't mix the two methods, its one or the other.

This is not some complex puzzle to solve, you've been given the answers on how to implement this, but you ignore them?!

[phx]

I would recommend reading the hardware reference manual concerning 8520/652x-like I/O chips first, before programming them.

Reading the CIA's ICR (Interrupt Control Register) acknowledges the interrupt and clears all interrupt flags! This means the OS-handler will detect no interrupt anymore.

Writing the ICR is a completely different function. It is used to enable/disable interrupt sources.

[roondar]

Originally Posted by litwr

It sounds like Amiga programming is a very tricky thing because even in the end of 2018 there is still no clear answer for the question how to do keyboard polling.

There is a clear answer, we gave it to you several times already.

Is it possible to do keyboard polling and simultaneously using OS? Please help, is there an answer to the question?

You should not manually poll the keyboard when using the OS. Use the mechanisms designed for that purpose. We've described them already.

Read works fine for the keyboard input with my pi-spigot...

Working and being meant to be used for that purpose are not the same. Case in point: Read only 'works fine' for shell/cli applications.

[litwr]

Thanks to everybody for attempts to help with the keyboard polling. Sorry, but I got rather a lot of hazy hints that something that could help me. I want an OS friendly code for a fullscreen application. Thus if understood hints correctly I need to open a borderless window, then to work with the keyboard device and this can help. Is it right? If it is so then I have several more questions.

1. Does anybody know where can I find a code-sample for opening of a borderless fullscreen window?
2. It looks like that the function CreateExtIO is not easy to use with assembler. What library does it belong to? How to invoke it? I can't find its assembly parameters in several Amiga references. An example or link will be greatly appreciated.

Excuse me, maybe my questions sound too ignorant but I am doing my first Amiga gfx application only on weekends for the recent several weeks.

Anyway I'm very impressed by the level of support that I have already got. Amiga is a great computer. It is sad that Moto and Commodore failed to support it properly.

EDIT. It seems that I could find the requested code samples...

[roondar]

For those interested, here is a C example of reading the keyboard using intuition. It's fairly involved because it also opens the window etc, but the actual event loop is not that big. The example is at the bottom of the page and might need OS 2.0 for some elements (if it does, it should be fairly simple to change it to 1.3 compatibility).

https://wiki.amigaos.net/wiki/Intuition_Keyboard

Also, CreateExtIO info can be found here: http://amigadev.elowar.com/read/ADCD.../node0029.html. It belongs to amiga.lib (a support library used by many programs).

[litwr]

It's become my obsession. If I had known that reading of a port can affect it I would have never used a direct access to hardware with Amiga. I have found that Amiga OS friendly programming is very interesting. I really missed a lot. However OS looks too difficult to use, it requires much time to study it. There is also some problems with documentation. I found a way to do key polling. I am using a message port of my window - it works very well. But now I have other unexpected problem - I don't know how to write text to my window. I think about two ways: 1) using the same message port for output, but I don't know how to form a proper message structure for this; 2) using the raster port of my window - I tried the next code but it doesn't work.

        movea.l WINDOW_HANDLE(pc),a0
        movea.l 50(a0),a1    ;offset of RastPort? I'm not 100% sure
        lea TESTSTRING(PC),a0
        move.w #8,d0
        move.l GRAPHICS_BASE(PC),a6
        jsr -60(a6)   ;call to TEXT routine

Any clues will be greatly appreciated. BTW I tried to use Write call but it writes not to my window but to a window where my program was involved. There is also a console device open for keyboard scan codes conversion to ASCII, it can be also used for write text, but I need more data about this. My screen has a font associated with it - I also don't now how to use it...

Originally Posted by roondar

For those interested, here is a C example of reading the keyboard using intuition. It's fairly involved because it also opens the window etc, but the actual event loop is not that big. The example is at the bottom of the page and might need OS 2.0 for some elements (if it does, it should be fairly simple to change it to 1.3 compatibility).

https://wiki.amigaos.net/wiki/Intuition_Keyboard

Also, CreateExtIO info can be found here: http://amigadev.elowar.com/read/ADCD.../node0029.html. It belongs to amiga.lib (a support library used by many programs).

Thank you. However look at the pointed text for CreateExtIO - it doesn't contain even registers used for parameters and result. IMHO there is no strict ABI used with Amiga OS.

EDIT. Maybe the raster port requires some initialization?

[litwr]

I had to use MOVE before TEXT. Now the raster port works well too. But this port doesn't allow to use control sequences. What is the best way to use them with a new window? Thanks.

[roondar]

Originally Posted by litwr

Thank you. However look at the pointed text for CreateExtIO - it doesn't contain even registers used for parameters and result. IMHO there is no strict ABI used with Amiga OS.

AFAIK the OS and its libraries use two calling conventions.
The first is passing through registers, the second is passing through stack (aka the 'C function calling convention').

For functions that should have parameters passed through registers, the documentation will note which registers to use. As an example, see the Exec function AllocMem(): http://amigadev.elowar.com/read/ADCD.../node0332.html

For functions that use the stack, the documentation will not note which registers to use and expects you to pass the parameters as such that the first item to be popped from the stack is the first parameter of the function, etc. As an example, the amiga.lib function CreateExtIO() (http://amigadev.elowar.com/read/ADCD.../node0147.html) would be called something like this:

    move.l    size,-(sp)
    move.l    port,-(sp)
    jsr    _CreateExtIO
    addq    #8,sp

Which function falls into which category is not something I can tell beforehand, but the documentation should make it clear what option to use.

Note: I am not able to test the above code right now and this is all purely based on what I can recall - I could be wrong about parts of it so do test it yourself to be sure.

[phx]

Originally Posted by roondar

For those interested, here is a C example of reading the keyboard using intuition.
(...)
https://wiki.amigaos.net/wiki/Intuition_Keyboard

Beware! This is OS4.x code, which is not the intended target system, as far as I understood. For OS1/2/3 the code is simpler, as you don't have to deal with "Interfaces", but just open the libraries.

Originally Posted by roondar

AFAIK the OS and its libraries use two calling conventions.
The first is passing through registers, the second is passing through stack (aka the 'C function calling convention').

OS libraries always pass their arguments in registers, which is documented in the NDK and the appropriate OS header files.

Additionally there are C support functions, which are not part of the OS-ROM, but are provided via linker libraries (like CreateExtIO()). Those are using the normal 68k C calling ABI (arguments on the stack, result in register D0).

Which function falls into which category is not something I can tell beforehand, but the documentation should make it clear what option to use.

That's easy. See above. Real OS shared library functions get their argument passed in registers. Additional functions use the C ABI.

[phx]

Originally Posted by litwr

I had to use MOVE before TEXT. Now the raster port works well too. But this port doesn't allow to use control sequences. What is the best way to use them with a new window? Thanks.

Text() is just raw text font output on the bitmap. Either parse the control sequences yourself, or use CMD_WRITE from console.device. But it requires more than opening a window to make it a working console.

[roondar]

Originally Posted by phx

Beware! This is OS4.x code, which is not the intended target system, as far as I understood. For OS1/2/3 the code is simpler, as you don't have to deal with "Interfaces", but just open the libraries.

I actually totally missed that. Thanks for pointing it out. Perhaps in general wiki.amigaos.net is a poor choice for OS 3.x code then, it does appear to be maintained by Hyperion and is probably only aimed at OS4.0.

OS libraries always pass their arguments in registers, which is documented in the NDK and the appropriate OS header files.

Additionally there are C support functions, which are not part of the OS-ROM, but are provided via linker libraries (like CreateExtIO()). Those are using the normal 68k C calling ABI (arguments on the stack, result in register D0).

Again, thanks for the clarification. Like I said, I did most of this from memory so it's good to have better information here.

That's easy. See above. Real OS shared library functions get their argument passed in registers. Additional functions use the C ABI.

It is complicated slightly by the autodocs apparently containing both in a single file. For instance, look at the exec.library documentation as found here: http://amigadev.elowar.com/read/ADCD.../node0322.html

This contains both AllocMem(http://amigadev.elowar.com/read/ADCD.../node0332.html) and CreateMsgPort (http://amigadev.elowar.com/read/ADCD.../node0345.html) and one of these is called using registers while the other appears to be called using the stack. If I understand what you wrote correctly, this means that one of the above is an 'actual' OS library call and the other is a C support library call.

Is this correct? Or am I missing something here?

[phx]

Originally Posted by roondar

This contains both AllocMem(http://amigadev.elowar.com/read/ADCD.../node0332.html) and CreateMsgPort (http://amigadev.elowar.com/read/ADCD.../node0345.html) and one of these is called using registers while the other appears to be called using the stack. If I understand what you wrote correctly, this means that one of the above is an 'actual' OS library call and the other is a C support library call.

No. All those exec.library functions shown there are in the ROM and receive arguments in registers. CreateMsgPort() is also such a shared library function (offset -666), but without any argument passed ("void").

BTW, saying that all those shared library OS functions are in ROM was wrong, of course. You also have shared libraries on disk. The main difference is: OS shared library <-> linker library.

[roondar]

Originally Posted by phx

No. All those exec.library functions shown there are in the ROM and receive arguments in registers. CreateMsgPort() is also such a shared library function (offset -666), but without any argument passed ("void").

BTW, saying that all those shared library OS functions are in ROM was wrong, of course. You also have shared libraries on disk. The main difference is: OS shared library <-> linker library.

Right, I think I get it now then.

OS libraries (whether in ROM or on disk) always use registers to pass parameters and the registers used are always named by the documentation (with void being nothing so no register is used - I really should've spotted that ).

Linker libraries do not use registers and as such always use the stack for passing parameters.

Thanks for the clarifications

[litwr]

It is easy to open a console window just opening a file named "CON:" by Open call. Is it possible to adjust this console window? I would like to remove borders and a title.
IMHO AmigaOS gives too many ways to do the same things.

EDIT. Yet another question. Is it possible to open window without a title? Using SCREENQUIET attribute for a screen and CUSTOMSCREEN attribute for a window gives a window without a visible title but this only hides the title place. When I try to put a text into the title area with the Text call it doesn't work.

MORE EDIT. I could get a window without a title. I had to remove a requester text from the window definition and call ShowTitle.

[alkis]

http://amigadev.elowar.com/read/ADCD.../node016C.html