freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] Fwd: Re: Timezone and timestamp

[Peter S. <p....@sc...>]

On Sun, 29 Jul 2018 12:19:10 , Peter Slegg <p....@sc...> wrote:
>
>
> 2018-07-29 11:23 GMT+02:00 David GÃílvez <dga...@gm...>:
> > Do you have the timezone data base installed?, see if you have the
> > file /etc/localtime in your system, if so you don't need to set the
> > system variable TZ in mint.cnf, but be aware that the file localtime
> > must be the correct one for you time zone. If not you can copy it from
> > /usr/share/zoneinfo to the /etc directory and rename it to
> > "localtime".
>
> >Sorry, possibly this is not the way to install your localtime file, my
> >memory failed me again. The "zic" command should be used instead, read
> >this:
> >https://github.com/freemint/mintlib/blob/master/tz/README.1st
>
> -
>
> The localtime file is a link to /usr/share/zoneinfo/factory which
> contains:
>
> TZif                   
   
           
   1      Local time zone mus
> t be set--see zic manual page
>
>
>
> Peter
>


This looks wrong:
 
bash-4.3# tzinit
Current date and time: Sun Jul 29 12:18:04 2018
Time zone in use: BST
East of Greenwich Mean Time: 1:00:00
Kernel clock mode: localtime
bash-4.3# date
Sun Jul 29 12:18:07 BST 2018

[Freemint-discuss] Fwd: Re: Timezone and timestamp

[Peter S. <p....@sc...>]

2018-07-29 11:23 GMT+02:00 David GÃílvez <dga...@gm...>:
> Do you have the timezone data base installed?, see if you have the
> file /etc/localtime in your system, if so you don't need to set the
> system variable TZ in mint.cnf, but be aware that the file localtime
> must be the correct one for you time zone. If not you can copy it from
> /usr/share/zoneinfo to the /etc directory and rename it to
> "localtime".

>Sorry, possibly this is not the way to install your localtime file, my
>memory failed me again. The "zic" command should be used instead, read
>this:
>https://github.com/freemint/mintlib/blob/master/tz/README.1st

-

The localtime file is a link to /usr/share/zoneinfo/factory which
contains:

TZif                   
   
           
   1      Local time zone must be set--see zic manual page



Peter

Re: [Freemint-discuss] Timezone and timestamp

[David G. <dga...@gm...>]

2018-07-29 11:23 GMT+02:00 David Gálvez <dga...@gm...>:
> Do you have the timezone data base installed?, see if you have the
> file /etc/localtime in your system, if so you don't need to set the
> system variable TZ in mint.cnf, but be aware that the file localtime
> must be the correct one for you time zone. If not you can copy it from
> /usr/share/zoneinfo to the /etc directory and rename it to
> "localtime".

Sorry, possibly this is not the way to install your localtime file, my
memory failed me again. The "zic" command should be used instead, read
this:
https://github.com/freemint/mintlib/blob/master/tz/README.1st

Re: [Freemint-discuss] Timezone and timestamp

[David G. <dga...@gm...>]

2018-07-28 13:01 GMT+02:00 Peter Slegg <p....@sc...>:
> On Fri, 27 Jul 2018 10:01:10 , David Gálvez wrote:
>> Hi Peter,
>>
>> 2018-03-26 15:32 GMT+02:00 Peter Slegg <p....@sc...>:
>> >
>> > Myself and others have reported timezone issues especially with
>> > the change to summertime.
>> >
>> >
>> > Android has a bug that means files sent over samba have their
>> > timestamps set to the sysdate. So I use touch -t to reset the
>> > times based on the filename. I have hacked up a perl script to
>> > do this.
>> >
>> >
>> > I do the mp4 files individually:
>> >
>> > touch -t 201712101030 /tmp/20171210_103049.mp4
>> >
>> > but in Thing they are shown with a time of 1 hour ahead.
>> > I am using BST (GMT +1)
>> >
>> > In this example the file is shown as 11:30 when I have stamped it 10:30
>> >
>> >
>> >
>> > In bash the file time is correct:
>> >
>> > bash-4.3# ls -l /tmp/
>> > total 10460
>> > -rw-r--r--    1 root     root     10692187 Dec 10 10:30 20171210_103049.mp4
>> >
>> >
>>
>> Is your hardware clock set to the localtime or UTC (GMT)?
>> I guess is UTC but to be sure.
>>
>> How do you run tzinit in mint.cnf? Which option do you use?
>>
>
>
> In mint.cnf I have the original (very old) settings commented out and the
> updated one that was suggested when I originally mentioned the issue
> about 8-10 years ago.
>
> # Timezone (mandatory)
> #~setenv TZ GMT-0BST,3.5.0,10.5.0
> setenv TZ GB
> exec    u:\sbin\tzinit -l
>
>
> Somewhere, in the labyrinth of the start-up, ntpdate is called to set the clock.
>

I have read that ntpdate feeds your system with an UTC time, so you
need to change the option for tzinit from "-l" to "-u". This explains
why you wrote in an email from last year that the clock in your
taskbar is not right during DST, during the rest of the year is
correct only by chance.

Do you have the timezone data base installed?, see if you have the
file /etc/localtime in your system, if so you don't need to set the
system variable TZ in mint.cnf, but be aware that the file localtime
must be the correct one for you time zone. If not you can copy it from
/usr/share/zoneinfo to the /etc directory and rename it to
"localtime".

Re: [Freemint-discuss] Timezone and timestamp

[Peter S. <p....@sc...>]

On Fri, 27 Jul 2018 10:01:10 , David Gálvez wrote:
> Hi Peter,
>
> 2018-03-26 15:32 GMT+02:00 Peter Slegg <p....@sc...>:
> >
> > Myself and others have reported timezone issues especially with
> > the change to summertime.
> >
> >
> > Android has a bug that means files sent over samba have their
> > timestamps set to the sysdate. So I use touch -t to reset the
> > times based on the filename. I have hacked up a perl script to
> > do this.
> >
> >
> > I do the mp4 files individually:
> >
> > touch -t 201712101030 /tmp/20171210_103049.mp4
> >
> > but in Thing they are shown with a time of 1 hour ahead.
> > I am using BST (GMT +1)
> >
> > In this example the file is shown as 11:30 when I have stamped it 10:30
> >
> >
> >
> > In bash the file time is correct:
> >
> > bash-4.3# ls -l /tmp/
> > total 10460
> > -rw-r--r--    1 root     root     10692187 Dec 10 10:30 20171210_103049.mp4
> >
> >
>
> Is your hardware clock set to the localtime or UTC (GMT)?
> I guess is UTC but to be sure.
>
> How do you run tzinit in mint.cnf? Which option do you use?
>


In mint.cnf I have the original (very old) settings commented out and the
updated one that was suggested when I originally mentioned the issue
about 8-10 years ago.

# Timezone (mandatory)
#~setenv TZ GMT-0BST,3.5.0,10.5.0
setenv TZ GB
exec    u:\sbin\tzinit -l


Somewhere, in the labyrinth of the start-up, ntpdate is called to set the clock.


Peter

Re: [Freemint-discuss] Timezone and timestamp

[Thorsten O. <ad...@th...>]

On Montag, 26. März 2018 15:32:28 CEST Peter Slegg wrote:
> but in Thing they are shown with a time of 1 hour ahead.

I think this is because Thing is compiled by Pure-C, which does not have a 
complete timezone database. Sometimes setting the TZ environment variable 
helps, but not always, and you have to remember to change that accordingly 
when switching to/from summertime.

Re: [Freemint-discuss] Timezone and timestamp

[David G. <dga...@gm...>]

Hi Peter,

2018-03-26 15:32 GMT+02:00 Peter Slegg <p....@sc...>:
>
> Myself and others have reported timezone issues especially with
> the change to summertime.
>
>
> Android has a bug that means files sent over samba have their
> timestamps set to the sysdate. So I use touch -t to reset the
> times based on the filename. I have hacked up a perl script to
> do this.
>
>
> I do the mp4 files individually:
>
> touch -t 201712101030 /tmp/20171210_103049.mp4
>
> but in Thing they are shown with a time of 1 hour ahead.
> I am using BST (GMT +1)
>
> In this example the file is shown as 11:30 when I have stamped it 10:30
>
>
>
> In bash the file time is correct:
>
> bash-4.3# ls -l /tmp/
> total 10460
> -rw-r--r--    1 root     root     10692187 Dec 10 10:30 20171210_103049.mp4
>
>

Is your hardware clock set to the localtime or UTC (GMT)?
I guess is UTC but to be sure.

How do you run tzinit in mint.cnf? Which option do you use?

Re: [Freemint-discuss] A NetUSBee question

[David G. <dga...@gm...>]

Hi Roger, nice to read that you're working on those drivers

2018-07-16 17:02 GMT+02:00 Roger Burrows <an...@xp...>:
> I'm looking at the NetUSBee code with the objective of getting a mouse driver
> (and later a keyboard driver) to work under TOS.
>
> In /sys/usb/src.km/ucd/netusbee/isp116x-hcd.c, I don't understand why
> TOS_INT_OFF/TOS_INT_ON are not used every time that MINT_INT_OFF/MINT_INT_ON
> are used.  Both set the interrupt level to 6 to prevent device drivers (hooked
> off etv_timer) from being called while critical sections are running.  Can
> someone explain why some sections of code are protected under MiNT but not
> under TOS?
>

When I added that code, interrupts were set/unset the same for MiNT and TOS,
indeed I use the same macros for both systems, after adding that code
the transfer
rate using USB storage devices decreased significantly. As the
NetUSBee TOS driver
was stable before the code was added Claude proposed to turn off the
interrupts in the TOS
driver only where it was done previously. Although I think it's like
playing to the "Russian Roulette" ;-)
for now it looks like the driver is still stable under TOS...well
there are some problems
with some TTs and PAK3 cards, but those issues I suspect are timing related.

[Freemint-discuss] A NetUSBee question

[Roger B. <an...@xp...>]

I'm looking at the NetUSBee code with the objective of getting a mouse driver 
(and later a keyboard driver) to work under TOS.

In /sys/usb/src.km/ucd/netusbee/isp116x-hcd.c, I don't understand why 
TOS_INT_OFF/TOS_INT_ON are not used every time that MINT_INT_OFF/MINT_INT_ON 
are used.  Both set the interrupt level to 6 to prevent device drivers (hooked 
off etv_timer) from being called while critical sections are running.  Can 
someone explain why some sections of code are protected under MiNT but not 
under TOS?

Thanks,
Roger

Re: [Freemint-discuss] Mouse emulation via keyboard

[Peter S. <p....@sc...>]

I may or may not be related to this work but in Texel
ctrl-Insert should insert a row and shift-ctrl-Insert should
add a row.

It hasn't worked in Minat/XaAES as far as I can remember. It
does work in NAES and TOS.


Peter

Re: [Freemint-discuss] Mouse emulation via keyboard

[David G. <dga...@gm...>]

2018-06-07 19:38 GMT+02:00 Björn Buske <bj...@cu...>:
> Hello David,
>
> On 07.06.2018 12:04, David Gálvez wrote:
>> I'm fixing some issues with the mouse emulation through the keyboard,
>> I've seen that MiNT emulates a double left mouse button click with the
>> key combination "ALT+SHIFT+INSERT". TOS doesn't implement this. I'm
>> not sure if this is a good idea because now it's impossible to select
>> multiple files, you would do this with your mouse left clicking on the
>> objects while pressing the shift key.
>
> In TOS, you could achieve a double click by two fast consecutive hits on
> the INSERT key. That has always worked well for me.
>
>> I'm for removing the feature and imitate TOS behavior, I think the
>> original implementation is good enough and these changes at the end
>> confuse the user.
>
> Considering the above, and that the keyboard mouse is really only a last
> resort for most people, this should work well enough.
>

I've commited the changes. At the end the mouse emulation behaves like
TOS when using the left shift,
and I've left the old MiNT's double click feature when using the right
shift  (ALTERNATE+RIGHT_SHIFT+INSERT).

Re: [Freemint-discuss] Mouse emulation via keyboard

[Björn B. <bj...@cu...>]

Hello David,

On 07.06.2018 12:04, David Gálvez wrote:
> I'm fixing some issues with the mouse emulation through the keyboard,
> I've seen that MiNT emulates a double left mouse button click with the
> key combination "ALT+SHIFT+INSERT". TOS doesn't implement this. I'm
> not sure if this is a good idea because now it's impossible to select
> multiple files, you would do this with your mouse left clicking on the
> objects while pressing the shift key.

In TOS, you could achieve a double click by two fast consecutive hits on
the INSERT key. That has always worked well for me.

> I'm for removing the feature and imitate TOS behavior, I think the
> original implementation is good enough and these changes at the end
> confuse the user.

Considering the above, and that the keyboard mouse is really only a last
resort for most people, this should work well enough.

Peace!

--
      Björn Buske
--> bj...@cu... <--

[Freemint-discuss] Mouse emulation via keyboard

[David G. <dga...@gm...>]

Hello list,

I'm fixing some issues with the mouse emulation through the keyboard,
I've seen that MiNT emulates a double left mouse button click with the
key combination "ALT+SHIFT+INSERT". TOS doesn't implement this. I'm
not sure if this is a good idea because now it's impossible to select
multiple files, you would do this with your mouse left clicking on the
objects while pressing the shift key.

I'm thinking about removing this feature. Now normal double clicking
doesn't work but I've fixed this, so the double click emulation with
the shift key it's not essential.
I was thinking also about using the left shift for one purpose
(multiple file selection) and the right shift for another (double
click emulation), or another option would be when the shift key is
pressed make a short hit of the insert key a normal click and a long
one a double click.

I'm for removing the feature and imitate TOS behavior, I think the
original implementation is good enough and these changes at the end
confuse the user.

What do you think?

Re: [Freemint-discuss] Initmouse

[David G. <dga...@gm...>]

2018-06-04 19:09 GMT+02:00 Gerhard Stoll <ger...@gm...>:
> Hello,
>
> David start a thread on GitHub[1] about the parameter mousevec from Initmouse[2]. I agree with him and Thorsten that this is wrong in tos.hyp. I will change it and also describe the return value.
>
> I have one question: Is there somewhere the source code  from TOS <= Version 4.04 ? I saw that the MilanTOS have a type = 5. At the moment I don't know what it do.
>

I didn't find any information about Milan's type 5 in Initmous( ), but
I was thinking that may be you could ask Michael Schwingen, some years
ago while working on the Milan's USB driver I contacted him and he was
very helpful.

Re: [Freemint-discuss] Initmouse

[Miro K. <mir...@gm...>]

On 4 June 2018 at 19:09, Gerhard Stoll <ger...@gm...> wrote:

> I have one question: Is there somewhere the source code  from TOS <=
> Version 4.04 ? I saw that the MilanTOS have a type = 5. At the moment I
> don't know what it do.
>
>From the TOS 4.x source I have it gives this description:

*************************************************************************
*                                                                       *
*               EXTENDED RBP BIOS MOUSE INIT CALL                       *
*                                                                       *
*       entry:                                                          *
*                                                                       *
*       void    initmous(type,param,intvec)                             *
*       word    type                                                    *
*       long    param,intvec                                            *
*                                                                       *
*               type - key/abs/rel/off  mouse function requested        *
*                       4/  2/  1/  0   value                           *
*               param - address of parameter block                      *
*               intvec - mouse interrupt vector                         *
*                                                                       *
*                                                                       *
*       parameter block definition:                                     *
*                                                                       *
*       byte 0 - y=0 at top/bottom; if non-zero then y=0 at bottom      *
*               otherwise y=0 at top                                    *
*       byte 1 - parameter for set mouse buttons command                *
*       byte 2 - x threshold/scale/delta parameter                      *
*       byte 3 - y threshold/scale/delta parameter                      *
*                                                                       *
*       the following bytes are required for the absolute mouse only    *
*                                                                       *
*       byte 4 - xmsb for absolute mouse maximum position               *
*       byte 5 - xlsb for absolute mouse maximum position               *
*       byte 6 - ymsb for absolute mouse maximum position               *
*       byte 7 - ylsb for absolute mouse maximum position               *
*       byte 8 - xmsb for absolute mouse initial position               *
*       byte 9 - xlsb for absolute mouse initial position               *
*       byte a - ymsb for absolute mouse initial position               *
*       byte b - ylsb for absolute mouse initial position               *
*                                                                       *
*************************************************************************

-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

[Freemint-discuss] Initmouse

[Gerhard S. <ger...@gm...>]

Hello,

David start a thread on GitHub[1] about the parameter mousevec from Initmouse[2]. I agree with him and Thorsten that this is wrong in tos.hyp. I will change it and also describe the return value.

I have one question: Is there somewhere the source code  from TOS <= Version 4.04 ? I saw that the MilanTOS have a type = 5. At the moment I don't know what it do.

Gerhard

[1] <https://github.com/freemint/tos.hyp/issues/85>
[2] <https://freemint.github.io/tos.hyp/en/Screen_functions.html#Initmouse>

Re: [Freemint-discuss] Installing different cross-compiler versions

[Miro K. <mir...@gm...>]

What I do in my Makefile <https://github.com/mikrosk/m68k-atari-mint-build> is
installing the compiler the home directory so I can have any toolchain next
to each other. However now I think about it, Thorsten's solution (custom
suffixes) looks much better. I should add it to the scripts.

On 25 May 2018 at 09:16, David Gálvez <dga...@gm...> wrote:

> Is there a clean way to install different cross-compiler versions?
>
> I use version 4.8.4 under Linux Mint, but I'd like to try newer
> versions without loosing my current setup.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>



-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] Installing different cross-compiler versions

[Thorsten O. <ad...@th...>]

On Freitag, 25. Mai 2018 09:16:49 CEST David Gálvez wrote:
> Is there a clean way to install different cross-compiler versions?
> 
> I use version 4.8.4 under Linux Mint, but I'd like to try newer
> versions without loosing my current setup.
> 

I have it installed like this:

lrwxrwxrwx /usr/bin/m68k-atari-mint-gcc -> m68k-atari-mint-gcc-4.6.4
-rwxr-xr-x /usr/bin/m68k-atari-mint-gcc-4.6.4
lrwxrwxrwx /usr/bin/m68k-atari-mint-gcc-7 -> m68k-atari-mint-gcc-7.3.1
-rwxr-xr-x /usr/bin/m68k-atari-mint-gcc-7.3.1
lrwxrwxrwx /usr/bin/m68k-atari-mint-gcc-8 -> m68k-atari-mint-gcc-8.1.0
-rwxr-xr-x /usr/bin/m68k-atari-mint-gcc-8.1.0

Similar for the g++ compiler drivers. So by default, gcc-4.6.4 is used, 
because that is what most people still have installed, and i want it to use 
for emutos and freemint. When i want to test another version, i just do

make CC=m68k-atari-mint-gcc-7 CXX=m68k-atari-mint-g++-7

or

CC=m68k-atari-mint-gcc-7 CXX=m68k-atari-mint-g++-7 ./configure

if the project is autoconf based.

The binutils (as, ld etc) are the same for all compilers, from the 2.30 
release.

[Freemint-discuss] Installing different cross-compiler versions

[David G. <dga...@gm...>]

Is there a clean way to install different cross-compiler versions?

I use version 4.8.4 under Linux Mint, but I'd like to try newer
versions without loosing my current setup.

Re: [Freemint-discuss] nanoseconds delay function

[Roger B. <an...@xp...>]

Hi David,
On 19 May 2018 at 8:16, David Gálvez wrote:

> 2018-05-18 22:19 GMT+02:00 Roger Burrows <an...@xp...>:
> >
> > Something similar to this is done in EmuTOS, in case you haven't noticed. 
> I
> 
> I saw the this approach for the nanoseconds delay in the USB TOS
> drivers that took the idea from EmuTOS.
> 
> > think that, unless you really expect MiNT to run native on modern PCs,
> trying
> > to get a nanosecond-level value is a bit optimistic.
> >
> 
> Having 1 nsec granularity is very optimistic I know :-), but if my
> calculations are correct with a 060 at 66 Mhz you can have between 15
> nsec and 20 nsec granularity that is not so bad.
> 
Yeah, those seem about the correct numbers, but (apart from overclocking) that 
is as fast as you can go.  On a more typical Atari system (e.g. a TT at 32MHz), 
the granularity is about 250 nsec, and on an 8MHz ST, it's about 2500 nsec.  
For delays in the 100 nanosecond range (as required by some USB hardware), this 
will result in sub-optimal performance.  The only way around this that I've 
been able to come up with is separate binaries: for e.g. base STs you use a NOP 
instead of a delay loop.  On an 8MHz 68000 system, that would be a 500 nsec 
delay but that's as good as possible I think.

The real solution is not to use hardware that requires software delays.  But 
that isn't always an option.

Roger

Re: [Freemint-discuss] nanoseconds delay function

[David G. <dga...@gm...>]

2018-05-18 22:19 GMT+02:00 Roger Burrows <an...@xp...>:
>
> Something similar to this is done in EmuTOS, in case you haven't noticed.  I

I saw the this approach for the nanoseconds delay in the USB TOS
drivers that took the idea from EmuTOS.

> think that, unless you really expect MiNT to run native on modern PCs, trying
> to get a nanosecond-level value is a bit optimistic.
>

Having 1 nsec granularity is very optimistic I know :-), but if my
calculations are correct with a 060 at 66 Mhz you can have between 15
nsec and 20 nsec granularity that is not so bad.

> The EmuTOS approach is to calculate the number of loops for a millisecond delay
> value during EmuTOS initialisation.  Individual drivers multiply (rare) or
> divide it as required during driver initialisation.  If the MiNT mdelay()
> function is accurate, then you could use the same approach.
>

Similar to what MiNT does, it calculates the value "loops per second"
during the system's boot.

> The key thing is to make the actual delay loop itself as repeatable as
> possible.  EmuTOS does a subq.l from a register, which should be relatively
> immune to caching & pipeline variability.
>

The same than MiNT, this was imported from Linux-m68k years ago.

Re: [Freemint-discuss] nanoseconds delay function

[Roger B. <an...@xp...>]

On 18 May 2018 at 10:57, David Gálvez wrote:
> 
> I'd like to add a delay function for nanoseconds for driver to use,
> similar to udelay() and mdelay(). The problem is that the count loop
> calculation takes probably the time the driver needs to wait or may be
> more in our machines. So I was thinking to use another approach,
> adding two functions, one than calculates the loops given a number of
> nanoseconds, getloops4ns( ), then in the loading part of the driver
> code the driver gets the loops for the delays it needs, for example if
> it needs 150 ns and 500 ns it will do:
> 
> delay_150ns = getloops4ns(150)
> delay_500ns = getloops4ns(500)
> 
> and then when the delay is need it, it will call the second function
> that loops directly.
> 
> ndelay_loops(delay_150ns)
> ndelay_loops(delay_500ns)
> 
> so we don't have the loop calculation overhead in the use moment.
> 
> The ndelay() function still will be available.
> 
> I've attached the patch for you to take a look in case you want to
> comment anything.
> 

Something similar to this is done in EmuTOS, in case you haven't noticed.  I 
think that, unless you really expect MiNT to run native on modern PCs, trying 
to get a nanosecond-level value is a bit optimistic.

The EmuTOS approach is to calculate the number of loops for a millisecond delay 
value during EmuTOS initialisation.  Individual drivers multiply (rare) or 
divide it as required during driver initialisation.  If the MiNT mdelay() 
function is accurate, then you could use the same approach.

The key thing is to make the actual delay loop itself as repeatable as 
possible.  EmuTOS does a subq.l from a register, which should be relatively 
immune to caching & pipeline variability.

Of course, mdelay() may already do all this, I haven't looked, so apologies if 
I'm preaching to the converted.

Roger

Re: [Freemint-discuss] nanoseconds delay function

[David G. <dga...@gm...>]

2018-05-18 16:58 GMT+02:00 Thorsten Otto <ad...@th...>:
> On Freitag, 18. Mai 2018 16:33:28 CEST David Gálvez wrote:
>> the loop count would be 0
>> for any given value of nanoseconds below 1000, so the loop count will
>> be round up to 1 to get at least the delay requested.
>
> Yes, but if the loop count is so low that it is not really precise for
> microsecs, whats the purpose then computing it based on nanosecs? Even a
> 060@95Mhz is not 1000 times faster than a 68000.
>

OK, I understand that for slow CPUs a nanosecond delay calculation
doesn't make too much sense because only going through the loop once
is going to take at least 1 usec. But I think it makes sense for the
060 and ColdFire, I don't know yet about the 040.

> Also, given that one of the factors is already essentially shifted right by 28
> bits, that leaves only 4 bits, multiplied by the ns value, then divided by
> 1000, and thus only a range of 1-16 loops, if i read the code correctly.

I'm not sure what are you implying here, that ndelay() for the 060
doesn't make sense either?
With a 060 at 66 Mhz for 150 nsec I get a loop count value of 10.

If I implemented this I should do something for slow CPUs too. The
code could check if the kernel is running in a slow machine and to
don't make any calculation if it's the case, but I'm not so sure if
this function should do this, I could do it in getloops4ns( ) but not
in ndelay( ) because it will add still more overhead. I guess is up to
the driver's coder to check the machine or do specific machine
binaries and decide to use ndelay() or a couple of "nop" instructions.

Re: [Freemint-discuss] nanoseconds delay function

[Thorsten O. <ad...@th...>]

On Freitag, 18. Mai 2018 16:33:28 CEST David Gálvez wrote:
> the loop count would be 0
> for any given value of nanoseconds below 1000, so the loop count will
> be round up to 1 to get at least the delay requested.

Yes, but if the loop count is so low that it is not really precise for 
microsecs, whats the purpose then computing it based on nanosecs? Even a 
060@95Mhz is not 1000 times faster than a 68000.

Also, given that one of the factors is already essentially shifted right by 28 
bits, that leaves only 4 bits, multiplied by the ns value, then divided by 
1000, and thus only a range of 1-16 loops, if i read the code correctly.

Re: [Freemint-discuss] nanoseconds delay function

[David G. <dga...@gm...>]

2018-05-18 11:29 GMT+02:00 Thorsten Otto <ad...@th...>:
> On Freitag, 18. Mai 2018 10:57:10 CEST David Gálvez wrote:
>> I've attached the patch for you to take a look in case you want to
>> comment anything.
>
> Might be cleaner to write ndelay as
>
> #define ndelay(n)  ndelay_loops(getloops4ns(n))
>

Good idea, thanks!

> Also i'm not entirely sure whether the DIV_ROUND_UP macro is used correctly
> there, you are rounding up the number of loops there? Wouldn't that give way
> too large values on slower processors?
>

The aim of these functions (mdelay, udelay and ndelay) is not to be
very very precise but give "at least" the delay requested.
On slow CPUs (for example a 030 at 16MHz) the loop count would be 0
for any given value of nanoseconds below 1000, so the loop count will
be round up to 1 to get at least the delay requested.