Steem SSE 3.9

[FedePede04]

Hi
I just tried the beta, and using the Sampled ym2149+c268901/ym2149 did the trick, with the clicking.
i can say why it sounded like crap, when your are averaging the sound.
i don't know if it is because i render all the clk cycles (Or clk div 16 because the square pulse is clk div 16) but in my program it sound as good as raising the frequency.

anyway, what you have done is awesome, many thx for the feature.

[Steven Seagal]

The guy who wrote the emu in MAME is Couriersud, I just ripped it.
But yes it's awesome if it sounds better for some cases.

Oversampling may have sounded bad because I was averaging the YM data (4bit or 5bit), don't know.

[FedePede04]

it still need skilled to take and use other things, sometimes it is a lot harder.
i don't think i want to guess how many hour you must have spend on STeem. but it must be MAAAAANY.
so I would like to thank you, for continue you work to improve Steem.

[Steven Seagal]

it still need skilled to take and use other things, sometimes it is a lot harder.

Of course, but in this case I would say figuring out the correct YM2149 (AY8910 in fact) behaviour was harder. Couldn't have done it myself.

i don't think i want to guess how many hour you must have spend on STeem. but it must be MAAAAANY.
so I would like to thank you, for continue you work to improve Steem.

Oh yeah, many hours in the chopper back from missions, but it's a passion, sometimes I prefer it to martial arts!

[FedePede04]

it still need skilled to take and use other things, sometimes it is a lot harder.

Of course, but in this case I would say figuring out the correct YM2149 (AY8910 in fact) behaviour was harder. Couldn't have done it myself.

i don't think i want to guess how many hour you must have spend on STeem. but it must be MAAAAANY.
so I would like to thank you, for continue you work to improve Steem.

Oh yeah, many hours in the chopper back from missions, but it's a passion, sometimes I prefer it to martial arts!

yes i also struggle a lot with the YM emulations, but i think mine is very close today.

[Steven Seagal]

Already some little changes in this new hack:
- Fixed some bugs.
- Option Sampled YM2149 not necessary (but recommended); without it Steem's original tables are used.
- Oversampling by simple averaging of rendered samples added, but it doesn't help Star Trek for example.
It helps Nostalgia credits.

[gemtwo]

Hi Steven , i am curious about your earlier teaser-post that you are planning a dongle emulator for STEEM, will that also enable us to sample and save cartridge-reads for further processing ?

[Steven Seagal]

Welcome to the forum.
Not sure I understand the question, the Boiler does have the ability to log cartridge reads, like here BAT playing music.
(option Log2/Cartridge)

Code: Select all

PC 146C6 read.w FA0346 = 0
PC 146C6 read.w FA03B4 = 0
PC 146C6 read.w FA048C = 0
PC 146C6 read.w FA051A = 0
PC 146C6 read.w FA0556 = 0
PC 146C6 read.w FA04F4 = 0
PC 146C6 read.w FA050E = 0
PC 146C6 read.w FA056A = 0
PC 146C6 read.w FA053C = 0
PC 146C6 read.w FA0516 = 0
PC 146C6 read.w FA05A6 = 0

But there's no emulation of complex dongle cartridges.
Dongles are in the 'Ports' option page.

[Cyprian]

Thx, I'll look at it.
But I guess you mean BLIT mode (hog bit=0)?

I've just corrected my previous posts, and changed HOG to BLIT where it was needed

[Steven Seagal]

Cancel your holiday, release of v3.9.2 is planned for end of this month (one year after v3.8.2, do you see a pattern?)

Last cool feature that was just added: ability to run on a second monitor, windowed or fullscreen (D3D only).

[Cyprian]

+1

just cancelled

[Steven Seagal]

Steem SSE 3.9.2 has been released on 30/06/2017.


v3.9.2 Features
_________________

- Can copy from the 'readme' texts to the clipboard.

- Can use Steem on a second monitor (D3D).

- Optional borderless window fullscreen mode for even more compatibility
(D3D).

- 'Laptop' fullscreen mode renamed 'Max Resolution', now with correct aspect
ratio + optional ST aspect ratio (DD).

- Sound: more sampling rates are managed, up to 384Khz.
Higher rates depend on your hardware. They can reduce aliasing in some
cases (Star Trek, Union Demo).


v3.9.2 Emulation improvements
_______________________________

- Hardware Expansions:
Support for MonSTer alt-RAM.

- Blitter:
Further improvements of blit mode bus arbitration.
Note that those improvements increase overhead while having no practical
use (game, demo...), but that's the price of more precise emulation.
Thx Cyprian for good test programs.

- YM2149:
If option'C2' is checked, an alternative, lower level YM2149 emulation
inspired by MAME is used. Thx Couriersud.

- Timings: NTSC clock for the Mega ST, PAL clock for the STF and the STE.


v3.9.2 Refactoring
____________________

- Former options 'Interpolated Scanlines' and 'PAL Aspect Ratio' have been
merged into a new option 'ST Monitor'.

- MFP: Timer B tick better following the 'DE' signal.
More precise timers when the CPU is accelerated (sound routines).
Some timing changes.

- CPU: 64bit cycle timers (Win64).
This makes older memory snapshots incompatible.


v3.9.2 Bugfixes
_________________

- CPU timing destination = .W (-An).

- GUI crash on select MIDI in (Win64).

- DC offset: sound is now centred on zero, start/stop shouldn't click.
Note:
PSG emulation produces positive-only values, DMA sound samples are signed.

- 2.5MB memory setting was forgotten at second cold reset.

- More compatible, less trashy fullscreen GUI (DD & D3D).

- Some other Fullscreen bugs (trash, wrong size...).


Download
__________

http://sourceforge.net/projects/steemsse/
http://ataristeven.exxoshost.co.uk/Steem.htm

[Cyprian]

moved to bug reports

[itaboy]

Tnx!! Will download t once

[Steven Seagal]

Yo dudes,

If you think about it, we are fortunate that A-F opened a dedicated forum section just for Steem bug reports, so please let's use it:

http://www.atari-forum.com/viewforum.php?f=112

Don't be taken aback by all the rules, the main idea is one separate thread per bug, it's useful, easier to follow.
Configuration details if appropriate, screenshot if appropriate, versions on which the problem appears, etc. If I need more I'll ask you in that particular thread.

[npomarede]

How it works: in a BLIT mode the BLiTTER counts every memory access used by the CPU. And after 64th it takes the control over the bus if I remember correctly for 65 bus cycles (1 cycle for bus mastering, 63 for data operations and 1 for bus mastering), later it releases the bus and again counts every memory access used by the CPU, after 64th it takes the control... and so on

Following code uses exactly 64 bus cycles, and it delays the BLiTTER pass by about 8.5 raster lines (about 4456 CPU cycles):

Code: Select all

	move.w d6,(a3)				; red to $FFFF8240		8 CPU cycles / 2 bus cycles
	move.w d3,(a3)				; white to $FFFF8240		8 CPU cycles / 2 bus cycles
	REPT 30
			move.l	D6,D7				4 CPU cycles / 1 bus cycle
			divs.w	D5,D7				144 CPU cycles / 1 bus cycle
	ENDR

Hi cyprian, this test code is very useful and I could use it to emulate accurate cpu/blitter bus sharing under Hatari (not released yet).

But when the blitter gets the bus, it will only copy $000 to $ff8240 using halftone regs. Could you preload halftone regs to use more colors than just black ? For example black, light blue, medium blue, dark blue (000, 007 , 005, 003) ?
This is because when color is black in current test, it either means that blitter just copied 000 to $ff8240 (a write was made) but it can also means that blitter did not transfer during the last 4 or 8 cycles (bus arbitration or internal delay), so the latest color will be displayed during 4 or 8 more cycles.
It would make it easier also to count how many writes were made by the blitter by looking at the screen.

Just preloading ff8a00 - ff8a1e with 000, 007, 005, 003 x4 should be enough

Nicolas

PS : sorry for hijacking a Steem thread, but this blitter description could be useful not just in emulation

[Cyprian]

Nicolas, that's cool.
I attached binary and source code. Colors changed as you asked ("halftone" label).
Sixteenth halftone register contains "green" color, to show that blitter uses 63 bus cycles for moving data

[npomarede]

Nicolas, that's cool.
I attached binary and source code. Colors changed as you asked ("halftone" label).
Sixteenth halftone register contains "green" color, to show that blitter uses 63 bus cycles for moving data

Thanks, I will have a look at it later. Could you post a picture of a real STE running this ? I think I have the same results, but just to be sure we have a reference image
PS : maybe we could start another thread with this instead of having it in Steem 3.9 thread, as it's more general.

[Cyprian]

https://goo.gl/photos/baoFtSQn32Av2kAy5

[Steven Seagal]

Nicolas, that's cool.
I attached binary and source code. Colors changed as you asked ("halftone" label).
Sixteenth halftone register contains "green" color, to show that blitter uses 63 bus cycles for moving data

Since this is still a Steem thread, here's the PNG screenshot of this new version, looks more or less the same:

BLiT_H6a4f_00001.png

[Steven Seagal]

Hi cyprian, this test code is very useful and I could use it to emulate accurate cpu/blitter bus sharing under Hatari (not released yet).

Wonder how you did it? In Steem, if a blit is going on, there's a check at each CPU R/W, which adds overhead.

[npomarede]

Hi cyprian, this test code is very useful and I could use it to emulate accurate cpu/blitter bus sharing under Hatari (not released yet).

Wonder how you did it? In Steem, if a blit is going on, there's a check at each CPU R/W, which adds overhead.

Same thing, no black magic involved Only solution is to count memory accesses in the parts common to all cpu opcodes, which adds a little overhead (some of this overhead can be turned off at runtime in Hatari using different memory access functions in case we're emulating an STF or cycle accurate mode is not selected for STE). But in the end, the overhead doesn't seem too much, considering that cpu emulation already does a lot of work, handling a counter is not a huge difference.

[Steven Seagal]

Steem v3.9.3 should be released soon, probably in September, mainly with bugfixes (Gianna STE, Rogue...), and an effective antialias filter for YM2149 emulation. Star Trek begins to sound OK even at 44.1khz!

Features talked about in other threads such as 'Freeboot', 'Hardware Overscan' and the 'Advanced Settings' switch are saved for future v4.0.

[Steven Seagal]

Release of v3.9.3 planned on 30/9 (next Saturday).

Last dev builds just uploaded, I'd appreciate if you could test those.
The link is in my "signature" but anyway:

http://sourceforge.net/projects/steemss ... DevBuilds/

[Maartau]

Release of v3.9.3 planned on 30/9 (next Saturday).

Last dev builds just uploaded, I'd appreciate if you could test those.

Thanks Steven .

I will test .