C development and patching for P01/P59

bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: C development and patching for P01/P59

Post by bubba2533 »

Visual Studio
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
In-Tech
Posts: 778
Joined: Mon Mar 09, 2020 4:35 pm
Location: California

Re: C development and patching for P01/P59

Post by In-Tech »

bubba2533 wrote:Visual Studio
Hiya bubba,
I feel your pain. I can do assembly and some vb stuff. I've been meaning to delve the C stuff but haven't made it there yet. My C and C++ guys have been telling me for years that if you can do assembly, the C stuff is easy as it uses pointers(which my assembler 8 bit crap that I built 20 years ago did too but wth do I know? funny is, they are skeert of assembly or whatever the catch phrase is, lol)
Keep up the good work :)
User avatar
Gampy
Posts: 2330
Joined: Sat Dec 15, 2018 7:38 am

Re: C development and patching for P01/P59

Post by Gampy »

bubba2533 wrote:Visual Studio
That's good and that's bad ...

Good in the fact that it is language intuitive, intellisense is very helpful and educational.
Bad in the fact that it does so much behind the scenes hiding some of the important foundation work ... On top of that is the MS bloat!

If you want to learn the hard way (the only way to really learn IMO), I suggest going CLI using GNU GCC and a simple Text editor ...

Either way you'll do just fine!

Pointers in C are the most common failure point, many use them, fewer understand them ...

-Enjoy
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
User avatar
Gampy
Posts: 2330
Joined: Sat Dec 15, 2018 7:38 am

Re: C development and patching for P01/P59

Post by Gampy »

Bah Humbug, my apologies, I need to correct myself, sorry if I've confused you.

The following statements are incorrect ... I don't know what I was thinking, an int is also four bytes. DUH!
Gampy wrote: The OS id is 4 bytes, use an unsigned long, int is to small.

Code: Select all

    unsigned long operatingsystem; // OsID is 4 bytes.
An unsigned int will work as well ...

Surprised someone didn't take me out to the woodshed for that!
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: C development and patching for P01/P59

Post by bubba2533 »

Gampy wrote: That's good and that's bad ...

Good in the fact that it is language intuitive, intellisense is very helpful and educational.
Bad in the fact that it does so much behind the scenes hiding some of the important foundation work ... On top of that is the MS bloat!

If you want to learn the hard way (the only way to really learn IMO), I suggest going CLI using GNU GCC and a simple Text editor ...

Either way you'll do just fine!

Pointers in C are the most common failure point, many use them, fewer understand them ...

-Enjoy
I'm easy able to use a simple text editor if you think that will simplify things. I'm already fairly overwelled with simply getting it setup and ready to compile a simple NOP or something.

I have Notepad++ that I could use. I'm very new to all of this, but I imagine once I get everything setup I should be self sufficient when writing and testing code.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
User avatar
Gampy
Posts: 2330
Joined: Sat Dec 15, 2018 7:38 am

Re: C development and patching for P01/P59

Post by Gampy »

Simplify is a subjective term ...

You would have to learn more of the foundation work ... Like command line options for the tools you'll be using, what tools to use in what order.
It's a lot more work, it's a lot harder, but you learn so so much more about the process and how to manipulate it.

I'm not saying one is better then the other, that is a decision you have to make.

I will say this though, there are no shortcuts to education and experience ...

Exercise for you ...
Take the .c file from this thread, place it in a directory all by itself, take note of the filename and location.
Open a "Developer Command Prompt for VS ????".
Change directory to where you have the above .c file.
Enter: cl -FeBubbasProgram FILENAME.c
When it's done,
Enter: BubbasProgram

-Enjoy

[edit]
Something else I just thought of, ultimately you are going to be coding in GNU's m68k ??
Might be better for you to be working with GNU so you don't learn all the Microsoft-isms at this time.

I dunno know ... That's above my pay grade!
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: C development and patching for P01/P59

Post by NSFW »

When I was working on the flash kernel I used Visual Studio as an editor, but I built from the command line. It's probably possible to have VS call the GNU compiler but I never tried.

Build.cmd in the Kernels directory shows how to run the compiler for kernel builds. For starters though, you could probably just use this line - change the file names to suit yours:

"c:\SysGCC\m68k-elf\bin\m68k-elf-gcc.exe" -c -fomit-frame-pointer -std=gnu99 -mcpu=68332 -O0 main.c write-kernel.c crc.c common.c common-readwrite.c flash-intel.c flash-amd.c

And change the location of the .exe file if you need to.

Then, the tricky part is stitching your code into the PCM code. For the stuff I did with Subaru, I usually found a jump-to-subroutine instruction and tweaked the address to point to my own code, then my code would do whatever I needed, then call the factory code that the jump-to-subroutine had called, and return.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
User avatar
Gampy
Posts: 2330
Joined: Sat Dec 15, 2018 7:38 am

Re: C development and patching for P01/P59

Post by Gampy »

Bubba,

Are you wanting to jump right into C in m68k, or learn a bit of C in x86/64 first ??

More help, better debugging in the latter ...
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
bubba2533
Posts: 498
Joined: Wed Apr 11, 2018 8:50 am
cars: 03 Chevy S10 Turbo V6

Re: C development and patching for P01/P59

Post by bubba2533 »

Thanks NSFW! The tricky part for me is getting this all setup and running. Stitching the code for me isn't that bad as I've done it a few times in different places now. Although I'm sure it could be more difficult once I'm writing code in C.

For example in my custom OS:
I put a jump to my code where I thought it would work the best. This usually didn't line up with a jump to another function in the code. So the way I did it was replace a number of instructions with a jump, then within my function I run those instructions, and then I run my code. This is definitely not the cleanest way to patch code in, but for small modifications of the code it would be nice to be able to program some in ASM. I'm not really sure how I would be able to do that in C since I imagine I would need to mix some ASM and C code together. If they can be combined then I will be able to document everything I did and why.

I think I'd like to jump into m68k, but I was hoping there was going to be some amount of overlap. I really have no current goals other than this custom OS, so I really don't know if I would use what I learned on the PC side of things.
LS1 Boost OS V3 Here. For feature suggestions post in here Development Thread. Support future development ->Patreon.
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: C development and patching for P01/P59

Post by antus »

The way you are describing patching is the normal way to do it. The code you want to patch over typically has no slack space in it, so you need to jump out then run the original instructions. C wont really help you with the patching process, I'll just help you write the logic you need in a higher level language and then give you the asm code to patch in. You will probably find it takes a bunch of time to set up the linker to build the code ready to exist in the right address in the pcm. Then you'll still need to patch it in yourself, or write another tool to help you do it.

I am not sure if the benefits of C would outweigh the learning process, and setting up the environment. It might but if you were making progress in asm and are getting used to 68k asm and the C gets too hard its worth sanity checking you still think your heading in the right direction. C would be worth it for a larger amount of code, but if your only planning to add a few small pieces for some specific functions the C tooling and process might not be ideal.

Most compilers build relocatable code in an object format where the binary payload exists in one section and another describes the relocations. Then when the operating system loads the code, it takes the relocations and injects addresses through the binary payload. When you write code to tun on PCM bare metal hardware there is no OS, and the load address is fixed. So then you need some scripts to convert from the executable format (typically elf) to a binary format, and to resolve the relocations. That is in the build process for the kernel. I just describe what it is because I think you'll find you need to understand it at some stage.

See https://github.com/LegacyNsfw/PcmHacks/ ... /Build.cmd

This takes the object files that have been compiled with relocation information, and puts them together in to kernel.elf. The kernel.ld file explains the memory mapping we are targeting.

Code: Select all

"%GCC_LOCATION%\m68k-elf-ld.exe" --section-start .kernel_code=0x%BASE_ADDRESS% -T kernel.ld %DUMP_MAP% -o kernel.elf main.o write-kernel.o crc.o common.o common-readwrite.o flash-intel.o flash-amd.o
If you look at the .ld file you'll see the segment names, and what order the objects are stacked up. .text is a fake address because we dispose of it. Its there because gcc is built to create executable files, and we do not want this. Its easier to create a junk .text segment and discard it later than it is to omit it https://github.com/LegacyNsfw/PcmHacks/ ... /kernel.ld

This takes the elf and its relocation information, resolves it and creates the binary ready to go in to the pcm at the given address.

Code: Select all

"%GCC_LOCATION%\m68k-elf-objcopy.exe" -O binary --only-section=.kernel_code --only-section=.rodata kernel.elf kernel.bin
In your case you'd need to make the address a place in the rom where you want it to go, you'd need to patch it in to the rom at that address manually, and then you'd need to look at the sym file (symbol information) to see what addresses have your particular functions, then you need to patch the OS to jump to those functions. You may be able to come up with another program to automate this.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Post Reply