BigEd saw my post on Hackaday and asked that I post here as well. So here it is!





I have been busy working on a playground for my 6502 based game system, Dodo. The playground is a hosted IDE and Simulator that makes it easy to develop and share games based on my system and game API. The game API is fully documented in the playground. The only caveat is that this will not work on mobile for now. I need to develop a touch interface for the game buttons.

Here is a my game 0xDEADBEEF https://play.dodolabs.io/?code=f5aa0e9

The games are written in C and compiled using cc65. I am running cc65 in the cloud.

Here is the hackaday post with some more detail: https://hackaday.io/project/9325-dodo-6 ... playground

Right now I am working on a Chrome Extension that will talk to the playground and allow for flashing games over USB/Serial straight to the device. This should even work on a Chromebook!

After the flashing feature, I need to give more love to the hardware. However, I do have plans for more playground functionality. I want to add a touch interface, a built in sprite pixel editor, and perhaps even some sort of music creator!

Thanks for looking!

_________________
My 6502 Game System: https://hackaday.io/project/9325-dodo-6502-homebrew-game-system

Thanks for posting! I do like the idea of offering a browser-based simulator, because it's so accessible and tweakable compared to hardware. (I wonder if in some ways we'd do better if we started with a simulator.) I also like the idea of writing the simulator in a "good" language and transpiling to the browser's JavaScript - productivity is everything! It also means you get a high performance command line simulator almost for free!

And I like the idea of offering the simulator with a cloud-based compiler so you can iterate and test your code easily. That must have taken a bit of figuring out!

Where can we look for good info on the game-relevant API you offer in the ROM? That seems like another good idea! (Edit: Ah, I see it's in the right sidebar of the simulator - scroll down!)

Let me just pull out that API very briefly:

Cool, glad you found it! If you want to see the source for how the API is implemented it is here:

https://github.com/peternoyes/dodo/tree ... src/common

Note that this is my first ever project in Assembly and I made almost no use of Macros. I have a bunch to learn in that area! I want to do some cleanup now that I have a bit more experience.

_________________
My 6502 Game System: https://hackaday.io/project/9325-dodo-6502-homebrew-game-system

One more thought @Ed

There is a ton of room available in my ROM, I am using 32KB. I am sure I could fit a version of BASIC in there. If that is done and some bindings were created for the game API, then it would be possible to be able to write games in BASIC. I think the performance would be reasonable because the heavy lifting is all done by the API for the most part. If that were done, then the playground could have a dropdown where you could switch between languages. It would also be fairly straightforward to let Assembly be an option for the playground. I would just need to think about the best way to have people call the API. For now it is using the cc65 calling convention which is a bit annoying for trying to hand develop Assembly and then call functions that take 5 parameters.

The way I designed the storage of the game on the cartridge I have left 100 bytes reserved in the beginning. I could use this for specifying a version or a language. This way, the hardware could also support BASIC.

_________________
My 6502 Game System: https://hackaday.io/project/9325-dodo-6502-homebrew-game-system

That's an interesting idea! As you may know, BBC Basic offered commands like MOVE, PLOT, DRAW, ENVELOPE and SOUND, and INKEY. But nothing for sprites. All of the above are shims which call the corresponding OS routine, which has a stable ABI. For anything complex, the parameters are passed in (and out) in a parameter block in memory, pointed to by Y and X.

Cool! I will take a look at it.

_________________
My 6502 Game System: https://hackaday.io/project/9325-dodo-6502-homebrew-game-system

Hi Peter, BigEd

BigEd gets about - he has been looking at my articles on hackaday on the self-designed programming language (derived from BASIC) that I have created, and saw some of my ideas for commands to support game programming. He then linked me back to here - very interesting work Peter and love the cloud based approach to hosting the IDE and simulator.

I am assuming that you have some hardware abstraction layer so that your application software will work on the real and simulated hardware and this is the API you refer to? I'm guess from there that you have libraries in the simulator and real hardware which conform to the API to enable the portability?

My approach is somewhat less sophisticated in one sense (although I have built an entire interpreted language from scratch in 65c02 assembly - that took a lot of effort!). I commands which reflect the underlying hardware quite closely. I have a TMS9918 which supports hardware sprites, and an AY-3-8910 which provide 3 channel (+1 noise channel) sound which can be modified by certain envelope settings.

So my BASIC commands for supporting hardware sprites include:

Sound commands include:

Input commands include:

I also have various commands to clear the screen, plot a string at any coordinate and change screen modes (I support 40 column monochrome and 32 column multicolour modes).

I have no bitmap graphics support hence no LINE or DRAW commands, although I do have vpoke and vpeek to enable direct writing to the video RAM (which is not shared by the 6502).

So two different approaches - the API approach you have taken is the modern approach of course, whereas mine is a lot like many home computers of the 80s in which the OS was intimately tied to the specific hardware set up. We know which approach prevailed!

Cheers, Dolo

Hi Dolo,

There is a HAL in the sense that the API is in C and there could easily be an implementation on other hardware. The online simulator is actually simulating the true hardware fairly accurately. I do this because performance is so critical that I want to be able to show what the cycle count is for each iteration of the game loop.

I like your API for sprites and especially for sound. I need to make my sound API more user friendly, for now it is pretty cryptic and the values passed in are tightly coupled to how the 6522 works.

Cheers!

-Peter

_________________
My 6502 Game System: https://hackaday.io/project/9325-dodo-6502-homebrew-game-system

As a follow up I recently updated the playground to allow writing directly in assembly language.

Here is a quick sample

https://play.dodolabs.io/?code=51447f62

_________________
My 6502 Game System: https://hackaday.io/project/9325-dodo-6502-homebrew-game-system

Really nice Peter - I like that you have a homebrew computer which other people can program for using the simulator. I am considering a simulator as a follow on project to my homebrew creation - but I think it will need to run as a native application like MAME does due to needing to simulate the behaviour of the TMS9918 video chip and AY-3-8910 sound chip. So until then only I can build programs for my machine..

Cheers, Dolo
https://hackaday.io/project/5789-6502-homebrew-computer