C API for Next hardware sprites

If you like transforming your statements into code, this is the place for you

Moderator: Programming Moderators

Stefan123
Posts: 102
Joined: Mon Jun 05, 2017 9:38 pm

Re: C API for Next hardware sprites

Post by Stefan123 » Thu Aug 17, 2017 8:42 pm

Still, it shouldn't be too much longer and we can use real hardware!
I bought the accelerated version so I have to patiently wait until January... Now I regret not buying the dev board as well :(

Spec-chum
Posts: 36
Joined: Tue May 30, 2017 11:14 am

Re: C API for Next hardware sprites

Post by Spec-chum » Thu Aug 17, 2017 11:55 pm

Stefan123 wrote:
Thu Aug 17, 2017 8:42 pm
Still, it shouldn't be too much longer and we can use real hardware!
I bought the accelerated version so I have to patiently wait until January... Now I regret not buying the dev board as well :(
You and me both :(
I'm not insane; my mother had me tested

maniccyberdog
Posts: 14
Joined: Mon May 29, 2017 7:23 pm

Re: C API for Next hardware sprites

Post by maniccyberdog » Fri Aug 18, 2017 1:07 pm

Thanks for the update, now working well in cspect!

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

Re: C API for Next hardware sprites

Post by Alcoholics Anonymous » Fri Aug 18, 2017 2:07 pm

Stefan123 wrote:
Thu Aug 17, 2017 8:37 pm
All four versions work fine in ZEsarUX but only the first two versions work in CSpect. Either there is a problem with the z80_outp() and intrinsic_outi() functions in Z88DK or CSpect fails to execute them correctly. The latter reason is more likely. Maybe Alvin (Z88DK lead developer) can shed some light on this issue?
There is a bug (or rather misunderstanding) in CSpect where it's 16-bit decoding the 8-bit ports so that the top 8-bits of ports like 0x5b must be zero for anything to happen. That means outi / otir can't be used to write to these ports since they modify the upper 8 bits as they run. This should be fixed in the next version of CSpect, maybe tonight.

Actually it's a bit of a miracle that any of those methods work because 8-bit port writes using those other methods is likely done with "OUT (n),a" which also places the A register on the top 8 bits, so maybe there is a bug in CSpect's handling of the OUT instruction too.

Stefan123
Posts: 102
Joined: Mon Jun 05, 2017 9:38 pm

Re: C API for Next hardware sprites

Post by Stefan123 » Sat Aug 19, 2017 7:49 pm

Thanks for the clarifications. I will try both otir and outi when the next version of CSpect arrives.

You kind of wish that the Next team would have specified more clearly that these ports should be treated as 8-bit. That would have saved some time for the emulator guys.

Spec-chum
Posts: 36
Joined: Tue May 30, 2017 11:14 am

Re: C API for Next hardware sprites

Post by Spec-chum » Sat Aug 19, 2017 8:38 pm

If you're using CSpect and snasm you can even just use the new OUTINB instruction too as that doesn't alter B.

If you use pasmo just do a macro to emit:

Code: Select all

ED90
like this:

Code: Select all

outinb	macro
	dw		$90ed
endm
EDIT: Whoops, forgot what thread I was in! Clearly not using snasm or pasmo, sorry!
I'm not insane; my mother had me tested

Spec-chum
Posts: 36
Joined: Tue May 30, 2017 11:14 am

Re: C API for Next hardware sprites

Post by Spec-chum » Sat Aug 19, 2017 9:10 pm

I'm not insane; my mother had me tested

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

Re: C API for Next hardware sprites

Post by Alcoholics Anonymous » Sun Aug 20, 2017 12:20 am

Spec-chum wrote:
Sat Aug 19, 2017 8:38 pm
EDIT: Whoops, forgot what thread I was in! Clearly not using snasm or pasmo, sorry!
All the new instructions are in z88dk's assembler as of tonight's build (August 20) or right now if you use github.
https://www.z88dk.org/forum/viewforum.php?id=19

Code: Select all

New Z80 opcodes on the NEXT (more to come)
======================================================================================
   swapnib           ED 23           A bits 7-4 swap with A bits 3-0
   mul               ED 30           multiply HL*DE = DEHL (no flags set)
   add  hl,a         ED 31           Add A to HL (no flags set)
   add  de,a         ED 32           Add A to DE (no flags set)
   add  bc,a         ED 33           Add A to BC (no flags set)
   add  hl,NNNN    ED 34 LO HI     Add NNNN to HL (no flags set)
   add  de,NNNN     ED 35 LO HI     Add NNNN to DE (no flags set)
   add  bc,NNNN     ED 36 LO HI     Add NNNN to BC (no flags set)
   outinb            ED 90           out (c),(hl), hl++
   ldix              ED A4           As LDI,  but if byte==A does not copy
   ldirx             ED B4           As LDIR, but if byte==A does not copy
   lddx              ED AC           As LDD,  but if byte==A does not copy, and DE is incremented
   lddrx             ED BC           As LDDR,  but if byte==A does not copy
   fillde            ED B5           Using A fill from DE for BC bytes
   ld  hl,sp         ED 25           transfer SP to HL
   ld  a32,dehl    ED 20           transfer dehl into A32
   ld  dehl,a32    ED 21           transfer A32 into dehl
   ex  a32,dehl    ED 22           swap A32 with dehl
   inc dehl          ED 37           increment 32bit dehl
   dec dehl          ED 38           increment 32bit dehl
   add dehl,a        ED 39           Add A to 32bit dehl
   add dehl,bc       ED 3A           Add BC to 32bit dehl
   add dehl,NNNN    ED 3B LO HI     Add NNNN to 32bit dehl
   sub dehl,a        ED 3C           Subtract A from 32bit dehl
   sub dehl,bc       ED 3D           Subtract BC from 32bit dehl
   mirror a          ED 24           mirror the bits in A     
   mirror de         ED 26           mirror the bits in DE     
   push NNNN        ED 8A LO HI     push 16bit immidiate value
   popx              ED 8B           pop value and disguard

   nextreg reg,val   ED 91 reg,val   Set a NEXT register (like doing out($243b),reg then out($253b),val )
   nextreg reg,a     ED 92 reg       Set a NEXT register using A (like doing out($243b),reg then out($253b),A )
** reg,val are both 8-bit numbers

   pixeldn           ED 93           Move down a line on the ULA screen
   pixelad           ED 94           using D,E (as Y,X) calculate the ULA screen address and store in HL
   setae             ED 95           Using the lower 3 bits of E (X coordinate), set the correct bit value in A
   test NN         ED 27 NN     And A with NN and set all flags. A is not affected.
We're waiting until ZEsarUX has implemented them (shortly) before the compilers and library starts to use them so that a full emulation is available. But you can use them in your asm in combination with CSpect. Compiling with "-subtype=sna -create-app" will generate an sna file that CSpect can load via F2.

Spec-chum
Posts: 36
Joined: Tue May 30, 2017 11:14 am

Re: C API for Next hardware sprites

Post by Spec-chum » Sun Aug 20, 2017 8:39 pm

Just keeps getting better :)
I'm not insane; my mother had me tested

Stefan123
Posts: 102
Joined: Mon Jun 05, 2017 9:38 pm

Re: C API for Next hardware sprites

Post by Stefan123 » Tue Sep 19, 2017 7:34 pm

Update

The C hardware sprite API has been updated with support for loading sprite files, setting layer priorities in the new way and making use of intrinsic_outi() in the set_sprite_pattern() function.

https://github.com/stefanbylund/zxnext_sprite
https://github.com/stefanbylund/zxnext_sprite_demo

Post Reply