Idea for x-platform language

[Wall_Axe]

How about a language which has all the nice features of assembly like pointers, and flexibility but is cross platform between c64 and spectrum.
So speed would obviously suffer. The c64 has fewer registers so they would not be used much on the spectrum either.

So basically,it's assembly, but simpler and more generic.
Common functions would have to be done in assembly by the language author, like drawing things input etc.

The functions would be
Dereference pointer. (Puts a sixteen bit number from ram into a register or different ram area)
Add a byte to a sixteen bit number.
Load variable ( loads a byte from ram to THE (not A) register)
Save variable from THE register to RAM.
The obvious things like INC ,ADD,SUB
Loop n number of times.
Then a few IF statements could be created from CP.

Would it be totally pointless?

Data would be created from defb and defw statements like assembly.

[AndyC]

It would pretty much be C, I'm not sure you'd gain much more by inventing an entirely new language. It's certainly a way of writing cross platform code, but 8-bit machines are so limited you tend to be aiming at the lowest common denominator and the results are never going to be like code tailored to the machines.

[ParadigmShifter]

Yeah, it's C or if you are feeling bold something like Forth (which is stack based rather than register based). Both of those were invented in the 60s or 70s I think?

PROBABLY UNWANTED ADVICE INCOMING:

Really you need to stop flip-flopping and thinking of new ideas/looking for new languages/frameworks to implement games and get down to doing something.

You originally wanted to do a simple text game with 3 rooms, then you complained about things you tried using too much memory (fair enough maybe) or overwriting code and data (probably a user error rather than a framework error?). 3 rooms is not a lot of memory

It's not hard to write a 3 room text game in any framework, even assembly (which you are investigating and seem to be doing ok - so kudos for that). Even in Basic! (But Sinclair basic does suck though)

Time to knuckle down and implement something simple rather than wanting the moon on a stick straight away?

All journeys begin with the first steps...

People here can help you with things you get stuck on (I've posted lots of my code already and can post more) but you need to show your working out as well

[AndyC]

It would be more like checking flags in z80 and c64 but in a unified way.

The problem with that is it very rapidly becomes complicated trying to hide all the nuance in the difference between Z80 and 6502. It's a lot easier when you're doing C style X<Y type comparisons and just generating semantically equivalent code (which is why C does that in the first place - it was explicitly supposed to be "portable assembly language")

[ParadigmShifter]

Anyway sorry for being a bit harsh I think you probably need some motivation to start doing something concrete though.

You remind me of someone making an exam revision timetable - making sure you have planned everything out, shuffling the revision time schedules, colouring in the timetable with felt tip pens etc., looking for better ways to produce a revision timetable - rather than, you know, doing any revision

[Wall_Axe]

Oh believe me,I didn't move on from one language until it had failed in an unrecoverable way. Maybe I didn't configure things correctly sometimes. But asm just is the choice, I think if I build up lots of functions it will be fast development then.
Yeah I am planning on doing the simple move between rooms thing.
My attempts to remake the game often ended around there.
I have the generic code for the menus in C (and three other languages) so I can just translate it over.

I haven't investigated c64 coding so I would need to know the similarities and differences in those basic functions such as the flags set after CP

[ParadigmShifter]

I wouldn't go near 6502 assembly if you are only just learning Z80 - which as a processor is much more powerful and programmer-friendly.

6502 only has 3 (8 bit!) registers but has many more addressing modes (which makes it more complicated to understand in some ways).

You can't do any 16 bit operations at all on a 6502.

If you want cross platform definitely stick to C.

[ketmar]

tbh, C is not a good idea too: it has to support recursion, and it makes the code way more complicated that it needs to be. PL/M is way better, i believe. that's why i started to write a compiler for it. sadly, i don't have enough time to finish it yet, but i will eventually do it.

also, Forth can be made quite portable too.

[ParadigmShifter]

Well a good compiler might be able to detect if a function (especially if it is in a single source file) can be called recursively but I can't comment on z88dk since I haven't used it. I think there is also a way to pass arguments in registers (usually __fastcall or something like that?) if it can. Obviously you can complicate stuff by having function a() call function b() which then calls function a() and the like so it's not trivial to optimise that. And taking the address of a function can make it think a function might be called recursively too.

I mentioned Forth above yeah that's simple and portable but I don't like the syntax myself I know you are a Forth fan

I usually write pseudocode in C for complicated stuff (maybe even test it on a PC - probably use C# then though) and then convert it to ASM. (So I tend to use cute variable names like hl, de, bc, a, b, c, d, e, h, l etc.)

EDIT: Anyway my point was OP shouldn't be thinking up schemes to invent stuff that already exists when they should be writing something simple using what they already have.

[catmeows]

How about a language which has all the nice features of assembly like pointers, and flexibility but is cross platform between c64 and spectrum.

Well, there is Action! for Atari, it is well optimized for 8 bit cpu (and yes, it is faster than C in general because it avoided stack frames).

Quote reduced by admin

[ketmar]

Well a good compiler might be able to detect if a function (especially if it is in a single source file) can be called recursively

…or you can simply mark recursive functions with a special flag. ;-) that's basically what PL/M does.

i believe people want too much from compilers. 100% reliable detection is impossible, because it is the halting problem. and 80% gives programmer a false sense of security. so the easiest way is just don't do it, and let the programmer take care of proper marks.

I mentioned Forth above yeah that's simple and portable but I don't like the syntax myself ;) I know you are a Forth fan :)

Forth actually doesn't have any syntax. ;-) it's quite easy to write a translator from infix to postfix code, if you'd like to. but nobody does that due to the same reasons people gave up on "infix lisps": it is easier to write Forth code in "natural" way. still, when i don't feel like it's time to write a good Forth code, i am actively using locals, for example. it usually means that my code smells, but meh… for most people any Forth code looks like random gibberish anyway. ;-)

p.s.: current UrAsm/Forth doesn't even have conditionals and loops, for example, they are compiled from Forth source code on bootstrap. and i am slowly working on moving more words from kernel to Forth bootstrap source.

[Timmy]

How about using French for that?

You can now use "mil neuf cent quatre-vingt-trois" instead of "1983", and it can describe everything you want to describe.

It's more useful than a programming language to a non-programmer anyway. Because it's more important for them to be able to express everything than actually do any coding in it.

[ParadigmShifter]

French is a bit modern, all good languages like INTERCAL use Roman numerals as output

https://en.wikipedia.org/wiki/INTERCAL

Also no GOTO (only COME FROM) so that's good. And you have to make sure your program is sufficiently polite (but not too polite IIRC) or it won't compile.

[Timmy]

Well a good compiler might be able to detect if a function (especially if it is in a single source file) can be called recursively but I can't comment on z88dk since I haven't used it.

To be honest, it really doesn't matter whether you use C or assembly to finish your game. For me, it only matters if you finished your game or not.

Assembly is very important if you are writing a sprite engine, for example. But most of the stuff I write is gameplay, and for me, that's usually in (z88dk) C because it's just faster for me to finish.

But C alone is not an substitute for a fast sprite engine, and luckily I have several engines to choose from. The one I'm currently using (repurposing the one from Future Looter) does about 6 sprites in 1 frame, but it's probably enough for what I want to do. The problem is that it's such an old engine I forgot how it worked.

Quoting reduced by admin

[utz]

mumble muble Turbo Rascal muble mumble...

[Wall_Axe]

mumble muble Turbo Rascal muble mumble...

Yeah I took a look at that,its mostly c64 focussed.