Galaga for 8-bits?

[Heaven/TQA]

@Rybags

 

your Moon Cresta 7800 to VBXE port.... how did you handle the "zones" and Maria stuff?

 

as source of Galaga is available of the 7800 version... what about do a VBXE one?

[Rybags]

Moon Cresta maintains traditional X/Y positions for the objects and does bounding box collision detection.

So, you can just disregard the 7800 DLists and such.

From memory I spaced each line of the bitmap data apart such that less processing was needed in preparing the rendering of the sprites.

Starfield is Antic graphics which just loops.

 

For 7800 to VBXE translations the objective would be to find or construct arrays describing the positions and animations required.

Then just feed them into BCBs. I was sort of lazy and just had all the BCBs active - I think for enemies that weren't visible they were just rendered in an area that was non-display.

[popmilo]

So....

- Anybody has path data from arcade, or idea how to get it ?

- What's your source control choice - hg or git ?

- José can do gfx in a day imho

My vote goes to setting up public repo for shared code. Different gfx versions can be worked on in same time etc...

ps. Same time means like months and years between commits, but that time frame is kinda standard imho

[Heaven/TQA]

Never saw the NES version but thats quite close to the arcade? Why are the sounds so close, too?

 

https://youtu.be/KqRv4N_NK7s

[EnderDude]

Never saw the NES version but thats quite close to the arcade? Why are the sounds so close, too?

 

https://youtu.be/KqRv4N_NK7s

Because most of the sounds of the arcade sound close to a 25% duty square wave that the NES can do with ease. Maybe using the filter on the POKEY might sound close enough.

Edited September 26, 2018 by EnderDude

[peteym5]

If I were to complete this game, I would use the code the Playsoft provided and build a complete game from it. So far, that looks and plays the best so far.

 

I decided to work on a port of Venture on the Atari 7800 using that 7800 Basic to save time on development. Someone showed me how to set up a character mapped Antic 4 screen on the 7800.

[Keatah]

I want this to remain a community project rather than be monetized. Especially with the proof-of-concept mock-ups Playsoft did.

[Marius]

I want this to remain a community project rather than be monetized. Especially with the proof-of-concept mock-ups Playsoft did.

 

Indeed!

[NRV]

So....

- Anybody has path data from arcade, or idea how to get it ?

- What's your source control choice - hg or git ?

- José can do gfx in a day imho

 

My vote goes to setting up public repo for shared code. Different gfx versions can be worked on in same time etc...

 

ps. Same time means like months and years between commits, but that time frame is kinda standard imho

I haven't used git much, but I still would vote for it, instead of hg.

I think probably is going to be easier to plot the trajectories taking screenshots in Mame

 

Never saw the NES version but thats quite close to the arcade? Why are the sounds so close, too?

Aaaargh.. you made me look for the sounds and I drifted far away x)

 

If you want to take a "look" at the Nes sounds:

https://www.sounds-resource.com/nes/galagademonsofdeath/sound/4033/

 

Or prefer a version for the 2600: (there is source down the page)

http://atariage.com/forums/topic/214498-galaga-2600-sound-test/

 

And this app for the Ipad is really nice:

https://itunes.apple.com/us/app/korg-gadget/id791077159?mt=8

 

It seems Namco made available there, the sounds of lots of old arcade games.. including Galaga, Xevious, PacMan, etc.

The nice thing is that it models a Waveform Sound Generator, like the sound chip in the old Namco arcade games,

so you can see how the sounds were constructed, in all detail.

 

 

You can see in the video the wave table (of 32 steps) for some of the sounds.

 

 

Bonus tracks.. two translations of the same interview:

http://shmuplations.com/galaga/

 

https://galaga.com/en/special/int_vol1.php

 

And a nice site that I didn't knew about

https://retrocomputing.stackexchange.com/questions/4733/how-did-z80-multiprocessing-work-in-the-namco-galaga-hardware

[popmilo]

Hey, really nice info on some of those links ! Thanks!

 

Here is what I've found related to enemy movement.

 

http://www.computerarcheology.com/Arcade/Galaga/CPU2.html

 

There are at least 10 types of enemy movements:

; Movement routines
0920: 48 0E       ; 0: (Code does little.) ?
0922: 11 0B       ; 1: Blue Bees Attack Pattern
0924: 41 0B       ; 2:
0926: 49 0B       ; 3:
0928: 9B 0A       ; 4: Keeps ships from leaving initial circle to formation
092A: CC 0B       ; 5: Keeps attack pattern from returning to formation
092C: 5A 0B       ; 6: "
092E: 82 0B       ; 7: Keeps pick-up bee from returning to formation
0930: 93 0B       ; 8: Something strange in the very first fly-on
0932: A3 0B       ; 9: Something strange late in a wave
0934: 42 09       ; A: CHECK THIS OUT -- freezes blue bees after "cheat bee's" first dive
0936: 50 0A       ; B: Pickers caught in circle at top
0938: FE 09       ; C: Red bee caught in large circle
093A: 7B 09       ; D: Split bee into specail bees
093C: 68 09       ; E: ?
093E: 55 09       ; F: Initial wave caught in initial circle
0940: 4E 09       ; 10: ?

For example "blue bees attack pattern":

; Movement Routine 1
0B11: E5          PUSH  HL                 ;
0B12: EB          EX    DE,HL              ;
0B13: 3A 15 92    LD    A,($9215)          ;
0B16: 0F          RRCA                     ;
0B17: DD 46 13    LD    B,(IX+$13)         ;
0B1A: A8          XOR   B                  ;
0B1B: 07          RLCA                     ;
0B1C: 3A E2 93    LD    A,($93E2)          ;
0B1F: 3C          INC   A                  ;
0B20: 3D          DEC   A                  ;
0B21: 20 02       JR    NZ,$B25            ; 
0B23: 3E 80       LD    A,$80              ;
0B25: 38 04       JR    C,$B2B             ; 
0B27: ED 44       NEG                      ;
0B29: C6 F2       ADD   $F2                ;
0B2B: C6 0E       ADD   $0E                ;
0B2D: 67          LD    H,A                ;
0B2E: 3E 1E       LD    A,$1E              ;
0B30: CD A9 0E    CALL  $0EA9              ; 
0B33: 7C          LD    A,H                ;
0B34: EB          EX    DE,HL              ;
0B35: D7          RST   0X10               ; HL+=A
0B36: 7E          LD    A,(HL)             ;
0B37: DD 77 0D    LD    (IX+$0D),A         ;
0B3A: E1          POP   HL                 ;
0B3B: 3E 09       LD    A,$09              ; Add ...
0B3D: D7          RST   0X10               ; ... 9 to HL
0B3E: C3 FA 0B    JP    $0BFA              ; 

My z80 is little rusty, so if there's anyone who knows more about it could tell us how hard it would be to replicate something like this ?

[Rybags]

PUSH = push register pair onto stack.

EX = exchange registers.

LD A,(adr) = load A with the contents of adr.

RRCA = Rotate right A and duplicate the contents of bit 0 into the carry as well as bit 7.

XOR B = Xor the accumulator with register B

RLCA = Rotate left A and dup contents of bit 7 into carry as well as bit 7.

JR = Jump relative on condition

NEG = Negate accumulator (2s complement)

CALL = call subroutine, equivalent to 6502 JSR

 

I have the original but for sure there'd have to be Zaks Programming the Z80 on PDF somewhere.

[peteym5]

I want this to remain a community project rather than be monetized. Especially with the proof-of-concept mock-ups Playsoft did.

 

I cannot disagree in that having community projects encourages more game projects to be produced. Improves quality. I will leave the ideal of a collectible cartridge ideal floating around IF enough people request it to make it worthwhile to produce it.

 

I see a lot of game projects getting started, make some progress, and suddenly stop.

 

For the title screen, are we doing a separate screen, display list, VBI that the program goes to and waits until some presses fire or start? I have a template I use for title screens that has a Graph2Font set up for top half, and Antic 2 or 3 for texts underneath, showing authors, scores, instructions, game options, or story. Done with MADS assembler. Not sure what assembler Powersoft used.

[EnderDude]

Okay, so concerning the sfx, what should we do? I think that we should use a filter between the first 2 channels.

[peteym5]

Something that move things along is divide tasks among different members of the community. Powersoft provided the core programming. Someone can work on secondary programming like title screen, setting up levels, scoreboard displays. and another person can work on the sounds. Maybe do separate standard Atari graphics and VBXE versions. Normally I do sound and music late in the development process because it is critical to get the graphics and game player working correctly first. Are we planning to make this a game that can fit inside 48K so it can be run on an Atari 400/800 with 48K, or we taking advantage of RAM under OS or extended RAM?

[Kyle22]

Personally, I'd like to see a 128 or even CompyShop 576K separate ANTIC version.

 

Most of us have it, and for those who don't, it supports the hardware and firmware vendors.

 

 

Edit: (for the oblivious types) This means they can keep upgrading and DEVELOPING NEW PRODUCTS...

Edited September 30, 2018 by Kyle22

[adamchevy]

I’d like to see a 48k version myself.

[Kyle22]

That would be great if and ONLY if the full arcade experience is there.

 

If it's not too hard to do, it would be nice to see a 48 or 64K version, but also make a big, full featured one.

[Keatah]

Personally, I'd like to see a 128 or even CompyShop 576K separate ANTIC version.

 

Just wondering what you mean by an "ANTIC" version?

 

---

 

I believe that most new games for any system should take advantage of extra memory IF it is there, otherwise stick to a base hardware config.

Edited September 30, 2018 by Keatah

[Gunstar]

Personally, I'd like to see a 128 or even CompyShop 576K separate ANTIC version.

 

Most of us have it, and for those who don't, it supports the hardware and firmware vendors.

 

 

Edit: (for the oblivious types) This means they can keep upgrading and DEVELOPING NEW PRODUCTS...

I agree with you except a seperate ANTIC version if you mean 100% 130XE memory compatible. It's not about supporting hardware upgrades, it's about far more Rambo type upgrades out there and when already talking of a smaller installed base of extended memory owners, 100% ANTIC compatible extended memory is a minority in this smaller community, the fact is most DO NOT have it. Stick with the lowest common denominator with extended memory...that's why so few programs use it already! Things would be different if Atari had been the first to come out with extended memory banking rather than the last...Rambo is the standard most programmers use (and most memory upgrades too!) for the largest user base. And changing upgrades for a half-dozen programs, and maybe just one I'd actually use, seems a waste to me.

Edited September 30, 2018 by Gunstar

[Kyle22]

130XE style Memory Management. ANTIC can use its own bank of RAM which is different from the bank the CPU is using.

 

This is helpful with programs that are large. They can keep video RAM in one bank and the game in another bank.

 

It improves the overall efficiency and appearance of the program. It gives it more space to use without interfering with ANTIC's RAM which could cause the screen to flash and display rubbish as the bank switch happens.

[emkay]

130XE style Memory Management. ANTIC can use its own bank of RAM which is different from the bank the CPU is using.

 

This is helpful with programs that are large. They can keep video RAM in one bank and the game in another bank.

 

It improves the overall efficiency and appearance of the program. It gives it more space to use without interfering with ANTIC's RAM which could cause the screen to flash and display rubbish as the bank switch happens.

One of those silly things they did while developing the Ataris, because it is not really an advantage.

Actually, it WOULD be an advantage, if ANTIC was able to do things itself.

Just like reading it's own charset for the textmode and, offer less Cycle stealing....

But, every time, the screen memory needed a changing , the pages had to be swapped to have access by the CPU. Also: If you do the change at the end of the Display List/start of the VBI, there will be never any flicker, on any machine with any RAM expansion.

[Kyle22]

Stop being so negative. Please don't make me (and more) put you on 'IGNORE' list.

[adamchevy]

It would be nice if this needed to use more ram or some fancy schemes of some sort, that it could take advantage of something like the harmony board. I would really like to not have to purchase an XL with a wizztronics Upgrade.

Edited September 30, 2018 by adamchevy

[emkay]

Stop being so negative. Please don't make me (and more) put you on 'IGNORE' list.

Feel free to do so.

I'm not the one who has given up already , by using the Atari with non Atari extensions, like 16 Bit CPUs or VBXE...

[+Philsan]

Nowadays many of us have 128/320/1024KB machines and/or flashable or SD/CF carts.

Therefore, if 64KB are not enough, a good solution would be to make an executable version for 128/320KB machines and/or a cart version for 64KB machines (128/320/1024KB cart, like Atari Blast!, Space Harrier, Bomb Jack...).

 

Not everyone would like to install a memory expansion, but a $40 multicart is a good investment to play many >64KB old an new cart games.