IPB

Welcome Guest ( Log In | Register )

2 Pages V   1 2 >  
Reply to this topicStart new topic
> Burning Eproms
rush6432
post 14 Apr 2012, 16:11
Post #1





Group: Members
Posts: 38
Joined: 26-4 09
Member No.: 222



Hey guys, ive been having a bit of trouble getting my binary programs burned to a cartridge.
Ive got a programmer that will burn the chips with whatever i want and verify ok after burning but all i get is a black screen afterwards (this is on a stub jag)

Here is the breakdown of how the binary is prepped before burning..


I take a binary file that links and compiles at 4000 (ram) and has no header. i use a wrapper program i wrote that compiles and includes this binary file and immediately copys the file to ram an then jumps to the execution point. This wrapper program starts at 802000 and has no header either.

I then use the following on a windows machine to put the 8k universal header on the file.
copy univ.k3y/b + program.bin/b ENCRYPTED.ROM/b

I have verified with a hex editor that the 8k univseral header is added at this point.

I am able to load this file into project tempest emulator and virtual jaguar and run it without issues. It also runs perfectly fine like this on the skunkboard.

I then use romsplit.exe (supplied atari tool) to split the rom using the following command

romsplit -w encrypted.rom which gives me a .HI and .LO file.

Now from everything ive seen the hi file goes on the top eprom spot on the cartridge and low in the other.

When i burn each chip the program and chip offset are both 000000. I just get a black screen after following this.


Any suggestions? do i need to byteswap the .hi and .lo files? am i missing a step here?
Go to the top of the page
 
+Quote Post
Matthias
post 14 Apr 2012, 21:30
Post #2


Great giana sister
*

Group: Members
Posts: 51
Joined: 18-6 06
Member No.: 63



Hello!

QUOTE (rush6432 @ 14 Apr 2012, 16:11) *
Hey guys, ive been having a bit of trouble getting my binary programs burned to a cartridge.
Ive got a programmer that will burn the chips with whatever i want and verify ok after burning
but all i get is a black screen afterwards (this is on a stub jag)


A stable black screen is a bit unusual, it could just indicate, that your program does a wrong video-initialization.
(But i have no experience with a STUBulated Jaguar)

To check if the whole process of creating the Eprom-content is correct i suggest that you use a ROM-dump of an commercial game and treat it as you did with your own game-program.

QUOTE
Here is the breakdown of how the binary is prepped before burning..


I take a binary file that links and compiles at 4000 (ram) and has no header. i use a wrapper program i wrote that compiles and includes this binary file and immediately copys the file to ram an then jumps to the execution point. This wrapper program starts at 802000 and has no header either.

I then use the following on a windows machine to put the 8k universal header on the file.
copy univ.k3y/b + program.bin/b ENCRYPTED.ROM/b

I have verified with a hex editor that the 8k univseral header is added at this point.

I am able to load this file into project tempest emulator and virtual jaguar and run it without issues. It also runs perfectly fine like this on the skunkboard.


Sounds ok for me, but what is the databus-width setting of the "univ.k3"-file?

QUOTE
I then use romsplit.exe (supplied atari tool) to split the rom using the following command

romsplit -w encrypted.rom which gives me a .HI and .LO file.

Now from everything ive seen the hi file goes on the top eprom spot on the cartridge and low in the other.


Even if you mix them up you can check this out easily by swapping the 2 EPROMs.


QUOTE
When i burn each chip the program and chip offset are both 000000. I just get a black screen after following this.

Any suggestions? do i need to byteswap the .hi and .lo files? am i missing a step here?


As said above, your process-hanlding sounds ok for me.

Kind regards
Matthias


--------------------
Go to the top of the page
 
+Quote Post
Matthias
post 15 Apr 2012, 12:00
Post #3


Great giana sister
*

Group: Members
Posts: 51
Joined: 18-6 06
Member No.: 63



QUOTE (rush6432 @ 14 Apr 2012, 16:11) *
...but all i get is a black screen afterwards (this is on a stub jag)

...
..
.
I then use the following on a windows machine to put the 8k universal header on the file.
copy univ.k3y/b + program.bin/b ENCRYPTED.ROM/b


Is the bit for showing the spinning cube set in that universal header?
If so: Does the screen go black immediatelly after booting the Jaguar or does the cube show up and the screen wents black after it?

Bye!
Matthias


--------------------
Go to the top of the page
 
+Quote Post
rush6432
post 15 Apr 2012, 18:07
Post #4





Group: Members
Posts: 38
Joined: 26-4 09
Member No.: 222



QUOTE (Matthias @ 15 Apr 2012, 06:00) *
QUOTE (rush6432 @ 14 Apr 2012, 16:11) *
...but all i get is a black screen afterwards (this is on a stub jag)

...
..
.
I then use the following on a windows machine to put the 8k universal header on the file.
copy univ.k3y/b + program.bin/b ENCRYPTED.ROM/b


Is the bit for showing the spinning cube set in that universal header?
If so: Does the screen go black immediatelly after booting the Jaguar or does the cube show up and the screen wents black after it?

Bye!
Matthias


I am unsure if the bit is set for the spinning cube in the header. Im not quite sure how to check this other than a hex editor and even them im not sure what id be looking for really.

The spinning jaguar cube does come up but thats due to it being a stub jag i think.

I really probably need a normal jaguar to test this stuff out on.

Ill try a copy of a 2mb game here and see what i come up with using the same process i listed above.


Edit: i was able to burn iron solder. all i did was split the rom file with the romsplit program and burned each portion to a chip.

It did show the jaguar logo here but then went to a red screen for 2 seconds and then started the game. my only guess is that it didnt pass encryption and the stub jag bios let it pass anyway. It didnt help that one of my chips on that burn didnt pass the verify stage but still worked.
Go to the top of the page
 
+Quote Post
rush6432
post 15 Apr 2012, 20:35
Post #5





Group: Members
Posts: 38
Joined: 26-4 09
Member No.: 222



QUOTE (rush6432 @ 15 Apr 2012, 12:07) *
QUOTE (Matthias @ 15 Apr 2012, 06:00) *
QUOTE (rush6432 @ 14 Apr 2012, 16:11) *
...but all i get is a black screen afterwards (this is on a stub jag)

...
..
.
I then use the following on a windows machine to put the 8k universal header on the file.
copy univ.k3y/b + program.bin/b ENCRYPTED.ROM/b


Is the bit for showing the spinning cube set in that universal header?
If so: Does the screen go black immediatelly after booting the Jaguar or does the cube show up and the screen wents black after it?

Bye!
Matthias


I am unsure if the bit is set for the spinning cube in the header. Im not quite sure how to check this other than a hex editor and even them im not sure what id be looking for really.

The spinning jaguar cube does come up but thats due to it being a stub jag i think.

I really probably need a normal jaguar to test this stuff out on.

Ill try a copy of a 2mb game here and see what i come up with using the same process i listed above.


Edit: i was able to burn iron solder. all i did was split the rom file with the romsplit program and burned each portion to a chip.

It did show the jaguar logo here but then went to a red screen for 2 seconds and then started the game. my only guess is that it didnt pass encryption and the stub jag bios let it pass anyway. It didnt help that one of my chips on that burn didnt pass the verify stage but still worked.


Another update, ran the binary file through the Jiffi program to make a rom file and then used a windows hex editor to strip out the padding. testing the rom file after stripping out the padding and worked just fine. then used romsplit and split the rom and burned on to respectiv chips, still a black screen.. unsure what the deal is here. i am not using the official atari video startup (udg one) so this may play a role im guessing?

Even though, why would it work on the skunkboard and alpine board and then throw issues when burned to a cartridge?
Go to the top of the page
 
+Quote Post
Zerosquare
post 16 Apr 2012, 23:24
Post #6


Rick dangerous
***

Group: Administrators
Posts: 2.105
Joined: 4-1 06
Member No.: 30



The fact that a normal game runs fine is pretty strange... if the endianness or the bus width had been wrong, it wouldn't run... (note for Matthias : the universal header is set for 32-bit bus width).

There's the possibility that your program doesn't initialize a register that happens to be set correctly when running on a Skunkboard, but not on a Stubulator BIOS. Try checking that you're initializing the video registers properly, especially VI.


--------------------
« Mon PC on dirait un Amiga tellement c'est instable » – GT Turbo
« Soit A un niveau d'absurdité, il existe un post N tel que... » – Azrael et al., 2006
Go to the top of the page
 
+Quote Post
rush6432
post 17 Apr 2012, 03:29
Post #7





Group: Members
Posts: 38
Joined: 26-4 09
Member No.: 222



QUOTE (Zerosquare @ 16 Apr 2012, 17:24) *
The fact that a normal game runs fine is pretty strange... if the endianness or the bus width had been wrong, it wouldn't run... (note for Matthias : the universal header is set for 32-bit bus width).

There's the possibility that your program doesn't initialize a register that happens to be set correctly when running on a Skunkboard, but not on a Stubulator BIOS. Try checking that you're initializing the video registers properly, especially VI.



I was setting the VI register early on in the code but.. ive eliminated my startup code all together now and just used the atari startup.s file instead to get the system up and running. seems to work fine so far when testing.

As for the eeproms

Can anyone shed some light on which method would be better suited for encrypting/splitting the roms??

Should i just use the jagcrypt.exe program which splits and encrypts or just use the manual copy of the univ.k3y file onto the binary and then use the atari romsplit.exe file?? does it really matter??

Is there a preferred method here to use?
Go to the top of the page
 
+Quote Post
rush6432
post 17 Apr 2012, 04:18
Post #8





Group: Members
Posts: 38
Joined: 26-4 09
Member No.: 222



Just burned eproms again here, this time i used the atari video startup sequence/system init file supplied with the SDK. Didnt work (suprise rolleyes.gif ) this was however just in the program that is transfered to ram by the wrapper program.

I used my wrapper program to encapsulate the binary file into a file that loads from cart and directly to ram. However i literally have the wrapper just doing the copy right away and nothing else. im guessing this could be my problem??? im assuming i should throw atleast something to the effect of this....

move.l #$70007,G_END
move.w #$FFFF,VI ; disable video interrupts

move.l #STOPOBJ,d0 ; stop the obj processor.
swap d0
move.l d0,OLP

in the wrapper program? should disable video and set obj processor to a stop object so the system wont crash... that would be my best guess as to why its doing nothing afterwards...... could be crashing before it even starts the copy of the program to ram??

Or i could possibly use the startup.s (atari sys startup file) AS the wrapper program to setup the system and then throw in some copy code to load the binary to ram and jump to the ram location.... the binary file would just not have the sys init stuff and would perform the normal functions of what its designed to do.

Anyone see any issues with either method?
Go to the top of the page
 
+Quote Post
rush6432
post 17 Apr 2012, 23:15
Post #9





Group: Members
Posts: 38
Joined: 26-4 09
Member No.: 222



QUOTE (rush6432 @ 16 Apr 2012, 21:18) *
Just burned eproms again here, this time i used the atari video startup sequence/system init file supplied with the SDK. Didnt work (suprise rolleyes.gif ) this was however just in the program that is transfered to ram by the wrapper program.

I used my wrapper program to encapsulate the binary file into a file that loads from cart and directly to ram. However i literally have the wrapper just doing the copy right away and nothing else. im guessing this could be my problem??? im assuming i should throw atleast something to the effect of this....

move.l #$70007,G_END
move.w #$FFFF,VI ; disable video interrupts

move.l #STOPOBJ,d0 ; stop the obj processor.
swap d0
move.l d0,OLP

in the wrapper program? should disable video and set obj processor to a stop object so the system wont crash... that would be my best guess as to why its doing nothing afterwards...... could be crashing before it even starts the copy of the program to ram??

Or i could possibly use the startup.s (atari sys startup file) AS the wrapper program to setup the system and then throw in some copy code to load the binary to ram and jump to the ram location.... the binary file would just not have the sys init stuff and would perform the normal functions of what its designed to do.

Anyone see any issues with either method?



Well.... i feel like a fool.....

the above theory was correct....

I jumped directly to copying the binary instead of disabling the VI and stoping the obj processor which caused it to crash and lock the system and never really either complete the copy of the binary file to ram or even start copying....

All fixed though, the above code when added with a basic copy loop for the binary file works like a charm!
Go to the top of the page
 
+Quote Post
sh3-rg
post 18 Apr 2012, 00:41
Post #10


Super sprint
**

Group: Members
Posts: 348
Joined: 3-6 09
From: bolton, england
Member No.: 227



QUOTE (rush6432 @ 17 Apr 2012, 22:15) *
All fixed


yes.gif


--------------------
Would you Push The Button?
"Do not trust people who offer incense" - zerosquare offering some important advice via google translate
Go to the top of the page
 
+Quote Post
rush6432
post 22 May 2012, 14:48
Post #11





Group: Members
Posts: 38
Joined: 26-4 09
Member No.: 222




Quest continues....

Boots, but intermittently.....

im not quite sure what the issue is here. On a stub jag it boots literally every time...The loader program sets the disables the VI and sets the OLP to a stop object. tried to set it with the gpu (like atari does) and even with the 68k. no dice

not quite 100 percent sure what im missing here but my best guess would be a transition from the list with a stop object in the loader program to a fully populated list when the program in ram takes over.

Anyone care to shed some light onto this with their own experiences in "loader" programs loading ram based games? Am i missing something obvious? if so please point a fellow hobbyist in the right direction smile.gif
Go to the top of the page
 
+Quote Post
Matmook
post 22 May 2012, 15:56
Post #12


Super sprint
**

Group: Members
Posts: 651
Joined: 18-3 08
From: Angers (à côté)
Member No.: 194



Yop ! Hum, quick idea... Is the stop object of your loader program in RAM ?


--------------------
Matmook
Go to the top of the page
 
+Quote Post
rush6432
post 22 May 2012, 16:23
Post #13





Group: Members
Posts: 38
Joined: 26-4 09
Member No.: 222



QUOTE (Matmook @ 22 May 2012, 09:56) *
Yop ! Hum, quick idea... Is the stop object of your loader program in RAM ?


it isnt actually.... its defined within the cart loader program...

i can however relocate this..

Do you think it may hve to do with the transition from a stop obj to a real list by chance? waiting until an interrupt completes now prior to loading in the list is how ive got it setup at the moment, but this is within the program thats loaded to ram. one the loader program dumps the binary file to ram it that program in ram takes over and finishes setting up a few system settings.

Another thing i thought might be holding it back is the possibility of writing the stop obj with the 68k or the gpu... ive heard the 68k will do it in two writes where as the gpu can do it in a single write and be done. Any real issues with using the 68k to set the OLP to a stop specifically? Ive seen quite a few other programs do this as well which makes me think its not a huge deal but others swear the gpu is the only way to set the OLP to a stop upon system startup (ie atari startup routine)


Ill see if i can post a snip of code of how i have it setup at the moment when i get home.
Go to the top of the page
 
+Quote Post
Matmook
post 22 May 2012, 16:32
Post #14


Super sprint
**

Group: Members
Posts: 651
Joined: 18-3 08
From: Angers (à côté)
Member No.: 194



CITATION(rush6432 @ 22 May 2012, 17:23) *
CITATION(Matmook @ 22 May 2012, 09:56) *
Yop ! Hum, quick idea... Is the stop object of your loader program in RAM ?


it isnt actually.... its defined within the cart loader program...

i can however relocate this..

Do you think it may hve to do with the transition from a stop obj to a real list by chance? waiting until an interrupt completes now prior to loading in the list is how ive got it setup at the moment, but this is within the program thats loaded to ram. one the loader program dumps the binary file to ram it that program in ram takes over and finishes setting up a few system settings.

Ill see if i can post a snip of code of how i have it setup at the moment when i get home.

It's just an idea but :
a) jag start in ROM
cool.gif loader is launched (your stop(0) object is in ROM)
c) loading is finished
d) you jump in ram (the OP is still "stoping" in ROM)
e) your game/code do some init with the sound and the video (but will probably change the bus mode too...)

just an idea...


--------------------
Matmook
Go to the top of the page
 
+Quote Post
Matthias
post 23 May 2012, 16:38
Post #15


Great giana sister
*

Group: Members
Posts: 51
Joined: 18-6 06
Member No.: 63



Hello!

QUOTE (rush6432 @ 22 May 2012, 17:23) *
QUOTE (Matmook @ 22 May 2012, 09:56) *
Yop ! Hum, quick idea... Is the stop object of your loader program in RAM ?


it isnt actually.... its defined within the cart loader program...


Although the OLP-register is a full 32bit-Register, the Link-adresses contained in the objects are only 19+3 bits wide, therefore all of these linked objects need to be placed within the lower 4MB of the Jaguars address space. This might indicate that this restriction is true for the very first object as well, which would mean that the object-list always needs to be placed in RAM.


About the method to set a new object-list address into OLP:
Using the 68000 for this is no problem as long as the writes of the two 16bit-words isn't interrupted, but using a RISC processor is more safe.

Here is some code i got from Bastian Schick that initializes (and shuts down) everything, you can see that the STOP-object is placed at a free memory loacation (address $0):

CODE
INIT:             move    #$2700,sr
                  lea     $1000.w,sp
                  lea     $F00000,a0
                  move.l  #$070007,d0          ; big endian
                  move.l  d0,$210C(a0)
                  move.l  d0,$F1A10C
                  moveq #0,d0
                  move.l d0,$2114(a0)          ; stop gpu
                  move.l d0,$f1a114            ; stop dsp
                  move.l d0,$2100(a0)          ; disable GPU-IRQs
                                               ; disable DSP-IRQs
    bra     goon2
                  move.l #%10001111100000000,$f1a100
                  move.l #%111111<<8,$f10020   ; clear and disable IRQs
goon2:
                  move.l  d0,0.w
                  moveq   #4,d0
                  move.l  d0,4.w
                  moveq   #0,d0
                  move.l  d0,$20(a0)           ; set OP to STOP-OBJECT
                  move.w  d0,$26(a0)           ; clear OP-Flag
                  move.l  d0,$2A(a0)           ; border black
                  move.w  d0,$56(a0)           ; set CRY mode to color/not BW
                  move.w  d0,$58(a0)           ; background black
                  move.l  d0,$50(a0)           ; stop PIT
                  move.l  d0,$f10000           ; stop JPIT1
                  move.l  d0,$f10004           ; stop JPIT2
                  move.l  #$1F00<<16,$E0(a0)   ; clear pending irqs
                  move.w  #$7fff,$4e(a0)       ; no VI
                  lea     dummy_irq(pc),a0
                  move.l  a0,$0100.w
                  bra.s   INIT1
dummy_irq:        move.l #$1f00<<16,$f000e0
                  rte
INIT1:            moveq #0,d0
                  moveq #0,d1
                  moveq #0,d2
                  moveq #0,d3
                  moveq #0,d4
                  moveq #0,d5
                  moveq #0,d6
                  moveq #0,d7
                  move.l d0,a0
                  move.l d0,a1
                  move.l d0,a2
                  move.l d0,a3
                  move.l d0,a4
                  move.l d0,a5
                  move.l d0,a6
                  move.l a0,usp


After this, you are free to start up the Jaguar again wink.gif


Kind regards
Matthias


--------------------
Go to the top of the page
 
+Quote Post
rush6432
post 24 May 2012, 16:11
Post #16





Group: Members
Posts: 38
Joined: 26-4 09
Member No.: 222



Matthias and Matmook, thanks for the replies.

I have tried the supplied code you suggested with it "shutting down" the jaguar esentially and setting the OP to a stop object at location $0

This seems to work very well and my loader loop loads my binary to ram which and executes. Seems my program startup is a little screwy because ive tried the same thing using just the atari startup.s file as its own binary to just display the licensed to or by logo and this loads perfectly fine, however when swapping the binary loaded to ram it seems my program is not initializing something right.... Sound plays but garbled scaled graphics appear.

Atleast im in the right direction now though smile.gif Thanks to all.
Go to the top of the page
 
+Quote Post
Zerosquare
post 24 May 2012, 21:18
Post #17


Rick dangerous
***

Group: Administrators
Posts: 2.105
Joined: 4-1 06
Member No.: 30



Maybe there's something I don't understand, but why do you need to setup the OP with an empty list, etc. ? On startup, the ROM (either the original one or the BJL one) will do this for you. Copying the ROM program to RAM and jumping to it will work fine ; no need to bother with extra initializations smile.gif


--------------------
« Mon PC on dirait un Amiga tellement c'est instable » – GT Turbo
« Soit A un niveau d'absurdité, il existe un post N tel que... » – Azrael et al., 2006
Go to the top of the page
 
+Quote Post
SCPCD
post 25 May 2012, 08:38
Post #18


Rick dangerous
***

Group: Level2
Posts: 1.131
Joined: 13-5 05
From: Nord
Member No.: 5



Because we don't know where the OP list is so we can accidentaly erased it when copying ROM to DRAM ?


--------------------
Nyan ! :p
Go to the top of the page
 
+Quote Post
rush6432
post 25 May 2012, 14:13
Post #19





Group: Members
Posts: 38
Joined: 26-4 09
Member No.: 222



QUOTE (SCPCD @ 25 May 2012, 02:38) *
Because we don't know where the OP list is so we can accidentaly erased it when copying ROM to DRAM ?



Very good point ^^^

I personally did not know that the system upon boot up set itself to a stop object already.... I was under the impression you had to set the hw and put it on a stop obj to keep the system happy or else when the VI/Interrupts are enabled the olp would have nothing to process and crash/lock the system....

If i were to copy my binary file after bootup its a possibility that the stock rom is putting the stop obj in the middle of ram and im just overwriting it when copying to ram then which would explain my problems ive been having...
Go to the top of the page
 
+Quote Post
ggn
post 25 May 2012, 18:26
Post #20


"Can I hear you say YEAH?"
*

Group: Members
Posts: 168
Joined: 11-8 08
Member No.: 207



Hello, just popping in with a small warning:

QUOTE (Matthias @ 23 May 2012, 18:38) *
CODE
                  move.l a0,usp


If you assemble using smac, this will get wrongly assembled as

CODE
                  move.l a0,sp


which means your stack will point at $0, and your program might crash if you're not setting the stack afterwards! I found this the hard way a couple of years back smile.gif.
Go to the top of the page
 
+Quote Post

2 Pages V   1 2 >
Fast ReplyReply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



Lo-Fi Version Time is now: 17-9-2014 / 04:29