English Amiga Board


Go Back   English Amiga Board > Other Projects > project.CARE

 
 
Thread Tools
Old 19 September 2014, 13:31   #41
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Another hint for the DMA usage in Pac-Mania: writing to the address $E84087 initiates a DMA transfer to copy or fill memory blocks. The last instruction of "DMA_BLOCK_COPY" and "DMA_BLOCK_ERASE" are doing this so you need an own copy/fill subroutine to be invoked at that point. Also search for "L_00E84000+0x87.l" within the code and put your subroutine at the right place as well. I am also checking if the target memory lies between $EB8000 and $EB8000+0x6000 because that is the sprite data memory. In fact, the DMA is used for the animation of the characters.

Here's a short example how it works:
Code:
x68k_dma:
	move	#0x2700,sr

	movem.l	d0-d7/a0-a6,-(sp)

	lea		L_00E84000+0x80,a0
	cmp.l	#L_00EB8000,20(a0)
	jlt		1f
	cmp.l	#L_00EB8000+0x6000,20(a0)
	jge		1f
	move	10(a0),d0
	move.l	12(a0),a0
	lsr		#7-1,d0
	jbsr	convert_sprites

1:
	lea		L_00E84000+0x80,a0
	move.l	12(a0),a1
	move.l	20(a0),a2
	move	10(a0),d0

	move	d0,d1
	lsr		#5,d0
	and		#0x1f,d1
	move	#32,d2
	sub		d1,d2
	add		d2,d2

	cmp.b	#0x5,6(a0)
	jne		x68k_dma_not_copy

	jmp		x68k_dma_copy_loop(pc,d2.w)
x68k_dma_copy_loop:
.rept 32
	move	(a1)+,(a2)+
.endr
	dbf		d0,x68k_dma_copy_loop

	jra		x68k_dma_exit

x68k_dma_not_copy:
	move	(a1),d1

	jmp		x68k_dma_fill_loop(pc,d2.w)
x68k_dma_fill_loop:
.rept 32
	move	d1,(a2)+
.endr
	dbf		d0,x68k_dma_fill_loop

x68k_dma_exit:
	movem.l	(sp)+,d0-d7/a0-a6

	move	#0x2300,sr

	rts
AnimaInCorpore is offline  
AdSense AdSense  
Old 22 September 2014, 09:16   #42
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,426
Well after thinking about it, i've changed my mind about the way to make these ports. It appears we're not using the right methods here.

We have two Atari game ports. We need two Amiga game ports.
But, wait. If we had a common platform interface, rewriting that code would be all that's needed to make one.

So the idea is to replace every X68000 (or Atari, depending where you start from) specific thing by some call to an external, well-documented function which you invent yourself. The fact the function is just a place holder does not matter as long as it behaves correctly (and we can leave the most difficult ones for later).
If the same functions are used for every port (they clearly are for my ST ports, even my Mac HOMM2 port works with that very same set), then it's just a matter of implementing them. These functions have to be high level enough, like load a file at some place, wait next vbl, update screen region, etc, but certainly not "emulate X68k register xyz". They need to be put in an include file so nothing specific remains in the main source. This way, whether the port is made on Atari or Amiga would simply not matter : only the special functions would differ !
And cherry on the cake, having that for the x68k itself would make a great reference...

About the asm syntax, try assembling on Atari with Devpac and you will see what needs to be changed (we need to use a common syntax of course).
You could also try VAsm on the PC (perhaps it's able to make an x68k exe, if not i can request it).

Are you ready to work this way ?
meynaf is offline  
Old 22 September 2014, 11:27   #43
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Quote:
Originally Posted by meynaf View Post
But, wait. If we had a common platform interface, rewriting that code would be all that's needed to make one.
I agree.

Quote:
Originally Posted by meynaf View Post
So the idea is to replace every X68000 (or Atari, depending where you start from) specific thing by some call to an external, well-documented function which you invent yourself. The fact the function is just a place holder does not matter as long as it behaves correctly (and we can leave the most difficult ones for later).
If the same functions are used for every port (they clearly are for my ST ports, even my Mac HOMM2 port works with that very same set), then it's just a matter of implementing them. These functions have to be high level enough, like load a file at some place, wait next vbl, update screen region, etc, but certainly not "emulate X68k register xyz". They need to be put in an include file so nothing specific remains in the main source. This way, whether the port is made on Atari or Amiga would simply not matter : only the special functions would differ !
And cherry on the cake, having that for the x68k itself would make a great reference...
I agree as well.

I would suggest to use a platform like GitHub or Bitbucket to keep the sources and the use of "define" for the platform specific parts. You can choose what you like. I already have a Bitbucket account but I can also register at GitHub. What do you think?

Quote:
Originally Posted by meynaf View Post
About the asm syntax, try assembling on Atari with Devpac and you will see what needs to be changed (we need to use a common syntax of course).
Definitely.

Quote:
Originally Posted by meynaf View Post
You could also try VAsm on the PC (perhaps it's able to make an x68k exe, if not i can request it).
Ok, it seems that vasm is the way to go.

Quote:
Originally Posted by meynaf View Post
Are you ready to work this way ?
Yep. So my first step is to prepare the source for vasm to have a working X68000 binary again. I'll check if the human68k toolchain is able to work with the vasm output.
AnimaInCorpore is offline  
Old 25 September 2014, 11:03   #44
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,426
Quote:
Originally Posted by AnimaInCorpore View Post
I would suggest to use a platform like GitHub or Bitbucket to keep the sources and the use of "define" for the platform specific parts. You can choose what you like. I already have a Bitbucket account but I can also register at GitHub. What do you think?
This kind of site has a problem : i can't go there with IBrowse, at least not when it's https. Why would we need to host the sources on a commercial site anyway ?


Quote:
Originally Posted by AnimaInCorpore View Post
Yep. So my first step is to prepare the source for vasm to have a working X68000 binary again. I'll check if the human68k toolchain is able to work with the vasm output.
Ok. Let's see what will come out of that first step.
meynaf is offline  
Old 26 September 2014, 17:46   #45
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,004
Quote:
Originally Posted by meynaf View Post
You could also try VAsm on the PC (perhaps it's able to make an x68k exe, if not i can request it).
Is the Human68k executable file format documented somewhere?
phx is offline  
Old 26 September 2014, 19:45   #46
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Quote:
Originally Posted by meynaf View Post
This kind of site has a problem : i can't go there with IBrowse, at least not when it's https. Why would we need to host the sources on a commercial site anyway ?
I would like to keep the sources in a GIT repository or an appropriate alternative. It doesn't have to be one of those sites.

Quote:
Originally Posted by meynaf View Post
Ok. Let's see what will come out of that first step.
So far the ELF output format does kind of work but the result crashes on the X68000 probably caused by some nasty jump address calculations or wrong labels. I need to check that later on.
AnimaInCorpore is offline  
Old 05 October 2014, 14:18   #47
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Found some time to have a look at the problem. So the ELF format is fine. Checked the (now vasm compatible) disassembler output of another X68000 game in combination with the human68k toolchain and the reassembled result now works on the X68000.
AnimaInCorpore is offline  
Old 27 September 2015, 04:14   #48
Retro1234
5150

Retro1234's Avatar
 
Join Date: Jun 2006
Location: Sycophantazia
Posts: 3,745
holy @!#.? [ Show youtube player ]
Retro1234 is offline  
Old 27 September 2015, 12:56   #49
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Who dares to do a port of Cho Ren Sha 68k for the Amiga 1200? The sources are available in a vasm compatible syntax.
AnimaInCorpore is offline  
Old 28 September 2015, 03:04   #50
Akira
Registered User

Akira's Avatar
 
Join Date: May 2001
Location: New York
Posts: 18,192
I love ChoRenSha 68k, would love an AMiga version!
Akira is offline  
Old 28 September 2015, 20:36   #51
Locutus
Registered User

 
Join Date: Jul 2014
Location: Finland
Posts: 757
Cho Ren Sha made my brain melt after a while
Locutus is offline  
Old 28 September 2015, 20:41   #52
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,004
Quote:
Originally Posted by AnimaInCorpore View Post
Who dares to do a port of Cho Ren Sha 68k for the Amiga 1200?
Certainly not. The port looks awesome! Is it running on a 68060-Falcon? How much of the game was rewritten and adapted to use the Falcon's coprocessors? Or is it all rendered with the CPU?

Quote:
The sources are available in a vasm compatible syntax.
Where are they?
phx is offline  
Old 28 September 2015, 22:19   #53
frank_b
Registered User
 
Join Date: Jun 2008
Location: Boston USA
Posts: 329
Quote:
Originally Posted by phx View Post
Certainly not. The port looks awesome! Is it running on a 68060-Falcon? How much of the game was rewritten and adapted to use the Falcon's coprocessors? Or is it all rendered with the CPU?

Where are they?
That's an *unaccelerated* Falcon I believe. IE DSP, blitter + 16 mhz CPU.
frank_b is offline  
Old 29 September 2015, 07:34   #54
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Quote:
Originally Posted by phx View Post
Certainly not. The port looks awesome! Is it running on a 68060-Falcon? How much of the game was rewritten and adapted to use the Falcon's coprocessors? Or is it all rendered with the CPU?
Thanks. The [ Show youtube player ] linked above shows an alpha version running on a stock 16 MHz Atari Falcon with 14 MB RAM.

The original game source contains only a few modifications (21 conditional "ifd __ATARI__" parts) to invoke the appropriate sprite/graphics routines. In fact, the same game source can be assembled for the X68000 as well to check if it's still 100% identical to the original. The system related routine calls (DOS and IOCS) are being emulated by redirection since those are Traps and Line-F calls. So the Atari version could be called a 50% emulation.

Except for the DSP which supports the CPU for sprite drawing there's no special use of the other Atari Falcon custom chips. But even that shouldn't be a problem since the graphics interface is quite clean due to the aforementioned simple game source modifications. I.e. the Amiga specific routine calls could be put at the very same places.

Quote:
Originally Posted by phx View Post
Where are they?
They're not public but available on request. If someone is interested to have a look at them please send me a pm.

Quote:
That's an *unaccelerated* Falcon I believe. IE DSP, blitter + 16 mhz CPU.
Except for the Blitter you're right.
AnimaInCorpore is offline  
Old 29 September 2015, 12:15   #55
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,426
Quote:
Originally Posted by AnimaInCorpore View Post
I.e. the Amiga specific routine calls could be put at the very same places.
Not so easy if the game asks for a 65536 color (16-bit) frame buffer...
It does use such a mode, doesn't it ?
meynaf is offline  
Old 29 September 2015, 16:55   #56
Retro1234
5150

Retro1234's Avatar
 
Join Date: Jun 2006
Location: Sycophantazia
Posts: 3,745
What screen modes does the x68000 have? You need graphics converted to 256? thers a few artists about here on eab.
Can I get a copy of one of them maybe pacman compiled just some text output? - Im sad like that.

Have you had any running on others in Atari ST family Like the ST/Mega/TT/ etc?

I think Atari just smashed Amiga
Retro1234 is offline  
Old 29 September 2015, 17:15   #57
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,426
Quote:
Originally Posted by Boo Boo View Post
You need graphics converted to 256? thers a few artists about here on eab.
'Tis more about graphical routines than the graphics themselves. For converting to 256, the code must be changed. And that's the big part.
meynaf is offline  
Old 29 September 2015, 17:20   #58
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Quote:
Originally Posted by meynaf View Post
Not so easy if the game asks for a 65536 color (16-bit) frame buffer...
It does use such a mode, doesn't it ?
Actually the game just says what sprite (ID) should be displayed at the position x, y and also if it is flipped. You may prepare your sprites for the optimal display while loading the data. Nothing more and nothing less. So it's completely up to you how to display the sprites. The background and text display is also not bound to any special graphic modes as well.
AnimaInCorpore is offline  
Old 29 September 2015, 17:31   #59
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,426
Quote:
Originally Posted by AnimaInCorpore View Post
Actually the game just says what sprite (ID) should be displayed at the position x, y and also if it is flipped. You may prepare your sprites for the optimal display while loading the data. Nothing more and nothing less. So it's completely up to you how to display the sprites. The background and text display is also not bound to any special graphic modes as well.
So even the file i/o routines are supposed to know that they load ?
I mean, it's not just general i/o to load data regardless of what it is ?
meynaf is offline  
Old 29 September 2015, 17:45   #60
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Quote:
Originally Posted by meynaf View Post
So even the file i/o routines are supposed to know that they load ?
I mean, it's not just general i/o to load data regardless of what it is ?
There are routines for loading the samples and the sprites which also track the sprite/sample IDs and storage addresses. Because the game has been written originally in C all of them are using the standard fopen(), fread(), fseek() and fclose() functions. So you can easily add/inject your own conversion routines.

However, you should be aware that up to 512 sprites (16 x 16 pixels) are being displayed on the screen simultaneously.
AnimaInCorpore is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
porting vlc ? turrican3 request.Apps 4 25 June 2011 22:27
X68000 games with debug infos. hitchhikr project.CARE 9 28 January 2011 12:10
x68000 games download sites redblade Retrogaming General Discussion 27 09 November 2010 21:58
Help porting Mindscape's Legend Queller request.Other 6 30 October 2010 13:07
X68000 stainy Retrogaming General Discussion 5 07 October 2005 10:58

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 05:39.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.33191 seconds with 12 queries