-= B E G I N =- Date: Mon, 1 Jul 1996 13:21:22 -4 Comments: Authenticated sender is From: Robb Holmes Subject: Re: newbie's video problem I reported: > > I run Euphoria 1.4 programs in a DOS window under Windows 95. The > > first time EX runs, it forces the window to full-screen mode.... Robert Craig replied: > Yes, this is the behaviour that I see on win95 as well. I > think it happens the first time you run *any* DOS program - no?. I have > always assumed there was some setting in win95 to change this behaviour, > but I have not tried very hard to find it. Unfortunately I won't > be able to investigate it for a couple of days - maybe someone else on > this list has the answer already. I'll let you know if I find out more. In my experience, this is not typical of DOS windows under Windows 95. If set up (in the .pif file) to run in a window, they generally stay that way, unless a program requres a video mode that cannot be emulated in a window. A graphics viewer or an editor in 132-column mode will force the session to go full-screen, but the session usually returns to windowed mode when the program exits or switches back to 80x25. Since my first message on the subject, I have found that using i = graphics_mode(-1) forces the session to return to windowed mode. With my hardware, it does so in very unattractive manner, with a lot of flashing and flickering, unless it's preceded by use_vesa(1) Curiously, VIDEO_CONFIG shows no change in mode or any other paramters when GRAPHICS_MODE(-1) is invoked. I appreciate your responding to my question. ------- Robb Holmes holmesr@ilinks.net "Did God ever build a wall?" -- Duke Ellington Rude Interlude, a Duke Ellington home page: http://www.ilinks.net/~holmesr/duke. htm -= B E G I N =- Date: Mon, 1 Jul 1996 22:05:48 +0100 From: Marcel Kollenaar Subject: Run out of memory under WIN95 On June 28, Rob Craig answered: >[...] >I typed in this quick example of what you seem to be doing and it >ran ok for me under windows 3.1 with an 8Mb RAM machine. >It generated a 1.5 Mb "junk.dat" file. >I will try it later on a win95 machine. Maybe you can post some of >your code so we can see more precisely what you are doing. >[...] Rob, Thanks for the explanation and example code. Here follows some code of the program which ran out of memory at the moment it read in the entire list. EX was running in a DOS-box in WIN95. ----------- start of mycode ----------------------- -- 29/05/96 -- modified 01/07/96: translated -- small testprogram to examine the write time for print(fnum,list) -- for a given list with structure {{n,n},{n,n},{..,..}}. include sort.e include get.e include machine.e constant EXAMPLES = 100000 -- number of keys in list constant SCREEN = 1 -- standard output atom t0, t1 -- time sequence list -- list of numbers integer fnum -- file handle number --with trace --trace(1) -- create empty list list = {} -- fill the list with random numbers puts(SCREEN,"Fill the list with random numbers.\n") t0 = time() for i = 1 to EXAMPLES do list = append(list,{rand(1000000),i}) -- structure {{n,n},{n,n}} end for t1 = time() printf(SCREEN,"Time to create the list: %f\n",t1-t0) -- sort the list on key-field puts(SCREEN,"Sorting.\n") t0 = time() list = sort(list) t1 = time() printf(SCREEN,"Sorting time: %f\n",t1-t0) -- write list to file in structure {{...},{...}} puts(SCREEN,"Writing the list to file list.ind.\n") fnum = open("list.ind","wb") t0 = time() print(fnum,list) t1 = time() printf(SCREEN,"Writing time: %f\n",t1-t0) close(fnum) -- make the list empty list = {} -- Read the list from disk puts(SCREEN,"Read the list from disk.\n") fnum = open("list.ind","rb") t0 = time() list = get(fnum) t1 = time() printf(SCREEN,"Time to read the list: %f\n",t1-t0) close(fnum) ------------- end of mycode -------------------- To overcome temporary the problem: I've changed the MS-DOS "settings" (I don't know how it is called in English because I've a Dutch version) to "Pure MS-DOS", WIN95 is closed and all what remains is good old 'new-95-MS-DOS'. The program runs fine and at EXIT Windows starts all over again. To get the same possibility as DOS/Windows 3.11 I changed in the hidden systemfile MSDOS.SYS the parameter BootGUI = 1 to BootGUI = 0 so WIN95 wil not start up and will stop after loading AUTOEXEC.BAT. Be careful, MSDOS.SYS attribs must remain RHS after editing. If you want to go to Windows type "WIN". Regards, Marcel Kollenaar -= B E G I N =- Date: Tue, 2 Jul 1996 11:23:09 +0100 From: Marcel Kollenaar Subject: Re: Interface to DOS info Hi John, You wrote: > I would like to collect a bit of info about the DOS machines:I can get > the DOS version, hard drive size, amount of conventional memory > by using interrupts. From contents on the hard drive I can determine the > existence of Win31. I can not find anyway to determine > > extended memory size > Processor > processor speed > Manufacturer > Model Marcel said: What I can do is give you a search vector. I found some Pascal code which is a part of SWAG (Sourceware Archival Group). You can get the SWAG program library from any good BBS. I hope you are familiar with Pascal so you can translate the code. But I must warn you, a lot of this code is machine code. Here follows some Pascal code for detecting XMS/EMS. After that code follows some information how to get the EMS/EXM amount from de CMOS setup ram. What I learned from the Pascal code: it is difficult to determine how fast the CPU is running. It is all on empirical base. Good luck, Marcel Kollenaar -= B E G I N =- BBS: Canada Remote Systems Date: 06-12-93 (09:36) Number: 26301 From: CHRIS JANTZEN Refer#: NONE To: WILLIAM SITCH Recvd: NO Subj: RE: DETECTING EMS/XMS Conf: (1221) F-PASCAL ---------------------------------------------------------------------- ----- On Thursday June 10 1993, William Sitch wrote to All: WS> Does anyone know how to detect XMS/EMS? I've used something documented in WS> my PC INTERRUPTS book, but I can't seem to get it to work. The following code was *mostly* right. Go back to your original source to compare the changes I made: procedure check_ems (VAR installed:boolean; VAR ver,ver2:byte); var regs : registers; begin regs.ax := $46; intr($67,regs); installed := regs.ah = $00; if (installed = true) then begin ver := hi(regs.al); ver2 := lo(regs.al); end; end; procedure check_xms (VAR installed:boolean; VAR ver,ver2:byte); var regs : registers; begin regs.ax := $4300; intr($2F,regs); installed := regs.al = $80; if (installed = true) then begin regs.ax := $4310; regs.ah := $00; intr($2F,regs); ver := regs.ax; ver2 := regs.bx; end; end; WS> I am pretty sure I'm calling the interrupts right, but it always returns WS> false, indicating that I do NOT have EMS/XMS, although I do. Can anyone WS> help me out? You were. Mostly. What you forgot was that when a real world book like PC Interrupts says "Load the AX register with the value 4300h", it means to us Pascal programmers "Load the AX variable with the value $4300". Note the dollar sign. That means hexadecimal (like the little h on the end means hexadecimal to assembly programmers). Chris KB7RNL =-> --- GoldED 2.41 * Origin: SlugPoint * Coos Bay, OR USA (1:356/18.2) ********** next code for looking at CMOS information ********** { >I heard many times about people talking about CMOS password ? >Is it a password that comes with the hardware ??? > I'll try to make a long story short. One of the crucial parts of the PC is the MC146818 RTC chip. Although this primarily is a real time clock, it also contains 64 bytes of RAM, which conveniently are buffered by a battery or an accu, so they keep the volatile info even when you turn the PC off (at least as long the battery hasn't turned into fluid :-) All the setup options of the BIOS are stored in those 64 bytes. Modern BIOSes usually allow to have a password option set for either at every booting or just when entering the setup. Below you find the standard CMOS layout as it was defined by IBM. AMI, Phoenix and others have added some options called "Advanced Setup" and used the bytes which are marked reserved here. Somewhere in this reserved range the password gets stored. Maybe there are PCs with some other RTC chip with more RAM, but at least around here even the latest buys still carry this old but worthy chip. From: skolnik@kapsch.co.at (Gerhard Skolnik) +--------------------------------------------------------------------- -+ a CMOS Storage Layout more a +--------------------------------------------------------------------- -+ 00H-0dH used by real-time clock 0eH POST diagnostics status byte 0fH shutdown status byte 10H diskette drive type -----+ 11H reserved a 12H hard disk drive type a 13H reserved a- checksum-protected 14H equipment byte a configuration record (10H- 20H) 15H-16H Base memory size a 17H-18H extended memory above 1M a 19H hard disk 1 type (if > 15) a 1aH hard disk 2 type (if > 15) a 1bH-2dH reserved -----+ 2eH-2fH storage for checksum of CMOS addresses 10H through 20H 30H-31H extended memory above 1M 32H current century in BCD (eg, 19H) 33H miscellaneous info. 34H-3fH reserved +----------------+ aUsing CMOS Data a +----------------+ To read a byte from CMOS, do an OUT 70H,addr; followed by IN 71H. To write a byte to CMOS, do an OUT 70H,addr; followed by OUT 71H,value. Example: ;------- read what type of hard disk is installed mov al,12H out 70H,al ;select CMOS address 12H jmp $+2 ;this forces a slight delay to settle things in al,71H ;AL now has drive type (0-15) } -= B E G I N =- Date: Tue, 2 Jul 1996 19:25:09 EDT From: Robert Craig <72614.1667@COMPUSERVE.COM> Subject: Re: Run out of memory under WIN95 On July 1, Marcel Kollenaar wrote: > Here follows some code of the program which ran out of memory at > the moment it read in the entire list. EX was running in a DOS-box in > WIN95. I ran your program on a 24Mb win95 machine in a DOS box. It worked fine. The disk was quiet (not swapping). The mem command showed 23Mb of free extended memory. I then ran it on an 8Mb win 3.11 machine under "pure" DOS. It worked ok there too. I then tried it in a DOS box on the same 8Mb win 3.11 machine. During the sort it started swapping intensely and after half an hour I gave up and hit control-alt-delete. When a program repeatedly steps through a large sequence that won't all fit into memory the "least-recently-used" algorithm for virtual memory breaks down badly. The program ends up reading the disk every time for each chunk of the sequence that it needs. It never has the required data in memory because, for example, the first part of the sequence has always been swapped out by the time it finishes the last part and is ready to start over again. Regards, Rob Craig Rapid Deployment Software -= B E G I N =- Date: Wed, 3 Jul 1996 10:05:20 +0100 From: Marcel Kollenaar Subject: Re: Run out of memory under WIN95 Robert wrote, > I ran your program on a 24Mb win95 machine in a DOS box. > It worked fine. The disk was quiet (not swapping). The mem command showed > 23Mb of free extended memory. > > I then ran it on an 8Mb win 3.11 machine under "pure" DOS. > It worked ok there too. For the time being I will work under "pure" WIN95-DOS. > I then tried it in a DOS box on the same 8Mb win 3.11 machine. > During the sort it started swapping intensely and after half an hour I gave > up and hit control-alt-delete. When a program repeatedly steps through a large > sequence that won't all fit into memory the "least-recently-used" > algorithm for virtual memory breaks down badly. The program ends up > reading the disk every time for each chunk of the sequence that it needs. It > never has the required data in memory because, for example, the first part > of the sequence has always been swapped out by the time it finishes > the last part and is ready to start over again. Robert, I'll change the code (takes some time) to break up the large sequence in more manageable parts (eg. 20,000 items or less), shellsort each part, put them on disk and end up with a mergesort also in small parts on disk, with an index on the index. Maybe that someone who reads this has an better idee. Thanks for your help. Marcel Kollenaar -= B E G I N =- Date: Sun, 7 Jul 1996 20:17:00 GMT From: Angelo Pesce Subject: On-line Assembler Do you have exadecimal assembler op-codes for use with euphoria? ------------------------------ ANGELO KEN PESCE us008@uniserv.uniplan.it ken@uniserv.uniplan.it -= B E G I N =- Date: Thu, 18 Jul 1996 22:47:43 EDT From: Robert Craig <72614.1667@COMPUSERVE.COM> Subject: Euphoria 1.4a I'd like to welcome several new people who have signed up to the Euphoria mailing list recently. The last time I issued a "review euphoria" command there were 26 people on the list. I expect this number will grow significantly as EUPHOR14.ZIP gets into wider circulation. We recently announced Euphoria version 1.4 'a' on the WEB page. It has a new library routine called crash_message() plus a bunch of fairly minor improvements and bug fixes. For more details see the WEB page, or RELNOTES.DOC in the .ZIP file. Anyone who has the v1.4 Complete Edition can download the 1.4a Complete Edition for free - just send e-mail to RDS and we'll give you the downloading instructions. A few more Euphoria example programs were added yesterday to the WEB page. They're bundled as "goodies.zip". If you have ideas for improving Euphoria, or if you are stuck on a problem, feel free to post a message to this mailing list. Regards, Rob Craig Rapid Deployment Software