The harddisk is still around somewhere (again, in my parents' basement), but don't get your hopes up.
Your second statement I did not understand completely?

@parallax
As no border masking is performed during the scrolling, I guess that the screen width is 240 only to
reduce the drawing time, isn't it ?

Ho do you use the VRAM pages?
How many 8x8 tiles do you address in your maps and store in your VRAM?
How do you map special features of the blocks like transparency or level layers?
How do you recognize that the current tile does not need to be updated as the
one that is already there is the same tile?
Do you plot the screen per lines or per columns?

If the harddisk has "only" crashed logically, I can help you if you are willing to do some e-mail exchange and running some custom diagnostic programs on your MSX. I have had harddisk crash already 3 times. Once one of the hard drive reading heads broke, but other times have been logical problems, and I've been able to fix them without dataloss.

Typical problem is, that you execute some stupid program, that messes up your partition table or bootsector. Usually damage is limited to this, because this already makes the hard drive unusable (even for the damage making application)

I don't know what interface you have, but I have some experience of fixing these kind of problems on Novaxis compatible SCSI drives and Sunrice IDE drives.

If it is really physically broken, then maybe you can tell us the hard disk model. If we can find identical, maybe the problem can be corrected by replacing some parts to it.

parallax, your harddrive crash is one of the key stories on this website, so you definitely won't get rid of the subject And it's understandable, Core Dump was/is just too good to be true

Oh dear, I turn my back for a second and questions pop up.

@artrag:

> size?
yes, just for performance.
> Ho do you use the VRAM pages?
dunnoh, I forgot. Needless to say that every byte is used.
> How many 8x8 tiles do you address in your maps and store in your VRAM?
Tech specs here: www.shape9.nl/parallax/Core_Dump/tech.htm
> How do you map special features of the blocks like transparency or level layers?
An information byte per block, with each bit carrying info. This is also used to determine what are walls/platforms and such.
> How do you recognize that the current tile does not need to be updated as the
> one that is already there is the same tile?
Because there is a buffer per page, where I store what was printed last time.
> Do you plot the screen per lines or per columns?
That is not very relevant. But in fact, I first plot the sprite areas, and then do whatever is left (per line, but this is irrelevant for the speed).

Okay, I get some coffee and then return for the rest of the questions.

Riiiight.... *slurp*

@nyyrikki and latok:

The harddisk had (at least) a physical problem; I would have been able to restore sectors myself; in the end, I couldn't even get it to spin anymore. However, let's be clear about this: I'm sorry, but even if such a recovery were possible, I don't have any time to work on Core Dump.

So please guys, let us restrict this to an information passing thread and not a hardware forum

Allright: considering the tech specs on the sprite blocks:

It says 5 sets of 256 blocks. That's completely true, but I can tell you how that breaks down into three sets:
1x 256 blocks for bullets/explosions: anything used in every level which is symmetrical.
2x 256 blocks for player sprites, laser weapons: the engine mirrors the set (so the second set is simply a mirrored set): each sprite has a bit to flip it horizontally; then, the engine automatically makes sure animation and everything runs correctly.
2x 256 blocks for the level enemies: again, 256 blocks facing left, 256 facing right.

This automatic flipping of the sprites involves reading animation/map tables in reverse, and things like that. But it saves you a lot of trouble if the engine can handle it automatically and you don't have to worry about it.

Interesting stuff! Now I have a question. How do you take your coffee?

Assuming you need 2 VRAM pages for page swapping
you have left for storing tiles an area of 256*512 points, i.e. 2048 8x8 tiles

On coredump tech page you say :
5*256 tiles for sprites = 1280 8x8 tiles
256 8x8 blocks for layer 2 + 256 8x8 blocks for layer 3 = 512 8x8 tiles
256*192 pixels for backgound = 768 8x8 tiles

The sum is 2560 8x8 tiles... Am I missing something?

what do you meand when you say that the engine flips automatically the sprites?

Do you store the sprite maps in RAM ? (probably yes)

About the aswer on the buffer you say

"Because there is a buffer per page, where I store what was printed last time."

Actually my question is was :

how does the asm code check if the tile already in the buffer is the correct one ?

PS
thanks for answering :-)

Quote:

So please guys, let us restrict this to an information passing thread and not a hardware forum

Ok, then please pass on (all information on) that harddisk *grin*

Looking at the Gallery, I have to say the some of the backdrop images look very much like the backdrop images used in the Amiga/PC games 'Another World' and 'Flashback'.
Coincidence? :-)

@Edwin:

Well, glad you asked Black, Today, but usually with milk.

@artrag:

Well look at it this way: 128KB vram breaks down to 4 pages, each with room for 4 x 256 blocks. Thus you could store 16 in memory, if not for the fact you need to reserve two pages for visible screen swapping. If you cut these at 192 pixels vertically, you can just fit one set below each page. This leaves 2x1 + 2x4 = 10 sets. The static background basically covers the same space as 3 sets. So there are 10-3 = 7 sets left. The sprites take five, and the remaining two are for layer 2 and 3. Memory full!

Flipping, well yes. So each item has a bit that says 'facing left or right'. If you flip it, the engine makes sure the sprite is flipped horizontally (by using the alternate block set and reading the animation maps from right to left).

Would you be willing to reveal the complete story line you had intended for Core Dump? (Or publish it in a PDF some time; heck, I think I'd even buy the book! )

@auroramsx: you spotted the similarity, indeed. Well, these were the first tests we ran: the gallery contains few pictures of the final version, and the part you mentioned was later changed to more inspired original work

About the storyline, well, maybe I'll look up what's left sometime. But it was fairly intricate and I cannot remember all the details I had in my. Mind you, it was a fairly dark storyline, turning the humans into the 'evil' force.

Well, allright then, I've got a little present then. I've relocated the Blade Lords beta: I made this more than five years ago in 2001, and never finished it, because I started my phd. However, it works online in Flash 5, and it's even twoplayer... on the same keyboard, that is. It's much like the MSX version with the one-button option for the joystick. Hope you enjoy the bits that work:

games.shape9.nl/bladelords/beta

login: msx
password: nostalgic

Mind you, I found programming an MSX easier than Flash 5, but hey, I heard they made it easier now. It was a fun experiment.

ps. I don't think the downloadable wallpapers work, don't know why.

hey parallax, don't you worry, you made perfectly clear you're no longer motivated for active MSX development. It's just cool hunting down abandoned MSX projects which might become open source in the near future. Chances are these kind of games will see daylight after all. If CD data from the crashed HD can be retrieved....well.......who knows ^_^