I TRY SOMETHING : PLEAZE !! WE NEED MODIFICATIONS ON STEEM

A forum for anything about the STEem Engine STE emulator, comments, problems, bug reports etc. The current version is v4.0.2. All support queries should be posted on the SourceForge site.

Moderators: Mug UK, Steem Authors, Moderator Team

C-Rem
Captain Atari
Captain Atari
Posts: 394
Joined: Wed May 01, 2002 6:45 pm

I TRY SOMETHING : PLEAZE !! WE NEED MODIFICATIONS ON STEEM

Post by C-Rem »

PLEAZE DONT LET US LIKE THIS !! STEEM NEEDS FEW THINGS TO BE PERFECT !!

PLEAZZZZZZZZ STEEM GOD AUTHORS .. MODIFY THE LASTS FEW BUGS IN THE BLITTER .. SHIFTER .. ETC

:)

At least i've tried 8)

Everybody : let a message here to let'em know we need steem to be improved at least a last time .. (tobe u can write the things u need ;) )

thx a lot
User avatar
tobe
Atari God
Atari God
Posts: 1459
Joined: Sat Jan 24, 2004 10:06 am
Location: Lyon, France
Contact:

Post by tobe »

+1

Actually there's a really annoying bug in the blitter emulation: the smudge mode isn't emulated at all :)

I found another bug related to the handling of the internal 32 bits register used for shifting.

Some shifter timings need to be fixed:
http://atari.freemind-tobe.com/BEER.PRG
In this intro, the background rasters are shifted on Steem (require TOS 1.06, doesn't work with TOS 1.62 due to shifter revision specific hack).

That's all for me :)

I can understand why Steem isn't updated. I have some spare time and I think I can fix these bugs by myself and I will accept any conditions from the original authors if they let me fix theses bugs. I've spent 8 years coding video games so complex and dirty code isn't a problem for me ;)

Please !!!
step 1: introduce bug, step 2: fix bug, step 3: goto step 1.
User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Post by Nyh »

+1

The timing of move ...,-(an) is not correct. It is first prefetch and then the write and not the other way around.

Hans Wessels
User avatar
RetroGamerUK
RetroLamerUK
RetroLamerUK
Posts: 2921
Joined: Fri Mar 26, 2004 6:37 pm
Location: Northwest England.

Post by RetroGamerUK »

I wonder if the Steem authors still login here, they have not posted anything for just over a year..
Well, I hope they do return and find the time to further improve Steem, so come back all is forgiven and so on :)
User avatar
caffeinekid
Atari maniac
Atari maniac
Posts: 88
Joined: Sun Apr 11, 2004 12:24 am
Location: Wakefield, UK
Contact:

Post by caffeinekid »

Would be nice if it went open source even if the original authors are too busy or have lost interest. I'm sure the other talented coders here could squash those bugs in no time at all.
http://www.tcksoft.co.uk <- my remakes site
"Anyone got any Neon Lights menus?" :)
User avatar
telengard
Atari freak
Atari freak
Posts: 55
Joined: Mon Dec 26, 2005 10:33 pm

Post by telengard »

caffeinekid wrote:Would be nice if it went open source even if the original authors are too busy or have lost interest. I'm sure the other talented coders here could squash those bugs in no time at all.
Yeah I'm surprised they haven't done this. This is one of the few emulators I can think of that is closed source. They must have a good reason for this.

~telengard
User avatar
Marcer
Atarilegend
Atarilegend
Posts: 4450
Joined: Wed Mar 10, 2004 6:21 pm
Location: sweden

Post by Marcer »

I also have some stuff which actually Crash in Steem, like some of my old GFA demos..

Then a small update of the YM/DMA(STE sound) handeling could be nice too!

// Marcer
- Atari ST/FM/E - Mega sTe - Portfolio - Falcon 030 FX 3 in 1 -- Atari 7800/Lynx/Jaguar -
- FTP... Ask for info
- Atari Legend (Games all-a-round)
- Paradize (Chip Music)
- Elite (Atari Softs)
- The Legion (Demos)
- Alive Maggie Team
_/|\_YM-RockerZ_/|\_
User avatar
ggn
Atari God
Atari God
Posts: 1258
Joined: Sat Dec 28, 2002 4:49 pm

Post by ggn »

telengard wrote:
caffeinekid wrote:Would be nice if it went open source even if the original authors are too busy or have lost interest. I'm sure the other talented coders here could squash those bugs in no time at all.
Yeah I'm surprised they haven't done this. This is one of the few emulators I can think of that is closed source. They must have a good reason for this.

~telengard
How about "to prevent of several corporate whores (or arseholes in general) from taking the source, building a custom version and selling it"? Of course UAE is open sourced, but who cares about Amiga? :P
is 73 Falcon patched atari games enough ? ^^
User avatar
herrv
Captain Atari
Captain Atari
Posts: 341
Joined: Thu May 29, 2003 10:19 am
Location: Rennes

Post by herrv »

full of humour le ggn ;)
------------------------------------------------------
------------ /|\ l a p i n d e f /|\ -------------
* Pray The UnHoly Lapinou From Hell ! *
------------------------------------------------------
User avatar
NiceGuyUK
Atari Super Hero
Atari Super Hero
Posts: 581
Joined: Thu Nov 25, 2004 1:03 pm
Location: Kent, England
Contact:

Post by NiceGuyUK »

ggn wrote:How about "to prevent of several corporate whores (or arseholes in general) from taking the source, building a custom version and selling it"? Of course UAE is open sourced, but who cares about Amiga? :P
Open source it under the right license (GPL springs to mind), and any changes to make a "custom version" would legally have to be made open source as well. If they're worth keeping, we'd just fold them back into the main source tree and everyone gets them for free anyway. If they don't, they're in breach of the license and they're stopped from distributing their proprietary software
Also known as Big Boss Man of Demografica
User avatar
tobe
Atari God
Atari God
Posts: 1459
Joined: Sat Jan 24, 2004 10:06 am
Location: Lyon, France
Contact:

Post by tobe »

Ok ok ok ok ok, but the topic is about Steem and the last few bugs to fix to have a *perfect* STE emulator, so I think we can get ride of the usual boring discussions about opensource and bla bla bla :)
step 1: introduce bug, step 2: fix bug, step 3: goto step 1.
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 2289
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Post by Cyprian »

tobe wrote:Actually there's a really annoying bug in the blitter emulation: the smudge mode isn't emulated at all :)
I requested this bug two years ago :)
http://www.atari-forum.com/viewtopic.php?t=6126
Nyh wrote:The timing of move ...,-(an) is not correct. It is first prefetch and then the write and not the other way around.
I found the other prefetch issue. On real STE, in some cases blitter and CPU can work in parallel, Steem can't emulate this feature.
User avatar
tobe
Atari God
Atari God
Posts: 1459
Joined: Sat Jan 24, 2004 10:06 am
Location: Lyon, France
Contact:

Post by tobe »

I found the other prefetch issue. On real STE, in some cases blitter and CPU can work in parallel, Steem can't emulate this feature.
It should work until the 68k tries to access the bus, well actually i'm coding like this but I don't know if it works :)
step 1: introduce bug, step 2: fix bug, step 3: goto step 1.
User avatar
ggn
Atari God
Atari God
Posts: 1258
Joined: Sat Dec 28, 2002 4:49 pm

Post by ggn »

NiceGuyUK wrote:
ggn wrote:How about "to prevent of several corporate whores (or arseholes in general) from taking the source, building a custom version and selling it"? Of course UAE is open sourced, but who cares about Amiga? :P
Open source it under the right license (GPL springs to mind), and any changes to make a "custom version" would legally have to be made open source as well. If they're worth keeping, we'd just fold them back into the main source tree and everyone gets them for free anyway. If they don't, they're in breach of the license and they're stopped from distributing their proprietary software
Take a look here (hall of shame). If they can get away with using the high-profile LAME encoder in a commercial project without even mentioning it, so others can potentially use the more unknown STEEM, if it gets open sourced. Anyway....
is 73 Falcon patched atari games enough ? ^^
User avatar
caffeinekid
Atari maniac
Atari maniac
Posts: 88
Joined: Sun Apr 11, 2004 12:24 am
Location: Wakefield, UK
Contact:

Post by caffeinekid »

Anyone who bought a commercial ST emulator built from an opensource freeware one would deserve all they got. :?
http://www.tcksoft.co.uk <- my remakes site
"Anyone got any Neon Lights menus?" :)
User avatar
Cyrano Jones
Atari Super Hero
Atari Super Hero
Posts: 662
Joined: Wed May 28, 2003 8:28 pm

Post by Cyrano Jones »

+1

Hard disk access with timer C disabled or changed should not work.

Probably correct with pasti hard disks, not checked yet.
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 2289
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Post by Cyprian »

tobe wrote:
I found the other prefetch issue. On real STE, in some cases blitter and CPU can work in parallel, Steem can't emulate this feature.
It should work until the 68k tries to access the bus, well actually i'm coding like this but I don't know if it works :)
what exactly are you trying? I'm asking because I did some tests and I able to run one cpu instruction (e.g DIV/MUL ) and do blitting in parallel :)
User avatar
tobe
Atari God
Atari God
Posts: 1459
Joined: Sat Jan 24, 2004 10:06 am
Location: Lyon, France
Contact:

Post by tobe »

Cyprian_K wrote:
tobe wrote:
I found the other prefetch issue. On real STE, in some cases blitter and CPU can work in parallel, Steem can't emulate this feature.
It should work until the 68k tries to access the bus, well actually i'm coding like this but I don't know if it works :)
what exactly are you trying? I'm asking because I did some tests and I able to run one cpu instruction (e.g DIV/MUL ) and do blitting in parallel :)
Instructions in the prefetch will be executed before the blitter is started. The question is to know if the blitter will start while the instruction is executed, if that instruction doesn't access the bus.
Can you describe your test? It looks *very* interresting to me ;)
step 1: introduce bug, step 2: fix bug, step 3: goto step 1.
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 2289
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Post by Cyprian »

tobe wrote:Instructions in the prefetch will be executed before the blitter is started. The question is to know if the blitter will start while the instruction is executed, if that instruction doesn't access the bus.
Can you describe your test? It looks *very* interresting to me ;)
ok :)
If you look on attached screenshot, you can see many blue/black coloured lines.
First rounded blue colored linie represents following code:

Code: Select all

move.b	d1,(a0)			; start blitter
mulu.w	d6,d0			;
In this case MULU has been done after blitting

Second represents:

Code: Select all

asl	(a0)		; prefetch mulu ; start blitter
mulu.w	d6,d0	; do mulu during blitting
Third represents:

Code: Select all

add.w 	d3,(a0)	; prefetch mulu ; start blitter
mulu.w	d6,d0	; do mulu during blitting
In second and third example, MULU has been prefetched and done during blitting.

I've attached my program, feel free to debug it :)

One important thing, this program works properly the only on real STE!
Neither Steem nor Saint nor Hatari can emulate those CPU/Blitter combiantion.
You do not have the required permissions to view the files attached to this post.
ijor
Hardware Guru
Hardware Guru
Posts: 4099
Joined: Sat May 29, 2004 7:52 pm
Contact:

Post by ijor »

Cyprian_K wrote:
tobe wrote:Instructions in the prefetch will be executed before the blitter is started.
...
In second and third example, MULU has been prefetched and done during blitting.
That's not exact. MULU has been already prefetched in all the 3 cases. What is stopping the CPU is the prefetch of the next (to MULU) instruction, which is prefetched before starting MULU execution.
User avatar
tobe
Atari God
Atari God
Posts: 1459
Joined: Sat Jan 24, 2004 10:06 am
Location: Lyon, France
Contact:

Post by tobe »

Thanks A LOT :)
I just saved 32 scanlines of cpu time by re-scheduling instructions in my code :D
ijor wrote:That's not exact. MULU has been already prefetched in all the 3 cases. What is stopping the CPU is the prefetch of the next (to MULU) instruction, which is prefetched before starting MULU execution.
What can prevent the the mul instruction to be executed while the blitter is running ? The next instruction is too long ? or it use an addressing mode that access the bus ?
step 1: introduce bug, step 2: fix bug, step 3: goto step 1.
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 2289
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Post by Cyprian »

ijor wrote:That's not exact. MULU has been already prefetched in all the 3 cases. What is stopping the CPU is the prefetch of the next (to MULU) instruction, which is prefetched before starting MULU execution.
ok, I got it.
Well, can you see possibility to run more than one instruction during blitter activity?

tobe thats great.
We'll waiting for your new production, then.
ijor
Hardware Guru
Hardware Guru
Posts: 4099
Joined: Sat May 29, 2004 7:52 pm
Contact:

Post by ijor »

tobe wrote:What can prevent the the mul instruction to be executed while the blitter is running ? The next instruction is too long ? or it use an addressing mode that access the bus ?
The next instruction is not relevant, neither MULU is. What makes the difference is the order of bus cycles in the previous instruction (the one that starts the Blitter).

Once Blitter takes control of the bus, the CPU keeps running until it needs to perform a bus cycle. The key is to start Blitter with an instruction that performs the write as the last bus cycle. Otherwise that instruction (and not MULU) is being stopped.

See my article linked below for a more detailed elaboration and a table of which instructions you can use:

http://pasti.fxatari.com/68kdocs/68kPrefetch.html
ijor
Hardware Guru
Hardware Guru
Posts: 4099
Joined: Sat May 29, 2004 7:52 pm
Contact:

Post by ijor »

Cyprian_K wrote:Well, can you see possibility to run more than one instruction during blitter activity?
No, because any instruction performs at least one bus cycle. So you have a single instruction that can partially overlap with Blitter. That instruction won't even end executing until Blitter gives back the bus.

Technically you can say that two CPU instructions execute partially concurrently with Blitter. Part of the instruction that starts Blitter, and (depending on the case) the start of the next one.
User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 2289
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Post by Cyprian »

ijor thanks for your explanation.

I found two other bugs:
- In NonHOG mode Steems blitter blocks cpu for 64 main clock cycles (8MHz),
but in real STE blitter takes 64bus cycles (2MHz).
- Second concern SKEW/FXSR flags. But I need to recheck this case.
Post Reply

Return to “Steem”