A strategically place RDFAST $8000_0000 could be very effective. As well as providing byte alignment, it is far more immediate in the pre-fetching too. Not using the command buffer, nor the FBW event. The FIFO runs contiguous until the next RDFAST.
By the way if @Wuerfel_21 doesn't want these additional CPU emulator discussions cluttering up her console emulation thread, happy to start a new thread, although there are two CPU emulators, 68k and Z80 currently being worked on here, so dunno where it fits.
@evanh said:
PS: Also, when using non-zero block counts, all start addresses have to be longword aligned.
Is this another problem, that rules out automatic wrapping with RDFAST & FBLOCK? On branching, first byte in FIFO must be opcode at exact jump or call address, not up to 3 bytes lower.
I figured, with fixed 64-byte blocks, wasted fetches all round was going to be order of things.
PS: Note, as above, zero count can be byte aligned.
Yes, reading up to 3 unwanted bytes to cater for long-aligned start address is not a problem. However, 64 bytes is a lot of code with no branching and most CPU emulations could have a succession of different single RDFAST blocks.
I answered the question of how to use FBLOCK. Agreed, it isn't very effective unless you're wanting complete blocks. ie: Reading/writing a block device.
I answered the question of how to use FBLOCK. Agreed, it isn't very effective unless you're wanting complete blocks. ie: Reading/writing a block device.
All I meant was I have to go out now.
I suggest moving relevant posts to a new topic, say PSRAM and XBYTE
(note that that Sonic drives PSG and OPN from the 68000 and only uses the Z80 for percussion samples (and that SEEEEEEGAAAAAAA sound), so this doesn't really mean much. But it sounds slightly funny)
Totally awesome and a great example of the flexibility of a P2. The amount of dedication needed just to reach this stage is outstanding and should be an inspiration to all who want to succeed. You'll have things running nicely in the end, and it probably won't be long now...
Music in Sonic 1 seems to work now (including percussion), but the SEEEEEEEEEEEEEEEGAAAAAAAAAAAAAAAAAAAA is still not playing. Most other games hang or have no sound still, presumably due to lack of OPN timers and Z80 interrupts.
Streets of Rage is one of the ones that does do something, but that something isn't exactly what you'd want...
...
Why does the rocket launcher sound like a wind chime?
This city was once a happy, peaceful place...
until one day, bad sound emulation.
This vicious syndicate soon had control of all
oscillators and even the envelope generator.
The city has become a center of violence
where no one is safe.
Amid this turmoil, one young programmer has
sworn to fix this fucking shitass piece of Smile.
She is willing to risk anything... even her life... on the...
Streets of Unsatisfactory YM2612 Emulation
(I wrote this while frustrated with the original OPN2Cog development. I feel it is relevant once again. Though I think the issue here has more to do with the PSG than the YM??? Idk its getting late, need sleep.
Well, messed with the audio stuff all day and it mostly works now.
Remaining issues:
- Timers don't quite work right (every game that uses them has a differently wrong tempo)
- CH3 special mode is broken
- For some reason some games don't play some samples (the SEEEEGAAA screen in all three Sonic games and also the RISE FROM YOUR GRAVE in Altered Beast). The SEEEGAAAA screen in particular is a strange one, since it does work if you leave the game idle long enough for it to play again.
Occurred to me that I haven't put out a ZIP with the audio parts yet. Here's one to that. I think I've partially fixed the CH3 special stuff... SOR's rocket launcher is no longer a wind chime and Xeno Crisis isn't as offensively out-of-tune.
Remaining known issues (audio):
SEEEEGAAAA sound in the sonic games doesn't play the first time (this one is quite puzzling. It seems to not even try to play it)
Voice samples in Altered Beast don't play at all (presumably same issue as Sonic??).
Music in Flicky, OutRun and Castlevania: Bloodlines plays too slow (timer issue).
Thunder Force IV: Occasional issues when changing music (???), but correct tempo (also timer-based)
Xeno Crisis suprisingly works, but some instruments are a bit bung
Vectorman has broken audio in-game and lots of glitches that weren't there before I added the Z80
.common_reg
cmp zk_memtmp1,#$2B wcz
if_e wrbyte zk_tmp8,ptrb[1] ' DAC enable
if_ne cmp zk_memtmp1,#$29 wz
if_nc_or_z ret wcz ' Also return on nonexistant registers $2C..$2F and $29
cmp zk_memtmp1,#$2A wz
if_e wrbyte zk_tmp8,ptrb[0] ' DAC data
if_e ret wcz
cmp zk_memtmp1,#$27 wz
if_e jmp #.tctrl ' CH3 special mode and timer ctrl
cmp zk_memtmp1,#$26 wz
if_e wrbyte zk_tmp8,ptrb[3] ' Timer B freq
if_e ret wcz
cmp zk_memtmp1,#$22 wz
if_e wrbyte zk_tmp8,ptrb[2] ' LFO ctrl
if_e ret wcz
cmp zk_memtmp1,#24 wcz ' <--------------- BUDGET CUTS !!!!!!!!!!!!!!!!!!
if_b ret wcz ' Return on unused registers $00..$21 and $23
' Must be Timer A frequency
rdword zk_memtmp0,ptrb[18/2]
if_e shl zk_tmp8,#2
if_e setq ##%11_11111100
if_a setq #%11
muxq zk_memtmp0,zk_tmp8
wrword zk_memtmp0,ptrb[18/2]
ret wcz
It's one of them dang dollar signs missing! (on line 7334 in alpha 018, if you're curious).
And they say money can't buy you happiness...
Spent yesterday staring at that code and didn't find anything wrong. Then I saw at it again today and immediately noticed the blunder....
Unfortunately, there are some new issues I've discovered since:
- Sonic 2's aquatic ruins zone has some weird plings in its music that shouldn't be there (and IIRC aren't there when playing the VGM dump through OPN2cog)
- Music tempo in Thunderforce IV is a bit unstable and slows down frequently (This is rather noticable during Stage 1's boss section)
Also, since y'all seem to like videos, here's some (patently terrible) gameplay of Castlevania: Bloodlines. With the timer fix from the previous post applied, this one now works basically flawless.
Before you ask:
- Yes, the stair climbing animation is supposed to look like that, lol
- No, the vertical bars in the picture are just a video capture artifact (chroma bleeding into luma)
- ... as is the background noise in the audio
Addendum: The timer fix (or was it one of the other fixes I have locally that I thought did nothing?) apparently also fixed whatever was causing the issues in Vectorman and that one can also be added to the "flawless" list. Well, I suck so much at it that I haven't gotten past the first level, but the demos play fine I guess.
@Wuerfel_21 said:
Guess what was up with that timer issue...
It's one of them dang dollar signs missing!
Yeah been there done that.
I recall a time I had unknowingly lent on the space key and "," key somehow and put a comma into my source file unfortunately at the far end of a line that was off the screen in the editor window with no line wrapping. Wasted a day or so staring at the apparently simple code trying to figure out what was wrong but for the life of me I couldn't see any problem. C code compiled fine with no warnings but did something totally wrong. Lesson learned: leave line wrap on.
@Wuerfel_21 said:
Guess what was up with that timer issue...
It's one of them dang dollar signs missing!
Yeah been there done that.
I recall a time I had unknowingly lent on the space key and "," key somehow and put a comma into my source file unfortunately at the far end of a line that was off the screen in the editor window with no line wrapping. Wasted a day or so staring at the apparently simple code trying to figure out what was wrong but for the life of me I couldn't see any problem. C code compiled fine with no warnings but did something totally wrong. Lesson learned: leave line wrap on.
Or just turn on indentation lines
This is what inserting a random comma off the screen looks like in VSC:
Fix top bit of PSG frequencies being discarded (fixes issues heard in Sonic 2 and Xeno Crisis. Or any game that ever tries to play a low note on a PSG channel. Xeno Crisis of course still isn't quite perfect...)
Fix some initial values for Z80 (doesn't seem to fix anything)
Make modem port registers read zero instead of undefined value (doesn't seem to fix anything)
@Wuerfel_21
Have you implemented the whole Z80 emulation including flags?
If so, I have testing for most instructions that compares with a real Z84C00. It does take hours to run but you can comment out the tests you don't want. It is based on the zexall test set.
I've tried using zexall, but it just takes too long to run.
The test I've found runs in an ADHD-compliant time frame and does more or less the same.
(I wish there was a similar test for 68000 instructions...)
All the documented flags are emulated and most of the undocumented ones (I think the block I/O ones are still wrong despite best efforts. I just gave up on that since the megadrive's Z80 doesn't need them, anyways (all devices are memory mapped))
Currently there's still some strange issues, but that I think have more to do with how the Z80 core is hooked into the rest of the system (missing sega sound in sonic, tempo issues in thunderforce)
Out of curiosity: what's the way you've choose to detect any incoming (simulated) ~BUSRQ-signaling. and, sure, how the generation of its corresponding ~BUSAK are guaranteed to match the original behaviour of a Z80 part?
@Yanomani said:
Out of curiosity: what's the way you've choose to detect any incoming (simulated) ~BUSRQ-signaling. and, sure, how the generation of its corresponding ~BUSAK are guaranteed to match the original behaviour of a Z80 part?
You could just look at the code. That's why I post it!
But ye, the way bus requests are implemented is that after each instruction, it checks the state of the bus request and reset registers. If bus is requested, acknowledge it and loop until bus is free again.
THE CURSE OF FACTOR 5 HAS BEEN VANQUISHED FOR ANOTHER DAY
Changes for alpha 020:
Fix MOVEP displacement not getting sign-extended (Mega Turrican uses MOVEP to prepare DMA commands. Due to incorrect interpretation of the displacement, the byte writes went whereever and lots of 128k (DMA length = 0) transfers from $FF0000 got executed)
Figured out the case of the missing SEGA sound (and the speech samples in Altered Beast) and of course the solution was blindingly obvious - the YM2612 pan registers all reset to $C0 (left and right channels both enabled). I was resetting them to zero, so while the sample was infact playing, the output was effectively muted until something initialized that register for channel 6.
I don't know why it took me so long to figure this out. The Sonic 2 disassembly even helpfully notes that the game forgets to set the register:
Eitherhow, here's a new ZIP and Sonic 3 in action:
Comments
A strategically place RDFAST $8000_0000 could be very effective. As well as providing byte alignment, it is far more immediate in the pre-fetching too. Not using the command buffer, nor the FBW event. The FIFO runs contiguous until the next RDFAST.
Yes please.
Yes, reading up to 3 unwanted bytes to cater for long-aligned start address is not a problem. However, 64 bytes is a lot of code with no branching and most CPU emulations could have a succession of different single RDFAST blocks.
That's enough for now.
I answered the question of how to use FBLOCK. Agreed, it isn't very effective unless you're wanting complete blocks. ie: Reading/writing a block device.
All I meant was I have to go out now.
I suggest moving relevant posts to a new topic, say
PSRAM and XBYTE
Something something audio.
(note that that Sonic drives PSG and OPN from the 68000 and only uses the Z80 for percussion samples (and that SEEEEEEGAAAAAAA sound), so this doesn't really mean much. But it sounds slightly funny)
YES ITS GOING VERY WELL
Well, almost right.
Amazing Ada!
Keep up the fantastic work
Totally awesome and a great example of the flexibility of a P2. The amount of dedication needed just to reach this stage is outstanding and should be an inspiration to all who want to succeed. You'll have things running nicely in the end, and it probably won't be long now...
Music in Sonic 1 seems to work now (including percussion), but the SEEEEEEEEEEEEEEEGAAAAAAAAAAAAAAAAAAAA is still not playing. Most other games hang or have no sound still, presumably due to lack of OPN timers and Z80 interrupts.
Streets of Rage is one of the ones that does do something, but that something isn't exactly what you'd want...
...
Why does the rocket launcher sound like a wind chime?
This city was once a happy, peaceful place...
until one day, bad sound emulation.
This vicious syndicate soon had control of all
oscillators and even the envelope generator.
The city has become a center of violence
where no one is safe.
Amid this turmoil, one young programmer has
sworn to fix this fucking shitass piece of Smile.
She is willing to risk anything... even her life... on the...
Streets of Unsatisfactory YM2612 Emulation
(I wrote this while frustrated with the original OPN2Cog development. I feel it is relevant once again. Though I think the issue here has more to do with the PSG than the YM??? Idk its getting late, need sleep.
Well, messed with the audio stuff all day and it mostly works now.
Remaining issues:
- Timers don't quite work right (every game that uses them has a differently wrong tempo)
- CH3 special mode is broken
- For some reason some games don't play some samples (the SEEEEGAAA screen in all three Sonic games and also the RISE FROM YOUR GRAVE in Altered Beast). The SEEEGAAAA screen in particular is a strange one, since it does work if you leave the game idle long enough for it to play again.
Occurred to me that I haven't put out a ZIP with the audio parts yet. Here's one to that. I think I've partially fixed the CH3 special stuff... SOR's rocket launcher is no longer a wind chime and Xeno Crisis isn't as offensively out-of-tune.
Remaining known issues (audio):
Remaining known issues (other):
(I feel like these three might all be rooted in the same 68000 bug...)
Guess what was up with that timer issue...
.common_reg cmp zk_memtmp1,#$2B wcz if_e wrbyte zk_tmp8,ptrb[1] ' DAC enable if_ne cmp zk_memtmp1,#$29 wz if_nc_or_z ret wcz ' Also return on nonexistant registers $2C..$2F and $29 cmp zk_memtmp1,#$2A wz if_e wrbyte zk_tmp8,ptrb[0] ' DAC data if_e ret wcz cmp zk_memtmp1,#$27 wz if_e jmp #.tctrl ' CH3 special mode and timer ctrl cmp zk_memtmp1,#$26 wz if_e wrbyte zk_tmp8,ptrb[3] ' Timer B freq if_e ret wcz cmp zk_memtmp1,#$22 wz if_e wrbyte zk_tmp8,ptrb[2] ' LFO ctrl if_e ret wcz cmp zk_memtmp1,#24 wcz ' <--------------- BUDGET CUTS !!!!!!!!!!!!!!!!!! if_b ret wcz ' Return on unused registers $00..$21 and $23 ' Must be Timer A frequency rdword zk_memtmp0,ptrb[18/2] if_e shl zk_tmp8,#2 if_e setq ##%11_11111100 if_a setq #%11 muxq zk_memtmp0,zk_tmp8 wrword zk_memtmp0,ptrb[18/2] ret wczIt's one of them dang dollar signs missing! (on line 7334 in alpha 018, if you're curious).
And they say money can't buy you happiness...
Spent yesterday staring at that code and didn't find anything wrong. Then I saw at it again today and immediately noticed the blunder....
Unfortunately, there are some new issues I've discovered since:
- Sonic 2's aquatic ruins zone has some weird plings in its music that shouldn't be there (and IIRC aren't there when playing the VGM dump through OPN2cog)
- Music tempo in Thunderforce IV is a bit unstable and slows down frequently (This is rather noticable during Stage 1's boss section)
Also, since y'all seem to like videos, here's some (patently terrible) gameplay of Castlevania: Bloodlines. With the timer fix from the previous post applied, this one now works basically flawless.
Before you ask:
- Yes, the stair climbing animation is supposed to look like that, lol
- No, the vertical bars in the picture are just a video capture artifact (chroma bleeding into luma)
- ... as is the background noise in the audio
Addendum: The timer fix (or was it one of the other fixes I have locally that I thought did nothing?) apparently also fixed whatever was causing the issues in Vectorman and that one can also be added to the "flawless" list. Well, I suck so much at it that I haven't gotten past the first level, but the demos play fine I guess.
OutRun also works, btw.
Yeah been there done that.
I recall a time I had unknowingly lent on the space key and "," key somehow and put a comma into my source file unfortunately at the far end of a line that was off the screen in the editor window with no line wrapping. Wasted a day or so staring at the apparently simple code trying to figure out what was wrong but for the life of me I couldn't see any problem. C code compiled fine with no warnings but did something totally wrong. Lesson learned: leave line wrap on.
Or just turn on indentation lines
This is what inserting a random comma off the screen looks like in VSC:
Here's a new ZIP...
@Wuerfel_21
Have you implemented the whole Z80 emulation including flags?
If so, I have testing for most instructions that compares with a real Z84C00. It does take hours to run but you can comment out the tests you don't want. It is based on the zexall test set.
I've tried using zexall, but it just takes too long to run.
The test I've found runs in an ADHD-compliant time frame and does more or less the same.
(I wish there was a similar test for 68000 instructions...)
All the documented flags are emulated and most of the undocumented ones (I think the block I/O ones are still wrong despite best efforts. I just gave up on that since the megadrive's Z80 doesn't need them, anyways (all devices are memory mapped))
Currently there's still some strange issues, but that I think have more to do with how the Z80 core is hooked into the rest of the system (missing sega sound in sonic, tempo issues in thunderforce)
Normal reset: PC=0000, IR=0000, IFF1=IFF2=0 (DI), IMFa,IMFb=00 (IM 0)
Special reset: PC=0000
Other registers unchanged by reset.
Out of curiosity: what's the way you've choose to detect any incoming (simulated) ~BUSRQ-signaling. and, sure, how the generation of its corresponding ~BUSAK are guaranteed to match the original behaviour of a Z80 part?
You could just look at the code. That's why I post it!
But ye, the way bus requests are implemented is that after each instruction, it checks the state of the bus request and reset registers. If bus is requested, acknowledge it and loop until bus is free again.
THE CURSE OF FACTOR 5 HAS BEEN VANQUISHED FOR ANOTHER DAY
Changes for alpha 020:
Figured out the case of the missing SEGA sound (and the speech samples in Altered Beast) and of course the solution was blindingly obvious - the YM2612 pan registers all reset to $C0 (left and right channels both enabled). I was resetting them to zero, so while the sample was infact playing, the output was effectively muted until something initialized that register for channel 6.
I don't know why it took me so long to figure this out. The Sonic 2 disassembly even helpfully notes that the game forgets to set the register:
Eitherhow, here's a new ZIP and Sonic 3 in action:
Emulation: wow! Gameplay - wowx2 Now as it has a proper audio I have to try this.
Try and report back!
Unrelatedly, found another borked game. Truxton isn't rendering any sprites...
Amazing work @Wuerfel_21 !
PSRAM needed... and I only have these chips in the antistatic bag. Time to solder them hoping it will work...