DB_BCON **************** ONLY for TOS 4.1 **************** A replacement for the console device in TOS4.1's Bconout routine. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Why replace TOS's BCONOUT routines, you ask? The answer is very simple. TOS 4.01 (often called 4.1) has three very annoying bugs- nothing terrible, mind you, but it does fail to emulate the very same VT52 codes that all other STs, STes and TTs have been quietly performing for all these years. Although one can easily live with these VT52 bugs, Murphy's Law dictates that the one program you need in an emergency will demand that the VT52 emulation is bug-free. This bconout replacement extends the compatibility of the Falcon and thereby reduces the "doesn't work on the Falcon" list. "DANGER, WILL ROBINSON, DANGER" Robby the robot While this program does its best to cure the VT52 emulation problems, it must access the TOS ROMs directly for one single ROM address. This address cannot be found with any reliability anywhere else; the inherent bconout routines themselves get this address directly from ROM. Normally, I would never distribute a ROM-specific program. Such programs have obvious shortcomings, namely: as soon as the ROMs are changed, the program becomes obsolete. Secondly, such programs are not of any use on any other ROM version. This bug-fix is for TOS 4.01 (Falcon TOS) only. There are already two (and maybe three) later versions of TOS4. I have not had the opportunity of investigating these later versions but do suspect that the bugs have been squashed by now. The trouble is, what about us TOS 4.01 users? Are we destined to live forever with these bugs? No. Here's the fix. "And remember... be careful out there." Sgt. Phil Esterhouse - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Wanted Dead or Alive (preferably dead) Ok, Ok. Just what are these bugs? 1) LINE WRAP bug. Although the codes for line wrap do work, TOS doesn't do it right. Well, more accurately, TOS forgets that it did it immediately after it does it (sort of like short-term memory loss). The result is a column of characters that scroll down the left side of the display. Even if you've had a speed-reading course, those characters go by just to dang-blasted fast to make any sense of. 2) CURSOR SAVE bug. (Esc j Esc k) These are a pair of functions to save the current cursor position (Esc j), and to restore the position (Esc k). Restore (Esc k) works just fine and dandy. Problem is... the Save function (Esc j) does not! The result is that the cursor is always restored to location 0,0 or the home position. TOS saves the cursor position to the wrong place and then it forgets where it saved it. 3) Color Change bug. (Esc b Esc c) These just plain didn't work, period! Neither the back- ground nor the foreground color can be changed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "So what's the cure, doctor?" DB_BCON is a TSR that replaces the console device driver in the bcon_out routines. It does this completely leagally (save for the previously mentioned ROM access). It places its own address in the bconout_vec in low memory using the standard XBRA vector replacement protocol. From that point on, it's installed. All three bugs are gone! It does NOT: o Check for rom type. o Check for MultiTos o Check for other bconout replacements. o Cure any problems that may exist in the "RAW Console" driver portion of TOS4. It DOES: * Fix all aforementioned bugs. * Check for machine type. * Leave a cookie in the cookie jar (DBbc). * Follow common-sense programming logic... (no secret tricks or toys) * Use an internal pointer for con_state, normally located in low memory. This prevents HiSoft's AMON or MON from resetting the new bconout driver. * Use XBRA protocol for vector replacement. * Add 4 additional codes: Esc s SAVE COLORS (both fwg&bkg) Esc r RESTORE COLORS (both fwg&bkg) Esc z RESET colors to B/W Esc X SET X position (similar to Esc Y but only one argument, X, is used) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Installation DB_BCON can be installed either from the desktop or placed in the AUTO folder and run automatically at powerup. During its initialization, it will look for a file by the name of db_bcon.DEF and if found will 'show' that file to the screen. This allows you to set TOS's colors at powerup... if you so desire. (note: if run from the AUTO folder, DB_BCON.DEF must reside in the root of your boot drive.) DB_BCON checks to see if it's already been installed and if so will not keep a second copy of itself in memory. It will, however, read the DB_BCON.DEF file as usual and then exit without a trace. DB_BCON _can_ install a second version of itself... if there's a need to. Hold down the key when DB_BCON starts up. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This code is not guaranteed for any other versions of TOS... it's not even guaranteed for TOS4.1 so "use with caution". 02/14/94 (with love) Bye: Dr. Bob ----------------------------------------------------------------- "Can you show me what it does?" SAMP_???.QQQ Three sample ascii text files are included; one for 16/256 color resolutions of 640x480, one for 320x200 and for True Color 320x480. They contain imbedded escape sequences to demonstrate the color functions, cursor save functions and the wrap function. SHOW them from the desktop *before* installing DB_BCON to see how plain they look and how the last example of line wrap scrolls the display. ("SHOW", you know... double-click on the file at the desktop and then select SHOW from the alert box... see, I knew you knew) THEN install DB_BCON and show them again. This time you'll be amazed! Colors galore, cursor save works and line wrap doesn't scroll on every single character. Spiffy! ----------------------------------------------------------------- Digressing Notes: (so indulge me a little bit ;-) What started this whole project was a spreadsheet called "Logistix" from Grafox in England. It's copyrighted 1985 and 1986. Yeah yeah, I know. Who would expect such and old program to be Falcon-compatible. Well, it is... almost. Everything runs along just fine except that the cursor is invisible. All cell calculation, macros, file saving and loading etc. etc. etc. work without a hitch. You just can't see the cursor (thank goodness that the cell location is referenced on the status line). Conversations on GEnie also mentioned the inability of the Falcon to change the text colors with VT52 codes. Although I had never had reason to use these VT52 commands in any application, I WANTED them. There _SUPPOSED_ to be there. Add to that the annoying wrap error on long text lines and it just became too much. I've got Atari's newest computer and hell if it's going to balk on me now! So out comes my favorite debugger, HiSoft's MON built into DevPac. I traced the BIOS trap and located the proper bconout routine (the console driver portion) and sat down to what I thought would be some intensive exploratory surgery (software-wise). The major portion of time was spent tracking all the little sub- routines called by the console driver. This was completed, oddly enough, in a single afternoon. (I must be getting better at this;-) What is curious is that all three bugs exist in that one small section of code. One is beyond doubt just a typo-error in the source code; the cursor-save function saves the x and y coordinates to the mouse pointer coordinates instead of the alpha cursor coordinates. The others are rather simple too. Line wrap increments the X coord- inate properly but when it decides that the line has to be wrapped, it mistakenly saves the Y coordinate instead of X (this too looks to have been a typo in the source code). Color changes were a bit trickier because of a few new 'undocumented' memory references and a puzzling piece of code that checks to see if there is MORE THAN 16 planes in the current resolution (I suppose that is so any future video resolutions will have an equal share of bugs in rom . Actually, one can't be sure of this bug's origin. it may have been a typo {BLE instead of BLT} or it could have been a programming error ...or... who knows for sure). Any questions may be directed to W.PARKS3 on GEnie (W. David Parks) 02/16/94 Bye(again): Dr. Bob