Post by thread:new MPASM features

Hello everyone, I have ftp'ed the MPASM version 1.21 from rasi.lr.ttu.ee (that is much faster than ftp.ultranet.com) and it is working fine with my asm-files. But in a readme-file there were some special variables mentioned like __MAXRAM or __BADRAM. I have found similar variables in the different PIC variable initialization files, but the included documentation (I think it is named usrguide.txt) doesn't mention this new feature anywhere. It seems that the document has not been updated yet. Who can point me towards a description of these 'system variables', please, or post a documentation? BTW, I still prefer the DOS-version of MPASM. But it only uses the 80x25 character resolution and does not switch back to my preferred 100x40 screen resolution which is based on the 800x600 graphics res. and provided by most ET4000 graphic adapters. Siggi Siegfried Grob, | student of electrical engineering, | university of ulm, germany | e-mail: spam_OUTsiegfried.grobTakeThisOuTstudent.uni-ulm.de | tel&fax: +49 731 25148 | --------------------------------------------------'

> I have ftp'ed the MPASM version 1.21 from rasi.lr.ttu.ee (that is much faster > than ftp.ultranet.com) and it is working fine with my asm-files. > But in a readme-file there were some special variables mentioned like > __MAXRAM or __BADRAM. I have found similar variables in the different PIC > variable initialization files, but the included documentation (I think it is > named usrguide.txt) doesn't mention this new feature anywhere. It seems that > the document has not been updated yet. > > Who can point me towards a description of these 'system variables', please, or > post a documentation? They were documented in README.1ST from ASM12100.ZIP when I downloaded it from MCHIPBBS. The USRGUIDE.TXT in there did not mention them yet. > BTW, I still prefer the DOS-version of MPASM. But it only uses the 80x25 > character resolution and does not switch back to my preferred 100x40 screen > resolution which is based on the 800x600 graphics res. and provided by most > ET4000 graphic adapters. Agreed! I have a 132x25 mode which is perfect for viewing listings output from the assembler, but MPASM insists on switching to 80x25, and does not switch back. I suspect this means it would not work if I redirected the console (CTTY?) to a serial port, etc. Microchip! Please give an option for no-mode-switching standard output from MPASM! > Siggi Peter F. Klammer, Racom Systems Inc. .....PKlammerKILLspam@spam@ACM.Org 6080 Greenwood Plaza Boulevard (303)773-7411 Englewood, CO 80111 FAX:(303)771-4708

> > > I have ftp'ed the MPASM version 1.21 from rasi.lr.ttu.ee (that is much faster > > than ftp.ultranet.com) and it is working fine with my asm-files. > > But in a readme-file there were some special variables mentioned like > > __MAXRAM or __BADRAM. I have found similar variables in the different PIC > > variable initialization files, but the included documentation (I think it is > > named usrguide.txt) doesn't mention this new feature anywhere. It seems that > > the document has not been updated yet. > > > > Who can point me towards a description of these 'system variables', please, or {Quote hidden}> > post a documentation? > > They were documented in README.1ST from ASM12100.ZIP when I downloaded it > from MCHIPBBS. The USRGUIDE.TXT in there did not mention them yet. > > > BTW, I still prefer the DOS-version of MPASM. But it only uses the 80x25 > > character resolution and does not switch back to my preferred 100x40 screen > > resolution which is based on the 800x600 graphics res. and provided by most > > ET4000 graphic adapters. > > Agreed! I have a 132x25 mode which is perfect for viewing listings output > from the assembler, but MPASM insists on switching to 80x25, and does not > switch back. I suspect this means it would not work if I redirected the > console (CTTY?) to a serial port, etc. Microchip! Please give an option > for no-mode-switching standard output from MPASM! Yes!!! Those silly buggers at bytecraft must believe that everyone uses the 'menu-interface' of the assembler; I just want to run the assembler directly from my editor (which doesn't like mode changes in its DOS shell) or from make (in which case my screen is blanked and reset to 80x25). This way of forcing one's own preferences down the throat of users seems to come mainly from the example that turbo pascal set back in 1985. Frank "Mutual respect, even if we disagree." ------------------------------------------------------------------------ Frank A. Vorstenbosch +31-(70)-355 5241 falstaffKILLspamxs4all.nl

In message <.....199510190934.KAA14933KILLspam.....listserv.rl.ac.uk>, EraseMEfalstaffspam_OUTTakeThisOuTxs4all.nl writes : >Those silly buggers at bytecraft must believe that everyone uses the >'menu-interface' of the assembler; I just want to run the assembler >directly from my editor (which doesn't like mode changes in its DOS >shell) or from make (in which case my screen is blanked and reset to >80x25). I'm glad I'm not the only person who finds this _really_ annoying. I don't expect command line utilities (which is how _I_ use the assembler) to mess around with the video settings. It doesn't _need_ to do anything fancy. As a compromise, there should be a /NOVIDEO (or somesuch) option so that those of us with build scripts and extended video modes can work without this getting in the way. It can't be that difficult to add an option for this. Please! Dave.

In message <199510190934.KAA14933spam_OUTlistserv.rl.ac.uk>, @spam@falstaffKILLspamxs4all.nl writes : >Those silly buggers at bytecraft must believe that everyone uses the >'menu-interface' of the assembler; I just want to run the assembler >directly from my editor (which doesn't like mode changes in its DOS >shell) or from make (in which case my screen is blanked and reset to >80x25). I'm glad I'm not the only person who finds this _really_ annoying. I don't expect command line utilities (which is how _I_ use the assembler) to mess around with the video settings. It doesn't _need_ to do anything fancy. As a compromise, there should be a /NOVIDEO (or somesuch) option so that those of us with build scripts and extended video modes can work without this getting in the way. It can't be that difficult to add an option for this. Please! Dave.

> Those silly buggers at bytecraft must believe that everyone uses the > 'menu-interface' of the assembler; I just want to run the assembler > directly from my editor (which doesn't like mode changes in its DOS > shell) or from make (in which case my screen is blanked and reset to > 80x25). I'm confused. I use MPASM 1.21 from the DOS command line because I don't like the menu (e.g. C> MPASM mysrc ) and it doesn't affect my 80x50 display at all. What am I missing here? Works fine from the editor DOS shell, too. MPSIM on the other hand does change the display to 80x25. And just to show how dumb it is, it does it when it exits, so it isn't even necessary. It would be much nicer if it would use all 50 lines! Peter -- KILLspampeterjKILLspamnetcom.com URL: http://mall.turnpike.net/~jc/ Stereograms - Shareware - Amateur Radio - WWW Camera Map - Delphi Mysteries

> > Those silly buggers at bytecraft must believe that everyone uses the > > 'menu-interface' of the assembler; I just want to run the assembler > > directly from my editor (which doesn't like mode changes in its DOS > > shell) or from make (in which case my screen is blanked and reset to > > 80x25). > > I'm confused. I use MPASM 1.21 from the DOS command line because I > don't like the menu (e.g. C> MPASM mysrc ) and it doesn't affect my > 80x50 display at all. What am I missing here? Works fine from the > editor DOS shell, too. > > MPSIM on the other hand does change the display to 80x25. And just > to show how dumb it is, it does it when it exits, so it isn't even > necessary. It would be much nicer if it would use all 50 lines! I have a little 48-byte .COM file I wrote which may be of help. When run the first time, it disables all calls to INT 10h; when run a second time, it re-enables them. Rather than executing as a TSR, it (blindly) assumes that the user vectors at 1F0-1F4 [inclusive] will be available for its use; it uses 1F0-1F3 to store the old INT 10h vector and 1F4 to store a 0CFh instruction [IRET]. If anyone is interested, I could uuencode it and put it up here (I know, no binaries here, but this one would be less than four lines long...)

I truly agree for a couple of reasons. One can send the output to a file, if desired, to process by some other unrelated utility. It is also possible to do other non-standard things with the output such as run it to a speech synthesizer. Those of us who are blind appreciate software that can produce standard output because it is much easier to make it work right for us than programs that only write to the screen buffer. This feature should not be much trouble to implement because somebody had to reinvent output to write directly to the screen so why not make it possible to divert that output to standard output if desired. a flag to switch between direct screen writes or BIOS should make everybody happy. I do not yet have a programming setup for PIC's, but I have plaid around with the Motorola 68HC11 whose free assembler totally uses standard I/O and I have no trouble at all with it. In message <RemoveMEm0t5ob8-0000nNCTakeThisOuTdc.cis.okstate.edu>, PETE KLAMMER writes: >I have a 132x25 mode which is perfect for viewing listings output >from the assembler, but MPASM insists on switching to 80x25, and does not >switch back. I suspect this means it would not work if I redirected the >console (CTTY?) to a serial port, etc. Microchip! Please give an option >for no-mode-switching standard output from MPASM! Martin McCormick WB5AGZ Stillwater, OK 36.7N97.4W OSU Center for Computing and Information Services Data Communications Group