@database CadOS history @node main "CadOS history" Project started on 10.1.96, to replace the ugly DEMO macro I normally used. Version 1.0 (20.1.96) - No 020 support. - Ran without checking 020, AGA, WB2 or PAL. - Didn't fix the sprite resolution. - Bug in display takeover. - Didn't shift VBR. - Disable and Enable, TakeoverScreen and RestoreScreen were all inline with the startup code. - Didn't ask user if it could run when started from icon - No memory tracking. - No MakeScreen, DisplayIFF, AllocBitmap, WriteClxCon, GenerateScroll, MakeCprBpl, or FindChunk. - Had SetColour, GetColour, SetColourRGB, GetColourRGB, SetColours, SetColoursRGB, GetColours, GetColoursRGB. But no FadeColours. - No internal vblank server - No debug support - Macros were: QUITDEMO, testlmb, testrmb, waitblit, waitvbl - No DOS support. - Not re-entrant. - Had lots of relocs. Bleah! - Only AllocChip8 existed, and FreeChip8 to free it. Version 1.1 (18.3.96) - Checked for 020 and AGA, and WB3 - Disable and Enable are now functions. - Added SetAutovec and SetTrap - Added various display functions - Removed all GetColour#? functions (They were useless :) - 1st docs written, not .guide format, though. - Added LoadFile, but it didn't decrunch things - Added memory tracking to AllocChip8. But, because I realised this memory tracking could be useful, I added an AllocMem and FreeMem for fastmem or chip-if-no-fast allocations. Version 1.2 (20.4.96) - Changed system functions to use 020 commands. - Split SetColours so it shared code with SetColoursRGB - Added get and getbase macros, and riddled CadOS code with them. - Ignored copying/restoring vbrtable, just copied it then moved vbr, so I could simply move vbr back during Enable. This also meant vbr would be in fast memory if possible, and it costs processor no extra time :) - Fixed wrong conditioncode in AllocMem (proceeded if memory WASN'T allocated :) - Rewrote the macro docs in new format. - Took the autodocs out of CadOS source and made man pages from them. - Turned CadOS docs into AmigaGuide - Made FreeMem generic to free either AllocChip8 memory or AllocMem - It will also support an AllocChip64k if I write one. - Changed LoadFile to support powerpacker, and also added SizeFile, DumpFile and SaveFile - removed data-cache disable and added FlushCache function On 15.5.96 after a blitter mistake caused MASSIVE damage to cados.asm file, I stopped writing CadOS for a while, also because I now did a lot of work on @{" Adamant " link ada}. The salvaged version of CadOS was next looked at 31.8.96 Needless to say I now make many backups of CadOS.asm !! Version 1.3ß (9.9.96) - Removed AllocChip8 - I discovered AmigaOS already allocates on 8-byte borders. You can blame @{" HowToCode7 " link the_utter_lie} for making me believe that the AmigaOS was unusable for 8-byte allocations!!! The What an utter panic they must have put the Amiga coding community into! - Fixed FreeMem bug (forgot to clear bit 31 of chipallocationsize, meant that I was freeing negative amounts of memory :) - Added SizeMem, and also fixed an AllocMem bug - Fixed SaveFile and DumpFile, I'd never tested them and when I finally did I found oodles of bugs! This shows the dangers of programming in assembler at night while drunk :) - Added SizeMem support to SaveFile and DumpFile. Also added another way to calculate the savesize to SaveFile. - Added XFD support to LoadFile. Thought about overlayed StoneCracker support, but said 'no' when I saw that it needed a variable safety margin, which could be any size. That margin would not be freed until the whole file was freed, so maybe 20k :) of memory would be wasted. I will continue to look at other overlayed-file decrunch libraries. - Splitted the DisplayIFF and MakeScreen into lots of seperate routines so the coder can create his pictures in any way he likes. Created FindChunk, UnpackIFF, AllocBitmap, MakeCprBpl, and MakeCopper. - Added a VBL interrupt. Also added a lot of timing support. - Added inital support for user-set variables in CadOS. - Whoops, forgot a and.w #31,d0 in SetColour#?, any pen >31 didn't write to a colour register, instead it wrote to $dff180+(d0*2). - Added saving, but not modifying, of adkcon. - Discovered that gb_LOFlist roughly equates to the most recent system copy of cop2lc, so now I save/restore this also. Version 1.3ß-asmone (25.10.96) - (Modifications to run under AsmOne by Vodka/Saturne) - completed registers name for all "movem" operations - replaced all "bset.b" by "bset" - replaced all "btst.b" by "btst" - removed "SP=3" line because of reserved word - some changes in "_SetColourRGB" Version 1.3 (2.2.97) - 1ST PUBLIC RELEASE - Changed "cados.asm" to "CadOS.asm" - Removed the equates and macros into another file - CadOS.i - Finished writing MakeCopper. - Added input section with ReadKey, CheckKey, GetMouse and SetMouseLimits. - Added error-handling, now reports where and why a demo crashed! - Added display and input autodocs and a CadOS_errors.guide - Now CadOS remembers screen colours, interrupts, DMA, autovectors and traps through a Enable-RestoreScreen-whatever-TakeoverScreen-Disable session. - Given up all hope of making this WB1.3 compatible (far too many 2.0 only calls) - Added NO_FILESYSTEM, NO_MESSAGES, NO_REQUEST - Added RemAutovec and ResetTrap to CadOS.system section. - Added CadOS.system/SystemRequest to do an EasyRequest, rewrote the startup code to use this. - PreDemo and PostDemo stuff actually works now. - Removed some (pc) relative code from some macros - had to add a seperate "getbasepc" as CadOS would have relocs otherwise! - added USEMAIN option. - Now uses keymap.library to provide a TranslateKey routine. - Made ReadKey realise the keyboard's reset and resend codes. - Added a quickie FlushKeyboard routine - Killed off all (most?) bugs in MakeCopper, MakeScreen and DisplayIFF. - Added CauseDelay routine, using the CIA-A timer A. - Removed one of the UnpackILBM bugs. - Extracted CadOS_FAQ.guide and CadOS_history.guide from CadOS.guide - Added some favourite bugs descriptions to CadOS_errors.guide - Arranged some crappy icons for the docs. - Wrote a few testsources for "the public". (shudder!) - Tweaked the old autodocs to have the same style as new ones. - CadOS is now over a year in the making! Happy birthday! @{" Click here " link future} to read my future plans for CadOS. @{" Click here " link bugs} to read the known bugs in CadOS. (Only one!) @endnode @node future "CadOS future" FUTURE DEVELOPMENTS In general, I'm aiming to make the OS not only great for programming demos but also I want to have a OS-product to use for creating Amiga _GAMES_. Admittedly, the Amiga's commercial games market is almost dead, but that doesn't mean people who own Amigas don't want games. That's why I want to add scroll-routines, bobs, sprites etc. - Too lazy to add this time round, MSF_DUALPLAY and MSF_HALFBRITE - Needs more example sources. I have plenty, but I'm too tired tonight to update them to work with CadOS. Expect rotzoom, wolf3d, shadebobs, plasma, vectors, glenz, star3d, dottunnel, dotscape, fontpainter, realtime corridor (a bit like the one in Sanity's Arte), some of those torus things and maybe some coppertricks. I'd also like to realise 8 bigbobs. I have a non-50Hz implementation, but I need to add some blitter and coppertricks to speed it up a lot more. - Instead of calling CadOS directly, have a library offset system to call CadOS. This would allow me to seperate the CadOS code from the actual demo, allow external code, and allow different implenetations of CadOS to all run the same, eg if a new version of CadOS was released to fix a bug, all CadOS demos could be fixed at once. Also, a trackdisk version of CadOS could be implemented, and in my total compatibility of AGA/ECS/OCS, the correct version of a routine could be set as a jump change at the beginning of setup, instead of deciding each time the routine is run. I could also call my CadOS a client-server model :) However, a normal version, compatible with CadOS 1.3, could be made just by using a switch. For coders who like CadOS the way it is, and don't want to recode their routines a third time :) Note I will also include a converter program written in Amiga E to convert source files from using bsr/jsrs to use librarybase instead, but it will be very unoptimised, eg replaces jsr _MakeScreen with move.l a6,-(sp) / move.l CadOS_lib_base,a6 / jsr _MakeScreen(a6) / move.l (sp)+,a6 for every CadOS call. - I'm geting very excited about the possibility of adding MMU MEMORY PROTECTION to CadOS. That would remove almost all bugs from democode. Børge Nøst sent me "enforcement.library", from which I believe I can writeprotect all memory that CadOS does not own. The only problem is testing - I have no local access to an 020MMU, 030, 040 or 060 based machine! - Allow shell options (what shell options? oh yeah, add shell options as well!) to be set from tooltypes also. - Auto-support for non AGA machines, in colour fades, causing 7 and 8 plane screens to fail, fallback on GenerateScroll and WriteClxCon, etc. Very difficult, but great if it's possible. I would always have a flag to not include this, and just have a full speed AGA version. - Saving the state of the CIA chips, and providing a few functions using these, such as serial data and timing. A bloke from England tells me it's possible! - DisplayIFF should be enhanced tenfold. Improvements include supporting the various mask formats, taking note of unimportant chunks (GRAB/SPRT/ DEST/CRNG/CCRT), supporting PROPs, LISTs and CATs, and supporting more screenmodes than HIRES/LORES LACE/UNLACE HAM/NOHAM. - Faster FadeColours/SetColoursRGB, _not_ calling SetColourRGB? - Create a MoveScreen (MakeScreen without new bitmap/copper allocation) - Non-15Khz support in MakeScreen? Easy, AHEM!!! - Internal chunkydraw (c2p, not chunkycopper)? (Would support Akiko) - Create a LoadSegment function for external code? - A general purpose blitting routine - any size bitmap to another. - Some maths support. Maybe a fast 3D wire/fill routine? @endnode @node bugs "Bugs in CadOS that are known" CIA TIMERS ARE NOT SAVED: CadOS currently makes no attempt to save the CIA registers. So some timing may be trashed on exit, but most systems can seem to cope with it. Still, this is a serious bug. @endnode