02 December 2018, 11:47 | #61 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,377
|
Or, with an even greater chance of success (due A2 not being trashed, as trashing registers is quite bad upon exiting an interrupt) :
Code:
move.l level2_vector,-(a7) rts |
02 December 2018, 11:49 | #62 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,377
|
|
02 December 2018, 12:04 | #63 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,515
|
Quote:
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. |
|
02 December 2018, 12:51 | #64 | ||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,456
|
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: Quote:
However, regardless of all that I still think that jumping/returning straight to the OS handler is very bad news though Quote:
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. Last edited by roondar; 02 December 2018 at 13:21. |
||
02 December 2018, 13:34 | #65 | |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
Quote:
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... |
|
02 December 2018, 13:55 | #66 | |
Going nowhere
Join Date: Oct 2001
Location: United Kingdom
Age: 50
Posts: 9,030
|
Quote:
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?! |
|
02 December 2018, 13:55 | #67 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,569
|
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. |
02 December 2018, 14:01 | #68 | |||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,456
|
Quote:
Quote:
Quote:
|
|||
02 December 2018, 17:27 | #69 |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
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... Last edited by litwr; 02 December 2018 at 21:25. |
02 December 2018, 22:28 | #70 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,456
|
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). |
06 December 2018, 11:54 | #71 | |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
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.
Code:
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 Quote:
EDIT. Maybe the raster port requires some initialization? |
|
06 December 2018, 12:38 | #72 |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
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.
|
06 December 2018, 13:48 | #73 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,456
|
Quote:
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: Code:
move.l size,-(sp) move.l port,-(sp) jsr _CreateExtIO addq #8,sp 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. |
|
06 December 2018, 14:06 | #74 | |||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,569
|
Quote:
Quote:
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). Quote:
|
|||
06 December 2018, 14:11 | #75 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,569
|
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.
|
06 December 2018, 14:54 | #76 | |||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,456
|
Quote:
Quote:
Quote:
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? Last edited by roondar; 06 December 2018 at 14:57. Reason: Clarified things slightly and changed the layout to be a bit more readable |
|||
06 December 2018, 16:29 | #77 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,569
|
Quote:
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. |
|
06 December 2018, 16:40 | #78 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,456
|
Quote:
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 |
|
06 December 2018, 18:50 | #79 |
Registered User
Join Date: Mar 2016
Location: Ozherele
Posts: 229
|
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. Last edited by litwr; 06 December 2018 at 20:00. |
06 December 2018, 20:01 | #80 |
Registered User
Join Date: Dec 2010
Location: Athens/Greece
Age: 53
Posts: 728
|
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Misc Amiga Assembler Source Code | copse | Coders. General | 14 | 20 October 2019 02:05 |
The 6502 assembler code in "The Terminator" (1984) | Shoonay | Nostalgia & memories | 2 | 15 May 2009 13:52 |
Assembler System Friendly code | redblade | Coders. General | 3 | 29 July 2008 12:15 |
Amiga Cross Assembler to code intros! - Help! | W4r3DeV1L | Amiga scene | 6 | 30 May 2008 16:53 |
3D code and/or internet code for Blitz Basic 2.1 | EdzUp | Retrogaming General Discussion | 0 | 10 February 2002 11:40 |
|
|