Poking the display file...?
Poking the display file...?
This is something I've done extensively on the Spectrum - starting with playing around with the attributes, then the bit that actually writes to the screen, and finally manipulating it in a way that's really useful - such as, being able to hard-invert a character square, followed by its attributes, in a screen that BMP2SCR has produced. This has been incredibly useful in my initial foray into machine code, since New Generation Software's tutor program mostly used the attibutes block to show what a simple machine code program would actually do.
Before I knew it I'd written a program to fill the screen with random shash (INPUT area and all), and then made a better version when I discovered the random-ish refresh register and the LDIR instruction.
So I thought... why not try it on the ZX81 and see what happens?
I'll start with BASIC. Oh, wait... the display file isn't in a fixed position. Still, no biggie, there's bound to be a system variable to tell me where it is - D_FILE, two bytes at 16396, all well and good.
10 LET DF=PEEK 16396+256*PEEK 16397
20 PRINT DF
...16550, I see. Right...
20 POKE DF,0
...what's happened to the screen? Why is it flipping around like that? It's crashed anyway, so I'll try again, something slightly more ambitious, and I'll move it a line down, just in case...
10 LET DF=PEEK 16396+256*PEEK 16397
20 FOR N=DF+32 TO DF+63
30 POKE N,13
40 NEXT N
What I'd expect was row 1 to be filled with CHR$ 13 (a dollar sign). Instead, the last three squares of the top row were filled with dollars, followed by all but the last five squares of row 1 - when 32 characters should at least make a complete line. Or at least, that's what it looked like initially. On a loser look, the first of the three characters on the top line had PRINTed AT (0,31), and the other two had spilled off the edge into where the border would be if this was a Spectrum, which is isn't. It reached the 0/40 report fine, but then the text of the program went mad again.
Either:
(1) There is a lot more to the ZX81 display file than meets the eye.
Or:
(2) EightyOne isn't quite the all-singing-all-dancing emulator I thought it was.
As the Mitchell brothers from 'Stenders would say: "Woss ga'in on?"
Before I knew it I'd written a program to fill the screen with random shash (INPUT area and all), and then made a better version when I discovered the random-ish refresh register and the LDIR instruction.
So I thought... why not try it on the ZX81 and see what happens?
I'll start with BASIC. Oh, wait... the display file isn't in a fixed position. Still, no biggie, there's bound to be a system variable to tell me where it is - D_FILE, two bytes at 16396, all well and good.
10 LET DF=PEEK 16396+256*PEEK 16397
20 PRINT DF
...16550, I see. Right...
20 POKE DF,0
...what's happened to the screen? Why is it flipping around like that? It's crashed anyway, so I'll try again, something slightly more ambitious, and I'll move it a line down, just in case...
10 LET DF=PEEK 16396+256*PEEK 16397
20 FOR N=DF+32 TO DF+63
30 POKE N,13
40 NEXT N
What I'd expect was row 1 to be filled with CHR$ 13 (a dollar sign). Instead, the last three squares of the top row were filled with dollars, followed by all but the last five squares of row 1 - when 32 characters should at least make a complete line. Or at least, that's what it looked like initially. On a loser look, the first of the three characters on the top line had PRINTed AT (0,31), and the other two had spilled off the edge into where the border would be if this was a Spectrum, which is isn't. It reached the 0/40 report fine, but then the text of the program went mad again.
Either:
(1) There is a lot more to the ZX81 display file than meets the eye.
Or:
(2) EightyOne isn't quite the all-singing-all-dancing emulator I thought it was.
As the Mitchell brothers from 'Stenders would say: "Woss ga'in on?"
Spectribution: Dr. Jim's Sinclair computing pages.
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!
Re: Poking the display file...?
Yes, EO is too complicated to run a simple program!
Have a look to "Your Computer" 's program example:
Code: Select all
1 REM P.B.
20 PRINT "SURROUND"
30 INPUT D$
40 CLS
100 FOR I=VAL"1" TO VAL "10"
110 PRINT "««««««««««"
120 NEXT I
130 LET Q=PEEK VAL"16396"+ VAL"256" * PEEK VAL "16397"+ VAL"1"
140 LET T=VAL"0"
150 LET X=VAL"5"
155 LET Y=X
160 PRINT AT Y,X;"*"
165 FOR I=VAL"1" TO VAL"3"
170 LET A=X+INT(RND*VAL"3")-VAL"1"
175 IF A>VAL"9" OR A<VAL"0" THEN GOTO VAL"170"
180 LET B=Y+INT(RND*VAL"3")-VAL"1"
185 IF B>VAL"9" OR B<VAL"0" THEN GOTO VAL"180"
190 IF A=X AND B=Y THEN GOTO VAL"170"
200 PRINT AT B,A;"o"
205 NEXT I
210 INPUT D$
215 IF CODE D$>VAL"36" OR CODE D$<VAL"33" THEN GOTO VAL"400"
220 LET V=X+(D$="8")-(D$="5")
230 LET W=Y+(D$="6")-(D$="7")
240 IF PEEK (Q+V+VAL"11"*W)=VAL"180" THEN GOTO VAL"400"
250 PRINT AT Y,X;"«"
260 LET X=V
270 LET Y=W
280 LET T=T+VAL"1"
290 GOTO VAL"160"
400 CLS
410 PRINT"TIME=";T
420 RUN
The " CHR$ 0 " character is a space!
And you had to preserve the video RAM structure integrity.
Code: Select all
[D_File]
[128] ; = New/line
[char 1] ; @ 0,0
[...]
(char 31] ; @0,31
[128] ; = New/line
Line 2 ;
[char 33] ; @ 1,0
[...]
[...]
(char 23x33] ; @23,33
last char.
[128] ; = New/line
On all Zx81 or TS1000 below 2K, this rule can't be use.
The D_file don't reserve a fix memory room (24x32 chars), but place a N/L char after the last character in a line.
It's a floating screen length…
To POKE directly on the D_File, you had to set the RAMTOP to the 16k configuration ($7FFF, or above $4800).
1-2 K bytes:
16 k bytes: Note: In 16k, the length line can be set by everywhere 0-32 to keep memory, or speed up display…
But, 32 characters isn't the maximum column displayable!
You can extend the video to 34x24 instead of 32x24...
Just add 2 characters in a line, before the 128 ($76) New/line.
But, a CLS will back to 32x24...
Xavier ...on the Facebook groupe : "Zx81 France"(fr)
- 1024MAK
- Posts: 5145
- Joined: Mon Sep 26, 2011 10:56 am
- Location: Looking forward to summer in Somerset, UK...
Re: Poking the display file...?
ZX81 Variations
ZX81 Chip Pin-outs
ZX81 Video Transistor Buffer Amp
Standby alert
There are four lights!
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer later in the year.
ZX81 Chip Pin-outs
ZX81 Video Transistor Buffer Amp
Standby alert
There are four lights!
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer later in the year.
Re: Poking the display file...?
I did go back to it for a bit and instead of POKEing DF to DF+31, I tried DF+1 to DF+32 and that did what I want and didn't crash. Then I tried DF+2 to DF+33 and that did crash after spilling over to the next line, so that explained a fair bit.
If it helps, I was in 16K mode all the time. Trying to cram everything I need to do into 1K isn't an experience I'm keen to repeat (after 33 years away from that!) - and the real hardware I have now has inbuilt 16K so I never need to worry about that (or a minor earthquake).
Once I get a BASIC program that POKEs 22x32 characters to the screen and doesn't crash, I'll see about translating it into machine code. At some stage I should be able to make it fill the screen with random ROM graphic characters to simulate a load of random PLOTs (though not using the dithered graphics A-H).
I'll have a use for it some day!
If it helps, I was in 16K mode all the time. Trying to cram everything I need to do into 1K isn't an experience I'm keen to repeat (after 33 years away from that!) - and the real hardware I have now has inbuilt 16K so I never need to worry about that (or a minor earthquake).
Once I get a BASIC program that POKEs 22x32 characters to the screen and doesn't crash, I'll see about translating it into machine code. At some stage I should be able to make it fill the screen with random ROM graphic characters to simulate a load of random PLOTs (though not using the dithered graphics A-H).
I'll have a use for it some day!
Spectribution: Dr. Jim's Sinclair computing pages.
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!
Re: Poking the display file...?
So, a BASIC version of this was fairly straightforward, in the end:
10 LET D=PEEK 16396+256*PEEK 16397
20 FOR N=1 TO 760 STEP 33
30 FOR M=0 TO 31
40 POKE D+N+M,13
50 NEXT M
60 NEXT N
However, my machine code equivalent wasn't so successful. As far as I know I am running the exact equivalents of all the processes of the BASIC program, but it fails. It doesn't crash, it stops after printing one dollar sign and gives error C/0 - even though there's not a VAL to be seen!
Seeing as I only have an external assembler for the Spectrum, I tried the same routine (assembled at 60000 and starting with ld hl,16384 rather than the absent D_FILE) so it would print 32 broken lines (00001101) followed by steeping over the next byte, and do that 24 times. It worked fine.
Where is the ZX81 error coming from?
Here's the code:
Once I've got this going, I can think about a routine to select random selections of the chessboard characters.
Also an external assembler for the ZX81 would be handy...
10 LET D=PEEK 16396+256*PEEK 16397
20 FOR N=1 TO 760 STEP 33
30 FOR M=0 TO 31
40 POKE D+N+M,13
50 NEXT M
60 NEXT N
However, my machine code equivalent wasn't so successful. As far as I know I am running the exact equivalents of all the processes of the BASIC program, but it fails. It doesn't crash, it stops after printing one dollar sign and gives error C/0 - even though there's not a VAL to be seen!
Seeing as I only have an external assembler for the Spectrum, I tried the same routine (assembled at 60000 and starting with ld hl,16384 rather than the absent D_FILE) so it would print 32 broken lines (00001101) followed by steeping over the next byte, and do that 24 times. It worked fine.
Where is the ZX81 error coming from?
Here's the code:
Code: Select all
ld hl,(D_FILE)
ld a,24
loop1:
ld b,32
loop2:
inc hl
call shash
djnz loop2
inc hl
dec a
jr nz,loop1
ret
shash:
ld (hl),13
ret
Also an external assembler for the ZX81 would be handy...
Spectribution: Dr. Jim's Sinclair computing pages.
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!
Features my own programs, modified type-ins, RZXs, character sets & UDGs, and QL type-ins... so far!
Re: Poking the display file...?
Code: Select all
10 LET D=PEEK 16396+256*PEEK 16397+1
Code: Select all
;------- TASM ASM mnemonics. -------
; Compile this file using:
; Set TASMOPTS = -b
; tasm -80 ThisCode.tas MyBinary.BIN
;-----------------------------------
; Zx81 Program name: VB81 XuR [FILL.P] :
; REM line name: 1 REM: 17 Bytes@4082-4092
#define ORG .org ; TASM cross-assembler definitions
#define equ .equ
;-----------------------------------
;------------------------------------
;-Basic sub-routine entry. -
;+----------------------------------+
; Lb4082 ; <- USR Basic Enty.
;+----------------------------------+
ORG $4082 ; [@16514/@h4082]
Lb4082: ; <- USR Basic Enty.
LD C,$16
Lb4084:
LD B,$20
LD A,$80
Lb4088:
RST 10H ; Display= A reg.
DJNZ Lb4088 ; [$4088:16520]
LD A,$3B
RLA
RST 10H ; Display= A reg.
DEC C
JR NZ, Lb4084 ; [$4084:16516]
RET ; ==========================
.end
Code: Select all
ld hl,(D_FILE)
INC HL ; D_FILE=D_FILE+1
ld a,24
Xavier ...on the Facebook groupe : "Zx81 France"(fr)
Re: Poking the display file...?
What do you mean by external assembler?
Or I use Tasm on Dosbox.
There’s also a full ZX81 IDE for Windows, but I haven’t tried that.
- Assembler on your ZX81?
- Assembler on an emulator?
- Assembler on a pc for the ZX81?
- Assembler on a pc with debugger?
Or I use Tasm on Dosbox.
There’s also a full ZX81 IDE for Windows, but I haven’t tried that.
Re: Poking the display file...?
DON'T DESTROY THE D_FILE:
.ORG 16514
ld hl,($400C)
ld c,24
loop1:
ld b,32
loop2:
inc hl
ld a,118
cp (hl)
jr z,loop2
call shash
djnz loop2
inc hl
dec c
jr nz,loop1
ret
shash:
ld (hl),13
ret
.end
Code: Select all
1 REM [HEX:\
2A,0C,40,0E,18,06,20,23,\
3E,76,BE,28,FA,CD,99,40,\
10,F5,23,0D,20,EF,C9,36,\
0D,C9 ]
10 LET D=PEEK 16396+256*PEEK 16397+1
20 FOR N=1 TO 760
40 IF PEEK (D+N)<>118 THEN POKE D+N,13
60 NEXT N
Xavier ...on the Facebook groupe : "Zx81 France"(fr)
Re: Poking the display file...?
After hitting my head on this problem all day, I found the solution. Display memory wasn't there and my poke's were overwriting bytes beyond it.
The solution explained here should work for systems with 8K RAM or more.
From the ZX81 User's Manual:
In my case it was the TASM32 template I started to code with. In that template the screen was defined at the bare minimum size, like this:
I solved this problem by changing the Display definition in my source code to this:
Or you could put your own characters in place of the zeroes, making the playfield image visible just after tape load.
Doing this the .P image will be bigger (by 768 bytes, that won't be a problem), but the real drawback is that the program won't run on a minimum 1K RAM system (I didn't try), I think it'll need at least 16K.
Happy coding!
The solution explained here should work for systems with 8K RAM or more.
From the ZX81 User's Manual:
Before you attempt to put values in the display memory, make sure it's allocated correctly.When the total amount of memory (according to the system variable RAMTOP) is less than 3 1/4 K, then
a clear screen - as set up at the start or by CLS - consists of just twenty five NEWLINEs. When the
memory is bigger than a clear screen is padded out with 24*32 spaces & on the whole it stays at its full
size; SCROLL, however, & certain conditions where the lower part of the screen expands to more than two
lines, can upset this by introducing short lines at the bottom.
In my case it was the TASM32 template I started to code with. In that template the screen was defined at the bare minimum size, like this:
Code: Select all
Display: DEFB $76 ; Newline
DEFB $76 ; Line 0
DEFB $76 ; Line 1
DEFB $76 ; Line 2
DEFB $76 ; Line 3
... etc
Code: Select all
Display: DEFB $76 ; Newline
DEFB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,$76 ; Line 0
DEFB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,$76 ; Line 1
DEFB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,$76 ; Line 2
DEFB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,$76 ; Line 3
... etc
Doing this the .P image will be bigger (by 768 bytes, that won't be a problem), but the real drawback is that the program won't run on a minimum 1K RAM system (I didn't try), I think it'll need at least 16K.
Happy coding!
Re: Poking the display file...?
Almost true.
It can corrupt the display and most likely will crash when the screen can't finish the display with just characters and start executing code. Most likely when you don't have 25 linefeeds as a screen anymore.
However......
there is a trick to even compress a compressed screen. Most of my 1K lowres games (if not all) have a #E9-opcode (JP (HL) ) as final byte on the screen. Even with less than 25 linefeeds the display will finish in a correct way.