| Posted By
Murphy
on 2023-10-25
14:20:22
|  Questionmark
| Title: | Questionmark | | Category: | Demo/Trackmo | | Release Date: | 2003-10-25 | | Language: | English | | Size: | 64K | | Device Req.: | Disk only (1 side) | | Machine: | PAL Only | | Code Type: | Machine code | | Distribution: | Freeware |
|  |
|
|
Posted By
Murphy
on 2023-10-25
14:20:22
| Re: Questionmark
Digi music in a demo based on raster effects.
Still hard to believe that this is possible.
|
|
Posted By
BSZ
on 2023-10-25
18:05:49
| Re: Questionmark
@Murphy: I think I'm not telling you any big secret: all timing is connected to everything else. 
|
|
Posted By
gerliczer
on 2023-10-26
06:16:57
| Re: Questionmark
We demand a detailed description of all technical challenges and nuances. Or, as it is called in the scenes related to your activities, a BSZ novel.
|
|
Posted By
Murphy
on 2023-10-26
15:15:10
| Re: Questionmark
@BSZ For an effect this can be done with a bit of work, but for a whole demo it's very hardcore code. 
|
|
Posted By
BSZ
on 2023-10-28
04:18:38
| Re: Questionmark
@Murphy: There is perhaps so much simplification that these effects were designed for this demo. I didn't need to modify ready-made effects.
@gerliczer: I could write a whole book about this, not a novel.
For me, this was the first project that I created entirely with cross-platform tools. There is source code, the compile was done with assembler, run on pc. (One advantage of this is that you know at least roughly when I started coding: the source files have a modification date. ) At that time there was no good emulator available, so the tests were done on a real machine: the pc and the plus/4 were connected by a parallel cable, and the resulting binaries could be "transferred" from the pc to the plus/4 with the appropriate programs. (This setup was so good that I have used the logic ever since, although the hardware has changed in the meantime.)
However, the very first content of the demo is earlier than the first code: it's the digi music itself. (The first codes were write in June 1997.) But this music mix was not actually made for this demo. (The original plan never got beyond brainstorming.) In fact, the music was originally digitized at twice that sampling rate. I was also planning to load the "other half" of the digitization at the end of the demo and switch to double frequency playback. But I didn't get that far.
Perhaps one of the interesting parts of the demo is the music playback. Before that time, the team had made a lot of digi-mixes, which - approximately - playing in the following way: sound samples are typically 4-bit, two of which fit into a BYTE. An interrupt is set, the frequency of which is given by a timer, this is the sampling frequency. This interrupt routine does the following: it reads the BYTE of the next sound sample, decides which 4 bits required, reads the TED register value for this 4 bits from a table, and writes it in to the TED register. It then steps the pointer to the next sound sample. In the meantime, it checks whether the given part of the music has ended. When if finished, it reads the start/length of the next music snippet from the mixing table and sets it. It also sets the sampling frequency of the new music snippet from the same table. (Also, my previous request for the music was that the sampling frequency should not change during the whole music mix. For this reason, frequency switching will not be necessary for this music.) This is complex enough to be included with a raster effect in this form, so a different solution is needed.
All related #1: The sampling frequency of music is not random. It has been selected to be in sync with the machine's display. We've seen music playback where the border color register is changed when the sound register is written: colored rasterlines bounce across the screen. In the synchronized case, you would see the rasterlines blink, but their position on the screen would not change. This is a big help, but the above task running in interrupt is too much. The solution is to take the above interrupt routine out of the interrupt with some modification: the sample-handling code does not write the corresponding register of the TED, but saves the "calculated" register value in a buffer. This "next sample" part of the program must be called as many times in a cycle as there is space in the buffer. The "real" sample-playing interrupt routine can thus be very simple: it reads a BYTE from the buffer, writes it to the TED register, and then increments the buffer pointer. When the end of the buffer is reached, it signals that the next batch of data is required. Double buffering is useful here: when the buffer reaches its end, it switches to the other buffer. And the empty buffer is fillable.
All releated #2: The buffer size is not random. The "round size" (2^n) would be the simplest, but it is not appropriate here. Here, the buffer holds exactly as many sound samples as are needed during one screen display. Thus, the positions at which the sound samples are written to the TED register do not change, and the buffer is always flushed at the same screen position. When the buffer is empty, a routine can be called at any time to reload the empty buffer in one go. (Funnily enough, there is also a "classic raster time" for playing digital music. )
As I remember, the "empty buffer" is currently timed to the top of the screen. The interrupt system is such that it switches the empty buffer to another previously filled one, and then re-enables interrupts (after the appropriate state saving). Here you will call the desired subroutines, including the buffer reloads. This way the whole system runs under interrupt, while the main program can do its own thing, such as loading the next part.
All releated #3: The "buffer empty" is not where it is by random. If there is some effect in the screen, this starts immediately after the "buffer empty" event. In this case, the effect's raster routine is called after the "buffer change". The raster routine then incorporates reading the sample from the buffer and writing the TED register. At the bottom of the screen, call the routines for the effect and the music playback (buffer fill) as above.
That's about the music. In short.
|
|
Posted By
Luca
on 2024-10-25
02:20:53
 | Re: Questionmark
21 years after the release of this fantastic piece of code and art. There was a time when I literaly used to wake up and load it dince the early morning. Absolutely once in a million prod <3
|
|
Posted By
Csabo
on 2024-10-25
10:40:21
| Re: Questionmark
A big 10 from me
|
|
Posted By
BSZ
on 2024-10-25
11:56:29
| Re: Questionmark
@Luca + @Csabo: Thanks!
(A bit funny, but it really got me thinking, so that the final version could be ready for the last Function party in 2023, the 20th anniversary. Of course, if it had been done, you would already know about it. )
|
|
Posted By
George
on 2024-10-25
20:22:08
 | Re: Questionmark
Amazing demo! Impressive music! Well Done!
|
|
Posted By
JimmyCoupe
on 2024-10-26
03:57:03
 | Re: Questionmark
Wow, show this in 1985 and its another story. Super impressive, has Atari ST vibes to the demo. Is that really the TED chip making that sound? amazing.
|
|
Posted By
Lavina
on 2024-10-26
07:28:20
 | Re: Questionmark
One of the (if not the) best trackmos on plus4 among the very few (28 total) ever made.
|
|
Posted By
George
on 2024-10-27
06:09:06
| Re: Questionmark
Tried to load it on an SD2IEC drive yesterday , but seems not to work with it.
|
|
Posted By
gerliczer
on 2024-10-27
06:56:29
| Re: Questionmark
Most of the stuff utilizing fast loaders won't work that way. It is a rare minority that has KERNAL fallback or SD2IEC compatible loader. And this latter is most of the time needs BSZ's VCPU extension for the SD2IEC drive as well as direct support in the programme.
|
|
Posted By
George
on 2024-10-27
11:07:49
| Re: Questionmark
Ok, thank you for the info. Yes you are right, and i forgot about it.
Is a pity, because my Disk-drive is broken and i would like to show some of these marvels on my small Youtube-channel.
|
|
Posted By
BSZ
on 2024-10-27
15:46:05
| Re: Questionmark
@George: These software use special loaders, none of which will work with SD2IEC. Funny, but the SD2IEC didn't even exist when this software was created!
Of course, what @gerliczer wrote is a possible solution, but it is not enough now. But it's not out of the question that I'll make a loader for it one day. 
|
|
| |
Copyright © Plus/4 World Team, 2001-2024. Support Plus/4 World on Patreon |
