First steps into Z88DK...and many more to come!

Discuss game and other programming topics not specifically covered in another forum

Moderator: Programming Moderators

User avatar
SevenFFF
Posts: 565
Joined: Mon Jun 05, 2017 5:30 pm
Location: USA

Re: First steps into Z88DK...and many more to come!

Postby SevenFFF » Mon Jun 04, 2018 10:07 pm

Hi Samus, yes Godaddy were reasonably helpful. I had to talk to them a couple of times, and they did what I needed. I also forgot to cancel my renewal for another domain, and they refunded it without question when I called.

For what it's worth, my wife organised the wedding of the guy who owns it. Apparently everyone calls him Daddy, without a trace of irony...

I personally think the game loop is the best way. The Next is fast enough at 14MHz to do 50fps. It also has extra methods to make syncing easier, so you almost get the best of both worlds.

There's a raster interrupt you can set on any of the 312 video lines, and you can also query the current video line from non-interrupt code, which is easier than trying to do floating bus-style tricks.

You can also program the copper to wait for a particular video line and character column before doing stuff, and you can lock the DMA to the turbo rate, making playing audio samples easier when the turbo rate changes (at 14MHz, it drops down to 7MHz while the raster is over the pixel area, to avoid timing problems reading the Layer 2 RAM).
Robin Verhagen-Guest
SevenFFF / Threetwosevensixseven / colonel32
NXtel NXTP ESP Update ESP Reset CSpect Plugins

SamusDrake
Posts: 258
Joined: Mon Jun 26, 2017 10:11 pm
Contact:

Re: First steps into Z88DK...and many more to come!

Postby SamusDrake » Mon Jun 04, 2018 10:21 pm

I have to say, Robin, Godaddy does seem a solid service. And thats a interesting story you have there - organising any wedding must a real pain. For the time being I'm going to play along with Ehost( transferring to JustHost ), but really digging around I think Godaddy makes a lot of sense for domain names at least. I'm considering another dn for a second site...

I've spent the night setting up Retro Pie on my RPi-3, and its making a lot of sense for homebrew. Theres a Spectrum menu on RetroPie, and I wonder if they can play Next games...

SamusDrake
Posts: 258
Joined: Mon Jun 26, 2017 10:11 pm
Contact:

Re: First steps into Z88DK...and many more to come!

Postby SamusDrake » Tue Oct 29, 2019 8:57 pm

Its been a while. VR is hungry work and I've returned to all things retro for a break...

Rolled the sleeves up and learning Z80 assembly proper with the tutorials on Chibi Akumas. While that site is great, I am thankful for the help I got here last year. I ought to backup the work here to Github, just in case.

Explored the Amiga by means of Amiban and a Pi 3. While I doubt I'd have the skill to make games in assembly, I would like to at least practice 68000 assembly, all the same. I feel learning the Z80 first is a good foundation for when that time comes...

While I'm mostly doing VR work now(Oculus Go + Unity), the influence for that game project is the old Freescape games such as Castle Master and Driller. Very fond memory of reading the YS review for 3D Construction Kit and wishing I had a copy for the old Spectrum. Would be nice if there was a Next version...

Finally got ZEsarUX working! Had a muck around with Castle Master on turbo(omg, its fast!), so not that familar with it yet. It would be cool if there was a Raspberry Pi distrobution that turned the Pi into a Speccy Next, should there not be another run. A year on, and I wonder what state z88dk is in with regards to Next support...as I think I should be able to manage a small game with the platform. ^_^

Does the next still use traditional spectrum memory for the screen and attributes or would that be all new? Very exciting times!

Ped7g
Posts: 256
Joined: Mon Jul 16, 2018 7:11 pm

Re: First steps into Z88DK...and many more to come!

Postby Ped7g » Wed Oct 30, 2019 3:33 pm

SamusDrake wrote:
Tue Oct 29, 2019 8:57 pm
Does the next still use traditional spectrum memory for the screen and attributes or would that be all new? Very exciting times!
The classic ZX graphics mode is still available, but there are many new options.

Some are still "classic" like the "Timex" modes which were introduced with the TS2068 (Spectrum clone with some changes) (the HiColor mode which has attributes per 8x1 pixels = each byte of pixels has its own byte for attributes, HiRes mode having 512x192 half-width pixels having even more crazy memory scheme than original) => these are mutually exclusive replacement to the classic mode.

Some are "new" modes, but replacing the classic ULA mode, like LoRes 128x96 256 colour and similar LoRes 128x96 16 colour mode.

Some are extra modes, which can be also combined together with original modes, composing them with different order/priority (and having transparent cutout in particular mode to show the layers below).

"Layer 2" mode = 256x192 256 colour mode (one byte = one pixel, simple linear framebuffer = 48kiB)

"Tile-mode" = lives around ULA mode (in the same memory bank) and has many options how to set it up, but probably the most beefed (and memory demanding) config is 640x256 resolution 80x32 tiles with attribute (resolution is like Timex 512x192 but with extra 32px up/down into border and 64px left/right into border, i.e. pixels are "half-width" compared to regular ULA mode) with 16 colour tiles graphics from 256 palette...
(maybe the simplest way to describe to get the idea is "like VGA text mode")

All of them have now support for HW scrolling.

And there are HW sprites available.... (256 colour, pixel resolution same as ULA mode, but they can go 32px deep into border area)
(sprites have again many possible configurations, but there can be 128 entities on screen without multiplexing, with "64 to 128" graphic patterns (depending if you want to use 8bit or 4bit graphics, 8bit eats sprite-gfx-pattern memory twice as fast)

So depending what you want to do, and how many new things you want to learn, you have quite some options how to configure Next.

The new modes are mostly very friendly to newcomer programmers, and putting some simple static-like 256 colour background with 16x16 sprites over it is viable even in BASIC, some simple classic games are sort of "easy" to do (compared to classic ZX and it's video ram and SW sprites).

SamusDrake
Posts: 258
Joined: Mon Jun 26, 2017 10:11 pm
Contact:

Re: First steps into Z88DK...and many more to come!

Postby SamusDrake » Wed Oct 30, 2019 8:29 pm

Good to know it gets easier when moving on from the classic speccy display. Thank you kindly. ^_^

Alcoholics Anonymous
Posts: 781
Joined: Mon May 29, 2017 7:00 pm

Re: First steps into Z88DK...and many more to come!

Postby Alcoholics Anonymous » Wed Nov 27, 2019 6:17 am

About emulation... there is no complete or 100% accurate emulation of the next yet. There are still two main emulators: cspect and zesarux. cspect requires the least cpu to run and it has been compiled for the pi3 as well as the pi4. It runs fairly well on a pi3, although I am not sure how that will hold up now that the next can run at 28MHz and with possible future feature additions. The pi accelerator add-on is probably going to be an important feature extension of the next (albeit optional) so that would make things difficult to emulate. I hope wifi will take off for some multiplayer games and that may present a challenge to emulator authors as well.

For z88dk, I am the main dev for the next support and I stopped working on the z88dk side early in the year as I moved to working on the next hardware instead. I only have a limited amount of spare time so I had to choose unfortunately. The next support is significant in z88dk though, although it doesn't yet have dedicated libraries for things like hardware sprites. Programming the hardware directly is not too difficult once you understand how it works, or you could see what others have done. There is a simple hw sprite library by Stefan that was written last year. I don't think it has been updated for the new sprite module but it will still work. The new sprite module supports up to 128 sprites (100 visible per line) and things like scaling and grouping into larger sprites. Designing a good sprite library around these features would take some thought. I will be returning to z88dk soon, applying the lessons learned in a year's experience on the next hw side. For serious alternative to asm development, C is the way to go, although the features of the next do make it possible for other high level languages to succeed as well.

SamusDrake
Posts: 258
Joined: Mon Jun 26, 2017 10:11 pm
Contact:

Re: First steps into Z88DK...and many more to come!

Postby SamusDrake » Fri Nov 29, 2019 4:43 pm

Good to know how far things have come, Alvin - and that you've been having a ball with the Next hardware! ^_^

Finding assembly much easier to understand with Keith's tutorials over on ChibiAkumas and now able to pick out things that are "under the hood" in C. I wasn't so sure last year but now I can confidently say that knowing some Assembly is an advantage for any programmer - there is so much that can go wrong when programming at the low level, and there is respect to be had for those who have given time and effort to creating the Assemblers, Compilers and IDEs we take for granted. Although its bordering on heresy I am starting to appreciate the Amstrad, as Keith uses it along with WinApe for the tutorial lessons. He's also given some thought to the Next...

I've got next week off work so I'm planning on giving some time to Z88DK, SGDK and getting to grips with Github(I've been putting it off for too long). I think if I do make a game for either the spectrums or megadrive it will be influenced by CRL's "Samurai". Loved that game and having spent the last two years returning to the tabletop, I can see possibilities which I feel I could program comfortably.

SamusDrake
Posts: 258
Joined: Mon Jun 26, 2017 10:11 pm
Contact:

Re: First steps into Z88DK...and many more to come!

Postby SamusDrake » Mon Jan 04, 2021 7:32 pm

Its been a year since last posting and a strange one at that. I hope everyone is doing alright and keeping well.

This week I loaded up ZX Spin, opened the Assembler and begun working through how to address the zx spectrum's screen memory - much like I had with Z88DK using C...

Code: Select all

HIGH_BYTE	equ %01000000
LOW_BYTE	equ %00000010
			  ; 10 RANDOMIZE USR 32768
X_Coord		equ &9001 ; 20 PRINT PEEK 36865
Y_Coord		equ &9002 ; 30 PRINT PEEK 36866
X_Component	equ &9003 ; 40 PRINT PEEK 36867
Y_Component 	equ &9004 ; 50 PRINT PEEK 36868
X_Byte		equ &9005 ; 60 PRINT PEEK 36869
Y_Boundry	equ &9006 ; 70 PRINT PEEK 36870
Y_Line		equ &9007 ; 80 PRINT PEEK 36871
Y_Block		equ &9008 ; 90 PRINT PEEK 36872


;----- MAIN PROGRAM (ADDRESS: 32768) -----
ORG &8000
	LD 	A, 128+5
	CALL 	STORE_X
	LD 	A, 39
	CALL 	STORE_Y

	CALL 	OBTAIN_X_COMPONENT
	CALL 	OBTAIN_X_BYTE

	CALL 	OBTAIN_Y_BLOCK
	CALL 	OBTAIN_Y_BOUNDRY
	CALL 	OBTAIN_Y_LINE
RET

;------------------------
STORE_X:
	LD DE, X_Coord
	LD (DE), A
RET

;------------------------
STORE_Y:
	LD DE, Y_Coord
	LD (DE), A
RET

;------------------------
RESET_ACCUMULATOR:
	LD A, 0
RET

;------------------------
SHIFT_X_COORD:
	LD 	A, (X_Coord)
	SRL	A
RET

;------------------------
OBTAIN_X_COMPONENT:
	LD 	A, (X_Coord)
	SRL 	A
	SRL 	A
	SRL 	A
	LD 	DE, X_Component
	LD 	(DE), A
RET

;------------------------
OBTAIN_X_BYTE:
	LD 	A, (X_Coord)
	RES 	3, A
	RES 	4, A
	RES 	5, A
	RES 	6, A
	RES 	7, A
	LD 	DE, X_Byte
	LD 	(DE), A
RET

;------------------------
OBTAIN_Y_BLOCK:
	LD 	A, (Y_Coord)
	RES 	0, A
	RES 	1, A
	RES 	2, A
	RES 	3, A
	RES 	4, A
 	RES	5, A
	SRL 	A
	SRL 	A
	SRL 	A
	LD 	DE, Y_Block
	LD 	(DE), A
RET

;------------------------
OBTAIN_Y_BOUNDRY:
	LD 	A, (Y_Coord)
	RES 	0, A
	RES 	1, A
	RES 	2, A
	SLL 	A
	SLL 	A
	LD 	DE, Y_Boundry
	LD 	(DE), A
RET

;------------------------
OBTAIN_Y_LINE:
	LD 	A, (Y_Coord)
	RES 	3, A
	RES 	4, A
 	RES	5, A
	RES 	6, A
	RES 	7, A
	LD 	DE, Y_Line
	LD 	(DE), A
RET

;------------------------
DISPLAY_BYTE:
	LD A, 255
	LD H, HIGH_BYTE
	LD L, LOW_BYTE
	LD (HL), A
RET
...at the moment this is just to store a x,y coordinate, and strip out the required components for the screen memory address, and the byte that will be stored there. Theres also bit of basic code to get it running...

Code: Select all

10 RANDOMIZE USR 32768
20 PRINT PEEK 36865
30 PRINT PEEK 36866
40 PRINT PEEK 36867
50 PRINT PEEK 36868
60 PRINT PEEK 36869
70 PRINT PEEK 36870
80 PRINT PEEK 36871
90 PRINT PEEK 36872
...its a complete mess for now but its the first time I've been able to put aside the tutorials and write assembly without assistance. At some point this will turn into a program where we can move a dot around the screen with keyboard input.

Useful sites were this forum, Chibiakumas, Z80 Heaven and "L Break into Program". Without these sites some of us would still be back in the stone age figuring out how to get started...

Anyway, nice to be back. Cheers.

SamusDrake
Posts: 258
Joined: Mon Jun 26, 2017 10:11 pm
Contact:

Re: First steps into Z88DK...and many more to come!

Postby SamusDrake » Mon Feb 08, 2021 3:12 pm

Very small update but finally got my head around the pixel plotting. Never thought I'd have a use for bit rotation and its given me ideas for scrolling animations, but thats a while off yet.

Nothing fancy but essentially a line of 32 screen bytes each displaying the last( 8th ) pixel filled...

Code: Select all

HIGH_BYTE	equ %01000000
LOW_BYTE	equ %00000010
			  ; 10 RANDOMIZE USR 32768
X_Coord		equ &9001 ; 20 PRINT PEEK 36865
Y_Coord		equ &9002 ; 30 PRINT PEEK 36866
X_Component	equ &9003 ; 40 PRINT PEEK 36867
Y_Component 	equ &9004 ; 50 PRINT PEEK 36868
X_Byte		equ &9005 ; 60 PRINT PEEK 36869
Y_Boundry	equ &9006 ; 70 PRINT PEEK 36870
Y_Line		equ &9007 ; 80 PRINT PEEK 36871
Y_Block		equ &9008 ; 90 PRINT PEEK 36872

ADDR_BYTE_HIGH	equ &A001 ; 100 PRINT PEEK 40961
ADDR_BYTE_LOW	equ &A002 ; 110 PRINT PEEK 40962


;----- MAIN PROGRAM (ADDRESS: 32768) -----
ORG &8000
	LD	B, 255
	LD 	A, 0
	CALL 	STORE_X
	LD 	A, 0
	CALL 	STORE_Y
	
	CALL	RENDER_DOT_LINE
RET

RENDER_DOT_LINE:
MAIN_LP	PUSH	BC
	PUSH	AF
	CALL	BUILD_COORDINATES
	POP	AF
	POP	BC
	LD 	A, (X_Coord)
	INC	A
	LD	(X_Coord), A
	DEC	B
	CP	0
	JP	NZ, MAIN_LP
RET

BUILD_COORDINATES:
	CALL 	OBTAIN_X_COMPONENT
	CALL 	OBTAIN_X_BYTE

	CALL 	OBTAIN_Y_BLOCK
	CALL 	OBTAIN_Y_BOUNDRY
	CALL 	OBTAIN_Y_LINE

	CALL	BUILD_LOW_BYTE
	CALL 	BUILD_HIGH_BYTE

	CALL 	STORE_SCREEN_ADDRESS
	
	CALL	LOAD_SCREEN_ADDRESS
	CALL	CONVERT_X_BYTE
	CALL	DISPLAY_BYTE_ON_SCREEN

	CALL	DISPLAY_BORDER
RET

;------------------------
STORE_X:
	LD DE, X_Coord
	LD (DE), A
RET

;------------------------
STORE_Y:
	LD DE, Y_Coord
	LD (DE), A
RET

;------------------------
RESET_ACCUMULATOR:
	LD A, 0
RET

;------------------------
SHIFT_X_COORD:
	LD 	A, (X_Coord)
	SRL	A
RET

;------------------------
OBTAIN_X_COMPONENT:
	LD 	A, (X_Coord)
	SRL 	A
	SRL 	A
	SRL 	A
	LD 	DE, X_Component
	LD 	(DE), A
RET

;------------------------
OBTAIN_X_BYTE:
	LD 	A, (X_Coord)
	RES 	3, A
	RES 	4, A
	RES 	5, A
	RES 	6, A
	RES 	7, A
	LD 	DE, X_Byte
	LD 	(DE), A
RET

;------------------------
OBTAIN_Y_BLOCK:
	LD 	A, (Y_Coord)
	RES 	0, A
	RES 	1, A
	RES 	2, A
	RES 	3, A
	RES 	4, A
 	RES	5, A
	SRL 	A
	SRL 	A
	SRL 	A
	LD 	DE, Y_Block
	LD 	(DE), A
RET

;------------------------
OBTAIN_Y_BOUNDRY:
	LD 	A, (Y_Coord)
	SLL 	A
	SLL 	A
	RES 	0, A
	RES 	1, A
	RES 	2, A
	RES	3, A
	RES	4, A
	LD 	DE, Y_Boundry
	LD 	(DE), A
RET

;------------------------
OBTAIN_Y_LINE:
	LD 	A, (Y_Coord)
	RES 	3, A
	RES 	4, A
 	RES	5, A
	RES 	6, A
	RES 	7, A
	LD 	DE, Y_Line
	LD 	(DE), A
RET

;------------------------
DISPLAY_BYTE:
	LD A, 255
	LD H, HIGH_BYTE
	LD L, LOW_BYTE
	LD (HL), A
RET

;------------------------
BUILD_LOW_BYTE:
	LD A, (Y_Boundry)
	LD B, A
	LD A, (X_Component)
	OR B
	LD L, A
RET

;------------------------
BUILD_HIGH_BYTE:
	LD A, (Y_Block)
	LD B, A
	LD A, (Y_Line)
	LD C, A
	LD A, 0
	OR B
	OR C
	RES 7, A
	SET 6, A
	RES 5, A
	LD H, A
RET

;------------------------
STORE_SCREEN_ADDRESS:
	LD DE, ADDR_BYTE_HIGH
	LD A, H
	LD (DE), A

	LD DE, ADDR_BYTE_LOW
	LD A, L
	LD (DE), A
RET

;------------------------
LOAD_SCREEN_ADDRESS:
	LD A, (ADDR_BYTE_HIGH)
	LD D, A
	LD A, (ADDR_BYTE_LOW)
	LD E, A
RET

;------------------------
DISPLAY_BYTE_ON_SCREEN:
	LD A, (X_Byte)
	LD (DE), A
RET

;------------------------
CONVERT_X_BYTE:
	LD A, (X_Byte)
	LD B, A
	inc B
	LD A, %00000001

CXB_ROT	RRC A
	DJNZ CXB_ROT
	
	LD (X_Byte), A	
RET

;------------------------
DISPLAY_BORDER:
	LD A, 3
	OUT (&FE), A
RET
...part of me wants to run away from how scary this all is, but the other is driven to learn more. With these old cpus you assume there is a complicated way of achieving a task, but then reason that the Z80 has to use simple instructions was to keep a half-decent frame rate. It can't afford to do anything fancy.

Finally came across the classic Spectrum ROM Disassembly text from the early 80s and its helping a lot in understanding how the Spectrum works, exposing the memory map for things like how to load data from a tape to changing the border colour. Most of its examples go right over my head now, but its something I can always refer to when I need to understand how to perform a task.

Alcoholics Anonymous
Posts: 781
Joined: Mon May 29, 2017 7:00 pm

Re: First steps into Z88DK...and many more to come!

Postby Alcoholics Anonymous » Wed Feb 10, 2021 5:07 am

I find reading the spectrum rom disassembly painful :) But it's because it's a large program that you must read a lot of to understand how it works. Isolated subroutines are less painful. I've not quite understood why people say it's a good way to learn assembly yet :D

If you have a lot of RES in a row, you can better do that with an AND instruction. Eg:

RES 0, A
RES 1, A
RES 2, A
RES 3, A
RES 4, A
RES 5, A

can be replaced by "AND $e0" (keep the top three bits). There is a small difference in that the AND instruction also affects flags whereas RES won't. RES is also added to the shifted opcode space (it has a prefix byte) so that means it takes two bytes to encode it (prefix + opcode) for a total of 8 cycles to execute. AND N takes 7 cycles (opcode + fetch operand via memory read). The z80 is an extension of the 8080 so the 8080 instruction set had to be preserved, number one, and those occupy the single opcode space. Most of the z80-specific instructions have to be added to a shifted space where you put in a prefix opcode(s) to indicate those are not single byte.

The instructions "rr a", "rrc a", "rl a", "rlc a", "srl a", "sla a" (note the spaces!) are extended opcode instructions too, taking 8 cycles. "rla", "rrlca", "rra", "rrca" (note no space!) are single opcode instructions taking 4 cycles as those are inherited from the 8080.

The instruction "SLL A" is an undocumented instruction and may not be supported on z80 derivatives or all z80 chips, though all nmos z80s (and the zx next's z80) will support it for sure. Hopefully that is assembling on z88dk with at least a warning.

The other key with assembly is to always try to do as little work as possible. The load of CALL/RET is ok for learning but otherwise it's a lot of wasted cycles for a function which, in its most broken down form, is "get me a display file address". Breaking it down further isn't helpful I don't think.

But anyway, good job on getting started. Seeing something working is always a good feeling! There are a load of such screen address routines in z88dk if you ever want to compare and I will only mention that the z80n has a special instruction for computing the screen address from coordinates -- that would just get in the way of learning.


Who is online

Users browsing this forum: No registered users and 5 guests