General Sound died :( help :)

ZXNet echo conference «hardware.zx»

From Evgeny Muchkin To All 21 August 2006

Hello, psb in 187 gives 126, i.e. 01111110, everything seems to be correct. When loading starts, it does not freeze, the mod is fully loaded into memory (at least there is such an appearance). I give the command to start playing, it passes, but there is no music. It feels like the teams are flying into a black hole irrevocably.

From psb To All 21 August 2006

Hello, CHRV CHR> Check the memory, nothing to do with the ROM. how to check memory? GS has a test. if his memory had faded, he wouldn't gave out 14 or 3. or played at least something (although who knows). and if not the 0th page (ROM) is turned on, then it will definitely not play, but the covox will work maybe :) Question: does it hang after loading the module (or when loading starts)? if not load with the player, but with your own program?

From psb To All 21 August 2006

Hello, Evgeny Muchkin Evg> It feels like the teams are flying into a black hole forever. But what if you give some commands that give out some information? they work or not? launch something like a riff tracker, etc. do more experiments It will be clearer (look also at the Xecutor4GS bootloader, there is a GSki test there).

From psb To All 21 August 2006

Hello, Evgeny Muchkin and try to do in 187? bits 1 to 6 should be 1, you never know... although, maybe with ROM or something with memory in general..

From Mark Antonov To All 21 August 2006

Hello, Evgeny Muchkin You need to write a tester - run it inside with standard commands and run it

From Chunin Roman To All 21 August 2006

Hello, psb psb> and try to do in 187? bits 1 to 6 should be 1, you never know psb> what... psb> psb> although, maybe with ROM or even with memory.. Check the memory, nothing to do with the ROM.

From psb To All 21 August 2006

Hello, Evgeny Muchkin Evg> in 187 gives 126, i.e. 01111110, everything seems to be correct. and try doing it like this in assembler: out (#bb),a in a,(#bb) and out (#b3),a in a,(#bb) In such a short time, bits 0 and 7 should not have time to be reset. if they will always be at 0, then some TM2 thread is not working or something is wrong with the bus.. then commands may be lost (more precisely, the response status bits to commands).

From Evgeny Muchkin To All 21 August 2006

Hello, psb I do this: I'm trying to download a block of codes from address 0 of length #4000 from the GS, to ZX at address #8000 ld hl,#8000 ld bc,#4000 ld a,c ; LEN.L out (#b3),a ld a,#15 ; unloading a block of codes from the HS out (#bb),a call wd ; THIS IS HERE WE GET STUCK!!!!! ld a,b ; LEN.H call wdd etc. wdd out (#b3),a wd in a,(#bb) rlca jr c,wd ret The WD label from the port reads #FE! :v2_eek; Moreover; from this state GS exits only by RESET! I checked it with emulsion. The state of the bits is identical until the out instruction is passed (#bb),#15. In the emulsion, #7F eventually appears on the WD label in the port and everything works fine. Which one do you want to change TM2? What a fucking mess :(

From Evgeny Muchkin To All 22 August 2006

Hello, Evgeny Muchkin Here’s something else I noticed: when I switch to covox mode (command #0E), then from he can't get out. Those. to exit the covox mode, you need to throw 0 into the command register; I throw it there, then I throw #f3 there (reset GS), but the kovox mode is still the same remains active and working. I don't understand anything... :-/

From Evgeny Muchkin To All 25 August 2006

Hello, Evgeny Muchkin Fixed it!!! :D Thanks to Kostya Verbov! He gave me a tip to replace LP8, which I did, putting SN74LS125AN in its place. Everything works now, thanks everyone for your feedback! :)

From psb To All 25 August 2006

Hello, Evgeny Muchkin oh! :))) well, good :))