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
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|
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=hextobinThen 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:
[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]
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
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@
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.