[AnimaInCorpore]

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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).

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.

Originally Posted by meynaf

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).

Originally Posted by meynaf

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.

Originally Posted by meynaf

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...

Originally Posted by meynaf

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)".

Originally Posted by meynaf

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.

Originally Posted by meynaf

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.