You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
2003 |
Jan
(1) |
Feb
(4) |
Mar
(18) |
Apr
(7) |
May
(16) |
Jun
(2) |
Jul
(46) |
Aug
(1) |
Sep
(15) |
Oct
|
Nov
|
Dec
(8) |
2004 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(20) |
Nov
(19) |
Dec
(6) |
2007 |
Jan
|
Feb
(7) |
Mar
(14) |
Apr
(4) |
May
(3) |
Jun
(2) |
Jul
(12) |
Aug
(31) |
Sep
(9) |
Oct
(2) |
Nov
(5) |
Dec
(2) |
2008 |
Jan
(4) |
Feb
(4) |
Mar
(28) |
Apr
(16) |
May
(17) |
Jun
(9) |
Jul
(24) |
Aug
(13) |
Sep
(17) |
Oct
(19) |
Nov
(41) |
Dec
(52) |
2009 |
Jan
(27) |
Feb
(14) |
Mar
(31) |
Apr
(45) |
May
(125) |
Jun
(86) |
Jul
(65) |
Aug
(19) |
Sep
(17) |
Oct
(31) |
Nov
(7) |
Dec
(17) |
2010 |
Jan
(5) |
Feb
(6) |
Mar
(62) |
Apr
(61) |
May
(74) |
Jun
(70) |
Jul
(33) |
Aug
(52) |
Sep
(15) |
Oct
(1) |
Nov
|
Dec
(1) |
2011 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
(2) |
2016 |
Jan
(6) |
Feb
(5) |
Mar
(5) |
Apr
(9) |
May
(3) |
Jun
(3) |
Jul
(2) |
Aug
(5) |
Sep
(4) |
Oct
(7) |
Nov
(6) |
Dec
(5) |
2017 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Peter W. <pet...@ly...> - 2003-12-31 01:48:59
|
Chapter 2.1, page 7, very last point of this chapter: Must be aspace.h instead of event.h Chapter 2.2, page 10: The lis of register functions seems short and unbalanced, but no comment that these functions apply to all registers. So: No get_ES(), get_GS()? No setES/FS/GS()? No get_LDTR()? Figure 2.2, page 12 seems to be out of place? There's talk about threads on page 11 and 13, and in the middle of the sentence page 12 with the multiboot struct breaks in. Kind regards Peter Wiehe |
From: Peter W. <pet...@ly...> - 2003-12-30 23:49:46
|
I've replied to Luca only, not to the list :( because I clocked "Reply" [The "Reply To All" was always contrary to my way of thinking :( because I think I get a mail by the listbot and if I reply it will go to the bot. But that's wrong!] But I wanted to reply to the list. Luca, can You forward my reply, please? |
From: Paolo G. <pao...@ti...> - 2003-12-30 20:20:13
|
Hi Luca, Hi Peter, I see no problem if the extender continues to be coded as a part of OSLib... As Luca already said, they can be thought as independent parts of the same projects... The only reason why I could imagine that splitting the extender is a good reason is to make it more visible to people that do not want to use OSLib but that can anyway get advantages in using the extender... I could suggest probably to make the eXtender page a lot more visible in the web page, actually it is somehow more hidden than the rest... (it is not cited in the Project Overview, but can be found in the subproject)... probably the weight of the web site should be half libraries/half extender... >>And OSLIb should ignore, by which loader it was booted. Yes and no... I would say the converse... X should be able to boot multiboot images that are not written knowing that they will be booted by the extender... But if I boot with the extender, I got some nice features like the return to DOS, and the X_CallBIOS feature... that for example we use heavily inside the shark kernel (http://shark.sssup.it) to get support for the VESA graphic cards using BIOS calls... Actually I tried to boot with X also another OS, called MarteOS (http://marte.unican.es) , and it worked fine... apart of course for the return to dos... bye PJ |
From: Luca A. <luc...@em...> - 2003-12-30 18:16:19
|
Hi Peter, what's the advantage in making the extender an independent project? It already is in a separate cvs module (the eXtender module in the sf cvs), and can be downloaded separately from oslib (oslib and the extender are different packages in the sf project page). > And OSLIb should ignore, by which loader it was booted. Well, let's say that it can ignore the loader by which it was booted. But if it knows that it has been loaded by the eXtender it can take advantages from this fact. For example, the eXtender can load oslib programs from DOS allowing such programs to return to DOS when they finish (very useful for debugging). But in order to safely return to DOS a program must not corrupt the DOS memory. Hence, x.exe passes information about the DOS memory to oslib (this is an extension to the multiboot standard). If a program ignores the loader, it cannot safely return to DOS. I think this can be also done by using the memory maps supported by the multiboot standard (and creating a fake memory map that marks dos memory as ROM), but I still have to have a better look at this solution. > For example, this means: example/mbdemo.c should show the loader name, This is correct, thanks for pointing it out... I'll fix mbdemo.c in the next days. Luca |
From: Peter W. <pet...@ly...> - 2003-12-30 15:33:49
|
Why someone wants OSLib anyway? Because modularizaition is a good thing. So it seems to me, that this should be applied to the extender as well. The extender should become a project independent of OSLIb. And OSLIb should ignore, by which loader it was booted. For example, this means: example/mbdemo.c should show the loader name, but it should not have a check or a variable for eXtender. Kind regards Peter Wiehe |
From: Giacomo G. <gi...@ga...> - 2003-09-16 14:16:09
|
Hi these are the comparisons between the external timer and shark using different timer mode PIT: the old mode without TSC TSC: only TSC TSC+RTC: TSC with CMOS corrections (P3-333Mhz) PIT - (on 15h) delta = 175 sec 184 ms (P3-333Mhz) TSC - (on 15h) delta = 1 sec 760 ms (P3-333Mhz) TSC+RTC - (on 15 h) delta = 450 ms (P4-2000Mhz) PIT - (on 15h) delta = 254 sec (P4-2000Mhz) TSC - (on 15h) delta = 4 sec 520 ms (P4-2000Mhz) TSC+CMOS - (on 15h) delta = 170 ms Giacomo |
From: Giacomo G. <gi...@ga...> - 2003-09-16 14:00:09
|
Hi all the precision of the timer in Shark is due to the calibration routine that calculates the CPU clocks on 1 msec. This value is printed during the init step of a shark demo (the clk_per_msec). I rewrote this calibration routine starting from the linux one... but there are not the same and it's normal a difference of some microsec. Anyway, after a test session with an external timer (controlled by parallel port) I think that is Linux the more imprecise. The timer precision is due to the relation between the PIT and the TSC. Considering that a PIT has 16 bit counter, this precision cannot be more than 1 part on 65535 With RTC corrections (the IRQ8Handler) I tried to reduce the long term drift... and the effect cannot be seen on 1 second, but hours. The old timer routine of shark (the current of OsLib) uses this 1197 value that now is no more significative (the system tick is apart from the timer count) and it brought a bigger error. bye Giacomo Ian Broster wrote: >We've got a serious problem of clock drift in Shark. >Over 1 second, sys_gettime() loses about 50us >compared to the machine running linux. > >I note that oslib/kl/event.c and oslib/ll/sys/ll/time.h >make use of a magic number 1197, relating to >1.19718 MHz. Should this be 1.193182 MHz? > >I'm not sure about this, particularly as the >ratio of these two frequencies (1.10032) does not >quite match our clock drift discrepancy (1.0059). > > >ian > > > |
From: Ian B. <ia...@cs...> - 2003-09-16 13:06:46
|
> unsigned char use_tsc = 1; //Enable the TSC counter mode > unsigned char use_cmos = 1; //Enable the RTC correction This didn't seem to help---the clock drift is the same. i |
From: Paolo G. <pao...@ti...> - 2003-09-16 12:23:23
|
Yes... we also noted that. I never checked the real frequency of the system, but we noted that the system was not going properly compared to an external alarm. Giacomo implemented a clock correction algorithm based on the Pentium RTC that also uses the real-time clock of the PCs. It has been submitted as a patch to Luca, and it is currently part of the Shark distribution. you have to check the value of the following two variables in oslib/advtimer.c: unsigned char use_tsc = 1; //Enable the TSC counter mode unsigned char use_cmos = 1; //Enable the RTC correction ...they should be both 1. I also think that Giacomo prepared a small note on the clock correction, but I think that he never published it yet... (Giacomoooo???) bye PJ On Tue, 2003-09-16 at 13:27, Ian Broster wrote: > We've got a serious problem of clock drift in Shark. > Over 1 second, sys_gettime() loses about 50us > compared to the machine running linux. > > I note that oslib/kl/event.c and oslib/ll/sys/ll/time.h > make use of a magic number 1197, relating to > 1.19718 MHz. Should this be 1.193182 MHz? > > I'm not sure about this, particularly as the > ratio of these two frequencies (1.10032) does not > quite match our clock drift discrepancy (1.0059). > > > ian -- Paolo Gai <pao...@ti...> Scuola S. Anna |
From: Luca A. <luc...@em...> - 2003-09-16 11:58:21
|
Hi Ian, I do not remember where the 1197 comes from... I suspect you are right, and it should be 1193. Try to use 1193 and see if it works better... ;-) BTW, shark also has some "time correction" mechanism based on the RTC... Did you try it? Luca -- _____________________________________________________________________________ Copy this in your signature, if you think it is important: N O W A R ! ! ! -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Sconti fino al 50% su eBay Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1649&d=16-9 |
From: Ian B. <ia...@cs...> - 2003-09-16 11:33:23
|
We've got a serious problem of clock drift in Shark. Over 1 second, sys_gettime() loses about 50us compared to the machine running linux. I note that oslib/kl/event.c and oslib/ll/sys/ll/time.h make use of a magic number 1197, relating to 1.19718 MHz. Should this be 1.193182 MHz? I'm not sure about this, particularly as the ratio of these two frequencies (1.10032) does not quite match our clock drift discrepancy (1.0059). ian |
From: Luca A. <luc...@em...> - 2003-09-12 09:39:01
|
On Thu, 2003-09-11 at 16:30, Paolo Gai wrote: > > Is it ok if I remove the cli()/sti() from irq_bind() (it is the only > > oslib function that protects itself with cli/sti)? In this way, the > > responsibility for locking/unlocking is left to the kernel (right now, > > this seems to me the correct thing to do...). > > > > Also, this would answer the "open question" in oq.txt (I forgot about it > > ;-). > > >From my point of view, it should be that OSLib functions are not > protected with cli/sti. Ok, I am going to remove cli()/sti() from irq_bind()... > That is, it is responsability of the upper layer (the kernel) to disable > the interrupts when needed. > > That is at least what I always thought when I implemented the shark > kernel layer... Well, it was an open question... Time to close it :-) Luca -- _____________________________________________________________________________ Copy this in your signature, if you think it is important: N O W A R ! ! ! -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Al Garden Center Peraga fioriscono nuove iniziative: ecco i Tour Day Peraga, per andare alla scoperta del Canavese! INFO 0125 665500 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1613&d=12-9 |
From: Paolo G. <pao...@ti...> - 2003-09-11 15:31:02
|
> Is it ok if I remove the cli()/sti() from irq_bind() (it is the only > oslib function that protects itself with cli/sti)? In this way, the > responsibility for locking/unlocking is left to the kernel (right now, > this seems to me the correct thing to do...). > > Also, this would answer the "open question" in oq.txt (I forgot about it > ;-). >From my point of view, it should be that OSLib functions are not protected with cli/sti. That is, it is responsability of the upper layer (the kernel) to disable the interrupts when needed. That is at least what I always thought when I implemented the shark kernel layer... bye PJ -- Paolo Gai <pao...@ti...> Scuola S. Anna |
From: Luca A. <luc...@em...> - 2003-09-11 15:03:14
|
Hi all, > > oslib/kl/intevt.c:65 return in line 70 without sti, also warning in comments > bug Is it ok if I remove the cli()/sti() from irq_bind() (it is the only oslib function that protects itself with cli/sti)? In this way, the responsibility for locking/unlocking is left to the kernel (right now, this seems to me the correct thing to do...). Also, this would answer the "open question" in oq.txt (I forgot about it ;-). > > oslib/kl/intevt.c:111: cli() possible without sti after? or are we deep in something else > should be ok... Yes, it is ok. It is re-disabling the interrupts that have been enabled at line 106. Luca -- _____________________________________________________________________________ Copy this in your signature, if you think it is important: N O W A R ! ! ! -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Con KLM puoi risparmiare fino a 20 Euro sul tuo biglietto aereo prenotando on line per Usa, Europa e il resto del mondo Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=1259&d=11-9 |
From: Paolo G. <pao...@ti...> - 2003-09-10 08:03:51
|
> I am willing to do this change, however... In this particular situation, > the abort 64 is more than motivated even in the oneshot case. Guys, we > are spending more than 1ms in the int handler!!! The kernel must > complain, otherwise we are going to have a lot of funny bugs in the > future... > Maybe I can just change the overrun test (converting it in a test on the > amount of time spent in the handler) and print a warning if things are > going bad... My opinion is that the action that have to be carried when a timer overrun is detected should be left to the kernel layer. In my opinion, printing a message or exiting with ll_abort is not a good idea, because ll_abort -just exits without saying a word- in general the kernel should have the possibility to do at least something like: - clean up all its things before exiting - sending a signal to some process saying "hey! something strange happened!", leaving to the application the possibility to ignore that or to exit properly. - adjust the timer period adaptively ;-) Also note that a clock overrun is -really- critical if it lets you loose the time reference...but not so critical if it happen when using the TSC (that has a longer lifetime). (Btw, Giacomo sent you a patch about TSC/APIC support in the event mechanism of oslib... I've not checked if it has been rejected or included in the CVS tree... if you want we can post it again in the patch part of the sourceforge website...) Also note that the clock overrun problem happens often at initialization time, so since things have not yet started properly, we should allow some flexibility. I would propose some kind of hook that is by default set to ll_abort, but that it can be redefined by the user, in a similar way to what happens to the irqs/exceptions/... bye PJ -- Paolo Gai <pao...@ti...> Scuola S. Anna |
From: Luca A. <luc...@em...> - 2003-09-10 07:43:14
|
Hi, > ok, I underestimate the video scroll function... it takes 1900 us sec on > a P3 celeron. Since there is some I/O involved, this long time is not completely surprising. However, most of the text output functions (as they are implemented now) are just crap, and they should be rewritten. I wanted to do that, but I never found the time (as usual ;). As you note, for example, the scroll function is implemented through _scroll, and this is just bad. If someone is going to reimplement the relevant parts of libcons, I am more than willing to commit the changes. In particular: - All the functions that support windows (I remember about _clear() and _scroll()) should be renamed to win_*(), and moved to a different file (something like wincons.c). - All the functions calling win_* functions should be reimplemented, in a simpler and optimized way. > So the ABORT 64 error with system TICK of 1000 it's normal... Yes, doing a message() inside an irq handler is a _very_ bad idea. > with one shot mode it shouldn't happen. I suggest to change the ll_timer > to skip > the abort test in case of one shot. I am willing to do this change, however... In this particular situation, the abort 64 is more than motivated even in the oneshot case. Guys, we are spending more than 1ms in the int handler!!! The kernel must complain, otherwise we are going to have a lot of funny bugs in the future... Maybe I can just change the overrun test (converting it in a test on the amount of time spent in the handler) and print a warning if things are going bad... > I modified also the scroll function: > > void _scroll(char attr,int x1,int y1,int x2,int y2) > { > register int x,y; > WORD xattr = attr << 8,w; > LIN_ADDR v = (LIN_ADDR)(0xB8000 + active_page*(2*PAGE_SIZE)); > > for (y = y1+1; y <= y2; y++) > for (x = x1; x <= x2; x++) { > w = lmempeekw((LIN_ADDR)(v + 2*(y*cons_columns+x))); > lmempokew((LIN_ADDR)(v + 2*((y-1)*cons_columns+x)),w); > } > for (x = x1; x <= x2; x++) > lmempokew((LIN_ADDR)(v + 2*((y-1)*cons_columns+x)),xattr); > } > > //#define OPTIMIZED > #ifdef OPTIMIZED > > void scroll(void) > { > > int x; > WORD xattr = bios_attr << 8; > LIN_ADDR v = (LIN_ADDR)(0xB8000 + active_page*(2*PAGE_SIZE)); > > memcpy((LIN_ADDR)(v), > (LIN_ADDR)(v + 2*cons_columns), > cons_columns*(cons_rows-1)*2); Uhmmm... Maybe memmove()? The two memory areas are overlapping... Ok, since dest < src memcpy() works well, but memmove() would be safer... Can you measure any performance difference if you use memmove? Luca -- _____________________________________________________________________________ Copy this in your signature, if you think it is important: N O W A R ! ! ! -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Conto Arancio: facile aprirlo, difficile rinunciarci. Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=663&d=10-9 |
From: Giacomo G. <gi...@ga...> - 2003-09-09 16:10:31
|
Hi all ok, I underestimate the video scroll function... it takes 1900 us sec on a P3 celeron. So the ABORT 64 error with system TICK of 1000 it's normal... anyway with one shot mode it shouldn't happen. I suggest to change the ll_timer to skip the abort test in case of one shot. I modified also the scroll function: void _scroll(char attr,int x1,int y1,int x2,int y2) { register int x,y; WORD xattr = attr << 8,w; LIN_ADDR v = (LIN_ADDR)(0xB8000 + active_page*(2*PAGE_SIZE)); for (y = y1+1; y <= y2; y++) for (x = x1; x <= x2; x++) { w = lmempeekw((LIN_ADDR)(v + 2*(y*cons_columns+x))); lmempokew((LIN_ADDR)(v + 2*((y-1)*cons_columns+x)),w); } for (x = x1; x <= x2; x++) lmempokew((LIN_ADDR)(v + 2*((y-1)*cons_columns+x)),xattr); } //#define OPTIMIZED #ifdef OPTIMIZED void scroll(void) { int x; WORD xattr = bios_attr << 8; LIN_ADDR v = (LIN_ADDR)(0xB8000 + active_page*(2*PAGE_SIZE)); memcpy((LIN_ADDR)(v), (LIN_ADDR)(v + 2*cons_columns), cons_columns*(cons_rows-1)*2); for (x = 0; x <= cons_columns-1; x++) lmempokew((LIN_ADDR)(v + 2*((cons_rows-1)*cons_columns+x)),xattr); } #else void scroll(void) { _scroll(bios_attr,0,0,(cons_columns-1),(cons_rows-1)); } #endif with the optimized one I got 1200 us instead of 1900... not much but it's called many times. Regards Giacomo |
From: Luca A. <luc...@em...> - 2003-09-08 21:28:10
|
Hi all, [...] > - oneshot timer: This case is more strange, because the one-shot timer > reprograms the timer everytime it exits from a timer interrupt; to avoid > that, Luca set a minimum interarrival time between two interrupts (in > oslib/include/i386/pit.h), so -it should be- that the abort 64 with the > one-shot timer never happens... but (I do not know why), sometimes it > happens :-( > > ... anyway, I guess that the overrun check for the oslib events should > be done only in the periodic case, not in the one shot case. After thinking a lot about it, I can agree that the overrun test can be avoided in the oneshot case: I'll do the change as soon as I will find some spare time... Luca -- _____________________________________________________________________________ Copy this in your signature, if you think it is important: N O W A R ! ! ! -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Il notebook che hai sempre desiderato lo trovi su Ebest Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=551&d=8-9 |
From: Giacomo G. <gu...@li...> - 2003-09-06 11:20:12
|
Hi all I think the situation is more complex and it's not only a problem of long interruptions I measured the time of a periodic_wake_up and or oneshot_wake_up functions called by ll_timer. With the cprintf active in scheduler functions and relative scrolls of the video, I got 15 us on my Pentium 200 MMX... I don't understand where 1 ms comes from. I think that in the shark kernel there is a bug where a cli is called without the relative sti... so long time passes between the interrupt reactivation and two timer interrupt come at the same time. bye Giacomo |
From: Paolo G. <pao...@ti...> - 2003-09-06 09:47:36
|
(I reply to this thread on shark-devel and to oslib-devel because I think it may be of interest of all the subscribers...) where it is printed: -- ABORT 64 is written by abort_tail() (oslib/kl/init.c), that is called from ll_abort() (oslib/kl/abort.s), that is called from the timer interrupt handler called ll_timer (oslib/kl/timeint.s) why? -- It happens when a timer interrupt arrived before the previous timer interrupt finished. That situation is quite bad, becaude it means that something strange is happening, and that (probably) the timer reference has been lost (the timer interrupts are used to take track of the system time). (Note that the timer interrupt have anyway a robustness of 55ms) We have to distinguish 2 cases: - periodic timer: In this case, the real-time clock raises an interrupt every XXX ticks. This is the real problem... because we do not know how many interrupts have been raised since the last timer handler. - oneshot timer: This case is more strange, because the one-shot timer reprograms the timer everytime it exits from a timer interrupt; to avoid that, Luca set a minimum interarrival time between two interrupts (in oslib/include/i386/pit.h), so -it should be- that the abort 64 with the one-shot timer never happens... but (I do not know why), sometimes it happens :-( ... anyway, I guess that the overrun check for the oslib events should be done only in the periodic case, not in the one shot case. Typical situations: -- The ABORT 64 typically happens if someone puts some cprintf inside the interrupt handler, and these printfs have to scroll the screen, that usually takes around 1ms per scroll... In the shark case, it may happen that the linux timer raised by the network driver is quite long, and so it maybe should be run inside a thread. I think Michael is working on a solution like that. Other notes can be found in the FAQ 1.1 on the shark website. That's all for now... bye PJ On Fri, 2003-09-05 at 18:12, Giacomo Guidi wrote: > Hi all > > I'm studing the "ABORT 64" error... it's one of the most strange things > of SHARK. It should happen if the ll_timer function inside OSLib, called > by the the PIC timer, isn't ended before another PIC interrupt is > posted. This mean that if an event of the shark kernel (like a scheduler > decision) is longer than the system tick... you got an ABORT 64. > > I measured with TSC how long are these events. In the worst case, when > all debug stuff are activated, on my slow PENTIUM 200, i got around 10 > us. It's much less than the 1000 us of the system tick... but I got > anyway ABORT 64. > > So, what's the problem ? Maybe a routine that reactivate the interrupt > in the middle of a system event (that should have interrupt disable) can > cause this behaviour ? > > Regards > > Giacomo |
From: Juras B. <yb...@tu...> - 2003-08-17 11:47:59
|
Hello freedos-32-dev, I found out that if I place a value of 3000000 or 4000000 or 5000000 to "ips:" in bochsrc, the timer IRQ works in Bochs ok. But if I try some values higher or lower than 1000000, i.e. 3500000, 4500000, 3600000, 3900000 the timer will not tick in Bochs! (my proc. AMD AthlonXP-1600) -- Best regards, Juras mailto:yb...@tu... |
From: Paul D. <du...@ho...> - 2003-07-31 01:53:55
|
Part of the problem with floppy access, is that it need the timer. Most probably, to be able to abandon, if floppy disk access don't work within a reasonable delay. In DOS, you're not supposed to chain directly int08 (IRQ0) to have your program be called at each tick, but to chain on INT 28 (0x1C). Now, that's a bit special, because, we have to reflect 0x40 (IRQ0) and INT 0x1C, that is called from inside the reflected 0x40. Which seems to cause an error. I'll try to send you the log in an other message, I just wanted to avoid Luca to search too much. _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://messenger.fr.msn.ca/ |
From: Paul D. <du...@ho...> - 2003-07-12 19:03:36
|
Well I have removed "useless" 0x66h from my x_sw2.nsm. Examples seems to run exactly as before. So my bug is always there, but that did not broke anything either. _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://messenger.fr.msn.ca/ |
From: Paul D. <du...@ho...> - 2003-07-12 13:16:06
|
Looking through x_sw2.nsm (eXtender sources) I see something like this: db 066h mov eax,cr0 ; switch to pm mov [ds:_old_CR0],eax ; store old CR0 value or ax,1 db 066h mov cr0,eax I am very afraid by these db 066h. First, it seems it was in a 16 bits segment, so by seeing mov cr0,eax in a 16 bits segment, the assembler, will, should, automatically insert the toggle prefix 066h. But now, when there are two prefix, I don't know if the CPU will toggle back as if they were no 66h at all, or just ignore the fact that there is more than one. This seems ok to code explicitly the 066h when you explicitly code yourself the instruction, but not to put it before a mov, as then you may be undoing what the assembler supposed to do. _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://messenger.fr.msn.ca/ |
From: Paul D. <du...@ho...> - 2003-07-12 11:18:00
|
First forget what I said about ES:DI for int13h ah=02h, it's really ES:BX. And about int86x? Well, I don't fully thrust it, but that don't means it don't work. _________________________________________________________________ MSN Messenger : discutez en direct avec vos amis ! http://messenger.fr.msn.ca/ |