Jump to content

mariuszw

Members
  • Content Count

    178
  • Joined

  • Last visited

  • Days Won

    4

mariuszw last won the day on October 27 2018

mariuszw had the most liked content!

Community Reputation

626 Excellent

About mariuszw

Recent Profile Visitors

7,398 profile views
  1. 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.
  2. 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
  3. Looks great, I like its Atari-zed look! Keep on good work! I havent ported this game, but I may help if necessary. Mariusz.
  4. Yes, it is bitmap mode, just like original game on C64 was. There is one big 16x16 charset (with ~200 16x16 characters) for map items, and the other one for font, game logo and decorations (8x8, ~96 chars). Can't really fit that layout easily in multiple charsets on A8. Screen has 320 pixels (40 characters) a line, so I had an idea to emulate bitmap and have new charset every 3 lines, but this creates a gap for every three line with 8 characters (64 bytes) which makes addressing weird and also would require additional 512 bytes of RAM for these gaps, which I simply can't afford, as there is no free RAM left.
  5. Amazing job! I'm really impressed. The three titles I missed on Atari back in the day were: Gunfright (done by me ), Rick Dangerous (in production) and Flimbo's Quest (done). I feel happy like a kid
  6. It looks you have found a bug I guess it is one of my optimizations which broke it. I'll try to find a reason and fix it eventually. I was focusing on making the game work on 64KB machines, so I didn't consider making 128KB version. Actually, almost everything fitted in 64KB apart from game load/save from C64 which I had to remove due to lack of RAM. I'll consider making a version for 128KB machines. At one point I implemented faster integer division based on https://www.microsoft.com/en-us/research/publication/software-integer-division/, but I had to remove it as it is based on multiplying by inverse and it required a table with inverse numbers. I didn't have memory for this table. The slowest part seems to be geometry transformations, and this is difficult to follow and understand in 6502 assembly Mariusz.
  7. It woks perfectly on Atari with Rapidus board.
  8. And source code for those interested. Game is built upon binary image of C64 version, with Atari routines replacing C64-specific stuff. Atari version also feature several optimizations, which make the game faster than C64 original: fast table-based multiplication, optimized integer division, optimized polygon rendering and polygon sorting. Ornaments on game screen are built with PM/G graphics, which allow to use different colours in different sections of the screen (i.e. upper panel, game 3d view and bottom panel). Game also supports stereo Atari with extending mono sound to sound channel (RMT player has been modified with this feature). Enjoy! Mariusz. tesource.zip
  9. Hi everybody, We are proud to release Atari 8bit port of 3D adventure game: Total Eclipse! Team: Code: Mariusz Wojcieszek Graphics: Adam Wachowski Music and sound effects: Michał 'stRing' Radecki Additional graphics: Jose Pereira. Game is ported from C64. It features much better speed due to heavy optimizations and faster CPU clock, so it is much more enjoyable on Atari. It requires Atari with 64KB of RAM to run. It supports both PAL and NTSC, and also (for the first time) NTSC-50 and PAL-60. Game will also run properly on Atari with Rapidus accelerator. Game control: joystick up (or key arrow up) - move forward joystick down (or key arrow down) - move backward joystick left (or key arrow left) - turn left joystick right (or key arrow right) - turn right joystick fire (or key 0) - fire a pistol key P - look up key L - look down key A - angle change (small,medium or big, for current angle see heiroglyphics above the watch) key S - step size change (slow,medium or fast, see heiroglyphics for current state) key F - face forward (useful when disorientated) key U - U-turn key H - height change (stand or crouch) space key - shooting mode key C - enable/disable crosshair key R - rest key I - interrupt, a pause, displays a menu which offers music/sfx change (M) and game abort (ESC) key SELECT - changes between music and sound effects, work on title menu and in-game Gameplay video: TOTAL ECLIPSE Featuring Freescape by Major Developments Commodore 64 WELCOME TO EGYPT BACKGROUND It is written that, in the heart of ancient Egypt hundreds on years ago, the High Priest of the day had become annoyed. His people were revolting and refused to continue the sacrifices to Re the God of Sun. His anger had erupted so he set an ominous curse as punishment to the people. A great pyramid was erected and at the topmost chamber a shrine was built for Re the Sun-God. The curse was set. Should anything ever block the sun's rays during daylight hours it would be destroyed. It is now 26th October, 1930 and in just 2 hours the moon will totally eclipse the sun, triggering the curse of Re, causing the offending moon to explode showering the Earth with colossal meteorites thus upsetting the ecological balance, and plunging civilisation into a dark age of starvation and conflict. YOUR MISSION It is 8 o'clock, you have just landed your bi-plane next to the great pyramid. Your mission is to reach and destroy the shrine of the Sun-God Re, which is located at the apex of the pyramid. TREASURE Collect as much as possible-you're gonna be rich! First day's target #125,000. YOUR EQUIPMENT A revolver -plus an ample supply of bullets. Your wrist watch -the eclipse is due just before 10 o'clock. A water bottle -keep this topped up-it is very hot! It is not healthy to be without water for long periods. Your trusty compass -an essential item for succesful orientation. THE SCREEN DISPLAY Top left -Ankhs collected. Top middle -Value of treasure collected. Top right -Current state of the eclipse. Main window -Freescape 3D generated view of your present surroundings. Message display -(Under main window). This normally indicates your current location plus the height of this chamber above sea level shown in cubits eg. 24c=24 cubits. The entrance to the shrine is at a height of 72 cubits. Bottom left to right-Wrist watch, water bottle, heart beat, compass. 26th OCTOBER 1930, EGYPT... After a three day journey involving most methods of transport one can think of, and a few one would probably not like to, I arrived at Ankh-Arah village. It was a fairly typical North African town, with dry dirty streets, square whitewashed houses, and a stone well in the main square. I jumped clumsily down from my "taxi" and payed the camel driver his money. Doing a quick calculation in my head I came up with the same answer as when I started the journey-five shillings and a sixpence for a six mile camel ride. Captive markets such as helpless English Archaeologists obiviously lend themselves to exploitation by the locals... oh, well, at least I had learned the knack of getting off a camel without landing on my head, and that probably lowered the price by sixpence or so. The driver unstrapped my cases and let them drop to the ground. Without any ado he spurred his camel, turned about and was gone, leaving me looking rather lost in a slowly setting cloud of dust. I retrieved my cases and set off in search of somewhere to stay. It took me twenty minutes to find the only inn in the village: a small sandstone building like all the others, with two bedrooms, a hole in the ground for a latrine and enough insect life to set the whole English population scratching themselves. One of these was the owner, who quinting into the sun I could just make out the tiniest silver of the crescent moon, which would soon eclipse the sun. All the other exploration work I had conducted had been very much smaller than this, and took months of painstaking effort, researching and training. It was too big. I would never make it in time. The shrine that "Tiny" had identified was right at the apex. Skirting the base of the pyramid, I saw the door into the ante-chamber... te.xex te.atr
  10. Thanks for this one. Looks good. I misunderstood the principle previously, hence I was asking incorrect questions. Now I understand that PMG positions are fixed, it is only PMG data that changes and gives chosen colours.
  11. No plans at this moment. Lords of Chaos have C64 version which makes porting easier. The other games exist for Spectrum AFAIK, and this makes the port much bigger effort.
×
×
  • Create New...