o General: The source-code of "Viewer4.4" is not public domain software. It's freeware. I, as the author of the source-code, will allow you to improve this source-code so long you don't remove MY copyright notice. If you have got improved "Viewer's" source-code, you have to place that modified source-code and the object-file of it into the pd-pool - also as freeware! The object-file of "Viewer4.4" may be enclosed to a commercial product - as a text or ILBM-viewer. The source-code of "Viewer4.4" may be also enclosed to any assembler package as an example, so long the copyright notice is unmodified. You, as an commercial dealer, or as a programmer of the above mentioned package, is it allowed to modify the source-code of "Viewer4.4" so that it can be assembled with your assembler - although I didn't used any specific advantage of the "HiSoft Devpac Amiga 3" assembler (preassembled include-files are a standard). Needless to say that I can't be held for any errors, lost of data, lost of profit or anything else may happen using "Viewer" as object- or source-file. o Known bugs: At the moment I don't know about any bug which will cause "Viewer" to crash. In fact, "Viewer" didn't crash my "A2000-B, ks 1.2, 68000 CPU, 512kB chip, 2 MB ranger RAM", "A500, ks 1.3, 68000 CPU, 1 MB chip, 1MB ranger RAM", nor my "A4000-D, ks 3.0, 68040 CPU, 2MB chip, 16MB fast". "Viewer4.4" was successfully tested with "SegTrecker", "Enforcer" and ""Mungwall". Remainder: If you want to improve "Viewer", test that modified file with the above named programs. A hint: An addressing mode like: movea.l _What(Ax),Ax cmpa.l 0.w,Ax beq _There .... will cause an Enforcer-hit - because it compares really the value of the address, here: contents of address zero. Although cmpa.l #0,Ax is allowed (no Enforcer hit), don't use it. Some assemblers optimise this code to cmpa.l 0.w,Ax which isn't allowed - so for your and my sake change the above to: tst.l _What(Ax) beq _There movea.l _What(Ax),Ax .... Shown bugs: Under ks 1.2 (v33) to beta ks 2.0 (v36) the border of the screen shows blank and not the picture's border. This is a bug in those kick-starts - the ignored flag: "SCREENQUIET" ( - don't display screen's title bar). Fonts taller than 15*10 are trashing the "Auto-Requester" window or leave it. X- and Y- aspect not really set when running above of ks 1.3. You can improve that on your own. o What is not implemented and what will never be done through me: I will not support IFF-anim-x formats because they are too slow when running high-resolutions and a lot of colours, e.g. 768*580 and 256 colours. Also 24-bit images dithering to 5/6/8 bit planes I will not support. AAA (RTG) resolutions - (if the Amiga is staying alive) - for such a small program like "Viewer" it's too much to look forward to AAA resolutions and the RTG-standard. 3rd party graphic devices are not supported directly; my speculations depend on the fact that a bitmap, which isn't a standard Amiga bitmap, is created through an alien software package and thus a graphic, layer and intuition emulation is running. Since all 3rd party graphic devices are originally from the IBM compatible PC I guess that it cannot support Overscan and other AMIGA specific stuff. This means also that no 8 bits per gun colour palette is in screens available, which are not 24 bits deep. "Viewer" will actually not care about this fact, which result in incorrect colours on that device since LoadRGB32() will not correct this on its own. The next problem is that the Amiga OS cannot handle 24 neither 16-bit bitmaps. This means that although "Viewer" will allocate a temporary bitmap with 24 bit planes, the higher 16 bit planes cannot be copied (blitted) to the visible 24 bit screen which was created through the graphic emulation since the Amiga OS functions (used by "Viewer") take only the first 8 bit planes into account. Currently a well-made graphic emulation is not available for the AMIGA although "CystGraph" will allow "Viewer" to display images on its screens (with a few limits). It's not possible to display super-bitmap screens on a "VanGogh96" display although the screen is taller than the displayable part (unsupported change of View^dx and View^dy). Any 3rd party software package to emulate the Amiga OS graphic functions should now work, but only if the monitor(s) are adapted by the system-functions. ASL-file-requester - no directory caching and - directories are shown at the bottom - thus I do not support it. o Talking about the source: - Take a look at the routine "_StrToLong" and you know that all numbers that are converted (string to number) can be over given in decimal, dual or hexadecimal - e.g. tool types. - The complete binary code of "Viewer3.B" can be holding resident in memory. If you are going to improve "Viewer" try and write it for resident use, too. -- Problems of current kickstarts (including 3.1): - Console device. The console-device output is so slow that it makes no difference if you are calling it from assembler or from ARexx! I hope that we get in the future a faster console output, otherwise I write my own (problem of Layers/Gfx-library). You can increase output's speed when you decrease the number of bit planes of the screen "Viewer" appears on to 1. If you know think that you only have to change RastPort's rp_Mask to %00000001 (1 bit plane), you'll get the wonder, output is not sped up, instead it flickers only harder (tested only in PAL-mode). If coloured texts are printed out to the console-window, the output speed is decreased again, approximately by 300%. The thing that helps in this case is only to reset the complete console-window - press therefore the "R"-key. The routine to enter the search string has been stripped. It now doesn't support cursor moving anymore. This is mainly because the code grew by this about 1.2 KB, - for a simple line editing routine!! With the original routine Viewer was more a text-editor than a viewer! The reason why the routine was so tall is because it fully supported tabs, which is a little difficult to handle. - Bug in v39 of dos-library. When a read/write error occurred and the Read/Write routines of the dos returned to the program-code, the base register A6 didn't contained the DOSBase any more - this bombed my A4000 a lot times! - Example: movea.l _DOSBase,A6 jsr _LVORead(A6) tst.l D0 bmi Error .... Error jsr _LVOIoErr(A6) ; Amiga bombed! - because A6 doesn't contains the pointer to the DOSBase! - Intuition gadgets. I would have used a normal intuition gadget with a border around it when there wasn't a bug in the Intuition- library: although you can change RastPort's rp_Mask to 3 (2 bit planes) before adding and displaying a gadget, all bit planes are used by intuition to draw the gadget - when now the screen has 8 colours (3 bit planes) and the GADGHCOMP-flag is set for the gadget, the selected gadget looks ugly - the only things which helps is to draw gadgets with the GadTools-library - but... GadTools is not available on ks 1.2 neither on 1.3 so I made it via images. - Message handling is not what it should be... Although you can tell intuition to stop sending messages to a message port (PA_IGNORE), it will ignore (like the flag tells) our wish. The message that has reached us got other in its back that will also be sent to us. Commodore has made a C-subroutine (see CloseWindowSafely) to ignore all soon coming messages - I didn't implement this in "Viewer" because each times this routine is called and ignores messages, the system will lose 40 bytes of memory. I did it via GetMsg() and ReplyMsg() - the same effect but no lost of memory. - FreeMem(). If you allocate memory with a size which is not divisible by eight (8) AllocMem() will round it up to a size of eight (maximal plus 7 bytes). When now FreeMem() is called the over given size is de-allocated - means it may happen that you lose maximal 7 bytes of memory - and that each time you call FreeMem(). It seems that allocating & freeing memory of FAST-RAM type works correctly - but not with chip-ram!!!! What occurs when this happens should be known by everybody - memory fragmentation through memory corps! To avoid this, aligned each size which should be allocated to eight and when this memory block should be freed, align the size again, example: move.l _FileSize,D0 move.l #MEMF_CLEAR,D1 addq.l #7,D0 andi.l #-8,D0 movea.l _SysBase,A6 jsr _LVOAllocMem(A6) move.l D0,_FileAddress beq Error ..... movea.l _FileAddress,A1 move.l _FileSize,D0 addq.l #7,D0 andi.l #-8,D0 movea.l _SysBase,A6 jsr _LVOFreeMem(A6) - Direct hardware access. The picture viewer of "Viewer" makes directly use of the hardware, but not for displaying the picture, instead of it for checking if a mouse button (right or left) is pressed or released. This can cause trouble under future (if there will be a future for the Amiga) versions of the custom-chip set. The routine which checks if a printer is turned on or off is also hardware coded, it works only well with "Epson" printers. - PowerPacker-library. Through PowerPacker-library packed files are supported, but I (will) remove(d) the de-crunch-code and replace(d) it through a PowerPacker-library call. - ILBM-files. Because it's close to impossible to detect if a colour-map ("CMAP") contains colours of 8-bits wide, the highest bit of BMHD->pad1 is set when the colour-map entries are valid 8-bits (newer programs set this bit), otherwise this bit is cleared. "Viewer" looks for this bit. When it is set, the colours are taken as 8-bit values for LoadRGB32() otherwise out of the high-nibble of each colour (upper four bits) the 8-bit value is computed - if the picture does not contain more than 32 colours - else I guess that it contains the right palette order but didn't set the BMAP->pad1 bit. - ASCII extraction _ANY_ IFF-file that contains the CHRS-chunk can be used as input for _LoadFCFile(). You have only to insert a line in _CheckFile() which compares the type of the file (currently only SWRT#### and FTXT#### are supported). - AUTO-requester The auto-requester can be easily extended (modified) for OS2.0 and up when using OS built in function: Intuition's EasyRequestArgs() - although this routine has got a bug: If the font used for the Requester is too tall to display it doesn't use an other, it will always use the one currently installed for the screen. This may result in non-click able gadgets and in non-readable messages. Same problem with ReqTools.library functions.... - CODE optimisations ViewerV4.4 has not been optimised in any case. After I got the idea it was immediately written down. Thus there is enough room to do it. Some general: If you study the execution time of a command such as "DBF" (DBRA) and you write your own cycle-peeker you'll get strange results. Did you know that a bloody boring "subq.w #1,Dx bcc.s "LABEL"" is much faster than a "DBF Dx,"LABEL"" (MC68040)? So, trial (and error) can result in much faster programs than studying execution times :-( - Dirty code Some parts of the source code I wrote are in a badly written code-style. My excuses at this point. Some functions / implementations were written late at night. With half open eyes it's hard to follow the guidelines... Also much code has been written after riding my motorbike at its and my limit. Because of this I lost during typing the pleasure for a clean source-code. Jörg van de Loo Hövel 15 47559 Kranenburg Germany