Main > Main Forum

GAMEBOX Multi-Game Platform TV Video Game Console -MAME-

Pages: << < (36/50) > >>

shanghaiguide:

The board I've been buying (lots of!), has 4G Flash onboard, but no SD.

You can mount the Flash as a FAT32 partition by plugging in a USB cable.
You can then copy games over, and hope they work.

Currently I need to dump a full copy of the current firmware so I can take it apart a bit.
I succeeded in getting the boot loader and other things clearly identified dumpwise, but need to double check a few things before I make one the sacrificial goat and flash stuff to it.

Its designed from ground up to be a jamma replacement.
It takes power from JAMMA  - no external PSU.
It can output via VGA or the standard JAMMA out, which is convenient.

I also got another (slightly different) one today, which I'll be dissecting.

Software wise - its slightly deficient, but thats remediable.
The current software compile is aimed at "it works, its good enough" vs our nitpicky - OMG!!!! forced to 30fps!!!  I must commit hari-kiri now lest I profane the SF gods!

That is solvable though.

For the most part I find emulation speeds to be quite acceptable, although some of the audio is a bit wonky on some roms.  Thats not the hardware though, thats the software.

Currently no 6 button support. 

If I could get enough people interested (probably 100+ pre-orders sort of level), then I can have the factory make some board revisions.  There are spare GPIO's available onchip, so doable with a revised design.

Currently its FBANext bastardized Chinese edition missing bits edition, so its got some wierd ass bugs and rom support.

CPS1 works
CPS2 works
CPS1-SYSTEM-DASH works
NEO-GEO works
Psyko - works
Cave (PGM) - FBANext supported stuff works eg ProGear (although could be slightly better if we changed the Z80 emulator in use)

The menu system doesn't recognise some of the rom's that work; its obviously doing some kind of lookup for game photo's internally on the FS so it "recognizes" files.  Once I get a proper dump of the NAND I'll be able to get a better look.

The FS is YAFFS2, so I need to make a full dump.
Then write some code to iterate through the dump page by page, remove the pages that are marked bad in the dump (as the 4750 doesn't do ECC in its NAND support the way the bootloader expects it to), then write out the revised  NAND Dump. 
I then need to check where the MTD structures are, then identify partition start and end, and then dump that.

Then once I have those written out on disk as separate files for each potential FS, I need to try mount in yaffs2 and see if it can be mounted, and what I've screwed up.


I have some current rom dumps I've made, but I'm not 100% sure on success yet, as the usb_boot doesn't quite support the NAND format that the board actually uses (it uses an 8096 byte + 488 byte block size), but the uboot doesn't support 8k sizes properly, so munges things.

I can dump correctly (I think), based on looking at the current partial NAND dump's I've made

So far I've identified code segments in the following area's:


0x00000 - 0x0840 ? bootloader
0x02000 - 0x2840 ??
0x04000 - 0x4840 MINIOS kernel (bootloader?)

Sample dump of base memory of NAND below:

USBBoot :> nreadraw  0 1024 0 0


--- Code: ---00000000  ff 55 55 55 55 55 55 55  ff ff ff ff 01 00 11 04  |.UUUUUUU........|
00000010  00 00 00 00 21 e0 e0 03  00 00 e9 8f 21 e0 20 01  |....!.......!. .|
00000020  00 80 1d 3c 00 40 bd 37  00 80 19 3c 90 06 39 27  |...<.@.7...<..9'|
00000030  08 00 20 03 00 00 00 00  00 00 00 00 00 00 00 00  |.. .............|
00000040  1b 43 02 3c 83 de 42 34  19 00 82 00 0f 00 02 3c  |.C.<..--BINGO! Either that, or I was attempting to say "before" but it was too many letters to type--.......<|
00000050  10 20 00 00 40 42 42 34  82 24 04 00 1b 00 44 00  |. ..@BB4.$....D.|
00000060  f4 01 80 00 50 c3 03 34  21 60 a0 00 12 48 00 00  |....P..4!`...H..|
00000070  1b 00 69 00 f4 01 20 01  12 28 00 00 02 10 25 71  |..i... ..(....%q|
--- End code ---

I've been running the nreadraw dumps through a simple parser (without the code offset segments)
like so:

sfk filter raw.txt +hextobin raw.bin

with http://stahlworks.com/dev/index.php?tool=hextobin

Then running

hexdump -C  raw.bin  to get a prettified dump like above

---

From the Spanish forum (translated by google):

12 bytes are recorded on the NAND indicate the configuration of the same: if the bus is 8 or 16 bits, is shared or not, the page size and number of read cycles required. According to data stored on the NAND (FF 55 55 55 55 55 55 55 FF FF FF FF) configuration that leaves here is: FF: The bus is 8 bits. 55 55 55 55 55 55 55: bytes of checking to see if the bus is shared or not (55 is 01010101). In our case, is shared with the SDRAM. FF: 3 cycles of row. FF FF: Page Size: 4KB FF: not used. All this, as expected, coincides with the data we have from the NAND.


I'm using the following for usb_boot config:


--- Quote ---[NAND]
BUSWIDTH            8    ;The width of the NAND flash chip in bits (8|16|32)
ROWCYCLES    3    ;The row address cycles (2|3)
PAGESIZE            8192    ;The page size of the NAND chip in bytes(512|2048|4096)
PAGEPERBLOCK    256    ;The page number per block
FORCEERASE    0    ;The force to erase flag (0|1)
OOBSIZE        448    ;oob size in byte
ECCPOS        6    ;Specify the ECC offset inside the oob data (0-[oobsize-1])
BADBLACKPOS    0    ;Specify the badblock flag offset inside the oob (0-[oobsize-1])
BADBLACKPAGE     0 ;Specify the page number of badblock flag inside a block(0-[PAGEPERBLOCK-1])
PLANENUM            2    ;The planes number of target nand flash
BCHBIT        8    ;Specify the hardware BCH algorithm for 4750 (4|8)
WPPIN        0    ;Specify the write protect pin number
BLOCKPERCHIP    0    ;Specify the block number per chip,0 means ignore

[END]
--- End quote ---


NAND is a 4G HYNIX -

HYNIX_H27UBG8T2A 3.3V 32Gbit NAND
4096M x 8bit

USB_Boot NANDquery gives:

 ID of No.0 device No.0 flash: //
 Vendor ID    :0xad  (Hynix) //Manufacturer Code
 Product ID   :0xd7  (Device ID) // Device Identifier
 Chip ID      :0x94  //Internal Chip Number
 Page ID      :0x9a  //Page Size/BlockSize/Redundant Area
 Plane ID     :0x74  //Plane Number , ECC
 Tech ID      :0x42 //Tech / EDO /Interface


-----
Manual says:
3.3V Bus Width x8
2 Planes of 1024 blocks.  Each block has 256 programmable pages.  Each Page 8640 bytes (8192+448spare)

If I check the byte sequence against the HYNIX chipset documentation I get the following from the numbers:

3rd Byte Dev ID

0x94=0b10010100

00 -  Internal Chip Number 1
01 -  4 Level Cell (cell type)
01 -  2 pages programmed at once
10 -  Interleave supported, Write Cache Supported

0x9a=0b10011010

10 - 8kb page size
0 10 - 448 Bytes (redundant area size)
1 01 - 2M Block Size (without spare area)

0x74=0b 0 111 01 00

01 - 2 Planes
ECC level - reserved.

0x42=0b01 000 010
010 32nm Nand
0 EDO Supported
0 SDR NAND Interface

---

The prelim dumps look correct though, but bootloader won't let me go to a specific page without screwing up the dump location+numbering, so, so far I've been doing dumps via copy / paste of portions of code iteratively from the start.

eg from

nread 0 81920 0 0  (copy, paste to new file)
then

nread 0 163840 0 0  (copy from 81920 -> end, paste to new file)

repeat...

bit tedious doing that for all 4G!

Would be nicer to have proper piping access on Linux, instead of having to use crappy Windows only tools.

I'm getting there though.
I also have a working compile environment going, so when I do finally get a FS dumped correctly thats mountable, I can go ahead, wipe it, then compile up Linux or similar.

Then I can use this as a base board to emulate anything vs only what the board designers half assedly added.

I do enjoy this kind of thing though, and I already got quite far last night on this.

eg


--- Quote ---strings *.bin
UUUUUUU
@BB4
4 "--BINGO! Either that, or I was attempting to say "before" but it was too many letters to type--
C$!(
$!0@
$! @
c4%8C
M4!0
4 "--BINGO! Either that, or I was attempting to say "before" but it was too many letters to type--
xK   T
k)=l
7;%_
'! 
B$+
 Prepare to Download MINIOS.
 Ingenic Semiconductor Co., Ltd. Loader Version V1.0
1: Bad Block
2: Bad Block
Uncorrect ECC Error
 Jump to 0x
 Launch...
Uncorrectable error occurred
stat = 0x
oob_size =
read 61th page error!,read next page
read 62th page error!
Stop here,please check nand status!
@` @
@z@@@r
@@gX@
wH@@
; @@
@@?0P@
--- End quote ---


So, NAND format must be close to correct or correct, as I have actual readable text from the bootloader in my dump.

:)


I believe that this board and the gamebox board will turn out to be fairly similar software wise - same cpu, diff hardware i/o, but otherwise I'm expecting minor differences, so a lot of the work on that, or on the Dingux a330 / a380 should be portable to this without too much change.

Its a bit technical, I know, but basically - I like the hardware.  Software isn't quite there, but thats fixable, and I know how to do it, and am working on it.



shanghaiguide:

Er "--BINGO! Either that, or I was attempting to say "before" but it was too many letters to type--" isn't in my dumps, so I think the board software is doing some cackhanded autoreplacement on something in my post!

Ignore those parts, as they aren't part of the notes.


Have been reading up on my MTDNAND structures also, as thats going to be necessary to verify stuff / split apart cleanly.
This is dry, but good reading:

http://www.kernel.org/doc/htmldocs/mtdnand.html

Some of this might be useful also - http://imxcommunity.org/group/imx28andimx28evk/forum/topics/nand-boot-attempt-no-bcb-error-0x80508001?xg_source=activity

Mostly as its also same chip in use, and I'm not quite sure on the ECC side of things / BCH values, so its often good to read other peoples attempts to solve issues as often its the same stuff people go through again and again...

emphatic:

 :applaud: Very nice work! It's good to have someone working with a standard set above the usual "knockoff copy BS" that China mostly offers with bad frame skipping etc.

I have been eyeing a 19in1 PCB for a while but this sounds better even better. I prefer having the original PCB for most of my games, but some are too rare to hunt down today.

6. Would it be possible to have a menu that can be changed from horizontal to vertical? Just porting Advancemenu (or have it as an option) to this hardware would be a great frontend as it picks up any new game rom on each reboot.

7. Will all games run in native res/refresh rate?


Note: Progear is CPS2 and not PGM. For good games to try in the PGM driver, check out DDP DOJ or Ketsui which both lack any slowdown on original hardware.

BobA:

Great work. Nice to see a newer board being taken apart and put back together with the purpose of improving the software side.  Software on the xxx in 1 boards have not advanced much over the years.   :applaud: :applaud: :applaud:

shanghaiguide:

I also have a newer board my staff ordered for me (but didn't tell me about), which I need to *not look at* until this one gets further, lest I get distracted.

The 2nd one is more expensive, lacks VGA, and USB though, so I think I like my cheaper more usable one :)

More notes on my reverse engineering on the current one here -

http://www.computersolutions.cn/blog/?p=850

I have pretty much every arcade XXX in 1 available locally, as I've been selling them (post testing to see whats actually good). 
The 19 in 1 has a horrible UI that doesn't like sitting in a game, and exits out as soon as you so much as blink. 
Me no likey, but it is a third the price of the newer boards...

It does have defender though, and I did just order some 4 way sticks, and...  ---fudgesicle---.. Just made another machine...

I also have a 60 in 1 in a cocktail at the office.  The 60 in 1 is crap slow booting up (minutes!)


So..., I think its best I get this one up and running, so I can crosscompile an ancient version of SDL MAME or similar then its the same thing, but... better :) or something else, or fix the current stuff better or.. or...   go to sleep as its almost 5am here in China.


--- Quote ---It's good to have someone working with a standard set above the usual "knockoff copy BS" that China mostly offers with bad frame skipping etc.

--- End quote ---

I know why that happens, and its because they don't speak to the clients, so don't know people complain about it.
Its also because the dev houses are secretive ---daisies--- when it comes to giving out any info, even when it is all based on existing open source stuff..  Sigh, so even if you did offer to assist them, they're like - WHY?  You wants our source doesn't you.  Noo its my ring, er source code.




Pages: << < (36/50) > >>

Go to full version