#: 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 . 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 : copies memory to flash -f : copies binary file to flash -r : 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 !>