16-bit + basic programming

I would suggest you *learn* C. It's not really that difficult (especially if you know hardware). Much depends on what you mean by BASIC, of course, but I have to say I heartily agree with this quote from Edsger Dijkstra (a legend in computing, in case you didn't know)

"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

He's talking more about the issues with BASIC than the ability of good minds :)

See this page for more quotes:

There are voluminous resources on C, and if you want to do any hardware centric computing, BASIC makes it 'difficult' to say the least (well, you have peek and poke, but that's rather a kludge).

I will agree that VB has helped somewhat (it's actually structured, after a fashion), but there are subtle (and not so subtle) issues with it that make me personally avoid it like the plague.

Cheers

PeteS

Dijkstra's no legend to me. In my eyes he's just a fart programmer. He's absolutely right though!. Prior exposure to BASIC completely destroys any hope of a subject becoming pliant enough to accept "C" brainwashing. I know of these things from personal experience, as at an early age I was fortunate enough to be suckled from the warm and bountiful teat of Basic.

It's not that I've haven't made valiant efforts to align myself with the C language. Lord, oh Lord, how I've tried. I spent a whole 3 months last year back engineering a C programmers 'work' and for the past 2 weeks have been writing a hardware control prog' in C. But ... no matter how hard I try to ignore my preconditioning, I still look at the C stuff that I or other people have written, or read the programming reference manuals and can only ever see screeds of contrived-to-be-awkward' text constructs. Most of all though, I look at the stuff and think "god that is ugly and impenetrable". John Larkin had it spot on, with a comment that it's a language composed of punctuation marks. (no I'm not a programmer). john

As a last resort, you can "develop" your program in BASIC and then use a translator such as

. Make sure you use a compiler with an IDE ( integrated development environment) that allows breakpoints and sissy-stepping through every little thing you do.

... or a "disintegrated" debugger that does the same sort of stuff.

One thing to check is how fast the debugger gets in and out of a single step or break point. If it is over about 5 seconds, worry about how much time you will spend waiting.

You want to be able to do the following:

Go until one of N breakpoints is hit. Where N>1.

Step by one source statement

Step by one instruction

View the contents of a variable as understood by the compiler

View the contents of memory as a hex dump

View the code as disassembled instructions

View the content of any special function registers

The following are nice to also have:

Conditional break points so you can have a variable's value checked

Go till the routine returns

Change a variable's contents on the fly so you can continue testing after the first bug is found

Looping constructs more complex than just the conditional breakpoints sort of like "go til line 57; variable i=7; loop until j=32"

The ability to write what you do to a log-file

--
--
kensmith@rahul.net   forging knowledge

I agree, debugging facilities are most important. Most all of my PC software is still written in Borland Turbo C. They invented (as far as I can tell) the integrated debugger environment.

Code - Compile - Run - Ooops - Debug - Code ... etc.

Luhan

One can write horrible code in any language, of course. I have seen plenty of it in most languages, especially from hardware designers (of which I am one) but often from software engineers.

The difference (for the OP) is that C is supported in many forms for this target, whereas BASIC is not.

I will say that properly written C is clean and readable, but to someone who expects to find everything defined in one place it *will* be difficult. Composed of punctuation? good point, but so is Verilog and VHDL.

C is not going to save you from yourself; in this sense it is an assembly language programmer's high level language. You are completely free to trash the entire system (but then you are free to do that in assembly too), but then it was written as a systems level language.

There are many arguments for and against just about every language in existence, many of them well deserved. One uses the language that works best for a particular situation.

An old tagline was 'Unix is user friendly. It's just very particular who it's friends are', and there's a lot of truth in that. As C was designed by the same person as co-wrote the original Unix[tm] [dmr], it's hardly surprising to find the same arguments ;)

Cheers

PeteS

Dijkstra is also credited with saying 'I have yet to meet a C compiler easier to use than eating soup wth a fork'. He was an equal opportunity criticiser :)

Certainly trying to decipher the warning/error outputs of cc [or gcc for that matter] is one of life's challenges ;)

Cheers

PeteS

In article , Luhan wrote: [...]

If they didn't invent it, it sure is a standard against which others can be compared. As of yet I haven't seen one that was better. There is now "free pascal" with an almost perfect copy of the Borland IDE. It runs on many systems.

Also: The Pascal compiler is very fast. It looks to be a classic recursive decent compiler where the first error stops it.

--
--
kensmith@rahul.net   forging knowledge

I wrote a C cross compiler modeled after Borland. It ran under DOS and sent out Z80 code to the target on bi-directional bit-bang lines. There was no hardware emulator, but it did source level trace with variable watch. Only 3 functions were needed at the target: Write memory location with data, Read data from location, Goto to location.

Since the compiler had access to the symbol table, variables could be asked for by name and the debugger just looked up there address in the target and requested that location.

Trace was done by reading a known location specified by the source line, writing in a 'trap' instruction, and executing from the current location until the trap was reached.

The total program size was 83K which included the editor, compiler, debugger, and code generators for both Z80 and 68000. All written in Borland Turbo C.

Luhan

Turbo C was perhaps one of the best compilers I ever used. Lean and mean, excellent documentation. My first copy was 'borrowed' from a friend in college c. 1988 (the price was $50 if I recall correctly) and was the first decent IDE I ever saw - in my opinion, it still beats many of the so-called IDes out there today.

Cheers

PeteS

In response to what PeteS posted in news: snipped-for-privacy@s13g2000cwa.googlegroups.com:

The two languages I write in these days, from choice, are C and Pascal.

Pascal tries to stop me from doing what has to be done: C lets me do what ought not to be done.

Choose your evil!

--
Joe Soap.
JUNK is stuff that you keep for 20 years,
then throw away a week before you need it.

The best route is to learn generic object oriented programming methodology, then C. Helps kill off the BASIC thinking.

Luhan

Yes indeed Sahib, you have that most exactly correct !

Luhan

About correct, though. Its that age old concept of taking something simple and useable... and screwing with it until its so f*'d up, its useless.

was

year

been

only

impenetrable".

of

If you think C is bad you ought to try APL. It is so full of punctuation marks and contrived punctuation marks that only impenetrable function and variable names are left. It even takes special software (previously done in hardware) to even view it. It has its own extensive character set (500+ symbols i think).

--
JosephKK
Gegen dummheit kampfen die Gotter Selbst, vergebens.  
--Schiller

In article , joseph2k wrote: [...]

I think APL is a good language. "Life is too short to spend it coding DO loops". In many ways it is like assembly programming on a machine that just happens to do arrays automatically.

Most implementations allow longish names so you can make the names mean stuff.

For those that done know: In APL, funtion calls are written:

function function right left function right

Where "left" and "right" are arguments.

This makes:

Mary had a little lamb, some potatoes and some carrots

a perfectly good APL statement. This is all done without a single #define. Now I think you can see that APL is a truely lovely language.

--
--
kensmith@rahul.net   forging knowledge

a standard VGA display could support 512-symbol fonts in text mode, (trading blink for the extra bit of character iirc)

the original lisp machines used an extended character set too. Lambda was a single symbol, dunno about "car" and "cdr"

perl can be pretty indecipherable too and it's all ASCII.

ISTM that any unicode text editor would be fine for APL or LISP these days.

Bye. Jasen