|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Author | Message |
---|---|
|
Z80 Stuff
Posted: Fri Mar 27, 2020 11:34 pm Last edited by Stokes on Sun Sep 12, 2021 2:47 pm; edited 3 times in total |
Talk about some Z80 stuff here. | |
|
Posted: Sat Mar 28, 2020 12:08 pm |
I'll do it, lemme just fire up my secret Scratch-Z80 compiler and Sike. If you want your game on the SG-1000, why not learn some Z80 assembly and port it yourself? You'll probably find that you'll need to make significant changes to your game to get it on the SMS. |
|
|
Posted: Sat Mar 28, 2020 1:35 pm |
O_o Well, since this is my first year to be on here while I've done some MSX2SMS ports, I will try for all. |
|
|
Posted: Sat Mar 28, 2020 2:08 pm |
If you want to start from something close to Scratch, you could try Blockly-Z80:
http://www.haroldo-ok.com/blockly-z80/blockly-z80/demos/commands/index.html Please, do keep in mind that the tool is extremely unfinished, and the Z80 code it generates is correct, but far from optimal. Also, for didactical purposes, you might also want to try the 8bitworkshop IDE: https://8bitworkshop.com/v3.5.0/?platform=sms-sms-libcv&file=climber.c It is pretty easy to use, but you will need to know either assembly or C. |
|
|
Posted: Sat Mar 28, 2020 4:04 pm |
Wow! Thank you very much for this. I will try to create my Scratch game with these assemblers. :-) |
|
|
Posted: Sat Mar 28, 2020 4:14 pm |
https://scratch.mit.edu/projects/379884159/
Just reposted the instructions. |
|
|
Posted: Tue Mar 31, 2020 3:38 am |
I just decided to put my conversion of Q-Bert's Qubes for the SG-1000 on here.
|
|
|
Posted: Fri Apr 03, 2020 8:59 pm |
I am trying to create a GEM emulator (Game Boy Emulator for MSXturboR created by The New Image) for the Master System. I'm using both the Game Boy and Game Boy Color BIOS as a test. One of you guys might say it's not possible to put Game Boy on Master System. The SMS just uses the regular Zilog Z80, but the Game Boy has the same, or not if it just uses the "GBZ80," but it also uses the Intel 8080. | |
|
Posted: Fri Apr 03, 2020 11:00 pm |
That's definitely possible, though it will be incredibly slow. Also, you will need to provide extra RAM, since both GB and SMS have 8KB of RAM, meaning there wouldn't be nothing left for the emulator itself. A bigger obstacle would be the graphics part: the gameboy supports tile flipping for sprites, the SMS doesn't. This means that you would probably need to rewrite the sprites on the fly in order to simulate flipping. Even harder would be to simulate the window layer; there is nothing similar to it on the SMS. An alternative would be to use one of the legacy SG-1000 bitmap modes and draw everything from scratch, the same way it would be done on a PC; of course, this would probably be even slower. So, basically, you can definitely write a GB emulator for SMS, but it will have very poor performance. Still good for the hack value, though. |
|
|
Posted: Sat Apr 04, 2020 3:18 am Last edited by Stokes on Sat Apr 04, 2020 3:29 am; edited 1 time in total |
Okay, that's good to hear, I would also put it on Game Gear, but is there any way to put the BIOS inside an emulating part or change it in the start of the file? I'm trying to change the hexadecimals and coding of the BIOS at the start, including the Game Boy Color, although the GBC might have more colors that Master System like Game Gear. |
|
|
Taylor Stokes' MSX2SMS Ports
Posted: Sat Apr 04, 2020 3:27 am
|
The screen also might be like this too.
|
|
|
Posted: Sat Apr 04, 2020 9:11 am |
Did you take my advice and learn any Z80 assembly? Because if you haven't, you will really need to do that. Hex editing will not cut it here. Also, I don't believe the source is available for GEM, in which case you'd need to disassemble it yourself. I wonder whether you might be trying to run before you can walk here, to be honest. |
|
|
Posted: Sat Apr 04, 2020 10:59 am |
For whatever it's worth, there seems to be a large fraction of Game Boy games that never use the window layer at all, so you still might be able to get to "interesting" results using SMS or Game Gear the usual way. Also EverDrives have cartridge RAM support you may be able to abuse to overcome memory limitations, though it still might not fit when the game itself also used Game Boy cartridge memory. Game Boy Color has a higher speed clock available for the CPU, but some games didn't use it, typically because they also ran in the older models. If you're doing more "targeted conversion" than "pure emulation" you might also be able to port over Super Game Boy borders and colorization, those improve the appearance of many titles on a color screen. Also at least a few games targeting both Game Boy and Game Gear were built from a shared codebase Back In the Day, so there might be something to learn by analyzing them (I don't know ) | |
|
Posted: Sat Apr 04, 2020 12:05 pm |
Y'know, I'm trying to learn it in C, but still taking advice. |
|
|
Posted: Sat Apr 04, 2020 1:34 pm |
Well, if you're trying to program a GB emulator for SMS, don't care about the speed (since it won't run at full speed, even with ASM) and are trying to learn C, one option would be to port the C source of a existing GB emulator to SMS. |
|
|
Posted: Sat Apr 04, 2020 1:41 pm |
C is a good start, but the source for GEM isn't available (I just downloaded the archive to check), so you'd need to disassemble the binary and then work with the disassembly. Knowledge of C wouldn't help you there. Also, it might be considered poor form to disassemble something that actually got a release in the last decade. Edit 2: In fact, GEM is written in assembly to begin with, per their website, so C is really a non-starter for the purposes of porting it. Edit: If you're not interested in learning assembly, but you do want to try to port a Game Boy emulator, haroldoop's suggestion is probably the way to go. Just be aware that you'll probably find the performance is even worse than it might've been with an assembly-based port of GEM. Not only do you have the C overhead to worry about, but GEM had the advantage that it's written to take advantage of the similarities between the host and target CPUs, and a more generalized emulator won't have that. |
|
|
Posted: Sat Apr 04, 2020 5:12 pm |
On the other hand, if you want to be adventurous, you could try to implement a static translator, which would pick the GB-Z80 assembly code and translate it to plain Z80 code equivalents; most of the code that's not related to audio and video acess could be translated to good-performing Z80 equivalents, though you would need to perform some memory relocations here and there.
The graphics, on the other hand, would fall into exactly the same issues you would have with an emulator. Still, overall, the solution would be much faster than a pure emulator; on the other hand, a pure emulator would be far easier to code. |
|
|
Posted: Sun Apr 05, 2020 3:54 am |
The GB CPU is known as "GBZ80" because it is modified with some custom instructions added and some instructions' opcodes were moved (making them still effectively different from a stock Z80). Also, I'm fairly certain GBC uses a 15-bit palette (the same as SNES, which is what the SGB borders are infact, they are SNES graphics), even if it doesn't look like it since many games used only bright colors to compensate for the low-visibility LCD. |
|
|
Posted: Sun Apr 05, 2020 10:30 am |
For the record, these are the GB-only opcodes: Opcode GMB --------------------------------------- 08 LD (nn),SP 10 STOP 22 LDI (HL),A 2A LDI A,(HL) 32 LDD (HL),A 3A LDD A,(HL) D9 RETI ; Same functionality, but a different opcode E0 LD (FF00+n),A E2 LD (FF00+C),A E8 ADD SP,dd EA LD (nn),A F0 LD A,(FF00+n) F2 LD A,(FF00+C) F8 LD HL,SP+dd FA LD A,(nn) CB3X SWAP r/(HL) These opcodes would have to be either emulated, or translated. |
|
|
Posted: Tue Apr 14, 2020 6:27 pm |
Nobody has responded to the conversation. Is this supposed to be the BIOS of the original Game Boy? |
|
|
Posted: Tue Apr 14, 2020 6:37 pm |
no, this is not BIOS. These are the CPU instructions specific of the Game Boy CPU. These aren't present on a 'regular' Z80 | |
|
Posted: Tue Apr 14, 2020 7:14 pm |
If by "conversation" you mean this:
You do realize that it's going to take more than just a BIOS to get, really, ANY Game Boy game to work, right? I know you've been doing a lot of converting MSX ROMs, but with respect to that, emulating a Game Boy is LEAGUES above what you've done so far. If your question is "How can I paste a GB BIOS onto the start of a GB ROM and have it run on an SMS?" the answer is: you can't. |
|
lester64652373
|
I have 20 great iseas BUT
Posted: Sun May 03, 2020 6:14 pm
|
I do not have enough source examples.
I can get around in Z80 Assembly but I am not proficient at it. I was working on a side scrolling game for the SG1000 and Colecovision but it just doesn't work. I set up the 8x8 tiles and everything but my pointers and math are all off. Does anyone have a decent scroll routine in written source code that they want to share. My premise is my player is in the middle of the screen and the screen scrolls in all 4 directions. If I get to the end of the screen it wraps around to the other side. Anyone can do pacman and tetris, I want to do something new. Please, please, please anyone that can help. |
|
|
Posted: Sun May 03, 2020 6:54 pm |
Having played the Wonder Boy SG-1000 port, I doubt that any scrolling routine could be considered decent for the 9918. Check out this bit on Sega Retro about the challenges involved in software scrolling and how other games dealt with it. That said, since you know that your layout is wrapping round to the other side of the screen, it rather sounds as though you need to add a layer of extrapolation, so that you can stream your layout to the screen. Whilst I realize you want to do something "new", perhaps you should start with something less challenging so that you can get a feel for the hardware. |
|
lester64652373
|
Posted: Mon May 04, 2020 2:06 am |
Whilst I realize you want to do something "new", perhaps you should start with something less challenging so that you can get a feel for the hardware.[/quote]
Well, I have already invested 4 months into the game it's just I can't figure out the scrolling part so I will take anything I can get. Way back when I learned basic using old computer magazines on my Coleco ADAM but now that I am working at Assembly language level source code is harder to come by in order to learn. Lot's of TRS80...Very little SG1000 |
|
|
Posted: Mon May 04, 2020 3:01 am |
Are you looking for truly pixel-perfect omnidirectional scrolling, or would a "close approximation" be sufficient? If the latter, you might check out Namcot's Bosconian conversion for the MSX 1. The hardware is very similar to SG-1000, and an unofficial Korean release got it running on the SMS too as part of a multicart.
Also, it's not as readable as assembly language, but disassembling existing MSX, SG-1000, and SMS games has proven very instructive. Some emulators have built-in tools that help with this, but in the worst case a hex editor and a Z80 machine code cheat sheet are still enough to start putting together a disassembly you can use |
|
lester64652373
|
Posted: Mon May 04, 2020 9:05 pm |
[quote="bsittler"]Are you looking for truly pixel-perfect omnidirectional scrolling, or would a "close approximation" be sufficient? If the latter, you might check out Namcot's Bosconian conversion for the MSX 1. The hardware is very similar to SG-1000, and an unofficial Korean release got it running on the SMS too as part of a multicart.
For now just to get the math and things working I have no problem just moving tiles to the next column or row next to it. Later I can try and refine as best as possible or even try some type of double buffering. I have seen way too many games on the SG1000 and Colecovision to know that such things are possible. I mean Zaxxon itself, though choppy, is proof positive that almost anything can be done. |
|
|
Posted: Mon Jun 15, 2020 11:05 pm |
[quote="lester64652373"]
It's been a while for this forum post, but why not try this demo from Daniel Bienvenu that I converted for the SG-1000. It's a ColecoVision demo, but I hope this helps, I also wish that I could convert this into source code. |
|
|
Posted: Tue Jun 16, 2020 1:58 am |
By the way, there was a Korean release of Bosconian for the Samsung Gam*Boy? Wait a minute, you're talking about the 128 Total collection? Is there any ROM dump for that? Thanks in advance. |
|
|
Posted: Sat Oct 17, 2020 2:49 am |
Also Wafer, you have luck ahead of you because I'm doing assembly now. I am trying to see if I can get any TI calculator or any Z80 system on MSX. |
|
|
Posted: Sat Sep 11, 2021 11:50 am |
Hey, does anyone remember when I tried to see if I can emulate Game Boy games on the SMS or Game Gear? To this day, I discovered this Game Boy homebrew converted to the Game Gear and SMS!
|
|
|
Posted: Sat Sep 11, 2021 12:36 pm |
Yes, I had seem this one; the creator actually recompiled it from the C source; it's a different process. If you know C, there are plenty of GB games made in C that could be recompiled to SMS/GG with some variable amounts of work: * https://ultima3.ultimacodex.com/ultima-3-for-game-boy-color/ * https://github.com/MasterIV/PostBot * https://github.com/kanfor/gunsridersgameboy * https://github.com/rubfi/gbc-atari-boxing * https://web.archive.org/web/20171002042716/http://ludumdare.com/compo/ludum-dare... * https://github.com/flozz/evoland.gb * https://gbdev.gg8.se/forums/viewtopic.php?id=674 * https://github.com/elfgames/doctorhow * https://github.com/Zal0/Super-Princess-2092-Exodus * https://github.com/SimonLarsen/tobutobugirl * https://refreshgames.co.uk/2017/04/24/ludum-dare-38-entry-hives/ * https://github.com/bbbbbr/Petris * https://www.tensi.eu/thomas/programming/gameboy/loderunner.html * https://github.com/oshf/hungry_birds * https://github.com/Rafagars/Unstoppable-Knight-GB * https://github.com/JROB774/gbjam8 * https://github.com/SamuliJaaskelainen/Woolball * https://github.com/DonaldHays/bubblefactory * https://github.com/bitnenfer/FlappyBoy * https://github.com/bbbbbr/plutoscorner * https://github.com/Imanolea/bitbitjam3_red_hot_princess_carnage * https://github.com/avivace/quadratino * https://github.com/kdrnic/aliBabaAndThe40Thieves * https://github.com/rnegron/dino-gb * https://github.com/untoxa/ISOEngine * https://github.com/ML-Chen/gba-ddr * https://github.com/Imanolea/Rocket_Man_Early_Prototype * https://github.com/CaitSith2/infinity * https://github.com/DonaldHays/event-aurora * https://github.com/bandreghetti/gbsnake * https://github.com/jcnmsg/Escape-Obliterizer-GBC * https://github.com/garrettgu10/modern-gb-tetris * https://github.com/Rafagars/UFO-Hunter-GB-DEMO * https://github.com/gb-archive/fbgb There's a compatibility layer made by me and much improved by sverx that can get you halfway through the conversion, but they still need some manual adjustments due to hardware differences: https://github.com/sverx/sms-gbdk-compat You may also want to take a look at: https://github.com/gbdev/awesome-gbdev |
|
|
Posted: Sat Sep 11, 2021 3:32 pm |
You don’t need any compatibility libraries anymore, GBDK-2020 now supports SMS/GG natively: https://www.smspower.org/forums/18639-GBDK2020GetsSupportForSMSGGTargets |
|
|
Posted: Sat Sep 11, 2021 10:20 pm |
Yes, I forgot that detail, and it is even better than a compatibility layer, and should simplify a good portion of the conversion process. On the other hand, it would still be necessary to do some manual work due to hardware differences, like the fact that the SMS VDP hardware does not have sprite flipping nor a window layer. The music and sound effects would also have to be remade essentially from scratch, too. |
|
|
Posted: Sun Sep 12, 2021 12:18 am |
For the sprite flipping, could you perhaps have GBDK automatically create flipped tile data and insert it into the ROM if the target is GG/SMS? | |
|
Posted: Sun Sep 12, 2021 5:28 am Last edited by toxa on Sun Sep 12, 2021 5:52 am; edited 2 times in total |
There is a cross-platform example called “metasprites” (one with an animated elephant). There is a png image and assets are created from it. So, yes, png2asset tool creates deduplicated sprite tiles with flipping for GB and without flipping for SMS. But in that case (with Black Castle) game sources come without original images, only with prepared compressed data blob. Probably it is not too hard to decompress, add a few tiles, then compress that back, but that was not my goal. I was trying to encourage author of the original game to release SMS/GG versions in future. He makes very cool and quality games. Not sure i had succeed though. |
|
|
Posted: Sun Sep 12, 2021 5:31 am |
k, I also wonder if it would be possible to do old Game Boy games and put those on the systems as well. |
|
|
Posted: Sun Sep 12, 2021 5:37 am |
Well, games will not do that themselves, anyway. ;) |
|
|
Posted: Sun Sep 12, 2021 5:49 am |
Yes, perfectly possible if you are willing to disassemble the game, hand translate the assembly to Z80, unpack and convert the assets and re-compile the ROM. If you start now you should be able to convert 1 game every 3-6 months, looking forward to your conversions! |
|
|
Posted: Sun Sep 12, 2021 5:56 am |
If you are speaking about licensed games, probably, for most of them, it is easier to remake those from scratch. |
|
|
Posted: Sun Sep 12, 2021 9:58 am |
There are a few commercial GB games for which there are annotated disassemblies available; the game logic can be converted by search and replace, but the graphics/sound code will have to be rewritten from scratch, which will be a considerable amount of effort.
If you want fast results, you will have better luck converting the GBDK-based homebrew. |
|
|
Posted: Sun Sep 12, 2021 2:42 pm |
Indeed, as the GB Z80 uses many custom instructions, with some of the original instructions moved or removed. There would certainly be code that needs to be rewritten for stock Z80. |
|
|
Posted: Sun Sep 12, 2021 4:46 pm |
SM83 is nearly a half of z80. But that is less complex part. Device architecture is very different. Not only vdp/ppu. SMS lacks timers. Systems have different memory layout, say, SRAM location. There is no DMA on SMS. And so on, and so forth. If we have to rewrite all that, so the question is: how much assembly code will remain? ;) Probably the only worthy stuff is ripped graphics and level data. Everything else should be rewritten. |
|