textfiles/messages/ALANWESTON/1995/CIS08_05.txt

#: 21080 S1/General Interest
    30-Jul-95  17:54:47
Sb: #21030-#Ultra C V 1.2
Fm: ole hansen 100016,3417
To: Jost Eberbach 73502,2041 (X)

Hello Jost

I have been working with MW and OS-9/OSK since 1983. I haven't had that much
problem with their products. It sometimes needs some better documentation, but
it turns out to work very well in 99 % of the time. Fastrak for Windows suffers
from running under DOS/Windows. We use windows heavyly in my company too(WFW
3.11 and NT server 3.51) and it is not the most stable OS in the world. Most of
the problems I found in Fastrak for Windows, had to do with the TCP/IP- stack
being used and the programs loaded beside Fastrak.

regards

ole@danelec.dk

There is 1 Reply.

#: 21081 S1/General Interest
    31-Jul-95  06:36:34
Sb: #21080-#Ultra C V 1.2
Fm: Jost Eberbach 73502,2041
To: ole hansen 100016,3417 (X)

Hi Ole,

if you like a product or not depends on what you compare it with, and what you
are used to. Before I started using OS-9 two yrs ago, I used VAXELN from DEC
for realtime applications on VAXes, a plain C-compiler for applications running
without an OS on Digitalsignalprocessors, and Microsoft C for DOS and OS/2. I
liked the last the most, they were the most convenient to use. The least hassle
I had with the DSP, there was no OS to srew you. OS-9 and its development tools
are so inconvenient to use, the documentation is just a mess, and the realtime
performance is questionable.

I have no experience with Fastrak though, that was Christian's topic. I haven't
heard anything good about Fastrak though. Somebody told me you need two serial
lines and one Ethernet connection to run Fastrak. I'm not sure if this is true,
but if so, MW are definitely on the way to nowhere.

I've used PCbridge a lot, it's a product full of little bugs, and if you tell
MW about them, they simply don't care. I never understood why PCbridge needed
so much memory. A Borland or Microsoft C-Compiler can compile an  ANSI-C
program with only 640k of memory, whereas PCbridge needs more than 4 MB to
compile the same source code. Ridiculous. If you compile the same source on the
self-hosted OS-9 C-Compiler, it only requires about 500 kB of free memory.
Strange.

Jost

There is 1 Reply.

#: 21084 S1/General Interest
    01-Aug-95  16:48:38
Sb: #21081-#Ultra C V 1.2
Fm: ole hansen 100016,3417
To: Jost Eberbach 73502,2041 (X)

Hello Jost

I missed who complained about Fastrak. Sorry.

Yes it depends what you are used to. I like to develop for OS-9 using the
selfhosted tools, as they give you fast load/unload times.

Fastrak for windows only need the Ethernet-link to do download/debug. You only
need serail-lines, if you don't have a terminal hooked to the console- port of
the target, and you want to do rombug-debugging for IRQ-routines or
programs/drivers that stop time-slicing.

What type of hardware do you run OS-9 on ??

And whom have you tried to get help from at Microware ?? I normally get a fast
response, when I submit a problem.

regards

ole@danelec.dk

There is 1 Reply.

#: 21088 S1/General Interest
    03-Aug-95  10:54:10
Sb: #21084-#Ultra C V 1.2
Fm: Jost Eberbach 73502,2041
To: ole hansen 100016,3417 (X)

Hi Ole,

thanks on the clarification on Fastrak. I prefer the self-hosted tools too. Not
only do you get fast compilation and loading time, they usually have the least
bugs. Of course, you need a hard disk or a big non-volatile memory board to
have them available on-site.

I used OS-9 on the Motorola MVME162-board. Right now I don't use it at all, I
moved back to Germany from the USA (where I had lived for 2 yrs) at the
beginning of July. I'm looking for a new job right now. Maybe somebody who
reads this knows of an OS-9 related job for me?

In the US, I used to call the Microware Hotline. Bob Allen was pretty familiar
with MVME162 BSP, and helped me a lot. I was a little disappointed with the
BSP, because it didn't really support the onboard FLASH-EPROM of the MVME162,
and I expected a Bord Support Packed to support these kind of things. If you
use the FLASH-EPROM, you have a lot of non-volatile memory available, and don't
need any external storage devices for your applications. It's not big enough
for the self-hosted development tools though. The FLASH-EPROM also has the
advantage, that you don't have to carry a hardware programming device with you.
When MW came out with OS9 V3.0, they changed the ROM-boot procedures, which
created some trouble for me. Eventually I could fix everything, and the utility
I wrote for the FLASH-EPROM works with both versions now.

I'd really like to get my hands back on an OS-9 system, I have some kind of
love and hate relationship to it...

Ciao,

Jost

There is 1 Reply.

#: 21089 S1/General Interest
    04-Aug-95  06:02:14
Sb: #21088-Ultra C V 1.2
Fm: ole hansen 100016,3417
To: Jost Eberbach 73502,2041 (X)

Hello Jost

I like the MVME162 very well too. I work in a company called danelec nerby
Copenhagen. I have done so since 1981, and we distribute MOTOROLA VME as our
main buisness. Because MOTOROLA is about 3-6 months ahead with boards com-
pared to BSP's, I have done some minor ports to MVME147 and MVME162. I would
like to ask, if the code for the FLASH-EPROM is avaiable. If you are
interrested I have a driver for the DMA-chip in the VME2-chip. It allows for
moving DATA

between onboard-memory and VME-memory with up to 18-20 MB/Sec depending on the
speed of the memory you talk to on the VME-bus. Recently I ported the
MVME162-BSP to run on the MVME162FX(32MHZ and dma to the IP-bus). Yes it is
great to do the development selfhosted. You don't have to learn to
Operating-systems (target and host), you only concentrate on target. It is also
very few REAL-TIME os's that can become a development-platform in the field,
just by connecting a harddrive to it.

regards ole@danelec.dk

#: 21074 S1/General Interest
    26-Jul-95  02:34:02
Sb: #21028-#Ultra C V 1.2
Fm: Christian Daschill 100112,277
To: Bob van der Poel 76510,2203 (X)

I just received and tested version 1.2.1 of Fastrak, and the compiler potion of
it seems to have improved quite a bit. At least now I can get execution
performance similar to code generated by the old compiler, and compile (if not
link) times have shortened a bit. While this is a step in the right direction,
I still think that that File manager appendix solution does not work right. The
makefile editor chokes on compile options itself has put into the makefile
(-y=). While I agree with you that a general flame is not very fair, I don't
regret posting one, because at least it prompted some interesting replies.
Microware should really take a more active role in this forum, or at least get
their WWW page up and running. It would be so much easier to up/download bug
reports and fixes than having to wait for a new release.


There is 1 Reply.

#: 21076 S1/General Interest
    27-Jul-95  00:20:16
Sb: #21074-#Ultra C V 1.2
Fm: Bob van der Poel 76510,2203
To: Christian Daschill 100112,277 (X)

 >While I agree with you that a general flame is not very fair, I don't
 >regret posting one, because at least it prompted some interesting replies.
 >Microware should really take a more active role in this forum, or at least
 >get their WWW page up and running. It would be so much easier to up/download
 >bug reports and fixes than having to wait for a new release.

I couldn't agree more! A long time ago MW did have its own forum here on CIS.
However, they really didn't do anything to support it and eventually it just
disappeared. However, I don't know why they can't support this one. I'm sure
that the sysop would be more than pleased to have an "offical MW" library, etc.
But, maybe they are too busy to look after customers <g>.

There is 1 Reply.

#: 21078 S1/General Interest
    29-Jul-95  17:30:06
Sb: #21076-Ultra C V 1.2
Fm: Steve Wegert 76703,4255
To: Bob van der Poel 76510,2203 (X)

Bob,

Actually, it was never a forum ... but what's call a Display area. Just a few
menus and associated files.

I sure would like to have them around here as well. I had hoped I was making
some progress when they agreed to let me electronically post the contents of
"Pipelines".

Who knows ...


*- Steve -*


#: 21075 S1/General Interest
    26-Jul-95  02:37:12
Sb: #21023-Ultra C V 1.2
Fm: Christian Daschill 100112,277
To: Peter Eisele 100041,2304 (X)

Mr. Eisele,
Yes, I do use Fastrak under OS/2. So far I've got only the compiler part up and
running, because for the debugger via TCP/IP I have yet to get the ISP package
for the OS9 end of it. If you want, I can keep you posted about my progress.
As for the Dr.Keil hotline, I haven't found much useful stuff on it yet.

#: 21082 S1/General Interest
    01-Aug-95  09:01:24
Sb: #21073-#OS9 and Compuserve
Fm: W. Stein 100525,677
To: Steve Wegert 76703,4255 (X)

Hi Steve, hi Pete


Sorry for my late answer.
I downloaded Sterm 1.5.1 but I have some troubles in using the program.
Everytime I start the program and login into Compuserve the first lines
come in with no problems, but then the cursor went to the right side of
the screen and nothing happens any more. I allways had to disconnect the
modem to get out of Comuserve then I had to use Crtl e to get out of the
program.

Please give me a hint how to go on.

Thank you,
Stefan

There are 2 Replies.

#: 21083 S1/General Interest
    01-Aug-95  10:23:48
Sb: #21082-OS9 and Compuserve
Fm: Mark Griffith 76070,41
To: W. Stein 100525,677 (X)

Stefan,

When you're using Sterm, you need to make sure your Compuserve terminal type is
correct for your machine.  Normally, you should set your CIS terminal type to
'CRT' with whatever other options you want.  Steve Wegert here should be able
to help you more.

Sterm sends all characters through to your screen without any type of screen
control.  If you're using a terminal to talk to your OS-9 machine, you should
set it and your CIS terminal type to be tha same.  To set your CIS terminal, GO
TERMINAL.

Mark

#: 21086 S1/General Interest
    02-Aug-95  17:30:56
Sb: #21082-OS9 and Compuserve
Fm: Steve Wegert 76703,4255
To: W. Stein 100525,677 (X)

Mark Griffith, the author of Sterm, has given you a couple of good suggestions
to start with. Let us know how you do with those.

If you're still having problems, we'll give it another shot.

*- Steve -*


#: 21085 S1/General Interest
    01-Aug-95  16:54:59
Sb: os9000/386+adaptec
Fm: ole hansen 100016,3417
To:  100016,3417 (X)

hello OS9000/386 users

does anybody use OS9000/386 with ADAPTEC 1542C??

I have a PC with 16MBRAM 486DX4-100 and Adaptec 1542C, that denies to talk at
all to the SCSI-devices from OS9000. It works O.K. from DOS.

If yes to above, does anybody know how to configure the Adaptec 1542C ??

regards

ole@danelec.dk

#: 21087 S1/General Interest
    03-Aug-95  03:19:12
Sb: fastrak for windows
Fm: ole hansen 100016,3417
To:  100016,3417 (X)

Hello to all Fastrak for Windows users

How many on this board are using Fastrak for windows ?? and having problems
with it ??

I suggest we start a debat about this product and sign up a problem- report and
give it to Microware as a group.

I have just tried to run it under Windows 95, but creating a makefile in the
makefile-tool, eats up the harddrive when trying to save it !!!! and it is not
simple to regain the lost space.


As there is a lot of Hardware-platforms that can run Windows, I suggest we list
the hardware used, as well as the TCPIP-stack and version of Windows/
Windows95/WindowsNT or OS/2 !!!

regards

ole@danelec.dk

#: 21091 S1/General Interest
    04-Aug-95  11:14:26
Sb: #FLASH EPROM MVME162
Fm: Jost Eberbach 73502,2041
To: ole hansen 100016,3417 (X)

Hi Ole,

yes, the code for the FLASH programming utility is available.

It has the following usage options:

  -m <hex address> <hex size> : copies memory to flash
  -f <filename>               : copies binary file to flash
  -r <filename>               : copies flash into binary file
  -p                          : copies the bootable ramdisk at address 80000H
with a
                                 size of d0000H plus a copy of ROMBUG to flash,
                                 enabling booting from flash (V2.4 only)
  -q                          : copies the ramdisk at address 80000H
                                 with a size of c0000H to flash,
                                 contents of flash within address range
                                 0 to 0x3ffff will remain unchanged (V3.0 only)
  -c                          : erases flash

It's tested on MVME162 boards with FLASH chips from Intel and another
manufacturer. I forgot the name, but I have the manufacturer and device codes,
the program checks for them.
For the Intel chips the codes are 0x89 and 0xbd, for the others its 0x1 and
0x2a.

I'll send you the code for a program that reads the device code of your Flash
Eprom via email, ok?

Have fun,

Jost

There is 1 Reply.

#: 21092 S1/General Interest
    04-Aug-95  17:51:42
Sb: #21091-#FLASH EPROM MVME162
Fm: ole hansen 100016,3417
To: Jost Eberbach 73502,2041 (X)

Hello Jost

I look forward to the 'testprogram'.

How is the utility/driver available ??

regards ole@danelec.dk

There is 1 Reply.

#: 21093 S1/General Interest
    05-Aug-95  07:42:32
Sb: #21092-FLASH EPROM MVME162
Fm: Jost Eberbach 73502,2041
To: ole hansen 100016,3417

Hi Ole,

>>How is the utility/driver available ??<<

well, you can get the source code from me. If you only want to use it for your
own fun, and promise me not ot give it to anybody else, I can give it to you
for free. If you want to use it for your company, and maybe resell it with the
boards you sell, you would have to reimburse for giving you the copyright.

Does the testprogram work? Do you get good manufacturer/device codes?

Ciao,

Jost

#: 21077 S6/Applications
    27-Jul-95  21:43:07
Sb: #21008-Zip Bug fixed(?)
Fm: Mike Haaland 72300,1433
To: David Breeding 72330,2051 (X)

About that problem with ln.c:

Yes, I did find the problem before.

ln.c should really be avoided if at all possible.  It does make a nice move
command tho.  But I don't suggest using it for anything else.

 - Mike -

#: 21079 S7/Telecommunications
    29-Jul-95  17:42:52
Sb: rz/sz considerations
Fm: David Breeding 72330,2051
To: Bob van der Poel 76510,2203 (X)

Bob,

I saw your query on comp.os.os9 about sometimes losing data on huge text files.

I wonder what telecom program you are using.  Offhandedly, I'd guess you would
be using the OSTerm offshoot, but if you are using STerm, there may be one
other possibility.  I'm not sure how any of the other telecom packages besides
STerm handle this, though.

In STerm, when you are using disk capture, when it writes to disk, it sends
XOFF.  But your modem, if set for Hardware flow control, does not recognize
XOFF, I suppose.  My guess s to what happens is that XOFF is passed through to
the other system, and it, perhaps, stops, but, as you suggested, the modem has
lots of stuff still in its buffer if you have extensive compression, so it just
keeps on pumping.

Of course, if your serial driver does automatic RTS/CTS flow control, this
should not be a problem.  However, my system, a Delmar, did not offer this flow
control, and as it came out, had an extremely small buffer.  I disassembled and
rewrote my driver.  Actually, when I upped my buffer to 2 K, it seemed to
straighten itself out (I think you said you had a 4 K buffer?).  I did add a
rough auto RTS/CTS implementation, and now, I have not had any trouble.  Let's
see, though, actually, I cannot remember downloading any really hugh text, and
the CIS connection I use does not support data compression (and often not even
14.4 but 9600 {:-[ ) so I might run into the same thing you are mentioning, but
I'm hoping not.

I guess I took too long to say what I was trying to say, but it could be that
your driver does not offer automatic RTS/CTS flow control, and coupled with the
possibility that your comm program might not, either, (especially if you are
using STERM), you may be having a problem of mismatched flow control.

It does seem that you are somewhat on the right track of the problem. I
remember in the docs for rz/sz, the testers found that if the coco had a too
large a buffer in the driver, that often the sender would get so far ahead of
the coco that it could never figure out what block it needed to resend and
would error out, so, as I said, you are pretty much on track as to the nature
of the problem..

                         -- David Breeding --
       CompuServe : 72330,2051             Delphi :  DBREEDING
    *** Composed with InfoXpress/OSK Vr. 1.02 & VED Vr. 2.4.0  ***

Press <CR> !>