MILC logo

IndexVorigeVolgendeLeeg

SOLUTION FOR SOME DOS 2 & TURBO R PROBLEMS
Henrik Gilvad, 00-00-00


    
(Overgenomen uit Quasar 19)

SOLUTION FOR SOME DOS 2 & TURBO R PROBLEMS
==========================================

Written by Henrik G.

I often see programs & diskmagazines that have big problems
with DOS 2.20. We (the scandinavian -no finnish members-
usergroup) have also had some with our diskmag. and other
programs. In this text I will try to explain the source and the
solutions for some of them.

Problem 1: RAMsearch vs. DOS 2 pagecontrol conflict
---------------------------------------------------
The DOS 2.20 is mapped in 4 x 16k pages, the page selection is
done by writing a value from 0-3 to adr. #6000 in the slot that
the DOS cartridge is plugged in.
A few DOS 2 cartridges use using all of the area from
#4000-#7FFF but most only use #6000-#7FFF. (The Turbo R only
uses #7FF0 or so and it has 8 pages. 3 for DOS 2, 1 for DOS 1
and 4 for something yet to be found out.)

Some RAMsearch routines use a simple algorithm which look
somewhat like this one.

  Read old value
  Turn all bits
  Write this new value
  Read it again and turn all bits
  Compare this value to the original value
  (Write old value)

If the slot contains RAM then this routine will discover it.
But if the testaddress is in the DOS 2 pageselection area then
a 'random' (= uncertain) page will be selected. The next time a
piece of code in the DOS 2 ROM is called, it will probably not
be there and the computer hangs.

Possible solution 1: Write '00h' to the testadr. after each
test, and not the original value (unless it WAS RAM). The DOS
is always set back to page 0 by its own routines.

Solution 2: Read contents of address #40FF and write this value
to the testadress after testing. Adress #40FF contains the page
number in the DOS 2 ROM. (Even on Turbo R DOS 2.30.) This is
perhaps the best solution. The value should be from 0-3 if it
is a DOS slot.

I discovered this problem the first time with Dynamic Publisher
a few years ago, it uses the adr. #6000 as RAMtest address and
my DOS did not like that.


Problem 2: XBASIC vs. DOS
-------------------------
When Xbasic (in any of its many names) is installed in RAM then
an adress between #FCC9-#FD08 is set to #20 in order to tell
the basic CALL interpreter that there now is a CALL handler in
this slot. If you stop a program using XBASIC and then go to
DOS, the area from #4000-#7fff will often be overwritten. When
you return to Basic again and try to use a CALL statement, the
Basic interpreter will still believe that there is a CALL
handler in the RAM slot, but there isn't. The computer will
call some mad code and the computer hangs.

This problem is not restricted for XBASIC only but also for any
other Basic extension (like MIDIIO) that is loaded into RAM.

The solution is simple. Just clear the byte that tells Basic
where you installed a 'cartridge'. If you do not know which one
then use this formula:

10 AD=&HFCC9 + PS*16 + SS*4 + PA
20 POKE AD,0

PS is Primary slot for the RAM. (0-3)
SS is Secondary slot for the RAM. (0-3)
PA is the page number. 0 for #0000-#3fff, 1 for #4000-#7fff,
                       2 for #8000-#Bfff and 3 for #C000-FFFF

PA will always be 1 for machinecode extensions.

If you are using DOS 2 then make a litle DOS program that do
this trick and state this programname in the REBOOT.BAT.
REBOOT.BAT is called when ever CALL SYSTEM is used.


Problem 3: Dynamic Publisher and Turbo R
----------------------------------------
My original H.S.H. version of D.P. was very difficult to start
on the Turbo R in the beginning. First of all I had to get it
on my harddisk. "BDOSPROT.BIN" from Lars Hansen fixed that one.
(This program simulates the error on the floppy disk.) But then
some more problems occured, that had something to do with DOS
2.20 as written earlier. After changing the loader there were
some more problems, this was due to the DOS 2 Memorymapper
routines. MAP.COM was the solution to this one.

DO NOT use "MAP2.COM" when you want to run D.P.! Use MAP.COM
instead. The only difference between MAP and MAP2 is this:
MAP only changes the DOS 2 mapperroutines concerning #FD-#FF
MAP2 changes all 4 mapperroutines from #FC-#FF

D.P. is the only program having problems with MAP2.COM but if
you get some then just reboot and try MAP.COM. (It is a static
error, so if it works once it will also work later on.) A
program like EASE (from Philips/Operasoft) will not work good
with MAP but needs MAP2.

There is still 1 error with Dynamic on the Turbo R! Sometimes
it suddenly stops while loading but once it is loaded it works
fine. (I have no solutions for this problem yet.)


Problem 4: Turbo R super turbo mode vs. memorymapper
----------------------------------------------------
In the super turbo mode (LD A,#82; CALL #180) the Turbo R does
not have the normal number of mapperpages available. Some
programs are using a bad kind of logic when they examine the
mapper.

IF pages >  8 then Mapper = 256k
IF pages > 16 then Mapper = 512k

etc.

This will not do for the Turbo R since it is using 4 pages for
'FastROM'. Furthermore, the DOS 2 is using 2 pages which are
not 'disabled' like the 'FastROM'. This means that if a program
is using mapperpages which are not there, the result will be
always #FF. Remember also that you must never use the 2 DOS
RAMpages.

One of these programs is RAMCOPY.BIN that is used in MSX PAINT
4 (sorry Juan and Marco) and that is why the BRUSH type
commands are always drawing with white colour. (= #FF)

The solution for this specific program is to change CPU mode to
MEDIUM. (LD A,#81; CALL #180) Then RAMCOPY.BIN works fine. (If
it does not, use the 2 DOS 2 pages.)

Remember that this is ONLY for TURBO R. There are no problems
of this kind on other MSX's.

Since this problem was how to define the actual numbers of
mapperpages if have to prevent another fault.

Do not 'just' use a simple algorithm like the following to
decide the number of mapperpages.

FOR A=1 to 255
  test mapper page A for ram.
IF RAM then NEXT A
?"Number of pages =";A

This will overwrite at least 2 bytes in the DOS 2 ram area.
Therefore RESTORE the original contents of the adr. you test.

FOR A=1 to 255
  OldValue=peek(xx)
  test mapper page A
  poke xx,OldValue
IF ram then NEXT A
?"Number of pages =";A

This is also necessary if you do not have a 4Mbyte mapper
because then this algorithm will destroy 1 byte in mapper page
0. (mainly adr. #C000.)

If your program is to be used only on MSX DOS 2 then you should
consider to use the DOS 2 memorymapper manager functions, which
are easy to use.

That were all my experiences with DOS 2.20. I hope this can
help other programmers to avoid the problems I have had.

                                                H.G.

    

Index

Vorige

Volgende