T-zer0 CD32 TF328

[wairnair]

Tried the HDF+CD version with FS-UAE, config similar to a TF328, 020, 8MB fast ram. Unfortunately, it crashed like on the real CD32, during the first mission I got a black screen with some garbage on the bottom then it rebooted. Switched over to an 030 in FS-UAE and I also made it to stage 2 just fine.
So it looks like an 030 is indeed required for this game and it rules out the CD32 unless you're lucky enough to own an SX32.. Too bad as the game doesn't make any use of the extra performance a 030 provides.

Otherwise thanks for the HDF+CD combo, it's perfect for say, an expanded A1200 or emulators.

[DamienD]

Originally Posted by wairnair

Tried the HDF+CD version with FS-UAE, config similar to a TF328, 020, 8MB fast ram. Unfortunately, it crashed like on the real CD32, during the first mission I got a black screen with some garbage on the bottom then it rebooted. Switched over to an 030 in FS-UAE and I also made it to stage 2 just fine.
So it looks like an 030 is indeed required for this game and it rules out the CD32 unless you're lucky enough to own an SX32.. Too bad as the game doesn't make any use of the extra performance a 030 provides.

Yup, guess a 68030 is required

Originally Posted by wairnair

Otherwise thanks for the HDF+CD combo, it's perfect for say, an expanded A1200 or emulators.

No problem, this one took a while to get everything running perfectly

[earok]

Well, anyway, I thought I'd have a crack at this myself. My attempt (ISO for CD32 with FastRAM) is below.

https://mega.nz/#!ZuxhiChC!h26qyOay3...TwOnwq6Wqjp65w

Broadly speaking, there's two issues I had a look at.

Firstly, there's an issue with some games (such as Powder, Capital Punishment and possibly some others) wherein the delay between a file being closed, and the next file being opened, is too short - normally not a problem when a game is run from an HDD, but it is a problem when run from CD. Sir Galahad was kind enough to bless me with such a tool to resolve that issue (closedelay20) and sure enough, when closedelay20 is run the game will at least get to playing the game (eventually.. loading times are pretty slow, and closedelay20 itself introduces artificial delay)

The second problem is.. well, as has been noted, the game crashes after a short time on an 020. I'm not an expert here but my gut told me that it was problematic that the game is taller than PAL vertically, so I did a rough-and-ugly hack that forced it to maintain 256 lines tall the entire time. That at least seemed to work (I didn't play for that long but I did manage to get well past the place it crashed for me last), with the caveat that the game is slightly cut off at the top and the bottom (for instance, part of the "player one" text is cut in half). This could maybe introduce weird graphical issues in places where more than 256 lines tall is expected I suppose..

So, I'll leave it there for now, there's probably not much more I can do on it but (hopefully) it's acceptably playable on a fastram equipped CD32 with a CD drive. If anyone (AmigaJay?) wants to use it for a release, maybe with the CD audio on it, please be my guest - though I'd recommend making sure the game runs from start to finish without any crashes.

Also note that this is untested on real hardware, just WinUAE with CD32, 020, 8MB Fast.

[Amigajay]

Ah good job at least getting it to work as far as you have! Will give it a look a bit later.

[thairacerjp]

Wonderful Work, really appreciate your kind for this beautiful shoot'them up, the most beautiful on CD32 when no crashing , I'm going to test now with tf328

[thairacerjp]

Update !
so today I have burn the iso and tested on the CD32 with tf328 and it works like a charm , the game screen is a little crop but it doesn't disturb at all, I have just played 2 levels, I will do more tomorrow , thanks Master


NEW SCREEN


ORIIGNAL SCREEN

[Cobe]

Tried it on real cd32 and after a minute or so when I picked up a laser screen got scrambled

[jotd]

I'm not the only one who gets crashes on TF with games (whdload)... seems to have an issue with the memory.

[earok]

Thanks guys!

@Cobe sorry it still has issues :/ I'll give it a proper go on my real CD32 sometime. Random question - if you disable sound, do you still get crashes?

@JOTD T-Zero in particular seems to have these glitchy issues even in WinUAE with 020/FastRAM.

Though it seems that shrinking the vertical size of the display with an ugly hack (a copper list hack to redirect all DIWSTART/DIWSTOP writes to the "NOP" register!) has made it at least a little better and less likely to corrupt.

What do you think the problem could be? I get the impression (as a complete layman here) it's something to do with DMA demand, with an 020 instead of the "minimum" 030 the CPU hogs the memory for longer and thus runs into conflicts with audio and graphics, which eventually leads to the screen corrupting. But maybe what I just said was nonsense.

[Amigajay]

Probably CPU delays as you say, the speech to pick a craft is announced 15 secs before the screen comes up!

No luck getting the Nuclear Blast or Pause buttons working with joy2key.

Though i did use the blank system config and the custom load so you don't get to see the horrid workbench screen, it also skips the really slow intro screens.

You can grab this disc here - https://mega.nz/#!1QsV3aKZ!IKXqj1s1q...gW_NhiD7jH7QPE

I also recommend turning off all background anims and transparency, this may help (or not) i have yet to test on real hardware, but its worth trying for people that have and see if they get any different results.

[earok]

Originally Posted by Amigajay

Probably CPU delays as you say, the speech to pick a craft is announced 15 secs before the screen comes up!

No luck getting the Nuclear Blast or Pause buttons working with joy2key.

Though i did use the blank system config and the custom load so you don't get to see the horrid workbench screen, it also skips the really slow intro screens.

You can grab this disc here - https://mega.nz/#!1QsV3aKZ!IKXqj1s1q...gW_NhiD7jH7QPE

I also recommend turning off all background anims and transparency, this may help (or not) i have yet to test on real hardware, but its worth trying for people that have and see if they get any different results.

Great work

Background anims and transparency is probably worth having turned off by default, if it isn't already? I could look at doing that.

Also -maybe- I can get nukes hooked to second button (kind of surprised that, this late in the Amiga life, they didn't bother with at least second button if not full CD32 pad support!).

[wairnair]

The manual (http://hol.abime.net/1551/manual) mentions under the Tips section:
"Data and instruction cache of your cpu should be set to the max"

68(ec)020 only has an instruction cache, no data cache whereas the 030 has a 256 byte data cache as well.

Could this be a / the problem? Sounds like they're using both caches actively.. what do you think?

[earok]

Originally Posted by wairnair

Could this be a / the problem? Sounds like they're using both caches actively.. what do you think?

Maybe! I have no idea heh.

I've attached an experimental patch (to tzero_custom) that tries something different - essentially disables the "shake" effect when you get hit etc which MAYBE could have been messing things up. I've only tested it minimally though.

Zip also includes the original copper list file (the one included in my previous attempt was hacked to have lower screen height) if you needed it - just copy to the data folder.

I'm not sure if that'll make things better or not, but may be worth a try to narrow things down a bit.

[wairnair]

Tried it under WinUAE, no dice. It had distorted sound, some graphical artifacts and eventually crashed (after 4-5 minutes) and gave a guru.
Here's my thinking..
030 is not a lot more/different than the 020, except quote http://www.cpu-world.com/CPUs/68030/index.html :
- The CPU has additional 256-byte data cache with one clock access time.
- Access time for the instruction cache was reduced by 50% - from two to one clock cycle.
- New burst memory interface can be used to quickly fill-in data and instruction caches.
- On-chip MMU can perform address translation in parallel to other CPU functions.

Since T0 can be run on a 68EC030 (A4000), it doesn't use the MMU. Looks like it's either the absence of data cache or burst memory interface, or both. Otherwise they're just identical..
Now, I went further and looked into the instruction sets. The 030 has LESS instructions than the 020, apart from 5 that are MMU related, only available on the full 030.
So that rules out the instruction set, too. Also, they both have the exact same data addressing modes (based on this https://www.nxp.com/files-static/arc.../M68000PRM.pdf)

So I think it boils down to some timing issue where the 020 just can't provide data in time..

Originally Posted by earok

Maybe! I have no idea heh.

I've attached an experimental patch (to tzero_custom) that tries something different - essentially disables the "shake" effect when you get hit etc which MAYBE could have been messing things up. I've only tested it minimally though.

Zip also includes the original copper list file (the one included in my previous attempt was hacked to have lower screen height) if you needed it - just copy to the data folder.

I'm not sure if that'll make things better or not, but may be worth a try to narrow things down a bit.

[thairacerjp]

Originally Posted by Cobe

Tried it on real cd32 and after a minute or so when I picked up a laser screen got scrambled

i made another test today in arcade mode, I was at the end of first level and I have half screen with glitches, similar to "Code" after black screen ! , it happens when I took bonus and the voice said "power up" lol! but DEAD in the second

[earok]

Hmm :/

I'll take another look.. it seems as though powerups or other effects are the trigger. Is this only a real hardware issue or can it be replicated in WinUAE? Was transparency and background anims turned on or left off?

[wairnair]

Built an ISO based on AmigaJay's disc in which I replaced the 2 files (T-zer0_custom and TRAUMAZERO.TRAUMADISPLAY) with earok's hack.
Gave it a try under FS-UAE with CD32 settings + 8MB fast ram, transparency and background anims turned OFF, sound fx also turned OFF.
Ship disappeared after ~1min, see attached image.

[thairacerjp]

Originally Posted by earok

Hmm :/

I'll take another look.. it seems as though powerups or other effects are the trigger. Is this only a real hardware issue or can it be replicated in WinUAE? Was transparency and background anims turned on or left off?

all turned on, I will do tests tonight without effects

EDIT : another test with all effects disables, crash at the end of the 1st level

[wairnair]

One more thing I tried was going with a full 030 AND disabling CPU caches on the early startup screen. I works 100%, so even cache seems not to be it!

I just think, it's the 030's speed advantage at the micro architecture level why the game fails on the 020.

Any other idea/opinion?

[earok]

Originally Posted by wairnair

One more thing I tried was going with a full 030 AND disabling CPU caches on the early startup screen. I works 100%, so even cache seems not to be it!
I just think, it's the 030's speed advantage at the micro architecture level why the game fails on the 020.
Any other idea/opinion?

I think.. that's basically it - too much overload of stuff going on, 030 can handle it, 020 can't.

So, I've done one last build. If this one crashes, I'll just abandon it. If it works to everyone's satisfaction, I'll work on hooking up the nukes to second button (for both players) and take a look at CD audio so we can be done with it. Help with testing would be much appreciated since I'll be quite busy with other Amiga projects this weekend.

What I've done is
- Taken the AmigaJay previous version
- Cut even more off the screen, so the score text is completely gone rather than cut in half
- Turned off animated walls, transparency and even sound by default (you can STILL turn these back on if you want)


https://mega.nz/#!x7YF1aBJ!xTLHirq5F...7G6BPgn6ghH2T0