spudge - a new Atari 8 bit programming language

[Wally 2109]

Is there any interest in using a new programming language for Atari 8 bit programming?

Or is this destined to be a language with only one user

Last year I returned to write some new code for the Atari (for a bit of nostalgic fun after 30+ years away). It was great relearning how this old machine works and diving back into 6502 coding.

After writing some test programs and thinking about what else I wanted to do I had a ‘to do’ list with dozens of entries - from arcade games to little apps and demos. As much as I enjoy working in assembler I wanted a higher level language for the parts of the program which are not time critical.

After looking at the available options I didn’t find one which felt like a good fit, so I decided to create something new - I’ve always wanted to make a compiler…

I’ve been using a ‘placeholder’ name for the language for a few months until a better one came to mind, but, well, that didn’t happen so it’s still spudge

This has been a side project for a few months and I feel it is about 70% done (except for the libraries which may never be finished), hopefully it will be ‘finished’ in another few months (somewhat dependent on other distractions: holidays, gaming, wine, beer… and maintaining my level of interest)

It’s implemented in Perl 5 - creating an asm file which is assembled with MADS (the Mad Assembler) into an xex file, so it should run anywhere a recent version of perl 5 and MADS can be run.

spudge isn’t directly modelled on another language but it is probably most like Action!

It makes similar compromises to Action! - no floating point, ‘static’ subroutine local variables (including parameters), poor support for recursion...

The language is quite different to Action! but supporting much the same functionality with a few extra operators, and a more free form syntax, and, hopefully, often better performance.

What has already been done...

• variables (local + global): byte, uint, int + pointers to these types, volatile (for memory mapped hardware) and const modifiers, alignment specification, address specification
  
• string literals
  
• numeric literals: decimal, hex or binary
  
• arrays
  
• for, while and if statements
  
• procedures, functions
  
• asm blocks (using standard asm instruction mnemonics)
  
• unary operators: -, +, !, not
  
• operators: =, +, |, &, ~, xor, or, and, lsh, <<, rsh, >>
  
• assignment / update operators: =, +=, -=, &=, |=, <<=, >>=, lsh=, rsh=, &=, |=, ~=, and=, xor=, or=
  
• comparison (signed) operators: ==, <>, !=, <=, >=, >, <
  
• a few library calls
  
• resource level ‘linking’ - only subroutines and variables which are actually referenced are included in the output
  

What is still to be done...

• multiplication, division
  
• signed comparisons
  
• signed / unsigned / pointer expression tracking
  
• elsif, else extensions to if
  
• subroutines taking a variable number of arguments; esp. printf
  
• more: validation, error checking, optimisations
  
• user defined types
  
• direct access to high / low bytes of 16 bit variables
  
• lots of libraries
  

Is there anyone out there interested in: testing it, trying to use it in its current incomplete state?

Are there any 6502 experts wanting to suggest improvements to the generated code, provide library code (players, sound, graphics, CIO, etc.), code for multiplication, division, signed comparisons...?

Eventually I expect to get around to doing all of these but am happy to start with / integrate other code (but be warned I don’t think it will lead to fame or riches (and for one reason or another I might no be able to accept a particular bit of code))

[Wally 2109]

spudge example with generated MADS asm and matching xex

sieve-of-Eratosthenes-array-opt-2018-01-11.zip

Edited January 11, 2018 by Wally 2109

[pirx]

looks like you could reuse some libs from mad pascal

[Wally 2109]

looks like you could reuse some libs from mad pascal

Thanks for the suggestion. I will look into this when I get closer to version 1

[explorer]

Support for hardware?

 

Today, the new programmers want all languages have SPRITE command, like the olds STOS/AMOS Basic languages for ST/AMIGA.

 

Or framework or game engines like Godot, GDevelopp o Game Maker.

 

Regards from another Perl programmer.

Edited January 13, 2018 by explorer

[Wally 2109]

Support for hardware?

 

Today, the new programmers want all languages have SPRITE command, like the olds STOS/AMOS Basic languages for ST/AMIGA.

 

Or framework or game engines like Godot, GDevelopp o Game Maker.

 

Regards from another Perl programmer.

I plan to implement a simple player/missile library but I hadn’t really thought about implementing an ST style software sprite library, although looking at my ideas list for games I am thinking about doing it might be useful for a couple of them

I’ve certainly been planning some games requiring lots of concurrent sprites (several dozen) but I expect each of these screens will need custom designed PM + DLI combinations with some very tight timing which would be difficult to generalise into a sprite library.

Are there any good Atari sprite libraries (xor or otherwise) out there which I might able to use.

[tebe]

mads\examples\sprites\

[mgr_inz_rafal]

Great stuff, Wally 2109,

As far as I know there is at least one Action! programmer out there, so Spudge might turn seductive enough for him to switch Good luck with the project. I myself also like to write compiler from time to time, but it's always hard for me to make it to the end.

 

Do you plan to release the Spudge source code? I love to read stuff like that.

[Wally 2109]

Great stuff, Wally 2109,

As far as I know there is at least one Action! programmer out there, so Spudge might turn seductive enough for him to switch Good luck with the project. I myself also like to write compiler from time to time, but it's always hard for me to make it to the end.

 

Do you plan to release the Spudge source code? I love to read stuff like that.

It was frustrations with working with Action! (some of the syntax, missing logical operators, poor asm integration, expression and subroutine call limitations, and I really prefer cross compiling on the PC) which prompted this effort - hopefully I won’t be the only Action! programmer who finds it palatable.

 

The source code will be provided when it is publicly released (once I get more of the language completed (maybe when it’s all there except variable arguments and user defined types)), a few more libraries and more example spudge code. It’s all implemented in perl, a “scripting” language so exposing the source is the natural state

 

It’s all been hacked together without sufficient planning and forethought so I wouldn’t really recommend looking at the code too closely - maybe just the code it generates

[+slx]

I remember someone either posting here or talking on ANTIC about working on an object-oriented 8-bit language as he had come to like object-oriented code since leaving the Atari decades ago. That would be a novelty.

 

I think an easy to use floating point extension or library would make a new software more approachable.

 

I might be another action programmer although I only wrote a single-use utility recently and never tried a game. What I found a bit frustrating with Action! was the total freedom to shoot your own code with unbounded arrays, etc. Apart from the lack of documentation that might have contributed to it never achieving the status its speed and versatility would have warranted.

 

While I find it fascinating that you develop a new language, I'd be more likely to give it a try if it ran as a cross-compiler allowing higher-than-assembly-level programming for the Atari on a PC/Mac.

 

As my age has exceeded $30 I find it increasingly difficult to remember language syntax I didn't learn in my youth between projects....

[Wally 2109]

I remember someone either posting here or talking on ANTIC about working on an object-oriented 8-bit language as he had come to like object-oriented code since leaving the Atari decades ago. That would be a novelty.

 

I think an easy to use floating point extension or library would make a new software more approachable.

 

I might be another action programmer although I only wrote a single-use utility recently and never tried a game. What I found a bit frustrating with Action! was the total freedom to shoot your own code with unbounded arrays, etc. Apart from the lack of documentation that might have contributed to it never achieving the status its speed and versatility would have warranted.

 

While I find it fascinating that you develop a new language, I'd be more likely to give it a try if it ran as a cross-compiler allowing higher-than-assembly-level programming for the Atari on a PC/Mac.

 

As my age has exceeded $30 I find it increasingly difficult to remember language syntax I didn't learn in my youth between projects....

None of my expected uses will require floating point, so I don't expect I will add a floating point library - someone else is welcome to if desired.

spudge is implemented in such a way as to even disallow usage of the ROM floating point routines as well - its using the floating point zero page locations in its own nefarious manner

 

To some of us the lack of array checking is one of the positive features of Action! as it makes for faster and smaller code.

 

Well at least spudge meets the cross compiler preference

[JoSch]

None of my expected uses will require floating point, so I don't expect I will add a floating point library - someone else is welcome to if desired.

spudge is implemented in such a way as to even disallow usage of the ROM floating point routines as well - its using the floating point zero page locations in its own nefarious manner

 

To some of us the lack of array checking is one of the positive features of Action! as it makes for faster and smaller code.

 

Well at least spudge meets the cross compiler preference

But, you could include Mad Pascal fixed point library.

[tebe]

Mad Pascal -> \base\6502\cpu6502_single.asm

 

IEE754 (32 bit) by David Schmenk

 

https://sourceforge.net/projects/vm02/

http://vm02.cvs.sourceforge.net/viewvc/vm02/vm02/src/

[+slx]

To some of us the lack of array checking is one of the positive features of Action! as it makes for faster and smaller code.

I fully appreciate the speed. I'd just prefer to have an easier way to debug stuff I botched that way. Maybe a cross-debugger

[Wally 2109]

But, you could include Mad Pascal fixed point library.

It (hopefully) will be quite straight forward for others to package new libraries if they want to use them, and I would be happy to add them to the 'canonical' spudge version if they work well and are license compatible (I'm currently tending towards the unspoken license). (this would be limited to using a subroutine level interface)

 

I'm aiming to create a simple, small language. If people want something more sophisticated Mad Pascal looks like a better choice for them