TINY memory model C, compiler recommendation?

[Scali]

You do have to wonder why, if synthesis can be so good, why anyone would want to spend $50K on a bassoon or 'cello.

Probably for the same reason why people buy vintage cars (or in our case vintage computers)?
New stuff may be cheaper/better/whatever, but preserving the classic stuff, and experiencing the ways of days gone by, is interesting as well.

I do wonder though... do these MIDI controllers for such instruments give you the proper feedback? I know with synthesizers, the cheap ones tend to feel 'rubbery', and expensive ones have actual weighted mechanisms behind the keys, pretty much the same as the hammer on a real piano, to get the right fee, which aids in playing and adding expression.

On my main instrument, the electric guitar, both the guitar and the amp are an important part of the equation. Even the way the strings interact with the speaker has an effect. I can't really play with headphones, because I don't get that interaction, and the guitar feels 'dead'.
Likewise, I am very peculiar about the type of wood, pickups, and the response of the amp itself, to pick up the nuances in my playing in the way I expect.
I don't like to play on certain brands of guitars or amps, because they don't respond to my playing well.

I've witnessed the transition from analog to digital processing and amp modeling over the years, and I must say, current amp modeling is acceptable, but it's not like playing a real amp. I have found Roland/Boss to be notoriously bad in getting a nice attack from the guitar, and I never liked playing their stuff. Line6 and Zoom do a much better job, giving a more natural feel to the guitar, closer to a real amp.

So, what I'm saying is that there's more to just how synthesizers/digital processing sounds, for a musician. You can have two amps/processors that sound pretty much the same at the end, but they might respond differently to your input, making one great to play, and the other requiring you to really force yourself to get the required output.

 

[Chuck(G)]

We're not talking about a vintage bassoon--we're talking about a new one from, say, Heckel. An orchestral tuba, by the same token can run well over $20K new. A new professional-grade 'cello and bow can easily run upwards of $50K--with the bow costing nearly as much as the 'cello.

A good musician acknowledges the instrument as an extension of his or her body. No mouse or keyboard can give you that degree of self-expression. Maybe someday, but not now and not in the foreseeable future. And let's be clear--music is self-expression--nothing more.

Similarly, one can ask why we still employ people to prepare food? Surely a computer-controlled automaton can be more precise.

 

[neilobremski]

I'm still getting through this thread and here near the end it seems to be about something else, but a lot of the discussion and comparison of different compilers is very useful. In my current project I chose Microsoft C 5.10 because I wanted a compiler that was considered commercial quality around the same time as the technologies I'm interested in were still being used. It also happens to be targeted by a lot of sample code in the old books I'm reading.

I played with OpenWatcom and it really is very good. Back in the day I'd hear about the mythical Watcom and it's 32-bit protected mode DOS EXE's and fantastize about having the money to buy it (I was making due with Borland C++ 5.01 from a friend and it was great but all of the "cool" games were being written in/for Watcom). Now it's free and that's simply astounding. The fact that I was able to run the setup program in DOSbox flawlessly was a great boon. My only issue (with OpenWatcom) is that this is a modern, optimizing compiler and it was never used to produce commercial-quality binaries back in the late 80's. I'm sure it can do that, but the fact that I can use a compiler that was certainly used to do that is better for me as a learning approach.

The choices can be overwhelming and it takes so long to evaluate each one. Wikipedia doesn't have any decent page that compares antiquated compilers, does it?

Does anyone know if there is a webpage or document out there which compares the various 16-bit C compilers? I would imagine comparison points revolving not only around optimization (speed / size) but also adherence to new standards, differences in DOS/BIOS calls, inline assembly, etc. I'd love to see a chart like that! Bonus points if you could step through each year and figure out where compilers were at that time and what was "best". For example, you could answer something like: in 1986 what was considered the crème de la crème of C compilers?

 

[deathshadow]

I'm sure it can do that, but the fact that I can use a compiler that was certainly used to do that is better for me as a learning approach.

Generally I don't let that slow me down. Using more powerful or better platforms to develop for less capable ones is a proud tradition right back to the earliest version of Microsoft Basic, or as it was known at the time, Altair Basic.

Or the Ti-99/4 series, where little if any of the software for it prior to about a year into the A model being on the market was actually written ON it.

I don't have that hangup about new tools for old platforms; If I did I'd have to rule out half my development stack.

For example, you could answer something like: in 1986 what was considered the crème de la crème of C compilers?

Others seem to disagree with me on this -- MAYBE it's because I was a teen in the hobbyist realm in the early '80's and did military service instead of college in the late '80's, and was ENTIRELY microcomputer based...

But I don't remember ANYONE giving a flying purple fish about C on MICROCOMPUTERS in the '80's. It was at best a novelty, an also-ran. Mainframes? Sure, no problem... but if we're talking strictly 8 bit micro's, x86 PC or even 68k Mac, NOBODY I ever dealt with or encountered was talking about writing software with C. Much like Unix, it was something needlessly and pointlessly archaic and broken that was regularly mocked.

Just ask an OS/9 user to describe Unix sometime.

Much of that though was that there were no "quality" C compilers for the various platforms. It didn't EXIST. Even the compilers that did exist were a joke where you needed four 360k floppies, two drives, and 3 hours compile time just to build "hello world", and those cost you a few grand just to let you spin your wheels.

... and even when it was used, much like other languages you ended up lacing in large swaths of assembly because the systems just weren't powerful enough to let some high level language be allowed to slop itself all over the place.

All things I apparently had forgotten when I started this thread... which has given me a great big reminder of why C is NOT my favorite programming language.

But that's like one of the people I learned a great deal of programming from in the '80's who when someone would say "C is more like assembly language" he tended to introduce his boot to their testicles.

 

[BrianS]

This is getting off-topic.

I looked to see when Microsoft 5.1 as around- Found an article from 1989 comparing it with other compilers. C/C++ V1.52c for Windows will generate real-mode code for DOS, and is better than it's predecessors.

https://books.google.com/books?id=m...Q6AEIMjAE#v=onepage&q=microsoft 5.1 c&f=false

I used Fortran-77, RM Fortran for real mode and Microway NDP-386 with PharLap extended DOS at that time. Both were very similar to the VAX/VMS Fortran compilers. The Unix world used C, the VMS world used Fortran. All of the fast floating point boards and processors were supported by the Fortran compilers. If you want to experience 1980s programming for DOS X86 computers, the RM compiler can be downloaded from Vetusware.com. The RM compiler is very stable, the Microway compiler will produce code for the Weitek and Cyrix extended coprocessors.

Too funny...

http://www.nytimes.com/1988/01/10/b...mputer-a-top-machine-carries-a-top-price.html

I computed satellite orbits on mine. Now a used Laptop with a 2GHz Pentium-M and 1000 times the memory runs $40.

 

[Scali]

We're not talking about a vintage bassoon--we're talking about a new one from, say, Heckel. An orchestral tuba, by the same token can run well over $20K new. A new professional-grade 'cello and bow can easily run upwards of $50K--with the bow costing nearly as much as the 'cello.

Does that make a difference in this particular context?
I mean, aren't these instruments designed to look, feel and sound as close to the classic 'benchmark' instrument as possible?
I mean, like a 50s Mark VI saxophone from Selmer, or one of the better Stradivarius or Guarneri?

They're not like a synthesizer at least, which tries to achieve the same sounds by completely different means, and does not have even remotely the same look and feel.

And let's be clear--music is self-expression--nothing more.

Well, I think that is highly debatable.
Especially in an orchestra. Aside from the soloist, I don't think there's much room for self-expression, if any. You just need to play it the way the conductor wants it to sound, just like everyone else in the orchestra.
And even the soloist is just doing an interpretation of a piece of music someone else wrote. I think that is still a limited form of self-expression compared to actually writing and performing your own music.

I would say that we've arrived at a point where quite a lot of 'orchestral' music isn't actually played by orchestras anymore, but by synthesizers. Eg, a lot of music written and recorded for movies, games, commercials etc may sound orchestral, but are actually done entirely with virtual instruments, often on a single computer by a single person. The results sound 'good enough', and the time required to record, not to mention the cost, are way lower.

As a software developer, I'm in a similar situation. For my job, I write whatever software is required by the client.
In my spare time, I write the software that I want to write. Which one could view as a form of self-expression.
As a result, I use quite different tools at work compared to at home.

Similarly, one can ask why we still employ people to prepare food? Surely a computer-controlled automaton can be more precise.

I think once that actually becomes true, it will become a viable and popular option.

 

[MennoJoshua]

It would be reasonable if a compiler did similar to "ECHO ├>TEST.COM" when you compile "int main() { return 0; }. I'm going to hazard a guess here that nobody wrote optimising compilers to optimise for the case of empty programs.

You are pursuing something quite specific. Have you thought of building some of your own tools to assist with the job? Since you don't like C syntax, you could keep some of the things you like in Pascal, and also work on an optimiser that does the specific bits you care about.

Sometimes people worked on a project and had to make a sub-project to support it... and the sub-project ended up being a lot more significant. Rational Systems made Instant-C, but quickly ran out of memory, so they cooked up DOS/16M. Their DOS extender products ended up being quite significant to their company and to DOS, in an era when most other DOS extenders weren't very good and were expensive.

 

[MennoJoshua]

But I don't remember ANYONE giving a flying purple fish about C on MICROCOMPUTERS in the '80's. It was at best a novelty, an also-ran. Mainframes? Sure, no problem... but if we're talking strictly 8 bit micro's, x86 PC or even 68k Mac, NOBODY I ever dealt with or encountered was talking about writing software with C. Much like Unix, it was something needlessly and pointlessly archaic and broken that was regularly mocked.

C was a serious thing in the late 1980s on x86 PCs. One of the appeals of Windows was that you could write programs in C, which apparently was an improvement. I myself learned C in 1989.

Custom business applications in high level languages (from what I can remember) were a lot more likely to be in BASIC or QuickBASIC than C.

But that's like one of the people I learned a great deal of programming from in the '80's who when someone would say "C is more like assembly language" he tended to introduce his boot to their testicles.

I have trouble seeing how "C is more like assembly language" (compared to other languages) is an inaccurate statement. C leaves it up to the developer or the library to do a lot of things like memory management (beyond simple automatic variable storage on the stack), string handling, and doesn't really dictate any data structures at all.

I think some of your complaints are with the C run-time library. For most OS or driver writers, they would not use the C run time library, or would just use parts of it.

 

[deathshadow]

No mouse or keyboard can give you that degree of self-expression. Maybe someday, but not now and not in the foreseeable future. And let's be clear--music is self-expression--nothing more.

Someday is increasingly here as different controller types mature. It's all about reading more input data. The EWI is a great example of this since it's breath pressure sensitive, bite-pressure sensitive (typically mapped to pitch bend), has two strain gauges on the right thumb you can use for controlling expression (I set mine to growl and flutter tongue for "the sax brothers")... the only area it is lacking is the strictly on-off nature of the buttons since they are capacitive touch sensors instead of positional switches. Good if you are playing fast, but half open and transitional effects can't be communicated that way. (why I'm playing with using a variable optical sensor on my next Zoot build).

Other devices add different ways of adding expression, the Eigenharp for example has velocity touch, pressure sense, and four directions on it's tablature, a breath sensor, multiple capacitive sliders, and a host of other controls in addition to the on-board synth, loop, and other enhancements that give it a level of expression more suited to string type instruments than piano style keyboard.

https://www.youtube.com/watch?v=zcVqJh0qEMc

Even so, it comes down to the musician, not the synth. Simple MIDI synths aren't reading the level of data from the musician needed for a proper "performance" and that's limiting things a lot. Channel aftertouch, strike velocity vs. just treating it as level, speed of attack controlled by the player, etc, etc...

As Johnny 5 would say, "Input, need input!"

Though that's why such input devices run prices into the thousands just like any other professional instrument.

 

[Scali]

Even so, it comes down to the musician, not the synth. Simple MIDI synths aren't reading the level of data from the musician needed for a proper "performance" and that's limiting things a lot. Channel aftertouch, strike velocity vs. just treating it as level, speed of attack controlled by the player, etc, etc...

Yes, I suppose you can go both ways with this.
If you look at synths and drum machines from the 70s and 80s... they were quite limited, and didn't really do a convincing impression of actual instruments. However, musicians embraced their unique characteristics, and they became popular instruments in their own right.
In fact, the early Roland drum/bassline machines ended up being the basis of entirely new genres of music. That is probably not at all what the designers of the machines originally envisioned. They were originally meant as devices to create a simple backing track to practice over, or to make simple demo recordings of new songs.

 

[BrianS]

I'm still getting through this thread and here near the end it seems to be about something else, but a lot of the discussion and comparison of different compilers is very useful. In my current project I chose Microsoft C 5.10 because I wanted a compiler that was considered commercial quality around the same time as the technologies I'm interested in were still being used. It also happens to be targeted by a lot of sample code in the old books I'm reading.

I played with OpenWatcom and it really is very good. Back in the day I'd hear about the mythical Watcom and it's 32-bit protected mode DOS EXE's and fantastize about having the money to buy it (I was making due with Borland C++ 5.01 from a friend and it was great but all of the "cool" games were being written in/for Watcom). Now it's free and that's simply astounding. The fact that I was able to run the setup program in DOSbox flawlessly was a great boon. My only issue (with OpenWatcom) is that this is a modern, optimizing compiler and it was never used to produce commercial-quality binaries back in the late 80's. I'm sure it can do that, but the fact that I can use a compiler that was certainly used to do that is better for me as a learning approach.

The choices can be overwhelming and it takes so long to evaluate each one. Wikipedia doesn't have any decent page that compares antiquated compilers, does it?

Does anyone know if there is a webpage or document out there which compares the various 16-bit C compilers? I would imagine comparison points revolving not only around optimization (speed / size) but also adherence to new standards, differences in DOS/BIOS calls, inline assembly, etc. I'd love to see a chart like that! Bonus points if you could step through each year and figure out where compilers were at that time and what was "best". For example, you could answer something like: in 1986 what was considered the crème de la crème of C compilers?

At this point, given how utterly off-track this thread has become- "Code Bloat" comes to mind.

It would be best to start a new thread on 1980s compilers. I might even dig out the 5.25" Turbo C 2.0 floppies and put them on the Pentium Pro. I have 1.5 somewhere. Never used these much, ended up with the Microsoft "LearnC" tutorial and the MicroWay NDP C/C++ for protected mode. Used the GNU C/C++ for the MIPS R3000 and I960. Microsoft V1.52c C/C++ (runs under WINdows) for real-mode DOS. This was the last version of the compiler from Microsoft that generated a .exe for use on real-mode DOS. In my experience: Assembly language routines were required for time-critical operations when using all of these compilers, including the RISC architectures.

 

[bocke]

I remember someone was mentioning 16-bit backend for GCC in this topic. I've just (well, earlier today) seen this being posted on Reddit: Announcing Sourcery CodeBench Lite for IA16.

Haven't tested it yet.