GameGear Shinobi

[Electronscape]

The Title screen the 5 Shinbo's dont complete. the first one slides all the way down the screen when he should stop for the next one. After the next one begins, the screen shifts to the right...

i've attempted to fix the CPU and Zexall reports most is working, perhaps this is a flag being corrupted?

Thought i've ported it to my own hardware so im not sure its the porting process thats gone wrong.. Can you confirm that Shinobi for the GameGear works for you at least?

[ITotalJustice]

Hi, thanks for opening an issue. I'm away until Monday next week, so I'll be able to check/fix any issues. I have a lot of local changes that I haven't pushed yet (all mappers implemented, sg1000 support) so I'll push those as well

[Electronscape]

Woah i didn't expect you to respond so quickly!! My skill in understanding the GameGear Hardware, i've looked but the assert for changing screen sizes i've not yet understood how to implement it.

[ITotalJustice]

The screen size code is currently a mess. The local changes make it easier to understand. Sorry it'll be a few days until I can push them!

[Electronscape]

Thats ok :) I have to say this code is TIGHT its fast, to the point and none of that multiple files all over the place!!! Incredible work BTW! i've included it into my project... so there's credit going into it ;)

for now i'll stop pestering!! Amazing, work again! Thank you!!!

[Electronscape]

bit of an update... it still a little buggy but im sure this game shouldn't have floating sprites that type like this lol

[Electronscape]

did you do anything with this?

// TODO: THESE ARE WRONG, MISSING FLAGS!!! static FORCE_INLINE void INC_r16(struct SMS_Core* sms, uint8_t opcode) { const uint8_t idx = opcode >> 4; set_r16(sms, get_r16(sms, idx) + 1, idx); }

static FORCE_INLINE void DEC_r16(struct SMS_Core* sms, uint8_t opcode) { const uint8_t idx = opcode >> 4; set_r16(sms, get_r16(sms, idx) - 1, idx); }

[Electronscape]

Hi, hope youre doing ok.... did you get a chance to look at the CPU? is the Z80 working properly? have you got a copy of shinobi for the game gear?

[ITotalJustice]

I'm still away until Monday

[Electronscape]

ahh you mean THIS monday coming!! LOL

sorry ;) im thinking the CPU is slightly off, your implementation of this emulator is so elegent and simple! its sooo good!

[ITotalJustice]

ahh you mean THIS monday coming!! LOL

sorry ;) im thinking the CPU is slightly off, your implementation of this emulator is so elegent and simple! its sooo good!

No problem, I want very clear. Yeah my z80 implementation isn't very good. The code is messy because I got bored implementing each instruction, no doubt theres many issues

[ITotalJustice]

bit of an update... it still a little buggy but im sure this game shouldn't have floating sprites that type like this lol

i tried shinobi with my local changes and it seems to work fine.

i'll try with master branch to see if was broken before

EDIT: yes, it was very broken before

[Electronscape]

i thought so, you did say that it was from your old NES emulator, to befair though the Z80 code appears to be so so so good , i went over the code my self and tried to understand the Z80 (im not that bright) LOL and i couldn't see anything wrong other than the odd note "TODO: Buggy?" in some of the flags... it was what lead me to think it could be a CPU issue...... the Background draw and sprite draw while very very good! so simple very quick!!

this emulator with very small file count its one of the best simply implemented ideas ever!. very very snug in low ram applications

Thank you so much for getting back to me though!!! AAALSO just for added fun, i stripped out the audio, and ran everything in an interupt, for a MCU (STM32) this isn't a problem as each interupt happens at 44khz, and the tones are clocked at the rated cycles / 8 to give them the speed corrections... Plays funny sounds with sampled voices but not worked that one out yet.

THIS code is amazing, though also im not using the SDL, i stripped that out too to use openGL.. im familiur with it more, and SDL was just a pain to find and get working in the end.

[ITotalJustice]

i thought so, you did say that it was from your old NES emulator, to befair though the Z80 code appears to be so so so good , i went over the code my self and tried to understand the Z80 (im not that bright) LOL and i couldn't see anything wrong other than the odd note "TODO: Buggy?" in some of the flags... it was what lead me to think it could be a CPU issue...... the Background draw and sprite draw while very very good! so simple very quick!!

this emulator with very small file count its one of the best simply implemented ideas ever!. very very snug in low ram applications

Thank you so much for getting back to me though!!! AAALSO just for added fun, i stripped out the audio, and ran everything in an interupt, for a MCU (STM32) this isn't a problem as each interupt happens at 44khz, and the tones are clocked at the rated cycles / 8 to give them the speed corrections... Plays funny sounds with sampled voices but not worked that one out yet.

THIS code is amazing, though also im not using the SDL, i stripped that out too to use openGL.. im familiur with it more, and SDL was just a pain to find and get working in the end.

thank you for your kind words ❤️

i've pushed all my local changes, shinobi should work for your now.

the downside is that the changes are breaking, such as the rom loading now looks like this

bool SMS_loadrom(struct SMS_Core* sms, const uint8_t* rom, size_t size, int system_hint)

the system_hint is a hint as to what system the rom is for, (sms, gg, sg1000). these are the types that can be passed https://github.com/ITotalJustice/TotalSMS/blob/34bd19fa31f25cae3edf3593af6a0f870a033e8b/src/core/types.h#L73-L78 or you can simple pass -1 to let the emulator figure it out (this is how it worked before).

that examples/ folder no longer exists, instead is a collection of minimal-ish ports. hopefully those are easier to understand than the huge example_sdl.c that i had before.

there's a lot more code in the repo now, but the core emulator doesn't depend on any of it.

ive added an option to disable audio at build time, if you build with SMS_DISBALE_AUDIO=1 then all audio code is a nop.

is you need any help porting / updating your code with these breaking changes, let me know and i'll get back to you

[Electronscape]

i've ported the code to a small device, so the memory constraints are pretty high, so i redirect anything that uses ram[0][1024 16] or example i change those out to globle pointers to external ram, so the code mostly changed in the graphics. its so fun porting code over most of the time, again this code is so so much easier to work with. I noticed you put in a few more address patches! im looking forward to adding these changes... also i 've notived you put in bool flags: 1; i take it that alone fixed a few more issues? the load rom, i totally changed as the rom is aain a global pointer -

Once the product is finished though am i ok in mentioning you? the MasterSystem i've written from the ground up was laughably slow and buggy , i guess i didnt understand the hardware as i thought i had! LOL

THANK YOU so much for keeping me in the loop on this!!! aain Incredible work!!

[ITotalJustice]

Porting my gb emulator to a SM32 was the most fun I ever had programming. It had 1MB of ram, so the binary, ram, ROM and stack all shared that 1MB. Had to do some funky stuff to get big games to run (such as Pokémon, which is 1MB on it's own). I think it ran at about 200MHZ and used a 256 32bit CLUT for graphics. I didn't work on it directly, I kept sending the code to a friend who was building this system for his final project and wanted some software to show it off heh

Working on that embedded system made me change how I wrote my C code to be more portable and minimal. Like how the ROM loading takes a raw pointer rather than a file name and using fopen etc. I'd rather let the frontend decide how it loads a rom.

Anyway! Hope you're having fun with the porting! If the code is too slow, be sure to build the emulator as a single file (I gained 12 FPS alone on the SM32, 70+ FPS in Tetris!). LTO does nearly the same thing, but it broke my friends code on the SM32 so that wasn't an option. And yes you can mention me when the project is finished

[ITotalJustice]

The bool : 1 is a microoptimisation, didn't fix anything (likely didn't change anything either). Basically packs the register set to a byte, in total saving 2 bytes...not really anything special.

I added a huge LUT here https://github.com/ITotalJustice/TotalSMS/blob/73d67f0b5753aa52dcc194ad47c8b7b1d94faa9b/src/core/rom_database.c#L18 which may be too big for your ram. You can simply make that table empty and the code will still work for sms and gg games like it did before. The table is only needed for games without headers, knowing if a game has sram and if the game is an sg1000 game.

This crc32 table can also be ignored (if ignoring the above table) https://github.com/ITotalJustice/TotalSMS/blob/73d67f0b5753aa52dcc194ad47c8b7b1d94faa9b/src/core/sms.c#L75

And this colour table can be ignored if you don't care for sg1000 games https://github.com/ITotalJustice/TotalSMS/blob/73d67f0b5753aa52dcc194ad47c8b7b1d94faa9b/src/core/vdp.c#L865

The vdp rendering should be much faster now btw, I optimised it slightly to cache the palette decoding. It can be further optimised but I haven't got it fully working yet

[Electronscape]

its how im porting it too, STM32H743 large aount of ram and SG1000 i dont remember this machine too much but i need to get a few games, if you managed to improve the speed on the VDP!! nice!! i did find a glitch in i found that pallete index at 16 and 0 need to be taken into account, i'll be implementing the change though and when this is done........ AMAZING If you get a chance, check out Sidbox you'll understand why this emulator is going in too ;)

[Electronscape]

i did this with the VPD for the sprites priority stuff

prio->array[x_index] = priority && palette_index != 0 && palette_index !=16;

since in the Alex Kid, the octopus has tentacle that is hidden by some of the water (its on palette 16) so i did it like this and appears to be working fine.

i cant use the palelle optimisation as everytning is done on a display buffer then dumped in one go in the LCD.... though this would be much better if i was doing a CRT project (and I WANNA) lol

Fantastic work and comments handling here! I REALLY TRUELY love this code!!

[ITotalJustice]

Yeah I fixed that priority bug in the last commit https://github.com/ITotalJustice/TotalSMS/blob/73d67f0b5753aa52dcc194ad47c8b7b1d94faa9b/src/core/vdp.c#L481, nice job finding the bug yourself though. It also broke https://github.com/ITotalJustice/TotalSMS/issues/23.

[Electronscape]

i didnt quite do it the way you did.... i just added the indext 16, it seemd to work ! LOL i went through hundreds of emulator code, c++ and c, and yours is soo soo embedded systems friendly!! i went with this one I spent a WHOLE week fingure out why level 2 on sonic would fail and begin to corrupt.. turns out i forgot to add trhe and it solved most of it up!! did you make changes to the CPU emulation too? i didn't spot immediately if you had

[ITotalJustice]

Basically the background can use the bg palette (0-15) or sprite palette (16-31). That 16 is an offset added to the index.

A bg pixel is transparent when the palette index is 0. However, because I added the offset, it meant that if the background was using the sprite palette then it would always be 16+. That's why you had to add the check for 0 and 16. I instead added the offset when indexing the array because that's how I should've done it in the first place heh

[ITotalJustice]

I made a couple changes in the CPU emu. For one, I removed the incorrect comment about inc_r16 being wrong as it needed flags, it doesn't actually modify the flags. I removed the code that had bug??? next to it, as it was actually a bug. I corrected the timing for CB opcodes, it matches what the z80 docs say anyway.

Was there any other bugs that you found? I didn't try to pass zexall personally because it took too long to run each test and when a test failed, the error wasn't helpful (iirc it was a hash?). I'm not sure if every z80 opcode is implemented either. I only added what the sms, gg and sg games needed to run. Hence why there's only 1 interrupt mode as well because the sms only used that 1 mode

[Electronscape]

LOL its normally the tiny things we miss.. like you, i tend to get the tough parts done welll, and miss small details out like this...

I LOVE the "Line by line" render... it has however given me an idea for my own FPGA idea adaptor

[ITotalJustice]

Btw, I'd recommend replacing my z80 code with this https://github.com/superzazu/z80 which passes zexall and has everything implemented. I'd also merge the PR's, 2 of them are important, 1 is an optimisation.

[Electronscape]

the CPU zexall mostly works! a few CRC issues with SRC for example. but thats what through me, the CPU was mostly passing the zexall yet Shinoba took a dump on the screen! LOL so it might have been the timing CB opcodes might have been what was causing the Shinobi start up to fail.

I put the cpu code on my Sidbox Emuspace, so i cranked up the CPU clock to 3ghz (a 3GHZ z80 LOOL) and even at those speeds it still passed many of them. i Tried to mess around with the flags, but my knowlage of the Z80 is just not that fancy

thats ok the z80 eough to RUN GG/SMS its perfect. its probabliy why some of the zexall codes fail...

i tried to do the single file compile, but it just made a whole lot of mess of errors i dont mind multiple files, but your 4 files in one go was just beautiful!! its a stripped down, no frills and no bulk! its an emulator that is JUST single purpose!!

i can try to replace it, but if your Z80 code works with th games i want ;) OutRun, Shinobi, Sonic, 1, 2... also i do plan for a bit of fun using a 4 channel SID 6581 sound chip lol

[ITotalJustice]

I don't know exactly what caused the shinobi issue but it wasn't the z80. It was either bus.c or the vdp drawing itself, although the game did crash after a bit so I'm inclined to think it was the code in bus.c.

Interesting that single file causes errors! I have a single.c which does exactly that, it's what I do in release builds as the compiler inlines the entire code into almost a single function lol https://github.com/ITotalJustice/TotalSMS/blob/master/src/core/single.c

Yeah if my z80 works well enough then that's good. I wouldn't rely on it for other systems that need a z80 emulated heh.

[Electronscape]

i take the shinobi still crashes now? however before it was weird if you got past the intro screeen, and got nito the level, it would play for a a moment then go dark then crash! i tried to look a tthe VDP but i didn't know enough about the BUS to debug it

the z80 for now your code if you dont mind, will keep it :)

Are you ok with me crediting you in the project? only fair, you did put a LOT of time into this and i want it to live on in embedded systems too

[ITotalJustice]

No, shinobi is fixed in the latest commit. The web build is always the latest master build so you can try a game there if you're not sure https://itotaljustice.github.io/TotalSMS/

Being credited would be appreciated thank you

[Electronscape]

fantastic and i'll be building the work toniht after work!!! if you check out Sidbox Electronscape in youtube you'll see the work im workin on... i dont wanna go advertisin in here though

What name would you wanna go as? ITotalJustice? or something else?

[ITotalJustice]

Nice! I've joined the discord server as well, in case you find it easier to ask for any help there rather than github.

you can credit with "TotalJustice". thanks again!

[heeroy10]

Hello guys. . can't you help me How can I get link (Https://GitHub.com/Itotaljustice/patches). . . .

[ITotalJustice]

Hello guys. . can't you help me How can I get link (Https://GitHub.com/Itotaljustice/patches). . . .

can't really help you there

[heeroy10]

Yes