@pik33 said:
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...
It is really an impressive work, well done!
PSRAM needed... and I only have these chips in the antistatic bag. Time to solder them hoping it will work...
It would be nice to have a carrier board for the P2 edge module, with all needed components and connectors.
The P2 module could resemble a cartridge if mounter vertically and in the middle of the board.
A hint for Parallax ?
@pik33 said:
PSRAM needed... and I only have these chips in the antistatic bag. Time to solder them hoping it will work...
I think I could add support for HyperRAM, too. Anyone even have the HyperBus eval module though?
@macca said:
It would be nice to have a carrier board for the P2 edge module, with all needed components and connectors.
The P2 module could resemble a cartridge if mounter vertically and in the middle of the board.
A hint for Parallax ?
Yeah, simple board with all the I/O on it would be neat.
Just found a rather silly bug, thanks to a guy on Discord who knows more about Sonic 3 than me ;3 The 68000's BCHG/BSET/BCLR instructions (when used on a register) would inherit the P2's bitfield capability. You can see a subtle bug arising from this in the Sonic 3 video: At around 4:43, the secret room should have contained a big ring, but using the first one seems to have mistakenly set multiple bits in the variable that keeps track of which big rings have been used (which is a single long bit-indexed by a byte from the ring object's data)
@Wuerfel_21 said:
Just found a rather silly bug, thanks to a guy on Discord who knows more about Sonic 3 than me ;3 The 68000's BCHG/BSET/BCLR instructions (when used on a register) would inherit the P2's bitfield capability. You can see a subtle bug arising from this in the Sonic 3 video: At around 4:43, the secret room should have contained a big ring, but using the first one seems to have mistakenly set multiple bits in the variable that keeps track of which big rings have been used (which is a single long bit-indexed by a byte from the ring object's data)
Doesn't seem to fix any of the other bugbears.
Seems to be a painfully indirect way to find/fix bugs. If there was only some exhaustive way to test the 68k core perhaps some of this pain might be avoidable.
I'm sort of going through this myself with the AVR emulator core I am working on. It's all fully coded now but I am Iooking at ways to test this.
Already coded every single one of the 65535 opcode patterns and tested them to prove my disassembler matches GCC output so I'm confident with that aspect for my own debugging, but testing all cases of executable patterns is harder. Sort of thought to build some instruction call wrapper for the ALU stuff on real AVR HW and repeatedly test all 65k input patterns per opcode (2 x 8 bit registers) and capture them serially to later match my emulator output on the same data but that seemed a bit too much work right now. I may do a smaller subset though.
@Wuerfel_21 said:
Just found a rather silly bug, thanks to a guy on Discord who knows more about Sonic 3 than me ;3 The 68000's BCHG/BSET/BCLR instructions (when used on a register) would inherit the P2's bitfield capability. You can see a subtle bug arising from this in the Sonic 3 video: At around 4:43, the secret room should have contained a big ring, but using the first one seems to have mistakenly set multiple bits in the variable that keeps track of which big rings have been used (which is a single long bit-indexed by a byte from the ring object's data)
Doesn't seem to fix any of the other bugbears.
Seems to be a painfully indirect way to find/fix bugs. If there was only some exhaustive way to test the 68k core perhaps some of this pain might be avoidable.
I'm sort of going through this myself with the AVR emulator core I am working on. It's all fully coded now but I am Iooking at ways to test this.
Already coded every single one of the 65535 opcode patterns and tested them to prove my disassembler matches GCC output so I'm confident with that aspect for my own debugging, but testing all cases of executable patterns is harder. Sort of thought to build some instruction call wrapper for the ALU stuff on real AVR HW and repeatedly test all 65k input patterns per opcode (2 x 8 bit registers) and capture them serially to later match my emulator output on the same data but that seemed a bit too much work right now. I may do a smaller subset though.
The Z80 zexall suite tests instructions with incrementing (set by a parameter list) values and sums using a 32bit CRC. After each test set (doesn;t need to be whole instruction) the CRC32 is compared to what was obtained using a real Z80.
@Wuerfel_21 said:
Slight problem: You can't test 32 bit instructions like that if you want it to complete within your lifetime.
Yeah, true, 16 bit instructions have the advantage there. In the 32 bit case just the corner cases could be tested - but the main problem is someone still has to figure all those corner cases out and code up the test suite at least once. That alone is probably a lot of work too.
I see you posted the code, so might have to try it out very soon.
What kind of hardware setup do I need?
Is this TV out or VGA?
Need any external chips for this to work or just P2?
@Rayman said:
@Wuerfel_21 This is looking very cool!
I see you posted the code, so might have to try it out very soon.
What kind of hardware setup do I need?
Just video out, USB keyboard and external RAM right now. SD card in the future.
Is this TV out or VGA?
TV (NTSC or PAL60, SVideo and/or composite) or VGA right now, but you can hack anything onto it, really, as long as the vertical timing is roughly a multiple of NTSC.
Need any external chips for this to work or just P2?
Megadrive cartridges are too big for hub RAM (most games are between 512k and 2048k. 4096k is max capacity).
So it needs the new 32 MB PSRAM P2Edge board (or equivalent). HyperRAM support maybe(TM) soon(TM).
Figured out the missing sprites in Truxton. Turns out that bit 9 of a sprite's Y position only matters for interlaced mode, progressive mode ought to ignore it.
@whicker said:
I'm having a bit of trouble understanding how to load rom images.
I don't use Linux, I don't know ruby, and I don't really understand the command line switches to loadp2.
Does the file just get loaded starting at address 0 in the qspi ram? What ending order?
Yes, the file just needs to go into the RAM. You obviously can't load it all at once, thus the loadit script. You could figure some other way... Or just install a ruby interpreter and load away. The command is ruby ./loadit.rb rom_filename.bin
@pik33 said:
You can try a Windows tool called power shell which can interpret sh files too.
Time + energy + intelligence + ADHD = Great progress
ADHD and Time indeed, not sure about the rest...
I'm honored to have a few rows of asembly code in this awesome project as well (I stumbled upon it when I was browsing the code)
Yeah, the SNEcog code is in there. Does its thing and doesn't complain. Quite a lot of sound actually comes from the PSG, it supplements the FM voices well.
Unrelatedly, Zero Tolerance debugging progress: Issue seems to be some sort of memory corruptions. Usually crashes by returning to a bung address, I've also seen it crash on divide-by-zero. I think it is related to something the VInt handler does.
I see a lot of "(A6) + huge negative offset" in the code. Seems to always contain $FF8000, so I guess the idea is to address RAM with a 2 word instruction (as opposed for 3 words for long absolute mode)? But why, when there is short absolute addressing? A true mystery.
I feel this speaks for itself. (ignore the ##negx to mk_bit31 line, that's just an optimization)
Zero Tolerance seems to work now. Game is clearly not expecting CPU to be fast enough to actually redraw the screen at smooth rates, leading to it being even more stank than usual, heh.
Don't feel too bad @Wuerfel_21 . So far I've encountered and fixed about 6 bugs in my AVR emulator core. Very glad I also decided to build in a single step debugger into the emulator from day one to track these sorts of issues down.
3 were where a # was either not present when it was needed, or was present when it should not be in ALT type instructions!
1 was if_nz instead of if_z
1 was not realizing that CMPX D, S WZ would also include prior Z state in its calculation.
1 was a decimal instead of hex value
Hopefully that is about it now....it seems to be reasonably stable now.
Bugs happen and this is perfectly normal. Yesterday while I tried to make a display list for my player I discovered the repeat command works, but only once. The reason: I incremented a DL pointer in one place and forgot to decrement it after, which caused this pointer to increment every loop and then point to garbage. This was hard to find
@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.
@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.
That's enough for now.
Mr. Brewer,
Forgive me for contacting you in this way, out of the blue, but Patrik Rak, Peter Helcmanovsky, azesmbog and I are researching the behavior of the YF and XF flags in the Z80 CCF/SCF instructions. We have written several tests and have discovered that what David Banks found out when he and you cracked the block instruction flags is not quite true. Or rather, let's say, the issue is more complex and there are other behaviors caused by factors external to the CPU that affect the flags in those instructions.
We have obviously read your great research on the special reset, and would be honored to have you join our Discord server. We are emulator authors, and we want to unravel these latest Z80 mysteries.
Just posting to say that I'm still working on it (though not as much as I'd like, am having some bad days).
Eitherhow, I'm trying to finally squash that shadow bug in Panorama Cotton. Casual observations so far:
Running the game with debugging enabled is a bit of a nonstarter due to heavy use of horizontal interrupts. It kinda runs, but with messed up video.
The game never uses DMA for anything at all. This is not only strange, but also makes it a bit hard to debug.
Speaking of harder to debug, the shadows do not get drawn at all until a ways into the level (when you're close enough to the ground).
Speaking of harder to debug, Sprite graphics in VRAM seem to be governed by some sort of on-demand heap allocation (this includes the shadow sprites we're interested in - each individual size shadow just appears at a semi-random address in VRAM when needed)
Sprite slots 0 through 5 are always used to mask the HUD, the rest seem to be filled with objects by depth order, front to back. In most cases, Cotton is the closest object, using slots 6 and 7. If visible (enabled by level script(?) and not off-screen), her shadow is then sprite 8 (this is a general pattern, shadows always use the slot after the object they belong to)
That's like 4 layers of indirection to debug through (conjecture):
Shadow size is calculated (bug is likely here)
That is presumably looked up in a table to get the data for that size shadow sprite
The address of the graphic in VRAM is looked up (and newly allocated if it isn't there yet)
The sprite entry is written into sprite table in RAM
@Wuerfel_21 said:
Just posting to say that I'm still working on it (though not as much as I'd like, am having some bad days).
Wishing you more GOOD days. If it helps, you should know that watching all the cool work you're doing here makes me very ver HAPPY.
Best regards!
-j
Thanks for the kind words.
Unrelatedly (because I'm too tired to investigate that shadow nonsense further), I figured out why the Overdrive demo hangs. Is trying to do stuff with the H counter (current TV scan position), which we can't really emulate. But just giving random values (as I do with the HBlank flag) is apparently "good enough" to get past any hangups. A slightly better way to fake it would probably to give out incrementing values for each time it is read during a given scanline. Also, I think Hblank can be simulated "in spirit" by getting wether the VDPR is currently idle or working. That is a once-per-scanline thing, too, which should cause less issues than randomizing it.
Note that demos that do funny timing tricks will never work entirely right with MegaYume's HLE approach (and wobbly timing that stems from that).
@Wuerfel_21 For your H Counter If you are not yet using ATN, you might be able to send an ATN on each scanline start to the emulator COG from your video driver or your other render COG(s), which interrupts and latches the current P2 clock value in an ISR. Then you can try to interpolate pixel position on the scanline from the current offset from this time value when you need to read it. How much overhead that would add is unknown (it might need a division operation in the CORDIC for example). However if the pixel output timing is very different due to your VDP/compositor COG processing vs the real HW delays this may not work quite as well.
Comments
It is really an impressive work, well done!
It would be nice to have a carrier board for the P2 edge module, with all needed components and connectors.
The P2 module could resemble a cartridge if mounter vertically and in the middle of the board.
A hint for Parallax ?
I think I could add support for HyperRAM, too. Anyone even have the HyperBus eval module though?
Yeah, simple board with all the I/O on it would be neat.
Just found a rather silly bug, thanks to a guy on Discord who knows more about Sonic 3 than me ;3 The 68000's BCHG/BSET/BCLR instructions (when used on a register) would inherit the P2's bitfield capability. You can see a subtle bug arising from this in the Sonic 3 video: At around 4:43, the secret room should have contained a big ring, but using the first one seems to have mistakenly set multiple bits in the variable that keeps track of which big rings have been used (which is a single long bit-indexed by a byte from the ring object's data)
Doesn't seem to fix any of the other bugbears.
I have the P2-ES Eval Board HyperRAM & HyperFlash Add-on
Seems to be a painfully indirect way to find/fix bugs. If there was only some exhaustive way to test the 68k core perhaps some of this pain might be avoidable.
I'm sort of going through this myself with the AVR emulator core I am working on. It's all fully coded now but I am Iooking at ways to test this.
Already coded every single one of the 65535 opcode patterns and tested them to prove my disassembler matches GCC output so I'm confident with that aspect for my own debugging, but testing all cases of executable patterns is harder. Sort of thought to build some instruction call wrapper for the ALU stuff on real AVR HW and repeatedly test all 65k input patterns per opcode (2 x 8 bit registers) and capture them serially to later match my emulator output on the same data but that seemed a bit too much work right now. I may do a smaller subset though.
The Z80 zexall suite tests instructions with incrementing (set by a parameter list) values and sums using a 32bit CRC. After each test set (doesn;t need to be whole instruction) the CRC32 is compared to what was obtained using a real Z80.
Slight problem: You can't test 32 bit instructions like that if you want it to complete within your lifetime.
Retroemulators are the best way of testing CPU emulators included in them, particularly if there are demoscene productions on the tested platform.
yeah, no
@Wuerfel_21 This is looking very cool!
I see you posted the code, so might have to try it out very soon.
What kind of hardware setup do I need?
Is this TV out or VGA?
Need any external chips for this to work or just P2?
Just video out, USB keyboard and external RAM right now. SD card in the future.
TV (NTSC or PAL60, SVideo and/or composite) or VGA right now, but you can hack anything onto it, really, as long as the vertical timing is roughly a multiple of NTSC.
Megadrive cartridges are too big for hub RAM (most games are between 512k and 2048k. 4096k is max capacity).
So it needs the new 32 MB PSRAM P2Edge board (or equivalent). HyperRAM support maybe(TM) soon(TM).
Figured out the missing sprites in Truxton. Turns out that bit 9 of a sprite's Y position only matters for interlaced mode, progressive mode ought to ignore it.
I'm having a bit of trouble understanding how to load rom images.
I don't use Linux, I don't know ruby, and I don't really understand the command line switches to loadp2.
Does the file just get loaded starting at address 0 in the qspi ram? What ending order?
I've gotten so far as to translate the .sh file into a .bat file, so compile is working.
You can try a Windows tool called power shell which can interpret sh files too.
Yes, the file just needs to go into the RAM. You obviously can't load it all at once, thus the loadit script. You could figure some other way... Or just install a ruby interpreter and load away. The command is
ruby ./loadit.rb rom_filename.binThat's not a thing. PowerShell uses .ps scripts.
Well, found another one that's borked. Zero Tolerance. Seems to always crash after a while. Sometimes it even brings up a regdump on screen!
@Ada
Time + energy + intelligence + ADHD = Great progress
I'm honored to have a few rows of asembly code in this awesome project as well (I stumbled upon it when I was browsing the code)
ADHD and Time indeed, not sure about the rest...
Yeah, the SNEcog code is in there. Does its thing and doesn't complain. Quite a lot of sound actually comes from the PSG, it supplements the FM voices well.
Unrelatedly, Zero Tolerance debugging progress: Issue seems to be some sort of memory corruptions. Usually crashes by returning to a bung address, I've also seen it crash on divide-by-zero. I think it is related to something the VInt handler does.
I see a lot of "(A6) + huge negative offset" in the code. Seems to always contain $FF8000, so I guess the idea is to address RAM with a 2 word instruction (as opposed for 3 words for long absolute mode)? But why, when there is short absolute addressing? A true mystery.
facepalms
I feel this speaks for itself. (ignore the
##negxtomk_bit31line, that's just an optimization)Zero Tolerance seems to work now. Game is clearly not expecting CPU to be fast enough to actually redraw the screen at smooth rates, leading to it being even more stank than usual, heh.
Don't feel too bad @Wuerfel_21 . So far I've encountered and fixed about 6 bugs in my AVR emulator core. Very glad I also decided to build in a single step debugger into the emulator from day one to track these sorts of issues down.
Hopefully that is about it now....it seems to be reasonably stable now.
Bugs happen
and this is perfectly normal. Yesterday while I tried to make a display list for my player I discovered the repeat command works, but only once. The reason: I incremented a DL pointer in one place and forgot to decrement it after, which caused this pointer to increment every loop and then point to garbage. This was hard to find 
edit
Ada, whilst I have been mad busy with crunching at work, you have been doing amazingly well with the Megadrive emu, awesome work!
@ZjoyKiLer You might like to PM me. I have been testing a real Z84C0020 using the P2 to compare the flags using my modified zexall tests. I used this is to compare my Z80 emulation on the P2.
https://retrobrewcomputers.org/forum/index.php?t=msg&th=580&start=0&
https://retrobrewcomputers.org/forum/index.php?t=msg&th=689&start=0&
Just posting to say that I'm still working on it (though not as much as I'd like, am having some bad days).
Eitherhow, I'm trying to finally squash that shadow bug in Panorama Cotton. Casual observations so far:
That's like 4 layers of indirection to debug through (conjecture):
If that isn't a "bruh moment"...
Wishing you more GOOD days. If it helps, you should know that watching all the cool work you're doing here makes me very ver HAPPY.
Best regards!
-j
Thanks for the kind words.
Unrelatedly (because I'm too tired to investigate that shadow nonsense further), I figured out why the Overdrive demo hangs. Is trying to do stuff with the H counter (current TV scan position), which we can't really emulate. But just giving random values (as I do with the HBlank flag) is apparently "good enough" to get past any hangups. A slightly better way to fake it would probably to give out incrementing values for each time it is read during a given scanline. Also, I think Hblank can be simulated "in spirit" by getting wether the VDPR is currently idle or working. That is a once-per-scanline thing, too, which should cause less issues than randomizing it.
Note that demos that do funny timing tricks will never work entirely right with MegaYume's HLE approach (and wobbly timing that stems from that).
@Wuerfel_21 For your H Counter If you are not yet using ATN, you might be able to send an ATN on each scanline start to the emulator COG from your video driver or your other render COG(s), which interrupts and latches the current P2 clock value in an ISR. Then you can try to interpolate pixel position on the scanline from the current offset from this time value when you need to read it. How much overhead that would add is unknown (it might need a division operation in the CORDIC for example). However if the pixel output timing is very different due to your VDP/compositor COG processing vs the real HW delays this may not work quite as well.