19 September 2014, 12:31 | #41 |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
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 |
22 September 2014, 08:16 | #42 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,379
|
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 ? |
22 September 2014, 10:27 | #43 | ||||
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
Quote:
Quote:
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:
Quote:
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. |
||||
25 September 2014, 10:03 | #44 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,379
|
Quote:
Ok. Let's see what will come out of that first step. |
|
26 September 2014, 16:46 | #45 |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,570
|
|
26 September 2014, 18:45 | #46 | |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
Quote:
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. |
|
05 October 2014, 13:18 | #47 |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
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.
|
27 September 2015, 03:14 | #48 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,887
|
holy @!#.?
[ Show youtube player ]
|
27 September 2015, 11:56 | #49 |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
Who dares to do a port of Cho Ren Sha 68k for the Amiga 1200? The sources are available in a vasm compatible syntax.
|
28 September 2015, 02:04 | #50 |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,665
|
I love ChoRenSha 68k, would love an AMiga version!
|
28 September 2015, 19:36 | #51 |
Registered User
Join Date: Jul 2014
Location: Finland
Posts: 1,198
|
Cho Ren Sha made my brain melt after a while
|
28 September 2015, 19:41 | #52 | ||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,570
|
Quote:
Quote:
|
||
28 September 2015, 21:19 | #53 |
Registered User
Join Date: Jun 2008
Location: Boston USA
Posts: 466
|
That's an *unaccelerated* Falcon I believe. IE DSP, blitter + 16 mhz CPU.
|
29 September 2015, 06:34 | #54 | ||
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
Quote:
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. They're not public but available on request. If someone is interested to have a look at them please send me a pm. Quote:
|
||
29 September 2015, 11:15 | #55 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,379
|
|
29 September 2015, 15:55 | #56 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,887
|
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 |
29 September 2015, 16:15 | #57 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,379
|
|
29 September 2015, 16:20 | #58 |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
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.
|
29 September 2015, 16:31 | #59 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,379
|
Quote:
I mean, it's not just general i/o to load data regardless of what it is ? |
|
29 September 2015, 16:45 | #60 | |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
Quote:
However, you should be aware that up to 512 sprites (16 x 16 pixels) are being displayed on the screen simultaneously. |
|
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 21:27 |
X68000 games with debug infos. | hitchhikr | project.CARE | 9 | 28 January 2011 11:10 |
x68000 games download sites | redblade | Retrogaming General Discussion | 27 | 09 November 2010 20:58 |
Help porting Mindscape's Legend | Queller | request.Other | 6 | 30 October 2010 12:07 |
X68000 | stainy | Retrogaming General Discussion | 5 | 07 October 2005 09:58 |
|
|