Remove "copy code and data" in entrypoint about libdragon HOT 16 CLOSED

As explained in the description, that entrypoint code is redundant for ROMs < 1Mb but it's actually very useful for ROMs > 1Mb. It is extremely useful that they just work, and the feature has been used by several ports of PC games with huge code sizes.

I don't think we should remove this feature, as there is no easy workaround for this once the ROM becomes bigger than 1Mb. Also, I believe it is the 6102 IPL3 to be in the wrong: always loading a fixed amount of 1Mb seems not the correct choice. Once we have our own IPL3, it would make sense for sure to load the correct amount of data rather than a hardcoded size.

What I think we can still do even without our own IPL3:

• Use PI DMA to do the copy
• Just copy excess data after the first Mb, rather than everything

from libdragon.

I actually don't remember if 6105 would break with this. If it works on real HW after removing this then it does indeed seem redundant. I would be okay with a documented caveat that libdragon works with the N64 boot code and thus expects you to remain within 1 MiB and if you want more, look into gcc overlays or dynamic loading of code using DFS. That matches how lots of systems work in practice.

from libdragon.

Yes, it does work on real HW.
Do you have an idea where to document it? Then I could prepare this.

from libdragon.

I was wondering why libdragon's pif boot code does not touch the RSP when several commercial roms do (conker, majora). Where does it come from? Git history just says "merge alt_libn64", and I can't find much on that.

from libdragon.

Its md5sum doesn't seem to match any of 6101, 2, 3, 5, 6 available in mikeryan's repo (last 4032 bytes).

from libdragon.

It uses the 6102 bootcode. (The header file in the repo's root.)

But this has nothing to do with the entry code that my question was related to.

The games you are mentioning use other bootcodes than 6102. But I don't know if they do something with the RSP. Are you sure, this is happening in the bootcode? I think this is a task for the game code, but I'm not familiar with it.

Where are this md5 checksums?

Btw.: I wouldn't call them PIF boot codes. They are just loaded and executed from the PIF's bootrom.

from libdragon.

Yes, not directly related to removing the boot copy loop, sorry for the derail. Just curious about those things.

libdragon's header bootcode is not Nintendo's 6102, that I'm sure of. It looks like someone's reimplementation. You can check the md5sum of such a file with
dd if=header skip=64 bs=1 count=4032 status=noxfer | md5sum
You'll find it does not match any at
https://github.com/mikeryan/n64dev/tree/master/src/boot/bootcodes
including 6102.

Conker and majora run things on the RSP before the 0xaaaaae write. I've added printfs to cen64 trying to track down RSP DMA instability.

from libdragon.

The 6102 bootcode from the linked repo is identical. You can not use the md5 compare because this 6102 file is byteswapped (v64) and the header here is not swapped (z64).

Conker and Majora use the 6105 bootcode. Sorry, I don't know what the 0xaaaaae write is. Can you make this more clear?

from libdragon.

Oh, quite a surprise that. Half of mikeryan's are swapped and half are not. Yes, the bootcode here matches 6102 when byteswapped.

The 0xaaaaae write is the last RSP CP0 write done by the bootcodes, setting the "base state" before moving to user-side code. Those ROMs run things on the RSP before that write.

from libdragon.

I even noticed that the 6101 and 6102 codes are identical. This must be a mistake. Will check this later.

Hm, here is a disassembly of the 6102 bootcode:
https://github.com/PeterLemon/N64/blob/master/BOOTCODE/BOOTCODE.asm
The jump to game code is here: https://github.com/PeterLemon/N64/blob/63f09b404bef9c0bdba6be9efa87ce78401864d7/BOOTCODE/BOOTCODE.asm#L667

Now, I was looking for a mtc0 instruction and something with "aaaa" but without any luck. Eighter I still don't know what to look for or this is specific to the 6105 code. Does SM64 show this behaviour too?

from libdragon.

Just a few lines above:
https://github.com/PeterLemon/N64/blob/63f09b404bef9c0bdba6be9efa87ce78401864d7/BOOTCODE/BOOTCODE.asm#L598

The same 0xaaaaae write is in every bootcode, I think. It's done on the CPU side, not RSP.

SM64 - I couldn't say, I don't have this rom at hand.

from libdragon.

Ah, ok. Was confused because you wrote "CP0". The CP0 is in the CPU and the RSP is in the RCP. So I was looking for mtc0 and overlooked this searching using my phone. Now I see, what you mean.

Yes, this is all CPU code. It's a pity that I can't find a disassembly of the 6105 code.

All bootcodes are copied to SP_DMEM and executed from there by the CPU. But this is not done via DMA. A small part of the bootcode is copied to main ram after ram init. This writes of 0xaaaaae to the SP_STATUS register are in this part. Later the SP_DMEM and SP_IMEM are cleared to zero.

The 6102 is the most common bootcode and the games will behave like libdragon roms do. I agree, if you see these DMA accesses prior to the SP_STATUS init, it's coming from the bootcode.

I'd first check if this only happens with 6105 games. The 6105 is more complex in terms of security features and checks different things. But I have almost no knowledge about both the 6105 bootcode and the RSP.

from libdragon.

The RSP has its own CP0, sorry if I was unclear.

from libdragon.

Probably the reason for the misunderstanding was on my side.

I've looked into the RSP programmers guide and now I understand that the write to SP_STATUS goes to the RSP's CP0 RSP_STATUS register.

from libdragon.

I've sent a first PR that switches to PI DMA, but still copy the whole segments. TICKS_READ() at the start of main decreases from ~27267500 to ~22114050 in audioplayer.z64. That's ~110ms faster.

from libdragon.

The second part (transferring just data in excess to the first MiB) has been merged: 77eab03. This can now be closed.

from libdragon.