Newsgroups: comp.sys.apple2.programmer Path: news.uiowa.edu!uunet!in1.uu.net!comp.vuw.ac.nz!actrix.gen.nz!dempson From: dempson@atlantis.actrix.gen.nz (David Empson) Subject: Re: Shell-based uudecode Message-ID: Sender: news@actrix.gen.nz (News Administrator) Organization: Actrix Information Exchange Date: Wed, 29 Mar 1995 13:33:57 GMT References: <3kg24a$292@lastactionhero.rs.itd.umich.edu> <3kr4kg$g2c@paris.ics.uci.edu> <3kvnah$i6j@lastactionhero.rs.itd.umich.edu> <3l7cna$d6l@gap.cco.caltech.edu> X-Nntp-Posting-Host: atlantis.actrix.gen.nz Lines: 81 In article <3l7cna$d6l@gap.cco.caltech.edu>, Nathan Mates wrote: > In article <3kvnah$i6j@lastactionhero.rs.itd.umich.edu>, > Sean McAfee wrote: > >Unfortunately, I don't have the GS/OS reference manual, so I don't know how > >to determine the size of a file without actually reading it all in. I've > >looked at some of the appropriate header files, but haven't been able to > >make much of them. > > As others have said, you can use C lib calls. If you don't have C, > bug me, and I'll type up the right call from my GS/OS manual. Or me, or many others here. If you have a programming question, let us know! Someone is bound to come up with a useful reply. > >Coming up with an efficient assembly algorithm was quite a chore, but I > >eventually came up with one that looks promising. Two problems: 1) > >Since I want to shift only the low-order byte of the accumulator, the > >code rapidly switches the computer between native and emulation mode. > >Is this a Bad Thing? 2) It crashes, and I can't figure out why. Ouch! Switching to emulation mode is a VERY bad thing to be doing, unless you really have to. > You should be able to switch modes as fast as you want and not hurt > anything. But, there are some things to watch out for. 1) The stack > pointer is 8-bit in emulation mode, and 16-bit in native mode. Make > sure you save and restore it if you're going to be goind a lot of it. > 2) GS/OS stuff (especially mostly C stuff) starts off in native mode; > make sure you end up in it. In addition, you MUST NOT run in emulation mode outside bank zero, unless interrupts are disabled. If an interrupt occurs in emulation mode, the program bank is not saved, so the RTI will return to the wrong bank (0). A native mode interrupt/RTI will save and restore the program bank. There is no good reason to use emulation mode in native mode code, except when calling emulation mode code (e.g. the serial firmware or routines in the monitor) and that is what the FWEntry call is provided for. As Nathan said, what you should be doing is switching the size of the accumulator and/or index registers, using the REP and SEP instructions (you will then stay in native mode). ORCA/M provides macros for doing this easily. In ORCA/C's inline assembler, you cannot easily use 8-bit modes, because it assumes all immediate instructions have 16-bit operands. As long as you can avoid immediate 8-bit instructions, you can just use the following: sep #0x20 set 8-bit accumulator and memory sep #0x10 set 8-bit X and Y sep #0x30 set 8-bit A, X, Y and memory rep #0x20 set 16-bit accumulator and memory rep #0x10 set 16-bit X and Y rep #0x30 set 16-bit A, X, Y and memory The "memory" in the above descriptions refers to read/modify/write instructions (INC, DEC, ASL, etc.) If you switch the index registers to 8-bit mode, the high order byte will be clear when they are returned to 16-bit mode. The high byte of the accumulator is preserved when switching to 8-bit mode and back (using XBA will swap the high and low bytes, in either mode). Also note that transfers between A and X/Y are set by the size of the destination register: TAX/TAY with 8-bit A and 16-bit X/Y will transfer both bytes of the accumulator. TYA/TXA with 8-bit X and 16-bit A will set the high byte of A to zero. Unless you are doing a lot of consecutive 8-bit operations, 8-bit mode is really only necessary when writing to a byte-sized variable or I/O location. (You should also use an 8-bit access to read an I/O location.) -- David Empson dempson@actrix.gen.nz Snail mail: P.O. Box 27-103, Wellington, New Zealand