[cctalk] Re: best C compiler(s) for varied vintage programming
I'll pull it out and take photos of the mainboard later. Ve shall see. That scary monster sure didn't look like a pc to me. On Tuesday, December 27, 2022, 11:15:06 AM EST, geneb via cctalk wrote: On Tue, 27 Dec 2022, Chris via cctalk wrote: > Apparently Northstar's dos is yet another amended version of ms-dos. I > suppose it was supplied for basic tasks, as it couldn't possibly provide > all the features supplied by Netware. So whereas this may not be as > difficult as I thought, there are still significant hurdles. The floppy > drive's transfer rate is 250kbits/s. That probably isn't significant. Based on what I've read, the Dimension is "fully" PC compatible, which leads me to believe that there's not going to be any compatibility issues regarding screen i/o.. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!
[cctalk] Re: best C compiler(s) for varied vintage programming
On 12/26/22 23:08, Chuck Guzis via cctalk wrote: : "Lattice C was ported to MVS, VMS, Unix, OS/2, Amiga, Atari ST, and Sinclair." The TRS-80 You left out the TRS-80... bill
[cctalk] Re: best C compiler(s) for varied vintage programming
On 12/27/22 01:02, Steve Lewis via cctalk wrote: > asically: programming on an actual vintage MS-DOS system is very painful > these days. For starters, the 8.3 filenames and lack of COPY-PASTE. > True, there are some vintage editors that will have a form of copy-paste. > Another issue is some of those old editors are limited to 32KB or 64KB > files (which with comments, sometimes you might get to pretty large files), > and such old editors might not have multi-file support (like having .h and > .c open at the same time). I programmed many years in the "old DOS days" > with 8.3 filenames - reliving that wasn't for me. BUT, it is do-able. 8.3 was luxurious. How about 8 with no period or 6.3 or just trays I will say this about the old systems--by the time you sat down at the keypunch or sent your code to the keypunch pool, you had desk-checked your code carefully because it might be hours before you got to see the result. It instilled a certain discipline. You want interactive terminals? How about a TTY? The point is that a good programmer back in the day had his code written before setting pencil to coding form. It used to be a joy watching the good veteran programmers sit down at a keypunch (the work is essentially "blind") without so much as a set of notes and turn out a complete program module from memory. To this day, my choice of editor is Joe on Linux--mostly because I need some program to get things down in bits. I'm not a perfect touch-typist, as my high-school summer session typing teacher would have told you. A simple editor works wonders if you've already written the code in your head. One of the joys of programming low-end MCUs in my dotage is that I can write code pretty much from scratch. Modern WYSWYG editors with all of their styles and fonts are more of a burden to me because I can't simply write things down; they have to look good also. For example, my idea of a table may not match the canned version in the editor, so I have to struggle. Granted, I'm old and should be rummaging around for a couple of pennies for my eyes. 026s and 407s have long become museum curiosities--and I suppose that I should join them. But I had to have my say. Now get off my lawn! --Chuck --Chuck
[cctalk] Re: best C compiler(s) for varied vintage programming
On Tue, 27 Dec 2022, Chris via cctalk wrote: Apparently Northstar's dos is yet another amended version of ms-dos. I suppose it was supplied for basic tasks, as it couldn't possibly provide all the features supplied by Netware. So whereas this may not be as difficult as I thought, there are still significant hurdles. The floppy drive's transfer rate is 250kbits/s. That probably isn't significant. That is 5.25" MFM/"Double density" or 8" FM single density.
[cctalk] Re: best C compiler(s) for varied vintage programming
On Tue, 27 Dec 2022, Chris via cctalk wrote: Apparently Northstar's dos is yet another amended version of ms-dos. I suppose it was supplied for basic tasks, as it couldn't possibly provide all the features supplied by Netware. So whereas this may not be as difficult as I thought, there are still significant hurdles. The floppy drive's transfer rate is 250kbits/s. That probably isn't significant. Based on what I've read, the Dimension is "fully" PC compatible, which leads me to believe that there's not going to be any compatibility issues regarding screen i/o.. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://scarlet.deltasoft.com - Get it _today_!
[cctalk] Re: best C compiler(s) for varied vintage programming
I don't have it handy, but there was a copy run by the Gimpel family near Philadelphia (don't remember the company name) whose well-respected C products worked on IBM DOS, OS/2, MAC and Amiga. I have versions for most if not all. So, I'd say that "general purpose" can yet be broken down by processor but there were companies who ported their C's to various platforms, at least in the microcomputer / microprocessor world. Bill On Tue, Dec 27, 2022 at 10:11 AM Warner Losh via cctalk < cctalk@classiccmp.org> wrote: > On Tue, Dec 27, 2022, 7:31 AM Chris via cctalk > wrote: > > > Apparently Northstar's dos is yet another amended version of ms-dos. I > > suppose it was supplied for basic tasks, as it couldn't possibly provide > > all the features supplied by Netware. So whereas this may not be as > > difficult as I thought, there are still significant hurdles. The floppy > > drive's transfer rate is 250kbits/s. That probably isn't significant. > > > The Dimension machine you have is PC compatible, more or less, according to > the various places I found last night. > > In that era, MS-DOS provided part of the solution. It did the program > loading and filesystem services. The ROMs provided the rest. The difference > between the different MS-DOS versions for things like the Rainbow, Victor, > Tandy etc were all in the IO.SYS file that handled the device drivers for > the machines in question. It also handled the different floppy formats and > often times hid the second stage boot loader in funky, machine specific > places. > > In that era too a lot of software was in the ROMs and that's where 90-95% > of the non-timing incompatibility was: The ROM routines weren't complete in > the early clones (of which the Dimension was). And that was before there > was one video card standard, so going direct to video memory was tricky > (possible, and a lot of people did it, but there were many articles about > how to probe for what's there, how to structure your code to make it less > hard but still fast, etc). > > I suspect there is more there than you think, but probing it, or recreating > the boot disks may require some unique to the machine fiddling... > > Warner > > > >
[cctalk] Re: best C compiler(s) for varied vintage programming
On Tue, Dec 27, 2022, 7:31 AM Chris via cctalk wrote: > Apparently Northstar's dos is yet another amended version of ms-dos. I > suppose it was supplied for basic tasks, as it couldn't possibly provide > all the features supplied by Netware. So whereas this may not be as > difficult as I thought, there are still significant hurdles. The floppy > drive's transfer rate is 250kbits/s. That probably isn't significant. The Dimension machine you have is PC compatible, more or less, according to the various places I found last night. In that era, MS-DOS provided part of the solution. It did the program loading and filesystem services. The ROMs provided the rest. The difference between the different MS-DOS versions for things like the Rainbow, Victor, Tandy etc were all in the IO.SYS file that handled the device drivers for the machines in question. It also handled the different floppy formats and often times hid the second stage boot loader in funky, machine specific places. In that era too a lot of software was in the ROMs and that's where 90-95% of the non-timing incompatibility was: The ROM routines weren't complete in the early clones (of which the Dimension was). And that was before there was one video card standard, so going direct to video memory was tricky (possible, and a lot of people did it, but there were many articles about how to probe for what's there, how to structure your code to make it less hard but still fast, etc). I suspect there is more there than you think, but probing it, or recreating the boot disks may require some unique to the machine fiddling... Warner >
[cctalk] Re: best C compiler(s) for varied vintage programming
Apparently Northstar's dos is yet another amended version of ms-dos. I suppose it was supplied for basic tasks, as it couldn't possibly provide all the features supplied by Netware. So whereas this may not be as difficult as I thought, there are still significant hurdles. The floppy drive's transfer rate is 250kbits/s. That probably isn't significant.
[cctalk] Re: best C compiler(s) for varied vintage programming
I haven't followed the full thread here, but perhaps this might help: when I ported DestinyHunter (destinyhunter.org) from the 6502-based PET to the IBM PC, I gathered some notes on that process here https://destinyhunter.org/ibm-5150-development-notes/ Basically: programming on an actual vintage MS-DOS system is very painful these days. For starters, the 8.3 filenames and lack of COPY-PASTE. True, there are some vintage editors that will have a form of copy-paste. Another issue is some of those old editors are limited to 32KB or 64KB files (which with comments, sometimes you might get to pretty large files), and such old editors might not have multi-file support (like having .h and .c open at the same time). I programmed many years in the "old DOS days" with 8.3 filenames - reliving that wasn't for me. BUT, it is do-able. I did try Turbo C 2.0 to make a real-mode .com (the notes in the page setup a 486-emulation in 86BOX with a DOS 6.0 configuration). Since I had a project that already used long filenames, that was another reason I wanted to cross-compile from a modern system instead. If all the existing code was already in 8.3 filenames, maybe it would have been less of an issue. But in any case, the modern system is faster, so you can experiment and compile things in a few seconds -- but then you have to transfer the resulting binary to your vintage system (I was able to use FTP, but I can understand that' not being easy for everyone). As another option: I came across the WATCOM C/C++ compiler, but (AFAIK) it's no longer maintained and getting a "reliable" download of it was a challenge. All I recall was I ended up using version 1.9 instead of 2.0. It is an IDE of sorts, though I mostly still used an external editor (notepad++). I can't recall why I didn't use Lattice - maybe it/was Commercial? Another compiler is the Intel iC-86, but you end up having to use the Borland TLINK anyway with that. NOTE: I think both Turbo C and WATCOM C have code generation options for 80186 - although offhand I can't think of any specific code that would need/use 80186 features.And each of these compilers does have a slightly different variation of C (with some settings dials inside on how compliant to be). Another note: despite using _TINY_, Borland C is still going to make an EXE - you have to use Microsoft DOS 2.10 - 3.21 to run EXE2BIN to convert it to a .com. The next mess is "standard libraries." Borland was great, but they royally confused a whole generation of developers on what the "standard C library" actually meant. Like, conio.h is not standard. But regardless - when implementing the "C standard library" for disk I/O, no one would be re-implementing FAT -- that'd miss the whole point of having a "DOS". They'd implement it in terms of software interrupts - that hopefully were compatible between PC/DR/MS-DOS."Self Booters" (like early versions of Zork, Microsoft Flight Simulator, early versions of King's Quest) had to implement their own file systems (and it's why they aren't easy to copy, since they use a non-MS-DOS format). Thinking about it now, I think making a self-booter disk of DestinyHunter might be an interesting challenge. For reference, some notes are as follows: https://www.cs.uaf.edu/2011/fall/cs301/lecture/11_18_bootblock.html http://philipstorr.id.au/pcbook/book1/post.htm That is, the IBM PC BIOS is pre-programmed to examine the first sector for code, and do the work of copying 512 bytes to RAM and running it. What you choose to do in that boot loader is then up to you (or the OS) -- which can't be any MS-DOS interrupt calls. I'm not sure what existing code could be borrowed to read additional bytes from the disk (an annotated disaassembly of the BIOS, or examining the MS-DOS code in github maybe as a starting point). Nothing in the "standard" library of Borland Turbo C or WATCOM C, etc. really helps here (none of the fopen, fscanf, stuff). So it's not that the compiler you're seeking doesn't exist -- but some "off the shelf" utility functions doesn't readily exist. You'd have to borrow or re-implement much of what MS-DOS is already doing (if the 180KB format was ok). Again, the early MS-DOS source code is out on github as a starting reference... As far as writing it specifically to the first sector of a 5.25" disk -- I never found a "USB adapter" for a 5.25" disk drive; plenty for the 3.5" drives, but maybe the 525" drw too much power for USB?). Good Luck! On Mon, Dec 26, 2022 at 8:20 PM Chris via cctalk wrote: > It cannot rely on bios/ms-dos services for compiling preferably. Iow I'd > like to perform what I want to do on the target machine itself, LOL which > is hysterical as I've never even seen it boot even once. I could complie on > a standard pc I suppose and pop a disk in the Northstar Dimension. It would > be nice if it's optimized for it's 80186. Or at least supports it's > instructions. My goal is to get MINIX running on it, as
[cctalk] Re: best C compiler(s) for varied vintage programming
The server itself is not pc compatible. The plug in card (motherboards) are what are meant to run ibm pc software. The server runs Netware-86 or a tinkered with version, maybe strait out of the box, but regardless N-86 is super duper unobtainium. I suppose what happens is the machine is started, the server boots. The motherboards then are initialized, served up ms-dos, served up application software. Externally each of the server's motherboard cards has some kind of terminal attached (the terminal is a Northstar keyboard that looks identical to a Keytronic 5151? But for the logo. And has a modular connector. The monitor is identical to those seen with the Eagle-2 again but for the logo. I have 1 of the keyboards, an IBM 5151 monitor, but nothing else. There may have been an intermediary circuit board that tied the k/b+monitor together and interfaced to the back of the server (the expansion card actually). My unit was kind of banged up but has a hard drive, the most banged up part of the whole shlameel. It belonges to a hassidic man in Chicago who was running his bisiness with it I assume. It got beat up in shipping, couldn't complain as he sent me it free but asked what 2 hours of his time was worth after the fact. I pp'd him 50$. The dimenaion mobo doesn't look like any pc anyone has ever aeen. In fact the innards are a bit of a horror movie. The p/s is big and nasty and is unenclosed. There's all kinds of shit hanging of the mainboard, including the pc-cards. It'll be a work in progreas for some time. Loads of fun though. Dead bugs. On Tuesday, December 27, 2022, 12:50:19 AM EST, Fred Cisin via cctalk wrote: If it can run PC software, then it can handle DOS disk I/O. But BIOS and/or direct hardware access may be totally incompatible. On Tue, 27 Dec 2022, Chris via cctalk wrote: > All I can say with some certainty is this thing will read ms-dos formatted > floppies. How else could it run ibm pc software if it didn't. The individual > jumbo isa card-motherboards are doled out their rations internally from the > server departmemt. No drices excwpt what tje server itself has.
[cctalk] Re: best C compiler(s) for varied vintage programming
At no point was I asking for or expecting a recommendation of a compiler with an ide. In fact it never entered my mind. If QuickC would run lock, stock, and barrel on a Northstar Dimension I wouldn't be asking for anything. I did say the compiler couldn't rely on typical IBM PC facilities to talk to the screen. Then you brought up disk (file) i/o, which was a perfectly valid point, and I said so. So in the final analysis I guess I'll be writing w hatever on a "real" pc. Sorry for wasting the list's time. What I wanted may not exist. Were you referring to the Poppy? How did programs talk to the disk drive? On Tuesday, December 27, 2022, 01:04:00 AM EST, Chuck Guzis via cctalk wrote: On 12/26/22 21:23, Chris via cctalk wrote: > I'm not conflating anything. Most of the time screen i/o is accomplished >using bios calls. That's with ms-dos/pc-dos software (whatever the percentage >of the time). But it's feally irrelevant if it's dos compatible or not, as any >code can make use of the bios subroutines. That's an immediate show stopper if >you can't get feedback from the compiler. Please no references to early time >sharing Sure you are. Lattice had no IDE; it was strictly command-line driven--if the input required a text editor, it was up to you to furnish one. If the MSDOS hosting system used a BIOS, fine. But not all did. Consider the MSDOS platforms that interfaced to a simple serial terminal. In any case, console and file I/O is done via the DOS API. How DOS does things is no concern of the compiler. This is the way before fancy screen I/O that we did things. Before that, it was with punched cards. --Chuck
[cctalk] Re: best C compiler(s) for varied vintage programming
On 12/26/22 21:23, Chris via cctalk wrote: > I'm not conflating anything. Most of the time screen i/o is accomplished > using bios calls. That's with ms-dos/pc-dos software (whatever the percentage > of the time). But it's feally irrelevant if it's dos compatible or not, as > any code can make use of the bios subroutines. That's an immediate show > stopper if you can't get feedback from the compiler. Please no references to > early time sharing Sure you are. Lattice had no IDE; it was strictly command-line driven--if the input required a text editor, it was up to you to furnish one. If the MSDOS hosting system used a BIOS, fine. But not all did. Consider the MSDOS platforms that interfaced to a simple serial terminal. In any case, console and file I/O is done via the DOS API. How DOS does things is no concern of the compiler. This is the way before fancy screen I/O that we did things. Before that, it was with punched cards. --Chuck
[cctalk] Re: best C compiler(s) for varied vintage programming
OK. You guys are all over the place. I do think you are confusing Compiler and Run Time first off. I ran Turbo C on my DEC Rainbow which had MS-DOS compatibility but not PC-DOS/PC BIOS compatibility. TCC would run in this environment (modulo it's use of INT 18 which I did a hack to allow on the Rainbow which used that interrupt for its screen code). TCC would read files off the disk with MS-DOS calls to open the file, etc. Same with writing. It worked on all machines because it did this. It was no different than MASM or other command line compilers at the time which generally (but not always) avoided PC BIOS calls. For the Rainbow, if I wanted to use vanilla DOS, I used the default run time. If I wanted to use an optimized version that I had back then (but haven't seen recently), I had to add a bunch of command line flags to get it to swap out what's the equivalent of libc.a and crt0.o on Unix/Linux. So, you could write a program than runs on any MS-DOS computer. Or, you could use your own libc to do the low-level stuff and have it run on a specific computer. It would still need to be MS-DOS (though CP/M 86 was possible with a .EXE to .CMD converter and there were also hacks to convert the .OBJ files to .o files that some Unix-based loaders could cope with, but I really haven't seen those anywhere in a long time, though I've not needed to look). DOS handled all the weird formatting differences between a DEC Rainbow, IBM-PC and whatever other weird thing TCC ran in (at least in the early days). There was also no official support for the DEC Rainbow after the first TCC release (which is why I had to do the INT 18 hacks). If you wanted to run on raw hardware, though, you'd need to write a boot loader, which is way beyond the scope of this email :). Of course, you can use dosbox or similar to run the old-school compilers / assemblers to generate the binaries on Linux / FreeBSD. I've done this lately... So if it is running MS-DOS, there's a chance you can run TCC at least on it (at least early versions). The early versions were more MS-DOS-centric and less 'only runs on PC-DOS' at least. I moved on to FreeBSD/Linux around this time, so I don't know how things evolved. Warner On Mon, Dec 26, 2022 at 10:40 PM Chris via cctalk wrote: > Ok now some things are coming back. Borland compilers work from the > ms-dos command line. Bcc 5.5? came with an old textbook. But the Dimension, > although I assume has some sort of command line structure, doesn't have an > ms-dos command line. So let's just say tje program got up and running, even > compiled code (all that assumes a lot). How is it going to save the .obj > file. The file structure of Northstar dos would have to be identical to > ms-dos, 8.3. It would have to be able to read an ms-dos formatted disk. And > the main kicker is the object codw format, creating a 256 byte psp. Amongst > other shit I have to assume. Or does ms-dos itself handle some of that. Is > a compiler'a executable format compatible with this. This thing is binary > compatible in a broad sense. But can you simply for instance run Linux > wares on bsd?
[cctalk] Re: best C compiler(s) for varied vintage programming
If it can run PC software, then it can handle DOS disk I/O. But BIOS and/or direct hardware access may be totally incompatible. On Tue, 27 Dec 2022, Chris via cctalk wrote: All I can say with some certainty is this thing will read ms-dos formatted floppies. How else could it run ibm pc software if it didn't. The individual jumbo isa card-motherboards are doled out their rations internally from the server departmemt. No drices excwpt what tje server itself has.
[cctalk] Re: best C compiler(s) for varied vintage programming
All I can say with some certainty is this thing will read ms-dos formatted floppies. How else could it run ibm pc software if it didn't. The individual jumbo isa card-motherboards are doled out their rations internally from the server departmemt. No drices excwpt what tje server itself has.
[cctalk] Re: best C compiler(s) for varied vintage programming
Ok now some things are coming back. Borland compilers work from the ms-dos command line. Bcc 5.5? came with an old textbook. But the Dimension, although I assume has some sort of command line structure, doesn't have an ms-dos command line. So let's just say tje program got up and running, even compiled code (all that assumes a lot). How is it going to save the .obj file. The file structure of Northstar dos would have to be identical to ms-dos, 8.3. It would have to be able to read an ms-dos formatted disk. And the main kicker is the object codw format, creating a 256 byte psp. Amongst other shit I have to assume. Or does ms-dos itself handle some of that. Is a compiler'a executable format compatible with this. This thing is binary compatible in a broad sense. But can you simply for instance run Linux wares on bsd?
[cctalk] Re: best C compiler(s) for varied vintage programming
I'm not conflating anything. Most of the time screen i/o is accomplished using bios calls. That's with ms-dos/pc-dos software (whatever the percentage of the time). But it's feally irrelevant if it's dos compatible or not, as any code can make use of the bios subroutines. That's an immediate show stopper if you can't get feedback from the compiler. Please no references to early time sharing Basically when I say PC I mean in the sense of IBM PC. Unless I was being careless I wouldn't refer to a Zenith Z-100 as a pc. You alluded to a program needing hosting on a specific platform. Off the top of my head I couldn't think of a means whereby a compiler could be generic enough to run on a variety of computers that simply have an 80x86. I have to reread Fred's post ... If you wrote 8086 cose in the 70s it was 16 bit. Gcc compiles to 16 bit? Frankly can't remember but am having difficulty understanding why it would. I guess I'm forgettting gcc owes it's existence to Richard S., not Linus T. On Monday, December 26, 2022, 11:09:04 PM EST, Chuck Guzis via cctalk wrote: On 12/26/22 19:46, Chris via cctalk wrote: > Not all compilers were designed specifically to run on an ibm pc. If the >compiler itself utilzes bios fumction calls to display anything, it will not >run on anything but an pc or compatible. If you're referring to saving object >code to disk, well I giess that's a good question. But there were compilers >prior to tje 5150, and even after, a few of which, I have to imagine, had some >other means to save files. > It seems to me that you're conflating the IBM PC BIOS and MS-DOS. LC was available for a wide variety of platforms. We ran Lattice on a non-PC compatible (80186 with no memory-mapped display) To quote the page I pointed to: "Lattice C was ported to MVS, VMS, Unix, OS/2, Amiga, Atari ST, and Sinclair." My point being that the file I/O of the system hosting the compiler would be used. If you're running it on an x86-based MSDOS OS, you'll use MSDOS I/O. That does not imply a PC, only an x86 machine that can host MSDOS. If you want vintage, I think that there's a K C source on github: https://github.com/AoiMoe/knrcc Some time ago, I revisited some code I wrote in the late 1970s-early 1980s and found that gcc didn't like it at all. As mentioned, there are a host of C cross-compilers. --Chuck
[cctalk] Re: best C compiler(s) for varied vintage programming
On Tue, 27 Dec 2022, Chris via cctalk wrote:
Not all compilers were designed specifically to run on an ibm pc. If the
compiler itself utilzes bios fumction calls to display anything, it will
not run on anything but an pc or compatible. If you're referring to
saving object code to disk, well I giess that's a good question. But
there were compilers prior to tje 5150, and even after, a few of which,
I have to imagine, had some other means to save files.
In general, a compiler will use the operating system for its file I/O.
CP/M, MS-DOS, etc.
The problem that you are referring to, and yes, it is a real problem, is
generally an issue of programs that go below DOS, and even below the BIOS,
and do hardware access of video memory, keyboard, etc. for "improved
performance". It is impractical to do a graphical user interface without
doing that.
Therefore, what you want is a "command line" based compiler.
Those tend to be hardware agnostic.
Many/most of those were before ANSI C, and complied with the compiler
author's interpretations of the K holy scripturees. So, there are
differences, such as whether puts() appends a newline by default, etc.
One small one that I found was quick and easy to get started with, was the
DeSmet "Personal C Compiler"; it tends to work fine on MS-DOS macines that
are VERY NOT PC compatible.
For larger projects, Lattice C was the major workhorse for most
developers.
A graphical "IDE" ("Integrated Develpment Environment", TOTALLY
unrelated to IDE "Integrated Device Electronics", as used on hard drives)
is where you would encounter the difficulties.
But, even some of those will sometimes work on some machines that are
only "close" to PC compatible.
--
Grumpy Ol' Fred ci...@xenosoft.com
[cctalk] Re: best C compiler(s) for varied vintage programming
On 27-Dec-22 12:19 PM, Chris via cctalk wrote: It cannot rely on bios/ms-dos services for compiling preferably. Iow I'd like to perform what I want to do on the target machine itself, LOL which is hysterical as I've never even seen it boot even once. I could complie on a standard pc I suppose and pop a disk in the Northstar Dimension. It would be nice if it's optimized for it's 80186. Or at least supports it's instructions. My goal is to get MINIX running on it, as the original Netware-86 OS has proven to be more rare then really anything else. From there I'd like to figure out how to support the pc compatible (or so we're told) logic boards that are plugged into the motherboard like standard isa cards, and even have 34 contacts on their card edge. It would be nice if someone had the ideal compiler package they don't need and could sell. I don't know anything about the Dimension, can it boot regular MSDOS floppies? Circa late 80s I used to recompile the Minix 1-point-something kernel and utilities under Minix on a plain 8088 clone with two (IIRC 360k) floppies only, no HD. The Minix C compiler (Toby mentioned Amsterdam, that sounds like it) took a lng while, but it was doable and actually worked. I still have all the diskettes for it somewhere.
[cctalk] Re: best C compiler(s) for varied vintage programming
On 12/26/22 19:46, Chris via cctalk wrote: > Not all compilers were designed specifically to run on an ibm pc. If the > compiler itself utilzes bios fumction calls to display anything, it will not > run on anything but an pc or compatible. If you're referring to saving object > code to disk, well I giess that's a good question. But there were compilers > prior to tje 5150, and even after, a few of which, I have to imagine, had > some other means to save files. > It seems to me that you're conflating the IBM PC BIOS and MS-DOS. LC was available for a wide variety of platforms. We ran Lattice on a non-PC compatible (80186 with no memory-mapped display) To quote the page I pointed to: "Lattice C was ported to MVS, VMS, Unix, OS/2, Amiga, Atari ST, and Sinclair." My point being that the file I/O of the system hosting the compiler would be used. If you're running it on an x86-based MSDOS OS, you'll use MSDOS I/O. That does not imply a PC, only an x86 machine that can host MSDOS. If you want vintage, I think that there's a K C source on github: https://github.com/AoiMoe/knrcc Some time ago, I revisited some code I wrote in the late 1970s-early 1980s and found that gcc didn't like it at all. As mentioned, there are a host of C cross-compilers. --Chuck
[cctalk] Re: best C compiler(s) for varied vintage programming
Not all compilers were designed specifically to run on an ibm pc. If the compiler itself utilzes bios fumction calls to display anything, it will not run on anything but an pc or compatible. If you're referring to saving object code to disk, well I giess that's a good question. But there were compilers prior to tje 5150, and even after, a few of which, I have to imagine, had some other means to save files. Was the development platform for the D* a pc? Maybe it was for all I know. Seeing it sought emulate pc (hardwate) I guess it could seem natural. But not a necessity as it was a type of server that allowed individual pc compatible SIXTY TWO pin cards to boot and run a pc os and applications. The D* booted it's own dos. Which may or may not be Netwate-86 itself, can't say. I have.my own manuals for this thing (but can't find them) and it seems every piece of documentation that ever existed is available for download. So I I only have a cursory underatanding of this beast at the moment. Maybe I'm just assuming it doesn't habe some low level pc s/w xompatibility ... On Monday, December 26, 2022, 10:22:22 PM EST, Chuck Guzis via cctalk wrote: On 12/26/22 18:19, Chris via cctalk wrote: > It cannot rely on bios/ms-dos services for compiling preferably Huh? Exactly what should it do for file I/O? --Chuck
[cctalk] Re: best C compiler(s) for varied vintage programming
On 12/26/22 18:19, Chris via cctalk wrote: > It cannot rely on bios/ms-dos services for compiling preferably Huh? Exactly what should it do for file I/O? --Chuck
[cctalk] Re: best C compiler(s) for varied vintage programming
On 12/26/22 18:19, Chris via cctalk wrote: > It cannot rely on bios/ms-dos services for compiling preferably. Iow I'd like > to perform what I want to do on the target machine itself, LOL which is > hysterical as I've never even seen it boot even once. I could complie on a > standard pc I suppose and pop a disk in the Northstar Dimension. It would be > nice if it's optimized for it's 80186. Or at least supports it's > instructions. My goal is to get MINIX running on it, as the original > Netware-86 OS has proven to be more rare then really anything else. From > there I'd like to figure out how to support the pc compatible (or so we're > told) logic boards that are plugged into the motherboard like standard isa > cards, and even have 34 contacts on their card edge. > > It would be nice if someone had the ideal compiler package they don't need > and could sell. I'm not sure that I understand what you're after, but if you want a period-correct x86 C, Lattice C was what we used and what Microsoft recommended. https://winworldpc.com/product/lattice-c/2x However, note that LC is not ANSI C90 conforming. But it will run fine on a 5150. The run-time, of course, is your own lookout. --Chuck
[cctalk] Re: best C compiler(s) for varied vintage programming
On Tue, 27 Dec 2022, Chris via cctalk wrote: It cannot rely on bios/ms-dos services for compiling preferably. Iow I'd like to perform what I want to do on the target machine itself, LOL which is hysterical as I've never even seen it boot even once. I could complie on a standard pc I suppose and pop a disk in the Northstar Dimension. It would be nice if it's optimized for it's 80186. Or at least supports it's instructions. My goal is to get MINIX running on it, as the original Netware-86 OS has proven to be more rare then really anything else. From there I'd like to figure out how to support the pc compatible (or so we're told) logic boards that are plugged into the motherboard like standard isa cards, and even have 34 contacts on their card edge. Am I misunderstanding something? (or over-reacting to a typo?) 8 bit ISA cards, for 5150/5160 have 62 contacts. not 34 I thought that the Northstar Dimension had same/similar 16 bit ISA (5170) is 98 pins? (including the 62 pin bus) Apple 2 is 50 S100 is 100 SA400/450 (5.25") floppy interface is 34 contacts. SA800/850 (8") interface is 50 contacts
