If you could decide which programming language should be ported new to the CPC (for example using SymbOS or FutureOS as platform), which language would it be?
Consider today's possibilities: RAM expansions, mass storage, internet access etc. :)
Visual Basic.
What do you mean by "ported"? Generate code for CPC or to program inside the CPC?
I like the thread about porting small smalltalk, even if did not succeed.. it is really a language I like. Maybe "abusing" extended ram there may be a chance.
A LUA pico-8 like mode...
I think you could even do the Pico-8 graphics, expand the Gate Array limits to drive the screen 256x256 with 2x2 blocky pixels in 16 colours.
Quote from: asertus on 11:12, 04 October 24What do you mean by "ported"? Generate code for CPC or to program inside the CPC?
I like the thread about porting small smalltalk, even if did not succeed.. it is really a language I like. Maybe "abusing" extended ram there may be a chance.
Well, either port it from some system or do a rewrite. Or so something completely new.
The question is which language would be desirable?
Quote from: retro space on 12:41, 04 October 24A LUA pico-8 like mode...
I think you could even do the Pico-8 graphics, expand the Gate Array limits to drive the screen 256x256 with 2x2 blocky pixels in 16 colours.
Using the CPC in 256x256 pixel mode and four colors can be done by just adapting some CRTC registers. :)
But which programming language do you mean?
I was thinking in 16 colour mode the pixels are rectangular like 2x1, but if you put two of the same colour on two scanlines, you get like 128x128 pixels effectively, in 16 colours.
LUA is a language used by Pico-8, but also by Roblox. It is a bit like BASIC with the structure of Pascal/C
FUNCTION _INIT()
CLS(0)
END
FUNCTION _UPDATE()
END
FUNCTION _DRAW()
FOR N=0,15 DO
SPR(N,N*8,0)
END
END
LUA looks interesting. Would be nice to have a way (either PC or CPC) to work with it on CPC too.
Locomotive BASIC is a quite good BASIC, although some more modern features like functions and procedures with parameters, blocks of code for structured programming, as well as scoped variables would help. At least "DEF FN" is a beginning.
Assembler is required for many things that needs to be fast. I'm used to the MAXAM assembler as provided also in WinAPE. Again, something like namespaces would be of help here. I know there are other, more modern assemblers that provide more features.
For quite a long time I'm working with C++. The language was developed more or less at the same time the CPC got into appearance. But it has developed from there in several iterations. Modern C++ looks quite different than the older versions. You can see that the language has a longer history: it is far from being monolithic, although there are efforts to clean up the language. I read somewhere that the memory model of C++ and its classes is not well suited for the Z80. The index registers IX and IY would help to build up something, but it will be slower than something optimized for the Z80.
I also I got to know Swift. This is more modern and more monolithic than C++. Its syntax can be surprisingly compact, still providing full type checking.
Finally many compromises would be necessary. The memory is limited. Long source codes with neat formatting as well as descriptive identifiers and comments are maybe too modern for the CPC. On the other hand: Who knows what can be done if the online compression of source code as used by Locomotive BASIC by tokenization is extended to more modern data structures?
I'll have a look at Swift...
For me it would be Locomotive BASIC but without line numbers and supporting labels, like a mix of BASIC an assembler. It would be relatively easy to do a cross compiler that converts that into standard Locomotive BASIC with line numbers.
Example:
MODE 1:BORDER 0
GOSUB _print_menu
END
_print_menu
LOCATE 1,1:PRINT "MENU"
RETURN
Yeah, and whole screen editor with scroll listing by roll, and instead copy cursor highlight text to erase/copy/paste, and RSX for sprites/scroll/menus, and build in compiler. Oh yeah! Best Basic ever. :)
Quote from: ZorrO on 09:03, 06 October 24Yeah, and whole screen editor with scroll listing by roll, and instead copy cursor highlight text to erase/copy/paste, and RSX for sprites/scroll/menus, and build in compiler. Oh yeah! Best Basic ever. :)
So, for editing: Basically a good text editor with Copy and Paste (we got that at least).
Quote from: lightforce6128 on 01:57, 05 October 24Locomotive BASIC is a quite good BASIC, although some more modern features like functions and procedures with parameters, blocks of code for structured programming, as well as scoped variables would help. At least "DEF FN" is a beginning.
Assembler is required for many things that needs to be fast. I'm used to the MAXAM assembler as provided also in WinAPE. Again, something like namespaces would be of help here. I know there are other, more modern assemblers that provide more features.
I would like a
Locomotive BASIC like BBCBasic, that is, including fuctions and procedures as you say, but also chunk of assembler code.
https://oldpatientsea.github.io/agon-bbc-basic-manual/0.1/bbc3.html
I would like Turbo Pascal...
xesrjb
Quote from: xesrjb on 03:59, 07 October 24I would like Turbo Pascal...
already exist in CP/M ;)
I'd like something like Scratch to get someone younger interested in programming on the CPC.
Bryce.
Hello,
I don't really care about which specific language, but I think there are not so many which can run well given the CPC limitations.
Regarding compiled languages, we have a decent choice of these already with BCPL, C, Pascal, and Modula-2. They are stretching the limits of what you can do on a CPC already. I don't expect anything better will come out. It's possible to use a RAM disk to speed up build time, and also write code with "overlays" that could be put into memory banks (so you can have apps larger than the base 64K of memory).
Even for cross-compiled ones, there are things like Cowgol or Turbo Rascal, so no need to spend more time in that area (for me at least).
On the interpreted/scripting languages side, it is not as nice. Basically the choices are BASIC (either the Locomotive one or a few others available for CP/M), and maybe FORTH, LISP or MOUSE. None of these are really compatible with modern structured programming. I think Python, Lua, and other similar ones are all too big (in their current implementations) to be practical.
That's why I'm looking into Smalltalk now. As a scripting language running in a virtual machine, it can make the memory banking largely invisible and handle it for you. So you can write your complicated algorithm and not worry about where to locate the data. Of course, as a downside of that, it will be rather slow (we'll see if it's just a bit slow, or unbearably slow).
A few other things to consider:
Projects like Java Grinder, which is a converter from JVM (Java Virtual Machine) bytecode to assembler. You could then use Java (or Kotlin or Scala or other languages using tje JVM) and convert to assembler. I don't know how efficient it is. Definitely for cross-compilation only.
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_ :)
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.
Quiche - https://github.com/Bread80/Quiche
It's my own Pascal variant. The syntax is mostly a more modern superset of standard Pascal which removes the 'friction' and rigidity of 70s style languages and compilers.
Still a work in progress. It's currently a cross-compiler running under Windows. I indent to create a command line version with Free Pascal that can run almost anywhere. It's currently generating Z80 assembler compatible with RASM.
I intend to make it self-compilable which should enable an on-device compiler to be created (albeit with a reduced syntax and less good code generation). There's an examples folder which should give a rough idea of the language.
@Bread80 , very cool other GitHub stuff as well!
Some Functional Programming language. And/Or:
* nim (https://nim-lang.org/)
* racket (https://racket-lang.org/)
* SML (https://www.smlnj.org/sml.html)
These are very promising (eh, cross-compilation):
- Millfork (https://karols.github.io/millfork/)
- Wiz (https://github.com/wiz-lang/wiz)
Although I haven't done anything substantial with them. I have too much code already in ASM and C (with SDCC), and it pays off staying with the things I know best.
Quote from: Optimus on 10:32, 10 October 24Hard 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. ;) :)
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
Quote from: McArti0 on 10:32, 04 October 24Visual Basic.
Want to finish it? It can current parse itself to retarded.
https://github.com/PrimalNinja/vbcc
Quote from: GUNHED on 13:52, 08 October 24Well, 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?
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?
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.)
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.
Quote from: eto on 13:13, 24 October 24I 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 ;)
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.
Quote from: eto on 13:13, 24 October 24I 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.
Quote from: GUNHED on 13:23, 24 October 24Nobody 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
Quote from: Anthony Flack on 00:47, 25 October 24I 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
An open system with expandability is a very good point! :)