Anyone interested in converting AGD to the Dragon/CoCo?

[pser1]

Thank you for having a look.....
Hopefully you will finish your projects soon to join me ......
I'll start with tweaking my Z80-to-6502 conversion program to make it a Z80-to-6809 conversion program as a start.
It would be nice if you want to watch this topic now and then because I will have questions ......
Can you recomment a good assembler?
I also need a good emulator with debugging options, Xroar maybe?
Thanks.
Greetings
Kees

Of course I will keep an eye on that thread, it's very interesting!
Normally I use ASM6809 (by Ciaran Anscomb) to compile programs, together with a customization he did on GDB (debugger) on a
DOS old-style window. These are the tools I used for The Hobbit on the 6809 area.
In case I need to 'count cycles' to synchronize or reduce timing, then I use LWASM (part of the LWTools (by William Astle)
but due to different behavior on a few options you need to make some changes to switch from one to the other, but it's easy to do.
But some people would prefer MAME/MESS for debugging purposes

cheers
pere

[oss003]

Something to show your Spanish friends ....
Some previews of working AGD games:

Nixy: https://www.youtube.com/watch?v=AL6epGPeaCU
Ooze: https://www.youtube.com/watch?v=_Wn9pcoXxjE
Terrapins: https://www.youtube.com/watch?v=Vh4ykI0H0iE&t=24s
Rovr: https://www.youtube.com/watch?v=QpIsNWkf1xQ
Mike the Guitar: https://www.youtube.com/watch?v=nauAB8370V0

And Dodgy in colour mode: https://www.youtube.com/watch?v=HTGFHAPp5eU

Greetings
Kees

[jmk]

I had a quick look at the Z80 code, using "apulia" (Apulija-13). Excluding data, there's 5,805 bytes of engine code and 2,378 bytes of game-generated code. Total output: ~32K, which appears to exclude the screen memory, some upper memory buffers and the ROM call to read the keys. Clearly, this game wouldn't fit into a Dragon 32!

TestSpr is much smaller and outputs a total of 9,202 bytes. The engine size is the same, but the game-generated code is only 345 bytes (it's just a small demo).

So, there's (nearly) 6K of core code to be converted, as well as requiring some method of converting the game-generated code.

Kees, there's also a good game called "Double Bubble", which doesn't appear in your directory listing.

[oss003]

I had a quick look at the Z80 code, using "apulia" (Apulija-13). Excluding data, there's 5,805 bytes of engine code and 2,378 bytes of game-generated code. Total output: ~32K, which appears to exclude the screen memory, some upper memory buffers and the ROM call to read the keys.

The sprites take a lot of space because for every sprite, 4 images are stored which are all preshifted images of the previous image by 2 pixels.

Clearly, this game wouldn't fit into a Dragon 32!

On the Atom I have 34KB free and I must say that 90% of the games fit.
You're right, some games are to big to fit in 32KB because the ZX Spectrum has 48KB but it's always possible to remove some screens or do a conditional assembly like I do for the Atom.
If the menu isn't used, don't assemble the menu routines and this also applies for scrolling and shooting.
This way you can save some space.

All the TESTxxx programs are demo's I wrote for checking specific commands.

So, there's (nearly) 6K of core code to be converted, as well as requiring some method of converting the game-generated code.

The engine core of 6K has to be converted to 6809 code once because the same engine is used for all games.
The game-generated code is created by the AGD compiler, A C program which checks the ASCII AGD file and converts every AGD command to equivalent 6809 assembler code.
This C program is working but only the 6809 equivalent code has to be added.

Kees, there's also a good game called "Double Bubble", which doesn't appear in your directory listing.

There is a list of 150 AGD games: https://spectrumcomputing.co.uk/index.p ... 6&id=20176 but Double Bubble is on my list .......

Greetings
Kees

[jmk]

The sprites take a lot of space because for every sprite, 4 images are stored which are all preshifted images of the previous image by 2 pixels.

I see. That might be optimisable or, maybe, use 128x96 4 colour mode to save a few K.

On the Atom I have 34KB free and I must say that 90% of the games fit.
You're right, some games are to big to fit in 32KB because the ZX Spectrum has 48KB but it's always possible to remove some screens or do a conditional assembly like I do for the Atom.
If the menu isn't used, don't assemble the menu routines and this also applies for scrolling and shooting.
This way you can save some space.

I've made a (very) preliminary assessment and I think that the Dragon 32 would have about 17K free for the game (assuming that the size of the 6809 is roughly the same size as the Z80). A 64K model would have, maybe, 49K free! That figure depends on my assumptions being correct, though...

There is a list of 150 AGD games: https://spectrumcomputing.co.uk/index.p ... 6&id=20176 but Double Bubble is on my list .......

Ah, yes, it's on that list, but I couldn't find it in AtomSuite. (I've added it to my directory now).

Here's a question. How many frames per second does it run at? A number of the Atom builds run slower than the Spectrum ones. Does it just depend how many sprites are on screen and how long it takes to render them?

[oss003]

I've made a (very) preliminary assessment and I think that the Dragon 32 would have about 17K free for the game (assuming that the size of the 6809 is roughly the same size as the Z80). A 64K model would have, maybe, 49K free! That figure depends on my assumptions being correct, though...

I guessed that there is about 24KB free which is to tight but 49 KB for a Dragon64, should be enough.
I'm only using 2 systemcalls in the Atom verrsion but they can be rewritten to free the OS.

Here's a question. How many frames per second does it run at? A number of the Atom builds run slower than the Spectrum ones. Does it just depend how many sprites are on screen and how long it takes to render them?

Theoretically 25 frames per second for a 1MHz Atom but that depends on the complexity of the sprite event code and the number of sprites on the screen.
You can define code for every sprite type so if there are 3 sprites on the screen, 3 sprite event routines are called.
The game is one big loop and for a lot of events, a subroutine is called like initsprite, player, spritetype1-8, mainloop1, etc
So in one gameloop, every event is minimal called once.
I can switch the Atom to 2 MHz to get a better framerate but not all Atoms can switch to 2 MHz.
However I still must optimize the sprite routine to gain some speed.

I think the framerate would be better for the Dragon because you can use 16 bit registers which the 6502 doesn't have.
My Flappybird conversion uses the same graphics as the Flagonbird written by Bosco but is slower because of missing 16 bit registers.
https://www.youtube.com/watch?v=pfNotQIRrDw

Greetings
Kees

[oss003]

To make it easy to design an AGD game, Jonathan Cauldwell has written a Multi-Platform Arcade Game Designer 0.6 (Windows 64-bit).
It uses the same tools as included in my suites but has a lot of features:

- Block, object, sprite,screen, map, font and palette editors
- Import option to read data from a 48KB AGD game snapshot
- Selection for machine output: Spectrum, Timex CPC or Acorn Atom
- Automatic graphic conversion for the different machines
- Sprite templates

You can develop a new AGD game with this program.
The download is available at: http://www.spanglefish.com/egghead/inde ... eid=397755

Greetings
Kees

[oss003]

Jonathan just released a new editorless version of AGD.

http://arcadegamedesigner.proboards.com ... -version-7

Greetings
Kees

[oss003]

Hi pere,

I saw your conversion on the Spanish site ....... nice job .....
Did you rewrite a part of the code or do you have a conversion program to convert Z80 to 6809 assembler?

Did you also think about the memory map because I think the games are to big to fit in a Dragon32?

With the Atom conversion, I started with the game loop because that's the base of the game.
First put RTS in every routine called from the game loop.
Then analyze, in calling order, every routine and convert it.

Did you have a look at the Atom engine because all graphic routines are written for a 6847 in mono 256x192 mode.

Greetings
Kees

[oss003]

Hi pere,

if you have any questions about the Acorn Atom, please post them here so that I can see them.

You can find a disassembly of the #Fxxx rom here: http://www.acornatom.nl/atom_handleidin ... m/f000.txt

$FE71 reads a key from the keyboard matrix from bottom left upwards and then the next column upwards, if nothing is pressed then 255 is returned.
So SPACE returns 0, RETURN returns 13, etc.

Greetings
Kees