Steem SSE 3.6 bug reports

[Cyprian]

You may receive that message if loading the snapshot would crash Steem (C++ try/catch).
It doesn't happen all the time I hope, also when you delete that file. Steem v3.6.2 is usable for you?

Today I re-checked that on a clean setup. I removed old Steem folder, I downloaded the latest Steem from your page and I extracted it to a newly created folder. Unfortunately that issue still happens every time, except when I remove file "auto.sts".
I don't know if it matters but OS is Win7 64bit.

Thx, I'll check that.
About Microwire, in Steem 3.2 there was no real emulation, in current version there's emu of volumes & bass, not treble because of big dsp issues (crash), it's for later. You must check SSE option 'Microwire'.
It's one of the (very) rare areas where I admit Hatari does better.

That case touches only LMC mixer. In STe, YM sound is only audible when Input1 is selected (this is default TOS setting). In case of Steem, whether you choose Input1/2/3/4 or Open YM is always audible.

[npomarede]

It was OK in v3.2, I copied something from Hatari where they were wrong apparently, it does the same (blue).
Thx for the report and the tester, it clarifies things.

Better use the dev version of Hatari, it was fixed in july 2013

[Steven Seagal]

Today I re-checked that on a clean setup. I removed old Steem folder, I downloaded the latest Steem from your page and I extracted it to a newly created folder. Unfortunately that issue still happens every time, except when I remove file "auto.sts".
I don't know if it matters but OS is Win7 64bit.

I saw a potential bug that would cause the exception that ends up getting you the message.
Could you please try with this build:

http://ataristeven.t15.org/Files/Steem_SSE_Beta.zip

That case touches only LMC mixer. In STe, YM sound is only audible when Input1 is selected (this is default TOS setting). In case of Steem, whether you choose Input1/2/3/4 or Open YM is always audible.

The corresponding variable was updated at IO stage, but not used in sound rendering for some reason.

[Steven Seagal]

Better use the dev version of Hatari, it was fixed in july 2013

Is it possible to download the source without a Mercurial client?

[Hippy Dave]

Better use the dev version of Hatari, it was fixed in july 2013

Is it possible to download the source without a Mercurial client?

I don't think so.
here is a home made tarball.

[Cyprian]

I saw a potential bug that would cause the exception that ends up getting you the message.
Could you please try with this build:

http://ataristeven.t15.org/Files/Steem_SSE_Beta.zip

the problem has gone

The corresponding variable was updated at IO stage, but not used in sound rendering for some reason.

that works fine now

thanks

there is another small issue. DMA sound is crackling, you can hear it in that YM_LMC1 test.
If I remember correctly you mentioned about issue with small DMA buffer. In my case it is 12 bytes buffer.

[Steven Seagal]

I saw a potential bug that would cause the exception that ends up getting you the message.
Could you please try with this build:

http://ataristeven.t15.org/Files/Steem_SSE_Beta.zip

the problem has gone

Apparently Steem couldn't init capsimg.dll, but it should work with or without.
At least the exception was caught.
Because of this bug, v3.6.3 will be released very soon. Thx for the report.

The corresponding variable was updated at IO stage, but not used in sound rendering for some reason.

that works fine now

thanks

there is another small issue. DMA sound is crackling, you can hear it in that YM_LMC1 test.
If I remember correctly you mentioned about issue with small DMA buffer. In my case it is 12 bytes buffer.

This is harder to fix, I already reviewed dma sound emu once, without success.

[lotek_style]

Hey Steven... can you please check this:

http://demozoo.org/productions/77848/

mainmenu works fine in Saint... emulator issue?

[mOdmate]

gucksdu hier: http://www.atari-forum.com/viewtopic.ph ... mo#p243972

[Steven Seagal]

Yes normally this one runs but you must select wake-up option WS1 in current version.
Note that file 'SpecificHints.txt' gives such info:

- Hackabounds Demo: STF WS1

[Avanze]

Kick Off 2 (Ver.1.4e) ipf crc 4CC10F6D crashes during the loading screen with two bombs.

[Steven Seagal]

Kick Off 2 (Ver.1.4e) ipf crc 4CC10F6D crashes during the loading screen with two bombs.

Thx for the report, nice case.
It will be fixed in next version.

Technical: Steem wouldn't execute the 'DRQ' (data request) of the floppy disk controller if bit 7 of DMA control register wasn't set. It made sense because when that bit is 0, the 'DRQ' is for hard disk controller, not floppy.
But the DMA should transfer random (?) data instead of doing nothing.

[npomarede]

Kick Off 2 (Ver.1.4e) ipf crc 4CC10F6D crashes during the loading screen with two bombs.

Thx for the report, nice case.
It will be fixed in next version.

Technical: Steem wouldn't execute the 'DRQ' (data request) of the floppy disk controller if bit 7 of DMA control register wasn't set. It made sense because when that bit is 0, the 'DRQ' is for hard disk controller, not floppy.
But the DMA should transfer random (?) data instead of doing nothing.

IIRC, bit 6 enable/disable DMA is in fact useless (at least in FDC). Most programs will write 0x90, 0x190, 0x90 to flush the dma and put it in read mode and you can see that bit6=0, yet transfer will work. What matters to read/write data on disk is to have dma sector count > 0

Nicolas

EDIT : misread, in fact you're talking about bit 7 ; does it mean Kick Off doesn't use 0x90 / 0x190 to set dma control ?

[Steven Seagal]

IIRC, bit 6 enable/disable DMA is in fact useless (at least in FDC). Most programs will write 0x90, 0x190, 0x90 to flush the dma and put it in read mode and you can see that bit6=0, yet transfer will work. What matters to read/write data on disk is to have dma sector count > 0

Nicolas

EDIT : misread, in fact you're talking about bit 7 ; does it mean Kick Off doesn't use 0x90 / 0x190 to set dma control ?

DMA control register is $50 and FDC command is $80 at that time.
There's also a CRC error on the sector "16", track 2.

Code: Select all

Assert failed: MCR&CR_DRQ_FDC_OR_HDC
caps FDC IRQ CR 80 STR 88 ( MO CRC ) TR 2 SR 16 DR 128 ($80) HBL 470250 A0: T 2/0 DMA CR 50 $260A2 SR 5 #0 PC 19EFE

[IFW]

As far as I remember DRQ is always serviced by the DMAC automatically, see below.
Notice, how read first reads the data (causing DRQ to negate), then fails if there is anything wrong.

Code: Select all

// drq set callback
void __cdecl FdcCBDrq(PCAPSFDC pfdc, UDWORD state)
{
	if (!state) {
		// clear drq mirror
		dmcinf.status&=~DMADST_DRQ;
		return;
	}

	// HDC access, dma error
	if (!(dmcinf.modecontrol & DMADMC_FH)) {
		dmcinf.status&=~DMADST_ESD;
		return;
	}

	// set drq mirror
	dmcinf.status|=DMADST_DRQ;

	// process dma
	if (dmcinf.modecontrol & DMADMC_WR) {
		// transfer limit reached/disabled dma, dma error
		if (!dmcinf.sectorcount && !dmcinf.fifofill) {
			dmcinf.status&=~DMADST_ESD;
			return;
		}

		// write to fdc: fifo buffer to fdc data until fifo is empty
		if (dmcinf.fifofill) {
			CAPSFdcWrite(&dmcinf.fdc, 3, dmcinf.fifo[DMADISK_FIFOSIZE-dmcinf.fifofill--]);
			return;
		}

		// get dma base
		UDWORD bcnt=FdcGetBcnt();

		// copy dma area to fifo
		memcpy(dmcinf.fifo, STRam+bcnt, DMADISK_FIFOSIZE);

		// set new dma base
		FdcSetBcnt(bcnt+DMADISK_FIFOSIZE);

		// fifo full (minus the data just to be written)
		dmcinf.fifofill=DMADISK_FIFOSIZE-1;

		// write data to fdc data register
		CAPSFdcWrite(&dmcinf.fdc, 3, dmcinf.fifo[0]);
	} else {
		// get fdc data register
		UDWORD data=CAPSFdcRead(&dmcinf.fdc, 3);

		// transfer limit reached/disabled dma, dma error
		if (!dmcinf.sectorcount && !dmcinf.fifofill) {
			dmcinf.status&=~DMADST_ESD;
			return;
		}

		// data to fifo buffer until fifo is full
		dmcinf.fifo[dmcinf.fifofill++]=data;
		if (dmcinf.fifofill < DMADISK_FIFOSIZE)
			return;

		// get dma base
		UDWORD bcnt=FdcGetBcnt();
		// copy fifo to dma area
		memcpy(STRam+bcnt, dmcinf.fifo, DMADISK_FIFOSIZE);

		// set new dma base
		FdcSetBcnt(bcnt+DMADISK_FIFOSIZE);

		// reset fifo (empty)
		dmcinf.fifofill=0;
	}

	// process dma counters
	dmcinf.fifoaccess+=DMADISK_FIFOSIZE;
	if (dmcinf.fifoaccess >= DMADISK_SECSIZE) {
		dmcinf.fifoaccess=0;
		FdcSetSectorCount(dmcinf.sectorcount-1);
	}
}

[npomarede]

As far as I remember DRQ is always serviced by the DMAC automatically, see below.
Notice, how read first reads the data (causing DRQ to negate), then fails if there is anything wrong.

Yes, only DMA sector count matters to transfer data. It should be high enough to read all the sectors or track.
As already tested on my STF, the following mode values are working :
- $90 / $190 : bit7=1 fdc acces + bit6=0 DMA ON + bit4=1 dma sector count ; that's the most common values used
- $D0 / $1D0 : same as $90 / $190 but with bit6=1 (DMA OFF) -> transfer works
- $50 / $150 : bit7=0 hdc access + bit6=0 DMA ON + bit4=1 dma sector count -> transfer works

So, bit 6 is useless, DMA is always ON. As for bit7, it doesn't seem to be used too. Maybe bit 6/7 were supposed to do something, but it was not implemented by Atari ?

In all 3 cases, if you read a sector from disk, it is correctly transfered (you get the sector's content, not some random or null bytes)

Nicolas

[Steven Seagal]

Thx for the clarification.
It's pretty odd, though. Why did Atari so poorly design/document its own chip?
I suppose it's bit 3 making the difference between HDC/FDC for the DRQ:

Code: Select all

    ff 8606   W       |-------xxxxxxxx-|   DMA Mode Control (Word Access)
                              ||||||||     0  Reserved (0)
                              ||||||| -----1  A0 lines of FDC/HDC
                              |||||| ------2  A1 ................ 
                              ||||| -------3  HDC (1) / FDC (0) Register Select
                              |||| --------4  Sector Count Register Select
                              |||0         5  Reserved (0)
                              || ----------6  Disable (1) / Enable (0) DMA
                              | -----------7  FDC DRQ (1) / HDC DRQ (0) 
                               ------------8  Write (1) / Read (0)

Other funny thing is the game seems to start with random data, maybe that data isn't important and the game just wants CRC error when reading the protection sector.
The STX version works, so this aspect is well done in pasti fortunately.

[npomarede]

Other funny thing is the game seems to start with random data, maybe that data isn't important and the game just wants CRC error when reading the protection sector.
The STX version works, so this aspect is well done in pasti fortunately.

Kick Off 2's protection uses some fuzzy 1024 byte sectors on track 4,6,8,... (often on sector 16). That's something widely used in Rob Northen protection and pasti has no problem to image this.

[IFW]

Actually, it uses NFA.

[Marcer]

I havent managed to get treasure trap to work, crk by superior. But works in old 3.2..

Skickat från min C6903 via Tapatalk

[Steven Seagal]

I havent managed to get treasure trap to work, crk by superior. But works in old 3.2..

Yes, it's a bug in "STEP IRQ", will be fixed.
Meanwhile it sill works in fast, non "accurate" mode (he he).
Thx for the report.

[Marcer]

Ah okay

Next trouble...

Wipe Out (replicants file version).

Cant get it to work in any Steem versions. after reps intro it loads depacks and freezes.

[Steven Seagal]

Yes, it's a bug too but this one was already in v3.2 as you noticed.
Again the drive, this time management of command $D0 (interrupt).
I'm surprised it didn't surface before.
Will be fixed too, thx for the report, especially as I may add this game to my hit list!
By the way the .ST image is 2x80x6x512 and pasti.dll can't load it (read scroller).

[Steven Seagal]

That case touches only LMC mixer. In STe, YM sound is only audible when Input1 is selected (this is default TOS setting). In case of Steem, whether you choose Input1/2/3/4 or Open YM is always audible.

Coming back to this, it seems demo Pacemaker writes '0' in that register then plays some PSG tune.
There's no sound in v3.6.4 if Microwire is checked, so should it be -12 DB instead?

[Hippy Dave]

That case touches only LMC mixer. In STe, YM sound is only audible when Input1 is selected (this is default TOS setting). In case of Steem, whether you choose Input1/2/3/4 or Open YM is always audible.

Coming back to this, it seems demo Pacemaker writes '0' in that register then plays some PSG tune.
There's no sound in v3.6.4 if Microwire is checked, so should it be -12 DB instead?

The Pacemaker demo has a bug. -12 DB does not exist (YM2149 should be silent). The Pacemaker demo has sound because it incorrectly uses the Microwire register (and gets ignored on a real STE). Thus Steem must only have YM sound when input 1 is selected, and must emulate Microwire accurately enough to ignore the Pacemaker demo. Nicolas fixed this in Hatari (June 2014).