Space Invaders

[hap]

If you think CHIP8 is too easy, or GameBoy/NES/MasterSystem is too hard, writing a Space Invaders emulator is not. Most work will be put into creating an Intel 8080 CPU emulator (shouldn't be too hard for the GameBoy crowd :P ), the rest is peanuts.


Space Invaders, (C) Taito 1978, Midway 1979

CPU: Intel 8080 @ 2MHz (CPU similar to the (newer) Zilog Z80)

Interrupts: $cf (RST 8) at the start of vblank, $d7 (RST $10) at the end of vblank.

Video: 256(x)*224(y) @ 60Hz, vertical monitor. Colours are simulated with a
plastic transparent overlay and a background picture.
Video hardware is very simple: 7168 bytes 1bpp bitmap (32 bytes per scanline).

Sound: SN76477 and samples.

Memory map:
ROM
$0000-$07ff: invaders.h
$0800-$0fff: invaders.g
$1000-$17ff: invaders.f
$1800-$1fff: invaders.e

RAM
$2000-$23ff: work RAM
$2400-$3fff: video RAM

$4000-: RAM mirror

Ports:
Read 1
BIT 0 coin (0 when active)
1 P2 start button
2 P1 start button
3 ?
4 P1 shoot button
5 P1 joystick left
6 P1 joystick right
7 ?

Read 2
BIT 0,1 dipswitch number of lives (0:3,1:4,2:5,3:6)
2 tilt 'button'
3 dipswitch bonus life at 1:1000,0:1500
4 P2 shoot button
5 P2 joystick left
6 P2 joystick right
7 dipswitch coin info 1:off,0:on

Read 3 shift register result

Write 2 shift register result offset (bits 0,1,2)
Write 3 sound related
Write 4 fill shift register
Write 5 sound related
Write 6 strange 'debug' port? eg. it writes to this port when
it writes text to the screen (0=a,1=b,2=c, etc)

(write ports 3,5,6 can be left unemulated, read port 1=$01 and 2=$00
will make the game run, but but only in attract mode)

I haven't looked into sound details.

16 bit shift register:
f 0 bit
xxxxxxxxyyyyyyyy

Writing to port 4 shifts x into y, and the new value into x, eg.
$0000,
write $aa -> $aa00,
write $ff -> $ffaa,
write $12 -> $12ff, ..

Writing to port 2 (bits 0,1,2) sets the offset for the 8 bit result, eg.
offset 0:
rrrrrrrr result=xxxxxxxx
xxxxxxxxyyyyyyyy

offset 2:
rrrrrrrr result=xxxxxxyy
xxxxxxxxyyyyyyyy

offset 7:
rrrrrrrr result=xyyyyyyy
xxxxxxxxyyyyyyyy

Reading from port 3 returns said result.

Overlay dimensions (screen rotated 90 degrees anti-clockwise):
,_______________________________.
|WHITE ^ |
| 32 |
| v |
|-------------------------------|
|RED ^ |
| 32 |
| v |
|-------------------------------|
|WHITE |
| < 224 > |
| |
| ^ |
| 120 |
| v |
| |
| |
| |
|-------------------------------|
|GREEN |
| ^ ^ |
|56 ^ 56 |
| v 72 v |
|____ v ______________|
| ^ | | ^ |
|<16> | < 118 > |16 < 122 > |
| v | | v |
|WHITE| | WHITE|
`-------------------------------'

Way of out of proportion :P

attachments:
8080asm.7z: i8080 assembly programming manual, needed for 8080 emulation,
8080ds.pdf: i8080 datasheet, the table on page 8 and 9 is handy,
76477.pdf: SN76477 (I've hardly looked at that)

[hap]

Here's mine :D .. source code only.

*edit* made a mistake in the documentation: Read 0 should be 1, 1 should be 2, 2 should be 3. The above post has been corrected, but I won't release an updated version of "It's a trap!". (it's fine in the code)

[Exophase]

Looks good. This should only be a little bit harder than chip8, not counting sound. Is "attract mode" auto-play demonstration?

Other small question - this shouldn't make a difference for Space Invaders (and probably almost any software) but the way you're storing flags, as represented by the result of the previous calculation - it should be possible for the program to compute flags (using pop psw) and thus have both zero, negative, etc set at the same time. IE, if the user did (assume b is already something like 0xFF, loaded from memory or something)

push b
pop psw
push psw
pop b

You'd end up with a different b. Like I said, I doubt this matters because no sane programmers would construct the flags, it's just something I've thought about before.

[hap]

Yes, it's like having no pocket change.

*edit* you're right, I didn't think of that. I'm using the same method on my 6502 emulator (NES)... and should probably change that considering the large library of NES games.

[bronxbomber92]

Looks like something I can try next after I finish the chip8 :)... And looking at you source briefly it seems like space invaders would be easier, would it not?

[hap]

If you've successfully created a CHIP8 interpreter, you've gained experience. In that sense, it's easier to create a Space Invaders emulator. I mean, going from zero to CHIP8 is harder than going from CHIP8 to Space Invaders, get it?

[ShizZy]

Nice plastic transparent overlay :) This looks like a good project for a rainy day though sometime when I'm bored. Thanks for all of the docs. Oh, and by the way, is the rom PD? If not, you have any more specific name or something so it can be located? :P

[hap]

invaders.h, invaders.g, invaders.f, invaders.e, each 2KB in size. MAME supports the game, called "invaders.zip", search for it on Google.

If this link is against the rules, please remove it: mame roms "space invaders" - Google Search (http://www.google.com/search?num=20&hl=en&lr=&safe=off&q=mame+roms+%22space+invaders%22)

[Garstyciuks]

I think that I'm going to make space invaders emulator :) It looks quite interesting. But can someone explain me why does nes, gameboy, space invaders, and a lot of other systems need "RAM mirror"?

[Exophase]

I can't say the specific reasons, I can only guess the following two things..

- It's easier/faster to implement in hardware. Seems counterintuitive, but throwing out bits on an address bus is a lot easier to do than detecting bits and having it do something else. That's basically what happens with mirroring, it's like a big binary AND off the top bits, so you can just ignore them.

- Sometimes different mirrored region have different specifications, like on GBA the different cartridge spaces have different wait state configurations, and on PSP the different mirrors of VRAM affect swizzling somehow (I don't totally recall at the moment)

[|\/|-a-\/]

well, even if i try a space invaders emulator, i wouldn't understand the scrolling register in the gameboy :(

[bcrew1375]

What don't you understand about the scrolling registers?

[|\/|-a-\/]

hmm, i don't understand anything about the scroll reg... but that belongs in another thread..... they tried to explain it to me in the gameboy thread....

[blueshogun96]

Wow, that does look rather easy. No wonder the guy who wrote that emu programming tutorial that I posted on my sig decided to use space invaders as the tutorial example. :party:

[blueshogun96]

I found another helpful page for those willing to read it:
http://www.darkpact.com/proj/siemu/is/report2.html

btw, does anyone have documentation on the sound chip? Been searching google, and got only block diagrams and pinout sheets.

EDIT: Here's a list of machines that have similar/identical hardware:
System 16 - 8080 Based Hardware (Taito) (http://www.system16.com/hardware.php?id=629)

[Robbbert]

You should look at the source for MAME to get the idea of how to program the sound. The SN76477 is only used for the sound of the ufo moving across the top, all the other sounds are produced by discrete circuits (resistors, capacitors, diodes and op-amps). MAME uses samples for these sounds.

Look in src/sound/sn76477.c and src/sndhrdw/8080bw.c


Sound bits:
Port 3
- bit 0: Saucer sound via sn76477
- bit 1: shot
- bit 2: Base hit
- bit 3: invader hit
- bit 4: bonus base

Port 5:
- bits 0 to 3: walking sounds
- bit 4: saucer hit

[ShizZy]

Question for you hap. This may be kind of stupid of me for not seeing it, or lazy of me for not checking your source, but I didn't see what location in memory the read and write ports are? Could you explain? Thanks.

[hap]

I found another helpful page for those willing to read it:
http://www.darkpact.com/proj/siemu/is/report2.htmlNice find. And indeed, the best information source is probably the MAME source. The hardware description I posted in the 1st post was gathered from MAME too.

ShizZy: You already know of the concept memory mapped IO. Space Invaders (and plenty of other hardware) also uses port mapped IO, with opcodes OUT ($D3) and IN ($DB), both taking a port number (0-255) as parameter.

eg. OUT 2 writes A to port 2, and IN 2 reads from port 2 and puts the value into A. Read and write ports having the same number doesn't necessarily mean they're connected to the same IO device. (these opcodes are also available in the Z80, but were removed for the GameBoy CPU)

[ShizZy]

Ahh thanks... I was assuming it was mapped right into main memory, as on gb and nes, as well as many other more complex systems. That makes sense though.

[smcd]

There's an interesting approach called "tickle" that does things by emulating at the hardware level, Tickle(click here) (http://www.ascotti.org/programming/tickle/tickle.htm) interesting to look at if nothing else

[Pixman]

Anybody found some new articles or updates on this?

I'm now trying to code a Space Invaders emulator by myself, looks very interesting to me and as a good start before I can approach on something else.

Have some of you already finished an 8080 emulation and can provde source codes? Would be very interesting to me and others I think.

Greets,
Pix

[smcd]

http://www.ascotti.org/programming/side/side.htm is nifty (as is PIE and Tickle, which I mentioned earlier in the thread, is on there as well)...

[hap]

Any progress Pixman?

[Pixman]

Yeppa :)
It's going forward.
Your emulator was a big help, by the way. But I'm doign mine completly in C++ / OOP.

The base-structure is finished, now I'm implementing the opcodes and this is why I write: I'm looking for a good opcode-table _with_ cycles.

I don't want to lookup emulator source code all the time.
I only find tables without cycles.

Thanks for your help. :)

I already see, that it was a very good idea to make an I8080 emulator in the first place instead of the gameboy emulator... way more simple.
Greets,
Pix

P.s. I can _really_ recommend the SIDE / PIE source code for understanding the principles of emulation. Helped a lot in my case.

[hap]

I'm looking for a good opcode-table _with_ cycles.

I don't want to lookup emulator source code all the time.
I only find tables without cycles.

lut_cycles + lut_mnemonic in my emulator... source code (sorry :P )

[smkdan]

I have a quick question: There's a couple of operations for the 8080 that aren't documented anywhere it seems. I don't think I missed them, and that pattern looks suspect. They're 0x08, 0x18, 0x28, 0x38. At the moment I'm putting these as NOP's but incase something uses it, how does it react really? Google isn't being the friend people make out to be.

Thanks,

[hap]

how does it react really?I don't know.

If you're just going for a Space Invaders emulator, substituting undocumented opcodes for NOPs is ok, since it never executes them.

[smkdan]

Ok, thanks. One less thing to consider when problems arise. But now that they have...I want to make sure I got the right idea.

By interrupts CF and D7 you mean RST 1 and RST 2? I have 17066 cycles passing before 1, then another 17066 until the next as another doc here seems to say. With ram mirror on 0x4000+ does it apply to ram *only* or does rom become part of the mirror? I remember seeing in other doc it applies to the whole lot but I'd like to know where the problems may be for sure.

Also, does it actually rely on mirroring to function? I have 0x4000 bytes of memory set aside for rom and ram and I mask accesses with &0x3fff because the app kept crashing with accesses outside of the memory...If it doesn't, I know I have something to sort out.

Thanks again.

[hap]

Interrupts work with the interrupting device putting an opcode on the databus, theoretically this could be any single-byte opcode, in this case indeed RST 1 and 2.

Space Invaders is not very sensitive to timing, so a 50/50 (17066/17066) ratio will probably work. I assumed the interrupts to happen at the start and end of vblank, with timing of 127.35369 cycles per scanline (2mhz/(60/1.001)/262)*, 224 lines active display (28527 cycles) and 38 lines vblank (4839 cycles).
*: assuming standard NTSC with 262 scanlines at ~59.94hz

As for mirroring, I didn't test further than just RAM mirroring (got that info from MAME btw). My emulator writes outside the 'legal' area, which could be caused by a bug in my quickly written only-tested-with-SpaceInvaders 8080 core.

[smkdan]

Ok, I'm getting title screen (sort of) but it's not long before it crashes. It prints the introduction stuff like the score counts and high scores but when it tries to go into the attract gameplay it crashes. Also, everything that is printed is upside down, although they are placed on the right area of the screen...I figured I'd get all or nothing so this is really throwing me off...

http://img223.imageshack.us/img223/9334/sicrashnv4.png
http://img221.imageshack.us/img221/2882/sicrash2no6.png

Any ideas much appreciated because this is casuing an awful lot of head scratching.

[hap]

If the crash is a Windows program crash, it's probably due to the program reading/writing outside of an array. If it's an 'internal' crash, it's most likely due to a bug in your CPU core.

As for the upside-down graphics, when updating the window, you'll have to read the 8 bits from the vram bytes in reversed order. I had the exact same problem.

[smkdan]

I would have never thought of the reverse order video...

Well, I fixed up the rotate instructions so it goes in game and the attract play works great. Still more bugs to work out though, like those wierd bunker hits and the fact that the '0' in the score is deformed when hit (?!) and the alien that fixes up the inverted 'Y' is missing in the attract mode.

Anyway, atleast it'll a be a tad easier now that I get some actual game screen so I can immediately make changes and see them right away.

http://img215.imageshack.us/img215/1360/siattractre0.png

[smkdan]

http://img339.imageshack.us/img339/58/siworksob9.png

I've been staring at the CPU code for quite a bit when really the in game issues were caused by the shift register shifting left to make room for new data instead of shifting right...The bunker and shots look right and the aliens don't leave impressions of themselves as they advance. I thought all was well but the inverted Y at the second round of attract mode still doesn't have the alien coming out to fix it...This is the last niggling issue left until the game runs perfectly well (atleast to me and SI). I'm clueless as to what's causing it. I had a look at the MAME source but I'm still stuck. I was thinking of trying the NES out but having this irritating issue left...

Hap if you have any clues as to what's causing this it would be much appreciated. Unitl then, I'm going for a NES emulator. I got a good grasp on the 6502 and the PPU. Audio has to wait but I'll try my best to understand it.

http://img228.imageshack.us/img228/337/sidoesntworkswj5.png

[hap]

It's probably a bug hidden somewhere in your 8080 core. With only one game that can be used for testing (Space Invaders), I understand it's annoying and very hard to find it.
Actually, it might be easy to add support for games using similar hardware, that would make testing easier, but I haven't looked in to that myself. I suggest you just forget about :/ and move on to another fun project, like the NES. Space Invaders isn't worth the irritating hours it may take to find the bug :P

[krypt100]

Here's my progress on SI emulator and Phoenix (it's in JAVA), the i8080 assembly manual on the first page is really helpful for anyone who wants to write his own 8080 cpu core.

I had to copy the interrupt handling and IN/OUT routine from "it's a trap" since I was too lazy to do it myself (I hope you don't mind :))

As for Phoenix, I reused my cpu core (8080, phoenix uses 8085) and implemented the memory emulation.
I used the AEHOWTO.txt doc for the memory emulation and I had to use Jabawape 0.21 src for graphics emulation, since the doc that I found didn't elaborate much on it's video hardware and couldn't fully understand it.

[Thesuperchang]

Hi guys, I've upgraded from Chip-8 to Space Invaders. The emulator is being coded in C (C99 standard) in a 32-bit Linux environment (Ubuntu 8.10). The emulator currently relies on the X Window system. I will re/upload my work as it evolves.

My current status on this project is below;
- i8080 Core (http://www.megaupload.com/?d=YQY01JMZ) 85%
date: 20/01/09
At the moment, it should be able to compile on any little-endian platform that has support for the standard C libraries. However, if your not using a platform that has support for the X Window System, you won't be able to compile with debug mode enabled.

- i8080 disassembler (http://www.megaupload.com/?d=KI6FAGGM) 100%
Date: 20/01/09
Disassembles Intel 8080 machine code. Should be able to compile and run on any platform that supports the standard C libraries. To disassemble machine code type;

./executable input output

- i8080 Assembler (http://www.megaupload.com/?d=UOVJ8ARC) 100%
Date: 21/01/09
Will assemble anything that comes out of the disassembler found above. At the moment it does not contain a user manual containing the mnemonics, nor does it contain a manual of how the input should be structured. All I can recommend at the moment is to find some i8080 machine code and disassemble to get an idea of the programming structure. To assemble assembly code type;

./executable input output

- System Misc Hardware 10%

- System keypad/coins 0%

- System Graphics 10%

- System Audio 0%

I will not provide any protected i8080 machine code. Sorry.

[Antígeno]

Hi all, i need little from you guys to fix a bug in my space invaders emulator. I'm trying to understand how to update the screen. I'm doing something wrong , cause the player and the aliens are leaving impressions of themselves on screen. If you now how to fix it, let me know. I'm coding in C and Allegro.

thanks anyway

[CodeSlinger]

Without seeing your code it is difficult to guess what you're doing wrong. It sounds to me like you're not clearing the screen after rendering a frame.

[Antígeno]

I'm trying to upload a snapshot, but I'm getting an error message.
Anyway, my basic code.

void ramWrite( unsigned short int address, unsigned char byte ){

siRam[ address ] = byte ;
if( address > 0x2400 )
siVram(address,byte);

}

//
void siVram( unsigned short int address , unsigned char byte ){

int posx, posy, color;
posx = address>>5;
color = address&0x1f;
posy = ((address&0x1F)<<3);
_putpixel32(Buffer,posx,255-((posy) ), byte&1 ? Overlay : black );
_putpixel32(Buffer,posx,255-((posy)+ 1), byte>>1&1 ? Overlay[color] : black );
_putpixel32(Buffer,posx,255-((posy)+ 2), byte>>2&1 ? Overlay[color] : black );
_putpixel32(Buffer,posx,255-((posy)+ 3), byte>>3&1 ? Overlay[color] : black );
_putpixel32(Buffer,posx,255-((posy)+ 4), byte>>4&1 ? Overlay[color] : black );
_putpixel32(Buffer,posx,255-((posy)+ 5), byte>>5&1 ? Overlay[color] : black );
_putpixel32(Buffer,posx,255-((posy)+ 6), byte>>6&1 ? Overlay[color] : black );
_putpixel32(Buffer,posx,255-((posy)+ 7), byte>>7&1 ? Overlay[color] : black );

}

void siIrq( unsigned short int address ){

if ( inte ){

inte=0;
pushpc( pc ) ;
pc = address ;
//no need to decrement cycles
}

}

main(){


//my main loop. Just for test

while(!key[KEY_ESC]){ //

cpuRun( 17000 );
siIrq( 0x0008 );
[COLOR="Red"]blit(buffer,screen,0,0,0,0,224,256);
clear_bitmap(buffer);//wrong way to clean
cpuRun( 17000 );
siIrq( 0x0010 );
// audio/joystick update
}


}

Looks like everything(except timing and sound) that was emulated is ok. But look the picture.

http://farm4.static.flickr.com/3129/3219176900_49d7d2baa8_o.png

using clear_bitmap(buffer):
http://farm4.static.flickr.com/3476/3220246974_c91f50f7f8_o.png

I don't now how to fix this bug. I don't understand the right way to work with vram and how to update the screen. The clear_bitmap(buffer) was the last attempt.

[swatgod]

hi, i have been working on space invaders for a while now and i am just about finished, all that remains is that where the alien is supposed to come out to switch the y, it crashes, i have done some debugging and found that at an area where it is adding 20 to the h register pair, that its already to high at this point and causes it to go outside the boundaries of the memory array, would anyone know possibly why this happens?

edit: i figured out the cause of the crash and fixed it. it would seem space invaders needs a minimum (at least mien did to work right) of 0x41B9 bytes of ram to function perfectly and have the alien fix the y without crashing. hope this helps anyone else working on space invaders.

[serge2k]

well I started space invaders.

Got to the point where it was supposed to be showing stuff on the screen but it wasn't working properly and the design was incredibly painful to debug.

So I restarted and planned it out a bit better.

http://img118.imageshack.us/img118/74/spaceinvadersfristscree.png

It is quite slow right now, I have a bunch of code that I'm just using to debug it that I think might be part fo the problem. Still have quite a few opcodes to implement as well.

[redneon]

I'm trying to write a Space Invaders emulator to teach myself about writing emulators. I'm a professional programmer in the games industry and I've always been interested in emulators and fancied giving it a go.

I picked the Space Invaders cabinet because it seems extremely simple. I can theoretically just take existing 8080 or Z80 emulator code and just wire in the required functions to handle memory and whatnot.

Obviously, in future I'd like to do everything from scratch but as a start I thought I could knock up something like this in a couple of hours easily enough.

I'm using Marat Fayzullin's Z80 emulator code from http://fms.komkon.org. I've got a 64k memory buffer of which only the first 32k should be being used (16k for the cab and then the mirrored 16k). I'm loading the roms (invaders.h, invaders.g, invaders.f and invaders.e in that order) into the first 8k of my buffer.

I'm not sure how to do the mirror exactly but at the minute I'm literally just mirroring the first 16k into the second 16k (i.e. 0xab, 0x12, 0xd4 ... 0xd4, 0x12, 0xab).

The problem I'm having immediately is that only the read memory function from the Z80 emulator code is being accessed. The write memory, read port and write port functions don't get called at all from the Z80 code.

I'm presuming that the Z80 code starts picking up instructions at address 0x00 (the first element in my memory buffer and the first byte read in from the roms) and just runs from there. The first address it tries to read from is 0x00, followed by 0x01, 0x02, 0x03, 0x04 and 0x05. This would result in the following byte values being accessed 0x00, 0x00, 0x00, 0xc3, 0xd4, 0x18. Now I'm not sure how the Z80 works which is why I'm posting on here but the seventh address it tries to read is 0xd418 which seems strange to me for two reasons. 1) because it's greater than the 32k of memory that the cabinet is supposed to have (16k and 16k mirrored) but the main reason I find it strange is because 0xd418 is the combined value of the last two returned values (from accessing addresses 0x04 and 0x05).

I'm not sure whether it's a bug in the Z80 code or, more likely, something I'm doing wrong or not understanding.

My foray into the world of emulation is only a couple of hours long so far but I'm already enjoying it and am hoping someone can point me in the right direction.

[swatgod]

space invaders uses a i8080a cpu, which would explain the trouble you are having. z80 wont be able to run the space invaders code at all to my knowledge as they are 2 completely different cpu cores.

[nameuser]

Actually, the Z80 is backwards-compatible with the 8080/5, though there may be a few very differences when it comes to some flags. (for example, the P/V flag seems to be calculated differently)

For something as simple as booting Space Invaders - this shouldn't be a problem. (though fully running may prove problematic. Or may not.

Anyway, the program should jump to the valid address 0x18d4, so it seems that your emulator doesn't handle 16-bit words correctly? Maybe your machine's endianess is different from the machine endianess that the CPU emulator expects?


EDIT:
Oh and you misunderstood mirroring.
if, for example, a document says that "0x4000 - 0xffff" is a mirror of "0x2000 - 0x3fff", that means that:
mem[0x4000] = mem[0x2000]
mem[0x4001] = mem[0x2001]
...
mem[0x5fff] = mem[0x3fff]
mem[0x6000] = mem[0x2000]
...
mem[0xffff] = mem[0x3fff]

[nameuser]

Sorry for double posting, but I was wondering what the differences between the Z80 and the 8080 are? (aside from things like timing and the addition of many instructions and features in the Z80)

Going by the 8080 doc I read, it seems that the 8080 sets the P flag to the result's parity even in arithmetic instructions, while the Z80 sets the P flag to the overflow. Is this true?
Additionally, there seems to be no trace of the "N" flag in the 8080 doc I've looked through, suggesting that the 8080's DAA instruction always operates as if after addition. Is this true?
Anything else?

Are there any "the undocumented documented"-style docs for the 8080/5?
Thanks.

[redneon]

Oh and you misunderstood mirroring.

So it literally just duplicates the memory byte for byte from a specified address?

I know it's possible to emulate Space Invaders with a Z80 as a friend from work did it a few years ago. It was he who pointed me to Marat Fayzullin's website. I believe he used Marat Fayzullin's Z80 emulator too but it was a long time ago. 12 years, apparently :)

I see what you mean with the endianness but I believe the 8080 and Z80 are both little endian and the platform I'm developing on (x86, surprise surprise) is also little endian, so this shouldn't be an issue.

[redneon]

Just thought I'd reply and add that I've figured out what the problem was. There's a define in the Z80 code (LSB_FIRST) which enables little endianness (I wrongly assumed this would be done by default).

I'm on the right track now, at any rate.

[redneon]

Quick question. I've got it all working now but I don't understand why I need the mirrored memory? The game works exactly the same without it and with a 16k memory buffer.

[Facon]

I've problems coding interruptions in 8080, how it should work?, I try to check hap's code, but it's unclear to me, I also check the documentation of the post but it says nothing (apparently) about it.

Can anybody explains it?

[serge2k]

I was just wondering, is it actually necessary to emulate the 8088 auxilary carry flag?

edit: Okay, based on what I'm seeing it's not needed, but scoring and credits will be messed up if you don't.

[n00b1]

I'm also making space invaders emulator and still have some problems which prevents playing the game.

At the moment everything looks like it should until to the part where invaders should come to the screen and then the screen wipes black and resets the program. Same thing happens if I insert coins and press start.

I think the shift register works like it should but I don't know why does this happen.

Other thing is that I got bored playing with the space invaders and tried out the balloon bomber and lunar rescue roms also as they should work with the same hardware I think. But I don't get it how can they work if the rom size is bigger than space invaders 8KB < 12KB. Then they try to set the stack pointer to 0x2400 like space invaders. Isn't that rom area? Anyway as result I get messed graphics in the title screen because it is writing over the program area :)

[ASH-II]

Hello everybody (New here hope you can help :) )

I am trying to write Space Invaders on a new OS called SpecBas (it uses the ZX Spectrum Basic++ and outputs to Windows,Linux) it's in Alpha stage and I'm helping test it. (It's a bit like AMOS for the AMIGA but for PC's)

Anyway....

so I have managed to enter all the op codes and I am now up to the part where it draws the aliens in attract mode and from what I can understand (and I use that term in the loosest sense) I now need to emulate IN and OUT for the 'bit shifting' ???

and this is where I am stuck.

so in simple (idiot if you like) terms, what is 'bit shifting'?


how does the IN and OUT affect it (so which ones should I be emulating)

and where are the results stored? are the in the rom/ram or are they stored elsewhere (so I need to set up a new variable?)


Thanks for any help you can give me.

P.S. OR AM I TOTALLY WRONG HERE AND WHAT SHOULD I DO TO GET THE ALIENS DRAWING ? :(

Screen shots.

http://i699.photobucket.com/albums/vv352/ASH-II/space1.png

http://i699.photobucket.com/albums/vv352/ASH-II/space2.png

[pradipna]

"what is 'bit shifting'?"

I don't know the 'In' and 'Out' you're talking about (hadn't attempted to make a space invaders emulator :P) but bit shifting is really simple. Read the Bit Shift section of this: http://en.wikipedia.org/wiki/Bitwise_operation
In C++ you can use << and >> operators to shift bits.

And really nice screen shots, good luck!

[ASH-II]

Thanks for the link.

yes I understand that bit it's similar to rrc,rlc, etc I am confused which ports I need to emulate (this is the IN and OUT) just enough to get it running. :)

As you can see it won't show the Aliens , so is there an interrupt that I'm missing like the screen beam at $20c0