Delta on A8 and all stuff (in case someone is interested in...)

[José Pereira]

Here's the stuff and files will be sent in privat if there is someone who's interested in coding it.

 

-> First load the picture screen that is shown while playing music and/or people press a key to continue the loading process:

 

-> Loading screen with simply the logo (could have the colours blinking while loading like browns then blues then greens then ...) that can have laso the original C64's and the A8's credits underneath:

 

-> After loading:

Credits screen:

Showing weapons/shooting demo like is on C64:

Hi-Scores screen:

In-Game screen(s) where top and bottom grounds are 2charsets and middle enemy's is another one:

 

-> Additional stuff:

PMGs are our ship multicolour mode [PM0+PM1], the two balls shots are P2 and P3 where 2 per line stars are these last ones Missiles (and because the stars must go behind the enemys then we must use Prior 2 ):

The gfxs PFs/charsets are the top letters and those top icons charset_0, Delta logo charset_1, bottom icons charset_3 and each enemy wave in-game is charset_4:

Enemys are most of them just a copy of C64 ones and are a transfer to soft sprite data...

 

 

Now Im still here with the files to send them to anyone/someone that is interested ...

Edited December 18, 2016 by José Pereira

[shoestring]

How difficult is it to implement soft sprites on the Atari ? Maybe we can get some extra performance from the 65816?

 

I don't really understand the hardware limitations of the Atari so maybe someone can comment further but I imagine this process would be a lot of work and a different approach needs to be used.

 

I actually made headway to port Uridium to the L System Taito board which runs on a z80 processor and has some cool features. I have a short demo and I'm currently implementing spirites and the super dreadnoughts ( not in the demo )

 

https://youtu.be/VkTtDLlTnaU

 

I derived the z80 code from disassembling the original game code and turning that disassembly into a usable project that I could re-assemble on the c64, to understand how that code worked. It was a very long and difficult process to create a usable project. The process of porting from 6502 to z80 is also long and arduous. As I have to constantly debug routines side by side, check CPU flags.. Etc.

 

Now the question is, is this possible on an Atari ? Would it be crazy to attempt such a project. In some ways it would be easier ( because of the CPU ) but the hardware is vastly different in regards to the PMG vs sprites approach.

 

An Atari port of Delta would be cool though. But who would take up such a big task ?

Edited December 18, 2016 by shoestring

[mariuszw]

How difficult is it to implement soft sprites on the Atari ? Maybe we can get some extra performance from the 65816?

 

I don't really understand the hardware limitations of the Atari so maybe someone can comment further but I imagine this process would be a lot of work and a different approach needs to be used.

 

I actually made headway to port Uridium to the L System Taito board which runs on a z80 processor and has some cool features. I have a short demo and I'm currently implementing spirites and the super dreadnoughts ( not in the demo )

 

 

I derived the z80 code from disassembling the original game code and turning that disassembly into a usable project that I could re-assemble on the c64, to understand how that code worked. It was a very long and difficult process to create a usable project. The process of porting from 6502 to z80 is also long and arduous. As I have to constantly debug routines side by side, check CPU flags.. Etc.

 

Now the question is, is this possible on an Atari ? Would it be crazy to attempt such a project. In some ways it would be easier ( because of the CPU ) but the hardware is vastly different in regards to the PMG vs sprites approach.

 

An Atari port of Delta would be cool though. But who would take up such a big task ?

 

Software sprites are *somewhat* difficult to write. The big problem is however the performance. Games like Uridium require 50 Hz action and it is almost not possible to achieve if you want to render 8 software sprites applying masks and merging with background on ~1,3MHz 6502 on Atari. 65816 can certainly help, but actually it would be enough to run 6502 at higher speed - just take a look at BBC version of Uridium which does everything in software with reasonable effect, but it has CPU running at 2MHz.

 

Congratulations on making 6502 -> Z80 translation! I actually did the opposite for game like Pentargam (released for Atari, C64 and C+4) and GunFright (in the works). I used semi-automatic tool for debugging which saved me lots of efforts - I written simple emulator with 6502 and Z80 and let them run side by side checking memory accesses (as all data access must have the same values written and read apart from storing pointers in memory). The approach works perfectly. For Gunfright I expanded it with ability to load save state from Spectrum (Z80) version, apply save state to 6502 version and run comparison from there.

 

Can you please share disassembly of C64 Uridium? I'm interested to take a look.

 

Mariusz.

[shoestring]

I'm not sure if I want to continue my Uridium port to the Taito board at this time, that project is more a proof of concept ( that I could take a c64 game and port it to hardware that is completely different ). The biggest issue with the board is that it doesn't have much RAM and Uridium uses a lot of it just for scrolling, I had to use the spare character definition RAM to pull that off without completely wre-writing the code. Although the hardware is more than capable ( foreground / background layers, huge sprite availability ) except sprites on an arcade system are normally 16x16, so I have to combine 4 sprites to make one 24x21 equivalent ( see screenshot ). The two independent layers means stars can be drawn on the background layer and there's no need to shift the stars in the opposite direction to scroll as done on the c64 for the parallax effect.

 

I will share the disassembly of the c64 game in a new thread.

uridium.mp4

Edited December 28, 2016 by shoestring

[Stormtrooper of Death]

Wow Mariusz, Gunfright on Atari 8bit ! I played that game to pieces on the MSX when I was a teen in the 80s.

 

If somebody could also port Jack the Nipper (MSX/Spectrum) to Atari, my 2017 will be a good one.

 

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

[Tezz]

If somebody could also port Jack the Nipper (MSX/Spectrum) to Atari, my 2017 will be a good one.

 

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

I've got Jack the Nipper on my list of possible games. The colour map is quite minimal so the game can be reproduced on the A8 in the same way as Saboteur.

[mariuszw]

Wow Mariusz, Gunfright on Atari 8bit ! I played that game to pieces on the MSX when I was a teen in the 80s.

 

If somebody could also port Jack the Nipper (MSX/Spectrum) to Atari, my 2017 will be a good one.

 

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

 

You may already play Gunfright on Atari using WIP version from here: http://atariage.com/forums/topic/253681-new-game-wip-gunfright/. Final game feature music and sound effects, some colouring to match Spectrum ones and quite a lot optimization to get decent performance.

[mariuszw]

I've got Jack the Nipper on my list of possible games. The colour map is quite minimal so the game can be reproduced on the A8 in the same way as Saboteur.

 

I'll take a look into translating Spectrum Z80 code to 6502 then.

[Tezz]

I'll take a look into translating Spectrum Z80 code to 6502 then.

Ok great, I'll start looking into the game fully too. Let's get this one off the list

Edited December 29, 2016 by Tezz

[_The Doctor__]

If I ever get my BBS's up again, I am making a networked base dedicated completely to TEZZ and his works.... Just sayin'

[+playsoft]

I'm not keen on working on another shooter right now but it's always interesting to see what can be done with playfield graphics. You can get a nice lot of sprites on screen with a PM multiplexer but you are limited horizontally by the amount of flicker.

 

Looking at the game it seems that when the playfield graphics appear at the top and bottom that the sprites do not move into them. This means you could use a bitmap mode which I think gives better performance than a character mode here.

 

Implementing C64 sprites in software will require a compromise of some sort. In the attached tests, modeE7 runs at full frame rate under PAL with 74 scan lines spare but this will not be enough time to do everything else that Delta does (and NTSC is out of cycles already).

 

The following tests use the number of scan lines to give a crude indication of how much processing time is left in the worst case (all images visible, largest sized frame spanning 4 screen columns).

 

modeE7no = ANTIC E, 7 sprites, no PM DMA

PAL: 248 - 160 = 88 scan lines
NTSC: 248 - 236 = 12 scan lines

modeE7 = ANTIC E, 7 sprites, single line PM DMA

PAL: 248 - 174 = 74 scan lines spare
NTSC: 248 - 248 = 0 scan lines ==== slowdown

modeE7c4 = ANTIC E, 7 sprites, single line PM DMA, 4-byte column draw

PAL: 248 - 160 = 88 scan lines spare
NTSC: 248 - 240 = 8 scan lines spare

...but xex size increases by +12K and it's no longer a multi-purpose draw routine

modeD7 = ANTIC D, 7 sprites, single line PM DMA

PAL: 248 - 42 = 206 scan lines
NTSC: 248 - 108 = 140 scan lines

modeD14 = ANTIC D, 14 sprites, single line PM DMA

PAL: 248 - 177 = 71 scan lines
NTSC: 248 - 240 = 8 scan lines ==== slowdown

modeE7h = ANTIC E, 7 sprites, single line PM DMA, half frame rate

PAL: as modeE7 (74) + 312 = 386 scan lines
NTSC: as modeE7 (0) + 262 = 262 scan lines

modeE14h = ANTIC E, 14 sprites, single line PM DMA, half frame rate

PAL: 248 - 84 = 164 scan lines
NTSC: 248 - 249 = -1 scan lines ==== slowdown

modeD24h = ANTIC D, 24 sprites, single line PM DMA, half frame rate

PAL: 248 - 22 = 226 scan lines spare
NTSC: 248 - 153 = 95 scan lines spare

 

I'd probably opt for ANTIC D at half frame rate myself. It may not look as good (although designs done for this mode will improve their appearance) or as smooth but it is more fun to play around with more sprites.

xexs.zip

sources.zip

[popmilo]

Implementing C64 sprites in software will require a compromise of some sort.

 

I'd probably opt for ANTIC D at half frame rate myself. It may not look as good (although designs done for this mode will improve their appearance) or as smooth but it is more fun to play around with more sprites.

More sprites are almost always better

 

Nice routines ! Looks really fast. 24 one is impressive !

Are you doing "ORA" when putting byte on screen or are you using masking of some sort (maybe automask ?). When sprites overlap I don't see any eor-artifacts or something like that.

 

My favorite is Char mode. As you said, lack of colors per line is drastic... My thoughts are that charmode 5th color is such a big plus that any complexity is worth it. Plus erasing sprites is much quicker than in bitmap modes.

 

Check it out:

8 sprites sized 12x24 with full masking running at 25fps:

 

14 sprites sized 8x16 with full masking running also at 25fps:

 

All done using so called interleaved character screen. 4 charsets used for each buffer (two buffers used now), alternating each 4 rows. That way you get much more free characters to use for background, bullets etc. Any sprite can go anywhere, sprites are redrawn each cycle independent of background changes.

 

Downloads:

char_sprites 2x2.xex

char_sprites 3x3.xex

ps. With shooter games that have black, empty space as background shortcuts can be taken to make it even faster.

pps. 3x3 xex file is with 7 sprites because that Turrican track takes sooo many cpu time that it took 3 frames to draw 8 of them so I reduced it a bit.

[kiwilove]

Something to consider is to allow for as much animation as possible - for those who wish to do so - in their projects.

There are those who are quite happy for their game to look authentic - as if it was from the 80s' - and then there are those who want to add whatever enhancements that are possible now - since this is the year 2017 - that does run on the original hardware - still.

 

Harvey

[+playsoft]

More sprites are almost always better

 

Nice routines ! Looks really fast. 24 one is impressive !

Are you doing "ORA" when putting byte on screen or are you using masking of some sort (maybe automask ?). When sprites overlap I don't see any eor-artifacts or something like that.

 

My favorite is Char mode. As you said, lack of colors per line is drastic... My thoughts are that charmode 5th color is such a big plus that any complexity is worth it. Plus erasing sprites is much quicker than in bitmap modes.

 

Check it out:

8 sprites sized 12x24 with full masking running at 25fps:

 

 

14 sprites sized 8x16 with full masking running also at 25fps:

 

 

All done using so called interleaved character screen. 4 charsets used for each buffer (two buffers used now), alternating each 4 rows. That way you get much more free characters to use for background, bullets etc. Any sprite can go anywhere, sprites are redrawn each cycle independent of background changes.

 

Downloads:

char_sprites 2x2.xex

char_sprites 3x3.xex

ps. With shooter games that have black, empty space as background shortcuts can be taken to make it even faster.

pps. 3x3 xex file is with 7 sprites because that Turrican track takes sooo many cpu time that it took 3 frames to draw 8 of them so I reduced it a bit.

 

That is truly excellent work. The big advantage of character mode is that it's character mode! All the advantages of characters and more games are written in it, so you should get good mileage out of your sprite routines.

 

I am doing full and/or plotting. Looking at Delta there are lots of attacks where the sprites are all on top of each other so I don't think you would get away with anything less. It does lda/and/ora/sta for the draw and sta for the erase. If you add a background then you have to do lda/sta for the erase so it will reduce performance by about 1/6th.

 

I added a background and tried the same sized sprites - no music though.

 

12x24 pixel sprites @ 25fps = 12 sprites and 70 scan lines remaining:

 

modeE12hb1224.xex

 

8x16 pixel sprites @ 25fps = 22 sprites and 40 scan lines remaining:

 

modeE22hb816.xex

 

I did look into character sprites some time ago but I only wrote little test routines (it's complex!). Despite the faster erase it always seemed to turn out slower than bitmap mode for me (which was my primary interest). Ignoring the complexity of the code there are a few other areas where bitmap mode benefits:

• You only have to write the bytes that are actually used by the image. In character mode you have to copy the unused leading bytes in the first character and the unused trailing bytes in the last character.
• You can access screen memory with absolute addressing instead of indirect. So the lda/and/ora/sta is 2 cycles quicker. That might not seem like much but it is what the code is doing most of the time.
• I think less cycles are lost to DMA.

With Delta I'm confident that bitmap mode can handle the 7 big sprites (12x21) and have more than enough time for everything else at 30fps (i.e. supporting NTSC). I still don't know about character mode though!

[popmilo]

Wow, nice demos

 

I like your comment about addressing in bitmap mode. I see you used unrolled code in your routine. Nice !

Exactly for reasons you mentioned and that I don't like, I'm using 4 indirect addressing instructions for core routine.

lda (back),y
and (mask),y
ora (sprite),y
sta (chars),y

For each sprite I have to fetch character codes of background chars, calculate their address in charsets, stick it into core routine. Then comes calculating offsets for Yreg and mask, sprite and chars addresses for each sprite column... Talk about pain... Just because I want that 5th color so badly

 

Friend suggested I could get away with absolute mode for background byte fetches also but I haven't even tried thinking about it yet. This was already complex enough

 

As far as I've seen Delta uses only 7 sprites for enemies at a time. Those sprites are max 21 bytes high so your point about drawing only lines where sprite makes more sense.

For example in 8x16 routine I'm drawing 16 lines of sprite into 3x3 chars and than for 8 remaining lines I must copy background bytes into chars used for sprite. Guess that's where most of speed penalty comes from.

 

One problem with bitmap mode I see is bullets... You need to manage drawing 8 larger sprites + dozen bullets + bottom and top graphics...

On the other hand, bitmap mode has less dma access so more cycles available.

 

I'll stick to char mode only because I'm not planing on converting Delta, my goal is something with much more color and less action

 

Most important - Zybex showed how a fast shooter game on Atari can look like. That was almost 30 years ago... Think we can do better now

 

[emux]

Hello everyone,

 

Delta on the C64 has an unusual display system in that all the background graphics and sprites are made of hardware sprites and only the stars and bullets are made of characters.

 

Not sure why he coded it like that but he did!

[popmilo]

Hello everyone,

 

Delta on the C64 has an unusual display system in that all the background graphics and sprites are made of hardware sprites and only the stars and bullets are made of characters.

 

Not sure why he coded it like that but he did!

Yeah, my guess it was just easier to split graphics like that. Looks like each part has only 8 sprites at a time so only interrupts he needed were on transitions between top-bottom parts and middle of screen.

He was pioneering this stuff. There weren't that many shooter games with sprite multiplexing at that time.

 

With his previous game Sanxion he also did that split-screen method.

 

Only in 1987 when Delta came out, other games started using more than 8 sprites in complex manner. Zynaps, Wizball, Delta... Those were first really good shooters on C64.

IO and Armalyte came in '88 and beat everything else out there....

[emux]

Yeah, Delta lends it's self to that type of sprite arrangement and it also used sprites in the border to good effect as the C64 can't overscan. Also by using sprites as the background it did away with the need to have to build the screen every 8 pixels for the scrolling which would have saved some raster time.

 

The best early use of sprite multiplexing on the C64 IMO was Terra Cresta in 1986 (a very underrated game in my option) which had loads of sprites flying around and sorted without much glitching. The Ocean programmers were very good, it's a shame they didn't release more stuff on the A800.

Edited January 11, 2017 by emux

[oky2000]

Stavros wrote Sanxion and Delta games based on an impressive game engine kernal routine he had written and then turned both into those respective games.

 

Yes it's impressive for a game using only the hardware sprites pretty much but at the same time if you look at the multi-parallax games like Enforcer (the most technically sophisticated C64 game of all time) or even the shoot 'em up level of Turrican II it's a really silly idea to do Delta like that. There is no problem making 16 colour games that run at 50fps when your name is Manfred Trenz, the best C64 coder ever to work in the industry. Sanxion uses 4 colour backgrounds, Delta used characters only for bullets and starfield. 

 

 

[Mclaneinc]

Manfred was never known for accepting limitations.... Anyone taking a look at Turrican can appreciate just how good a coder he is..

[+Stephen]

3 hours ago, oky2000 said:

Stavros wrote Sanxion and Delta games based on an impressive game engine kernal routine he had written and then turned both into those respective games.

 

Yes it's impressive for a game using only the hardware sprites pretty much but at the same time if you look at the multi-parallax games like Enforcer (the most technically sophisticated C64 game of all time) or even the shoot 'em up level of Turrican II it's a really silly idea to do Delta like that. There is no problem making 16 colour games that run at 50fps when your name is Manfred Trenz, the best C64 coder ever to work in the industry. Sanxion uses 4 colour backgrounds, Delta used characters only for bullets and starfield. 

 

 

I think I finally see where Duranik got the idea for Native on the Jaguar

[oky2000]

That looks like a cool demo, just checked it out on youtube.