Jump to content

mariuszw

Members
  • Posts

    187
  • Joined

  • Last visited

  • Days Won

    4

mariuszw last won the day on October 27 2018

mariuszw had the most liked content!

2 Followers

Recent Profile Visitors

8,656 profile views

mariuszw's Achievements

Chopper Commander

Chopper Commander (4/9)

664

Reputation

  1. I'm happy to see that my game port attracted some attention What was the fix? Can you please share the source code for the fix? What's your plan for further optimizing the game for 128KB? I recall I didn't have ideas for further optimizations apart from improving integer divisions by using multiply by inverse with some tables which would need 128KB as there was really no memory left in first 64KB. Ah, probably the polygon renderer (including geometry calculations) could be redone for better performance but it looked like a really big task. Mariusz.
  2. @shanti77 did the coloring in Highway Encounter.
  3. I did something like that for Skool Daze 🙂 Every screen had its data for PMG (with simple RLE compression) and DLI (built like Copper lists and later expanded to 6502 code at runtime). The only problem with such approach is memory to fit data for all screens.
  4. Yes, exactly. z80->6502 conversion is semi-automatic with my tools. C64 version code looks is less clean, with rendering code tied to game logic. Spectrum version has these clearly separated. Regarding graphics design: even with PMG overlays and 5th colour, we will end up with 3 colors (+ black background) for action area, where player ship and and enemies move. How to distinguish player bullets from enemy bullets?
  5. I did some planning for Cybernoid 2 by myself, so here are my random thoughts: C64 runs this game in bitmap mode, simply graphics is too complicated to fit within a charset (even with 256 chars). Bitmap mode also allows more colors on C64. As far as I remember, shots are also drawn on screen, so they would consume additional chars. Personally I would go into direction of using ZX Spectrum version as a base, but with graphics in lores mode, more or less these already presented in this thread, with PMG overlays for more colour. Spectrum version (which was basis for other versions) runs its in 25fps and does all movements in two hires pixel resolution (=1 lores pixel). I am pretty sure that Atari can do the same in 25fps as well. Of course game slows down when there are lots of enemies and/or bullets on the screen, but I guess nobody complains. ZX Spectrum version does eor drawing and there is no backbuffer. Also, game sprites are kind of preshifted - actually each sprite frame has fixed horizontal offset and the game logic is designed so that given sprite frame appears only on fixed horizontal position (within byte). In general, game is designed with performance in mind. I think mode E is an option here. But since Spectrum version is 256 pixels wide, a "hybrid" mode could be used to allow 5th color for playfield, at the expense of slightly awkward screen addressing. I am thinking of having characters 0-$1f in first line, $20-$3f in second line, $40-$5f in third line and $60-$7f in fourth line. in next line, character generator is pointed to +$400, and whole thing repeats down the screen. So actual bitmap to draw on is character generator memory, while characters can will be used to implement one bit color map (to enable 5th color). In this more drawing can be done even faster, when we draw column by column - up to 8 bytes can be written without adjustment of pointers and also pointers adjusted by increasing high byte of screen pointer. The drawback is ANTIC bad lines and interrupts to change character generator address. I actually have 95% completed disassembly of ZX Spectrum Cybernoid 2. Mariusz.
  6. It’s @Tezz, so he knows more, but take a look at C64 version - fighting arena is made in 4 color bitmap mode, and fighters are drawn on this arena - they are not hardware sprites. Hardware sprites are used for the creature which takes away fallen player body. Game is perfectly doable on Atari. It’s a pity that @Tezz has stopped his progress. Mariusz
  7. Geoff Crammond managed to prepare one - see https://simonowen.com/articles/augmentinel/ Seriously speaking, I haven’t seen anybody preparing such tool. Mariusz
  8. First of all, your PoP port is pure awesomeness :) Actually, you don't have to understand every piece of Z80 code when translating from Z80 to 6502. My experience with porting Pentagram, Gunfright, Jack The Nipper and Highway Encounter from ZX Spectrum to Atari proves that :) Also, according to 80/20 rule (here it translates to: 80% of CPU time is spent in 20% of code), a naive Z80 to 6502 translation does its job exceptionally well, as you actually need only 20% of the code to be optimized for performance (this was really the case with ZX Spectrum games which do everything in software, and if you are porting arcade game and these tend to have hardware for sprites, numbers may be a little bit different). What is also important is the size of translated code: naive translation produces ~2x larger code. I have a compiler which does this naive translation and the results are really good - it saves lots of manual of work. There is still some manual work to do, but compiler tries to assist with the process, by marking places in the translated code which require manual intervention. To make sure that translated code runs correctly, I have written simple debugger, which is CPU core for 6502 and Z80 running both versions of the code side by side, and comparing addresses accessed and values written/read. If you omit CPU opcode fetches and stack accesses, all other accesses should match apart from situation, where pointer is written or read from memory. Mariusz.
  9. Hello Mariuszw,

    I found your z80 recompiler and get it to run but need a suitable disassembly file of one of my mame binaries.

    it is possible that you could release your Disassembler for the z80recompiler please ? or just disassemble a file for me that I can put in the recompiler please ?

     

    greetings

    Marco

  10. Apparently speed is not that big problem with auto-translation. Just remember that 80% of execution time is spent within 20% of code, which implies there is really no point to optimize for speed the other 80% of code, which accounts for 20% of execution time. That was the reason I haven't attempted to write performance optimizer, as I thought I'd spend less time optimizing appropriate parts of generated code manually compared to time required for designing, writing and testing performance optimizer for 6502 code. On the other hand problem with code size (z80 vs 6502) is more important. Auto-translation generates code 6502 2x bigger than original z80 code. Spectrum has 48K of RAM, and typical game has around 12KB of code. After translation I need 60KB of RAM, and another 1KB for support code, so almost all RAM is used, and there is no space for any Atari specific code, like music or colour handling. With simple optimization I get 1,5x code size rate, with very aggressive manual optimization I get 1,2x code size rate. I think this "simple optimization" phase could be implemented with a tool (with reasonable effort), but this still yet to be done.
  11. Hi, Well, I am aware of Skoolkit My tools accept disassembly listing in one file, but I think skoolkit can be used to produce one file with complete disassembly, instead of creating separate html files for each routine. Published recompiler is quite picky about format of disassembly and actually accepts only the format produced by my own disassembly tool. With the time, I updated recompiler to accept different formats of disassembly. Chances are I skoolkit produced disassembly listings can work now. If they don't, I can update recompiler. Note that produced code produced by recompiler usually doesn't even compile and requires some work to compile, and even more work to make game work properly - although recompiler provides assistance for this process, by marking places in generated files which require manual intervention with warning. Once warnings are fixed, the converted game should work, but at the very slow speed, as produced 6502 code is no way optimized, neither for speed nor for size. Code size should usually be optimized, as recompiler produces 2x bigger code, and some games simply do not fit straight in RAM after recompilation (this was the case with Jack The Nipper). For performance optimization it is usually enough to optimize manually sprite drawing routines, as these are responsible for 80-90% of game execution time. In other words, recompiler is not intended to perform whole process on conversion of Z80 Spectrum game to 6502 Atari game, rather it is intended to assist in whole process, taking care of most tedious and error prone phase, i.e. rewriting Z80 assembly into 6502 assembly line by line, as it was the case before my tools were prepared . For verifying correctness of 6502 code I use a tool which runs original Z80 code and translated 6502 code side by side, and differences can be spotted quite fast. The size and speed optimization is done manually. HW routines do not need to be rewritten, I have prepared routines which deal with hardware and provide their output in format expected by Spectrum code - like routines for reading keyboard and joystick. Also, the screen is handled in Spectrum native layout, with Antic display list taking care of proper display. I am not sure what is your goal. If you plan to make tools suite to convert skoolkit disassemblies into Atari games, they I am afraid, it will be not possible to achieve. If you want to simply provide a tool so that skoolkit disassembly can be fed into recompiler, then this is perfectly doable. On the other hand, if you want to convert specific Spectrum game to Atari, then I would rather not focus on skoolkit tools, but rather on that specific game itself. Mariusz
  12. Looks great, I like its Atari-zed look! Keep on good work! I havent ported this game, but I may help if necessary. Mariusz.
×
×
  • Create New...