News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_krusty_benediction

40 YEARS AMSTRAD MINI DEMO

Started by krusty_benediction, 12:05, 31 March 24

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

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.

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
ORIGIN 320,200:FOR r=1 TO 360:PLOT 5*(16*(SIN(r))^3),5*(13*COS(r)-5*COS(2*r)-2*COS(3*r)-COS(4*r)):NEXT

krusty_benediction

1st draft of the demo workflow. To be updated depending on your remarks
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.
Targhan/Arkos

Arkos Tracker 2.0.1 now released! - Follow the news on Twitter!
Disark - A cross-platform Z80 disassembler/source converter
FDC Tool 1.1 - Read Amsdos files without the system

Imperial Mahjong
Orion Prime

krusty_benediction

#7
@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

krusty_benediction

Update of the current status.

It is too soon to share the demosystem, I won't work on it for 1 or 2 weeks, but it is on a good way. 

It is currently able to
- play the music on request of the participant
- play the music automatically thanks to interruptions
- install and launch the next part upon request of the participant
- loop indefinitely (ATM it plays a single fake part a while, and reinstall and play it for always)
- request the participant to stop its part and launch the next one
- wait the vsync upon request of the participant
- select a memory configuration 0xc0/0x4/0xc5/0xc6/0xc7 upon request of the participant (the demo system requires 0xc1 at the moment)

Next step before sharing everything and allow participants to play with will be to :
- handle complex init of the parts before the start of the very first effect
- double check that the switches from/to interrupted music/manual music work perfectly (I need to write another fake demo part for that)
- crunch the demo and analyze the size of various components (I currently work with a snapshot where nothing is crunched), write the linker/loader that plays the demo properly
- create a bundle to allow the participants to code their effects using the demosystem

I would say the next update will be in less than one month, with all previous points already handled.

After that, I will have to
- handle the utility functions requested by participants
- fix remaining bugs in the demosystem or my toolchain to build it
- simplify the demosystem to make it crunch better
- set up hard deadlines and rules for the participants


krusty_benediction

I have finally been able to find some time to work on this project. The following tasks are then completed


Thanks to bndbuild, I'm already able to build a dsk with the demo crunched and a fake part.
It will be almost free for me to add new parts.

I have not yet worked on the task
  • create a bundle to allow the participants to code their effects using the demosystem
that is a prerequisite to allow you to work on your side

As a first view, I have clearly underestimated the size of the demosystem and the music. The current test music is already a bit more than 1kb which is already larger than what I initially allowed to the demosystem + music.
For sure final music will be smaller, i'll be able to earn plenty of bytes on the demosystem too, but i may never be able to reach this 1kb limitation (so the limit of 512 bytes per part is for sure too large to allow many participants).


krusty_benediction

Et voilà

first proof of concept of the demo playing 2 parts that seems to not have big bugs.
I have not yet worked on the bundle to help participants to code and test their part, but I have made some data reorganization to ease that.

Here is the code of the two fake parts (using basm, but I'll provide necessary for standard assemblers)

part1

;;
; Example of simple part that relies on the demo system and it s automatic music play
; No init are used for this part
;
; Of course parts can be written with any assembler as soon as the API contracts are respected.
; I'm pretty sure my files are rasm compatible


include "demosystem/public_macros.asm"
include "contract/part1.asm"

org PART1_LOADING_AREA

;;
; Each part must start with these 3 jump blocks
; So systematically 6 bytes that compress badly are lost
; In case no init is used, set the address to demo_system_address_of_a_ret
part1
dw init_assets_with_firmware  ; System has not been killed yet, it is then possible to use it to build/compute stuff
               ; this is called one time just after deo launched
dw init_assets_without_firmware ; Some other init may prfere a killed system.
                                ; it is better to lost 3 bytes rather than plenty more by saving firmware state
dw play_part ;

;;
; First stage init.
; Print a string using the firmware
init_assets_with_firmware
ld hl, .txt
.loop
ld a, (hl) : inc hl
or a : ret z
call 0xbb5a
jr .loop
.txt db 12, 10, 10, 10, 10, 10, 10, 10, 10, 10, "Part 1 uses firmware in first init stage, then clears some screen area in second stage. It's effect only consists in writting random bytes in the first 256 bytes of screen. Music is played under interruption by the system."
   db 10, 13
db 0

;;
; Second stage init.
; Clear some bytes on screen
init_assets_without_firmware
ld hl, 0xc000 + 80 * 5
ld de, 0xc000 + 80 * 5 + 1
ld bc, 256
ld (hl), 255
ldir
ret



;;
; A fake part that write random things on memory screen
play_part
; todo register a gunction to leave properly

; just a garbage effect to verify we loop and play the music
ld hl, 0xc000
.frame_loop

ld b, 50
.code_loop
ld a, r
ld (hl), a
inc l
djnz .code_loop

; Only a limit amount of  frames is allowed (init included)
; so we loop only if the system gives the authorization
DS_CHECK_IF_MUST_LEAVE (void)
jp nz, .frame_loop

.leave
; cleanup the mess
ld hl, 0xc000
ld de, 0xc000 + 1
ld bc, 256
ld (hl), l
ldir

if 0

; lost lots of time to see the screen cleanup
ld b, 50*3
.slow_down
push bc
DS_WAIT_VSYNC (void)
halt
halt
pop bc
djnz .slow_down
endif


; music is already under interruption, so there is no need to activate it again
DS_LAUNCH_NEXT_PART (void)




part2
;;
; Example of part that
; - does some inits
; - manually plays the music
; - make use of the data space in the banks
;
; Of course parts can be written with any assembler as soon as the API contracts are respected.
; I'm pretty sure my files are rasm compatible


include "demosystem/public_macros.asm"
include "contract/part2.asm"


org PART2_LOADING_AREA

FOREVER_VARIABLE_SPACE equ PART2_AVAILABLE_MEMORY_SPACE_FIRST_BYTE
VARIABLE1_RELATIVE_POSITION equ 0 ; a word that change over time
VARIABLE2_RELATIVE_POSITION equ 2 ; a byte to chose the palette

;;
; Each part must start with these 3 jump blocks
; So systematically 6 bytes that compress badly are lost
part2
dw init_assets_with_firmware ; System has not been killed yet, it is then possible to use it to build/compute stuff
               ; this is called one time just after deo launched
dw init_assets_without_firmware ; Some other init may prfere a killed system.
                                ; it is better to lost 3 bytes rather than plenty more by saving firmware state
dw play_part ;

;;
; the part uses the firmware for some init stuff
init_assets_with_firmware
; some fake data storage to test memory access
ld bc, 0x7f00 + PART2_DATA_BANK : out (c), c

ld hl, 0xdead
ld (FOREVER_VARIABLE_SPACE + VARIABLE1_RELATIVE_POSITION + 0), hl

ld bc, 0x7f00 + 0xc0 : out (c), c

ld hl, .msg
.loop
ld a, (hl) : or a : ret z
inc hl
call 0xbb5a
jr .loop
.msg db 10, "Part 2 uses system and write 0xdead in its dedicatd space during init 1, then 0xbeef in init 2. The effect continuously changes these values one time per call. Music is manually played and its duration is shown. Persistent memory is used to count the number of runs and select the palette", 0

;;
; This init is done when firmware is not used
init_assets_without_firmware
assert $<0x4000

; Some fake data storage to replace the previous one
ld bc, 0x7f00 + PART2_DATA_BANK : out (c), c
ld hl, 0xbeef
ld (FOREVER_VARIABLE_SPACE + VARIABLE1_RELATIVE_POSITION + 0), hl
ld bc, 0x7f00 + 0xc0 : out (c), c


xor a
ld (FOREVER_VARIABLE_SPACE + VARIABLE2_RELATIVE_POSITION ), a

assert $<0x4000
ret

play_part
.init
; play with the data stored
DS_SELECT_BANK PART2_DATA_BANK
ld hl, (FOREVER_VARIABLE_SPACE + VARIABLE1_RELATIVE_POSITION + 0)
inc (hl)

ld hl, (FOREVER_VARIABLE_SPACE + VARIABLE1_RELATIVE_POSITION + 1)
dec (hl)


; deactivate screen display
ld bc, 0xbc00  + 1 : out (c), c
ld bc, 0xbd00  + 0 : out (c), c

DS_SELECT_BANK PART2_DATA_BANK
ld a, (FOREVER_VARIABLE_SPACE + VARIABLE2_RELATIVE_POSITION + 0)
inc a : and %11
ld (FOREVER_VARIABLE_SPACE + VARIABLE2_RELATIVE_POSITION+0 ), a
DS_SELECT_BANK 0xc0

DS_STOP_INTERRUPTED_MUSIC (void)


; we play the music a bit later than the vsync.
; lets hope this 1/2 hlts of difference do not impact the sound experience
.frame_loop
DS_WAIT_VSYNC (void)

; Get the persistent data
DS_SELECT_BANK PART2_DATA_BANK
ld a, (FOREVER_VARIABLE_SPACE + VARIABLE2_RELATIVE_POSITION+0)
push af
DS_SELECT_BANK 0xc0
pop af


; Select the color according to it
ld d, 0 : ld e, a
ld hl, .raster_table
add hl, de
ld a, (hl)

; play the music using a different color
halt : halt
ld bc, 0x7f10 : out (c), c
out (c), a
DS_PLAY_MUSIC (void)
ld bc, 0x7f10 : out (c), c
ld bc, 0x7f40 : out (c), c
halt
ld bc, 0x7f54 : out (c), c


; Only a limit amount of  frames is allowed (init included)
; so we loop only if the system gives the authorization
DS_CHECK_IF_MUST_LEAVE (void)
jp nz, .frame_loop

.leave

; reactivate screen display
ld bc, 0xbc00  + 1 : out (c), c
ld bc, 0xbd00  + 80/2 : out (c), c


DS_INSTALL_INTERRUPTED_MUSIC (void)
DS_LAUNCH_NEXT_PART (void)


.raster_table
db 0x4b, 0x44, 0x45, 0x44
assert $< 0x4000


krusty_benediction

And I have been finally able to find time to write the kit to allow participants to create and test their part without building the demosystem themselves

Everything is here : https://github.com/rgiot/demo.revision2025.40yo
  • part1 and part2 are two examples of fake parts and their launcher to try them
  • kit contains the binaries of the demosystem
  • source code of the demosystem is in demosystem folder. Feel free to suggest any improvement to reduce its size (after compression)


It's time for participants to signal themselves (there are 2 slots available at maximum) and start to exchange here to finalize the rules.

Regarding the dates, I would say:

- september 2024: participants have a first draft of their part
- december 2024: participants have finalized their part, fixed potential bugs, generate the various binaries for CRTC compatibility, done the homogeneity modifications to have a consistent show
- march 2025: project is cancelled because we have been unable to have a small and nice music and a smaller demosystem everything works fine, 4k is ready to be submited to revision

krusty_benediction

Hi,
I worked a lot on my crossdev toolchain these last months to ease contribution to this project as well as final linking.
As a consequence, native orgams user are now able to work on a part, build it and test it easily.
The only limitation will be to copy paste some demosystem macros when I update them.

The proof of concept source code is here https://github.com/rgiot/demo.revision2025.40yo/tree/main/fake3_orgams/albireo

you need the last version of bndbuild (see https://www.cpcwiki.eu/forum/programming/basm-best-assembler-in-my-desk-room/new/#new) and Linux to build it on a PC.
Otherwhise a CPC is enough. First assemble EFFECT.ASM with orgams, then TEST.ASM to launch it

Powered by SMFPacks Menu Editor Mod