WhyCan Forum(哇酷开发者社区)

這是司徒在挖坑網最後留下的紀錄～
相當感謝暈哥以及支持司徒的所有朋友, 司徒在此跟大家說聲感謝 !

從RetroGame、Miyoo、FC3000一路走來, 得罪相當多的方案商,
我都只想讓掌機可以跑上更多的遊戲或者模擬器, 從來就沒有想要斷人財路的想法,
如果因此得罪, 在此說聲抱歉！

司徒相當感謝周哥、怀旧堂兩位恩人, 成功把司徒從國內圈子送走, 司徒之後不再碰觸任何寨機 !
馬沙機將會在司徒的網站繼續完善, 如果有興趣, 歡迎關注！
日後, 對於有興趣的掌機, 司徒將轉往discord參與討論, 司徒心想那或許是一個比較適合的地方～

感謝大家的支持～

@mstempin
Thanks for supporting me. I think we don't need waste time to discuss this topic further. As I known, FunKey S is preparing the next generation handheld. I would like to see more detailed information about this handheld. Do you have any discord channel for this handheld. If yes, please send invitation to my email (steward.fu@gmail.com). Thanks ~

@怀旧堂
關於破解這件事情, 真的相當不好意思, 在此跟你致歉, FC3000帖我會終結掉, 以後不在更新～

你需要把 *.ttf 字型檔案也放在一起～

司徒收到許多網友的來信，信中主要的問題，幾乎都是想要在舊版機器(8個模擬器)刷入新版的系統(10個模擬器)，因此，發生許多變磚的情況，雖然事後幾乎都有補救回來，不過，這也讓司徒更加好奇並且想要一探官方系統的奧秘，雖然逆向破解需要花費很多時間跟精力，而且失敗機率很高，司徒也不確定是否可以勝任，因此，司徒訂了兩個逆向目標：
1. 找出LCD初始化的地方
2. 繞過加密IC，不需要加密IC也可以進入官方系統
司徒給自己的時間是三個月，三個月後，如果還是無法破解，則以失敗收場，當然，這應該是司徒幫FC3000進行的最後一個實驗項目了，司徒還是希望可以漂亮收場，這樣就可以讓新系統可以刷入舊版的機器！

司徒使用黑箱測試手法測試，發現加密IC有三個使用時機點，分別是：
1. 開機時檢查，如果沒有加密IC，則無限迴圈
2. 進入模擬器時檢查，如果沒有加密IC，則無限迴圈
3. 退出模擬器時檢查，如果沒有加密IC，則等待到加密IC出現

司徒使用黑箱測試後，發現最舊的TFT v1系統和最新的IPS v2系統都是使用同一種加密IC，因此，合理猜測全部的FC3000都是使用同一套加密算法，廠家真是相當貼心～

@neotendo
It is good news for us that your FC3000 handheld can be restored back to normal ! For further topic, I am thinking about how to hack the stock firmware even if there is an encrypted IC in FC3000. I think it will be an interesting topic ~

JLINK仿真,  不過, MicroSD使用SPI方式, 因此, 如果需要使用JLINK, 你需要再拉出其它腳位

Here is the invitation link for FC3000 handheld: https://discord.gg/cqpK2XjXfv

看來這個datebase算法不對, 因為第七頁是1208樓, 但是, 在1204樓就算出需要新索引頁, 這個應該是典型的 ">" ">=" 的誤用...

@暈哥
第七頁開不了, 麻煩幫忙看一下, 感謝～

Tool for keypad testing

Source code: https://github.com/steward-fu/goodies

Run on PC

Run on FC3000

prebuilt binary: keytest_20221014.zip

@neotendo
Yes, this tool is only for dumping stock rom.

Here is the dump tool you can use to dump firmware from another FC3000:
https://github.com/steward-fu/fc3000/releases/download/v1.0/ips_fc3000_dump_0627_1.img.7z
Step 1: extract ips_fc3000_dump_0627_1.img.7z
Step 2: flash image into MicroSD as the following command

$ sudo dd if=ips_fc3000_dump_0627_1.img of=/dev/sdX bs=1M

Step 3: put this MicroSD into another FC3000 and then power on
Step 4: wait for 10 minutes and then power off
Step 5: provide v1rom.img back to me and I will create restore tool for you

@neotendo
Thanks for your testing !

@neotendo
Yes, F1C100S supports USB-OTG but it has not been implemented in kernel yet.

@zjzixuan
很抱歉～我們目前是針對FC3000掌機製作，所以你的部份無法幫你～

CPU Usage is pretty well on Debian 10 xfce4 (F1C100S @486MHz) ~

@zjzixuan
你的機器可以拍張照片嗎？然後屏的FPC排線也拍一下照片～

@neotendo
Thanks for your testing. It is different with other FC3000

660     // FC3000 V1 TFT (Old Version)
661     //
662     else if(suniv_variant == 3) {
663         I_UP    = ((32 * 5) + 0);
664         I_DOWN  = ((32 * 5) + 5);
665         I_LEFT  = ((32 * 5) + 4);
666         I_RIGHT = ((32 * 4) + 2);
667         //(32*4) 0,1,(2=RIGHT),(3=SELECT),(4=START),(5=A),(7=B),(8=Y),(9=X),(6=hangboot)
668         //(32*0) 1,2 = Shutdown menu!?, (3=MENU)
669         I_START = ((32 * 4) + 4);
670         I_SELECT = ((32 * 4) + 3);

TFT 1 => SELECT button, PE3
Others => SELECT button, (PE12=0) PA1
Here is the commit: https://github.com/steward-fu/bootloader/commit/123766b9e1b6639cfd9fe0fff16ae0a21d0172f6

@neotendo
Yes, user prefer flashing image over unzipping these files. I will not create any tool for this purpose because it is a little more complex and depends on many binary files we need upload upto another repo. So far, it seems eduke32 is running pretty well on FC3000 after build with new source code. I think it is time to study something I am interested on. If you have any question and would like to discuss with us, it is very welome. And thanks for your contributions on FC3000 !

@neotendo
Thanks for your efforts to share this image to us !

Here are the backtrace logs

// #define ZOFFSET (1 << 8)
// vm.g_sp->z = actor[vm.g_i].floorz - ZOFFSET;  <= at source/gameexec.c:1160
(gdb) p vm.g_i
$13 = 448

(gdb) p vm.g_sp->z
$2 = -8448

(gdb) p actor[vm.g_i].floorz
$3 = -469696513

(gdb) n
1162    in source/gameexec.c

(gdb) p vm.g_sp->z          
$4 = -469696769

#0  VM_Execute (once=0) at source/gameexec.c:1160
#0  VM_Execute (once=0) at source/gameexec.c:1402
#0  VM_Execute (once=0) at source/gameexec.c:1402
#0  VM_Execute (once=0) at source/gameexec.c:695
#0  A_Execute (iActor=448, iPlayer=0, lDist=12586) at source/gameexec.c:4930
#0  G_MoveActors () at source/actors.c:4774

(gdb) p sprite[448]
$1 = {x = 384, y = 44608, z = -8448, cstat = 257, picnum = 1680, 
  shade = 4 '\004', pal = 22 '\026', clipdist = 80 'P', filler = 0 '\000', 
  xrepeat = 40 '(', yrepeat = 40 '(', xoffset = 0 '\000', yoffset = 0 '\000', 
  sectnum = 258, statnum = 1, ang = 1920, owner = 448, xvel = 0, yvel = 0, 
  zvel = 0, lotag = 0, hitag = 0, extra = 30}

#0  G_MoveActors () at source/actors.c:3415     <= trace from here (i == 448)
#0  G_MoveWorld () at source/actors.c:7901
#0  G_DoMoveThings () at source/game.c:10447
#0  G_MoveLoop () at source/game.c:10312
#0  app_main (argc=1, argv=0x7fffffffe128) at source/game.c:10229
#0  main (argc=1, argv=0x7fffffffe128) at src/sdlayer.c:235

I don't know when the variable "actor[vm.g_i].floorz" is set as 0xe400ffff (-469696513). So, after subtract, the value of Z position becomes as invalid (-469696769). As you mentioned before, besides Z, XY are also affected. This issue doesn't happen on QEMU and x64 PC environments but on FC3000 handheld. Interesting

Here is the table for reference

According to the testing, Z position is affected firstly and then X postion.

When the monster is walking towards the player, the value of X position should be in order of increasing.

XYZ mapping

According to the raw data got from QEMU and FC3000, the results show that it is correct in QEMU environment but incorrect in FC3000.

Raw Data

 FUNCTION	X_QEMU	Y_QEMU	X_F1	Y_F1
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	384	44608	384	44608
 G_MoveActors	462	44584	384	44608
 G_MoveActors	462	44584	384	44608
 G_MoveActors	462	44584	384	44608
 G_MoveActors	462	44584	384	44608
 G_MoveActors	574	44549	384	44608
 G_MoveActors	574	44549	384	44608
 G_MoveActors	574	44549	384	44608
 G_MoveActors	574	44549	384	44608
 G_MoveActors	698	44511	384	44608
 G_MoveActors	698	44511	384	44608
 G_MoveActors	698	44511	384	44608
 G_MoveActors	698	44511	384	44608
 G_MoveActors	828	44471	384	44608
 G_MoveActors	828	44471	384	44608
 G_MoveActors	828	44471	384	44608
 G_MoveActors	828	44471	384	44608
 G_MoveActors	958	44432	462	44584
 G_MoveActors	958	44432	462	44584
 G_MoveActors	958	44432	462	44584
 G_MoveActors	958	44432	462	44584
 G_MoveActors	1088	44393	574	44549
 G_MoveActors	1088	44393	574	44549
 G_MoveActors	1088	44393	574	44549
 G_MoveActors	1088	44393	574	44549
 G_MoveActors	1218	44354	698	44511
 G_MoveActors	1218	44354	698	44511
 G_MoveActors	1218	44354	698	44511
 G_MoveActors	1218	44354	698	44511
 G_MoveActors	1353	44368	828	44471
 G_MoveActors	1353	44368	828	44471
 G_MoveActors	1412	44400	828	44471
 G_MoveActors	1412	44400	828	44471
 G_MoveActors	1471	44432	826	44335
 G_MoveActors	1471	44432	826	44335
 G_MoveActors	1530	44464	826	44335
 G_MoveActors	1530	44464	826	44335
 G_MoveActors	1589	44496	824	44199
 G_MoveActors	1589	44496	824	44199
 G_MoveActors	1648	44528	824	44199
 G_MoveActors	1648	44528	824	44199
 G_MoveActors	1707	44560	822	44063
 G_MoveActors	1707	44560	822	44063
 G_MoveActors	1766	44592	822	44063
 G_MoveActors	1766	44592	822	44063
 G_MoveActors	1885	44657	768	43938
 G_MoveActors	1885	44657	768	43938
 G_MoveActors	1885	44657	768	43938
 G_MoveActors	1885	44657	768	43938
 G_MoveActors	2012	44610	670	43843
 G_MoveActors	2012	44610	670	43843
 G_MoveActors	2075	44586	670	43843
 G_MoveActors	2075	44586	670	43843
 G_MoveActors	2202	44539	572	43748
 G_MoveActors	2202	44539	572	43748
 G_MoveActors	2202	44539	572	43748
 G_MoveActors	2202	44539	572	43748
 G_MoveActors	2329	44492	474	43653
 G_MoveActors	2329	44492	474	43653
 G_MoveActors	2329	44492	474	43653
 G_MoveActors	2329	44492	474	43653
 G_MoveActors	2429	44400	376	43558
 G_MoveActors	2429	44400	376	43558
 G_MoveActors	2429	44400	376	43558
 G_MoveActors	2429	44400	376	43558
 G_MoveActors	2429	44400	245	43430
 G_MoveActors	2429	44400	245	43430
 G_MoveActors	2506	44235	245	43430
 G_MoveActors	2506	44235	245	43430
 G_MoveActors	2506	44235	101	43290
 G_MoveActors	2506	44235	101	43290
 G_MoveActors	2590	44053	101	43290
 G_MoveActors	2590	44053	101	43290
 G_MoveActors	2590	44053	-48	43144
 G_MoveActors	2590	44053	-48	43144
 G_MoveActors	2678	43864	-48	43144
 G_MoveActors	2678	43864	-48	43144
 G_MoveActors	2678	43864	-197	42998
 G_MoveActors	2678	43864	-197	42998
 G_MoveActors	2766	43675	-197	42998
 G_MoveActors	2766	43675	-197	42998
 G_MoveActors	2766	43675	-197	42790
 G_MoveActors	2766	43675	-197	42790
 G_MoveActors	2967	43622	-197	42790
 G_MoveActors	2967	43622	-197	42790
 G_MoveActors	2967	43622	-197	42582
 G_MoveActors	2967	43622	-197	42582
 G_MoveActors	3168	43569	-197	42582
 G_MoveActors	3168	43569	-197	42582
 G_MoveActors	3168	43569	-197	42374
 G_MoveActors	3168	43569	-197	42374
 G_MoveActors	3369	43516	-197	42374
 G_MoveActors	3369	43516	-197	42374
 G_MoveActors	3369	43516	-117	42182
 G_MoveActors	3369	43516	-117	42182
 G_MoveActors	3575	43544	-117	42182
 G_MoveActors	3575	43544	-117	42182
 G_MoveActors	3575	43544	-117	41974
 G_MoveActors	3575	43544	-117	41974
 G_MoveActors	3754	43649	-117	41974
 G_MoveActors	3754	43649	-117	41974
 G_MoveActors	3754	43649	-117	41766
 G_MoveActors	3754	43649	-117	41766
 G_MoveActors	3933	43754	-117	41766
 G_MoveActors	3933	43754	-117	41766
 G_MoveActors	3933	43754	-117	41558
 G_MoveActors	3933	43754	-117	41558
 G_MoveActors	4112	43859	-117	41558
 G_MoveActors	4112	43859	-117	41558
 G_MoveActors	4112	43859	-117	41350
 G_MoveActors	4112	43859	-117	41350
 G_MoveActors	4291	43964	-117	41350
 G_MoveActors	4291	43964	-117	41350
 G_MoveActors	4291	43964	-117	41142
 G_MoveActors	4291	43964	-117	41142
 G_MoveActors	4470	44069	-117	41142
 G_MoveActors	4470	44069	-117	41142
 G_MoveActors	4470	44069	-117	40934
 G_MoveActors	4470	44069	-117	40934
 G_MoveActors	4649	44174	-117	40934
 G_MoveActors	4649	44174	-117	40934
 G_MoveActors	4649	44174	-117	40726
 G_MoveActors	4649	44174	-117	40726
 G_MoveActors	4828	44279	-117	40726
 G_MoveActors	4828	44279	-117	40726
 G_MoveActors	4828	44279	-117	40726
 G_MoveActors	4828	44279	-157	40629
 G_MoveActors	5012	44183	-157	40629
 G_MoveActors	5012	44183	-157	40629
 G_MoveActors	5012	44183	-157	40629
 G_MoveActors	5012	44183	-197	40532
 G_MoveActors	5196	44087	-197	40532
 G_MoveActors	5196	44087	-197	40532
 G_MoveActors	5196	44087	-197	40532
 G_MoveActors	5196	44087	-237	40435
 G_MoveActors	5380	43991	-237	40435
 G_MoveActors	5380	43991	-237	40435
 G_MoveActors	5380	43991	-237	40435
 G_MoveActors	5380	43991	-277	40338
 G_MoveActors	5587	43973	-277	40338
 G_MoveActors	5587	43973	-277	40338
 G_MoveActors	5587	43973	-277	40338
 G_MoveActors	5587	43973	-277	40234
 G_MoveActors	5785	44035	-277	40234
 G_MoveActors	5785	44035	-277	40234
 G_MoveActors	5785	44035	-277	40234
 G_MoveActors	5785	44035	-277	40130
 G_MoveActors	5983	44097	-277	40130
 G_MoveActors	5983	44097	-277	40130
 G_MoveActors	5983	44097	-277	40130
 G_MoveActors	5983	44097	-277	40026
 G_MoveActors	5983	44097	-277	40026
 G_MoveActors	6181	44159	-277	40026
 G_MoveActors	6181	44159	-277	40026
 G_MoveActors	6181	44159	-316	39929
 G_MoveActors	6181	44159	-316	39929

It seems there is a potential bug in F1C100S, which seems like we found before (LDRH instruction in odd address). I cannot make sure whether we can find root cause or not but it is very interesting for this issue. Here is the current finding for reference.

@neotendo
Thanks for your efforts.
Could you share this image to us ? I would like to try it on my FC3000.

@neotendo
Yes, you need put needed files in MicroSD for stock system but it is more handy to switch system without removing MicroSD.

You can save state by using "save game" option and then provide the saved state to me.

@neotendo
Please provide the save state to me.

@neotendo
Try to "OR" SDL_DOUBLEBUF when call SDL_SetVideoMode() function.

SDL_SetVideoMode(1, 1, 8, SDL_NOFRAME | SURFACE_FLAGS | ((fs&1)?SDL_FULLSCREEN:0) | SDL_DOUBLEBUF);

P.S. Update all of SDL_SetVideoMode() functions.

@Apaczer
Thanks for your information.

QEMU for FC3000 handheld

I spent some time on porting QEMU for FC3000 handheld. It is very useful for software development on QEMU environment because you can debug your application more easily. It is just a software level compatible, not hardware level, for example: you cannot access F1C100s registers in your application. This port is based on QEMU versatilepb (ARM926EJS) CPU and run FC3000's rootfs. So, you can test your app on this environment and then put it into your FC3000 after pass testing on QEMU environment.

Kernel Source: https://github.com/steward-fu/kernel/tree/f1c100s_fc3000_linux-4.14.0_qemu
Prebuilt QEMU: https://github.com/steward-fu/fc3000/releases/download/v1.0/fc3000-qemu_20220929.7z

QEMU for FC3000 handheld

You can type command via your terminal.

If you want to debug your app, add "sleep" in "/etc/main" and then repack rootfs.img

Remember to export SDL variables and then run gdb (I have put into rootfs.img already)

You can also put source code into sd.img for debugging

How to run QEMU for FC3000 handheld

$ cd
$ wget https://github.com/steward-fu/fc3000/releases/download/v1.0/fc3000-qemu_20220929.7z
$ 7za x fc3000-qemu_20220929.7z
$ ./run.sh

How to extract rootfs.img

$ zcat rootfs.img | cpio -idvm

How to repack rootfs.img

$ sudo find . | sudo cpio -o -H newc | gzip -9 > ../rootfs.img

@neotendo
Yes, you can do overclock on your FC3000 handheld under GMenu2X setting. If you need high CPU speed, ex: 900MHz, you need to do hardware modding. If not, I think 702MHz is the best choice.

@Apaczer
Thanks for your information. It seems your repo has fixed CPU overclock issue (or 0x80000000) already. After tested, it cannot work properly. It hangs after using different CPU clock (not 702MHz). You can test with different CPU clock value for this issue. Here is the reference for you: https://whycan.com/t_6647.html#p66051

@neotendo
Yes, I would like to see X Window running on FC3000. This is why I bought new FC3000 again. Accroding to the terminal log (it is most same as eduke32.log), I cannot find useful information. Maybe, I am not familiar with this game.

EDuke32 2.0.0devel 20100727
Using /mnt/games/eduke32/ for game data
Using /mnt/.eduke32/ for game data
Initializing SDL system interface (compiled against SDL version 1.2.15, found version 1.2.15)
Using "fbcon" video driver
No fullscreen modes available!
Searching for game data...
Using 'duke3d.grp' as main game data file.
Compiling: GAME.CON (151133 bytes)
Including: DEFS.CON (35992 bytes)
Including: USER.CON (45449 bytes)
GAME.CON: In state `blimphitstate':
GAME.CON:476: warning: expected action, found define.
GAME.CON: In actor `ORGANTIC':
GAME.CON:3969: warning: found `else' with no `if'.
GAME.CON: In state `pigshootenemystate':
GAME.CON:5892: warning: found `else' with no `if'.
Found 3 warning(s), 0 error(s).
Resizing code buffer to 16189*4 bytes
Script compiled in 948ms, 16181*4b, version 1.4+
1917/11264 labels, 321/2048 variables
125 quotes, 207 actors
Initialized 24.0M cache
RTS file DUKE.RTS was not found
Initializing OSD...
0 joystick(s) found
Setting video mode 1024x768 (16-bpp windowed)
Unable to set video mode!
Failure setting video mode 1024x768x8 windowed! Attempting safer mode...
Setting video mode 1024x768 (16-bpp windowed)
Unable to set video mode!
Failure setting video mode 1024x768x8 windowed! Attempting safer mode...
Setting video mode 800x600 (16-bpp windowed)
Unable to set video mode!
Failure setting video mode 800x600x8 windowed! Attempting safer mode...
Setting video mode 640x480 (16-bpp windowed)
Unable to set video mode!
Failure setting video mode 640x480x8 windowed! Attempting safer mode...
Setting video mode 320x240 (16-bpp windowed)
Initializing music...
Error: couldn't open any of the following files:
/etc/timidity/freepats.cfg
/etc/timidity/timidity.cfg
/etc/timidity.cfg
Error: couldn't open any of the following files:
/etc/timidity/freepats.cfg
/etc/timidity/timidity.cfg
/etc/timidity.cfg
S_MusicStartup(): failed initializing
Initializing sound...
ALSA lib pcm.c:8323:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8323:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8323:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8323:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8323:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8323:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8323:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8323:(snd_pcm_recover) underrun occurred
ALSA lib pcm.c:8323:(snd_pcm_recover) underrun occurred

It is recommended to do CPU overclock for this issue. In general, "underrun occurred" means the running speed is very slow (CPU is very busy) so that sound buffer cannot be handled properly. To do overclock can fix this issue.

It is very weird !!!

source/jmact/animlib.c

147 static void decodeframe(uint8_t * srcP, uint8_t * dstP)
...
172         count = B_LITTLE16(*((uint16_t *)((srcP += sizeof(int16_t)) - sizeof(int16_t))));
...

It can be formatted as the following code

count = B_LITTLE16(*(uint16_t *)srcP);
srcP += sizeof(int16_t);

It is just to get the content of memory at srcP and then put into count variable.

From GDB

count = B_LITTLE16(*((uint16_t *)((srcP += sizeof(int16_t)) - sizeof(int16_t))));

(gdb) p/x count
$2 = 0x9d80

(gdb) x/16x srcP-4
0xb4dc9b81:     0x8000  0xd99d  0x0000  0x2605  0x2d80  0x00c1  0x2605  0x2826
0xb4dc9b91:     0x280b  0x0600  0x0b0b  0x0b16  0x1a16  0x1a0b  0x0b1a  0x0b1a

srcP = 0xb4dc9b83
In general, it should be *(uint_16_t*)srcP = 0xd99d
But what we got is *(uint_16_t*)srcP = 0x9d80

GDB with instruction level

(gdb) stepi
   0x001e1f08 <+304>:   sub     r3, r3, #2
=> 0x001e1f0c <+308>:   ldrh    r3, [r3]
   0x001e1f10 <+312>:   str     r3, [r11, #-8]
   0x001e1f14 <+316>:   ldr     r3, [r11, #-8]

(gdb) info r
r3             0xb4dc9b83       3034356611

(gdb) stepi
   0x001e1f08 <+304>:   sub     r3, r3, #2
   0x001e1f0c <+308>:   ldrh    r3, [r3]
=> 0x001e1f10 <+312>:   str     r3, [r11, #-8]
   0x001e1f14 <+316>:   ldr     r3, [r11, #-8]

(gdb) info r
r3             0x9d80   40320

I'm getting crazy...

So, this is a workaround to fix this shit issue

172         //count = B_LITTLE16(*((uint16_t *)((srcP += sizeof(int16_t)) - sizeof(int16_t))));
173         count = B_LITTLE16(srcP[0] + (((uint16_t)srcP[1]) << 8));
174         srcP += sizeof(int16_t);

And now, animation works !

eduke32_fix.zip

Now, it is time to check MIDI issue...

@neotendo
For sound issue as the following logs, it isn't the key point caused eduke32 crash.

Initializing music...
Error: couldn't open any of the following files:
/etc/timidity/freepats.cfg
/etc/timidity/timidity.cfg
/etc/timidity.cfg

Although no any timidity.cfg found, it still works as well. Updating rootfs is an idea for this problem as you did. For more easy way to fix this warning, you can specify the timidity.cfg path as the following (in source/sdlmusic.c)

221    static char *s[] = { "/mnt/games/eduke32/timidity.cfg", "/etc/timidity.cfg", "/etc/timidity/timidity.cfg", "/etc/timidity/freepats.cfg" };

The main problem is at renderframe()

Thread 1 "eduke32" received signal SIGSEGV, Segmentation fault.
0xb6e25e68 in memset () from /lib//libc.so.0
(gdb) bt
#0  0xb6e25e68 in memset () from /lib//libc.so.0
#1  0x001e1e68 in decodeframe (
    srcP=0xb4df2bc6 "((\v\v\026!\342Ƴ\001\263\263\263\001\263\001\361\241_,,\017`\032\032!\026(", 
    dstP=0x1d229bb <error: Cannot access memory at address 0x1d229bb>)
    at source/jmact/animlib.c:180
#2  0x001e212c in renderframe (framenumber=0, pagepointer=0xb4df0b78)
    at source/jmact/animlib.c:239
#3  0x001e2198 in drawframe (framenumber=0) at source/jmact/animlib.c:253
#4  0x001e2a98 in ANIM_DrawFrame (framenumber=1) at source/jmact/animlib.c:330
#5  0x000cf2d0 in G_PlayAnim (fn=0x26a658 "logo.anm", t=5 '\005')
    at source/anim.c:261
#6  0x0006bccc in G_DisplayLogo () at source/game.c:8668
#7  0x0007055c in app_main (argc=1, argv=0xbeedbdf4) at source/game.c:9960
#8  0x00250f20 in main (argc=1, argv=0xbeedbdf4) at src/sdlayer.c:208

I need to trace it deeply to see whether resolution is the problem

And it seems the sound driver has problem when loading MIDI sound format

Initializing sound...
ALSA lib pcm.c:8323:(snd_pcm_recover) underrun occurred

I also need to take a look at this problem

By the way, for the first time to run eduke32, you need to configure keyboard options as the following steps to make sure you can control it well

@neotendo
Yes, it is running Linux OS with booting logo on my new FC3000 handheld now. I am creating 2 repos for bootloader and kernel source code. After complete, I will share it to you. For eduke32, as Apaczer mentioned, it is base on MIDI music format but it has some limitations on current rootfs because no any timidity configuration in system. Besides, eduke32 has another memory segmentation issue that happens on drawing animation. I think I will take a look at eduke32 soon.

Here are the ideas, maybe, we can use:
1. use WAV to replace MIDI
2. port SDL2 for eduke32

@卡卡cyj
你可以試試 lzgame02 提供的燒錄檔案～

@Apaczer @lzgame02
感謝分享～

@neotendo

Thanks for your contributions.
I think it is time to host 2 repositories for the kernel and uboot source code even though I don't like to maintain all of them.

[Q1] i am right that the logo is schown when the kernel is loaded? is there a way to show the logo when uboot starts?
You can add the initial code (include GPIO reinitialization) at sunxi_lcdc_panel_enable() in uboot/drivers/video/sunxi/sunxi_display.c file.
This is the simplest way you can use.

@neotendo

Thanks for your efforts.
Is it possible to share the flash file (FC3000 IPS v2) for MicroSD to us ?

Since my new FC3000 will arrive soon, is it possible to provide the patch file for kernel source to me ?
Thanks in advance.

祝大家中秋節快樂～

@neotendo

miyoo.h.zip

@neotendo

Yes, in order to prevent flicking, which some LCD panels show white color when RESET is active, it is turned off in uboot and framebuffer initialization stages. So, you also need to set backlight level in device tree:

kernel/arch/arm/boot/dts/fc3000.dts

27     default-brightness-level = <0>;

@neotendo

In framebuffer driver, I switched display layer from layer-0 to layer-1 as the following image shown:

Linux logo is always displayed on layer-0 when framebuffer driver is probed.
If you would like to show starting logo on LCD panel, here are the places you need to modify:

drivers/video/fbdev/sunivfb.c

954   mypar->app_virt->yoffset = 0;

1172   fb_prepare_logo(info, 0);
1173   fb_show_logo(info, 0);

P.S. You also need to turn Linux Logo on in kernel menu configuration.

As I remembered, this image is shown from kernel. It has been removed from kernel source already, hasn't it ?

Wow, amazing !
Since such LCD panel lacks of tearing signal, it is not possible to fix.
I think you have done the best thing that Linux OS can run on FC3000 handheld and you also extended their life, ~

QQ: 3164135789

由於某些喜歡黑人的奸商，我現在很少上QQ了，不過這個應該是目前可以找到我的地方，上線時間都是隨緣的～
有問題，還是可以在我的whycan相關貼子留言，我盡可能回覆～

加上小紅點，顏值更上一層樓～

目前背面

@neotendo

Yes, you can.
Make sure the dumped file is different with original one.
Even though you can dump from SPI flash successfully, but I cannot make sure it can be restored back to normal always, therefore, it is recommended not to touch any data saved in SPI flash for safety reason.

If your friend can port Linux OS on FC3000 IPS v2 and then share with us, we are really appreciate all of efforts.

屏

上膠帶

還不錯的樣子

打印完成

背面

接著上Q10鍵盤，因為沒有固定的地方，所以左右兩邊凸出來的四個點，剛好可以使用三秒膠黏住

STL：main.stl.zip
OpenSCAD：main.scad.zip

@neotendo

Make sure we are on the same page. How did you know this issue ?

@暈哥
竟然好了～哈～

司徒接著上網找尋可以使用的外殼，網路上還是有很多佛心的人，如下就是一個開放STL檔案的外殼，可是，司徒比較希望是可以包覆的外殼

如下是司徒找到的第二個外殼，雖然也提供STL檔案，不過，外殼還是沒有包覆

如下是沒有STL檔案的外殼

最後一個找到的外殼如下圖所示，相當接近司徒心目中的外殼，比較可惜是並沒有STL檔案可以下載使用

快要可以看到第6頁了～哈～

@阿黄
可能需要掛載 SWAP 或者找一個更精簡的編譯器來使用，這個到後期才會知道，不過，有MicroSD槽可以使用，所以問題可能不大

@neotendo

[Q1] can you tell me how i can add a new variant?
In kernel folder, run the following command and then you will know how to do next

$ grep suniv_variant . -r

[Q2] do you have the tool or can you maybe ask the user for his tool please (User: aoa)?
I don't have any tool to decrypt ".wst" file.
I have asked "aoa" for further information on dingoonity forum.

[Q3] rootfs is too small and does not boot
Make sure SDL v1.2 library is included and then edit "/etc/inittab" and "/etc/main" files.

By the way, here is the way (black box testing) to find L1 and R1 in kernel level.
(it assumes that they are not physically connected with A and B buttons):
1. List out all of unused GPIO, ex: PAx, PBx, PCx and so on.
2. Change framebuffer as console mode that log can be printed on LCD.
3. Try each unused GPIO and configure it as output (only 1 ouput for every round).
4. Press L1 and R1 and check the result on LCD.
But I am wrong because L1=A and R1=B, ha ha

@neotendo

Good spot !
I need to check whether we are on the same page or not.
Is our goal to find out why L/R and A/B use the same pins ?
If yes, please provide PCB front view image without LCD panel.
(you have already provided PCB back view in previous testing)
I would like to check something on this PCB.

In such scenario, black box testing is more powerful than white box testing.
I have an idea for this issue based on kernel level testing.
I will explain to you later.

@neotendo

It seems (A / L1, B / R1) share the same I/O pins in your FC3000.
In our FC3000, the designing is almost same as yours but different buttons mapping.

The following schematic I depicted shows the buttons share same I/O pins in our FC3000:

And functionality is shown in the following image:

Here is the code shows how to check MENU button:

290       l = gpio_get_value(I_L1);
291       r = gpio_get_value(I_R1);
292       if((l == 0) && (r == 0)){
293         val|= R_MENU;
294       }

Check PE12 firstly to see whether it connects to NMOS or PMOS elments or not.

@neotendo

[Q1] GUI issue
I have no idea too.

[Q2] Sound issue
It is PA2 (TPY1) as the following image shown:

We need configure PA2 as OUTPUT so that it can be controlled as HIGH and the bits for PA2 are bit8 ~ bit10:

Source code: kernel/sound/soc/suniv/dac.c
suniv_variant = 1: PocketGo
suniv_variant = 2: TRIMUI
suniv_variant = 3: FC3000
Change L144 as the following one:

129 static void suniv_gpio_init(void)
130 {
131   uint32_t ret;
132 
133   if(suniv_variant == 0){
134     ret = readl(iomm.gpio + PA_CFG0);
135 #if POCKETGO_USE_EARPHONE
136     ret&= 0xfffff0f0;
137 #else
138     ret&= 0xfffffff0;
139 #endif
140     ret|= 0x00000001;
141     writel(ret, iomm.gpio + PA_CFG0);
142     suniv_setbits(iomm.gpio + PA_DATA, (1 << 0));
143   }
144   else if((suniv_variant == 1) || (suniv_variant == 2)){
145     ret = readl(iomm.gpio + PA_CFG0);
146     ret&= 0xffffff0f;
147     ret|= 0x00000010;
148     writel(ret, iomm.gpio + PA_CFG0);
149     suniv_setbits(iomm.gpio + PA_DATA, (1 << 1));
150   }
151 }

@neotendo

What is filebrowser menu ?
Do you mean the ROMS list menu you can select the rom to be loaded in PICRODRIVE emulator ?
If yes, you need to press A button and then it shows ROMS lists for you.
Before this, you need make sure all of buttons can work properly.
I mean your input driver can work properly.

@neotendo

Congratulations !
I am very happy to see Linux OS runs on your FC3000 ~

[Q1] sound not working
In general, there is an enable pin in amplifier IC to mute or unmute sound.
You can use multimeter to see where this pin connects to.

[Q2] most buttons not working
You can use multimeter to find all of them out.
Then you need update changes into kernel/drivers/input/keyboard/suniv-keypad.c file.

[Q3] green power led not working
As I known, the LED isn't controlled by F1C100S.
It is just a power indicator.

[Q4] is it possible to inject the new lcd code into an stock v1 or v2 rom?
Yes, it is possible but you need reverse and analyze stock firmware in assembly to see how to do inject.
If you can do this, we appreciate your efforts.

[Q5] colors wrong
You can change the settings (swap r-g-b) in LCD panel or framebuffer driver.

@neotendo

Since I have stopped maintaining FC3000 some time ago, it is recommended to port by yourself.
If you need help or suffer from problem, it is welcome to post your question.

@neotendo

Here is the another idea for testing as the following image:

For i80 interface, there are 2 methods used to send command, which are DB0~DB7 and DB8~DB15 respectively.
In our previous testing, we focused on DB0~DB7 bus for command.
It is time to test another testing to see whether it works or not.
Here is the download link for testing (swap R-B and send command via DB8~DB15):
https://github.com/steward-fu/fc3000/releases/download/v1.0/lcd_panel_identify_swap-2_img.zip

SHA1

2ed14db691ad2add6257ef450cc003819e0708ad  test_1.img
f119dcd0328bf34114f969234477624252e8e30b  test_2.img
c8a20326a5896045f73e124d96d68ec0b4d534db  test_3.img
27d85a6b8f2408fc507e8e2a37cab78b0d4401c1  test_4.img
8f586266ad2b3b19b18bf9bbf738495884537f9f  test_5.img
01753ae90098cec8992732107fb3ef0f50c30063  test_6.img
88bf176e7bafc24e5f857d581a7982c5e7f9535a  test_7.img

@neotendo

[Q1] did you program the "snow" like this or should it be 3 color bars?
[A1] 3 color bars

@neotendo

[Q1] if R and B are swapped, shouldn't it just be wrong colors?
[A1]
For i80 interface, there is a MCU embedded in LCD panel, which is in charge of rendering color on LCD.
Before MCU gets started, we need to initialize this MCU firstly, ex: voltage, gamma, frame rate and so on.
So, this is why we need initial code to initialize LCD panel.
If the bus of R and B are swapped, the MCU cannot be initialized properly due to invalid initial sequence.
It means MCU cannot work properly, just like "snow" screen as your testing.

I have to think what of testing we can use.
If you have any suggestion or idea, it is very welcome.

@neotendo

[Q1] why do you think it's not hx8347?
[A1] In my experiences, ST-xxxx, GC-xxxx, ILI-xxxx series are more commonly used in inexpensive handheld.

Thanks for your information.
If I understood correctly, it seems the bus of R and B are swapped from F1C100S side as the following image I depicted:

Here is link for all of the LCD pinouts (TFT FC3000):
https://steward-fu.github.io/website/handheld/fc3000/lcd_init.htm

It is worthy to try this idea on your FC3000.
I will prepare testing images for your FC3000 later on.
Please wait for update.

@neotendo

[Q1] Had already tried to compile that yesterday, but I had errors in the gdb compilation.
[A1] Please post error logs if need help.

[Q2] fc3000 starts with a white screen now. is that right?
[A2] Yes, it means your FC3000 is bootig from MicroSD.

[Q3] i do not hear any sound when booting linux
[A3] Basically, it is a noise when turn on speaker.

According to the image you posted, it seems your FC3000 is more older than ours.
I guess some of LCD pinouts may be different with our FC3000.
Except for pinout changed, I am afraid that the LCD panel on your FC3000 is not HX8347.
So, it is not easy for us to port Linux OS into your FC3000 beacuse of many unknown information.
But we can try our best to see whether it is possible or not.
I spent some time to collect initial code from google for your FC3000 as possible.

Here are the lists I would like to test on your FC3000:
1. https://os.mbed.com/users/Suky/code/LCDTFT//file/1085b6177f6e/LCDTFT.cpp
2. https://searchcode.com/codesearch/view/46088261/
3. https://steward-fu.github.io/website/handheld/q8/asm_lcd_gpio.htm
4. https://whycan.com/t_6647.html#p64598
5. https://whycan.com/t_6647.html#p64694
6. https://www.microchip.com/forums/m624935.aspx
7. https://github.com/CariadDisplayLibrary/HX8347D/blob/master/src/HX8347D.cpp

All of them are compiled and packed as flash image files.
So, you just need flash them into your MicroSD and then test it on your FC3000.
Source code: https://github.com/steward-fu/fc3000/releases/download/source/lcd_panel_identify_src.zip
Flash image: https://github.com/steward-fu/fc3000/releases/download/v1.0/lcd_panel_identify_img.zip

SHA1

beb68550727732fe80b8f5083463df0e5f2996d8  test_1.img
3d4d309a1111e6cc813de2dfba485a7888ad67eb  test_2.img
57de59c85e1cca75983c1a1dc5283444137b4e76  test_3.img
dbef7df5b042f95398c8e7ff3d7188ec7a57a47c  test_4.img
47fa196756b54ee022ae305a81fe7dc200ccb727  test_5.img
e9efbfd13c8c508e7a392ce20bbb7e1dc79f1e2b  test_6.img
f7a49d1ea656d7df7800b4bec202d4e60a98fab8  test_7.img

How to test (test_1.img ~ test_7.img):
Step 1: flash test_x.img into MicroSD as the following command

$ sudo dd if=test_x.img of=/dev/sdX bs=1M

Step 2: put MicroSD into FC3000 and then power on
Step 3: if the initial code is correct, your FC3000 should look like this

@neotendo

I am curious about why MicroSD slot is located at top corner of your FC3000 ?
As I remembered, it should be SPI Flash, not MicroSD.

哈～你這個主意我喜歡～那...我們就等待下一個勇者來解決吧～哈

@neotendo
Q1: does anybody have the stock rom from the v1 old version ?
A1: As I known, we don't have such backup rom for you to restore your device back to normal. If you can find someone has the model as yours, I can provide dump progam to you and then you can try to dump it. I think this is what we can help on.

Q2: can anyone point me in a direction to port the linux to this device ?
A2: Sure, we can. But before porting Linux into your device, you need known which LCD model is used in your device.

So, what is your next step ?

@tevada2010 @nicholas3388
要使用 framebuffer console, 兩個部分需要：
1. UBoot 傳遞 console=tty0 訊息 (或者 kernel hardcode 這個訊息)
2. Kernel 必須開啟支援 Device Drivers > Graphics support > Console display driver support > Framebuffer Console Support

Ref: https://steward-fu.github.io/website/mcu/nuc972/framebuffer_console.htm

@alex3325
目前沒有～

pocketgo_od_jckl_no_roms.img 的實作細節, 其實我已經不記得了, 從你的圖片看來, 你的屏應該不是 ST7789, 你要不要自己修改屏初始化代碼, 這樣比較快解決問題 ~

有一顆奮鬥的心最重要，板子漂亮或者醜陋，不重要～

pocketgo_od_jckl_no_roms.img 這個鏡像的屏驅動，版本已經很舊，跟目前釋出的差異，應該是在 TE 腳位，想必你這個屏應該是沒有 TE 腳位？PocektGo 的顯示驅動是需要 TE 腳位的，你畫的這個原理圖可以開源嗎？如果可以開源，比較方便找問題～

今天是一個適合畫畫的好日子，既然都要顯示在同一個顯示記憶體上，你只要在 xxx_probe() mmap 一次，然後把 fb0.smem_start 跟 fb1.smem_start 都設定成同一個位址就可以，何必把事情想的如此複雜呢，正所謂：心境自然娘～

你的聲音 freq 有點問題, 預設應該是 44K~48KHz, 所以建議直接使用 gdb debug 看問題

修改 Makefile, 把 -s 修改成 -ggdb

LIBS += -ldl -lpthread -lz -lgcov -lasound -Wl,--as-needed -Wl,--gc-sections -flto -ggdb -lpng

讓 gpsp 帶有 debug symbol (not stripped)

$ file gpsp
gpsp: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, with debug_info, not stripped

用 gdb 跑 gpsp, 你應該就可以馬上看到問題

# gdb --args ./gpsp xxx.gba

Miyoo 的 SDL-1.2 源代碼是使用官方的, 沒有做任何修改, Miyoo 是從顯示驅動(fbcon)和聲音驅動(alsa)做修改, 符合 SDL-1.2 的基本需求, 所以可以直接使用官方預設的源代碼, 至於, v3s 是否可以使用 ？這要看驅動程式端的製作才可以知道, 我把 SDL-1.2 和 SDL-2.0 對於顯示和聲音驅動程式的要求貼在下方, 你可以看一下, 看看是否你的 v3s 驅動程式有支援～

SDL 對於顯示驅動的需求：

SDL 對於聲音驅動的需求：

如果你的 v3s 驅動程式不符合 SDL 的基本需求, 那也可對 SDL 源代碼動刀, 就像 PSP 或者 PSVita 那樣, 不過, 那個就是另一個話題了～

@huanxing
等韓劇看完, 我找時間查一下腳位, 應該是從TP進入才是～

@txusevas
Thank you for providing stock rom dumped from WL-28H105-A1 panel.
Restore back to stock rom for FC3000 with WL-28H105-A1 panel: https://github.com/steward-fu/fc3000/releases/download/v1.0/WL-28H105-A1_restore.img

Steps:
1. clone WL-28H105-A1_restore.img into microsd
2. insert MicroSD into your FC3000
3. power on (blank screen)
4. it starts to write stock rom from microsd automatically (take about 10 mins)
5. when screen backlight starts to blink (on ~ off ~ on ~ off...)
6. remove microsd and then reboot your IPS FC3000

@huanxing
好的, 沒問題～

GitHub資源：https://github.com/steward-fu/ggm/releases
GGM燒錄檔案：https://github.com/steward-fu/ggm/releases/download/v1.0/ggm_linux_sd_20220618.img.7z

目前司徒已經完成Game Gear Micro掌機的第一版Linux系統，雖然改機難度有點偏高，不過，司徒還是相當推薦喜歡改機的愛好者可以動手試試，那種樂趣只有自己體驗過才懂得，而基於開源精神，司徒目前已經把所有源代碼發布在GitHub，分享給有興趣研究的開源愛好者，雖然開源並沒有強制的法律約束力，不過，司徒還是建議大家可以多多分享修改後的源代碼，這種東西或許就是我們可以傳承給下一代的好東西！司徒接著說明刷機過程和源代碼修改的部份，如果對於源代碼沒興趣的玩家，只要看前半部份的說明就可以。

刷機步驟：
1. 下載ggm_linux_sd_20220618.img.7z
2. 解壓縮ggm_linux_sd_20220618.img.7z
3. 將ggm_linux_sd_20220618.img刷到MicroSD
4. 插入MicroSD後，開機就可以看到如下畫面：

按鍵1：官方系統(NAND Flash)
按鍵2：Linux系統(MicroSD)

按下按鍵1就會進入官方系統(NAND Flash)

按下按鍵2就會進入Linux系統(MicroSD)

為了致敬SEGA，司徒將桌面拆成四個字母使用：

S：設定(Setting)
進入S後，有兩個設定可以使用，分別是亮度調整以及超頻，使用十字按鍵操作，按下藍色START按鍵會返回桌面

E：實驗(Experiment)
目前尚未完成，這部份之後會用來跑虛擬GPU實驗項目，目前司徒先放閃屏測試程式，按下藍色START按鍵會返回桌面

G：GBA模擬器(GBA Emulator)
司徒使用gpsp模擬器進行修改，為了配合GGM的屏幕特性，司徒修改很多東西，而進入GBA模擬器後，如果沒有遊戲檔案(/roms/gba/)，則提示如下畫面

司徒重新改寫了載入遊戲選單，支援中文顯示，字型大小做了適當調整，每次啟動該選單時，會自動停在上次載入遊戲的位置，選單效能也進行優化，不會因為大量遊戲而造成卡頓(如PSP上面那樣)，支援LR快速選單跳躍功能

GGM的屏幕顯示區域是240x195，但是，GBA解析度是240x160，因此，多餘的35像素部份，司徒使用GAME BOY ADVANCE字眼顯示

按下藍色START按鍵進入選單(按鍵1退出菜單)，司徒也對菜單進行大改寫，只保留司徒覺得想要的部份

司徒也花了相當大量的時間在改善閃屏問題，司徒覺得目前狀態算是相當不錯，畫面顯示也相當柔順，如果玩家還是不滿意，建議超頻使用

A：Arduboy模擬器(Arduboy Emulator)
目前尚未完成，目前司徒先放聲音以及按鍵測試，按下藍色START按鍵會返回桌面

源代碼修改說明：
UBOOT修改部份如下

在reset時，就先跳轉到boot_menu，為何要在reset一開始就先跳轉呢？因為這是唯一一個可以轉從SPI啟動的時機

    .globl  reset
    .globl  save_boot_params_ret
    .type   save_boot_params_ret,%function

reset:
    bl boot_menu

    /* Allow the board to save important registers */
    b   save_boot_params

boot_menu一開始就會判斷是否從RAM執行(UBOOT Relocate後)，如果是，代表UBOOT正在啟動Linux Kernel

boot_menu:
    push {lr}
    tst pc, #0x80000000
    bne boot_linux

如果不是正在啟動Linux Kernel，則顯示開機選單，圖片位於MicroSD 2MB偏移位置

    bl ccu_module_init
    bl dram_module_init
    bl sd_module_init

    ldr r0, =IMG_BASE / 512
    ldr r1, =0x80000000
    ldr r2, =(2 * 1024 * 1024) / 512
    bl load_image
    bl lcd_init

    ldr r4, =PIO_BASE + PE
0:
    ldr r0, [r4, #PIO_DATA]
    tst r0, #(1 << 9)
    beq boot_stock
    tst r0, #(1 << 10)
    beq boot_linux
    b 0b

如果是需要從SPI啟動，則直接呼叫BROM的SPI啟動位址，反之則直接返回原本UBOOT，繼續啟動Linux Kernel的步驟

boot_stock:
    bl lcd_off
    ldr pc, =0xffff4110

boot_linux:
    pop {pc}

GBA模擬器修改部份，菜單源代碼替換成gui4ggm.c，原本舊的gui.c保留不動，SDL部份都改成Double Buffer

rl_screen = SDL_SetVideoMode(240, 240, 16, SDL_SWSURFACE | SDL_DOUBLEBUF);
screen = SDL_CreateRGBSurface(SDL_SWSURFACE, 240 * video_scale, 240 * video_scale, 16, 0, 0, 0, 0);

像素搬移的部份

int x=0, y=0;
uint32_t *s = (uint32_t*)screen->pixels + (30 * 120);
uint32_t *d = (uint32_t*)rl_screen->pixels + (30 * 120);
for(y=0; y<195; y++){
    for(x=0; x<120; x++){
        *d++ = *s++;
    }
}

VSYNC改使用IOCTL方式(司徒已經實作在Framebuffer顯示驅動中)

//delay_us((u64)virtual_frame_count * 50000 / 3 - new_ticks + 2);
if(fbdev > 0){
    int zero=0;
    ioctl(fbdev, FBIO_WAITFORVSYNC, &zero);
}

編譯步驟：
Miyoo編譯開發工具

$ cd
$ wget https://github.com/steward-fu/miyoo/releases/download/v1.0/toolchain.7z
$ 7za x toolchain.7z
$ sudo mv miyoo /opt/
$ export PATH=$PATH:/opt/miyoo/bin

編譯Kernel

$ cd
$ wget https://github.com/steward-fu/ggm/releases/download/src/kernel_20220618.tar.gz
$ tar xvf kernel_20220618.tar.gz
$ cd kernel
$ ./run.sh ggm

編譯UBOOT

$ cd
$ wget https://github.com/steward-fu/ggm/releases/download/src/uboot.tar.gz
$ tar xvf uboot.tar.gz
$ cd uboot
$ ./run.sh /dev/sdX ggm

編譯GBA模擬器

$ cd
$ wget https://github.com/steward-fu/ggm/releases/download/src/gpsp_20220618.tar.gz
$ tar xvf gpsp_20220618.tar.gz
$ cd gpsp/ggm
$ make -j

MicroSD佈局如下

ui：主界面顯示App
app_s：設定App(run.sh)
app_e：實驗App(run.sh)
app_g：GBA模擬器(run.sh)
app_a：Arduboy模擬器(run.sh)
rootfs：系統
mininit：由Kernel呼叫用來掛載rootfs(squashfs系統)
swap.img：虛擬內存(128MB)

音量控制是司徒失算的部份，一般音量轉盤都是直接控制大小聲音，但是GGM掌機並不是這樣設計，所以目前無法控制音量，另一部份則是電池顯示，不完美的部份就留給想要折騰的玩家，司徒接下來會把剩餘的虛擬GPU以及Arduboy模擬器完成

@huanxing
漂亮～這個改機可以給100分！
司徒最近正在追韓劇, 心想你應該需要一段時間才可以改機完成, 想不到如此快速就改機完成, 等我把韓劇追完在給你測試檔案～哈～
另外, 你的那些按鈕是3D列印, 可以分享一下檔案嗎？另外, 切割的大小以及距離, 可以分享一下嗎？感謝～

@txusevas
很抱歉，目前沒有～

@huanxing
驚！竟然真的有人改機～我來想想如何搞壞你的機器～

將這個檔案燒錄到MicroSD
https://github.com/steward-fu/ggm/releases/download/v1.0/ggm_lcd_test_20220609.img

看看開機後是不是這個畫面

兩個方向定位問題：
1. 硬件：如果畫面一樣有問題，那應該是焊接短路問題
2. 軟件：如果畫面正常，那是屏的參數有差異

@huanxing
對～透過MicroSD開機時，會有選單可以選擇要進入哪個系統～

為了致敬SEGA，司徒最後決定加開項目，開機畫面如下，共四個選項：

S: 設定 (Setting)
E: 實驗 (Experiment)
G: GBA 模擬器
A: Arduboy 模擬器
P.S. 實驗項目是司徒的一個心願，司徒要幫ARM9 F1C100S上一顆虛擬GPU，用來跑OpenGL ES的程序～

目前GBA模擬器已經可以跑了，正在收尾～

@huanxing
感謝支持～

司徒發覺有必要先把FrameBuffer的東西紀錄下來，當作以後的參考資料，因為GGM的屏是一個很奇耙的設計，解析度是240x240，但是，顯示區域則是240x195，為此，司徒在FrameBuffer驅動做了一些處理，從下圖司徒畫的圖可以看到，F1C100S的TCON0是以240x240做更新處理，DEBE則使用4個Layers做處理，解析度都是240x240，資料輸出給屏的機制是使用TE中斷腳位觸發，因此，保證從F1C100S給的資料不會有Buffer覆蓋問題(閃屏)，但是，最後回報給User Application則是240x195

為何是以240x195回報給User Application呢？因為，有效顯示區域只有240x195，為了不讓User Application花費多餘力氣處理偏移問題，這也是為何Linux Logo可以正確顯示在GGM屏幕顯示區域的原因，因此，SDL程式可以直接使用240x195製作

#include <stdio.h>
#include <stdlib.h>
#include <SDL.h>
  
int main(int argc, char** argv)
{
  SDL_Rect rt={0};
  SDL_Surface* screen;
  
  SDL_Init(SDL_INIT_VIDEO);
  screen = SDL_SetVideoMode(240, 195, 16, SDL_SWSURFACE);
  
  SDL_FillRect(screen, &screen->clip_rect, SDL_MapRGB(screen->format, 0xff, 0x00, 0x00));
  
  rt.x = 50;
  rt.y = 50;
  rt.w = 30;
  rt.h = 30;
  SDL_FillRect(screen, &rt, SDL_MapRGB(screen->format, 0x00, 0xff, 0x00));
  
  rt.x = 100;
  rt.y = 100;
  rt.w = 50;
  rt.h = 80;
  SDL_FillRect(screen, &rt, SDL_MapRGB(screen->format, 0x00, 0x00, 0xff));
    
  SDL_Flip(screen);
  SDL_Delay(3000);
  SDL_Quit();
  return 0;
}

編譯好的程式還需要設定如下3個環境變數：

# export SDL_NOMOUSE=1
# export SDL_FB_BROKEN_MODES=1
# export SDL_VIDEODRIVER=fbcon

SDL_NOMOUSE：不需要檢查滑鼠
SDL_FB_BROKEN_MODES：將240x195解析度加入預設清單
SDL_VIDEODRIVER：顯示驅動使用FrameBuffer

完成

P.S. 對於需要Double Buffer或者Quadruple Buffer則需要自己做Map

OK~沒問題的～

好可惜～你把環境毀了～
重新安裝：經驗值+0, 下次遇到一樣無解
找出問題：經驗值+100, 下次遇到輕鬆解決

"Starting kernel..." 後會有啟動的Kernel訊息, 你的沒有打印出來, 所以不知道你出錯的原因在哪, 不過看來你的 bootargs 並沒有被 kernel 吃到, 兩個排錯方向建議：
1. dts 看一下 uart0 是否有開啟
2. hardcode CONFIG_CMDLINE="console=ttyS0,115200 panic=5 rootwait root=/dev/mmcblk0p2 earlyprintk rw" 到 ".config"

CMDLINE 附加 console=ttyS0,115200, 把debug log印出來看才會更容易知道問題

@lzgame02
小強～好久不見了～IDA Pro比適合用於靜態分析，OllyDbg比較適合用於Windows PE檔案做動態分析，兩個都是很經典好用，如果可以不要逆向，那是最好，因為太花時間了，對於時間上來說，不見得划算，當然，不得已，那只能逆向了～

@tiopex
Welcome~
I am happy you can find the solution in this website.
The latest revised kernel source has been uploaded by geekchun today.
You can download and test it to see whether it has more better than previous one or not.
Backup source code has been put on: https://github.com/steward-fu/q8/releases/download/v1.1/lcd_q8_tf28qs006a.7z

@geekchun
相當感謝你的幫助，也感謝你開源出來讓大家使用，感謝～

The LCD model is same as https://whycan.com/t_6647_2.html#p65793