SpritesMind.Net

Hi,

We started this topic long time ago at Devega board.
Like many others, I found the idea of the demo very interesting

However!

I think we should use a rom header ( that hold the music engine & track) of, lets say 256KB. This rom header can reroot hint and vint using vectors in ram to each demo.
Each time a part of the demo is finished, it jumps inside the header

It would be great to define the part-size (was 256KB?) and define the location of each entry (so we can parameters our complilators to the correct adresses).

We should also define who's gonna to code the header and what kind of music we should use

-----------------
Ho, and all over the top, what about the théma of the demo? héhé, global thema? Individiual théma?
We have until 2008 to decide

is it a games rom or demos rom ? how about "Megadrive 20th year anniversary" as the theme :p

Great idea, but I didn't quite understand how you put all the demos together and switch between them. I have some small demo ideas in my head waiting to be realized...

Pascal> yeah, good thema idea.. It must be a demo rom I mean, everybody do a little screen with impressive things and we put all together .

"Great idea, but I didn't quite understand how you put all the demos together and switch between them. "
For exemple, if each demo have a limit of 256KB, we just group them all in a rom (compilating each one to good rom value of course) and we have a master rom header that jump on them one by one

Unfortunately, it would disable any BasicEgaZorg or SGCC entries, unless we find a nice trick.

The other method would be to use a bankswiching mecanism, but it require a specific hardware...

Fonzie wrote: Unfortunately, it would disable any BasicEgaZorg or SGCC entries, unless we find a nice trick.

That's for gays so we don't care

So we're doing 100% ASM stuff like I am ?
On HW it is quite simple to implement bank switching (I'm little into digital electronics). However, I have no big enough EPROMs and suitable Flashes are hard to get (for me) .
Maybe modify KMod to get suitable bank switching technique or something ?

I just got a great HW idea !!! First 256KB are SRAM based, in there you write a small routine which is copied to main RAM and which fills the SRAM with next 256KB ROM blockwhere demo is contained, however it requires that demo has the same routine in the end which copies next demo. If writes in ROM area are allowed on emulators, you will not need to build HW.

Yeah, nice idea... It would require to leave the 4 first word as rom (to have the power on /reset vector running from rom).
However, i checked, emulators don't support so big SRAM...
Or maybe i did something wrong.

As for basicegazorg and sgcc, maybe padding the rom header to the correct rom location would work...

I'm going to code in C, kaneda fr and pascal maybe too
But with XGCC, we can do watever we want, no problem around the rom mapping.

I think that having a bankswiched hardware or any "non reporducible" feature is to avoid for now... better find a method that is just plain rom.

well the easiest is to define which part of the ram gonna be available (so people doesn't override the reserved interrupts handlers,..., and make a 256k limit for every entries. After we give a rom slot to the coder with the starting address you'll need to compile with (just a org in asm, in XGCC linkscript) , so only a jump gonna be mandatory.

Emus support sram at addresses $200000 to $3FFFFFF, but only if you have written 1 to a reg in MD. My idea works on real HW (I have tested it on my SRAM cart) and you don't have to modify your rom in anyway.
But Pascal's idea is actually the best, whose gonna write a demo (need to make a list so everyone knows which ROM slot he/she has) ?
I'm in for sure !!!

music?

"Emus support sram at addresses $200000 to $3FFFFFF, but only if you have written 1 to a reg in MD"... I see, long time ago, i tried to create a sram of 1MB and it failed... 16KB worked, so

"music?"
You want to code the music part sergeeo?

I'll enter too. It will be hard to make my plan fit in 256KB but its challanging anyway.

I'm not a coder myself, but I can try composing something with MML.

Do you want an oldskool-style demo where you merely go from one part to the other in a predetermined order, or one with a menu that allows you to choose the part you want to watch? I'd almost prefer the former, but either way works for me. Neither way should be that hard - if you allocate up to 256KB per part, then for the oldskool way simply call the next part (which can start at the beginning of each 256KB block since there's no need for multiple headers). As was said, you can vector the interrupt handlers through RAM (basically, have a jmp $FFFFxxxx in the handlers, and at the desired RAM addresses simply put a jmp $whatever, which can then be changed by each part to point to it's own interrupt handlers).

Although I'm liable not to use interrupts at all, anyway - my part would be oldskool C64-style, and so I don't really need them - it's sufficient to just busywait until the desired scanline.

I think it would be interesting to do something like Cascade Cassette 50.

http://www.mobygames.com/game/zx-spectrum/cassette-50

There's also a remake of the games in the works:
http://www.rewindmag.co.uk/issue1/featu ... te50_3.php

Maybe the games from the original could be remade for the Genesis/Sega CD. Each one should easily fit within the shared ram of the Sega CD.

I have the Spectrum, BBC A/B, Electron, and C64 versions. I'm still looking for the CPC, ZX-81, and Dragon 32/64 versions.