Wally 2109

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

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

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

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.

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

spudge example with generated MADS asm and matching xex sieve-of-Eratosthenes-array-opt-2018-01-11.zip

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))

Thanks for the feedback. It's hard to tune the difficulty for a game like this. Make a minor change and it's too easy, change in the other direction it's too hard. I tuned the difficulties so that I (someone who has been playing video games since Pong) could play easy mode as long as I concentrated - it resets to slow at level 255 - although I didn't test for that long Hard level is still possible but now beyond my skill level (at 52 my reactions are slower than during my Defender years). My best 60Hz hard level score is about 26.

denial '77 - the first product of my retro programming project is (almost?) done. denial77NTSC.bin denial77PAL.bin denial77PAL60.bin The game is loosely modelled on Space Zap, an arcade game from 1980. setup Left player difficulty sets game difficulty Right player difficulty sets starting level (1 or 14) Reset or joystick button to start. gameplay You're protecting the base in the centre, move the joystick in the direction you want to fire. The base heats up when you fire, changing colour and expanding. The base firing rate slows as the base heats up. The base also heats up when hit. It's game over if the base hit when it is overheated. The level number is the only scoring mechanism. scores If anyone tries it out I would be interested to know what level you attain - and whether it was using an emulator or real hardware, easy or hard, 60Hz or 50Hz. waffle This was always intended to be my warm-up game as I returned to Atari 2600 programming after a 14 year hiatus (the unfinished Laseresal). It is lacking some polish generally found in modern 2600 games (separate title screen, option screen, more detailed scoring, game over screen, multiple chances etc.). Maybe it's more like a quick and dirty cash-in game from 1978 Part of me wants to go back and make it "the best it can be" and fix some of the "naive coding choices", but another part of me says I have other games I want to do on the 2600 and the Atari 8 bit (and other platforms) so this is probably it for this game.