DreamHAL - Dreamcast Hardware Abstraction Layer

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
Post Reply
User avatar
Moopthehedgehog
DCEmu Freak
DCEmu Freak
Posts: 84
Joined: Wed Jan 05, 2011 4:25 pm
Has liked: 4 times
Been liked: 34 times

DreamHAL - Dreamcast Hardware Abstraction Layer

Post by Moopthehedgehog » Fri Dec 06, 2019 1:17 am

DreamHAL - Dreamcast Hardware Abstraction Layer

If anyone has ever used an embedded device like an STM32, MSP430, Arduino, etc. you have probably come across something known as a hardware abstraction layer (or HAL, for short). Essentially what it is is a set of functions meant to easily initialize and configure various modules of a microcontroller in a completely on-demand way. This means things like timer units, DMA controllers, UART/serial ports, etc. can be added or removed from a project completely as-needed by including a header file, calling one initialization function with some initialization parameters, and then calling functions to make use of the desired peripheral. When designed and optimized appropriately, this can provide essentially no overhead and very high performance all in an easy-to-use way that does not depend on any external libraries.

This is in contrast to using standard libraries or building around kernels, as any unused functionality is simply not included in the project, so you only get the bare minimum you need to do what you want.

I've been thinking about how the Dreamcast is actually a pretty standard system as far as embedded hardware goes, and through conversing with user mrneo it appears evident that there may some desire for something like this--particularly a HAL that is highly optimized. Note that this is NOT the same as KOS, as it would only be a collection of .c/.h files pertaining to using the SH4. One way of thinking about it is turning the Renesas SH7750 hardware manual into usable code, ideally highly optimized. The SH4 is not a very complicated CPU, and it doesn't really have that many components to it (I think it's about 15?), so I don't think it would be too crazy a project.

Those who have looked at the source code for dcload-ip that I've been working on may have noticed that perctr.h/perfctr.c (attached), which are for controlling the supposedly "undocumented" performance counters, are in fact completely standalone, modular code. That's the kind of thing I have in mind, just do that for each subsystem of the SH4. Particularly with the bit of revival going on with SH4 patent expiry, this may also be useful outside of the Dreamcast universe.

I'd like to keep this something like MIT-licensed (although whatever modules I write I'd probably just go straight public domain. So many fewer headaches that way) to maximize adoption, although how licensing would be specifically handled is a discussion to be had only if I'm not going to be the only contributor ;). I can't guarantee when it might be done, only that it will at some point because I finish things I start (and I have one very big non-Dreamcast project in particular that's a bit higher-priority). If you want to help out, please feel free, but just keep that licensing restriction in mind. Getting involved is as simple as grabbing the "SH7750, SH7750S, SH7750R Group User's Manual: Hardware" manual (not the 7751, and not always the 7750R stuff in the 7750 manual; the Dreamcast's SH7091 is somewhere in between the SH7750 and SH7750R) from the Renesas website and making a module for a peripheral that hasn't been done yet. ...Which right now is most of them. I also want to make one single header file that has '#define's for every single memory-mapped address in the SH4's memory map, with each one having a comment stating exactly what it is.

A fair amount of this might already be out there, but it's not all in one place and not necessarily super-optimized. Additionally, it's probably not fully-featured; for example, the SCI and SCIF modules should probably have functions for polled, interrupt, and DMA modes of operation, etc.

Hopefully this name isn't already taken, as well. I wasn't able to find anything that had it already, so unless I missed something DreamHAL it is. :thumbup: (I really just wanted to make this post now in order to claim the name, get feedback on the idea, etc. I'm thinking of this as a more long-term project.)

admin edit: github repo was removed, for now can be downloaded at https://dreamcast.wiki/DreamHAL
Last edited by Moopthehedgehog on Tue Dec 17, 2019 1:13 am, edited 3 times in total.
These users liked the author Moopthehedgehog for the post (total 2):
Protofallfreakdave
I'm sure Aleron Ives feels weird with his postcount back to <10668
:D
Ayla
Insane DCEmu
Insane DCEmu
Posts: 140
Joined: Thu Apr 03, 2008 7:01 am
Has liked: 0
Been liked: 1 time
Contact:

Re: DreamHAL - Dreamcast Hardware Abstraction Layer

Post by Ayla » Fri Dec 06, 2019 7:04 am

Public domain is not a license. Have a look at the CC0 license.
User avatar
Moopthehedgehog
DCEmu Freak
DCEmu Freak
Posts: 84
Joined: Wed Jan 05, 2011 4:25 pm
Has liked: 4 times
Been liked: 34 times

Re: DreamHAL - Dreamcast Hardware Abstraction Layer

Post by Moopthehedgehog » Fri Dec 06, 2019 9:59 am

Hmm, how about BSD 0-clause, then?
Apparently public domain isn’t the same thing worldwide like I thought it was...
BSD 0-Clause wrote: Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
I'm sure Aleron Ives feels weird with his postcount back to <10668
:D
User avatar
BB Hood
Insane DCEmu
Insane DCEmu
Posts: 174
Joined: Fri Mar 30, 2007 12:09 am
Has liked: 17 times
Been liked: 5 times

Re: DreamHAL - Dreamcast Hardware Abstraction Layer

Post by BB Hood » Tue Dec 10, 2019 7:40 am

Post a link to the source code repository
User avatar
Moopthehedgehog
DCEmu Freak
DCEmu Freak
Posts: 84
Joined: Wed Jan 05, 2011 4:25 pm
Has liked: 4 times
Been liked: 34 times

Re: DreamHAL - Dreamcast Hardware Abstraction Layer

Post by Moopthehedgehog » Tue Dec 10, 2019 7:24 pm

I'm sure Aleron Ives feels weird with his postcount back to <10668
:D
User avatar
Moopthehedgehog
DCEmu Freak
DCEmu Freak
Posts: 84
Joined: Wed Jan 05, 2011 4:25 pm
Has liked: 4 times
Been liked: 34 times

Re: DreamHAL - Dreamcast Hardware Abstraction Layer

Post by Moopthehedgehog » Sun Feb 16, 2020 7:10 pm

If anyone is interested in getting updates to that repository, I recommend hitting the "watch" button on the repo. Stars don't send you e-mails whenever I add to it. E.g. I just added a ton of new high-resolution video modes the Dreamcast can do.
I'm sure Aleron Ives feels weird with his postcount back to <10668
:D
User avatar
Moopthehedgehog
DCEmu Freak
DCEmu Freak
Posts: 84
Joined: Wed Jan 05, 2011 4:25 pm
Has liked: 4 times
Been liked: 34 times

Re: DreamHAL - Dreamcast Hardware Abstraction Layer

Post by Moopthehedgehog » Fri Mar 20, 2020 2:32 pm

So I had a pretty dumb problem where division involving negative numbers was pretty broken using MATH_Fast_Divide() and MATH_Invert(). This has now been fixed in sh4_math.h version 1.1.1.

The now-fixed MATH_Invert() has been renamed to MATH_Fast_Invert() for consistency with naming convention (so if anyone was using MATH_Invert() before, just add the _Fast part because MATH_Invert() no longer exists). :P
I'm sure Aleron Ives feels weird with his postcount back to <10668
:D
Post Reply