Re: News from the CTNG lab :-)
Hello, > So I guess I will do it the easy way, and just introduce a new mnemonic > 'JRR'.. or is 'JR16' better? since there is also 24bit JR 'JR24' ? A easier solution: create a .Z380 directive (or something). If Z380 'mode' is enabled, then compile the JR as 16bits relative jumps. Otherwise 8bit relative jumps are used. Un saludo, Jose Angel Morente ([EMAIL PROTECTED]) ([EMAIL PROTECTED]) *MSX DREAMS* ([EMAIL PROTECTED]) ¡Suscríbete a HispaMSX! http://www.egroups.com/group/hispamsx [EMAIL PROTECTED] msxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsxmsx Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: News from the CTNG lab :-)
Em qua, 13 set 2000, Jon De Schrijder escreveu: > The good news: the new IDEFDISK 3.1 program is completely finished; the > TurboR bootproblem with the new type of bootsector was fixed. Now you > can add/kill variable-sized partitions like you wish, even FAT16 > partitions. Works great with the newest IDE bios 2.01 and Okei's FAT16 > driver. I will take the programs with me to Bussum, but probably it will > also be available at Sunrise. Cool! Any news about the FAT 16 SCSI driver? byE! -- Ricardo Jurczyk Pinheiro - M. Sc. Numerical Modelling - [EMAIL PROTECTED] - 3635907 [EMAIL PROTECTED] - ABUB, MSX, Linux, Gospel... More? Ask me! Sola Scriptura - Sola Gratia - Sola Fide - Solo Christi - Soli Deo Gloria I used to have a life. Now I have windows 3.1 Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: News from the CTNG lab :-)
--- Nestor Soriano <[EMAIL PROTECTED]> wrote: > > Afaik the Z380 uses special instructions (Decoder Directives) to > indicate > > which ranges are to be used. They all start with DDIR. > > But JR is an exception. There are different opcodes for 8 bit JR and > for 16 bit JR. Isn't that accounted for in the Z380 mnemonics??? Strange... > > And which to > > 'compile' by default depends on the mode the Z380 is currently on > (in > > extended memory mode 24-bit JR's and 32-bit JP's are default, if > I'm not > > mistaking). > > Are you sure? I did not read anything about this in the Z380 manual. > The > use of 8 or 16 bit JRs depends on the opcode used. And the use of 16, > 24 > or 32 bit JPs depends on the preceding DDIR decoder directive. But of > course, don't try a 24 or 32 bit JP in native mode because only the > low > 16 bit of the jump address will be used, and the rest will be > ignored. How can you jump 24-bit when in native mode??? ~Grauw = -- ><< email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ ><< __ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: News from the CTNG lab :-)
> Afaik the Z380 uses special instructions (Decoder Directives) to indicate > which ranges are to be used. They all start with DDIR. But JR is an exception. There are different opcodes for 8 bit JR and for 16 bit JR. > And which to > 'compile' by default depends on the mode the Z380 is currently on (in > extended memory mode 24-bit JR's and 32-bit JP's are default, if I'm not > mistaking). Are you sure? I did not read anything about this in the Z380 manual. The use of 8 or 16 bit JRs depends on the opcode used. And the use of 16, 24 or 32 bit JPs depends on the preceding DDIR decoder directive. But of course, don't try a 24 or 32 bit JP in native mode because only the low 16 bit of the jump address will be used, and the rest will be ignored. * XVIII MSX USERS MEETING IN BARCELONA: DECEMBER 9th 2000 * Konami Man - AKA Nestor Soriano (^ ^)v - Itsumo MSX user New web address: http://konamiman.msx.tni.nl & http2//nestor.msx [EMAIL PROTECTED] ICQ#: 18281450 Bill Gates should pay 1$ every time Windows fails everywhere in the world Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: News from the CTNG lab :-)
> On the other hand, when you load an ASCIIfile, then the loading process > takes a bit longer (I am not able to verify it yet), but that is in my > opinion not a big problem since you probably always use the ASMformat. > The ASCIIload/save is only there for exchangability with other > environments. I often use it to load textfiles... I think the suggestion of 'precompile on the background' is very nice (though difficult). Or maybe you can make another fileformat 'text', which doesn't precompile at all. > > - Use 8 bit JR when displacement fits in 8 bits, otherwise use 16 bit JR > that's just the big problem: the displacement can be dependent on the > fact if you will be using 8bit or 16bit JR! The snake that bites its > tail... Afaik the Z380 uses special instructions (Decoder Directives) to indicate which ranges are to be used. They all start with DDIR. And which to 'compile' by default depends on the mode the Z380 is currently on (in extended memory mode 24-bit JR's and 32-bit JP's are default, if I'm not mistaking). ~Grauw -- ><< email me: [EMAIL PROTECTED] or ICQ: 10196372 visit my homepage at http://grauw.blehq.org/ ><< Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: News from the CTNG lab :-)
Jon De Schrijder wrote: > > - Use 8 bit JR when displacement fits in 8 bits, otherwise use 16 bit JR >that's just the big problem: the displacement can be dependent on the >fact if you will be using 8bit or 16bit JR! The snake that bites its >tail... That's one of the reasons I used a multi-pass design in tniASM :) It just keeps processing the code until everything checks out. It might be slow, but I don't have to remember anything and forward references take care of themselves. Ofcourse for an assembler running on MSX it would be totally unpractical for speed reasons, I think... Anyway, I don't think anyone would want a Z380 assembler run on Z80/R800. Is Compass prepared for doing 32-bit math on expressions? I think a Z380 assembler should be run on Z380. And if a proper C compiler is made, a Z380 assembler can simply be ported to it. >So I guess I will do it the easy way, and just introduce a new mnemonic >'JRR'.. or is 'JR16' better? since there is also 24bit JR 'JR24' ? JR16 and JR24 are better IMO. Greetz, Patriek Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: News from the CTNG lab :-)
What Maarten thinks is correct; When you save to the ASMformat, also the precompiled code is saved. So if you load an ASMfile, the compilationprocess goes equally fast as when you just typed it. :-) Loading and saving ASMfiles goes very fast (is only a dump of the internal memorybuffers to disk). On the other hand, when you load an ASCIIfile, then the loading process takes a bit longer (I am not able to verify it yet), but that is in my opinion not a big problem since you probably always use the ASMformat. The ASCIIload/save is only there for exchangability with other environments. > - Use 8 bit JR when displacement fits in 8 bits, otherwise use 16 bit JR that's just the big problem: the displacement can be dependent on the fact if you will be using 8bit or 16bit JR! The snake that bites its tail... The same goes for DJNZ, but since almost all DJNZ jump to somewhere before the DJNZ, the displacement is not dependent on the 8/16/24bit type. So in that case it is possible to automatically choose the offset type. So I guess I will do it the easy way, and just introduce a new mnemonic 'JRR'.. or is 'JR16' better? since there is also 24bit JR 'JR24' ? cu Jon Maarten ter Huurne wrote: > > On Thu, 14 Sep 2000, you wrote: > > > However: compiling 8000 lines in 2 seconds is a bit of a misindication. You > > said it is compiled while editing. So the compilation time very much > > depends on what you did before. If I boot Compass, load the 8000 lines and > > then compile it, it will take much longer won't it? > > My guess is that the source is pre-compiled at loading time. So loading ASCII > will take longer than before, but assembling it once it's loaded is fast. If > you regularly use Compass, you can save in its native format and that > probably loads real fast. > > Bye, > Maarten > > > Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/ > Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: News from the CTNG lab :-)
On Wed, 13 Sep 2000, Jon De Schrijder wrote:
> The assembly process will also be much faster since the code is already
> assembled as much as possible when you are editing. Exact timing results
> are not known yet, but I've already measured 2 seconds for Pass1 of a
> source of 8000 lines without labels. (7MHz MSX2) Who will need a
> cross-assembler ? ;-)
I happen to LOVE vi :P
Bye,
main(){int c[4] ,x=4 ,l=getpid() ,i;; for( srand(l);c[ x]=- rand
()%6 ,x-- ;);; for( ;44> x;){ char a[9] ,*p=
"%.1f\n", b[9];x=i=0; gets(a);for (l=4 ;l-- ;)x+=-(a[l] -=48)==
(b[l ]=c[ l]); ;for (l=0;16>i;l =++i %4)x
+=(b[i/4]+ a[l] ?0:( a[l]=b[i/4] =10)) ;printf(p,x *.1) ;};}
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: News from the CTNG lab :-)
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/
Re: News from the CTNG lab :-)
> Don't we all love Belgium and its beers. :-) Hey, I did not put it THAT general! I only could say: I love Belgium's beers! ;-) Grtjs, Manuel Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: News from the CTNG lab :-)
Manuel Bilderbeek wrote: > > I say: Amen! Give that man a cigar! :-) > > Nah, I don't smoke! :-) (A nice Hoegaarden beer is welcome of course, > though!) Don't we all love Belgium and its beers. :-) David Heremans Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: News from the CTNG lab :-)
Sorry, couldn't resist to reply on the always entertaining e-mails of Eric: > Manuel Bilderbeek wrote from the land of the rising sun: Still 16 days left... > > But NOW I WANT FAT16 FOR MY BLOODY SCSI EQUIPMENT, DAMMIT! ;-) > I say: Amen! Give that man a cigar! :-) Nah, I don't smoke! :-) (A nice Hoegaarden beer is welcome of course, though!) > A 'Novaxis 2.0' EPROM with FAT16 support for my old HSH SCSI interface > would be more than welcome !! For my MSX Club Gouda Interface it is too! In short: for any Novaxis-compatible interface it is! (Those are the most used SCSI interfaces these days, I presume...) Grtjs, Manuel (who is leaving out the long sig here, since this e-mail is already wasting) Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: News from the CTNG lab :-)
Manuel Bilderbeek wrote from the land of the rising sun: > [Compass 2 almost finished and very promising options] > > One word: cool! Agreed. I'll definitaly give Compass 2.0 a look when it's ready... > But NOW I WANT FAT16 FOR MY BLOODY SCSI EQUIPMENT, DAMMIT! ;-) I say: Amen! Give that man a cigar! :-) A 'Novaxis 2.0' EPROM with FAT16 support for my old HSH SCSI interface would be more than welcome !! Eric Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: News from the CTNG lab :-)
> the bad news: Compass 2.0 is still not finished despite past 2 months of > programming. It is difficult to say when the non-beta version will be > released, but it will be worth waiting for. Well, we can wait a little more, I think it will be worth the wait ;-) > The assembly process will also be much faster since the code is already > assembled as much as possible when you are editing. Exact timing results > are not known yet, but I've already measured 2 seconds for Pass1 of a > source of 8000 lines without labels. (7MHz MSX2) Who will need a > cross-assembler ? ;-) What about assembling in a Turbo-R with external memory mapper? It is currently a very slow process, will it also be improved? > The new ASMformat was also designed to support new instructionsets, so > probably Z380 will be supported in the final version. That's really COOL!! 8-D > But I have noticed > a problem: Z380 supports 16bit relative jumps, so if there is in the > source something like this: JR label, how can one decide whether to use > the normal 8bit JR or the 16bit JR, if you take in consideration that > the value of label can be dependent on your choice?! Well, it is not so difficult at all. Add the JRR mnemonic as you say, but add also a new menu or assembler directive or both, which allows to choose between the following options: - Use always 8 bit JR, and display error when overflow (that is, as if it were a Z80). - Use always 16 bit JR. - Use 8 bit JR when displacement fits in 8 bits, otherwise use 16 bit JR. Also, it would be VERY nice if you add the following options for Z80 assembling: - Automatically change JRs into JPs when overflow. - Automatically change JPs into JRs when possible. > (and also: what is > the use of 16bit relative addressing: it takes 3 bytes, then you can > better use a normal JP; maybe 'relocatable code'..) Yes, you catch it. Use of non limited JRs and CALRs instead of JP and CALL makes possible to easily produce relocatable code, which is very useful. Don't forget that from version 3.0, LPE-Z380 BIOS allows memory reservation in frame 0 (the first 64K) in an arbitrary address (just like TSRs do in MSX memory page 3). BTW, don't forget CALR instruction, which has also 8 bit and 16 bit displacement version, if I remember correctly. I have also a suggestion about the disk menu. Currently it is a little nasty to use multiple sources and to assemble to disk, because: - Only the last accessed file name is remembered when accessing disk menu. So if I load A in buffer 1, and then I load B in buffer 2, when I want to save A I must type again "A" name because B is the default name. The file name (and path!) for each buffer should be separately remembered. - The COMPASS default directory is always selected when "assemble to disk" option is selected, that's very very nasty!! The last accessed directory should be remembered. Konami Man Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: News from the CTNG lab :-)
On Thu, 14 Sep 2000, you wrote: > However: compiling 8000 lines in 2 seconds is a bit of a misindication. You > said it is compiled while editing. So the compilation time very much > depends on what you did before. If I boot Compass, load the 8000 lines and > then compile it, it will take much longer won't it? My guess is that the source is pre-compiled at loading time. So loading ASCII will take longer than before, but assembling it once it's loaded is fast. If you regularly use Compass, you can save in its native format and that probably loads real fast. Bye, Maarten Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
Re: News from the CTNG lab :-)
[Compass 2 almost finished and very promising options] One word: cool! However: compiling 8000 lines in 2 seconds is a bit of a misindication. You said it is compiled while editing. So the compilation time very much depends on what you did before. If I boot Compass, load the 8000 lines and then compile it, it will take much longer won't it? However, if I edit some things after loading the 8000 lines and go to the toilet, it will be much faster, won't it? (So, does it also compile in the background, or only the instructions you just entered?) > The good news: the new IDEFDISK 3.1 program is completely finished; the > TurboR bootproblem with the new type of bootsector was fixed. Now you > can add/kill variable-sized partitions like you wish, even FAT16 > partitions. Works great with the newest IDE bios 2.01 and Okei's FAT16 > driver. I will take the programs with me to Bussum, but probably it will > also be available at Sunrise. One word again: COOL! But NOW I WANT FAT16 FOR MY BLOODY SCSI EQUIPMENT, DAMMIT! ;-) Anway, Jon, we love you. If you have some time left, after finishing Compass and stuff, please update the IDE FAQ with FAT16 stuff. Thanks! Best regards, Manuel --- Pre-PS: After 29/9/2000, I cannot use this address anymore. Therefore, from 25/9/2000, please send all mail to [EMAIL PROTECTED], my always- valid address. I can also read that mail from here in Japan. Thank you. PS: MSX 4 EVER! (Questions? See: http://www.faq.msxnet.org/ ) PPS: Visit my home page at http://bilderbeek.cjb.net/ Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
News from the CTNG lab :-)
Yo guys & girls, good news and bad news: the bad news: Compass 2.0 is still not finished despite past 2 months of programming. It is difficult to say when the non-beta version will be released, but it will be worth waiting for. One of my favourite new things is the clockcycle-indication: when entering mnemonics, the clockcycles needed for that instruction are displayed. (you can choose between Z80/R800 and add the extra waitstate if you like) Of course you can also select a block and calculate the total amount of cycles. The assembly process will also be much faster since the code is already assembled as much as possible when you are editing. Exact timing results are not known yet, but I've already measured 2 seconds for Pass1 of a source of 8000 lines without labels. (7MHz MSX2) Who will need a cross-assembler ? ;-) The new ASMformat was also designed to support new instructionsets, so probably Z380 will be supported in the final version. But I have noticed a problem: Z380 supports 16bit relative jumps, so if there is in the source something like this: JR label, how can one decide whether to use the normal 8bit JR or the 16bit JR, if you take in consideration that the value of label can be dependent on your choice?! (and also: what is the use of 16bit relative addressing: it takes 3 bytes, then you can better use a normal JP; maybe 'relocatable code'..) A possible easy solution could be using a new mnemonic like JRR (like the new CALR)... The good news: the new IDEFDISK 3.1 program is completely finished; the TurboR bootproblem with the new type of bootsector was fixed. Now you can add/kill variable-sized partitions like you wish, even FAT16 partitions. Works great with the newest IDE bios 2.01 and Okei's FAT16 driver. I will take the programs with me to Bussum, but probably it will also be available at Sunrise. Due to circumstances, CTNG will not have a booth on the fair in Bussum, but some of us will come as visitor. Greetings, Jon Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
