English Amiga Board


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

 
 
Thread Tools
Old 11 September 2014, 22:46   #21
saimon69
Bedroom musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 686
For the sound emulation, you said was matter of have instruction liker start and stop; you think could be mapped to in example a Mod player if someone want to convert the music in mod format?
[don't look at me for at least a while, since HOMM2 takes most of my free time :P ]
saimon69 is offline  
AdSense AdSense  
Old 11 September 2014, 23:31   #22
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Quote:
Originally Posted by saimon69 View Post
For the sound emulation, you said was matter of have instruction liker start and stop; you think could be mapped to in example a Mod player if someone want to convert the music in mod format?
[don't look at me for at least a while, since HOMM2 takes most of my free time :P ]
Correct. Most X68000 games use a "separate" memory resident music driver which is started before and invoked through TRAP calls from within the game. So basically these parts could simply be replaced with the appropriate MOD routines.

[No problem: There's no hurry since these are still only thoughts about how a port could be one. ]

Cheers
Sascha
AnimaInCorpore is online now  
Old 12 September 2014, 03:57   #23
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,159
Send a message via MSN to dlfrsilver
Quote:
Originally Posted by AnimaInCorpore View Post
Unfortunately I cannot link to the original discussion thread on the Atari-Forum where you can get more details about how the port was done. The AF webserver seems to have some serious problems and I hope that they'll sort it out soon.

However, the sources are disassembled and many important functions commented. The reassembled source runs natively on the X68000 again even with changes. So I was able to make a Pac-Mania trainer for the X68000.

The graphics emulation is done by putting "jsr" hooks in the source code where the sprites and background are being drawn on the Atari. The sound emulation was simply commented out.

The X68000 has indeed a decent sprite hardware but it is still limited by the fact that the memory mapped area of the sprite data is quite small. The games need to refresh that area to get all the sprites displayed so this results in either a DMA copy (Pac-Mania sprite animation) or caching (Galaga 88 compressed sprites) strategy.

What needs to be done for the Amiga port is to replace all the graphics functions and convert the graphics (sprites and backgrounds). This applies to the sound as well but that seems to be a far "simpler" task.

Cheers
Sascha
You mean convert the sprites as tiles to sprites frames right ?
dlfrsilver is offline  
Old 12 September 2014, 09:52   #24
kellygold
 
Posts: n/a
hi

I want to get more info about this topic because I am taking interest in it.
 
Old 12 September 2014, 09:53   #25
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Quote:
Originally Posted by dlfrsilver View Post
You mean convert the sprites as tiles to sprites frames right ?
Yes. But be aware that the sprites are composed of the data itself and the colour palette which can be changed dynamically. So this isn't as easy as it might seem. Fortunately both games do not use the sprite flipping feature.

Cheers
Sascha
AnimaInCorpore is online now  
Old 13 September 2014, 07:18   #26
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,159
Send a message via MSN to dlfrsilver
for instance you have only 16 colors for a sprites, note also that arcade boards use dynamic palette, which doesn't exist on computers. Most of the time, the coin-op games are in fact real 256 colors games, if you get all the sprites with the right colors.

Arcade boards are more of less PC-like architectures without keyboard and driven by a 68000 processor.
dlfrsilver is offline  
Old 13 September 2014, 08:49   #27
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
AF is up again so here's the link where you can find more details about the Atari port: http://www.atari-forum.com/viewtopic.php?f=68&t=24111
AnimaInCorpore is online now  
Old 13 September 2014, 22:10   #28
Wepl
Moderator
Wepl's Avatar
 
Join Date: Nov 2001
Location: Germany
Posts: 640
Hmm. Read the AF thread.
In AGA Amiga there is no 64k color mode. I have no idea how to display 2x 256 color screens + sprites + text as used in Galaga88.
Wepl is offline  
Old 14 September 2014, 10:29   #29
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Quote:
Originally Posted by Wepl View Post
Hmm. Read the AF thread.
In AGA Amiga there is no 64k color mode. I have no idea how to display 2x 256 color screens + sprites + text as used in Galaga88.
To make a port for the Amiga I would suggest to disable any graphic function and see if the game logic itself runs properly without them. Then add the appropriate functions step by step. This applies to the sound as well.
AnimaInCorpore is online now  
Old 14 September 2014, 14:08   #30
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
Quote:
Originally Posted by AnimaInCorpore View Post
To make a port for the Amiga I would suggest to disable any graphic function and see if the game logic itself runs properly without them. Then add the appropriate functions step by step. This applies to the sound as well.
Sorry for stupid question, but how I can be sure that game logic itself runs properly wihout any graphice function ?
Asman is offline  
Old 14 September 2014, 14:50   #31
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Quote:
Originally Posted by Asman View Post
Sorry for stupid question, but how I can be sure that game logic itself runs properly wihout any graphice function ?
Of course you need to have a visual "feedback" to see if the main loop is running (e.g. the attract mode). I've done this by emulating and displaying the first sprite on screen. A simple text layer emulation would do the trick also or display a hex value of a known memory address like a frame counter.
AnimaInCorpore is online now  
Old 14 September 2014, 15:37   #32
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Ok, here a short description why the source code is universal. It can be assembled and run on the X68000 and with only a few lines changed with additional TRAP and LINEF handlers the same source runs on a Atari ST as well (without any graphics emulation).

Addresses for interrupt vectors and X68000 memory mapped adresses are defined as follows (Pac-Mania):

Code:
	move.l  L_0000007C,OLD_7C_HANDLER.l
	move.l  #NULL_NMI_HANDLER,L_0000007C
	move.l  L_000000AC,OLD_AC_HANDLER.l
	move.l  #NULL_IRQ_HANDLER,L_000000AC
	move.l  L_000000B0,OLD_B0_HANDLER.l
	move.l  #NULL_IRQ_HANDLER,L_000000B0
	move.l  L_000000B4,OLD_B4_HANDLER.l
	move.l  #NULL_IRQ_HANDLER,L_000000B4
	move.l  L_000000B8,OLD_PROGRAM_ERROR_HANDLER.l
	move.l  #PROGRAM_ERROR_HANDLER,L_000000B8
The example above shows the interrupt vectors initialisation. The X68000 source has simply the label definitions like this: "L_0000007C = 0x0000007c" where the Atari source has the label pointing to a long word within the BSS area.

The VBL handling would look like this:
Code:
vbl:
	[Your code]

	move.l	L_00000118,-(sp)
	beq.s	_vbl_no_vdisp_handler

	rts

_vbl_no_vdisp_handler:
	addq.l	#4,sp

	rte
Here the handling of memory mapped registers: the X68000 target has the label defined as being described above where the Atari source defines a buffer within the BSS area:
Code:
	move.w  L_00E80000+0x2A.l,OLD_CRTC_PLANE_ACCESS_MODE_REGISTER.l
	move.w  #0x0,L_00E80000+0x2A.l
	move.w  L_00E82000+0x500.l,OLD_VIDEO_CONTROLLER_PRIORITY_REGISTER.l
	move.w  #0x12E4,L_00E82000+0x500.l
	move.w  L_00E82000+0x600.l,OLD_VIDEO_CONTROLLER_SPECIAL_PRIORITY_REGISTER.l
	move.w  #0x0,L_00E82000+0x600.l
	move.w  L_00EB0000+0x808.l,OLD_BG_CONTROL_REGISTER.l
	move.w  #0x212,L_00EB0000+0x808.l
Code:
L_00E80000:   | CRTC
	ds.b    0x2000
L_00E82000:   | VIDEO CONTROLLER
	ds.b    0x2000
L_00EB0000:   | SPRITE REGISTERS
	ds.b    0x8000
All you now need to do is to read the X68000 registers from the BSS area and emulate it.
AnimaInCorpore is online now  
Old 15 September 2014, 14:02   #33
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,431
Quote:
Originally Posted by AnimaInCorpore View Post
Ok, here a short description why the source code is universal. It can be assembled and run on the X68000 and with only a few lines changed with additional TRAP and LINEF handlers the same source runs on a Atari ST as well (without any graphics emulation).
If it can assemble and run on an Atari ST then maybe I can make it work as well on Amiga.
For a start remapping 64k colors to 256 on the fly may allow seeing something on screen, even if it becomes very slow.
If we can know which screen areas are updated and when, maybe it can even be done in real time.
Perhaps you could put a direct link to the sources here ?
meynaf is offline  
Old 16 September 2014, 01:56   #34
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Here are the sources for Galaga 88 and Pac-Mania. Both can be assembled with the Human68k toolchain to build executables which will work on the X68000 again.

The additional data files for Galaga 88 can be found in the release for the Atari Falcon (in fact no data has been modified in any way so the files from the original game disks will work as well).

Some notes about the changes to get Galaga 88 running virtually on the Amiga:

Remove the fixed address labels in the header and add the following BSS data. Please note that many memory mapped areas are not used and therefore they've been commented out ("|"). However, the VRAM is always 2 MiB in size due to the special graphics memory map layout so you'll need quite a lot of RAM even for a simple port without graphics emulation.

Code:
L_00C00000:   | VRAM
	ds.b    0x200000
L_00E00000:   | TEXT PLANE 1
	ds.b    0x20000
L_00E20000:   | TEXT PLANE 2
	ds.b    0x20000
L_00E40000:   | TEXT PLANE 3
	ds.b    0x20000
L_00E60000:   | TEXT PLANE 4
	ds.b    0x20000
L_00E80000:   | CRTC
	ds.b    0x2000
L_00E82000:   | VIDEO CONTROLLER
	ds.b    0x2000
|L_00E84000:   | DMAC
|	ds.b    0x2000
|L_00E86000:   | AREA
|	ds.b    0x2000
L_00E88000:   | MFP
	ds.b    0x2000
|L_00E8A000:   | RTC
|	ds.b    0x2000
|L_00E8C000:   | PRINTER
|	ds.b    0x2000
L_00E8E000:   | SYSTEM PORT
	ds.b    0x2000
|L_00E90000:   | FM
|	ds.b    0x2000
|L_00E92000:   | ADPCM
|	ds.b    0x2000
L_00E94000:   | FDC
	ds.b    0x2000
|L_00E96000:   | HDD
|	ds.b    0x21
|L_00E96021:   | SCSI (HDD)
|	ds.b    0x1FDF
|L_00E98000:   | SCC
|	ds.b    0x2000
L_00E9A000:   | I/O
	ds.b    0x4000
|L_00E9E000:   | FPU
|	ds.b    0x2000
|L_00EA0000:   | SCSI
|	ds.b    0xF900
|L_00EAF900:   | FAX
|	ds.b    0x100
|L_00EAFA00:   | MIDI 1
|	ds.b    0x10
|L_00EAFA10:   | MIDI 2
|	ds.b    0xF0
|L_00EAFB00:   | (ToDo)
|	ds.b    0x500
L_00EB0000:   | SPRITE REGISTERS
	ds.b    0x8000
L_00EB8000:   | SPRITE VRAM
	ds.b    0x8000
|L_00EC0000:   | USER I/O
|	ds.b    0x10000
L_00ED0000:   | SRAM
	ds.b    0x4000
|L_00ED4000:   | 'PRELIMINARY'
|	ds.b    0x1C000
|L_00EF0000:   | 'UNUSED'
|	ds.b    0x10000
|L_00F00000:   | CG ROM
|	ds.b    0xC0000
|L_00FC0000:   | 'PRELIMINARY'
|	ds.b    0x20000
|L_00FE0000:   | IPL ROM
|	ds.b    0x20000
Search for instructions accessing "0x18.l", "0xb8.l", 0x118.l" and "0x130.l". Remap them to BSS data labels as well. I noticed that I have not changed those addresses in the source linked above.

Now you should be able to compile the code. You probably need to cleanup the code a bit to meet your assembler syntax demands.

The next step is to add functions to simulate X68000 OS calls. To do so add a handler for TRAP #15 and LINEF like shown in the following code:

Code:
line_f:
	movem.l	d1-d2/a0-a2,-(sp)

	move.l	22(sp),a0
	move	(a0),d0
	addq.l	#2,22(sp)

	cmp		#0xff3d,d0
	bne		line_f_not_open

	move.l	26+LINE_F_OFFSET+0(sp),a0
	move	26+LINE_F_OFFSET+4(sp),d0

	move.w	d0,-(sp)
	pea		(a0)
	move.w	#61,-(sp)
	trap	#1
	addq.l	#8,sp

	bra		line_f_exit

line_f_not_open:
	cmp		#0xff3f,d0
	bne		line_f_not_read

	move	26+LINE_F_OFFSET+0(sp),d0
	move.l	26+LINE_F_OFFSET+2(sp),a0
	move.l	26+LINE_F_OFFSET+6(sp),d1
	and.l	#0x7fffffff,d1

	pea		(a0)
	move.l	d1,-(sp)
	move	d0,-(sp)
	move	#63,-(sp)
	trap	#1
	lea		12(sp),sp

	bra		line_f_exit

line_f_not_read:
	cmp		#0xff3e,d0
	bne		line_f_not_close

	move	26+LINE_F_OFFSET+0(sp),d0

	move.w	d0,-(sp)
	move.w	#62,-(sp)
	trap	#1
	addq.l	#4,sp

	bra		line_f_exit

line_f_not_close:

	clr.l	d0
line_f_exit:
	movem.l	(sp)+,d1-d2/a0-a2

	rte

trap_f:
	cmp		#17,d0
	bne		trap_f_not_contrast

	move	#15,d0

	rte

trap_f_not_contrast:
	cmp		#22,d0
	bne		trap_f_not_fntadr

	move.l	#draw_text_overlay+1024*512/8,d0 | Simply a valid dummy address (font address) where write accesses don't hurt much.

	rte

trap_f_not_fntadr:
	cmp		#0x21,d0
	bne		trap_f_not_b_print

	movem.l	d0-d2/a0-a2,-(sp)

	pea		(a1)
	move.w	#9,-(sp)
	trap	#1
	addq.l	#6,sp

	movem.l	(sp)+,d0-d2/a0-a2

	rte

trap_f_not_b_print:
	cmp		#0x60,d0
	bne		trap_f_not_adpcmout

	rte

trap_f_not_adpcmout:
	cmp		#0x6c,d0
	bne		trap_f_not_vdispst

	cmp.l	#0,a1
	bne		trap_f_vdispst_set

	move.l	a1,L_00000118
	clr.l	d0

	rte

trap_f_vdispst_set:
	clr.l	L_00000118
	clr.l	d0

	rte

trap_f_not_vdispst:
trap_f_exit:
	clr.l	d0

	rte
As you can see there's not much to do. Just fopen(), fread() and fclose() need to be simulated in the LINEF handler (here: mapped to Atari Trap #1 calls) also setting the X68000 VBL handler is the only important function in the TRAP #15 handler. I would suggest to replace the calls within the source directly with the appropriate Amiga DOS functions. However, please note the dummy return values of the remaining TRAP #15 and LINEF calls which the callee expect.

To disable the sound we need to comment out all TRAP #1 calls.

In the next step we will add timing functions. Setup a VBL routine and call the function at L_00000118 if the vector is not 0 (see TRAP #15 handler for the original VBL handler setup).

Alter the COUNT_VDISP_LOW_HIGH_STATE like shown in the following code snippet. This needs to be done because the function tests a VBL state flag which can be replaced by a simpler function.

Code:
COUNT_VDISP_LOW_HIGH_STATE:
wait_for_vbl:		| fixme
	addq.b	#3,70(a4)
	addq.b	#3,72(a4)
	tst	vbl_counter
	beq.s	wait_for_vbl
	clr	vbl_counter
	rts
Also add a VBL wait to the WAIT_FOR_VDISP_SET_AND_CLEAR_SPRITE_POSITIONS routine as well. Replace the first six lines of code:

Code:
WAIT_FOR_VDISP_SET_AND_CLEAR_SPRITE_POSITIONS:
	addq.b  #0x3,70(%A4)                            | 0x0002BB32 562C 0046                | S(0x00029C28)
	btst    #0x4,L_00E88000+0x1.l                   | 0x0002BB36 0839 0004 00E8 8001      | [MFP + 0x1]
	beq.s   WAIT_FOR_VDISP_SET_AND_CLEAR_SPRITE_POSITIONS                              | 0x0002BB3E 67F2                     |

L_0002BB40:
	addq.b  #0x3,72(%A4)                            | 0x0002BB40 562C 0048                |
	btst    #0x4,L_00E88000+0x1.l                   | 0x0002BB44 0839 0004 00E8 8001      | [MFP + 0x1]
	bne.s   L_0002BB40                              | 0x0002BB4C 66F2                     |
with:

Code:
WAIT_FOR_VDISP_SET_AND_CLEAR_SPRITE_POSITIONS:
wait_for_vbl:
	addq.b	#3,70(a4)
	addq.b	#3,72(a4)
	tst	vbl_counter
	beq.s	wait_for_vbl
	clr	vbl_counter
Finally before starting the main routine of Galaga 88 you need to initialise the virtual joystick data so that the attract mode will not be interrupted:

Code:
	move.b	#0xff,L_00E9A000+0x1.l	| Joystick 1 button and direction bits are inverted.
	move.b	#0xff,L_00E9A000+0x3.l	| Joystick 2 button and direction bits are inverted.
So now the game should run in a attract mode loop internally. As you can see there's not really changed much in the original source. At least the strategy works for Pac-Mania so far as well.

I'm not sure if I have missed something. Some time has passed since the port but I think that were the most important steps to have a good starting point.
AnimaInCorpore is online now  
Old 16 September 2014, 10:33   #35
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,431
Thanks.
I'll have a closer look at all that.
If it can work i may do something out of it, and if it can't i'll know why
meynaf is offline  
Old 17 September 2014, 03:06   #36
turrican3
Moon 1969 = amiga 1985

turrican3's Avatar
 
Join Date: Apr 2007
Location: belgium
Age: 41
Posts: 3,149
Thanks meynaf, i hope you will success...But it looks really tricky.
Akumajou Draculaon amiga aga !!!!! i want it !
turrican3 is offline  
Old 17 September 2014, 11:02   #37
Akira
Registered User

Akira's Avatar
 
Join Date: May 2001
Location: New York
Posts: 18,196
Quote:
Originally Posted by AnimaInCorpore View Post
To make a port for the Amiga I would suggest to disable any graphic function and see if the game logic itself runs properly without them. Then add the appropriate functions step by step. This applies to the sound as well.

Here's the key to a decent port.
What makes a game is the game logic. If you get that right you can work the rest up. You can make the graphics work the way the Amiga needs them to work, you will reduce colors and have the graphics in the format the Amiga needs and you will create a soundtrack that will easily work with the Amiga.

I for one think this would work just great. Galaga'88 is awesome and would be very much welcomed to the Amiga and a proper Pacmania port would be perfect too.
Akira is offline  
Old 18 September 2014, 11:07   #38
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 44
Posts: 2,431
First thing to say, Pac-mania is the one i wish to concentrate on, because it's smaller.


But for making some useful port, I need to plug in :

1. Screen buffer. No idea at all here : resolution is unknown, frame address also is, so i can't even show a background. Only thing i could do is the vbl handler.

2. File i/o. Very easy here (no need for a trap handler, load code is simple). Done. But this means i need the data files as well...

3. Input (joystick and maybe also keyboard) - missing infos could be rebuilt from that nice keyboard_joystick_translation_table. At least the game author seemed smart enough to have a central test routine. These things help a lot ! Partially done : that read_keyboard routine contains trap #15 i don't know a thing about.

4. Sound. That one can be postponed, ok But if some PCM samples are output, then why not doing it now ? There is some play sample routine, btw. If you can tell me what the trap #15 here are doing, it would be of a great help.

5. Memory management. As everything seems to be in bss, no problem here ?

That asm syntax is a pain to work with. I could somehow cope, but i'm not sure my numerous search-replace didn't break something. It would be safer for me to have a .TOS for the ST (ST .TOS, not Falcon .TOS, even if it contains Falcon code), as a reference (if not as a new starting point). The best for me would be the X68000 version but in .TOS format, where everything internal to the program is relocated. My own disassembler would then warn me about all direct (non-reloc) memory accesses, suspicious code, and so on, and that's of a great help to me.


About the code you posted, what is A4 in that COUNT_VDISP thing ? Counting the busy wait loops is totally unsafe (depends on cpu speed). Besides, we have WaitTOF() to do a vblank wait - and i just hate busy waits.
Replacing that by my good old waitvbl routine is peanuts, but these $70(a4) and $72(a4) variables are in the way.

I have zero knowledge about the X68000 and the sources don't give a clue on what the os calls and hardware accesses do.

The line_f looks a lot like ST's trap #1. But FF23, FF0F, FF0C lead to function numbers that do not exist there. What are they supposed to do ?

Your "vdispst" code seems wrong to me. If A1=0, move A1 to $118. If not, clear $118. The test on A1 is useless ; $118 always ends up cleared (and if the test were reversed, a simple move A1 to $118 would be enough).

Many trap #15 are "unknown" (-> no-op in the handler) : fct #4, #14, #16, #35, (etc). But they have to do something, right ?


Just looking at the start of the code (pac-mania) there are mysteries for me.
A line F call $FF23.
A trap #15 with D0=4.
Some copyright text supposed to be displayed, but the data only remotely looks like text (japanese text maybe ?). Sending that directly to some console output doesn't look like a very smart idea.


There is also some old remnant of protection code. And that trap #10 turned into trap #15 by altering the code has very few chances to properly work on '060 (i doubt it even does on '030).
This, of course, won't tell me what that trap #15 was supposed to be doing...
meynaf is offline  
Old 18 September 2014, 18:23   #39
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 39
Posts: 1,496
Quote:
Originally Posted by meynaf View Post
This, of course, won't tell me what that trap #15 was supposed to be doing...
Okay, here you have a reference for X68000 traps. Explanations are in japanese, but can be translated with google (with not so much language correctness):

http://datacrystal.romhacking.net/wiki/X68k:TRAP

Speaking about trap #15, it is an IOCS (X68000 bios) call.

Poor translation follows:

Argument d0.b IOCS call number

. Running to run the IOCS, and IOCS code in one word from the IOCS work $ a0e
(High byte always 0) by Le number is saved.
Arguments and return value other than d0.b differ by call number.

To speed up the IOCS call, call shortcuts in such a way that the following
To perform. However, it must be in supervisor state.

movea.l (IOCS call number * 4 + $ 400), a0
jsr (a0)

To create as a subroutine to return in rts Each function of IOCS.
no problem even if destroyed a0.l but when viewed from the (user, when you shortcut
Not guaranteed to be saved), do not destroy For the registers that do not pass the return value of the other
Thing.

How to respond to the vector base register vbr

It is possible to enable the vbr In (ROM IOCS version 1.3) X68030.
On it was confirmed that it is a standard vector that points to the ROM, the vector of the following, it
It may be changed to a value obtained by subtracting 2 from the set address of each. However, some
It is not possible to correspond to those calling the routine directly ROM within IOCS call.

(IOCS processing address table is also changed to vbr + $ 400) trap # 15
IOCS _FNTGET
IOCS _OPMINTST
IOCS _TIMERDST
IOCS _VDISPST
IOCS _CRTCRAS
IOCS _HSYNCST
IOCS _PRNINTST
IOCS _B_INTVCS
gulliver is offline  
Old 18 September 2014, 19:28   #40
AnimaInCorpore
Registered User
 
Join Date: Nov 2012
Location: Willich/Germany
Posts: 149
Quote:
Originally Posted by meynaf View Post
First thing to say, Pac-mania is the one i wish to concentrate on, because it's smaller.
Ok no problem so let's turn to Pac-Mania. The remarks from me in the last post about the VBL/TRAP/LINEF handling belongs to the Galaga 88 port.

Quote:
Originally Posted by meynaf View Post
1. Screen buffer. No idea at all here : resolution is unknown, frame address also is, so i can't even show a background. Only thing i could do is the vbl handler.
At first here you can find the documents I was using for the ports. However, I don't remember where the background memory map was documented. AFAIR the 256 colour background pixels are comprised of a 16 bit word of which only the lower byte is being used for the palette index. So that's the reason why you can find so many "movep" instructions within the source. That's also the reason why at least 1 MiB of memory is being reserved for that mode. 2 MiB is the "worst case" when using 16 colour backgrounds even only the lowest nibble is being used for the palette index.
Backgrounds are always 512x512 pixels in size. The displayed area is a window of 256x256(?) pixels. The background wraps horizontally and vertically.
Quote:
Originally Posted by meynaf View Post
2. File i/o. Very easy here (no need for a trap handler, load code is simple). Done. But this means i need the data files as well...
You can find all the data files in this archive. There's also a TOS file included.

Quote:
Originally Posted by meynaf View Post
3. Input (joystick and maybe also keyboard) - missing infos could be rebuilt from that nice keyboard_joystick_translation_table. At least the game author seemed smart enough to have a central test routine. These things help a lot ! Partially done : that read_keyboard routine contains trap #15 i don't know a thing about.
I think you're referring to the "_BITSNS" call!? Damn, I need to find a better documentation link. I remember having a better description for this function as it gets the key code from the keyboard matrix. I commented it with "F5" but I cannot find it in the docs I have linked above.
Quote:
Originally Posted by meynaf View Post
4. Sound. That one can be postponed, ok But if some PCM samples are output, then why not doing it now ? There is some play sample routine, btw. If you can tell me what the trap #15 here are doing, it would be of a great help.
Did you mead "_ADPCMOUT"? Actually that samples are being played in the (incomplete) port. I am converting all 4 bit ADPCM samples before and play them when this TRAP #15 is being called.

Quote:
Originally Posted by meynaf View Post
5. Memory management. As everything seems to be in bss, no problem here ?
Probably some of the memory mapped areas can be reduced in size. Maybe reducing VRAM to 1 MiB is possible (but be careful).

Quote:
Originally Posted by meynaf View Post
That asm syntax is a pain to work with. I could somehow cope, but i'm not sure my numerous search-replace didn't break something. It would be safer for me to have a .TOS for the ST (ST .TOS, not Falcon .TOS, even if it contains Falcon code), as a reference (if not as a new starting point). The best for me would be the X68000 version but in .TOS format, where everything internal to the program is relocated. My own disassembler would then warn me about all direct (non-reloc) memory accesses, suspicious code, and so on, and that's of a great help to me.
As noted above in the archive is a TOS version of the port but I think that's too much work compared to renaming the syntax. What exact syntax do you need? Uppercase instructions? Registernames without "%"? I can change them for you.

Quote:
Originally Posted by meynaf View Post
About the code you posted, what is A4 in that COUNT_VDISP thing ? Counting the busy wait loops is totally unsafe (depends on cpu speed). Besides, we have WaitTOF() to do a vblank wait - and i just hate busy waits.
Replacing that by my good old waitvbl routine is peanuts, but these $70(a4) and $72(a4) variables are in the way.
Forget that VBL routine as that it was only a illustration and related to Galaga 88.

Quote:
Originally Posted by meynaf View Post
I have zero knowledge about the X68000 and the sources don't give a clue on what the os calls and hardware accesses do.
I'll try to find better docs but it is really a pain to read Japanese documents (a Google translate Firefox plugin was my friend though).

Quote:
Originally Posted by meynaf View Post
The line_f looks a lot like ST's trap #1. But FF23, FF0F, FF0C lead to function numbers that do not exist there. What are they supposed to do ?
IIRC all LINEF calls other than fopen(), etc. are completely obsolete.

Quote:
Originally Posted by meynaf View Post
Your "vdispst" code seems wrong to me. If A1=0, move A1 to $118. If not, clear $118. The test on A1 is useless ; $118 always ends up cleared (and if the test were reversed, a simple move A1 to $118 would be enough).
Please ignore that as well...

Quote:
Originally Posted by meynaf View Post
Many trap #15 are "unknown" (-> no-op in the handler) : fct #4, #14, #16, #35, (etc). But they have to do something, right ?
Except for "_ADPCMOUT" any other calls are also obsolete.
Please have a look at the documentation "X68000 DOS calls (LINEF)" and "IOCS calls (TRAP #15)".

Quote:
Originally Posted by meynaf View Post
Just looking at the start of the code (pac-mania) there are mysteries for me.
A line F call $FF23.
A trap #15 with D0=4.
Some copyright text supposed to be displayed, but the data only remotely looks like text (japanese text maybe ?). Sending that directly to some console output doesn't look like a very smart idea.
You comment out that calls. $ff23 in the start code is "_CONCTRL" doing "turn cursor display mode off"... well, not that important I suppose.

Quote:
Originally Posted by meynaf View Post
There is also some old remnant of protection code. And that trap #10 turned into trap #15 by altering the code has very few chances to properly work on '060 (i doubt it even does on '030).
This, of course, won't tell me what that trap #15 was supposed to be doing...
Yes, that routine code modifying routine as well as the trap can be removed.
AnimaInCorpore is online now  
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 20:44.


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