- The background is gray instead of black. I think you are assuming CRAM is filled with all $00 on startup, instead you should initialize those values.

- You need to set the unused bits in register $85, e.g. OR the sprite table address with $81. Because of this the sprites are improperly displayed.

For me the left/right directions didn't work to control the main ship, but that may be due to the sprite problem I mentioned - when you don't set those bits the X/Y positions are incorrectly read, that may be the cause.

Of course in an emulator it looks very cool. If you are going to use 1-bit graphics only, maybe you should try the TMS9918 modes? :)

i've zeroed the cram, and set the the register 5 to $ff (instead of $7e)
could you give me more detail about the "1bpp TMS9918 mode" you're talking about ?
is it referenced in the vdp bible (aka msvdp-20021112.txt) ?

(i guess camilo by posting and opening a www with crappy w.i.p finally find a way to make me work on it, instead of wowing)

...Plus we have a very cool solid story for our game now, check this out:

Quote

STORY
76496 AD,
the master solar system is invaded by unknown alien oddities
having the capacity to multiply themselves quickly.
Soon the space oddities, known too as the Zlogian empire,
represent a real menace to men.
You, Mark Sri, best pilot of the human race is chosen
to control the high-tech prototype ToMuSu-9918A
and destroy the Zlogian empire and their native planet Zlogu80.

There are numbers of hidden references to the master system universe.
The first member of the forum to find it all will win a beer.

Could you change the files so they are zipped? My web browser didn't like the ".SMS" extension.

The new version works, all the old problems were fixed.

The VBlank routine takes too long, because I can see the sprite table being updated around line 80.

An easy way to tell when this happens is to change the screen or border color, or turn off the screen, at the start of the VBlank routine and restore it afterwards.

This way you can look at the top of the screen and see if the changes made during VBlank "overflow" into the next frame.

If you want some tips about speeding up VBlank processing, let me know.

Quote

i've zeroed the cram, and set the the register 5 to $ff (instead of $7e)
could you give me more detail about the "1bpp TMS9918 mode" you're talking about ?
is it referenced in the vdp bible (aka msvdp-20021112.txt) ?

many thanks for your feedback !

The TMS9918 modes use 1-bit sprites that can be 8x8 pixels or 16x16 pixels (instead of 8x16). If you want to make the game use 1-bit sprites only, this could be useful. But there are limitations like only 4 sprites per line instead of eight.

I haven't added the TMS9918 modes to my document (err... bible :) yet, but I've been using them a lot recently and will add them soon.

76496 AD, <-- SN76496 PSG (should probably be 76489)
the master solar system <-- Master System
is invaded by unknown alien oddities
having the capacity to multiply themselves quickly. <-- fast multiplication is alien to the SMS :)
Soon the space oddities, known too as the Zlogian empire, <-- Zilog, makers of the Z80 CPU
represent a real menace to men.
You, Mark Sri, <-- sounds like "Mark Three"
best pilot of the human race is chosen
to control the high-tech prototype ToMuSu-9918A <-- TMS9918A, the VDP in the SG-1000 etc, basis for the SMS, GG and MD VDPs
and destroy the Zlogian empire and their native planet Zlogu80. <-- Z80, which kind of sort of means Zilog 80

Before you post, I was wondering "How to send a beer to maxim?"
So no surprise,you won!!! \o/ \o/ \o/
By the way your "bock's birthday 2004" was a gem!
And thanks to mentioning the SN76496 mistake ,I'll change this.

Even in the active display period, push ix/pop ix/nop is more of a delay than is needed. In my tests (link) I was able to get consistently not-destroyed data with a total of 26 cycles between writes. This includes the length of the opcodes being used to perform the output (and since one of those cycles is performing the outut, that should really say 25). In most cases when outputting two bytes, you'd use the same opcode for both so you simply subtract its length (eg. 12 cycles for out (c),r) from 26. Suitable "nop" code depends on the context.

Charles did test it for me on an NTSC system but I don't remember what the result was; it may have been "your test program doesn't work". But regardless, trying to satisfy the VRAM access wait requirements in Emukon (assuming they're still there) results in slower-than-needed code.

Charles&Martin&Maxim:
i was waiting for $f3, (which according to bock reaction when i told him, was very BAD! , instead of proper interruption handling,
i quickly fix by waiting for $c0,
and removed the useless "pop/push/nop thing" as i'm finally handling SAT mirror in vblank
(i think martin notice sat mirror at line 0, because of the vblank routine overflow)

THANKS FOR YOUR COMMENTS !
(thanks for the beer)

plz watch for v17 (as soon as tet post it)
i'll take a look with emukon xor charles-vblank-tricks to see if i don't overflow anymore.

Before going to work,
information:
Yesterday, our staff grown up whith one significative member,
Zabutom, from BeepDealers (chiptune crew).
You can check the music he did for our project here:
(even if it's not a final version it's already impressive)

Actually, the importance of music is growing in the project; my idea is now
to release the game whith the idea of game-album, which will consist in not having
ANY sucky tune in the game + a sound test mode.(Maybe the music team will be bigger in few days too...)

Heya, just a message to tell you spaceoddity is far from dead,
even if our schedule was raped.
Now the team is working to release a 1 level demo,
(maybe at the end of the year)
don't expect new beta releases,
we whish to surprise you whith the demo =).