40 YEARS AMSTRAD MINI DEMO

[krusty_benediction]

Hi, we've just released Come join us.

The aim of this intro was to advert the "40 YEARS AMSTRAD MINI DEMO" I plan to collectively do and release at revision 2025.

Recap of text written in it.

Code Select Expand

THIS IS THE CALL FOR THE 40 YEARS AMSTRAD MINI DEMO.
A 4K FOR REVISION 2025.
1024 BYTES RESERVED FOR THE DEMO SYSTEM, MUSIC, SHARED DATA.
512 BYTES MAX PER GROUP AFTER COMPRESSION.
AT LEAST 6 SLOTS AVAILABLE!
SELECTION WILL BE BIASED TOWARDS OLDISH SCENERS!
KRUSTY.BENEDICTION@GMAIL.COM FOR DETAILS AND CONSTRAINTS.

we can also use this thread to exchange.

10 years ago, I handled the 30 Years Amstrad Megademo that was a project of several orders of magnitude of complexity.
So I can be trusted to handle that (as soon as there are participants ).

I have not yet decided the rules, I prefer first to exchange with potential participants to gather information of interest. But keep in mind, such project cannot be handled in a democratic way anyway.

What is settled now:
- The target is Amstrad CPC 6128 and must run on CRTC 0, 1, 3, 4. It is great if it can work on CRTC 2.
- I reserve 1024b for the demosystem (amsdos header , common routines and data, music if any). No problem to delegate its creation to someone else
- Only 512b maximum per participant (1 participant = 1 group, not 1 individual) after compression
- If a participant uses less than 512b, I'll choose how to use it (for the demosystem, or an additional participant)
- The number of participants is limited for the 4k constraint, so selection need to be made. I will favor old groups that have already contributed to the scene to newcomers. Participants not accepted to the 30YAM are welcomed.
- Consistency is the key to have a good show. You have to accept to stick to the rules, their potential modifications (timing, palette, ...), and modification requests of your part to commonly build a coherent 4k show.
- Revision 2025 is the hard deadline. If a participant behaves in a way that makes it impossible to release the demo for revision 2025, its part will not be included.
- 1 part = 1 assembly program. You can use any assembler, but have to provide me the binary and the sources (I may have to reassemble myself), eventually the assembler and various tools needed to build the demo. On my side I'll build the demo with my own assembler and toolchain https://cpcsdk.github.io/rust.cpclib/
- sources will be released

Things not settled yet:
- If each part HAVE TO call a routine every FRAME (even during initialization). It is highly probable you will have to do that
- How to handle CRTC compatibility ? I am in favor of assembling one version of the 4K per CRTC to remove all CRTC detection code and adaptation. (so the 512 bytes size constraint would apply on ALL variants, if any)
- the memory constraints (what you have to not touch). It is safe to consider you cannot access at all the extra banks
- How the parts are launched: a menu and parts need to go back to the menu ? Something  sequential, with or without interaction ? Something hybrid between them ?
- If we have a single music for the whole show or if any participant does as it wants (ie plays it's music or a default one of the demosystem). It is highly probable that you will have to use a common music for the sake of consistency (THIS HAS AN IMPACT on avaialble time for the demo; the probability to have a constant player is really low)
- how/when parts are uncrunched ? as a whole ? at their use ? Which cruncher ? (shrinkler is great but decompressor is huge and would have to be modified to work under interruption)

I will not look daily to this thread. I'll do my best to do it weekly

[PulkoMandy]

Interesting idea!

If the goal is a total size of 4K, you probably win a lot of space if you crunch it all together instead of each part separately. But it becomes difficult to measure if each part is 512 bytes crunched, or more. Parts added later will compress better than the previous ones since they can reuse the existing decompressed data. And, maybe the uncrunched version will not fit in RAM if someone does something crazy?

I think it makes sense to have each part shown one after another without a menu. Unless someone really wants to do a menu part?

I also have a question. Will the firmware be available? I used it for some sizecoding things I did (floating point math, PSG register writes or even ENV/ENT for music player, slow dots drawing, ...)

[krusty_benediction]

1- I think I'll check the limit of the parts by compacting them alone. But it does not when they will be compacted alone in the final product
2- I think that to store the parts (either crunched/uncrunched) in memory banks avoid such issues. I'm pretty sure some extra constraints in main memory will be needed. But we'll see one time depending on an what potential participants suggest
3- yep. With a menu it is more acceptable that have something not homogenous between the part. Without a menu, it is unacceptable Menu can be fake too (i.e. controlled automatically, not by a human).
4- sure it is possible to have the menu part as one of the available slots
5- For sure firmware will not be available during part execution, it would constraints too much the 4k. The demosystem will have access to the firmware and can execute code (that count in the limitation of the part if only this part use it) during the initialization.
The demo system will provide utilities function to generate data (but it only depends on what participants requests, space available and so on)
So it is a good idea to share artifacts between the parts from the demosystem.
 

[krusty_benediction]

Oh and the 4k will be released under the label "CPC". The signification is not yet fixed

- Coders Praise CPC
- Collective of Persons loving Crocodiles
- CPC porn collective
- ...

[Deevee]

Coders Prefer Crocodiles

[krusty_benediction]

1st draft of the demo workflow. To be updated depending on your remarks

Code Select Expand

1. User types: RUN"40ymd (or whatever will be chosen at this time) to load and start the demo

2. Bootstrap uncrunches the whole binary in whole bank 0xc7. Finger crossed it will not be bigger
3. Bootstrap makes some init for demo system using firmware (common curves ? chars retrieval ? XXX need to be defined)
3. For ech part p
 3.a Bootstrap copies p in main memory
 3.b Bootstrap calls init1 of p. Can use firmware if needed
 3.c init1 will never be reused again. This memory could be used for data for p
 3.d if needed (but for ALL parts) bootstrap copies p in demosystem memory

4. Boostrap kills the system and copies the jumpblocs in main memory
5. For each part p
 5.a Demo system copies p in main memory
 5.b Demo system calls init2 of p. Firmware cannot be used.
    If agreements have been made between groups, init2 of p can read private data of other groups computed at init1 to generate its own init2 data (for curve or stuff like that)
 5.c init2 will never be reused again. This memory could be used for data storage for p
 5.d if needed (but for ALL parts) demo system  copies p in demosystem memory
6. Demo system inits the music player under interruption

7. For ever
  7.a For each part p
  7.a.1 Demo system copies p in main memory
  7.a.2 Demo system jumps to the load address + 6 of part p
  7.a.3 Part p does its inits (crtc with proper transitions/ga/...)
  7.a.4 For each frame
      7.a.4.a Part p calls the demo system heart beat
   7.a.4.b Part p checks if it has to leave
   7.a.4.c If it times, part p does its cleaning and request a part change
  7.a.5 if needed (but for ALL parts) demo system  copies p in demosystem memory


[Targhan]

Interesting, count me in. I thought we were going for 256 bytes per entry, though.

[krusty_benediction]

@Targhan sure, if 512 bytes is too large, for sure you can use 256 bytes and provide the remaining space to someone else. But keep in mind that in such project you lost space by using demosystem routines and mainly by writting crtc / color transitions that would not exist in a single 256 bytes demo

I expect to have time in the next days/weeks to finalize a proof of concept of the demosystem with 2 fake parts. It will ease discussions