11 September 2014, 21:46 | #21 |
J.M.D - Bedroom Musician
Join Date: Apr 2014
Location: los angeles,ca
Posts: 3,679
|
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 ] |
11 September 2014, 22:31 | #22 | |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
Quote:
[No problem: There's no hurry since these are still only thoughts about how a port could be one. ] Cheers Sascha |
|
12 September 2014, 02:57 | #23 | |
CaptainM68K-SPS France
|
Quote:
|
|
12 September 2014, 08:52 | #24 |
Posts: n/a
|
hi
I want to get more info about this topic because I am taking interest in it.
|
12 September 2014, 08:53 | #25 | |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
Quote:
Cheers Sascha |
|
13 September 2014, 06:18 | #26 |
CaptainM68K-SPS France
|
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. |
13 September 2014, 07:49 | #27 |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
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
|
13 September 2014, 21:10 | #28 |
Moderator
Join Date: Nov 2001
Location: Germany
Posts: 881
|
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. |
14 September 2014, 09:29 | #29 |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
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.
|
14 September 2014, 13:08 | #30 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 830
|
Sorry for stupid question, but how I can be sure that game logic itself runs properly wihout any graphice function ?
|
14 September 2014, 13:50 | #31 |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
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.
|
14 September 2014, 14:37 | #32 |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
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 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 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 |
15 September 2014, 13:02 | #33 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,391
|
Quote:
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 ? |
|
16 September 2014, 00:56 | #34 |
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
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 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 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 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 | 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 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. 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. |
16 September 2014, 09:33 | #35 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,391
|
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 |
17 September 2014, 02:06 | #36 |
Moon 1969 = amiga 1985
Join Date: Apr 2007
Location: belgium
Age: 48
Posts: 3,914
|
Thanks meynaf, i hope you will success...But it looks really tricky.
Akumajou Draculaon amiga aga !!!!! i want it ! |
17 September 2014, 10:02 | #37 | |
Registered User
Join Date: May 2001
Location: ?
Posts: 19,665
|
Quote:
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. |
|
18 September 2014, 10:07 | #38 |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,391
|
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... |
18 September 2014, 17:23 | #39 | |
BoingBagged
Join Date: Aug 2007
Location: The South of nowhere
Age: 46
Posts: 2,358
|
Quote:
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 |
|
18 September 2014, 18:28 | #40 | ||||||||||||||
Registered User
Join Date: Nov 2012
Location: Willich/Germany
Posts: 236
|
Quote:
Quote:
Backgrounds are always 512x512 pixels in size. The displayed area is a window of 256x256(?) pixels. The background wraps horizontally and vertically. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Please have a look at the documentation "X68000 DOS calls (LINEF)" and "IOCS calls (TRAP #15)". Quote:
Quote:
|
||||||||||||||
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 |
|
|