Welcome, Guest. Please login or register.
Amiga Kit Amiga Store Iridium Banner AMIStore App Store A1200/A600 4xIDE Interface

AuthorTopic: newb questions, hit the hardware or not?  (Read 14006 times)

0 Members and 1 Guest are viewing this topic.

Offline DamageX

newb questions, hit the hardware or not?
« on: January 09, 2006, 07:03:48 AM »
I want to write some programs in assembly (please don't suggest a HLL as I won't use one) on my A2000. I want to do file I/O, some graphics on a HAM6 screen, and perhaps audio as well. Now the question is how to go about it. Looking at bits of source code and documentation that I've been able to find, the method of disabling the OS and accessing hardware registers directly seems to be very clear. But, can OS calls still be used for file I/O in this case? And where could I learn to open a custom screen and play audio the OS-friendly way anyways?
 

Offline Piru

  • \' union select name,pwd--
  • Hero Member
  • *****
  • Join Date: Aug 2002
  • Posts: 6946
  • Total likes: 0
    • http://www.iki.fi/sintonen/
Re: newb questions, hit the hardware or not?
« Reply #1 on: January 09, 2006, 08:21:50 AM »
@DamageX
Quote
Now the question is how to go about it. Looking at bits of source code and documentation that I've been able to find, the method of disabling the OS and accessing hardware registers directly seems to be very clear. But, can OS calls still be used for file I/O in this case? And where could I learn to open a custom screen and play audio the OS-friendly way anyways?

You can do exactly this, but you need to be very careful when setting it up or it will b0rk. Basically you need to take over display only (and prevent system from opening any requesters, since you won't see them!), and keep the system running on the background. You should then use input.device inputhandler to get input from the user. If you intend to use the disk I/O, you can't disable the interrupts or the dma.

Here's a simple startup code that does exactly this:
hwstartup.asm

With this startup code the system is still running normally while the display is taken over by it. You can do the disk I/O just fine.

To get user input you can modify ih_code to process input events (IECLASS_RAWKEY etc) BEFORE the events are nulled.

The display can be built several ways. You can build your own copperlist that sets up display window size, depth and plane pointers, and then render directly to the bitmaps. Or you can use graphics.library low level display routines to build view, viewport, rasinfo, bitmap etc. In this case the display is "loaded" with LoadView + WaitTOF. The advantage here is that you can use normal graphics.library rastport routines for rendering (just InitRastPort the rp and set rp_BitMap to point to your own bitmap, then fire away with gfx draw routines). However, if you intend to use HAM6 display, graphics.library functions aren't that useful.

For audio you can allocate the hardware via audio.device and then proceed banging the hw, or you can use audio.device for playing the samples (more restrictive), or you could use ahi.device (but this makes little sense if you bang hw already, the only reason would be to allow using soundcards).
 

Offline DamageX

Re: newb questions, hit the hardware or not?
« Reply #2 on: January 10, 2006, 01:45:07 AM »
This is just the kind of info I needed, thanks ^_^
 

Offline DamageX

Re: newb questions, hit the hardware or not?
« Reply #3 on: July 14, 2014, 08:22:40 AM »
for the record...
Code: [Select]
.nosignal:
move.l _WBenchMsg(pc),d0
beq.s .notwb
move.l a0,a1
jsr _LVOForbid(a6)
jsr _LVOReplyMsg(a6)

.notwb:
move.l d7,d0
rts

I was informed that this part is buggy. a0 was perhaps a typo for d0, and it is also not clear if a1 is preserved during the call to LVOForbid
 

guest11527

  • Guest
Re: newb questions, hit the hardware or not?
« Reply #4 on: July 14, 2014, 09:22:34 AM »
Quote from: DamageX;225347
I want to write some programs in assembly (please don't suggest a HLL as I won't use one) on my A2000. I want to do file I/O, some graphics on a HAM6 screen, and perhaps audio as well. Now the question is how to go about it. Looking at bits of source code and documentation that I've been able to find, the method of disabling the OS and accessing hardware registers directly seems to be very clear. But, can OS calls still be used for file I/O in this case? And where could I learn to open a custom screen and play audio the OS-friendly way anyways?

I would strongly discourage you to access the hardware yourself. The Os can do everything you can do by using the hardware directly, there is no advantage. So for example, users will no longer be able to switch screens if you do this, or run savely multiple programs. Also, people then often run into a Forbid() to get rid of task-switching, though any Os-bound I/O call will require task switching and enabled interrupts.

Opening a custom screen requires the Os, but is not hard. Information like this can be found in the RKRMs. Basically, you have to fill in a struct NewScreen and perform an OpenScreen() from intuition, or use an OpenScreenTagList() directly. See intuition/screens.i.
 

Offline OlafS3

Re: newb questions, hit the hardware or not?
« Reply #5 on: July 14, 2014, 10:38:04 AM »
Quote from: DamageX;225347
I want to write some programs in assembly (please don't suggest a HLL as I won't use one) on my A2000. I want to do file I/O, some graphics on a HAM6 screen, and perhaps audio as well. Now the question is how to go about it. Looking at bits of source code and documentation that I've been able to find, the method of disabling the OS and accessing hardware registers directly seems to be very clear. But, can OS calls still be used for file I/O in this case? And where could I learn to open a custom screen and play audio the OS-friendly way anyways?


I would also discourage to directly hit the hardware. There are a couple of new cores for FPGA in development (FPGA Arcade and the Apollo core are examples, but I also know of at least two others). If you want that your software runs everywhere it is a safer bet to use the OS.
 

Offline Jose

Re: newb questions, hit the hardware or not?
« Reply #6 on: July 14, 2014, 11:37:01 AM »
8 years after !? Awesome :)
\\"We made Amiga, they {bleep}ed it up\\"
 

Offline Thorham

Re: newb questions, hit the hardware or not?
« Reply #7 on: July 14, 2014, 12:07:29 PM »
Quote from: OlafS3;768906
If you want that your software runs everywhere it is a safer bet to use the OS.
You can't always do that if you want your software to run well on current low to mid end systems. Things such as planar CPU blitting (in cases where it's faster than c2p+chunky blitting). You just don't want to use the OS for that.

Making your software system friendly is one thing (I'm all for that), but getting it to run everywhere isn't always a good idea (depending on what the software is).
 

Offline biggun

Re: newb questions, hit the hardware or not?
« Reply #8 on: July 14, 2014, 12:27:02 PM »
Quote from: OlafS3;768906
I would also discourage to directly hit the hardware. There are a couple of new cores for FPGA in development (FPGA Arcade and the Apollo core are examples, but I also know of at least two others). If you want that your software runs everywhere it is a safer bet to use the OS.


I can only speak for Apollo/ Phoenix CPU and for the S-AGA Chipset.
With them you can savely hit the hardware as you are used to do it.
I myself write old school copperlists when I write demos testing the CPU or the AGA chipset.
So doing this is save and no problem at least for the Apollo/Phoenix CPU and the SAGA++ chipset.

guest11527

  • Guest
Re: newb questions, hit the hardware or not?
« Reply #9 on: July 14, 2014, 03:45:37 PM »
Quote from: Thorham;768912
You can't always do that if you want your software to run well on current low to mid end systems. Things such as planar CPU blitting (in cases where it's faster than c2p+chunky blitting). You just don't want to use the OS for that.

There is no problem using the blitter if the Os calls do not offer you want you need - and if you are sure what you are doing. You can reserve the blitter for your own purpose by OwnBlitter()/DisownBlitter() from the graphics.library, or by using QBlit()/QSBlit() to queue a blitter job.  

By "you are sure what you are doing" I mean that you cannot, in general, expect that you have a simple old planar bitmap for your screen. Graphics cards exist since a long time, and there working with the blitter is often a bad idea. Whenever possible, use the system calls to get your job done, because then you'll be sure it's done correctly even on non-native hardware.
 

Offline Thorham

Re: newb questions, hit the hardware or not?
« Reply #10 on: July 14, 2014, 04:52:36 PM »
Quote from: Thomas Richter;768926
There is no problem using the blitter if the Os calls do not offer you want you need
I actually meant blitting with the CPU (because it's faster than the CPU on 68020+).

Quote from: Thomas Richter;768926
By "you are sure what you are doing" I mean that you cannot, in general, expect that you have a simple old planar bitmap for your screen.
So, you'd have to sacrifice performance on actual native hardware just because the OS might not open a planar screen on non-native hardware? That means that basically everything you'd write ends up running like crap on actual Amigas without GFX boards. Sounds like a bad idea.
 

Offline itix

Re: newb questions, hit the hardware or not?
« Reply #11 on: July 14, 2014, 05:02:12 PM »
Quote from: Thomas Richter;768926

By "you are sure what you are doing" I mean that you cannot, in general, expect that you have a simple old planar bitmap for your screen. Graphics cards exist since a long time, and there working with the blitter is often a bad idea. Whenever possible, use the system calls to get your job done, because then you'll be sure it's done correctly even on non-native hardware.


He was going to use HAM6 which locks out certain configurations anyway.
My Amigas: A500, Mac Mini and PowerBook
 

Offline Sean Cunningham

Re: newb questions, hit the hardware or not?
« Reply #12 on: July 14, 2014, 05:05:28 PM »
Speed or compatibility, you can rarely pick more than one of these.
 

guest11527

  • Guest
Re: newb questions, hit the hardware or not?
« Reply #13 on: July 14, 2014, 05:05:28 PM »
Quote from: Thorham;768935
So, you'd have to sacrifice performance on actual native hardware just because the OS might not open a planar screen on non-native hardware? That means that basically everything you'd write ends up running like crap on actual Amigas without GFX boards. Sounds like a bad idea.

No, I do not mean this. Do you have an idea how much "performance you sacrifice" by using the Os calls? Or "how worse" the Os is in using the native hardware? Actually, not much. The core function (BltBitmap()) is pretty much low-level and bare to the metal. I wonder whether you can do any better yourself. The amount of additional checks needed for non-native hardware are a single pointer (in the bitmap). How much performance does that cost?

Sorry, but that's a typical argument of the "cycle counter party": Just hack the hardware because we don't know any better and argue "it's for speed". Rule number one for performance optimizations: Measure first. Then optimize.
 

Offline SamuraiCrow

Re: newb questions, hit the hardware or not?
« Reply #14 on: July 14, 2014, 05:55:52 PM »
@Thomas Richter

I've researched the OS functions extensively in the interest of encapsulating the most efficient special effects of the Amiga chipsets in shared libraries.  This is not only to make things easier for newbies on the Amiga but also to be able to reroute some of them to emulations on graphics cards for better compatibility.

BltBitMap only works on the Blitter.  What about MrgCop, the rather incomplete interface to the Copper?  CINIT, CBUMP, CWAIT, and CMOVE are hardly enough macros to suffice!  The Copper is able to implement display-list like properties to queue the Blitter much more efficiently than QBlit can do using the CPU and an interrupt.  Also, I'd like to be able to merge partial Copper lists based on different starting raster positions so that multiple effects can be combined.  (Both usages need not be concurrent since waiting for the Blitter and raster positions in the same CWAIT tend to result in race conditions.)  Neither the CNEXTBUFFER macro nor its underlying subroutine to skip to another buffer of Copper instructions was ever implemented even though certain infrastructure was added to graphics/copper.h indicating its existence.