honza.c

For example (r,g, = (63,63,63) represents white color on old machines, if you shift it you get (252, 252, 252) insteed white color (255, 255, 255); you get a bit gray insteed white, and all colors will be a bit darker but will not be changed, clolors will be correct. If you have for example 16-bit trucolor format RGB565 (5 bit red component, 6bit green and 5bit blue) and if you perform conversion based on shifts than you get completly different color, coloor will be changed; In this case (31,63,31) is white color and after shift you get (248,252,248) whitch is diferent color from white. I'm think i can't be visible diference but it isnot correct. Got it?

video dac on pc-at (ega, vga) has 6 bit resolution (0..63). game useing two methods to set palette 1. ega, vga bios call int 13h component have to be in range (0..63). 2. direct write to crt controller's dac registers, range (0..63) original game performs no conversion or shift because component is in hardware format and is written directly. main point is increase intensity to range (0..255), correct is to recalculate it linearly. do as you wish, it can't be visible.

small remark for md5: if you convert color components you use formula: red_new = red_old << 2; /* red_new ranges <0..255>, red_old ranges <0..63>, this gives new intensity 252 for value 63 */ i use commonly this formula: red_new = red_old * 255 / 63; /* same ranges, but gives 255 for value 63 and results a little more intensity */ same apply for green, blue component.

Hello mh5, welcome -First of all I apologize. I'm sorry. All you wrote is true. -Every body has some opinion. I sad I'm not interested, but forum can be very interested. Don't take only me into acount. It not depends on me. I also said scummvm is nice library with nice modularity and I have no better knowelede to make conclusions about scummvm, even utilize it. -At this stage of project we are trying to discover technics how to use original data and handle them. I think there must be many work done before we can start implement our engine. -I know some thinks about gba and I'm also developing hardware based on arm7, arm9 and cortex-m3, so this is reason for low footprint design. Low footprit can benefit on any platform and I don't see much arguments for wasting of resources. -Classes "objectification" or Structures. I still dont understant why structured programming have to be so bad. I started programming on i8080 in 1990 and my expiriences orders me to better write structured program primarilly if it is simple utility using arrays, several variables and several functions. In case I need genericity or polymorphism c++ comes handy, better choice. But I'm sure that package will grow and later will be rewriten. Leter, not now in stage of debuging and developement. Also SDL works well now. Later we can choose another libraries optimal for our requests. -Every good machine dependent interface can garant good portability not only scummvm or sdl. I believe scummvm can run more platforms than SDL supports. -Rewriting from assembly / reverse ingeneering, bad translation, sorry I'm not expirienced in eglish language much. -Mame copyright: dosbox (some older version) used shorted or adapted form of mame copyright and was scolded. In last version they rewrote all to c++ and completely removed fmopl.c. If I'm wrong I apologize again. Thats all from me. I wish you succes, you making good work.

Current state of reversing 1. LOGO Rewriting logo.exe is almost complete, but there is some error in displaing sptites. I must found it and repair it. I must missed some detail. I thing it will come to release soon, after i found that error. Also I add coments and rewrite it to be nice. Outputs: - We can benefit from logo algos and design more advanced sprite dumper - I benefit from logo during rewriting dunevga driver 2. DUNEVGA driver Rewriting dunevga is in progress. dunevga contents more advanced bliting funcs than logo an more variants than logo. Basic functions - palette processing, and bliting i have already rewriten to C but no debuuged or tested yet. Thanks to logo I compreheded it quite quickly. Rewrite more than half of code still remain. Also DUNEPRG nedded to understand how duneprg interfacing with this driver exactly. 3. DUNE386 driver Same video driver as dunevga. Only diference is in several 386+ 32-bit instructions used for acceleration. I dont need to worry about this. 4. DUNEADL driver Almost rewriten to C, 4 functions remaining. Several things I don't understand what is doing and how exactly works, inculde main player routine. I need to rewrite audio related code in duneprg and figure out how works together. Than I can write music player. More and more seems, that music format is very simple format and music is produced by writing a kind of raw data to adlib registers. Outputs: - music player and wave dumper or converting tool to/from ADL,AGD format. 5. DUNEAGD driver Generaly same driver as DUNEADL but uses 4 operator stereo FM. Diference is only extended adlib gold register set and extended music format. Fuction interface is same as duneadl. This would be done after duneadl will be completed. This is only extension to adlib and I think it would come very easy. 6. DUNESDB Sound blaster have same FM chip like adlib + digitized music. Like in point 4 this will be extension of adlib + dma/interrupt driven transfers. I'm thinkig about supporting digitized sound, because my game contents 11 voc files? 7. DUNEPRG Rewriting is in early state. I already reversed several first execuded functions releted to initializations. This is main point of interest now because I need to understant how interworks with drivers. Program counts over 20000 lines of machine code and progress is slow. REM audiodrivers use verry unplesand code with all kinds of irregular programming applied, counting selfcode modification, data buffers in code space, where code is executed and reused later as data memory ... I don't know who wrote audio, but I don't like him!

Im sorry, attachment CDune.zip

I posted minimum for building logo. Logo is still PRE-ALFA, but I finaly make it working on SDL. It displays final sprites with errors. I will debug and fix it soon, than I send first release. You need sdl with sdl prerequisities to run. You need legal logo.hnm file to run. Original assembly sources CAN'T be distributed of course. NOTE, code does not include assembly from original game or any assembly code for acceleration. Sources is pure standart C. Porting: With dummy port you may run logo even on toaster. scummvm port can be added if desired. PLEASE don't be narky in case you don't like it. Wait for first release. NOTE, logo was rewritten to work exactly as original. (Dumping bitmaps was added, msdos related command line paramer support was removed). Also remember that reversing process is much slower because I need figure out all knowledge befor I can write new code. I also NOTE that some parts recoded still looks horrible. After I finish debuging I will rewrite it to be nice C and add coments, it can be really soon. But now you can use it to study how original work and how video is processed (specialy bliting functions). Sources of several tools are available too (disassembler, unlzexe, hsq compressor, decompressor, binary image convertoor of executable ..., much bigger package). These are final, releasable

Big do you wont to share results? Do we can open new project on sourceforge.net or how can I share pakage obout 12MB? I can upload prealfa, (not finaly completed) logo writen in C (with no asm) running on SDL. It also dumps frames to bitmaps, I think good sprite dumper would be based on algos from logo because it contens rle decoding variants for both left and right row update direction and rle with color key (zero transparent pixel) and no color key. All this variants are used to extract sprites from logo.hnm. We will probably need some repository, where all work done can be accesibble and available.

Hello Monsieur OUXX I read your personal mail and scummvm thread. I'm not interesting about scummvm at all. Scummvm is nice library. At this stage of projesct I dont see much things to integrate into scummvm. My question is why to integrate dune to scummvm? What can I benefit from integration? I can benefit from is nice encapsulation or modularity of libarary. I'm trying to develop in ansi c (structured programming). I see no reason to design code in c++ (object oriented programming). I need no polymorphism, genericty even inheritance now! But it can change. I can't build scummvm-1.2.1 I used visual studio solution build files, problem is nasm. They are using visual studio toolchain and write assembly sources in nasm, not masm which is already included in vs? Even more asm optimized code is designed for most powerful platform pc, and not so less powerfull platform where it can more benefit in cpu load (arm have dsp instructions, instructions for paralel arithmetic, have aproximately doubled number of registers than intel and can do fast multiple load and stores ...). I thing object oriented design wast much more processing time than optimized asm can save (in comparison to structured c design built with optimization enabled). Present Intel have inough power to run game like dune, without asm optimalization. But main point of my design is small footprint, to run embedded platforms with minimal hardware requiremens as possible. What scumvm classes do? They rewrap and encapsulate code and data from other libraries. Why use mid-interface like this? If I need zlib, I use zlib. If I need flac, I use flac. If I need fmopl, I use fmopl. Portability Scummvm runs on SDL, other ports woud be added. But my program can run on SDL directly! Chip emulators I need fmopl to write adlib registers and make music (meed no midi). Emulation is already included in scummvm, but redesigned to c++, to be able to support midi. I dont need this. (They rewrite it to C++ and removed mame copyright) scummvm versus standart (original) libraries Do I need to investigate what they supported, changed, or removed from standart libraries? Sucumvm seems is under intensive design and reconstruction. They can remade or change everything. Do I need to investigate again and again what hapend. Documentation Interactive help would be very handy. I'm busy person and I won't waste my time to learn libraries from sources. Do I need to search complete package if i need some banality function? doc folder includes about 60kB. I better write my own package, which any body else can port to what ever platform/libraries he wont. Funny programming I'm rewriting cryos dune in free time. Until i have no running game, I wont to disturb nobody to integrate something to someting. In this stage i rewriting dune from assembly (or binary code) ansi c and structured programming is the best choice for me. If my package extends to much, probably i will rewrite all to c++ for better encapsulation or modularity. Only I wont to do now is share my results with forum. Some old programming technics woud be reused and is intereting to study them and bring back to life. This is my opinion, I can be wrong. Please, try do not disturb too much, I'm busy person. I read forum posts periodicaly at least per week. Sorry for eventual wrong english.

I can do it. I'm working on duneadl and duneagd drivers now. I would like to write music player/wave dumper. I'm using emulators for adlib (2-operator fm synth) and adlibgold (4-operator) chips from mame project (fmopl.c and ymf262.c) Audio rendering will be direct sound/wav writer. Stay tuned it will take more time.

BIG THANKS TO LAMPEL AND ZIF FOR PUBLICATION OF LZ ALGORITHM

Hello Several months passed. I think I solved mysteries around hsq. I discovered more info about compression on wiki [url=http://en.wikipedia.org/wiki/LZ77] http://en.wikipedia.org/wiki/LZ77 Our hsq is a kind of old well publishded Lampel Ziv algorithm. Methods like this are known as a dictionary coders. I found same algos in unlzexe for dos, I have to suspect it would be lampel ziv, to save work with compressor/encoder. Advanced encoders use KMP algorithm for pattern matching to work faster. I think, LZ77 encoding was very polular at end of past century. Hsq compressor already posted is using simple intuitive match-comparison method, which is slower than KMP. I hope I get some free time during christmass holiday. I would like to continue rewriting disassembled duneprg to C. Do you know that zip is improvement of this algorithm? (zip stores dictionary in huffman tree) Do you know that excelent lzma (7 zip) from Igor Pavlov is latest improvement of this type of compression? From time to time some body learned about this algo and wrote new one improved (most of them was/are popular and famous)

Hello segra I'm not responsible to work with ida db files (I'm lazy). If you can export data to any text format and send your results to me, you might be very helpfull.

Don't worry. I just want to ask which kind of enhancemets you are planning to make. I have only ideas what should be discuss. I'm new in 3d. I wont to know more about yours opinions. First task to solve is just rewriting game to C from assembly and make sources portable to be system independent. If some one wants to be helpfull and knows assembly/C language I may send him some pieces of code try to translate them. But it will take long time, so please wait. I have about 10% rewriten now, but not debugged even not tested.

3. More about music. I like Jescola Buzz Machine composer for electronic music. FSM Infector would be able accept parameters from adlib insdruments. These generated sounds can be proccesed in more advanced effects than adlib can do and you get better sound. Finaly music is exported to WAV. I'm mostly using OGG vorbis codec insted of WAV or MP3.

Sorry my english is not so good as yours. I had no choice I must study russian. But I'm trying to the best of my ability. I would like to ask your forum for your opinions. You all commonly tolking about game enhancements. I thing expansion of dialogs/story or remake to 3D would be nice idea. 1. What 3D engine do you plan to use for new dune? I'm thinking about unreal engine, but its comercial or licensed. OGRE is open source, free. 2. How can you create 3D graphics and animations? This job requires software 3D Studio Max or similar. But this software is comercial and is expensive (for me is very expensive). 3. Audio would be easy inough. Emulator for adlib/adlib gold OPL2/OPL3 exists in MAME project and source is free. This files are fmopl.c and ymf262.c. Music can be played original or do you want to remake music to? Thanks

Some questions. >I think you guys have spent several times longer reverse engineering this game than Cryo did building it Please tell me where I can found results? I must start dissassembly from scratch. >Yes, but having a full source code (instead of simply run the game inside DosBox) could allow... I need test assembled code if it works as expected. I'm doing it under dosbox. No disassembler produces perfect code which get build directly and work. Dissassembled code needs many fixes to get build and debuging to work properly. I mean my target is not dosbox. After that I will be able to convert it to higher level programming language. >No, development usually doesn't work like that. I don't plan developement. I simply wont to PORT/BUILD game for my embedded device, to be able to play the game. >It's more like "hmm, we need to make this thing show in something resembling 3D... let's see how we can do that!" Hnm player logo.exe is good start to try dissassembly. Its not to long. As I expected it shows most of knowledge related to graphics sprites/palettes. Now I see that it's posible to disassembly all the game. logo is using extraction similar to rlew, unhsq or direct copy, all varriants with or without color keying. All optimized for fast direct scrren videoram access. I garantee You can't figure out in other way which method to apply, whan apply and how apply without disassembly. Without disassembly no 1 would be able use or extract any data from original game, even write new one which using that! How can you do it without data extractor??? Oh, sorry. You may wont to play all the game and printscreen all pics. Or record music and sounds on microphone :-) Actualy I'm able to build new game completely from assembly sources (working and tested under dosbox!). But its over 20000 lines of pure machine code. It's realy very-very hard work to convert it to C or found code related to audio and video data storage formats. Most of graphics work (decompression, decoding) is proccessed in video drivers dune386 and dunevga. So finaly all game binaries and executables have to be dissassembled and understood how works together. You wont see results? I partialy converted logo to C, but still not complete. I coded hsq, unlzexe, disassembler, and binary convertors tools I nedded. I suppose assembly code is nonsharable, because of author rights. If you aren't perfect in assembly, it will end your life. I'm very busy now, I have no free time. But realy want to continue and success ... later.

Good, I read wiki pages. Formats are realy different. I think organization of game data is most based on "cryo" vesion 0. I will tell more after I disassembly duneprg.exe and I build new game executables from asm sources. I partialy rewriten logo.asm to logo.c, but I stoped it for a while. I'm focussed to duneprg now.

I Agree. Thanks. Maybe I will write new hnm player based on tricks and algos figured out from logo.exe and on docs available. If I get more time. I tested hsq compression. Works well for files about 1MB under win32. Under dosbox - imposible. Very long time no response ... If will you want to unpack large files (>64kB) with my tool hsq, you must break unhsq compatible header checking. Look for decompress function and replace line: if (isize != bitstream_p->ifsize) { with: if (isize != (bitstream_p->ifsize & 0x0000ffff)) {

Hello rymoah. Sorry, I forgot very important think. Unhsq tool allocates memory for unpacked data, after reading size of data from header. Size value storage is 2 bytes. It means unhsq is able unpack files with maximal size 65535 bytes. You also have to get message "unpacking ... done" or "unpacking ... failed" on your screen.

Hello rymoah Well, clear some mistakes now would be fair. >>>>I remember the old unhsq seemed to unpack all the hsq files contained in the game... and even the hnm videos Hnm (256 color, paletized) video files are not hsq packed. Its impossible to unpack them with unhsq tool. unhsq tool cannot success, because checks header (6 heading bytes). Remember unhsq code: char unpack2(byte *src, byte *dst) { byte *src2 = src, *dst2 = dst; if (((src[0] + src[1] + src[2] + src[3] + src[4] + src[5]) & 0xff) != 171) return 0; Header bytes has special meaning byte0 + (byte1 << 8) + (byte2 << 16) forms size of unpacked data (limited up to 16MB) byte3 + (byte4 << 8) forms size of packed data (limited up to 64kB) This means sum of 6 heading bytes must result 0xab => data are hsq packed. But some blocks of internal data would be hsq packed. There is special flag in high byte of image width (or height, I don't remember) signaling to apply unhsq method on current block. If you are interested about this old video format you may look wiki pages. I disassembled logo.exe (uses logo.hnm file). Logo.hnm start with first block size followed by palete data. Unhsq must always fail. Unhsq tool has several bugs which escalate to unpredictable results, memory corruption or tool colapse. Author generaly ignnores results of functions (nothing against him). for example: size = *((short *) src) ; dst = (byte *) malloc(size); ori_dst = dst; This code results in access violation (win32) during access to allocated memory, when requested memory is not available. This doesn't occure offten. >>>> Exactly, what do you mean by larger files ? unsigned short size = 0; fseek(f, 3, SEEK_SET); fread(&size, 2, 1, f); byte *data = (byte *) malloc(size); printf("source =%xn",data); fseek(f, 0, SEEK_SET); fread(data, size, 1, f); Functions fread and fwrite (win32, visual c compiler) fail allways, if you try to read/write large blocks (about 64k in size) or specialy whole file. Try it. Sorry if I'm impreccise, sorry my english is not good. I wish you succes.

Hello I can upload binary + source of hsq compressor/decompressor adapted for dos (working under dosbox) and precompiled binary for win32, if you are interested. Unfortunately I still have no much time to make more tool testing. This command line tool is simple to use: hsq -x infile outfile ... to extract packed file data hsq infile outfile ... to compress data If you enable selftest you would be able to extract hsq packed game data files. If you find some bugs, please let me to know. Your old source of unhsq tool seems doesn't proceess larger files under win32, my tool have to do. Actualy I'm disassembling duneprg - main executable. Keep a good work.

I wrote and attached c source of hsq (compression/decompression) utility. Enjoy archaic compression algorithm. hsq.zip

Hello I am sorry, I don't have a lot of free time now. Actualy I am programming hsq (compression) tool, but i still not finish. I also have to figure out how drivers works. I'll be back after some time with new uploads. I don't understand IDA disassembler. I'm using my dissassembler, which is able produce asm source. If somebody also trying disaasembly executables, have to be noticed that exe files are packed with lzexe (originated from Fabrice Bellard). You can see "LZ91" signature after ececutable header, so it's recomended to uncompress exe files before with unlzexe tool. I would like to continue after I get more free time. I attached unlzexe tool adapted for visualc/win32. unlzexe.zip

Do somebody have hsqpack routine or tool (source in c or c++) or have to be written? I disasembled duneadl, duneagd and dunesdb drivers and compiled again from new asm sources. I get same image as original drivers, I'm not afraid of than will not work correctly (or I will fix it). But I want to check to be sure and replace original drivers with new one. Problem is, that drivers have to be hsq-packed before testing. Thanks