pouët.net

Go to bottom

Multi Scroller Demo by Mad Axe

Multi-Scroller Demo. 
(C) 04.2012

***The demo file:*** MS.P 
Fastloader (for tape users) - MS.WAV
Sources: *.ASM files

DEMO MADE BY Andy Rea
Music by YERZMYEY

A program for any ZX81 16K.
With AY-module in ZonX standard you will also hear the music. 

________________
You can assemble the file 'multiscroll3.asm' with the following 

TASM -80 -B multiscroll.asm MS.P

that will create a self running zx81 .p file called MS.P

the telemark tasm assembler is available online for none comercial use,
you will also need an assembler table that supports the undocumented
instruction of the Z80. Only a couple are used.


FILES in the zip.

MS.P                -the .P file
MS.WAV              -the Fastloading Wav file (uses Szolt's hybrid loader)
multiscroll3.asm    -the main asm file
ReadMe.txt          -this file	
STPLAYMS.asm        -the STC player 
ZX81END.ASM         -include file
ZX81HDR.ASM         -include file
ZXCHARS.ASM         -include file

Regards Andy

A bit about the demo.

'Text only' demo for 16K ZX-81. So why only a text mode ?
Well not all ZX81's have been converted to do Hi-res
graphics so i wanted to try to demostrate that *some*
pixel position manipulation can be possible in text mode
only. The main problem been, that generating text on the
ZX81 is a finely tuned ballet between hardware and
software, during video generation special harware in the
ULA, detects if the memory byte that the CPU is request-
ing during the M1 fetch cycle should be treated as a
video byte, if so then the ULA latches the memory byte
and then forces all the data lines low, the CPU see's the
low data lines and interprets it as a NOP instruction,
during the latter half of the M1 fetch cycle (the refresh
phase) the ULA manipulates the address lines (A0 thru A8)
using bits 0-5 of the byte latched earlier for A3 thru A8
and a special internal counter for A0 tru A2, this inter-
nal counter detemines which of 8 bytes of the character
map data to use for that scanline, the internal counter
is reset by the Vertical syncronisation pulse in the video
signal, and is incremented by the Horizontal pulse in the
video signal, we have no other way to interact with this
counter. It has long been know that we can do a smooth
horizontal scroller 2 pixels at a time ( 1 cpu clock cycle
= 2 pixels ) by manipulating the number of clock cycles
used before *executing* video bytes: so we might add 3
cycles = a shift to the right of 6 pixels, then on the next
frame add 2 cycles = a shift to the right of 4 pixels and
so on, horizontal smooth scrolling made easy... But
vertical smooth scrolling is a little harder, we need to
find a way to reset the internal line counter, which we
know is reset by the Vertical syncronisation pulse, however
on ZX81 the Vsync is under software control :-) so it now
becomes a case of sticking a very short Vsync (11 clock
cycles) into the video signal but there is a catch, it has
to be done during the Horizontal sync pulse or else servere
display disruption occurs, so again we have to time this
short Vsync to happen during a window of just 16 clock
cycles. by adding this trick to the scanline imediatly
before the text lines we can be sure that the internal line
counter is set correctly for the genration of each row of
text. Then the next problem is how do we fit all of this
into the 207 cycles we have for each scanline? of course
it's not calculated on the fly there simply is not enough
spare cpu cycle to do that, so the entire display on a
scanline by scanline basis is calculated before hand and the
address of each succesive scanline is added to a Virtual
machine stack, only just before the video is to be genrated,
when all interrupts are disabled is the SP made to point
at this stack, the first scanline address is popped and
jumped to the rest happens like magic :-) well not really,
but each scanline of data ends with either a RET or a RET Z
(for timing purposes) which will of course return ( or jump
to the next scanlines data) finnally a *real* return address
is on the stack and our code once again take control and
restores the original SP before continuing with normal
code execution. OF course the real trick in this demo is
to have multiple TEXT lines moving at various rates
overlapping at times all without destroying the effect.
Go to top