C development and patching for P01/P59

[bubba2533]

I think I will still at some point want to write a function or two in C because it will allow me a very easy way to change code and retest.

It's going to take me some time to get everything ported out of google sheets and into a true ASM syntax, but even then it should be easier to make changes vs. what I was doing before.

[Gampy]

Ok, gotta ask ...

How are you doing this in a spread sheet ??

[bubba2533]

It's terrible....

I've been too embarrassed to show it previously, but now I hope I'll never have to use it again.

It is mostly just text in a lot of the cells, but I have some calculations to try and make it easier. Most instructions are very simple and it was mostly copy and pasting the correct hex values. The hard part is the branches because if I changed any code between the branches I had to find the new branch location and value.

I made a few mistakes, but for the most part it worked. It just took so much time I should have forced myself to do this before, but I just didn't know enough at the time and I wanted to get it done.

[Gampy]

Absolutely amazing ... I'm impressed!

[antus]

That is definitely not the way to do it... but.. I too salute your eagerness to learn and your will to do it while you come up to speed. also your persistance to be up to v3 beta with code entirely assembled by hand. You've probably learnt a lot of lessons this way and got a solid understanding of how it works to move forward with! Well done!

[bubba2533]

So now I have an .srec file for all of my functions that will be put in the empty address space (0x8A840 and up).

But now I need to place hooks to those functions. Ideally without having to manually determine the start of each function because I want to have the flexibility to change the functions.

I've tried to do it by using the .org expression but I get an output that includes all addresses between my new code sections and fills it with 0's

I think what I need to do it have the linker combine the separate functions so the output only contains the modified addresses. But perhaps I need to do some more reading because I can't seem to understand how to do that in the .ld file

[antus]

Thats right its all in the linker and binary conversion.

Have a play with this one to see how its done.

[bubba2533]

That looks like one section as mine already is, so it doesn't really show me more than I have already done. Unless there is something more than what I see in the link.lds file.

[antus]

Well the code it builds is portable. I cant see what your doing but generally blanks where there should be addresses means that its come from a relocatable format, and the relocations have gone missing. in, say, and elf or an exe executable or object the addresses are not in the bytecode, and there is another table with the 'relocations'. On a PC when its loaded by the OS, the OS puts the segments in to places, and goes over the relocation table and puts the correct addresses in place for the right context for where and how it was loaded. Thats called a reloc table. you can use objdump to see the relocations. So when you convert back to a binary format, as the package above does, if you have the right switches it'll resolve the relocations with the context of where it thinks its going to be loaded and the addresses will be in the binary written to disk. You mentioned SREC, so I suggest you convert to binary with the same command as in my package and see if there is any difference.

I had to spend quite a lot of time figuring out the correct syntax. That link.ld part was a killer. At one stage before I got it figured out I was even using objdump to dump the reloc table and patch the binary with my own tool! But now you have the working syntax to work from.

[antus]

Code: Select all

S:\ls1flash-free read kernel 1.09 source>make clean
del *.bin *.o *.h

S:\ls1flash-free read kernel 1.09 source>make
./m68k-elf-as  readcode.asm -o readcode.o
./m68k-elf-ld  -m m68kelf --oformat binary -T link.lds readcode.o -o readcode.bin

S:\ls1flash-free read kernel 1.09 source>m68k-elf-objdump -r readcode.o

readcode.o:     file format elf32-m68k

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
0000003e R_68K_32          .text+0x00000375
0000004a R_68K_32          .text+0x00000375
00000054 R_68K_32          .text+0x00000383
000000c0 R_68K_32          .text+0x00000387
000000cc R_68K_32          .text+0x00000379
000000d4 R_68K_32          .text+0x0000037a
000000dc R_68K_32          .text+0x0000037b
000000e6 R_68K_32          .text+0x00000377
000000ee R_68K_32          .text+0x00000378
00000160 R_68K_32          .text+0x00000396
00000168 R_68K_32          .text+0x00000395
00000170 R_68K_32          .text+0x00000394
000001b6 R_68K_32          .text+0x00000391
000001be R_68K_32          .text+0x00000393
000001c6 R_68K_32          .text+0x00000392
000001ec R_68K_32          .text+0x00000391
000001f4 R_68K_32          .text+0x00000393
000001fc R_68K_32          .text+0x00000392
0000024c R_68K_32          .text+0x0000038d
00000272 R_68K_32          .text+0x00000391
0000027a R_68K_32          .text+0x00000392
00000282 R_68K_32          .text+0x00000393
0000028a R_68K_32          .text+0x00000394
00000292 R_68K_32          .text+0x00000395
0000029a R_68K_32          .text+0x00000396
000002ca R_68K_32          .text+0x00000372
00000300 R_68K_32          .text+0x00000372

Note that I was also deving in linux previously and the makefile was set to use the linux rm command on clean. Because of the age of when I built that code, im having trouble running the linux build on modern linux now, so I swapped back to windows for this demo. Ive updated the zip 2 posts above to use del instead of rm for make clean and replaced the zip in the thread. if you downloaded it prior either update the makefile from rm -f to del or download the zip again.