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