Nestor Soriano wrote:
> What about assembling in a Turbo-R with external memory mapper? It is
> currently a very slow process, will it also be improved?
External slot access is always slower on a TurboR so you'ld have to
change the TurboR internally (Start soldering and replacing the S1990).
Also some mappers (like the checkmark ones ) can not handle 7 MHz and if
used as an extra ram expansion you will always have to switch to 3.5 MHz
Z80 are a data in the mapper gets corrupted.
> Also, it would be VERY nice if you add the following options for Z80
> assembling:
>
> - Automatically change JRs into JPs when overflow.
Nope.
Jon,Wouter and I had that discussion already a long time ago.
It is indeed I nice option, and a higher language compiler should do so,
but here you are already at the lowest level of programming. You can't
get any closer to the CPU (in human readable form that is)
Automating this would take away the 'full control' the programmers
probably wants at this stage. Also it would make it way more difficult
to write self-modifying code.
If a block of code is to long for a JR then perhaps you want to
rearrange other parts of he code as well (the 256 byte ranges speed u on
the TurboR spring to mind.)
> - Automatically change JPs into JRs when possible.
Besides JR are slower then JP so demo coders will not like it.And again
a self modifying code who changes JR is much more complicated then the
JP variant.
David Heremans
--
.--.
|o_o | In the beginning the Universe was created.
|:_/ | This has made a lot of people very angry
// \ \ and been widely regarded as a bad move.
(| | )
/'\_ _/`\ (Taken from THHGTTG)
\___)=(___/
****
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
****
