GP32 Just In Idea!


Last edited by a moderator:
The official SDK only checks to see if it is known firmware, and only then as a bugfix for 16bit modes. Nothing to do with BLU-/+/+-/RW :p

Just get mirko to init the LCD display the same way that the sdk does, if he hasn't already, then recompile.

Also, does nobody have a clue about directories here? Am I the only one that gets pissed off with everything going in GPMM even config files and roms?

Just occurs to me that GPETC is clearly for config files (like it is for *nix), and people should be putting roms under GAME somewhere, eg GAME\SPECTRUM or GAME\NES and so on. Would make it so much easier to use two different emulators then, if they expected roms in the same dir.

No idea what GPSYS would have been designed for, but I'm guessing it was for system libraries or something, not that I've seen any.

Rant over, sorry, just woke up so forgive me. :)
 
Isn't there a bit of EEPROM left to set a bit? Because if you have 3 SMCs, you need to create config files on every one of them (Ok, not that big of a problem, but still). If you could just set a bit in EEPROM that the program reads, there'd be no problem...
 
RobertJ posted on Jan 19 2005 said:
Just get mirko to init the LCD display the same way that the sdk does, if he hasn't already, then recompile.
Click to expand...
Right, but I think it's safe to assume that Mirko doesn't currently have the necessary information to implement this, otherwise he had done it already. So that information would have to be acquired first (and not necessarily by Mirko himself ofcourse).
 
Last edited by a moderator:
The Phantom posted on Jan 19 2005 said:
DaveMidknight posted on Jan 19 2005 said:
Hi,

fdave solution works fine (just tested), as long as every flashed firmware has the correct version. 1.66 for BLU+ and 1.57 or below for all the GP32 with Samsung LCD.
Click to expand...
The non-plus BLU firmware version is also 1.6.6. (Recall that to distinguish BLU from BLU+ you have to look at the date code, not the firmware version because they're both 1.6.6). Besides, we don't know if there will be another non-plus BLU firmware version available in the future (unlikely maybe, but something that should be taken into account.)

The best solution would probably be to use the same way of initting the LCD that GPSDK uses, which presumably involves calling some BIOS function. I'm not sure whether or not anyone has reverse engineered this yet.
​
Click to expand...

Where is the date code?
4 bytes up?
 
Last edited by a moderator:
synkro posted on Jan 19 2005 said:
reading the BIOS version is IMHo not the key because of the various existing/coming BIOS's. What is the Problem with that .cfg? I just one standard procedure everybody has to code

1.) is there a cfg file?
2a.) NO: ask the user if he/she sees any grey bar of if he has a BLU+
3a.) create .cfg reboot GP32
2b.) YES: load .cfg

so what? only ONE reboot per SMC, I think this is acceptable. So all coders have to commit oneself to include these procedure (whick should be standard/open source/ for both SDKs)....
​
Click to expand...

How you going to prompt the user if the screen isn't initted?
 
Last edited by a moderator:
Ok guys, Personally in my software, this is going to be my approach:

1) Check for 'lcd.cfg' in GPSYS or GPETC (not sure which yet)
2) Read first char. Should be '0' or '1' (I like reading the file better than just detecting it, even though its slightly more work).
3) If the first byte is 0, BLU - If the first byte is 1, BLU+
5) If the file doesn't exists, read the firmware version
6) If old version, BLU - If new version BLU+
7) Have option in the menu to change version, which also creates file.

So the order is:
Check config file
Check bios version
Allow user to change in menu

If gamepark are idiotic enough to change LCD again in the future, the byte read from the text file could be '2', '3' etc.
 
Sound good to me, pea. I would pick GPETC, even I picked GPSYS at first, but GPETC makes more sense for a cfg-file.

Hope the others will agree, too.

Dave
 
GPETC it is then. And in some instances it may not be feasible to add the LCD version to the menu (such as patching older code to work with the BLU+) so:
checking for the text file,
failing that checking the bios version
Should be fine. If the bios check fails, they can read the readme with the game and create the text file themselves.

EDIT: Psuedo code (i.e. not real). Please note that BLU is the default. The BLU+ code is only run if the text file is set to '1' or the version is new, in all other cases the normal BLU code is run.

Code: 
static int InitFrameBuffer(void *buffer,int depth,int rate){
 int bios=0;
 char lcdType = 0;

 // Check if text file exists
 if (text_file_exists){
   // Load the first byte
   lcdType = read_first_byte();
 }
 // Otherwise, check bios version
 else{
   // Find out if it's a new LCD or an old one:
   bios=*(int *)0x1014;
   if (bios>=0x01030606){ lcdType = '1'; }
   // Create the text file with the detected version
   create_text_file( lcdType );
 }
 
 // Do actual framebuffer init
 if (lcdType=='1'){
   return gp_initFramebufferBP(buffer,depth,rate);
 }else{
   return gp_initFramebuffer  (buffer,depth,rate);
 }               
}
 
Let us assume the following for a moment:

1) Somebody somewhere has the source to the official SDK

2) The official SDK has no problems initing the LCD properly so it works on both the old and new units

3) Mirko's code is not initing the display properly, but was doing it enough to work with the earlier GP32 units

4) Somebody who has the source to the official SDK will send a snippet of code to Mirko which will help him fix his library

So surely we can come to the conclusion that there is no need for a file that you are going to expect newbie users to put in before their stuff works properly. :)

A directory standard would be very good if we could get all the main emulator / app authors to use it.

All config files to go in GPETC and end in cfg
All emulator rom files to go in GAME\platform, where platform is C64, SPECTRUM, ARCADE, etc, either zipped or rar'd, or expanded in a subdir.

Just my tuppence worth. :)
 
RobertJ posted on Jan 20 2005 said:
Let us assume the following for a moment:

1) Somebody somewhere ...
2) The official SDK ...
3) Mirko's code is ...
4) Somebody who has the ...

So surely we can come to the conclusion that there is no need for a file that you are going to expect newbie users to put in before their stuff works properly. :)
​
Click to expand...

Let us assume you have the source of the official SDK. Great, send it Mirko. Problem solved!
Otherwise a lot of assumptions ;)

Dave
 
Last edited by a moderator:
Code: 
;************************************************************************
;int GpGraphicModeSet(int gd_bpp, int * gp_pal)  
;************************************************************************
	IMPORT	__gpver_for_hw
	IMPORT	__gpver_for_fw
GpGraphicModeSet
  stmdb	sp!,{r12,lr}
  stmdb	sp!,{r0-r2}
  mov  r0,#GOS_RES_GDI
  bl  _gp_os_res_lock
  ldr  r0,[sp],#4
  ldr  r1,[sp],#4
  mov  r2,#0
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;by achi 2002.1.8
;register backup
  stmdb	sp!,{r0}  ;sp-->r0,r2,r12,lr
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++	
  swi  _SCMD_LCD_STATUS
  stmdb	sp!,{r0,r1}  ;sp-->r0,r1,org r0,r2,r12,lr
  mov  r0,#GOS_RES_GDI
  bl  _gp_os_res_unlock
;+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;by achi 2002.1.8
;bug fixing code for 16bit graphic mode set
;	call swi_get_base. argument is 8
;	if fw version is less than 1.5, r0 & r1 should be NULL
;add
  ldmia	sp!,{r0-r2}  ;load r0, r1, original r0 --> so r2 is original r0. i.e. gd_bpp
  stmdb	sp!,{r0,r1}  ;sp-->r0,r1,r2,r12,lr
  cmp  r2,#0x10
  bne  %F0    ;if not 16bpp then, exit
  
  mov  r0,#8
  mov  r1,#0
  swi  _SCMD_GET_BASE
  add  r0,r0,r1
  cmp  r0,#0x10
  bge  %F0    ;if version base get swi exists, then fw is normal !!!
  ldr  r0,=0x14a00010	;else you can access hardware address (LCDCON5)
  ldr  r1,[r0]
  bic  r1,r1,#0x3
  orr  r1,r1,#0x1  ;bswap disable, hwswap enable
  str  r1,[r0]
0
;++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  ldmia	sp!,{r0-r2,r12,pc}

Have fun
 
As someone has already mentioned, the official SDK bases it on the firmware version
As someone else has already mentioned, future firmware/bios releases may not work using this system.

Hence the file. Otherwise we would just use the firmware version as the official SDK does. or not?
 
It's a version # that apparently isn't used by anything except the SDK. This being true, not everyone is making their own firmware, so why not just make sure that the firmware makers standardize this version # and that's the end of it. With this, the BLU+ setting will be known PER MACHINE, where it really matters, instead of PER CARD, where cards may be moved from machine to machine.
 
I think the problem is that *just in case* the firmware version number happens to be wrong, users will have no way of setting the LCD version except for flashing new firmware.

I guess this is ok though.

If we didn't have to use a text file at all, that would be a lot easier/cleaner solution.
 
You must log in or register to reply here.

Similar threads

Pickle
Sdl-config
Replies
8
Views
6K
Pickle
Pickle
M
GP32 c++ and iostrem
Replies
2
Views
1K
millettc
M
PSyMastR
Ok, Im An Idiot
Replies
3
Views
1K
PSyMastR
PSyMastR
silentbird70
Cross Compiling Have Libgcc_S.so.1 And Libc.so.6 Error
Replies
12
Views
7K
silentbird70
silentbird70
T
GP32 What About This ?? Bad Idea Or Not ?
2
Replies
23
Views
3K
BaDToaD
BaDToaD
Back
Top