Moderators: simonsunnyboy, Mug UK, Zorro 2, Moderator Team
f030 wrote:does not run from tt-ram, two bombs, (mighty sonic 32 with 20mb tt-ram)
Anima wrote:
Are you able to give me some more infos about the crash? Memory dump or register values?
Anima wrote:Thanks for testing on that configuration. Obviously it's not enough to use Mxalloc() for screen memory allocation and let all the other code reside in Fast RAM.
dml wrote:Could there be anything in the X68000 part of the source that assumes 24bit addressing? STRam is usually only needed by screen, blitter, audio/scsi/floppy dma.
That leaves the old 68k addressing problems...
f030 wrote:I do not know how to do it, some advice ?
CiH wrote:However, it works just fine with VGA and Fastram, also working with Centscreen enabled, and even starting from an extended (800 x 600) resolution as well.
f030 wrote:CiH wrote:However, it works just fine with VGA and Fastram, also working with Centscreen enabled, and even starting from an extended (800 x 600) resolution as well.
are you sure about that?
it seems that always load into st ram
try it with 4mb st-ram
CiH wrote:Good point. That will have to keep until later as I'm closed down for tonight. My configuration on CT2 is 14mb ST Ram and 64mb Fastram. I guess yours is 4mb and 20mb respectively?
dml wrote:On a 68040 with FastRam + I/D caches enabled I get 3 bombs and a corrupt screen.
However, trying again with both caches disabled, it seems to run.Not bad!
I checked the PRG flags and the FastRAM bits seem to be set already, is that correct? (not looked at this in years so I could get that wrong)
Trying again with D cache enabled, still works.
This is not terribly surprising - the 040 has a big instruction cache and if copyback mode is on, it needs pushed back to ram (instead of just clearing it). Or it may not have been cleared properly after SMC.
In any case FastRAM doesn't seem to be a problem here.
My 68040 MMU driver is a bit tricky though and maps the FastRam to exactly 16MB onwards - not sure where the MS board puts it...
CiH wrote:The news from my end is mixed, but better than some have been reporting![]()
Centurbo 2, in 'TOS 7.0' mode, with Fastram enabled, works!![]()
A screengrab is enclosed. The CT2 prefers a VGA display, as SCART/RGB seems to hit an unobtainable video frequency and I get a 'no signal' message. The program is still able to 'esc-exit' back to the desktop. This issue with RGB and CT2 is not uncommon, and can be found also with the game 'Running', which also needs a VGA screen, so this is not an issue with anything you've done.
CiH wrote:Hope the exception error messages mean something to someone.![]()
Anima wrote:simonsunnyboy wrote:Great effort, seems to work okay over here. I have to boot my Falcon into TOS to make it run, it does not run from FreeMinT.
What actually happens when you start it under Mint?
Cheers
Sascha
simonsunnyboy wrote:The TOS file simply terminated, it showed the output and terminated. Maybe the main proces waiting to be launched with SPACE is loaded into memory but does not receive the SPACEBAR pressing event. In any way RAM is pretty cramped then (NVDI, some ACCs, Teradesk, TOS2WIn loaded) so from 14MB only 7 or 8 are left IIRC. Maybe this is just too small for the game to fit.
simonsunnyboy wrote:Another issue: your ZIP distributes a lot of files. Are all needed or is the development stuff simpy packed for convenience?
Anima wrote:I am just using the m68k-atari-mint cross-tools for the assembling process. I don't know how to change the Fast RAM bits at all. I guess that the cross-tools are having this as the default!?
Anima wrote:In respect to the 68040 I just tried different Hatari CPU types for the emulation (68040 and even 68060) and it works so far. So I guess the emulation is not that accurate!?
Anima wrote:However, I think it could have something to do with the sprite code compilation and I can try to clear the I-cache after each sprite compiling process.
dml wrote:Anima wrote:I am just using the m68k-atari-mint cross-tools for the assembling process. I don't know how to change the Fast RAM bits at all. I guess that the cross-tools are having this as the default!?
That is possible. I'll check it more closely later on.
dml wrote:I checked the header of one of my own files generated by m68k-atari-mint-gcc, and prgflags == 0x00000007, which seems to mean all the speedy bits are set by default!
CiH wrote:I'm guessing you're running it on CT60/CTPCI with either caches turned off, delayed copyback cache set on the CT60 config menu, or both.
Users browsing this forum: No registered users and 3 guests