Detecting HRG

Discussion about ZX80 / ZX81 Software
User avatar
siggi
Posts: 990
Joined: Thu May 08, 2008 9:30 am
Location: Wetterau, Germany
Contact:

Re: Detecting HRG

Post by siggi »

RWAP wrote:By the way, is there any difference in the requirements for WRX (Wilf's) Hi-Res graphics and those from Matthias?
No, both require a HRG enabled ram (using /RD AND /RFSH to enable the ram for reading) and use a similar hires display routine.
In other words can a program written for WRX (such as ZX4PAINT) work with Matthias's drivers, or do you have to load the WRX drivers?
No. Even when using the same core routines for display, the hrg images are in general located at different locations. And the "library functions" like: "draw a hrg line from here to there" or "set pixel X/Y" (Wilf offers them in the SHREB-package as m/c in program lines 0.., Matthias in his "driver" above RAMTOP) are completely different. So a HRG application must fit exactly to the HRG environment and cannot work easily with another one.

Siggi
My ZX81 web-server: online since 2007, running since dec. 2020 using ZeddyNet hardware
http://zx81.ddns.net/ZxTeaM
User avatar
Forthretro.new.fr
Posts: 32
Joined: Thu Nov 19, 2009 9:34 pm

Re: Detecting HRG

Post by Forthretro.new.fr »

RWAP wrote:By the way, is there any difference in the requirements for WRX (Wilf's) Hi-Res graphics and those from Matthias?

In other words can a program written for WRX (such as ZX4PAINT) work with Matthias's drivers, or do you have to load the WRX drivers?

Rich, honestly, I don't know.

May be Siggi can answer with the following informations :


My Hi-Res for ZX4PAINT is a mix of :
- Pseudo HiRes
- HRG enabled ram.

and is very easy to understand.

A) If we look at the routine and information given by Steven McDonald for his pseudo-Hi Res

http://www.pictureviewerpro.com/hosting ... ighres.txt
, he says :
"As nearly all of the ROM characters have a blank line at the top, the high res
routine changes this to 12 which is at ROM address 3072 ($0C00) which I found contains
much more interesting bit-patterns than other values which can be used."


B)
For the 2 bit x 2 bit I wanted the following somewhere in the ROM:

00000000 = $00 -> 11111111 = $FF
00000011 = $03 -> 11111100 = $FC
00001100 = $0C .....
00001111 = $0F .....
11000000 = $C0 .....
11000011 = $C3 .....
11001100 = $CC .....
11001111 = $CF .....

Helas nor 3072, nor any ROM address had this sequence.

C) The solution was the enabled ram address $2000 and following, where I could put the 8 value.

D) Of course, in 'HRSET' I put A=$20 (for $2000) where Steve put LD A,$0C for address $0C00

E) I had to do another minor change : to save the BC register used by Forth.

F) I did in the RAM a high res display buffer (32 Car * 192 line, address = c_Frames)

;
; -------------
; THE 'HRESGEN' WORD
; -------------
; ( -- )
;
;

c_hresgen:.....LD HL,c_frames - $21 + $8000 ;
..................LD DE,$0021
hresgen3:......DI
..................LD C,$FE
..................LD B,$16
hresgen4:.......DJNZ hresgen4
..................LD B,$C0
hresgen2:.......IN A,(c)
..................OUT ($FF),A
..................ADD HL,DE
..................CALL hresgen1
..................DEC B
..................JP NZ,hresgen2
..................CALL $0292
..................CALL $0220
..................LD IX,c_hresgen
..................JP $02A4
hresgen1:.......JP (HL)
..................RET
;
;
; -------------
; THE 'HRSET' WORD
; -------------
; ( -- )
;
;
cf_hrset:
..................dw c_hrset
c_hrset:
..................PUSH BC ; Save BC
..................HALT
..................LD A,($4034) ; Wait
..................LD C,A ; for the
c_sync1: .......LD A,($4034) ; next
..................CP C ; new
..................JR Z, c_sync1 ; tv frame - used to sync the changeover!
..................LD A,$20 ; -> THIS IS ADDRESS $2000
..................LD I,A
..................LD IX,c_hresgen
..................POP BC ; Retrieve BC
..................JP next ; Return to FORTH

;
; -------------
; THE 'HRRET' WORD
; -------------
; ( -- )
;
;

cf_hrret:
..................dw c_hrret
c_hrret:.........PUSH BC ; Save BC
..................HALT ; Wait for an interrupt - used to sync the changeover!
..................LD A,($4034) ; Wait
..................LD C,A ; for the
c_sync2:........LD A,($4034) ; next
..................CP C ; new
..................JR Z, c_sync2 ; tv frame - used to sync the changeover!
..................LD A,$1E
..................LD I,A
..................LD IX,$0281
..................POP BC
..................JP next ; Return to FORTH
;
;
; -------------
; THE 'HRCLS' WORD
; -------------
; ( -- )
;
;

cf_hrcls:
..................dw c_hrcls ; Indirect address used by FORTH
c_hrcls:
..................PUSH BC ; Save BC ( BC is a Forth Vector)
..................LD HL,c_frames ; c_Frames is HiRes display
..................LD C,$C0
hrcls2:..........LD B,$20
hrcls1:..........LD (HL),$00
..................INC HL
..................DJNZ hrcls1
..................LD (HL),$C9
..................INC HL
..................DEC C
..................JR NZ,hrcls2
..................POP BC ; Retrieve BC
..................JP next
;
;
; -------------
; THE 'POKE ROM' WORD
; -------------
; ( -- )
;
;

cf_montagecar:
..................dw c_montagecar
c_montagecar:
..................LD HL,$2000
..................LD DE,$0008
..................LD (HL), $00.........; 00000000
..................ADD HL,DE
..................LD (HL), $0C.........; 00001100
..................ADD HL,DE
..................LD (HL), $03.........; 00000011
..................ADD HL,DE
..................LD (HL), $0F.........; 00001111
..................ADD HL,DE
..................LD (HL), $C0.........; 11000000
..................ADD HL,DE
..................LD (HL), $CC.........; 11001100
..................ADD HL,DE
..................LD (HL), $C3.........; 11000011
..................ADD HL,DE
..................LD (HL), $CF.........; 11001111
..................JP next ; Return to FORTH


A+ Dominique
User avatar
siggi
Posts: 990
Joined: Thu May 08, 2008 9:30 am
Location: Wetterau, Germany
Contact:

Re: Detecting HRG

Post by siggi »

Forthretro.new.fr wrote: My Hi-Res for ZX4PAINT is a mix of :
- Pseudo HiRes
OK.
- HRG enabled ram.
What is it used for? If it holds the new pattern for Pseudo Hires, it needs to be UDG-enabled ram (see below).
and is very easy to understand.

A) If we look at the routine and information given by Steven McDonald for his pseudo-Hi Res

http://www.pictureviewerpro.com/hosting ... ighres.txt
, he says :
"As nearly all of the ROM characters have a blank line at the top, the high res
routine changes this to 12 which is at ROM address 3072 ($0C00) which I found contains
much more interesting bit-patterns than other values which can be used."


B)
For the 2 bit x 2 bit I wanted the following somewhere in the ROM:

00000000 = $00 -> 11111111 = $FF
00000011 = $03 -> 11111100 = $FC
00001100 = $0C .....
00001111 = $0F .....
11000000 = $C0 .....
11000011 = $C3 .....
11001100 = $CC .....
11001111 = $CF .....

Helas nor 3072, nor any ROM address had this sequence.

C) The solution was the enabled ram address $2000 and following, where I could put the 8 value.
So you use the ram to hold the patterns of a new "character generator", which is normally in ROM. So you want to make UDG in the ram!
But normal ram in a REAL Zeddy is not usable as UDG ram: UDG ram must be connected to the ROM address pins (driven by the ULA), not to the edge connector or to the internal RAM address pins (driven by the Z80).

EO behaves different and IMHO allows to use any RAM as UDG-RAM!!!
That is the reason, why my INTERC-U game (using UDG at $2000) runs in EO, but not on most real Zeddies (except my web-server zeddy :D )

Did you test using a real Zeddy or EO?????
D) Of course, in 'HRSET' I put A=$20 (for $2000) where Steve put LD A,$0C for address $0C00
He took $0C, because this is an address in ROM. Addresses outside in "normal" rams won't work.
Steve says: "Due to hardware limitations, the "I" register can ONLY point into the ROM -
and not RAM (hence the reason for only pseudo high res - sigh!)."

Siggi
My ZX81 web-server: online since 2007, running since dec. 2020 using ZeddyNet hardware
http://zx81.ddns.net/ZxTeaM
Moggy
Posts: 3266
Joined: Wed Jun 18, 2008 2:00 pm

Re: Detecting HRG

Post by Moggy »

"EO behaves different and IMHO allows to use any RAM as UDG-RAM!!!
That is the reason, why my INTERC-U game (using UDG at $2000) runs in EO, but not on most real Zeddies (except my web-server zeddy :D )

Did you test using a real Zeddy or EO????"

Hi Dominique

Tried loading zx4paint on a real zeddy with 32k ram and 8k static ram on a hunter board no joy at all. Like siggi says the ram has to be hi res enabled on the real thing whilst EO "cheats" and allows anything. It would seem that two schools of thought are required when programming one for emulators and one for real machines. :cry: :cry:
User avatar
Forthretro.new.fr
Posts: 32
Joined: Thu Nov 19, 2009 9:34 pm

Re: Detecting HRG

Post by Forthretro.new.fr »

siggi wrote:
Forthretro.new.fr wrote: My Hi-Res for ZX4PAINT is a mix of :
- Pseudo HiRes
OK.
- HRG enabled ram.
What is it used for? If it holds the new pattern for Pseudo Hires, it needs to be UDG-enabled ram (see below).
and is very easy to understand.

A) If we look at the routine and information given by Steven McDonald for his pseudo-Hi Res

http://www.pictureviewerpro.com/hosting ... ighres.txt
, he says :
"As nearly all of the ROM characters have a blank line at the top, the high res
routine changes this to 12 which is at ROM address 3072 ($0C00) which I found contains
much more interesting bit-patterns than other values which can be used."


B)
For the 2 bit x 2 bit I wanted the following somewhere in the ROM:

00000000 = $00 -> 11111111 = $FF
00000011 = $03 -> 11111100 = $FC
00001100 = $0C .....
00001111 = $0F .....
11000000 = $C0 .....
11000011 = $C3 .....
11001100 = $CC .....
11001111 = $CF .....

Helas nor 3072, nor any ROM address had this sequence.

C) The solution was the enabled ram address $2000 and following, where I could put the 8 value.
So you use the ram to hold the patterns of a new "character generator", which is normally in ROM. So you want to make UDG in the ram!
But normal ram in a REAL Zeddy is not usable as UDG ram: UDG ram must be connected to the ROM address pins (driven by the ULA), not to the edge connector or to the internal RAM address pins (driven by the Z80).

EO behaves different and IMHO allows to use any RAM as UDG-RAM!!!

That is the reason, why my INTERC-U game (using UDG at $2000) runs in EO, but not on most real Zeddies (except my web-server zeddy :D )

Did you test using a real Zeddy or EO?????
D) Of course, in 'HRSET' I put A=$20 (for $2000) where Steve put LD A,$0C for address $0C00
He took $0C, because this is an address in ROM. Addresses outside in "normal" rams won't work.
Steve says: "Due to hardware limitations, the "I" register can ONLY point into the ROM -
and not RAM (hence the reason for only pseudo high res - sigh!)."

Siggi

Yes, I was aware of this limitation until 1FFF (bit 5 set to 1 ?) in a real ZX81.
But I believed that with the few modification with the hardware explained in several document one could poke address $2000. (EO call it "Enable RAM 8k - 16k and I suppose it is what Wilf Rigter in his tutorial call " modifying a standard 16K RAMPACK with a couple of diodes and a resistor.").
I would like to understand what happened : Pseudo Hi Res accept address C0 (and 1E, of course) but can't accept address 20 ! Is because $20 set a bit 5 to 1 ?

I just would like to understand better.

Dominique
User avatar
siggi
Posts: 990
Joined: Thu May 08, 2008 9:30 am
Location: Wetterau, Germany
Contact:

Re: Detecting HRG

Post by siggi »

Forthretro.new.fr wrote: Yes, I was aware of this limitation until 1FFF (bit 5 set to 1 ?) in a real ZX81.
But I believed that with the few modification with the hardware explained in several document one could poke address $2000. (EO call it "Enable RAM 8k - 16k and I suppose it is what Wilf Rigter in his tutorial call " modifying a standard 16K RAMPACK with a couple of diodes and a resistor.").
I would like to understand what happened : Pseudo Hi Res accept address C0 (and 1E, of course) but can't accept address 20 ! Is because $20 set a bit 5 to 1 ?

I just would like to understand better.

Dominique
That is not so easy: see Wilf' Video tutorial
http://www.user.dccnet.com/wrigter/inde ... torial.htm
and a ZX81 schema.

During lores or pseudo hires display the ULA overwrites during refresh (when the character generator is read) the Z80 address lines A0 to A8 (9 Bit: 0000..01FF, called A0'..A8'). These modified address lines A0'-A8' are connected only to the rom socket, while the internal and external ram get the original Z80 address lines A0-A8 (decoupled via "isolating" resistors, see the schema). So ram, which should be used for a character generator (for UDG or pseudo hires) must have the modified address lines (A0'-A8', driven by ULA) and must be connected to the rom socket (not the edge connector).

So you can have 3 types of ram at 8K:
1. a "normal" ram, which can be read with PEEK and written with POKE (EU: "enable ram at 8-16K") using A0-A8...

2. a "hires enabled" ram, which can be read with PEEK and during refresh and written with POKE (EO: "WRX enabled) using A0-A8...
That is what Wilf Rigter calls in his tutorial " modifying a standard 16K RAMPACK with a couple of diodes and a resistor.")

3. a "UDG" ram (connected to A0'-A8'), which can be read with PEEK and during refresh at by the ULA modified addresses and written with POKE.

HTH
Siggi
My ZX81 web-server: online since 2007, running since dec. 2020 using ZeddyNet hardware
http://zx81.ddns.net/ZxTeaM
User avatar
Forthretro.new.fr
Posts: 32
Joined: Thu Nov 19, 2009 9:34 pm

Re: Detecting HRG

Post by Forthretro.new.fr »

Moggy wrote:"EO behaves different and IMHO allows to use any RAM as UDG-RAM!!!
That is the reason, why my INTERC-U game (using UDG at $2000) runs in EO, but not on most real Zeddies (except my web-server zeddy :D )

Did you test using a real Zeddy or EO????"

Hi Dominique

Tried loading zx4paint on a real zeddy with 32k ram and 8k static ram on a hunter board no joy at all. Like siggi says the ram has to be hi res enabled on the real thing whilst EO "cheats" and allows anything. It would seem that two schools of thought are required when programming one for emulators and one for real machines. :cry: :cry:

Hi Moggy,

Helas ! :cry:
;)
I would like to thank you for all your effort, and your help !

BTW : If you you want to check the Pseudo HiRes routine in ZX4Paint (it is possible also to have a problem there) , the $20 of ..................LD A,$20 ; -> THIS IS ADDRESS $2000
is address $4128.

I you do a POKE 16680, 12 you will the ROM $0C00 .
0C00 -> 4F, The SCR will be full of 1001111

Thank you again Moggy.
User avatar
Forthretro.new.fr
Posts: 32
Joined: Thu Nov 19, 2009 9:34 pm

Re: Detecting HRG

Post by Forthretro.new.fr »

siggi wrote: That is not so easy: see Wilf' Video tutorial
http://www.user.dccnet.com/wrigter/inde ... torial.htm
and a ZX81 schema.

During lores or pseudo hires display the ULA overwrites during refresh (when the character generator is read) the Z80 address lines A0 to A8 (9 Bit: 0000..01FF, called A0'..A8'). These modified address lines A0'-A8' are connected only to the rom socket, while the internal and external ram get the original Z80 address lines A0-A8 (decoupled via "isolating" resistors, see the schema). So ram, which should be used for a character generator (for UDG or pseudo hires) must have the modified address lines (A0'-A8', driven by ULA) and must be connected to the rom socket (not the edge connector).

So you can have 3 types of ram at 8K:
1. a "normal" ram, which can be read with PEEK and written with POKE (EU: "enable ram at 8-16K") using A0-A8...

2. a "hires enabled" ram, which can be read with PEEK and during refresh and written with POKE (EO: "WRX enabled) using A0-A8...
That is what Wilf Rigter calls in his tutorial " modifying a standard 16K RAMPACK with a couple of diodes and a resistor.")

3. a "UDG" ram (connected to A0'-A8'), which can be read with PEEK and during refresh at by the ULA modified addresses and written with POKE.

HTH
Siggi

Thank you,

Well, not very easy to understand for a novice in eletronique.

My question is : Do you think it possible, with the RAM connected to the rom socket etc., the Pseudo Hi Res routine as given today to work with a modified Zeddy ?

I will recieve mine in few weeks ( my last one was a TK85 when I was living in Brazil) and I have someone who can do the modification.

For the RAM, I suppose it is possible to find it somewhere.

Thanks

Dominique
User avatar
siggi
Posts: 990
Joined: Thu May 08, 2008 9:30 am
Location: Wetterau, Germany
Contact:

Re: Detecting HRG

Post by siggi »

Forthretro.new.fr wrote: My question is : Do you think it possible, with the RAM connected to the rom socket etc., the Pseudo Hi Res routine as given today to work with a modified Zeddy ?
Yes, it would work with such a RAM. But that solution would work only on your Zeddy (and my web-server-Zeddy), not on most other real Zeddies around.
IMHO it would be a better solution, to replace the PSEUDO-HRG routine, that you use, by a TRUE-HIRES routine (like WRX). That would then only require the easy "Wilf's 2 diodes" modification of the 16K ram pack and then your program would run on most other Zeddies. And you would also have the full graphical resolution (not only 1x2 "fat-pixels").

Siggi
My ZX81 web-server: online since 2007, running since dec. 2020 using ZeddyNet hardware
http://zx81.ddns.net/ZxTeaM
sirmorris
Posts: 2811
Joined: Thu May 08, 2008 5:45 pm

Re: Detecting HRG

Post by sirmorris »

There is one point which I think may be worth mentioning.

Software written using a hires driver is nothing like software using the built-in video routines. There is, as far as I know, no author which has produced lores versions of any of their hires programs - what's the point? :) Lores rezurrection demo anyone?? :twisted:

If software is written to take advantage of a particular piece if hardware then this needs to be available. Only one add-on had software which was fundamentally the same in both normal and enhanced versions - that was the QS UDG board. The program just moved character block sprites around - the only difference was the character code used.

C
Post Reply