Is this an alternative to C?

[TheOldMan]

friend used visual c

My bad. Visual Basic, not visual c. He did a lot of wierd things in Basic.

[Bonknuts]

The rest were things I picked up helping my nephew and others do their school work. C++ was nice, if inefficient. Java was worse.

 My first two courses for CS are Java based. It's my first real exposure to Objects and classes (I stated away from that stuff in C++). It's not bad, so far. I have no idea what the performance is on JVM, but I'm thinking of doing some GUI based utils with it (cross-platform portability interests me). I lucked out because they're ending Java classes at the college and replacing them with Python. So I avoided Python just in time (no pun intended). We're also doing a lot of JUnit testing, which I've found to be a really nice tool for testing classes and methods. After which, we have to submit our code to an online server that does additional range checks in real time.

[dshadoff]

Amazingly, the vestiges of FORTH still exist. What a beautifully horrible language.

A masterpiece for it's time, and an absolute nightmare.

I considered making AtLast (AutoDesk's interesting 32-bit derivative of FORTH) the in-game scripting language for our company's game engine.  :oops:

After it because clear that every other programmer would quit, I relented and we implemented something usable instead. 

Yeah, Sun Microsystems was using FORTH in their OpenBoot PROMs in the late 90's, and I was sent to Palo Alto to debug a broken SCSI tape driver in OpenBoot.  Without knowing FORTH.  Or SCSI.  But all was well, as it was easy enough to fix (just obscure, and tedious to test).

Z80 assembler was the second computer language I learned (BASIC was first).

Me, too. What machine did you get to start on? I think that you're an American, so perhaps an Altair or TRS-80 or something like that? 

Well, Canadian - but you're close.
Yeah, TRS-80 Model I.  I bought it with the money I made on a paper route, I guess it was 1979 or 1980.

6809 assembler was the next one.
And I was about to learn 6502 as my next language (but the 6502 was dying by that time).

I'm jealous ... I've always wanted to have a chance/reason to play with a 6809!

I went straight from the Z80 to the 6502 (on the Apple II).

I almost went the Apple II route; I went TRS-80 Color Computer instead.

Being a game guy, I can think of Apple PowerPCs, GameCube, Wii, WiiU, Xbox 360 and PS3 ... and I'm sure that it must have had a different and successful life in the embedded world, too.

Didn't it also get used in some of IBM's server and supercompters somewhere?

Can you think of other examples to help me out?

A more modern descendant is still in IBM's System p servers running AIX.  They recently announced POWER9.

Other than that, I've seen it used as an embedded processor in things like printers, but that use is quickly being replaced with ARM variants and low-power x86.

[elmer]

I did BASIC as a kid, and learned C with OOP (that's what it was called in 1993/4) for about 6 months as a late teen. In 1999, I learned x86 assembly and z80 assembly at the same time. That was about 6 months, then directly switched over to GBz80 assembly (Gameboy) for another 6 months. And then stopped.

Interesting ... I thought that you were much younger, but we're really not that far apart (in cosmic terms). You just followed a different path to some of us ancient proto-greeks. 

65x was weird to get used to at first, but I never did like x86. It felt soo convoluted in approach (I did page mode addressing) - even without having any other experience with other processors. Looking back now, after coding more modern processor designs, I was right. Going back to z80 after all these years, I don't like that it doesn't have direct memory load/store into the A register (everything is pretty much done through the A reg like on the 65x and 68x and other related processors, so this bottleneck sucks). Too much register juggling - and stack use. The nice but limited 16bit macros (hardware macros) don't make up for it.

IMHO, it's just like the 6502 ... fatally flawed, but in it's own unique way.

BITD we used to draw sprites by setting the SP to the target location and then "LD HL,#$nnnn; PUSH HL", pretty much like your PCE "ST0" commands.

It's just another early architecture that rewards nasty "trick" programming ... just like the GameBoy's not-really-Z80 variant.

Pic 16f84 and related series MCU are the worst processor that I've ever coded assembly on. That processor is insanely crippled. About the only thing worse would be trying to program a DSP chip as a regular processor (it's almost the same level of convoluted-ness).

Have you looked at the insane restrictions of the 8051 architecture?

If SDCC can do a "bearable" job on that CPU, then I hope that we can end up with something "usable" on the 6502.
But it's not really up to me ... I'm just the "support" guy hoping that the "guru" doesn't bail out! 

IBM used it for a while in the Power series servers, and the 603 and variants were used as embedded controllers for lots of stuff. Various 603 versions powered Sega's impressive Model 3 arcade boards (precursor to Naomi/Dreamcast) and Konami used a bunch of PowerPC variants in arcade machines as well. You can bet Motorola was doing their best to sell that chip to anyone who would buy, because Apple wasn't necessarily perceived as a safe business partner at the time.

Ahhhh ... sounds like you may have had a career in "big-iron" or in sales. I'd love to pick your brains over a beer sometime! 

in order, as I remember it....
Pascal. Fortran 4 then 77.Cobol.  PL/1. 360/370 assembler. Logo. Basic. C. 6809 assembler. 386 assembler
Then, in no particular order...
C++ / Java /C# /MIPS assembler / and finally, 6502 assembler.

Most of the early stuff was in college. 2 years of fortran, right around the change over from 4 to 77.

Sounds like you're a few years older than me. I missed all of the historical mainframe languages, and started HLLs with Pascal and C.

It's been interesting to see the progression of Niclaus Wirth's ideas in Pascal vs Kernighan & Ritchie's idea in C.

While Pascal/Oberon/etc are pretty much dead to the world ... Wirth's ideas live on somewhat in Anders Hejlsberg's C#.

It's an interesting evolution ... and so much more of a "practical" solution than Bjarne Stroustrup's abominable C++ mistakes.

The rest were things I picked up helping my nephew and others do their school work. C++ was nice, if inefficient. Java was worse.

C++ is an interest attempt to add object-orientation and more modern design techniques to C ... but I hate it.

Every time I look at it ... if there's a design choice to be made, Bjarne usually made the wrong one (IMHO).

Then again ... he's rich and famous, and I'm pontificating on a PCE forum, so where do I get the right to criticize? 

Bonknuts, and anyone else interested in the actual "costs" of rampant overuse of object orientation, this was an interesting talk by Sony ...

http://harmful.cat-v.org/software/OO_programming/_pdf/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

[TheOldMan]

Sounds like you're a few years older than me.

54. And I don't care who knows it. At 50, I earned the right to be  grumpy a$$hole

...Kernighan & Ritchie's idea in C.

One of my professors knew Kernighan . He worked at Dec on the Vax stuff. (The professor. dunno bout Brian) Said they used to do pre-processors like c++ all the time. He wasn't impressed by it. Or by Ratfor, either.

C++ is an interest attempt to add object-orientation and more modern design techniques to C ... but I hate it.

I don't -hate- it; it has some good points (Mostly keeping stuff out of the way.)
But I do like to know when garbage is being picked up, and not having to chase through 30 layers of code to find out "Oh. That's a bloody one-line function, overloaded 60+ different ways...Now which one is actually being used?"
I honestly like the C pointer-to-function stuff better.  Those I can use in arrays.

[Arkhan]

I started with QBASIC, C+some 68k on the Amiga, and BASIC/6502 on the C64.  But the C64 never really went well because the f*cking disk drive would goon out all the time. 

assembly in general never went well because alot of it was me winging it as a child, with whatever books we had laying around.   Most of my fun was in QBASIC because I'd f*ck with all of the games and make them unplayable so I could watch my sister get demolished by the CPU.    I made the Pac Man game go way too fast, and the ghosts would just zero in on you immediately and kill you.   

lol, and I made Nibbles controls reversed so she couldn't play it.  It was pretty hilarious.


by the time I was really coherent, though, C++ was a thing, people were running away and crying at assembly, and everyone was doing the gradual shift towards the current programming paradigm of being a lazy, pretentious dickhead chasing whatever the new hotness is.

First, it was Java, now it's C# + any web platform.

it's all pretty dumb.

[elmer]

My first two courses for CS are Java based. It's my first real exposure to Objects and classes (I stated away from that stuff in C++). It's not bad, so far. I have no idea what the performance is on JVM, but I'm thinking of doing some GUI based utils with it (cross-platform portability interests me). I lucked out because they're ending Java classes at the college and replacing them with Python.

There's nothing wrong with objects and classes, they're a great way to express some ideas and build some programs.

The concept has definitely proven itself valuable.

The problem comes with their overuse, typically by new adherents to the paradigm who naturally try to turn everything into an object.

I really can't understand why Python seems to be taking over so much mind share in academia ... it's just like teaching BASIC.

And sorry, but any language where exact spacing is significant ... that's f**ked-up! 

I'm jealous ... I've always wanted to have a chance/reason to play with a 6809!

I went straight from the Z80 to the 6502 (on the Apple II).

I almost went the Apple II route; I went TRS-80 Color Computer instead.

I only used the Apple II for a few months for a project in my first job, and then got to do another project on the BBC Micro, I didn't actually own either of those machines.

When I had the cash, I bought an Atari 800. 

54. And I don't care who knows it. At 50, I earned the right to be  grumpy a$$hole

Heck, I'm 53, and I'm definitely a grumpy old curmudgeon! 

I wonder how you got exposed to all those mainframe languages that I missed out on.

My university CS Dept was running a PDP 11 and Unix, and we time-shared on another university's larger mainframe.

IIRC, we were started with Pascal on the mainframe, and then later courses shifted to C on the PDP 11.

The HLLs all seemed very painfully slow because I'd been programming in assembly on a microprocessor for a few years before university.

C++ is an interest attempt to add object-orientation and more modern design techniques to C ... but I hate it.

I don't -hate- it; it has some good points (Mostly keeping stuff out of the way.)
But I do like to know when garbage is being picked up, and not having to chase through 30 layers of code to find out "Oh. That's a bloody one-line function, overloaded 60+ different ways...Now which one is actually being used?"
I honestly like the C pointer-to-function stuff better.  Those I can use in arrays.

OK, I guess "hate" is too strong a word. I just think that it's overrated and ugly and that it's taken the wrong path. I still happen to use it as my main language anyway.

If Bjarne had been a decent designer, then there wouldn't be stupid "fad" ideas in there like operator-overloading, or the curse of multiple-inheritence screwing things up, and he'd have had the courage to make all objects require a vtable and decend from a single "base" object, and then he could have implemented proper introspection into the darned language.

The whole "reference" instead of "pointer" seems to have bitten us in the ass more than it's helped, too.

It was interesting to see that C11's "anonymous" structs and unions that finally let us all implement some OO design features in nice way in C.

I started with QBASIC, C+some 68k on the Amiga, and BASIC/6502 on the C64.  But the C64 never really went well because the f*cking disk drive would goon out all the time.

Hahaha ... those disk drives were horrible, weren't they! 

[TheOldMan]

I wonder how you got exposed to all those mainframe languages that I missed out on.
My university CS Dept was running a PDP 11 and Unix, and we time-shared on another university's larger mainframe.
IIRC, we were started with Pascal on the mainframe, and then later courses shifted to C on the PDP 11.

Pascal was first, as an 'introduction' to programming. I didn't like it, and ended up taking a year off.
When I went back (different college, btw) I had to take fortran 4. Once that was done, the CS courses opened up. The college ran 2 tracks: Math based (ie, CS) and business based. The next couple of times I had to choose courses, I split between the 2. 1 CS course, 1 business course. Most of the odd stuff was from the business courses.
The college ran a DEC Vax 11/780, and did time share for some local places; they also ran an IBM 360/370 that did 'book keeping' stuff (hence the business degree track). Funny thing is, until my 3rd year, they didn't have C installed there. I learned it on the CoCo.

The profs were annoyed when they started offering classes in C, because by then I knew a lot of the other geeks, and they would always ask me to help debug (rather than the profs) The profs were surprised when I pointed out a few errors that they couldn't find (One of which was a bad pointer problem which would write to the stack by accident, and crash the whole system. Gotta love off-by-1 errors.

FWIW, I ended with a CS degree and a history minor. That's what happens when you take all the elective stuff as regular courses, and fill the last semester with things like 'art appreciation'

[TailChao]

In response to the original topic -

Is the goal is to just make development faster and simpler, but still have everything run on the PC-Engine?

Why not just run everything on a microcontroller and use the console for video, audio, and input? That way you can just write everything in C (or C++) on a PC with some little emulated bits, then shove it on a sub $5 ARM. I can almost guarantee this is "cheaper" since the time investment will be lower than adding HuC6280 support to another compiler, and you get a PC version of the game for similarly low effort.

The fact that the performance will likely be better is another plus.
Nintendo did it back in the day, and there's no shame in doing it now to ship a better product.

[elmer]

Is the goal is to just make development faster and simpler, but still have everything run on the PC-Engine?

Why not just run everything on a microcontroller and use the console for video, audio, and input? That way you can just write everything in C (or C++) on a PC with some little emulated bits, then shove it on a sub $5 ARM. I can almost guarantee this is "cheaper" since the time investment will be lower than adding HuC6280 support to another compiler, and you get a PC version of the game for similarly low effort.

Hahaha ... you're right, that's certainly one option. 

It may even be a sensible option.

But it's not the intellectually-challenging option. It's not "fun" (to me, at least).

The fact that the performance will likely be better is another plus.
Nintendo did it back in the day, and there's no shame in doing it now to ship a better product.

So did Sega with the Mega-CD and the 32x. 

***************

If you just want to write a "game", and don't really care what it runs on, then there are plenty of options out there ... like Unity.

Oh, and I, personally, have no interest in doing a PC game. Been there, done that, have the polo shirt.

It's interesting (to me, at least) to try to push the old hardware and see what can be done.

I've quickly lost interest in modifying either HuC or CC65. They're too broken at a low level to ever get good results.

We'll see whether the SDCC guru manages to keep up his interest in adding 6502 support to that compiler, or whether that will fade as the difficulties mount.

He's already added support for a different architecture and maintains that port, so he knows exactly what to do, and he has a much better idea of the potential difficulties than I do.

Whatever happens ... my time investment isn't likely to need to be that great, because there's no way that I can jump into that codebase and help, it's way too opaque.

As an alternative, morphping the NESHLA concept into a PCEHLA front-end for CA65 might be interesting to do.

There are so many compiler-compiler tools out there these days, that just reading in a program in C-style-assembler and then transforming it into standard-assembler, is a pretty simple project.

Then I could get to play with the CoCo/R parser-generator again. It's so much nicer that lex/yacc, and it already has a complete ANSI C grammar written for it. Just add the symbol table, shake it all up, put it into the oven for half-an-hour, and it's done. How tough could it be? (Famous last words!  )

But, it's a low priority at the moment.

[TailChao]

Hahaha ... you're right, that's certainly one option. 

It may even be a sensible option.

But it's not the intellectually-challenging option. It's not "fun" (to me, at least).

It may not seem intellectually challenging at first, but once you start thinking about dedicating all the HuC6280's time to banging raster effects while the ARM does your game logic it gets more interesting.

I totally understand your point though, and wouldn't actually go with this option for this particular console.

So did Sega with the Mega-CD and the 32x. 

They certainly did, and were probably inspired by a fairly large spill of chex mix.

If you just want to write a "game", and don't really care what it runs on, then there are plenty of options out there ... like Unity.

Oh, and I, personally, have no interest in doing a PC game. Been there, done that, have the polo shirt.

It's interesting (to me, at least) to try to push the old hardware and see what can be done.

They're certainly not bad options either. But my point in bringing up a PC version is so that people who don't own the original hardware can play the game easily. I ended up having to write an emulator for a current project since the licensing (and codebase) for existing ones were so chaotic. Although that was fun.

The best new-game-for-an-old-thing I've seen that's actually shipped is still Fantasy Zone II DX. Aside from being a stellar product for the System-16, it was also available day one for the PS2 - in 2008. I think we can do better nearly a decade later.

There are so many compiler-compiler tools out there these days, that just reading in a program in C-style-assembler and then transforming it into standard-assembler, is a pretty simple project.

Then I could get to play with the CoCo/R parser-generator again. It's so much nicer that lex/yacc, and it already has a complete ANSI C grammar written for it. Just add the symbol table, shake it all up, put it into the oven for half-an-hour, and it's done. How tough could it be? (Famous last words!  )

I think you would be able to manage with just a good macro assembler and well developed support libraries  .

[Bonknuts]

 The ARM for C code idea is actually pretty decent, if all you wanted to do was develop games in HLL for PCE. Genesis doesn't really need it, but it'd be decent for SNES too (the whole 65x and C mismangled thing).

 Assuming the cost is low, part of the problem is modifying an emulator to run an ARM core. It's possible (I have a build of mednafen that has a 68k core running as accessible via ports on the PCE hardware bank).

 I'm comfortable with assembly, so I'm good without it. But I can see it being attractive to some.  I also code for the PCE because of the challenge, and that games really didn't push its limits. That might not be the motivator for all, though.

[TailChao]

Assuming the cost is low, part of the problem is modifying an emulator to run an ARM core. It's possible (I have a build of mednafen that has a 68k core running as accessible via ports on the PCE hardware bank).

I was wondering why that was in the Mednafen source for years. Good to know.


Also, I didn't mean emulate the whole ARM core on the PC. Ideally you'd define a simple messaging system between the HuC6280 and the ARM (or whatever coprocessor) on the cartridge. Then you can have all the coprocessor functionality compiled natively on the PC.

If the coprocessor is running all your game logic, you technically don't have to emulate the full PC-Engine hardware at all, just what it was supposed to do (get inputs, display this, play this noise).

For example, I have all the game logic running natively on the 6502 in the 7800. There is an ARM in the cartridge which runs a softsynth and responds to simple messages like PLAY, STOP, ATTEN, PAUSE, RESUME, and RESET. When running the game on Windows, the softsynth is native and the game is emulated. You could just as easily do the opposite.

Edit :

I'm comfortable with assembly, so I'm good without it. But I can see it being attractive to some.  I also code for the PCE because of the challenge, and that games really didn't push its limits. That might not be the motivator for all, though.

I agree, and yes - there is always more that can be done with any hardware.

Unfortunately, it can't be done for free.

[Bonknuts]

Assuming the cost is low, part of the problem is modifying an emulator to run an ARM core. It's possible (I have a build of mednafen that has a 68k core running as accessible via ports on the PCE hardware bank).

I was wondering why that was in the Mednafen source for years. Good to know.

It actually had its own bitmap display the overlaid the PCE display. Ports on the hardware bank, which is always mapped, was used to communicate with it and the PCE processor. The idea was that initially you load a script file, and code block, to the 68k via these ports. Then when the game runs, when it receives a special command - it displays an overlaid subtitled script for length of time. The idea was to hook all CDPLAY and ADCPLAY routines to write the sector arguments to the ports as well, which would hash into a lookup table to start the overlay script - instant subtitling for cinemas and ADPCM parts of Japanese games.

 There was also 1k of ram for the PCE hack/hook code to use, mapped in the hardware bank open bus area as well.

[Bonknuts]

FWIW, I ended with a CS degree and a history minor. That's what happens when you take all the elective stuff as regular courses, and fill the last semester with things like 'art appreciation'

That made me laugh. I haven't officially declared a minor, but it'll probably be psychology