Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store
IGNORED

Ghostbusters - Development Diary

TheMole

By TheMole
in TI-99/4A Development

 Share

Recommended Posts

retrodroid Moonsweeper

retrodroid

Posted
Posted
9 hours ago, TheMole said:

Hmmm, the ghost-beam collission detection routine is not the sort of code that you would think could lead to a crash: 

// If we're about to hit one of the beams, bounce the ghost off of the beam
// in the opposite direction
if (ghost.y > 16)	// Make sure spook is not higher than streams
{
	if (abs((ghost.x + ghost.hdir) - beam1_x) < (BEAM_BOUNCE + 1))
	{
		if ((ghost.x + ghost.hdir) > beam1_x)
			ghost.x += BEAM_BOUNCE;
		else
			ghost.x -= BEAM_BOUNCE;
	}
	else if (abs((ghost.x + ghost.hdir) - beam2_x) < (BEAM_BOUNCE + 1))
	{
		if ((ghost.x + ghost.hdir) > beam2_x)
			ghost.x += BEAM_BOUNCE;
		else
			ghost.x -= BEAM_BOUNCE;
	}
	else
	{
		ghost.x += ghost.hdir;
		ghost.y += ghost.vdir;
	}
}

 

It's a hell of a coincidence though. I'm not sure what to think of this...

I'll be flying back to Europe around christmas, where I can test on real hardware myself. I have an F18A console and two NTSC consoles I can try on. I'll also try reproducing it in any emulator I can get my hands on here.

 

 

Hey!  That't not assembly language!  

Link to comment
Share on other sites
TheMole Stargunner

TheMole

Posted
  • Author
Posted
5 hours ago, Asmusr said:

What I mean is that on the 9918A it's not alternating - you either see just the outline or just the interior. Could be something with my TV, I guess, if it's only showing half of the frames.

Oh, wow, that's weird. And you only have this issue on the map screen, not during the driving sections?

Link to comment
Share on other sites
Serafini Lapo Chopper Commander

Serafini Lapo

Posted
Posted
3 hours ago, TheMole said:

Quindi, riassumendo semplicemente l'elenco delle questioni aperte rimanenti (soprattutto per me):

  • @Serafini Lapocon la schermata del titolo che non veniva visualizzata correttamente.
  • @Asmusrcrash durante le sezioni di cattura dei fantasmi.

Qualcos'altro che sto dimenticando?

 

Exactly. However, I still have to try holding the button down during the title screen to "bypass" the control on the F-18 which is NOT present on my setup.

Link to comment
Share on other sites
Serafini Lapo Chopper Commander

Serafini Lapo

Posted
Posted
On 6/12/2023 at 04:51, TheMole said:

 

Grazie per le gentili parole! È un bug strano, quello schermo non fa nulla che gli altri schermi non facciano... puoi parlarmi un po' del tuo hardware? È una console non modificata o ha un F18A (immagino sia un F18A, perché alcune delle combinazioni di colori che penso di poter vedere non possono essere riprodotte su un vero 9918a)? Stai usando un FinalGrom o hai bruciato una cartuccia? Sembra che la modalità schermo non sia stata impostata correttamente, ma il testo in basso indica che almeno alcuni dati nella VRAM sono corretti.

 

Forse c'è una cosa che puoi provare per me, ovvero tenere premuto il pulsante di fuoco durante l'avvio del gioco (finché non vedi il logo della talpa), che dovrebbe bypassare il meccanismo di rilevamento F18A.

 

Qualcun altro l'ha provato su hardware reale con o senza F18A?

 

I tried just now, I hold down the fire button until the title "the mole" appears, but the initial screen appears with audio and video noise... (the title song is unrecognizable and the video appears as in the photo.) After that, everything is perfect.

I remember that I do NOT own F-18.

  • Thanks 1
Link to comment
Share on other sites
TheMole Stargunner

TheMole

Posted
  • Author
Posted
1 hour ago, Serafini Lapo said:

I tried just now, I hold down the fire button until the title "the mole" appears, but the initial screen appears with audio and video noise... (the title song is unrecognizable and the video appears as in the photo.) After that, everything is perfect.

I remember that I do NOT own F-18.

 

Thanks for confirming and testing!

 

I think you might have an issue with banking above 256kb. Most of the game data sits below this limit, but the title screen data sits right on that threshold and goes about 7kb over it. Further down in the binary, there's only the final boss battle and the graphic data for the station wagon (which hardly anyone ever chooses, I think :) ), so all of the other stuff would work indeed, even if you have an issue with banks ove 256kb.

 

So, I think it could be one of the following:

  • Somehow your download got corrupted, and the last banks in the binary are messed up. -> Can you try redowloading and copying to your SD card again?
  • Your FinalGrom99 has an issue with cartridges that are larger than 256kb.

To exclude an issue with the FinalGrom99, does any know of any other games to go beyond 256kb that @Serafini Lapo could try?

You can also try selecting the Station Wagon as your vehicle (the third one, blue color) and see if you have corrupted segments in other parts of the game? If that shows more corruption, that would confirm that there's an issue with the higher banks.

 

  • Like 3
  • Thanks 1
Link to comment
Share on other sites
JasonACT Dragonstomper

JasonACT

Posted
Posted
On 12/5/2023 at 3:34 AM, TheMole said:

For those that are interested, I've uploaded the source code to github: https://github.com/themole-ti/ghostbusters

Probably doesn't build out of the box on Windows, since my build system uses a few shell scripts, but it should be easy enough to get up and running if you have WSL installed.

Maybe because I'm on Windows, but I'm getting compile errors with include files (TISNPlay.h / TISfxPlay.h / sound.h) missing?

Link to comment
Share on other sites
JasonACT Dragonstomper

JasonACT

Posted
Posted (edited)
1 hour ago, Tursi said:

Those are libti99 files - do you have your library path set up?

No, I don't, but I did check that I didn't have the first 2 of those files anywhere on my system.  I do see sound.h in the version of libti99 I have, but not the other two files.  I assumed, given @TheMole has copied the VDP routines he's using from libti99 into his own include files, that sound.h would be his own too.

Edited by JasonACT
Link to comment
Share on other sites
TheMole Stargunner

TheMole

Posted
  • Author
Posted

TISNPlay.h and TISfxPlay.h are part of Tursi's libtivgm2 package: https://github.com/tursilion/vgmcomp2/tree/main/Players/libtivgm2

 

I did indeed include a copy of vdp.c/vdp.h in the main tree, since I sometimes customize those routines directly for my own use, not sure if they are still identical to the ones Tursi maintains or not. But I don't modify the sound files, so those can be taken straight from libti99 and libtivgm2.

 

Once you have gotten the files from Tursi's github pages, just make sure the include path at the top of the Makefile points to the right directories.

 

I will amend the build instructions to call out the dependcies more clearly.

 

  • Thanks 1
Link to comment
Share on other sites
JasonACT Dragonstomper

JasonACT

Posted
Posted

@TheMole

Ok, thanks, that got me a fair bit further.  My next problem was with create_resourcedefs.sh - and after a bit of tinkering, adding some echos, I could see what you were doing.  But the toolchain I've built for Windows is 32 bit (so should work on all versions of Windows) and I needed to amend your "cut -b" statements, by subtracting 8 from the byte positions (res.map in my version are 32 bit "Origin" values, where I can see yours are 64 bit, so the strings are positioned 8 bytes earlier in mine on each line).

 

Then, with the newest 1.27 TMS9900-GCC I seem to get some overruns when linking (so all compiles are now working, which is good)...

  

\t[LD] ghostbusters.bin
C:\MinGW\msys\1.0\home\NoMyth\install\bin\tms9900-ld.exe: section .text [00006026 -> 000064b1] overlaps section .persistent [00006026 -> 00007313]
C:\MinGW\msys\1.0\home\NoMyth\install\bin\tms9900-ld.exe: section .header3 [0000c000 -> 0000c025] overlaps section .bank2 [0000a026 -> 0000c15d]
C:\MinGW\msys\1.0\home\NoMyth\install\bin\tms9900-ld.exe: section .header4 [0000e000 -> 0000e025] overlaps section .bank3 [0000c026 -> 0000e1c7]
C:\MinGW\msys\1.0\home\NoMyth\install\bin\tms9900-ld.exe: section .data [00012000 -> 000127b7] overlaps section .bank5 [00010026 -> 00012203]
make: *** [all] Error 1

 

I thought to rebuild it with the 1.19 old GCC, but it seems to still have some (but less) overruns...

  

\t[LD] ghostbusters.bin
C:\MinGW\msys\1.0\home\NoMyth\install\bin\tms9900-ld.exe: section .text [00006026 -> 000064b1] overlaps section .persistent [00006026 -> 000072e9]
C:\MinGW\msys\1.0\home\NoMyth\install\bin\tms9900-ld.exe: section .header4 [0000e000 -> 0000e025] overlaps section .bank3 [0000c026 -> 0000e09b]
make: *** [all] Error 1

 

So, I guess I will need to wait to see if you pick up the new 1.27 compiler and shift things around?  Unless there's something else happening here that I'm not seeing?

 

(And I did need to compile up a version of "rev" for the script to run, which my Windows system didn't have already, but that was easy.)

Link to comment
Share on other sites
TheMole Stargunner

TheMole

Posted
  • Author
Posted (edited)
1 hour ago, JasonACT said:

 

So, I guess I will need to wait to see if you pick up the new 1.27 compiler and shift things around?  Unless there's something else happening here that I'm not seeing?

 

Greate to see that you managed to get that far, and thanks for trying to compile with the new compiler (it doesn't seem to build correctly on my mac, and I'm holding off on debugging the build process until there's a stable version to work from).

 

Yes, ROM usage is really tight in this game. If a build succeeds, you get a ROM usage summary like this:
  

memory usage summary
----------------------------------
 5938 bytes in persistent		\
   40 bytes in scratchpad		|-> this lives in bank0
 2174 bytes in bank0			/
 7432 bytes in bank1
 7832 bytes in bank2
 8144 bytes in bank3
 7228 bytes in bank4
 8094 bytes in bank5
 2142 bytes in data
20622 bytes in bss

 

As you can see, a few of the banks are close to the limit, and since the code generated by 1.27 is slightly bigger, I would expect some banks to overflow. But yes, once I have the new compiler up and running, I will spend some time shuffling things around to make sure the game can be built with the newest versions of the compiler without issues.

 

Apparently, I'm still on patch 1.12, so I guess I can't confirm wether it should build with v1.19 or not...

Edited by TheMole
  • Like 2
  • Thanks 1
Link to comment
Share on other sites
JasonACT Dragonstomper

JasonACT

Posted
Posted
8 minutes ago, TheMole said:

Apparently, I'm still on patch 1.12, so I guess I can't confirm wether it should build with v1.19 or not...

:)  I'll see tomorrow if I can find that patch and build it properly, it's a bit late here tonight to try now.

 

FYI - I did try for quite a few hours today to see if the game freezes with ghosts clashing with the beams, but on my TMS9918A machine it "just works" - no matter how many times I tried.  I couldn't see any reason why it would freeze in the code either, so it might be a F18A issue???  I don't have one to try though.

  • Like 1
Link to comment
Share on other sites
TheMole Stargunner

TheMole

Posted
  • Author
Posted
12 minutes ago, JasonACT said:

:)  I'll see tomorrow if I can find that patch and build it properly, it's a bit late here tonight to try now.

 

FYI - I did try for quite a few hours today to see if the game freezes with ghosts clashing with the beams, but on my TMS9918A machine it "just works" - no matter how many times I tried.  I couldn't see any reason why it would freeze in the code either, so it might be a F18A issue???  I don't have one to try though.

 

It might be, I have an F18A console in Europe that I plan to test on when I'm there, IF my FinalGrom99 arrives on time :)

But even with an F18A, I see absolutely no reason why it would freeze at that point in the code... it's puzzling. I mean, as far as interaction with the VDP is concerned, it's just uploading sprite tables there...

 

Thanks for playtesting though, really helpful!

  • Like 2
Link to comment
Share on other sites
JasonACT Dragonstomper

JasonACT

Posted
Posted
11 hours ago, TheMole said:

Apparently, I'm still on patch 1.12, so I guess I can't confirm wether it should build with v1.19 or not...

I guess you are, but it might still be a different patch to the 1.12 on the first page of the GCC thread.  When I use that one, I get an internal compiler error on 5 different lines of code where you are doing a multiply by constants.  decode_account has 4 lines (* 1000, * 100, * 10 and * 1) which fail, check_progression has 1 line (* 1000) which fails.  I commented them out, except the progression check where I did a shift left 10 bits (* 1024) and it all compiled.

 

I still got one overlap when linking, which always looked different to the others:

Quote 
section .text [00006026 -> 000064b1] overlaps section .persistent [00006026 -> 00007313]

which I tracked down to the Windows tms9900 linker ignoring your directive to put the "persistent/*.a" code where you wanted it, so it created a separate .text section which clashed.  For each "persistent/*.a" line I saw in your link file, I duplicated it and made it say "persistent\\*.a" - so this build script should work on both Windows and Linux now.  BTW: A single backslash didn't work for some reason.

 

With that the build finished without an error and the .bin file ran successfully.

  • Like 2
Link to comment
Share on other sites
JasonACT Dragonstomper

JasonACT

Posted
Posted

I tried patch 1.13 and the multiply statements compiled correctly, but more overlaps occurred in that version.

 

https://forums.atariage.com/topic/164295-gcc-for-the-ti/?do=findComment&comment=3637585

 

Quote

Fixed multiply to prevent using MPY with an immediate operand

Quote

The multiply fix corrects a problem originally seen by TheMole this spring (Yikes! So long ago!), and was pretty straightforward.

Which was referencing this post:

https://forums.atariage.com/topic/164295-gcc-for-the-ti/?do=findComment&comment=3442886

 

Quote

However, this new version is not able to compile Alex Kidd, I get the following error: 

unrecognizable insn:
(insn 140 138 141 7 persistent/collision.c:175 (set (reg:SI 165)
        (mult:SI (reg/v:HI 118 [ map_y ])
            (const_int 170 [0xaa]))) -1 (nil))
persistent/collision.c: In function ‘collide_world’:
persistent/collision.c:498: internal compiler error: in extract_insn, at recog.c:2048
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [persistent/collision.o] Error 1
dannys-mbp:Alex Kidd Cartridge lousbergd$

I haven't been able to chase down what is causing the problem in the code, the line that where the error occurs (line 175) seems innocent enough. Line 498 is simply the last line of code in the file.

I'm thinking @TheMole you may have taken the multiply fix from 1.13 and backported it to your 1.12 :)

Link to comment
Share on other sites
TheMole Stargunner

TheMole

Posted
  • Author
Posted
2 minutes ago, JasonACT said:

I tried patch 1.13 and the multiply statements compiled correctly, but more overlaps occurred in that version.

 

https://forums.atariage.com/topic/164295-gcc-for-the-ti/?do=findComment&comment=3637585

 

Which was referencing this post:

https://forums.atariage.com/topic/164295-gcc-for-the-ti/?do=findComment&comment=3442886

 

I'm thinking @TheMole you may have taken the multiply fix from 1.13 and backported it to your 1.12 :)

 

Oh, wow, you're right!

It's been so long, but now that you mention it, I do remember isolating the MPY fix and creating a v1.12a for myself to get things to work!

 

And thanks a lot for getting the build system going on Windows. I clearly need to think about how to make it more cross platform and more robust going forward. I like the fact that I'm not relying on external binary programs for anything, but too much can go wrong with shell scripts once you move platforms.

 

I'll also take a look at optimizing ROM usage some more. I noticed that if I flag certain functions that are only called from within a given translation unit as `static`, the binary tends to get quite a bit smaller. I just don't understand why that is though, so I need to dig a little bit deeper to make sure I know what I'm doing :). Maybe it uses a more optimized function prolog and epilog if it knows a function can't be called from outside of the translation unit?

  • Like 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
 Share
Go to topic listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...