@DamageX
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.asmWith 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).