fzsitvay@techbook.com (Frank Zsitvay) (09/26/90)
ok, get this. decided to try installing bascom 7.0 on the rainbow, just for the snowball-chance-in-hell that it might work... bc7 comes on 12 disks and you need to use a special setup program to install all of the needed files onto the hard disk. this can take up to 14 megabytes, which was my first obstacle since i only have a 10 meg drive on my 100+. you can trim the compiler down so it takes less space, but that didn't help me either... the microsoft installation program requires the disks to be in the same state they are when you get the compiler. (i.e. each disk must contain certain files, etc.) i don't have the rx50 driver for my at to read and write rx50 disks, so i can only use 180k ssdd disks, and setup didn't know how to deal with this situation. soooooooo.... i tried another road. with the system having long since been setup on my at, i thought about copying the already installed compiler onto 180k disks and tranferring it that way. main problem is that the qbx editor/compiler itself is 317k, and a lot of the libraries are in the 250 to 270k range. none of the local portland board i know of have the rx50 driver, and i wish i had it right then. i tried crunching the qbx environment with lharc, but the smallest i could make it was 270k, still too big. the libraries, however, did crunch down to 150k each, so i transferred them that way, using lharc to uncrunch them on the rainbow. (talk about taking a long time to do that) the command-line version of the compiler and the linker went over with room to spare. this left me without an editor, and i sure wasn't going to use edlin to generate source code. so i copied vde version 1.53 over, and configured it to work on a generic msdos machine. it's kinda slow when run in this mode, but it functions. (the reason why i hadn't done this until now was that i tried copying version 1.31 over some time ago, and it didn't work too well. 1.53 works fine on the rainbow.) so, with most of the essentials on the rainbow, i wrote a "hello, world" program, compiled it (which worked) and linked it (which also worked.) this surprised me since neither the compiler or the linker would work on my corona, which is supposed to be an ibm clone. it locks the corona good and tight. i executed the "hello" program, and it gave be back the dos prompt. no screen output. talk about frustration, after having gone this far. well, all hope was not lost. i was under the impression that bascom used bios calls for simple print statements, but apparently i was wrong. looking through the manuals, i found that you could open device "scrn:" as a file and write to it like a file, but your output would go to the screen instead of a file. i tried that, compiled, linked, and ran the program again. same results. obviously that wasn't the problem. or so i thought. these is another device called "cons:" which i remember worked for the interpreter, but the bascom manuals implied that it was a bidirectional version of devices kybd: and scrn:. well, i decided to give it try, figuring i had nothing to lose. it worked. now i can write to the screen through this device. since that worked, i tried file i/o. that works, too. so does all of the math functions. now, since writing to the screen this way is somewhat restrictimve, i was wondering if code blue would allow me to use the print function. to what extent does code blue go to in emulating an ibm?? does it do anything for the serial ports?? i'm glad now that i have a working basic compiler on the rainbow, but now i want to see how much more can be done to improve this setup. where can one get a copy of code blue, and how much does it cost?? -- fzsitvay@techbook.COM - one of these days i'll get it right... Version 2 of anything is usually the version that works.