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 :))