How to run ST(e) programs with a TT ?

[yungjoon]

Hi all,

I would like to know if there is a way to do this. I use my TT for midi purpose, my cubase 3 runs fine but some synth editors crash.

I used Backward with my falcon but I didn't see any equivalent emulator for the TT.

Any idea ?

Thanks...

[FatRakoon]

The TT uses 2 types of RAM ( Providing your TT has both types that is )

These are simply STRAM and TTRAM.

Now, STRAM, can be accessed by the DMA Chip, the TTRAM cannot.

If a program is written with just the STRAM in mind, then sure, if the Ataru chucks it in the TTRAM thenere may ver y well be problems. ( Lots of different types )

So, have a look at the program flags of these synth programs, and see if they are trying to either load the program into the TTRAM ,or if they are trying to let the program access the TTRAM.

I think that when a program does not work on an Atari, this should be the first place to look.

When I moved from my MegaST to my TT I had a large number of programs that many people said dont work on a TT and yet, once I started to fiddle with the loadflags, I found they worked just fine.

Only issues I do have is with CuBase 2 but then I moved to CuBase 3 and all was well.

Massive plus for Jinnee is that you can set the loadflags EN-MASSE or in otherwords, you an make sure the loadflags are all set to use STRAM on an entire folder rather than having to open and heck one at a time.

[Klapauzius]

If a program is written with just the STRAM in mind, then sure, if the Ataru chucks it in the TTRAM thenere may ver y well be problems. ( Lots of different types )

I don't think that programs that were developed for/on the ST/E would have the TT-RAM flag set in their program header?

Three common problems for ST programs not working on the TT are:
- CPU caches: just try to turn them off in the desktop
- 32-bit bus: up to the Falcon, it was no problem to have something other than $00 in the high byte of an address or address register. On the TT, this will give a bus error when this address is accessed. This is usually caused by sloppy coding. Would have to be fixed per program.
- external/internal video snyc: lots of games/demos write to $820a.w. On the TT, bit 0 is just the other way round as it is on other machines: it has to be 1 to get a picture on screen.

There are more, but from the top of my head, these should be the most common probs.

[FatRakoon]

I don't think that programs that were developed for/on the ST/E would have the TT-RAM flag set in their program header?

The flags are there no matter what.
They are just ignored on machines that dont have FASTRAM
Any and all Machines can have TTRAM, the TT obviously, the Falcon ( Mine has 256MB of TTRAM ) and yes, even the ST ( Pak 68 for example )

- CPU caches: just try to turn them off in the desktop

The Cache has never made teh slightest bit of difference to teh running of anything on my TT ?
Sure, on the CT63 on the Falcon, this did seem to mae a bit of a difference to some apps, and I have it switched off ( For the AUTO Folder stuff ) , but the CPX Module switches it back on once its on the desktop and so far, its been fine.

So, I really doubt it will be the Cache at all.

Dont quote me on that, but in over 10 years of running the TT, I have never had an issue that was caused by its cache... Thats also saying that thsi is only on the programs I have used.

-

Exactly what programs are you having issues with?

Links if they are available on the wu-wu-wu LOL

Let me know, and I will see if I can get the same errors and more importantly if I can solve them too???

I have a few Ataris ready to test it with.

[Klapauzius]

The flags are there no matter what.
They are just ignored on machines that dont have FASTRAM

I don't think so. Bits 1 and 2 of PRGFLAGS in the program header are responsible for FastRAM load + malloc. Even when the meaning of those bits was of course unknown before FastRAM was born, a good compiler/assembler will have left those bits untouched (set them to 0). I've just checked about 20 'classic' ST programs in a hex editor and none of them had the FastRAM bits set.
You are right though that those flags will be troublemakers if they are set by mistake or ignorance. That should be a rare case anyway, I'd think?

The Cache has never made teh slightest bit of difference to teh running of anything on my TT ?......
So, I really doubt it will be the Cache at all.

Yes, CPU caches may be less 'dangerous' with most apps, but they're often fatal with games/demos.

[FatRakoon]

Perhaps, and I am only going on my own personal exerience of course, but when I first had my first TT, I soon learned that the flags were more important than I had originally assumed, The TT had only 2MB ST and 4MB TTRAM and going from a 4MB ST I found that I really needed to use the TTRAM more as it was filling up...

I set about seeing what the flags actually did and I found that many of my AUTO folder programs did indeed attempt to load up in TTRAM and some in STRAM and why was this? - I never set them previously... Why would I have wanted to?... so some were indeed already set.

Either way, since yungjoon is tryign to run an STE program on a TT, then I would still suggest that making sure the flags are set to both LOAD an MALLOC with STRAM would be the first thing to make sure of.

The second, would simply be that the STE has a Blitter, the TT does not. The software might be needing one? - shame as I feel the TT without a blitter is fast enough anyway... Had the TT been built with one in, it would only have been for compatibility, and even then, if Atari thought it was fast enough without one, they could have at least doen something to pretend its got one in surely? - after all, they put it back for the Falcon!!! - Had the TT a blitter it would have made it much more compatible.

Anyway, that will do on that subject.

Still need to know what program it is that wont run and we will be able to tell you whjy it wont run? - its possible ( probable too knowing our luck ) that the PRGFLAGS have nothing to do with your problems at all?

[yungjoon]

Hi,

Many thanks for all your advices.

The first software I tested was Avalon from steinberg I would like to use with my yamaha TX16w. It crashed at first run. Ok...

After many tries, I managed to have it running, strangly with (fast ram disabled, TT ram for mem and prg enabled), TT cache disabled, TT mid res (no need to switch to ST hi res).

But after program load, when I move the mouse, the display crashes (black screen).

I tried also mouse prg for serial mouse and same crash occured.

I don't know what to do now ...

[Klapauzius]

But after program load, when I move the mouse, the display crashes (black screen).

What version of Avalon are you using?
Anyway, Avalon has its own mouse handling (it doesn't use GEM), so that may be part of the problem.
The ikbd routine probably doesn't like the TT...

I have found a version 2.0 - if yours is the same I will examine it a little closer.

[belboz]

With my TT I have never had an issue with the TTRAM flag being set (as Klapauzius has mentioned) by accident.

The only time I messed with this flag was for an application (i.e. not a game) that was older and didn't have the flag set. So I would set it so the program ran in TTRAM to see if it would aid the application in running faster.

For me game compatibility is pretty low on TT. I wish it was better, but it isn't.

There is a program called 24bit.prg that is suppose to help the TT be more ST compatible memory map wise. I have used it on occasion for a few programs.

[lp]

There is a program called 24bit.prg that is suppose to help the TT be more ST compatible memory map wise. I have used it on occasion for a few programs.

This is a patch that allows sloppy programs to run as noted by someone in an earlier post:

- 32-bit bus: up to the Falcon, it was no problem to have something other than $00 in the high byte of an address or address register. On the TT, this will give a bus error when this address is accessed. This is usually caused by sloppy coding. Would have to be fixed per program.

This was often done on purpose as it was a trick to pass an extra byte of data to some routine, since an ST would only look at the lower 24-bits of an address. Clever but not so good for the TT.

[yungjoon]

Klapauzius, I have also Avalon 2.0.

I can have the main desk of avalon (nice to see it on my TT), but the first mouse move kills all my dreams !

[FatRakoon]

I have Avalon 2.0 too!!!

I know for a fact that the PRGFLAGS MUST be set to MALLOC from STRAM because its a sample editor... ( This is an issue with the DMA chip and NOT the TT as such. )

I will dig it out however and have a look shortly...

[belboz]

Sorry, didn't see anyone above mention 24bit.prg. Must have missed that.

This is a patch that allows sloppy programs to run as noted by someone in an earlier post:

[belboz]

Actually I looked and didn't see anyone mention 24bit.prg except me.

This is a patch that allows sloppy programs to run as noted by someone in an earlier post:

[Klapauzius]

Ok, just had a look:

- like yungjoon said, caches have to be turned off, because the protection copies code around which is a no-no with the CPU's instruction cache on (without flushing the caches).

- the FastRAM flags have to be set for the program to load at all - however this seems to be a consequence of something else going wrong in the program initialisation on the TT. There is a faulty address offset at one point, making the code access RAM in the $500000 area, so if you've got only 4MB ST RAM or less -> bombs if no TT RAM active. Setting the FastRAM flags to get the program continue booting is just an 'accidental' effect: the program won't crash but the init will be faulty nonetheless. Like FatRakoon said, the FastRAM flags should of course be turned off, as the DMA can't access FastRAM, so this would probably sooner or later wreak havoc with this type of program.

- The black screen you get when moving the mouse is triggered by the program writing to $820a.w. The video sync bit is cleared in the mouse routine -> black screen on the TT. No idea why the program is doing this at all. This can be NOPed out, so the mouse will move.


I didn't get any further yet - due to lack of time and motivation.
The program will crash anyway after a few seconds of moving the mouse around.
I guess the crashes maybe caused in an earlier stage, where the init seems to be dodgy on the TT (see above), or by something else in the ikbd routine.

Maybe I'll continue a bit with this when I'm in the right mood.
Sorry, I'm more of a games buff rather than for music apps.

[belboz]

A game that never worked for me on the TT is 10th Frame Bowling.

Seems to be flaky on my Mega STE also.

If you ever want a list of TT incompatible games, I am your man. Seems all the ones I want to play don't work on the TT.

[Klapauzius]

A game that never worked for me on the TT is 10th Frame Bowling.
Seems to be flaky on my Mega STE also.
If you ever want a list of TT incompatible games, I am your man. Seems all the ones I want to play don't work on the TT.

I also like 10th Frame. Maybe I'll try my luck with it soon..

For a few more TT compatible games, you can check my website: I will post updated, TT compatible versions of all the games some time this weekend.

Some of D-Bug's recent fixes are TT compatible as well:
http://www.dbug-automation.co.uk/falcon.htm

[yungjoon]

Thanks a lot Klapauzius for your work.

I am not a coder, what is a "NOP" out ?

[FatRakoon]

Ah, one I do remember..

NOP means No Operation... Its a simple command that tells the system to do nothing.

I know it seems silly to get a computer to do nothing, but in a very basic example, it can be used to simply help with timing, or just to wait for a bit.

In the code mentioned above, ( and I have not seen the code ) but the section that causes the Mouse to hang, might be replaced with a bunch of NOP instructions and this will in effect get rid of the nasty code that crashes the Atari... Rather than the wrong code hanging the TT, it will be doing no code.

Kind of.

[Desty]

I can have the main desk of avalon (nice to see it on my TT), but the first mouse move kills all my dreams !

Very poetic