The Eye of Typhon ALPHA version released - Page 1

1

Le 16/05/2021 à 19:25

Hello,

TeoT Alpha has just been released for the neogeo

Also introducing ngDataLinker a little tool and method to use bank switching using NEODEV :
https://github.com/ozzyyzzo4096/ngDataLinker

Enjoy

All I can say is wow! The Alpha looks terrific! You can tell you guys put some real love into it!!

It is going to be a terrific week!

Thanks soooo much for this great tool!
I'm really curious to see if I can get it working!

This is really exciting stuff!!! Thanks again!!!

3

Le 17/05/2021 à 06:24

Thanks ^^

Yep we are putting our best efforts and love into this project , next version (closed Beta) will bring better controls + tuning and at a later date the final rom will be released for free

Concerning bank switching it just works as shown with this Alpha (proof of concept) ;-)

For your own projects you just need several makefiles where you put your data (tables/obj) in.

NgDataLinker will take care of the addresses , everything is explained on the git Readme ;-)

For testing out, i recommend to use Mame as there are compatibilities issues with P roms layout using NeoSD and NeoBuilderUI_1.06 which is expecting *only* two roms P1 (1MB) and P2 (1 to 8MB) .

To get the proper layout and build up P2 from several files u can use the new version of RomWak 0.3f as i've added to it a new concatenate option /c

https://github.com/freem/romwak/

Have fun

4

Le 17/05/2021 à 15:54

Really impressive work

Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

5

Le 17/05/2021 à 18:28

Really very impressive but there is still a lot of work to do... I hope you can do it, then it could be a awesome project!

6

Le 18/05/2021 à 04:55

I will apologize in advance as I will probably butcher this...

I'm really excited to see if I can get 8x time more P memory built into my current coding rig!!!!!!!!!!!
My goal is to see if based on what I am describing the NgDataLinker 1.0 can fit into my setup?

To my knowledge I am using Banking via DATLib at the moment.

I can access 4 banks of GFX data but my limitation is I cannot combine gfx from these banks in the same scene.
I also believe 8x more P means the ability to build more GFX!!!!!!!

Ok I am going to try and describe how it is all setup now.
It has been a very long time since I have reviewed this stuff and I am not great at the technical stuff.

I have 4 .xml files that build the GFX data. Each file has a setup at the top of it.
"fillmode" changes in each file.
I think each Bank is set to be 8mb's in size

EX:

//Bank 0 
<setup>
    <starting_tile fillmode="dummy">256</starting_tile>
    <charfile>out\bk0Char.bin</charfile>
    <mapfile>out\bk0Maps.s</mapfile>
    <palfile>out\bk0Pals.s</palfile>
    <incfile>out\bk0Include.h</incfile>
  </setup>

//Bank 1
 <setup>
    <starting_tile fillmode="none">65536</starting_tile>
    <charfile>out\bk1Char.bin</charfile>
    <mapfile>out\bk1Maps.s</mapfile>
    <palfile>out\bk1Pals.s</palfile>
    <incfile>out\bk1Include.h</incfile>
  </setup>

//Bank2
<setup>
    <starting_tile fillmode="none">131072</starting_tile>
    <charfile>out\bk2Char.bin</charfile>
    <mapfile>out\bk2Maps.s</mapfile>
    <palfile>out\bk2Pals.s</palfile>
    <incfile>out\bk2Include.h</incfile>
  </setup>

//Bank 3
<setup>
    <starting_tile fillmode="none">196608</starting_tile>
    <charfile>out\bk3Char.bin</charfile>
    <mapfile>out\bk3Maps.s</mapfile>
    <palfile>out\bk3Pals.s</palfile>
    <incfile>out\bk3Include.h</incfile>
  </setup>

Then I get Bank0.h Bank1.h Bank2.h Bank3.h that I include in my project.

Here is an example of Bank0.h all the other Bank files are very similar.
*Edit - I think DATLib is doing what the NgDataLinker 1.0 is doing when generating the Bank0-3.h files in this step. (but I could be wrong)

#ifndef __BANK0GFX_H__
#define __BANK0GFX_H__

#define BoxOrange 0x0020458e
#define Mission1 0x00200160
#define GD_Explosion_Palettes 0x002441fe
#define BoxBrown 0x00204624
#define BoxPurple_Palettes 0x00243e8c
#define BoxYellow 0x002045ac
#define Bios_Palettes 0x00243dc0
#define GD_Explosion 0x00242f46
#define BoxPink 0x00204642
#define Bullet1_Palettes 0x002441bc
#define TM_00177 0x0021d80a
#define Bullet1 0x002425c8
#define BoxRed 0x00204660
#define Bios 0x00200000
#define BoxOrange_Palettes 0x00243e26
#define Rob 0x0023732a
#define BoxGreen_Palettes 0x00243e04
#define BoxYellow_Palettes 0x00243e48
#define DebugBox0 0x0020467e
#define Rob_Palettes 0x00243f9a
#define BoxBlue_Palettes 0x00243e6a
#define BoxTeal_Palettes 0x00243eae
#define BoxRed_Palettes 0x00243f14
#define BoxGreen 0x00204570
#define BoxPink_Palettes 0x00243ef2
#define BoxBlue 0x002045ca
#define TM_00177_Palettes 0x00243f58
#define BoxBrown_Palettes 0x00243ed0
#define BoxPurple 0x002045e8
#define BoxTeal 0x00204606
#define Mission1_Palettes 0x00243de2
#define DebugBox0_Palettes 0x00243f36
#endif

To access my the Banks via code I use this command then I call the GFX I want to display.

//Bank 0
volMEMWORD(0x2ffff0)=0;
//Display GFX

//Bank 1
volMEMWORD(0x2ffff0)=1;
//Display GFX

//Bank 2
volMEMWORD(0x2ffff0)=2;
//Display GFX

//Bank 3
volMEMWORD(0x2ffff0)=3;
//Display GFX

The makefile I use is never altered it looks like this.
(I do all my coding in .h files...I realize it is probably bad form but it helps me be versatile and jump to other projects without changing the makefile)

# $Id: Makefile,v 1.4 2001/05/03 13:43:42 fma Exp $

#######################################
# Base dir of your m68k gcc toolchain #
#######################################

BASEDIR = $(NEODEV)
AS = as
LD = gcc
CC = gcc
AR = ar
OBJC = objcopy
BIN2O = bin2elf
GFXCC = gfxcc
FIXCNV = fixcnv

#######################################
# Path to libraries and include files #
#######################################

INCDIR = $(BASEDIR)/m68k/include
LIBDIR = $(BASEDIR)/m68k/lib
TMPDIR = tmp

###################################
# Output: {cart, cd} *lower case* #
###################################
OUTPUT = cart
#OUTPUT = cd

############################
# Settings for cart output #
############################
ROMSIZE = 0x20000
PADBYTE = 0xFF

##############################
# Object Files and Libraries #
##############################


OBJS = $(TMPDIR)/crt0_$(OUTPUT).o $(TMPDIR)/main.o

LIBS = -lDATlib -lprocess -lc -lgcc

#####################
# Compilation Flags #
#####################

ASFLAGS = -m68000 --register-prefix-optional
LDFLAGS = -Wl,-T$(BASEDIR)/src/system/neo$(OUTPUT).x -Xlinker -Map=output.map
CCFLAGS = -m68000 -O3 -Wall -fomit-frame-pointer -ffast-math -fno-builtin -nostartfiles -nodefaultlibs -D__$(OUTPUT)__
ARFLAGS = cr
DEBUG = -g

##################
# FIX Definition #
##################
FIXFILES = $(BASEDIR)/src/shared/fix_font.bmp

##############
# Make rules #
##############

ifeq ($(OUTPUT),cart)
Build/dev_p1.bin : Build/test.o
#	$(OBJC) --gap-fill=$(PADBYTE) --pad-to=$(ROMSIZE) -R .data -O binary $< $@
	$(OBJC) --gap-fill=$(PADBYTE) -R .data -O binary $< $@
#	copy dev_p1.rom c:\mame\roms\dev.bin /y
	
else
Build/test.prg : Build/test.o
	$(OBJC) -O binary $< $@
endif

#test.o : test.fix $(OBJS)
Build/test.o : $(OBJS)
	$(LD) -L$(LIBDIR) $(CCFLAGS) $(LDFLAGS) $(OBJS) $(LIBS) -o $@

$(TMPDIR)/%.o: %.c
	$(CC) -I$(INCDIR) $(CCFLAGS) -c $< -o $@

$(TMPDIR)/%.o: %.s
	$(AS) $(ASFLAGS) $< -o $@

clean:
	rm -f $(TMPDIR)/*.*
	rm -f palettes.pal
	rm -f test.o
	rm -f test.prg
	rm -f test.fix
	rm -f test.spr
	rm -f dev_p1.rom

############
# FIX Rule #
############

#test.fix : $(FIXFILES)
#	$(FIXCNV) $(FIXFILES) -o $@ -pal palettes.pal
#
#$(TMPDIR)/palettes.o: palettes.pal
#	$(BIN2O) $< palettes $@

Any tips or suggestions to on if it is possible to build this into the existing rig would be amazing. Thanks again for this great enhancement!!!!!

7

Le 18/05/2021 à 06:15Edité par ozzyyzzo le 18/05/2021 à 07:17

blastar (./5):
Really very impressive but there is still a lot of work to do... I hope you can do it, then it could be a awesome project!

yep, a lot of work needs to be done you're definitely right !!

Luckily, we had super cool help from some experienced people with a recent NeoSoundBuiler update and it's new crazy amount of 1792 sfx and the help to fix up Neo-SD compat issues was really welcome. ;-)

8

Le 18/05/2021 à 06:32

Mega Shocked (./6):
I will apologize in advance as I will probably butcher this...

Any tips or suggestions to on if it is possible to build this into the existing rig would be amazing. Thanks again for this great enhancement!!!!!

I'm not using DATlib myself, and i'm not aware of its limitations if any, but i guess it should be possible to do so.
*Unfortnately your makefile listing is not complete*

But anyhow, what you will need is to add more makefiles to your build process.

atm, your main makefile is generating dev_p1.rom and should contains all your OBJS (.o)
as suggested by the output name, everything will be located into P1 ROM (1MB)

just create another makefile which will output dev_p2.rom and move some OBJS from the original makefile in this one (by this you are intentionally associating data from P1 to P2)
then use romwak accordingly on dev_p2.rom (just like it is done with dev_p1.rom)

Finally, if you need more than 1MB in P2 you will need to concatenate multiple files (ex : xxx-p2..rom+xxx-p3.rom+xxx-p4.rom = xxx-p2.bin)

For TeoT for instance i'm building 9 makeifles generating : dev_p1.rom to dev_p9.rom
then using romwak, building roms process is as follow :

romwak /f dev_p1.rom 202-p1.bin
romwak /p 202-p1.bin 202-p1.bin 1024 255

romwak /f dev_p2.rom 202-p2.bin
romwak /p 202-p2.bin 202-p2.bin 1024 255

romwak /f dev_p3.rom 202-p3.rom
romwak /p 202-p3.rom 202-p3.rom 1024 255
romwak /c 202-p2.bin 202-p3.rom 202-p2.bin

romwak /f dev_p4.rom 202-p4.rom
romwak /p 202-p4.rom 202-p4.rom 1024 255
romwak /c 202-p2.bin 202-p4.rom 202-p2.bin

romwak /f dev_p5.rom 202-p5.rom
romwak /p 202-p5.rom 202-p5.rom 1024 255
romwak /c 202-p2.bin 202-p5.rom 202-p2.bin

romwak /f dev_p6.rom 202-p6.rom
romwak /p 202-p6.rom 202-p6.rom 1024 255
romwak /c 202-p2.bin 202-p6.rom 202-p2.bin

romwak /f dev_p7.rom 202-p7.rom
romwak /p 202-p7.rom 202-p7.rom 1024 255
romwak /c 202-p2.bin 202-p7.rom 202-p2.bin

romwak /f dev_p8.rom 202-p8.rom
romwak /p 202-p8.rom 202-p8.rom 1024 255
romwak /c 202-p2.bin 202-p8.rom 202-p2.bin

romwak /f dev_p9.rom 202-p9.rom
romwak /p 202-p9.rom 202-p9.rom 1024 255
romwak /c 202-p2.bin 202-p9.rom 202-p2.bin

hope that helps

note: you will have to build by yourself the new version of romwak (0.3f) which contains the concatenate option /c
(freem seems lazy enough not providing the latest binary release) lol ... just kidding... ^^

* update *

It's kinda obvious but using ngDataLinker with P1 (map file) is irrelevant as data from P1 must stay into the memory range [0x00100000- [0x001fffff] as generated by GCC link.
it has to be used with P2 roms and above to keep addresses between range [0x00200000- [0x002fffff] where bank switch mecanism occurs and data can be accessed.

* hint *

Just try with a simple configuration at first : 2 makefiles , let's also forget sprites and others generated data from third party applications.

- don't change anything to your original build setup and let's call your original makefile as 'P1'

- create a second makefile which will output dev_p2.rom and add whatever object you will need to access from your code.. a table for instance.

you could compile and link a C file from the second makefile containing :

const char const messageInABottle[] = "I'll send an S.O.S to the world";

you also have to access the data from somewhere in your OWN code in P1 like :

sprintf(txt,"%s, I hope that someone gets my..",messageInABottle);

but.. compiling and linking P1 will fail because there is no reference about messageInABottle table into modules compiled from P1 makefile.

- use ngDataLinker with P2 map file

generated header should contain a crazy immediate definition like this : #define messageInABottle 0x00200010

- #include the generated header into the P1 source file where messageInABottle table has to be accessed.

- recompile and link P1

- success and you are now accessing a string from P2 , also note that there is no need to specifiy any bank @0x2ffff0 because 1MB P1 and 1MB P2 is the default configuration.

'Message in a bottle, yeah
A year has passed since I wrote my note
I should have known this right from the start'
The Police

9

Le 18/05/2021 à 21:07

Thank you for seeing my SOS and reviewing my message in a bottle.

I tried your suggestion and of creating a P2 rom with some data in it.
Upon doing this I was met with challenges and revelations.

1. In my working directory I created a folder called P2 in that folder another folder titled P2_1
P2>P2_1
etc P2_2 (later on)

The folder contains:

common_crt0_cart.s
crt0_cart.s
LevelCollisionMap.c (Data File I am attempting to include in the P2 makefile)
tmp (directory)
build (directory)
makefile

Sad makefile so far.

# $Id: Makefile,v 1.4 2001/05/03 13:43:42 fma Exp $

#######################################
# Base dir of your m68k gcc toolchain #
#######################################

BASEDIR = $(NEODEV)
AS = as
LD = gcc
CC = gcc
AR = ar
OBJC = objcopy
BIN2O = bin2elf
GFXCC = gfxcc
FIXCNV = fixcnv

#######################################
# Path to libraries and include files #
#######################################

INCDIR = $(BASEDIR)/m68k/include
LIBDIR = $(BASEDIR)/m68k/lib
TMPDIR = tmp

###################################
# Output: {cart, cd} *lower case* #
###################################
OUTPUT = cart
#OUTPUT = cd

############################
# Settings for cart output #
############################
ROMSIZE = 0x100000
PADBYTE = 0x00

##############################
# Object Files and Libraries #
##############################


OBJS = $(TMPDIR)/crt0_$(OUTPUT).o $(TMPDIR)/LevelCollisionMap.o

LIBS = -lDATlib -lprocess -lc -lgcc

#####################
# Compilation Flags #
#####################

ASFLAGS = -m68000 --register-prefix-optional
#LDFLAGS = -Wl,-T$(BASEDIR)/src/system/neo$(OUTPUT).x -Xlinker -Map=output.map
CCFLAGS = -m68000 -O3 -Wall -fomit-frame-pointer -ffast-math -fno-builtin -nostartfiles -nodefaultlibs -D__$(OUTPUT)__
ARFLAGS = cr
DEBUG = -g

##############
# Make rules #
##############


Build/dev_p2.bin : Build/test.o
	$(OBJC) --gap-fill=$(PADBYTE) --pad-to=$(ROMSIZE) -R .data -O binary $< $@

#test.o : test.fix $(OBJS)
Build/test.o : $(OBJS)
	$(LD) -L$(LIBDIR) $(CCFLAGS) $(OBJS) $(LIBS) -o $@

$(TMPDIR)/%.o: %.c
	$(CC) -I$(INCDIR) $(CCFLAGS) -c $< -o $@

$(TMPDIR)/%.o: %.s
	$(AS) $(ASFLAGS) $< -o $@

clean:
	rm -f $(TMPDIR)/*.*
	rm -f palettes.pal
	rm -f test.o
	rm -f test.prg
	rm -f test.fix
	rm -f test.spr
	rm -f dev_p2.rom

"common_crt0_cart.s" - this is an altered version of the NeoDev file provided by DATLib when I run the makefile there are errors related to this file.
I guess the big question is can I somehow use the makefile and ignore incorporating this file into the build process?

c:\NeoDev\src\samples\GAME\P2\P2_1>make
gcc -Lc:\neodev/m68k/lib -m68000 -O3 -Wall -fomit-frame-pointer -ffast-math -fno-builtin -nostartfiles -nodefaultlibs -D__cart__ tmp/crt0_cart.o tmp/LevelCollisionMap.o -lDATlib -lprocess -lc -lgcc -o Build/test.o
tmp/crt0_cart.o: In function `__security_code':
tmp/crt0_cart.o(.text+0x10e): undefined reference to `bkp_data'
tmp/crt0_cart.o: In function `_entry_user':
tmp/crt0_cart.o(.text+0x1f4): undefined reference to `USER'
tmp/crt0_cart.o: In function `_entry_player_start':
tmp/crt0_cart.o(.text+0x1fa): undefined reference to `PLAYER_START'
tmp/crt0_cart.o: In function `_entry_demo_end':
tmp/crt0_cart.o(.text+0x202): undefined reference to `DEMO_END'
tmp/crt0_cart.o: In function `_entry_coin_sound':
tmp/crt0_cart.o(.text+0x20a): undefined reference to `COIN_SOUND'

common_crt0_cart.s

	* ++====================================================================++
	* || common_crt0_cart.s - C Run Time Startup Code for Neo Geo Cartridge	||
	* ++--------------------------------------------------------------------++
	* || $Id: common_crt0_cart.s,v 1.5 2001/07/13 14:46:31 fma Exp $		||
	* ++--------------------------------------------------------------------++
	* || This is the startup code needed by programs compiled with GCC		||
	* ++--------------------------------------------------------------------||
	* || BGM: Guitar Vader - S.P.Y.											||
	* ++====================================================================++

_ZERO_DIVIDE	=	0x00c00426
_CHK_CMD	=	0x00c00426
_TRAPV_CMD	=	0x00c00426
_NPC_1010	=	0x00c00426
_NPC_1111	=	0x00c00426
_IRQ4	=	0x00c00426
_IRQ5	=	0x00c00426
_IRQ6	=	0x00c00426
_IRQ7	=	0x00c00426

********************** Exported Symbols **********************
	.globl	_start
	.globl	atexit

********************** Imported Symbols **********************
	.globl	__do_global_ctors
	.globl	__do_global_dtors
	.globl	main
	.globl	memset
	.globl	__bss_start	
	.globl	_end

********************** Program Start *************************

** NOTE: Cartridge systems have swapped IRQ1 and IRQ2

	.org	0x0000

	.long	0x0010f300	|;reset stack ptr
	.long	0x00c00402	/*;reset ptr*/
	.long	0x00c00408	/*;bus error*/
	.long	0x00c0040e	/*;address error*/

	.long	0x00c00414	/*;illegal instruction*/
	.long	_ZERO_DIVIDE	/*;division by 0*/
	.long	_CHK_CMD	/*;CHK command*/
	.long	_TRAPV_CMD	/*;TRAPV command*/

	.long	0x00c0041a	/*;illegal privilege*/
	.long	0x00c00420	/*;trace exception handling*/
	.long	_NPC_1010	/*;no package command (1010)*/
	.long	_NPC_1111	/*;no package command (1111)*/

	.long	0x00c00426, 0x00c00426, 0x00c00426	/*;unused*/
	.long	0x00c0042c	/*;uninitialized interrupt*/

	.long	0x00c00426,	0x00c00426,	0x00c00426,	0x00c00426	/*;unused*/
	.long	0x00c00426,	0x00c00426,	0x00c00426,	0x00c00426	/*;unused*/
	.long	0x00c00432	/*;virtual interrupt*/
	|; 0x64
	.long _IRQ2, _IRQ1, _IRQ3, _IRQ4, _IRQ5, _IRQ6, _IRQ7	/*;4-7 unused*/

__security_code:
	.long 0x76004a6d, 0x0a146600, 0x003c206d, 0x0a043e2d
	.long 0x0a0813c0, 0x00300001, 0x32100c01, 0x00ff671a
	.long 0x30280002, 0xb02d0ace, 0x66103028, 0x0004b02d
	.long 0x0acf6606, 0xb22d0ad0, 0x67085088, 0x51cfffd4
	.long 0x36074e75, 0x206d0a04, 0x3e2d0a08, 0x3210e049
	.long 0x0c0100ff, 0x671a3010, 0xb02d0ace, 0x66123028
	.long 0x0002e048, 0xb02d0acf, 0x6606b22d, 0x0ad06708
	.long 0x588851cf, 0xffd83607
	.word 0x4e75

	.org 0x100
	.ascii	"NEO-GEO\0"
	.word	_NGH
	.long	_PROGRAM_SIZE
	.long	_WRK_BCKP_AREA
	.word	_WRK_BCKP_AREA_SIZE
	
	.byte	_EYE_CATCHER
	.byte	_EYE_CATCHER_TILES
	
	.long	JPConfig
	.long	USConfig
	.long	EUConfig
	
	jmp	_ENTRY_USER
	jmp	_ENTRY_PLAYER_START
	jmp	_ENTRY_DEMO_END
	jmp	_ENTRY_COIN_SOUND

_irq3_handler:
	move.w	#1, 0x3C000C
_dummy_exc_handler:
	rte
atexit:	|;Dummy atexit (does nothing for now)
	moveq	#0, d0
_dummy_config_handler:
	rts

_irq1_handler:	|;Standard IRQ1 handler
	move.w	#2, 0x3C000C
	rte

	.org	0x182
	.long	__security_code

_dummyTIdata:
	.word 0x0000

|;* Entry point of our program
_start:
	|;* Setup stack pointer and 'system' pointer
	|;lea		0x10F300,a7
	|;lea		0x108000,a5

	|;* Reset watchdog
	move.b	d0, 0x300001
	
	|;* Flush interrupts
	move.b	#7, 0x3C000C

	move.l #0, TInextTable
	
	|;* Enable interrupts
	move.w	#0x2000,sr
	
	|;* Initialize BSS section
	move.l	#_end, d0
	sub.l	#__bss_start, d0
	move.l	d0, -(a7)
	clr.l	-(a7)
	pea		__bss_start
	jbsr	memset
	
	jsr	0xc004c2	|; FIX_CLEAR
	jsr	0xc004c8	|; LSP_1st
	
	|;* Jump to main
	|;* jbsr main

	|;* Call global destructors
	jbsr	__do_global_dtors

	|;* For cart systems, infinite loop
9:
	jmp	9b(pc)


_entry_user:
	|;* Setup stack pointer and 'system' pointer
	|;* stack is set up by bios

	|;* Reset watchdog
	move.b	d0, 0x300001
	
	|;* Flush interrupts
	move.b	#7, 0x3C000C

	move.l #0, TInextTable
	
	|;* Enable interrupts
	move.w	#0x2000,sr

	jmp	USER

_entry_player_start:
	jmp PLAYER_START
	rts
	
_entry_demo_end:
	jmp DEMO_END
	rts
	
_entry_coin_sound:
	jmp COIN_SOUND
	rts

2. DATLib ships with neocart.x and neocartBank.x

I realize I have only been using neocart.x in my P1 makefile I have never actually used neocartBank.x (What the heck!?)
It looks like neocartBank.x focuses on building the 1mb P2 rom (I could be wrong)

So all these years I have only been using a P1 rom to access my gfx banks I guess...??

I wish I could see an example of a makefile using neocartBank.x to see if I can somehow work it into my setup.

I commented out the inclusion of the .x file in P2 makefile to see if I could get it to build but no dice.

Here are those files listed as a reference:

neocart.x

/* $Id: neocart.x,v 1.2 2001/04/13 09:36:11 fma Exp $ */

OUTPUT_FORMAT("elf32-m68k", "elf32-m68k",
	      "elf32-m68k")
OUTPUT_ARCH(m68k)
ENTRY(_start)
 SEARCH_DIR(/usr/m68k/m68k-elf/lib);
/* Do we need any of these for elf?
   __DYNAMIC = 0;    */

MEMORY
{
  /*roma (rx) : ORIGIN = 0x00000000, LENGTH = 0x100000
  ram (rwx) : ORIGIN = 0x00100000, LENGTH = 0xE000
  romb (rx) : ORIGIN = 0x00110000, LENGTH = 0xF0000
  */
  roma (rx) : ORIGIN = 0x00000000, LENGTH = 0x100000
  ram (rwx) : ORIGIN = 0x00100000, LENGTH = 0xF000
  romb (rx) : ORIGIN = 0x00200000, LENGTH = 0x100000
}

SECTIONS
{
  /* Read-only sections, merged into text segment: */
  . = 0x80000000 + SIZEOF_HEADERS;
  .interp     : { *(.interp) 	}
  .hash          : { *(.hash)		}
  .dynsym        : { *(.dynsym)		}
  .dynstr        : { *(.dynstr)		}
  .gnu.version   : { *(.gnu.version)	}
  .gnu.version_d   : { *(.gnu.version_d)	}
  .gnu.version_r   : { *(.gnu.version_r)	}
  .rel.init      : { *(.rel.init)	}
  .rela.init     : { *(.rela.init)	}
  .rel.text      :
    {
      *(.rel.text)
      *(.rel.text.*)
      *(.rel.gnu.linkonce.t*)
    }
  .rela.text     :
    {
      *(.rela.text)
      *(.rela.text.*)
      *(.rela.gnu.linkonce.t*)
    }
  .rel.fini      : { *(.rel.fini)	}
  .rela.fini     : { *(.rela.fini)	}
  .rel.rodata    :
    {
      *(.rel.rodata)
      *(.rel.rodata.*)
      *(.rel.gnu.linkonce.r*)
    }
  .rela.rodata   :
    {
      *(.rela.rodata)
      *(.rela.rodata.*)
      *(.rela.gnu.linkonce.r*)
    }
  .rel.data      :
    {
      *(.rel.data)
      *(.rel.data.*)
      *(.rel.gnu.linkonce.d*)
    }
  .rela.data     :
    {
      *(.rela.data)
      *(.rela.data.*)
      *(.rela.gnu.linkonce.d*)
    }
  .rel.ctors     : { *(.rel.ctors)	}
  .rela.ctors    : { *(.rela.ctors)	}
  .rel.dtors     : { *(.rel.dtors)	}
  .rela.dtors    : { *(.rela.dtors)	}
  .rel.got       : { *(.rel.got)		}
  .rela.got      : { *(.rela.got)		}
  .rel.sdata     :
    {
      *(.rel.sdata)
      *(.rel.sdata.*)
      *(.rel.gnu.linkonce.s*)
    }
  .rela.sdata     :
    {
      *(.rela.sdata)
      *(.rela.sdata.*)
      *(.rela.gnu.linkonce.s*)
    }
  .rel.sbss      : { *(.rel.sbss)		}
  .rela.sbss     : { *(.rela.sbss)	}
  .rel.bss       : { *(.rel.bss)		}
  .rela.bss      : { *(.rela.bss)		}
  .rel.plt       : { *(.rel.plt)		}
  .rela.plt      : { *(.rela.plt)		}
  .init          : 
  { 
    KEEP (*(.init))
  } =0x4e75
  .plt      : { *(.plt)	}
  .text      :
  {
    *(.text)
    *(.text.*)
    *(.stub)
    /* .gnu.warning sections are handled specially by elf32.em.  */
    *(.gnu.warning)
    *(.gnu.linkonce.t*)

    . = ALIGN(0x4);
     __CTOR_LIST__ = .;
    LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
    *(.ctors)
    LONG(0)
    __CTOR_END__ = .;
    __DTOR_LIST__ = .;
    LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2)
    *(.dtors)
     LONG(0)
    __DTOR_END__ = .;
  } =0x4e75
  _etext = .;
  PROVIDE (etext = .);
  .fini      :
  {
    KEEP (*(.fini))
  } =0x4e75
  .rodata   :
  {
  	*(.rodata)
  	*(.rodata.*)
  	*(.gnu.linkonce.r*) 	
  }
  .rodata1   : { *(.rodata1) }
  .gcc_except_table : { *(.gcc_except_table) }
  /* Adjust the address for the data segment.  We want to adjust up to
     the same address within the page on the next page up.  */
  .ctors   ALIGN(4): 
  {
    /* gcc uses crtbegin.o to find the start of
       the constructors, so we make sure it is
       first.  Because this is a wildcard, it
       doesn't matter if the user does not
       actually link against crtbegin.o; the
       linker won't look for a file to match a
       wildcard.  The wildcard also means that it
       doesn't matter which directory crtbegin.o
       is in.  */
    KEEP (*crtbegin.o(.ctors))
    /* We don't want to include the .ctor section from
       from the crtend.o file until after the sorted ctors.
       The .ctor section from the crtend file contains the
       end of ctors marker and it must be last */
    KEEP (*(EXCLUDE_FILE (*crtend.o ) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*(.ctors))
  }
  .dtors         :
  {
    KEEP (*crtbegin.o(.dtors))
    KEEP (*(EXCLUDE_FILE (*crtend.o ) .dtors))
    KEEP (*(SORT(.dtors.*)))
    KEEP (*(.dtors))
  }
  . = ALIGN(0x10) + (. & (0x10 - 1));
  .data    :
  {
    *(.data)
    *(.data.*)
    *(.gnu.linkonce.d*)
  }
  .data1   : { *(.data1) }
  .eh_frame : { *(.eh_frame) }
  .got           : { *(.got.plt) *(.got) }
  .dynamic       : { *(.dynamic) }
  /* We want the small data sections together, so single-instruction offsets
     can access them all, and initialized data all before uninitialized, so
     we can shorten the on-disk segment size.  */
  .sdata     : 
  {
    *(.sdata) 
    *(.sdata.*)
    *(.gnu.linkonce.s.*)
  }
  _edata = .;
  PROVIDE (edata = .);
  __bss_start = .;
  .sbss      :
  {
    *(.dynsbss)
    *(.sbss)
    *(.sbss.*)
    *(.scommon)
  }
  .bss       :
  {
   *(.dynbss)
   *(.bss)
   *(.bss.*)
   *(COMMON)
   /* Align here to ensure that the .bss section occupies space up to
      _end.  Align after .bss to ensure correct alignment even if the
      .bss section disappears because there are no input sections.  */
   . = ALIGN(32 / 8);
  }
  . = ALIGN(32 / 8);
  _end = .;
  PROVIDE (end = .);
  /* Stabs debugging sections.  */
  .stab 0 : { *(.stab) }
  .stabstr 0 : { *(.stabstr) }
  .stab.excl 0 : { *(.stab.excl) }
  .stab.exclstr 0 : { *(.stab.exclstr) }
  .stab.index 0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment 0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }
  /* These must appear regardless of  .  */
}

neocartBank.x

/* $Id: neocart.x,v 1.2 2001/04/13 09:36:11 fma Exp $ */

OUTPUT_FORMAT("elf32-m68k", "elf32-m68k",
	      "elf32-m68k")
OUTPUT_ARCH(m68k)
ENTRY(_start)
 SEARCH_DIR(/usr/m68k/m68k-elf/lib);
/* Do we need any of these for elf?
   __DYNAMIC = 0;    */

MEMORY
{
  roma (rx) : ORIGIN = 0x00200000, LENGTH = 0x100000
}

SECTIONS
{
  /* Read-only sections, merged into text segment: */
  . = 0x80000000 + SIZEOF_HEADERS;
  .interp     : { *(.interp) 	}
  .hash          : { *(.hash)		}
  .dynsym        : { *(.dynsym)		}
  .dynstr        : { *(.dynstr)		}
  .gnu.version   : { *(.gnu.version)	}
  .gnu.version_d   : { *(.gnu.version_d)	}
  .gnu.version_r   : { *(.gnu.version_r)	}
  .rel.init      : { *(.rel.init)	}
  .rela.init     : { *(.rela.init)	}
  .rel.text      :
    {
      *(.rel.text)
      *(.rel.text.*)
      *(.rel.gnu.linkonce.t*)
    }
  .rela.text     :
    {
      *(.rela.text)
      *(.rela.text.*)
      *(.rela.gnu.linkonce.t*)
    }
  .rel.fini      : { *(.rel.fini)	}
  .rela.fini     : { *(.rela.fini)	}
  .rel.rodata    :
    {
      *(.rel.rodata)
      *(.rel.rodata.*)
      *(.rel.gnu.linkonce.r*)
    }
  .rela.rodata   :
    {
      *(.rela.rodata)
      *(.rela.rodata.*)
      *(.rela.gnu.linkonce.r*)
    }
  .rel.data      :
    {
      *(.rel.data)
      *(.rel.data.*)
      *(.rel.gnu.linkonce.d*)
    }
  .rela.data     :
    {
      *(.rela.data)
      *(.rela.data.*)
      *(.rela.gnu.linkonce.d*)
    }
  .rel.ctors     : { *(.rel.ctors)	}
  .rela.ctors    : { *(.rela.ctors)	}
  .rel.dtors     : { *(.rel.dtors)	}
  .rela.dtors    : { *(.rela.dtors)	}
  .rel.got       : { *(.rel.got)		}
  .rela.got      : { *(.rela.got)		}
  .rel.sdata     :
    {
      *(.rel.sdata)
      *(.rel.sdata.*)
      *(.rel.gnu.linkonce.s*)
    }
  .rela.sdata     :
    {
      *(.rela.sdata)
      *(.rela.sdata.*)
      *(.rela.gnu.linkonce.s*)
    }
  .rel.sbss      : { *(.rel.sbss)		}
  .rela.sbss     : { *(.rela.sbss)	}
  .rel.bss       : { *(.rel.bss)		}
  .rela.bss      : { *(.rela.bss)		}
  .rel.plt       : { *(.rel.plt)		}
  .rela.plt      : { *(.rela.plt)		}
  .init          : 
  { 
    KEEP (*(.init))
  } =0x4e75
  .plt      : { *(.plt)	}
  .text      :
  {
    *(.text)
    *(.text.*)
    *(.stub)
    /* .gnu.warning sections are handled specially by elf32.em.  */
    *(.gnu.warning)
    *(.gnu.linkonce.t*)

    . = ALIGN(0x4);
     __CTOR_LIST__ = .;
    LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
    *(.ctors)
    LONG(0)
    __CTOR_END__ = .;
    __DTOR_LIST__ = .;
    LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2)
    *(.dtors)
     LONG(0)
    __DTOR_END__ = .;
  } =0x4e75
  _etext = .;
  PROVIDE (etext = .);
  .fini      :
  {
    KEEP (*(.fini))
  } =0x4e75
  .rodata   :
  {
  	*(.rodata)
  	*(.rodata.*)
  	*(.gnu.linkonce.r*) 	
  }
  .rodata1   : { *(.rodata1) }
  .gcc_except_table : { *(.gcc_except_table) }
  /* Adjust the address for the data segment.  We want to adjust up to
     the same address within the page on the next page up.  */
  .ctors   ALIGN(4): 
  {
    /* gcc uses crtbegin.o to find the start of
       the constructors, so we make sure it is
       first.  Because this is a wildcard, it
       doesn't matter if the user does not
       actually link against crtbegin.o; the
       linker won't look for a file to match a
       wildcard.  The wildcard also means that it
       doesn't matter which directory crtbegin.o
       is in.  */
    KEEP (*crtbegin.o(.ctors))
    /* We don't want to include the .ctor section from
       from the crtend.o file until after the sorted ctors.
       The .ctor section from the crtend file contains the
       end of ctors marker and it must be last */
    KEEP (*(EXCLUDE_FILE (*crtend.o ) .ctors))
    KEEP (*(SORT(.ctors.*)))
    KEEP (*(.ctors))
  }
  .dtors         :
  {
    KEEP (*crtbegin.o(.dtors))
    KEEP (*(EXCLUDE_FILE (*crtend.o ) .dtors))
    KEEP (*(SORT(.dtors.*)))
    KEEP (*(.dtors))
  }
  . = ALIGN(0x10) + (. & (0x10 - 1));
  .data    :
  {
    *(.data)
    *(.data.*)
    *(.gnu.linkonce.d*)
  }
  .data1   : { *(.data1) }
  .eh_frame : { *(.eh_frame) }
  .got           : { *(.got.plt) *(.got) }
  .dynamic       : { *(.dynamic) }
  /* We want the small data sections together, so single-instruction offsets
     can access them all, and initialized data all before uninitialized, so
     we can shorten the on-disk segment size.  */
  .sdata     : 
  {
    *(.sdata) 
    *(.sdata.*)
    *(.gnu.linkonce.s.*)
  }
  _edata = .;
  PROVIDE (edata = .);
  __bss_start = .;
  .sbss      :
  {
    *(.dynsbss)
    *(.sbss)
    *(.sbss.*)
    *(.scommon)
  }
  .bss       :
  {
   *(.dynbss)
   *(.bss)
   *(.bss.*)
   *(COMMON)
   /* Align here to ensure that the .bss section occupies space up to
      _end.  Align after .bss to ensure correct alignment even if the
      .bss section disappears because there are no input sections.  */
   . = ALIGN(32 / 8);
  }
  . = ALIGN(32 / 8);
  _end = .;
  PROVIDE (end = .);
  /* Stabs debugging sections.  */
  .stab 0 : { *(.stab) }
  .stabstr 0 : { *(.stabstr) }
  .stab.excl 0 : { *(.stab.excl) }
  .stab.exclstr 0 : { *(.stab.exclstr) }
  .stab.index 0 : { *(.stab.index) }
  .stab.indexstr 0 : { *(.stab.indexstr) }
  .comment 0 : { *(.comment) }
  /* DWARF debug sections.
     Symbols in the DWARF debugging sections are relative to the beginning
     of the section so we begin them at 0.  */
  /* DWARF 1 */
  .debug          0 : { *(.debug) }
  .line           0 : { *(.line) }
  /* GNU DWARF 1 extensions */
  .debug_srcinfo  0 : { *(.debug_srcinfo) }
  .debug_sfnames  0 : { *(.debug_sfnames) }
  /* DWARF 1.1 and DWARF 2 */
  .debug_aranges  0 : { *(.debug_aranges) }
  .debug_pubnames 0 : { *(.debug_pubnames) }
  /* DWARF 2 */
  .debug_info     0 : { *(.debug_info) }
  .debug_abbrev   0 : { *(.debug_abbrev) }
  .debug_line     0 : { *(.debug_line) }
  .debug_frame    0 : { *(.debug_frame) }
  .debug_str      0 : { *(.debug_str) }
  .debug_loc      0 : { *(.debug_loc) }
  .debug_macinfo  0 : { *(.debug_macinfo) }
  /* SGI/MIPS DWARF 2 extensions */
  .debug_weaknames 0 : { *(.debug_weaknames) }
  .debug_funcnames 0 : { *(.debug_funcnames) }
  .debug_typenames 0 : { *(.debug_typenames) }
  .debug_varnames  0 : { *(.debug_varnames) }
  /* These must appear regardless of  .  */
}

I know it sounds and feels like you are helping a delinquent because you are!

10

Le 19/05/2021 à 06:31

Mega Shocked (./9):
Thank you for seeing my SOS and reviewing my message in a bottle.

I tried your suggestion and of creating a P2 rom with some data in it.
Upon doing this I was met with challenges and revelations.

I know it sounds and feels like you are helping a delinquent because you are!

Hehe,,

yep, first step using 2MB instead of 1MB is a good and easy goal for a start.

Concerning your makefiles 3 suggestions:

1) Don't use and link any code into P2 or above , just data.. this means that you must avoid to link any library.

the line : LIBS = -lDATlib -lprocess -lc -lgcc is suspicious , code and libraries must be linked into 'P1' makefle *only*

2) Watch out about object files collisions your 'P2' makefile is linking over an object called test.o, i would recommend to output link results in different files per makefile (e.g : test1.o to test.9.o)

3) Keep 'P1' makefile as usual with everything required by Datlib there but keep 'P2' almost empty. (you should need only original neocart.x script and your OBJS as data.)

As an example the P2 link command could look like this :

gcc -L%NEODEV%\m68k\lib -m68000 -O3 -Wall -fomit-frame-pointer -ffast-math -fno-builtin -nostartfiles -nodefaultlibs -D__cart__ -Wl,-Map,foo2.map -T%NEODEV%\src\system\neocart.x %NEODEV%\tmp\_level01MapSprite.o -o test2.o

11

Le 19/05/2021 à 18:49Edité par Mega Shocked le 19/05/2021 à 23:55

Well I can't thank you enough for opening this can of worms.
It has got me fascinated with the build process.

So first thanks for your tips! I got the P2 to compile!
At this point I don't know if it will work because I jumped to another tangent in the process but it did build with both my neocart.x and neocartBank.x

Over the years I kinda automated things in my own broken way so I got less and less familiar with the inner workings of the makefile.
Plus I never really had a good grasp of it to begin with.

That said I am slowly realizing what is going on!

My typical makefile uses neocart.x and I have seperate makefiles for the 4 Banks of gfx data I am using that do indeed use neocartBank.x

I know that the more GFX I compile the larger the P rom gets. Since the GFX were compiled separately and they do not appear to be linked in the makefile that builds the P1 I was curious of how the P1 knows to inflate based on more GFX being built?

I came to realize that the makefiles have a .map file in the linker line. My legacy files of NeoDev don't have that.

-Wl,-T$(BASEDIR)/src/system/neocartBank.x -Xlinker -Map=_bankMap.map

When I cracked the file open the file reads this way. (There is more to the file than what is seen here but I can only guess that the files is generated from "neocart.x" or "neocartBank.x"

Memory Configuration

Name             Origin             Length             Attributes
roma             0x00000000         0x00100000         xr
ram              0x00100000         0x0000f000         xrw
romb             0x00200000         0x00100000         xr
*default*        0x00000000         0xffffffff

Linker script and memory map

                0x80000074                .=(0x80000000+SIZEOF_HEADERS)

This leads me to ask based is the configuration above of the output.map file setup to accept 8X the P! or is it limiting the data to only reside in the first 1mb of the P rom?

I would love to unlock romb as I believe I am living a life where roma is doing all the heavy lifting and eventually maxes out at 1mb.

this isn't my first kick at the can.

I exceeded roma here and was confused because I believe there should be more data built into at least the first mb of romb but I was lost then and still am now. lol
Upon reviewing the post I think my confusion was I thought GFX banks were identical to P banks when infact there is a difference.

topics/190747-roma-is-full-banko-section-text#post-7

I believe DATLib does something comparable to the NgDataLinker with the parsemap utility provided. I have been able to access my bank data via including defines with memory locations.

However this now has me fascinated....

In my current case each of my 4 makefiles / .xml files basically create GFX data every 8mbs via adjusting the fillmode then the parsemap utility provides address information that doesn't overlap I guess because the fillmodes have gaps in them.
(I could be wrong with what I'm saying here... factually...I have always been able to build and access all 4 banks of GFX data and reviewing the address information provided in the generated .h files it does not appear that the addresses overlap.)

Why I'm fascinated is because maybe now I can leave the filmodes alone and maybe set them all to something like '256' (Bank 0 has this...just going with that)
I'm think this way because if the rig can accommodate a setup where each mb of P2 points to a different bank information do I need to stagger banks when compiling them?

P2_1 -> Bank0, 0-1mb
P2_2 -> Bank1, 0-1mb
P2_3 -> Bank2, 0-1mb
P2_4 -> Bank3, 0-1mb

Oh wow I still might be able to build map tables into 4 more banks on top of what I already have above! EX:P_5-P8!!!!!?

I am thinking this...
I do realize I am limiting myself (technically P2 can be used for any data) but I would love to see if this rig could work...

P1 is only used for code and hardcoded tables etc
P2 is exclusive to GFX

Would this setup actually allow for the mixing of GFX from different banks in the same scene?
Is the secret in adjusting the neocart.x and neocartBank.x files....

These are mysteries that swirl in my head.

I know that incorporating DATlib is a little off topic as all your work is custom built on top of NeoDev but you ignited a spark and excitement is looming.
Any DATLib users that have mastered the art of romb please chime in if you could help with the working the angles on a 8mb P rom!!!!

I'm hyped up! Thanks for being patient as I stumble ozzyyzzo!

12

Le 19/05/2021 à 19:48

I have no clue of what is going on with Datlib , i do not use it ^^

and yes you can use data from different banks in the same frame/scene, that's what the bank switching mecanism is used for.

13

Le 20/05/2021 à 05:05

Hi ozzyyzzo!

Thanks again for shedding some light on the power of the P's!

I wish I was a cooler poster and could delete some of the non-sense I wrote but it is historical record.

Your tools got me excited and I ripped my little environment apart in search of the true nature of what is going on with my rig and banking.

In the end I am banking with multiple 1mb P2 roms. My mame driver and conversion to NeoSD scripts are the tell tail signs.
In my case with DATLib I don't believe I can yet combine GFX from separate banks but I hope one day I will be able to!

Examples of how I use the banks now:
I can have one whole scene with Attract Mode GFX based on bank 0
Then another whole scene with Gameplay GFX based on bank 1 etc...
FMV is great cause you can just jump from one bank to the next like a flip book.
So there are benefits here forsure!

For reference for anyone reading my non-sense posts the official Mame Driver and NeoSD script I am using look like this.
I'm posting them if perhaps they are slightly useful for example purposes.
(Why didn't I review these before I began digging through my dev environment I'll never know.

)

Mame Driver

<software name="game">
	<description>Game Demo</description>
	<year>2016</year>
	<publisher>MegaShockers</publisher>
	<sharedfeat name="release" value="MVS,AES" />
	<sharedfeat name="compatibility" value="MVS,AES" />
	<part name="cart" interface="neo_cart">
		<dataarea name="maincpu" width="16" endianness="big" size="0x500000">
			<rom loadflag="load16_word" name="dev_p1.bin" offset="0x000000" size="0x100000" crc="bdda2c6e" sha1="6a94dee2d22feb07ea68a90ce67d5cac1b17b9c9" />
			<rom loadflag="load16_word" name="Bank0.bin"  offset="0x100000" size="0x100000" crc="d707ec72" sha1="6ca9b79e5679e49684cb8993f532966df3186ec9" />
			<rom loadflag="load16_word" name="Bank1.bin"  offset="0x200000" size="0x100000" crc="53bed158" sha1="625f9f78980b8272303bd49309ff502e1da68315" />
			<rom loadflag="load16_word" name="Bank2.bin"  offset="0x300000" size="0x100000" crc="53bed158" sha1="625f9f78980b8272303bd49309ff502e1da68315" />
			<rom loadflag="load16_word" name="Bank3.bin"  offset="0x400000" size="0x100000" crc="53bed158" sha1="625f9f78980b8272303bd49309ff502e1da68315" />
		</dataarea>
		<dataarea name="fixed" size="0x040000">
			<rom offset="0x000000" size="0x020000" name="fix.bin" crc="0e6a7c73" sha1="31b1194524dcc80ec4d63bac088b6fb4909f496c" />
		</dataarea>
		<dataarea name="audiocpu" size="0x080000">
			<rom  offset="0x000000" size="0x080000" name="m1.M1" crc="da4878cf" sha1="ce13d18a4c5d01974df8542c67c4df00dbc6e7c1" />
		</dataarea>
		<dataarea name="ymsnd" size="0x800000">
			<rom name="v1.V1" offset="0x000000" size="0x800000" crc="2ced86df" sha1="d6b73d1f31efbd74fb745200d4dade5f80b71541" />              
		</dataarea>
		
		<dataarea name="sprites" size="0x2800000">
			<rom loadflag="load16_word" name="bk0char.bin" offset="0x000000"  size="0x800000" crc="a9bdc000" sha1="93b0dfcd2121ddf6ea1fe99514a176d76e4b0c98" />
			<rom loadflag="load16_word" name="bk1char.bin" offset="0x800000"  size="0x800000" crc="f8e21968" sha1="e103d4f59cd841267b882580aee338e99f192c3f" />
			<rom loadflag="load16_word" name="bk2char.bin" offset="0x1000000" size="0x800000" crc="f8e21968" sha1="e103d4f59cd841267b882580aee338e99f192c3f" />
			<rom loadflag="load16_word" name="bk3char.bin" offset="0x1800000" size="0x800000" crc="f8e21968" sha1="e103d4f59cd841267b882580aee338e99f192c3f" />
		</dataarea>
	</part>
</software>

NeoSD conversion script

SET ROMNAME=game
SET MAMEPATH="C:\mame"
SET MAMEROMPATH="C:\mame\roms\
SET PROJECTPATH="C:\NeoDev\src\samples\GAME"

cd %MAMEROMPATH%%ROMNAME%

romwak /f   dev_p1.bin  p1.p1 
romwak /p   p1.p1 p1.p1 1024 255

romwak /f   BANK0.bin B0.bin 
romwak /p   B0.bin B0.bin 1024 255

romwak /f   BANK1.bin B1.bin 
romwak /p   B1.bin B1.bin 1024 255


romwak /f   BANK2.bin B2.bin 
romwak /p   B2.bin B2.bin 1024 255

romwak /f   BANK3.bin B3.bin 
romwak /p   B3.bin B3.bin 1024 255

copy   /b   B0.bin + B1.bin + B2.bin + B3.bin p2.p2 

romwak /p bk0Char.bin bk0C.bin 8192 255
romwak /p bk1Char.bin bk1C.bin 8192 255
romwak /p bk2Char.bin bk2C.bin 8192 255
romwak /p bk3Char.bin bk3C.bin 8192 255

CharSplit bk0C.bin -rom a1
CharSplit bk1C.bin -rom b1
CharSplit bk2C.bin -rom d1
CharSplit bk3C.bin -rom e1

ren a1.c1 c1.c1
ren a1.c2 c2.c2

ren b1.c1 c3.c3
ren b1.c2 c4.c4

ren d1.c1 c5.c5
ren d1.c2 c6.c6

ren e1.c1 c7.c7
ren e1.c2 c8.c8

copy /y fix.bin s1.s1

move p1.p1 NeoSDTemp
move p2.p2 NeoSDTemp
move s1.s1 NeoSDTemp

copy m1.M1 NeoSDTemp

copy v1.V1 NeoSDTemp
copy v2.V2 NeoSDTemp
copy v3.V3 NeoSDTemp

move c1.c1 NeoSDTemp
move c2.c2 NeoSDTemp
move c3.c3 NeoSDTemp
move c4.c4 NeoSDTemp
move c5.c5 NeoSDTemp
move c6.c6 NeoSDTemp
move c7.c7 NeoSDTemp
move c8.c8 NeoSDTemp

del b0.bin
del b1.bin
del b2.bin
del b3.bin

del bk0C.bin
del bk1C.bin
del bk2C.bin
del bk3C.bin

CScript  zip.vbs  C:\mame\roms\game\NeoSDTemp  C:\mame\NeoSD\Exports\DEMO_%1.zip

del /q C:\mame\roms\game\NeoSDTemp\*.*

cd C:\mame\NeoSD

NeoBuilder -n DEMO_%1 -m DEMO -y 2021 -g Action Exports\DEMO_%1.zip

START C:\mame\NeoSD

cd %PROJECTPATH%

14

Le 20/05/2021 à 06:19

i'm glad that u made it works

i really hope that this will bring neogeo homebrews to another level , bring the excitement to devs and fun to the community!

now prepare yourself for world domination ^^

15

Le 07/06/2021 à 13:54

Hi

I am sure the bankswitching will be one of the best feature available for the future.

Sorry if that question was already answered before, but does it work on real hardware ? Is it supported by the common linkers ? (Neo SD, Darksoft Multi) And does it make the PCB manufacturing more complex ?

https://www.facebook.com/Chipsonsteroids/

16

Le 09/06/2021 à 22:23

works on NeoSD without problems! (except that the NeoBuilder.exe is a bit buggy)

17

Le 22/06/2021 à 17:42

This thread is a nice tutorial, thanks Ozzyyzzo and Mega Shocked for sharing the code

18

Le 16/02/2022 à 11:32

Thanks for this thread guys.

Can someone explain to me, though, why the NeoSD does things differently from how MAME loads NeoGeo Rom images?

Seems I am a bit lost on that topic at the moment..

19

Le 16/02/2022 à 15:51

The best way I can explain it is. MAME is an emulator and the .neo format is designed for the NeoSD with the intention of running the games on real hardware. In the case of real hardware the game files need to be in a specific format to match the various chips of the time where as MAME can load files with the game data on them that are not necessarily formatted for real hardware.

The script above is allowing me to convert my development files into a format that the Neo Geo can actually read. As per above this can get kinda sticky depending on how you need your files formatted. Neo Geo MVS/AES offered many board configurations based on how BIG your game data is. The good news is MAME lets us cheat and skip this conversion process. The bad news is you need to muddle with this conversion process when you have something worthy of real hardware.

20

Le 16/02/2022 à 16:45

Mega Shocked (./19):
The best way I can explain it is. MAME is an emulator and the .neo format is designed for the NeoSD with the intention of running the games on real hardware. In the case of real hardware the game files need to be in a specific format to match the various chips of the time where as MAME can load files with the game data on them that are not necessarily formatted for real hardware.

The script above is allowing me to convert my development files into a format that the Neo Geo can actually read. As per above this can get kinda sticky depending on how you need your files formatted. Neo Geo MVS/AES offered many board configurations based on how BIG your game data is. The good news is MAME lets us cheat and skip this conversion process. The bad news is you need to muddle with this conversion process when you have something worthy of real hardware.

Ah okay. That explains a lot.

Thanks, Mega Shocked!