It's the clock, just the clock.  It's a square wave usually, the old up and
down.  Pin 19, CLK, on the Intel 8086 DIP

When emulating the speed of a 8088, 8086, 80286,... CPUs you need to
emulate the Clock cycles

-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_...etc...

So sticking in NOPs may not work.

 -_nopnopnop-_nopnopnop-_nopnopnop-_...etc

...the Clock cycles are still too short.  You want...
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_...of the correct cycle length,
..the infamous buss instruction T-state lengths are what this is about.

You need to emulate at the CPU buss T-state level.

I have a DOS simulator package of that 80286.  It lets you step through an
instruction's execution T-state by T-state.  It's very instructional.  I
did not find a 80386 version or 80486.  I did find and purchase 18 years
ago a book "80x86 Architecture &
Programming<http://www.amazon.com/80X86-Architecture-Programming-Reference-Implementations/dp/0132454327>"
that had the T-state information for a 80486.

References:
http://www.cpu-world.com/info/Pinouts/8086.html
http://matthieu.benoit.free.fr/cross/data_sheets/Intel_8086_users_manual.htm
http://www.ece.msstate.edu/~reese/EE3724/lectures/bustran/bustran.pdf
http://en.wikipedia.org/wiki/Intel_8086
http://en.wikipedia.org/wiki/X86_architecture
https://docs.google.com/viewer?url=http%3A%2F%2Fdatasheets.chipdb.org%2FIntel%2Fx86%2F808x%2Fdatashts%2F8088%2F231456-006.pdf

Now you can program your own emulator.

Cheers
John S Wolter
------------------------
LinkedIn: johnswolter <http://www.linkedin.com/in/johnswolter>

- Mailto:johnswol...@wolterworks.com
- Desk: 734-408-1263
- USA, Eastern Standard Time, -5 GMT, -4 GMT DST



On Thu, Jan 3, 2013 at 5:52 PM, Mark Littlejohn <e...@zip.com.au> wrote:

> There should also be made a distinction between real time input and real
> time output and servo loop. If you are capturing timing events you really
> only need to respond to an event and store a time for later processing. I
> usually use a microcontroller and write a routine around its interrupts so
> that it can respond easily down to microseconds and give good resolution
> (this has been mainly for medical projects that are not particularly high
> frequency). So you have the interrupts running code real time, and the
> normal loop crunching the numbers and providing output.
> Real time output can be set up very much like above, where the internal
> counter triggers the interrupt which outputs a value. Say you want to
> output a particular current at a particular time.
> Servo is much harder because it must respond to an input, and process it
> to give an output, at a defined frequency response. This is usually
> demonstrated with the "balancing hammer" where the servo balances a hammer
> on its end. There are systems that achieve this even if the hammer has a
> jointed hinge in the middle. I have even heard of it being done where there
> are two joints. This is a bit like trying to reverse a 3 bogey semi-trailer
> up a country lane at freeway speed.
> When you see Windows attempt the hammer demo you can see that every
> keyboard press or mouse movement causes instability, and opening a browser
> can make the hammer fall over. Often a simple microcontroller can beat even
> a really fast powerful computer, mainly because you can use the interrupts
> which I have found are almost impossible to "get at" in computers.
>
>
>
>> "Real time" simply means "guaranteed to respond to an external event
>> within a specified period".  What time period is required?
>>
>> >> But on modern hardware, "other time-critical programs that will carve
>> >> out slices of CPU time" are likely a "Who cares?" issue.  Commonly
>> >> used hardware is orders of magnitude faster than the machines DOS was
>> >> made to run on, and there are cases like games where you might
>> >> specifically *want* to steal CPU slices, because otherwise your game
>> >> runs *too* fast and is unplayable. .
>> >>
>> > I have had to do this once, when writing an assembly code driver for a
>> > digital rotation encoder. The read cycle had to be slowed down by a
>> > specified number of NOPs to allow the register to load. The problem is
>> > that when a program is monitoring response devices such as the mouse and
>> > keyboard and presenting an animated display to the user, even a
>> > millisecond lost to some other program is a disaster. As I can often see
>> > the system "blink" on modern PCs running Windows and even Linux, I'm
>> > reasonably certain that I can't trust them to be accurately recording
>> > reaction times. One of my colleagues thought that she had solved the
>> > problem by buying an expensive test battery until I showed her the
>> > "uncertainty" factor that came with every response recorded.
>>
>> How accurately do you *need* to be recording reaction times?
>>
>> For that use case, I'm not sure I'd try to run DOS on top of Linux,
>> even with a Linux version modified for RTOS usage.
>>
>> The best option might be custom monitoring software running directory
>> on the RTOS, without DOS in the loop.
>>
>>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122712
> _______________________________________________
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Reply via email to