Jump to content
IGNORED

SDCC PIC16 C compiler?


zezba9000

Recommended Posts

I certainly tried to make it so. :-)

 

 

O lol, well maybe you're the guy that sent me the one I ordered and am waiting for in the mail !

 

I'm not really familiar with C#. I'm mostly a Linux guy with a Mac laptop that uses Windows as rarely as possible.

 

C# is fully open source for all platforms, Win, Lin, Mac, etc under the MIT licence. Because it has a compiler as a service it makes it very power to handle special case stuff. Also because its IL code is very verbose that can also just be used. You don't need to touch Windows to use C# in a fully open source posix way these days.

 

Many devs on here I think are much older than I am. I just have a passion for portable code and APIs and own many old computer / consoles. Many older Atari systems are before I was born (1985). Most my dev experience is with stuff like C/C++ and notability C# which is you know C can pick up in a sec. The only harder core ASM stuff I've done is write GPU programs before there was HLSL's.

 

My current research project is translating .NET IL (compiled from C#) to C89, C++, etc. This can also be used to tranlate to an asm lang as well. Here is a link: https://github.com/reignstudios/IL2X

 

I started out making a C# transpiler to C89 so I could target old systems with stuff like CC65 but think translating .NET IL may be better as C# 8 has many performance features you would might want to use on an old Atari system. In short if that project terns out well I can and plan on adding support for Intellivision specifically thus allowing C# code to run on it.

Edited by zezba9000
Link to comment
Share on other sites

I should add I'd be happy to help you with any CP1610 bits.

 

For sure, I'll keep this in mind. If my C# experimental IL translator project doesn't pan out as I expect, I may just work on developing a new lang that addresses many different issues including the ones discussed here.

Link to comment
Share on other sites

Some years ago, dZ-Jay and I were toying around with a language concept called SPLINT (Simple Programming Language for INTellivision). dZ came up with the name and much of the initial concept. I was working on library functions and providing my own feedback into the design. SPLINT would have offered some higher level constructs for handling dispatches, interrupts, game phases, etc. It was a much more structured approach.

 

I believe many of the ideas ended up in dZ's P-Machinery framework. When IntyBASIC arrived, it sucked the rest of the oxygen out of the room for a bespoke language.

 

I personally would love a C compiler, or better, a C/C++ compiler. I don't actually want a bespoke language for me. I've programmed embedded C for a couple decades now and am very comfortable with the fact I can't just take an off-the-shelf bit of code and compile it and expect for it to work. But, then, I'm building tools for myself, not everyone else.

Link to comment
Share on other sites

I think one benefit of having a language that is not following some kind of standard is that people can't expect to simply throw existing source code on the compiler and out comes a working program. If you advertise a C compiler for the Intellivision, some people will assume it works like a C compiler for any other target. A language like IntyBASIC may sound like any other BASIC but it doesn't take many minutes to figure out it is its own language, just with heritage of the old BASIC languages. Although there was an ANSI standard, BASIC also has never been quite that source code compatible across targets beyond the trivial HELLO WORLD program.

 

If C supported attributes that gave special compiler errors for what memory pool a struct can go in (as you could do in C#) I don't see why C like lang wouldn't work. This way even stack allocated objects know what stack memory to go in without needing to do it in an allocator.

Link to comment
Share on other sites

Some years ago, dZ-Jay and I were toying around with a language concept called SPLINT (Simple Programming Language for INTellivision). dZ came up with the name and much of the initial concept. I was working on library functions and providing my own feedback into the design. SPLINT would have offered some higher level constructs for handling dispatches, interrupts, game phases, etc. It was a much more structured approach.

 

I believe many of the ideas ended up in dZ's P-Machinery framework. When IntyBASIC arrived, it sucked the rest of the oxygen out of the room for a bespoke language.

 

I personally would love a C compiler, or better, a C/C++ compiler. I don't actually want a bespoke language for me. I've programmed embedded C for a couple decades now and am very comfortable with the fact I can't just take an off-the-shelf bit of code and compile it and expect for it to work. But, then, I'm building tools for myself, not everyone else.

 

Well because C# is just a better version of C++ in many aspects, if it compiled to odd memory embedded platforms this would be a pretty good option.

 

If not a single memory ownership lang that doesn't need a or use a GC my brother has come up with (kinda like Rust but way easier to use and read) might be best. I just love C# because of all the productive IDE's and tools you get with it.

 

I also have a micro GC option that can run in less than a KB of ram for embedded platforms. Normally you use none GC object though and pre-allocate stuff on the stack but its cool you can make them.

Edited by zezba9000
Link to comment
Share on other sites

O lol, well maybe you're the guy that sent me the one I ordered and am waiting for in the mail !

 

Yep, that's me!

 

 

If C supported attributes that gave special compiler errors for what memory pool a struct can go in (as you could do in C#) I don't see why C like lang wouldn't work. This way even stack allocated objects know what stack memory to go in without needing to do it in an allocator.

 

Plain C has a very casual pointer model where you can bounce arbitrary pointers off of either (void *) or (char *). You'd need to enforce a bit more discipline and limit pointers quite a bit more. Also, the definition of sizeof() gets a bit tricky.

 

Me? I'd rather just expose all of the wackiness of the Intellivision console and get an optimized compiler so i don't have to worry so much about basic arithmetic and bookkeeping. I don't want a high level framework, because that's not my thang.

 

I'd be happy to support someone who is building such a thing because it is their thang.

Link to comment
Share on other sites

Many devs on here I think are much older than I am. I just have a passion for portable code and APIs and own many old computer / consoles. Many older Atari systems are before I was born (1985). Most my dev experience is with stuff like C/C++ and notability C# which is you know C can pick up in a sec. The only harder core ASM stuff I've done is write GPU programs before there was HLSL's.

 

You're 10 years younger than I am (1975). Back when I was in college, I had a reputation on USENET for being "old for my age" because I was steeped in knowledge about PDPs and other gear that was as old as I was or older. ;-) I feel ya.

 

Since then, I spent a couple decades as a processor and memory system architect on specialized DSPs, and worked closely with the compiler team that made compilers for them. That's where I get my chapter/verse cred on C compiler semantics. My previous employer had some quirky devices that nonetheless got C compilers.

 

I'm now at a different $DAYJOB where I don't quite have that tight connection to the instruction set and compiler.

Link to comment
Share on other sites

I think one benefit of having a language that is not following some kind of standard is that people can't expect to simply throw existing source code on the compiler and out comes a working program. If you advertise a C compiler for the Intellivision, some people will assume it works like a C compiler for any other target. A language like IntyBASIC may sound like any other BASIC but it doesn't take many minutes to figure out it is its own language, just with heritage of the old BASIC languages. Although there was an ANSI standard, BASIC also has never been quite that source code compatible across targets beyond the trivial HELLO WORLD program.

I dont follow ... an advantage of a programming language is that it is slightly different from sibling dialects, enough to force people to re-learn patterns and solutions for different implementation models and paradigms? Are you sure about that?

 

dZ.

Link to comment
Share on other sites

I dont follow ... an advantage of a programming language is that it is slightly different from sibling dialects, enough to force people to re-learn patterns and solutions for different implementation models and paradigms? Are you sure about that?

 

I think the only point is that there's value in lowering your users' expectations about compatibility so they actually take the time to understand what they're looking at.

 

I can see how that would be valuable to the maintainer of the language. I can also see how it might push some users out of their comfort zone and lead to better results; most of these folks are the highly skilled folks that probably would have gotten there anyway, along with some folks on the borderline that get pushed over the edge.

 

I can further see how it makes it a steeper on-ramp for just about everyone else.

Edited by intvnut
Link to comment
Share on other sites

Me? I'd rather just expose all of the wackiness of the Intellivision console and get an optimized compiler so i don't have to worry so much about basic arithmetic and bookkeeping. I don't want a high level framework, because that's not my thang.

 

I'd be happy to support someone who is building such a thing because it is their thang.

I think there is a place for a higher level of abstraction, either via a new language or extensions to BASIC or Assembly. Personally, I don't like BASIC itself, so IntyBASIC doesnt attract me (even though I admire it's versatility and utility). I opted for Assembly Language because I thought that manipulating the macro pre-processor of the assembler would be easier than building a compiler. I also thought that adding high-level data structures and abstraction models to an existing platform (as1600) would be preferable than having to adapt a yet-to-implement one on top of implementing it. The best laid schemes of mice and men, as they say.

 

I still believe there is value in building high level frameworks (if not languages) for Intellivision game programming, and what I have built for P-Machinery is quite useful already.

 

I would love a C compiler for the Intellivision, but to me that's half the battle. I rather have the high level abstractions for the game-specific domain than just the language.

 

I appreciate that it's not everyone's cuppa, but it is mine at least. :)

 

dZ.

Link to comment
Share on other sites

 

I think the only point is that there's value in lowering your users' expectations about compatibility so they actually take the time to understand what they're looking at.

 

I can see how that would be valuable to the maintainer of the language. I can also see how it might push some users out of their comfort zone and lead to better results; most of these folks are the highly skilled folks that probably would have gotten there anyway, along with some folks on the borderline that get pushed over the edge.

 

I can further see how it makes it a steeper on-ramp for just about everyone else.

I get all that, but to me that's just lazy-thinking, sorry. It's an implementor making his life easier rather than his target users'. If that's their goal, to make something that is easier to implement and maintain, then OK. However, if the goal is to make something useful, lower the barriers to entry, and attract new users, then there is something to be said for solving people's problems and building cognitive bridges to existing models. *shrug*

 

dZ.

Link to comment
Share on other sites

I think there is a place for a higher level of abstraction, either via a new language or extensions to BASIC or Assembly. Personally, I don't like BASIC itself, so IntyBASIC doesnt attract me (even though I admire it's versatility and utility). I opted for Assembly Language because I thought that manipulating the macro pre-processor of the assembler would be easier than building a compiler. I also thought that adding high-level data structures and abstraction models to an existing platform (as1600) would be preferable than having to adapt a yet-to-implement one on top of implementing it. The best laid schemes of mice and men, as they say.

 

I still believe there is value in building high level frameworks (if not languages) for Intellivision game programming, and what I have built for P-Machinery is quite useful already.

 

I would love a C compiler for the Intellivision, but to me that's half the battle. I rather have the high level abstractions for the game-specific domain than just the language.

 

I appreciate that it's not everyone's cuppa, but it is mine at least. :)

 

 

To be clear: I'm not against higher level frameworks and proper abstraction.

 

I am, however, skeptical of baking too high a level of abstraction into the language with the assumption that a particular framework will always be used. While that's great for applications that match that model, it's also stifling.

 

That's why I'd like a plain, unadorned C compiler that I could build whatever framework I like on top of. And, when that framework doesn't suit what I was trying to do, I could discard it and build a different one.

 

Having a too-fancy pointer model that tries to hide the quirkiness of the Intellivision memory map—which is the main topic that caught my attention and lead to the post you replied to—would add a pervasive cost, while only benefiting those who weren't willing to learn the underlying reality of the hardware. I'd prefer to expose the underlying quirkiness, and let folks build their own abstractions on top of it that are appropriate for what they're trying to do.

 

If I produced a C compiler tomorrow, it wouldn't be very popular. On its own it'd be boring. It'd benefit from a library that provided some sort of framework. That'd get folks started. And, when the time came, you could ignore the framework.

Link to comment
Share on other sites

 

 

To be clear: I'm not against higher level frameworks and proper abstraction.

 

I am, however, skeptical of baking too high a level of abstraction into the language with the assumption that a particular framework will always be used. While that's great for applications that match that model, it's also stifling.

 

That's why I'd like a plain, unadorned C compiler that I could build whatever framework I like on top of. And, when that framework doesn't suit what I was trying to do, I could discard it and build a different one.

 

Having a too-fancy pointer model that tries to hide the quirkiness of the Intellivision memory map—which is the main topic that caught my attention and lead to the post you replied to—would add a pervasive cost, while only benefiting those who weren't willing to learn the underlying reality of the hardware. I'd prefer to expose the underlying quirkiness, and let folks build their own abstractions on top of it that are appropriate for what they're trying to do.

 

If I produced a C compiler tomorrow, it wouldn't be very popular. On its own it'd be boring. It'd benefit from a library that provided some sort of framework. That'd get folks started. And, when the time came, you could ignore the framework.

 

I agree with this. A lang should not be considered or convoluted with frameworks and APIs. Those should be modules you can choose and pick from.

 

 

Also here are some ideas I have for using C# to target Intellivision. From what you have said I think this model I'm suggesting would be highly powerful as it just gives compiler hints rather than forcing types to live in specific memory pools which allows the same game logic code to be shared with Atari 2600/5200, etc.

 

C# allows you to create any custom attribute that can be used on structs, classes, field and methods.

Also FYI a char in C# is 2 bytes already.

 

So take the following C# example (NOTE: structs in C# are the same as C)

using System;

public enum MemoryPoolType
{
  Auto,// auto choose what memory bank to use
  Bank_8bit,// 8 bit memory on Intellivision
  Bank_16bit,// 16 bit memory on Intellivision
  Bank_ROM// ROM cartridge / program memory
}

// IL2X translator looks at this attribute object at compile time when targeting Intellivision ASM output
public class MemoryPoolAttribute : Attribute
{
  public readonly MemoryPoolType type;
  public readonly int poolIndex;

  public MemoryPoolAttribute(MemoryPoolType type, int poolIndex)
  {
    this.type = type;
    this.poolIndex = poolIndex;
  }
}

[MemoryPool(MemoryPoolType.Bank_8bit, 0)]// give compiler error if any type doesn't fix this rule on Intellivision, ignored on single memory pool systems
struct Vec3
{
  public byte x, y, z;
}

// this pattern allows you to have an "object oriented" design and access differnt memory pools from a single object
struct Vec3
{
  [MemoryPool(MemoryPoolType.Bank_8bit, 0)] public byte x, y;// puts in 8bit memory on Intellivision, ignored on single memory pool systems
  [MemoryPool(MemoryPoolType.Bank_16bit, 0)] public short z;// puts in 16bit memory on Intellivision, ignored on single memory pool systems
  // OR
  [MemoryPool(MemoryPoolType.Bank_16bit, 0)] public byte x, y;// puts in 16bit memory on Intellivision as 2 bytes per field, ignored on single memory pool systems
  [MemoryPool(MemoryPoolType.Bank_8bit, 0)] public short z;// puts as 2 bytes in 8bit memory on Intellivision, ignored on single memory pool systems
}


struct Vec3
{
  public byte x, y, z;// would auto choose Bank_8bit on Intellivision
}

struct Vec3
{
  public int x, y, z;// 32bit types are changed to mean 16bit and sizeof(int) would respect this
}

struct Vec3
{
  public int x, y, z;// auto puts into 16 bit memory

  public int Foo(int x, byte abc)// auto puts "x" into 16 bit stack and "abc" into 8 bit stack
  {
    return x + abc;// pulls from 16bit and 8bit stack writing return value to 16bit stack
  }
}

class MyObject
{
  public char prefix;// 2 bytes on Intellivision, 1 byte on Atari 2600
}

Does that make sense? The idea is expandable to more platforms than just Intellivision. Its general purpose.

"poolIndex" is used if there are multiple 16 / 8 bit memory pools to choose from.

 

Heap allocations could also use these attributes. The allocator would just have to keep track of multiple banks for a single class object.

Edited by zezba9000
Link to comment
Share on other sites

I'm not familiar with C#, so I'm left wondering how this particular one could possibly work without Vec3 having a top-level structure with pointers to the actual storage:

.

struct Vec3
{
  [MemoryPool(MemoryPoolType.Bank_8bit, 0)] public byte x, y;// puts in 8bit memory on Intellivision, ignored on single memory pool systems
  [MemoryPool(MemoryPoolType.Bank_16bit, 0)] public short z;// puts in 16bit memory on Intellivision, ignored on single memory pool systems
}

.

The normal way C and C++ work is that each non-static member exists at some byte offset relative to the base of the structure, that way you can have a single pointer that describes the location of the structure, and can find the members with a compile-time known byte offset from that pointer.

 

If I have an array of this particular Vec3 in your proposed C# dialect, how do I find a.x, a.y, and a.z? What's the underlying instruction sequence the processor uses to compute the addresses being accessed? (Pseudocode is fine. IL, even, if it's low enough level.)

Edited by intvnut
Link to comment
Share on other sites

 

 

To be clear: I'm not against higher level frameworks and proper abstraction.

 

I am, however, skeptical of baking too high a level of abstraction into the language with the assumption that a particular framework will always be used. While that's great for applications that match that model, it's also stifling.

 

That's why I'd like a plain, unadorned C compiler that I could build whatever framework I like on top of. And, when that framework doesn't suit what I was trying to do, I could discard it and build a different one.

 

Having a too-fancy pointer model that tries to hide the quirkiness of the Intellivision memory map—which is the main topic that caught my attention and lead to the post you replied to—would add a pervasive cost, while only benefiting those who weren't willing to learn the underlying reality of the hardware. I'd prefer to expose the underlying quirkiness, and let folks build their own abstractions on top of it that are appropriate for what they're trying to do.

 

If I produced a C compiler tomorrow, it wouldn't be very popular. On its own it'd be boring. It'd benefit from a library that provided some sort of framework. That'd get folks started. And, when the time came, you could ignore the framework.

 

I also don't agree with an abstraction on the memory model. The distinction between 8-bit and 16-bit seems to me a basic and important one on the Intellivision platform, and not really such an onerous demand on programmers.

 

I agree with you that a fancy data type that does magic underneath to access all types of storage would be too costly for very little gain.

 

However, there is some "quirkiness" that I think provides incidental and detrimental complexity, which I would not miss at all if it ever were abolished: things like the crazily scattered memory map, or the silly way in which the bit pattern of colors is different depending on the element you are accessing and the phases of the moon.

 

Like you said, a C compiler by itself would be boring. Unlike you, I do not see a framework as a mere "stepping stone" into the platform, but as a solution to a problem: that of programming games for the Intellivision.

 

IntyBASIC offers, for example, a working programming model that appears to work for most folks. I don't expect those folks to switch from IntyBASIC to Assembly as a natural evolution of their craft just to move away from its limitations. In this modern day and age, I would expect them to either extend the language or provide additional library modules. One of the promises of IntyBASIC is that it could easily be extended with Assembly Language routines accessed directly from the BASIC language itself via macros and user-defined functions, and that you could change the epilogue/prologue at will. Personally, I would like to see better and more robust interfaces for these sort of things.

 

That's what I see as the natural progression of a programming environment on this and any platform: provide a basic assembler or compiler, a robust and useful library, and a means of extension -- and not, as you and nanochess sometimes appear to suggest, a bare bones API and framework that is there only to hand-hold newbies, which are then expected to shed it as soon as they can grow out of it like "real programmers."

 

Anyway, I digress. It think we're both in agreement in most of these points about the utility and desirability of a C compiler and framework, if not in the motives for it. :)

 

-dZ.

Link to comment
Share on other sites

 

I agree with this. A lang should not be considered or convoluted with frameworks and APIs. Those should be modules you can choose and pick from.

 

 

 

I don't think anybody has ever suggested this.

 

My point has always been that they both should exist at the same time, not that they should be baked together, because a language will not help many people and has limited reach and utility without a domain-specific framework and API around it.

 

However, when these conversations arise, the focus is typically on just the bare language, which prompts my response.

 

-dZ.

Link to comment
Share on other sites

 

That's what I see as the natural progression of a programming environment on this and any platform: provide a basic assembler or compiler, a robust and useful library, and a means of extension -- and not, as you and nanochess sometimes appear to suggest, a bare bones API and framework that is there only to hand-hold newbies, which are then expected to shed it as soon as they can grow out of it like "real programmers."

 

Consider the EXEC: It was a great framework for the initial games. Eventually, though, games outgrew it, and either implemented more direct approaches, or new frameworks.

 

My point is whatever framework you provide to get people started will eventually become a limiting factor. But, by the time that happens, you're probably in a better position to develop the next framework once you've learned what you really need. Or, at least move to a different framework someone developed.

Link to comment
Share on other sites

 

However, when these conversations arise, the focus is typically on just the bare language, which prompts my response.

 

The bare language always comes first, and the frameworks (plural!) come later.

 

I've had AS1600 for almost two decades now. How long has P-Machinery been around?

Link to comment
Share on other sites

Consider the EXEC: It was a great framework for the initial games. Eventually, though, games outgrew it, and either implemented more direct approaches, or new frameworks.

 

Ah, of course I was expecting this ... The EXEC. You know what the problem with the EXEC was? It wasn't that it was a framework. It was that it was static and baked into the console, and thus could never be adapted to solve new problems, or modified to do so in different ways.

 

We don't have that any more, do we?

 

Sure, new frameworks may come along, but the reason the EXEC was left behind is very specific, there was nothing you could do about it.

 

 

My point is whatever framework you provide to get people started will eventually become a limiting factor. But, by the time that happens, you're probably in a better position to develop the next framework once you've learned what you really need. Or, at least move to a different framework someone developed.

 

I don't necessarily agree with the first statement, not when we're talking about an exceedingly narrow domain as Intellivision game programming.

 

Of course, I am not suggesting that a framework can support 100% of cases perfectly, only that -- in practice -- the exceptions are really not as many as some would think.

 

You bring up the EXEC, I bring up IntyBASIC. IntyBASIC is not just a language, with it comes some very specific patterns and model of organizing logic (a framework), even if it is in a way rudimentary. I recall when some said the CP-1610 and the Intellivision was too limiting for such a language to be useful. In practice, it turned out that the high-performance and intense micro-optimizations we thought we needed, were mostly unnecessary to the vast majority of IntyBASIC games. (The whole "WAIT" all over the place still surprises me, and yet it seems to be effective to most people.)

 

-dZ.

Link to comment
Share on other sites

 

The bare language always comes first, and the frameworks (plural!) come later.

 

I've had AS1600 for almost two decades now. How long has P-Machinery been around?

 

Hehe, touché. My reaction is not to the construction of the language, but to the suggestions that "this language is what we need, and it'll solve our problems," along with a sprinkle of "frameworks? nah, a proper language is what you need. Frameworks are for newbies."

 

I think there is utility in designing them in parallel, and as a community effort, I do not see why this wouldn't work; but there has to be focus and support for it, and I just don't see it, which makes me sad. :(

 

I'm still working on P-Machinery because $REAL_LIFE gets in the way and also because I'm kind of on my own (although of course, I owe quite a lot of it to your and Arnauld's wonderful assistance). Most people nowadays are happy with IntyBASIC so any prospects of community participation keep on shrinking. *shrug*

 

Anyway, none of this was intended to be a slight to anybody. Just that I find that any energy spent on creating yet another language is another missed opportunity on extending and maturing IntyBASIC or the assembler. That is all.

 

-dZ.

Link to comment
Share on other sites

 

Ah, of course I was expecting this ... The EXEC. You know what the problem with the EXEC was? It wasn't that it was a framework. It was that it was static and baked into the console, and thus could never be adapted to solve new problems, or modified to do so in different ways.

 

We don't have that any more, do we?

 

And when you adapt version 1.0 of the framework into version 1.1... it's not the same framework any more. You have a new framework that's closely related to the previous one.

 

Of course, in the case of the EXEC, it needed more than just extension. Games that didn't fit its model needed a different programming model, not some tweaks.

 

I feel like there's a goalpost on wheels here, or that we're talking past each other.

 

Anyway, one of the aspects of IntyBASIC I find a little chafing is that it has a specific model of how you load graphics and how you update MOBs. And, given the way its sound engine works, there's an interaction between how many GRAM tiles you can update and whether you have 3 voice or 6 voice music. This is baked into the language implementation, in intybasic_prologue/epilogue.asm. Sure, you can rewrite those files and change the language, but then you're no longer in standard IntyBASIC.

 

If I were to provide a C compiler, and some libframework.a (and corresponding headers), you could reject the entire framework by not linking against it. Or, I could have a libfooframework.a and libbarframework.a and pick whichever one is the best fit for my application. That's my preferred model. I realize that most folks might want something more accommodating. I'll let others build those accommodations on the base I provide.

Link to comment
Share on other sites

 

Anyway, none of this was intended to be a slight to anybody. Just that I find that any energy spent on creating yet another language is another missed opportunity on extending and maturing IntyBASIC or the assembler. That is all.

 

 

Why not let folks scratch their own itches without getting a bunch of complaints that they aren't scratching yours.

Edited by intvnut
Link to comment
Share on other sites

 

Feel free to ignore my comments as well, it's super easy, Mr. Forum Police. :roll:

 

I suppose you could always start up a thread on programming framework design and carry the framework discussion over there, just as this thread was forked out of the moribund Hive discussion thread.

 

In the meantime, I'm interested in learning more about this C# to IL to asm process. If it pans out, you may have a new language to build that framework over someday.

Edited by intvnut
Link to comment
Share on other sites

And when you adapt version 1.0 of the framework into version 1.1... it's not the same framework any more. You have a new framework that's closely related to the previous one.

 

Of course, in the case of the EXEC, it needed more than just extension. Games that didn't fit its model needed a different programming model, not some tweaks.

 

I feel like there's a goalpost on wheels here, or that we're talking past each other.

 

Perhaps. I don't think I've moved the goalposts. I guess your definition of framework is a bit more stricter than mine. That's fair.

 

Anyway, one of the aspects of IntyBASIC I find a little chafing is that it has a specific model of how you load graphics and how you update MOBs. And, given the way its sound engine works, there's an interaction between how many GRAM tiles you can update and whether you have 3 voice or 6 voice music. This is baked into the language implementation, in intybasic_prologue/epilogue.asm. Sure, you can rewrite those files and change the language, but then you're no longer in standard IntyBASIC.

 

If I were to provide a C compiler, and some libframework.a (and corresponding headers), you could reject the entire framework by not linking against it. Or, I could have a libfooframework.a and libbarframework.a and pick whichever one is the best fit for my application. That's my preferred model. I realize that most folks might want something more accommodating. I'll let others build those accommodations on the base I provide.

 

I agree with your points there, and that is my preferred model as well. However, I do not see much interest from veterans to provide such frameworks, and the newbies are by definition not skilled to do so.

 

I do what I can when I can with in the programming forum, but unfortunately most people are using IntyBASIC and I am not very steep in it at the moment.

 

However, I would definitely participate in an effort for higher-level abstractions and libraries for any language (for as much as I can). I guess I have just not approached the subject adequately. What I see happening is this:

 

- I want to build a new language

- You know what we really need? Better frameworks.

- Nah, frameworks are for newbies (or frameworks are too limiting).

 

I guess, implicit in my recommendation is my interest in participating on such an endeavor; but I can see how it sounds like a complaint. I'm sorry if that is how it is taken.

 

-dZ.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...