Which would be your desired programming language for the CPC?

[GUNHED]

Hard to think of any besides C but we already have cross-dev tools for that. Maybe there are C compilers running on actual CPC but haven't tried and don't know how easy or fast they are. Maybe some minimal C with some minimal interface would be fun to try in actual hardware. But at the end of the day you are gonna need that speed. I used to write things in SDCC and I still do sometimes for prototyping fast, but I realize memory grows so fast, it's not hard to switch back to 100% assembly.

I would actual like to search what C compilers already exist that run natively on CPC and if there is an easy IDE/editor + compiler compo to use? But then it would take time off from actual developing things in what I am already used to. I was never the "try every OS or every programming language" guy.

There is already a very new C implementation for SymbOS - just in case you want to code in C.  But personally I never got "warm" with C. There must be something else in the universe. 

[zhulien]

https://8bitology.net/poc/jscompile/

https://youtu.be/q8kBgWHT944?si=JJtUTlINHFm75H_v

https://github.com/PrimalNinja/jscc

Javascript... as a compiler even as a subset which can also work in a browser.

I hope to one day finish it...

Also

JSASM with its z80 translation so you can code in assembly language within JS, I'm hoping to modify jscc to generate jsasm them to z80

https://github.com/PrimalNinja/jsasm

Important features to me, support for variety of memory models and dynamic loading of code modules or drivers

Primal will play a role in that


https://github.com/PrimalNinja/Primal

[zhulien]

Visual Basic.

Want to finish it? It can current parse itself to retarded.

https://github.com/PrimalNinja/vbcc

[zhulien]

Well, the CPC can have up to 4 MB of RAM and up to 32 GB of mass storage.
At least most todays CPCs have 576 KB of RAM. So, with that "limitation" pretty much everything can be done.

Why didn't it happen already?
well, commercial are only used up to 128 KB of RAM, to be able to target more customers.

IMO an well language must be implemented in assembler, therefore 576 KB or RAM is just _HUGE_ 

As Much as I'd like time to finish my js cross compiler, two things I have designed it around for now.

The OOP isn't a full OOP implementation. For performance it is really a scope.  As a scope, and syntactic sugar I can ensure that an object implimentation fits in a single block (16kb if on cpc). This and some control constructs, maybe hints within the comments can even force multiple objects to reside in the same 16kb. Possible even create duplicate instances of the implementation so an object can reside in more than one bank.  

This is important in a banked system so you can call one object from within another without having to always bank for ever call (unless you want to). 

Since doing the current coding I have leaned towards packed far addresses rather than 24bit far addresses because it makes coding a whole lot simpler and a lot less wasted register use and juggling when using the 16bit far addresses.

If one of the good assemblers supported this as an option (I suggested it several times before but only got pushback for it to be an option), then likely I'd stick with assembly language.  But I also get that not everyone wants to code in assembly language.

No 3gl can code as optimal as hand coded assembly language with a z80 target, they all produce crap code, some less crap than others. 

I wish the cpc community would work together more rather than everyone doing their own thing always, sometimes work together like demo groups do, why do we only work together for useless demos (still impressive though)?

There is so much talent in the cpc community its overlooked what a group wanting to work together could do?

Why don't we have locomotive basic 10 now with full overscan screen modes 3, 4, 6... full plus machine commands, split across more than 1 16kb ROM, def fn that allows for modern multi-line functions,  and more... and basic programs that potentially could be megabytes in size. Inbuilt tiles, sprites, scrolling commands etc.

Its possible, lomotive software created a fantastic product but limited it to 16kb, likely for cost, nothing more.  Make a 128kb basic rom...

And to me we need a driver model for developers of hardware just to make a new driver when they make their hardware. This is 2024 and now we have a hardware hell... the hardware works well enough with eachother which is amazing for a 1984 computer but... 

I started primal as a way to address some of the issues, it could compliment or replace the cpc os rom one day, but offer memory management and tasking and drivers!!!

Anyone else want drivers or locomotive basic 10 on cpc?  

[GUNHED]

Well, maybe the best would be to develop a new language (easy, and understandable) around the CPC and its features. So to say custom made. What do you think?

[eto]

I doubt that anything that needs the presence of ROM will see huge success.

It already limits the user base to those who have the hardware, knowledge and willingness to try it out. But then the programs created can also only be shared with those that have also installed the language ROMs. (It would make sense though if it comes in a hardware package, that gains wide traction. E.g. a CPC speeder/graphics solution that comes together with enhanced Basic 10 that supports the new features.)

[GUNHED]

Nobody talked about putting a 'new' language in ROM. Well, yes, somebody did actually 

But - hey - that's a great idea!
Putting it into ROM(s) will save RAM, makes it immediately available and save/stable.
And today nearly everybody has an ROM expansion (or similar) anyway.

Great examples for languages in ROM are Maxam and BCPL for example. Of course it was harder for them back the day, because only expensive EPROM card were available. Today orgAMS shows how successful ROM-software can be.

So, imo a ROM-resident and a RAM-based version of such a new language would be nice to have.

[Prodatron]

I doubt that anything that needs the presence of ROM will see huge success.

Surely anything that requires a ROM and therefore won't run on a bare original system will already result in a huge drop in potential users

[Anthony Flack]

I guess my question would be what is the objective?

I'm happy enough coding in ASM on the CPC, but if there was a stack of existing code you wanted to bring across? PICO-8 and SCUMM would be I think way too slow, but I wonder if Inform 7 (which modern interactive fiction is written for) would be possible. You could potentially have a cumbersome new way to play a whole lot of modern text adventures.

[zhulien]

I doubt that anything that needs the presence of ROM will see huge success.

It already limits the user base to those who have the hardware, knowledge and willingness to try it out. But then the programs created can also only be shared with those that have also installed the language ROMs. (It would make sense though if it comes in a hardware package, that gains wide traction. E.g. a CPC speeder/graphics solution that comes together with enhanced Basic 10 that supports the new features.)

ROMBoards are plentiful now on CPC and much much much cheaper than the price of a used CPC.  If you make it ROMbased, you can support 64kb machines.  Having said that, go buy a 512kb RAM expansion, they are also much much much cheaper than the price of a used CPC.  A ROM replacement updated Locomotive BASIC, Maglev BASIC or Bullet train BASIC? has merits, if backward compatible with the tokens (proven already it's possible, but not trivial), then we can just turn on the computer and use it as normal but with lots of cool features.  Not just a FRAME command and inline strings for BAR commands as with Locomotive 1.1.

[zhulien]

Nobody talked about putting a 'new' language in ROM. Well, yes, somebody did actually 

But - hey - that's a great idea!
Putting it into ROM(s) will save RAM, makes it immediately available and save/stable.
And today nearly everybody has an ROM expansion (or similar) anyway.

Great examples for languages in ROM are Maxam and BCPL for example. Of course it was harder for them back the day, because only expensive EPROM card were available. Today orgAMS shows how successful ROM-software can be.

So, imo a ROM-resident and a RAM-based version of such a new language would be nice to have.

And there is the c ROM

[zhulien]

I guess my question would be what is the objective?

I'm happy enough coding in ASM on the CPC, but if there was a stack of existing code you wanted to bring across? PICO-8 and SCUMM would be I think way too slow, but I wonder if Inform 7 (which modern interactive fiction is written for) would be possible. You could potentially have a cumbersome new way to play a whole lot of modern text adventures.

Objectives I see:

- depending on the language, it opens up for those who want to start coding on CPC not in Assembly Language.  A more enhanced locomotive BASIC could be good.  Look at Vision BASIC for Commodore 64, it's very impressive... 
- driver support please!!!
- extensibility to the language beyond BAR commands would be nice, or... if the language itself was an enhanced locomotive BASIC with inbuilt compilation facilities, maybe you can create libraries of BAR commands in a more relocatable way with the language itself

[GUNHED]

An open system with expandability is a very good point!