<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
      <title>Development - World of Spectrum</title>
      <link>https://worldofspectrum.org/forums/categories/development/p31/feed.rss</link>
      <pubDate>Mon, 22 Apr 2024 11:37:47 +0000</pubDate>
         <description>Development - World of Spectrum</description>
   <language>en-CA</language>
   <atom:link href="https://worldofspectrum.org/forums/categories/development/p31/feed.rss" rel="self" type="application/rss+xml" />
   <item>
      <title>Converting an integer arbitrary large binary number into a printable decimal form</title>
      <link>https://worldofspectrum.org/forums/discussion/45675/converting-an-integer-arbitrary-large-binary-number-into-a-printable-decimal-form</link>
      <pubDate>Thu, 28 Nov 2013 13:22:18 +0000</pubDate>
      <dc:creator>mcleod_ideafix</dc:creator>
      <guid isPermaLink="false">45675@/forums/discussions</guid>
      <description><![CDATA[This was asked a long ago at the comp.sys.sinclair newsgroup. At that time, I came up with a solution by extrapolating the classic algorithm of sucessive divisions by 10 and taking the remainder in each loop. This turned to be a working but very slow process (the Z80 is even unable to divide two arbitrary 8-bit numbers, so 2040-bit numbers is far from fast). Printing the largest 2040-bit number, i.e. (2^2040)-1 took me nearly 54 minutes.<br />
<img src="http://www.atc.us.es/~rodriguj/z80_large_number.png" alt="z80_large_number.png" /><br />
<a href="http://www.zxprojects.com/index.php/displaying-large-numbers-on-the-zx-spectrum" rel="nofollow">http://www.zxprojects.com/index.php/displaying-large-numbers-on-the-zx-spectrum</a><br />
<br />
Yesterday, I was introduced to the <a href="https://en.wikipedia.org/wiki/Double_dabble" rel="nofollow">"double dabble" algorithm</a>, which I didn't know about, to easily convert a binary number into BCD, from which it's very easy to print it. It's easy because it doesn't involve expensive operations, such as division: all it's needed is the ability to shift to the left, and adding 3 to a number. The amount of memory needed is: enough memory for the binary representation of the number, plus one byte for each two BCD digits of the resulting number.<br />
<br />
The number of BCD digits can be calculated as: ceil ( number_of_bits / log2(10) ) . ceil() is the C function that gives us the integer number closer to the argument, greater than it. For example: ceil(3.2) = 4 .<br />
<br />
After designing a hardware version of this algorithm for a school task, I gave it a try as Z80 machine code implementation, to see if it could beat my previous solution. Well... it turned to be way much faster :-o :<br />
<img src="http://www.atc.us.es/~rodriguj/z80_large_number_v2.png" alt="z80_large_number_v2.png" /><br />
<br />
The listing:
<pre>org 40000

Principal       proc
                call 0d6bh  ;CLS
                ld a,2
                call 1601h  ;OPEN #2 (screen)
                ld de,NBITS
BucConv         call Add4Block
                call ShiftBlock
                dec de
                ld a,d
                or e
                jr nz,BucConv
                call PrintBCD
                ret
                endp

ShiftBlock      proc
                ld hl,ENDNUMERO
                sla (hl)
BucShift        push af
                dec hl
                ld a,h
                cp high(BCD-1)
                jr nz,NoFinAun
                ld a,l
                cp low(BCD-1)
                jr nz,NoFinAun
                pop af
                ret
NoFinAun        pop af
                rl (hl)
                jr BucShift
                endp

Add4Block       proc
                ld hl,BCD
BucAdd          ld a,(hl)
                cp 50h
                jr c,NoAddHi
                add a,30h
                ld (hl),a
NoAddHi         and 0fh
                cp 05h
                jr c,NoAddLow
                add a,3
                and 0fh
                ld c,a
                ld a,(hl)
                and 0f0h
                or c
                ld (hl),a
NoAddLow        inc hl
                ld a,h
                cp high(NUMERO)
                jr nz,BucAdd
                ld a,l
                cp low(NUMERO)
                jr nz,BucAdd
                ret
                endp

PrintBCD        proc
                ld b,0   ;Flag to not print leading zeros
                ld hl,BCD
BucPrint2Dig    ld a,(hl)
                srl a
                srl a
                srl a
                srl a
                call PrNotLeading0
                ld a,(hl)
                and 0fh
                call PrNotLeading0
                inc hl
                ld a,h
                cp high(NUMERO)
                jr nz,BucPrint2Dig
                ld a,l
                cp low(NUMERO)
                jr nz,BucPrint2Dig
                ret
                endp

PrNotLeading0   proc
                jr nz,PrintDigit
                ld a,b
                or a
                ret z
                xor a
PrintDigit      ld b,1
                add a,'0'
                rst 10h
                ret
                endp

BCD             ds 308,0     ;Space to store BCD representacion (616 BCD digits)
NUMERO          ds 255,255   ;In big endian format. This is 2^(2040)-1
ENDNUMERO       equ $-1
NBITS           equ ($-NUMERO)*8

;BCD             db 0,0,0,0,0
;NUMERO          db 255,255,255,255   ;This is (2^32)-1
;ENDNUMERO       equ $-1
;NBITS           equ ($-NUMERO)*8

                end Principal

</pre>
]]></description>
   </item>
   <item>
      <title>Documentation for SP1 for Z88DK?</title>
      <link>https://worldofspectrum.org/forums/discussion/45569/documentation-for-sp1-for-z88dk</link>
      <pubDate>Sat, 16 Nov 2013 19:34:40 +0000</pubDate>
      <dc:creator>szeliga</dc:creator>
      <guid isPermaLink="false">45569@/forums/discussions</guid>
      <description><![CDATA[(I was going to post in <a href="http://www.worldofspectrum.org/forums/showthread.php?t=11729" rel="nofollow">the other thread</a>, so if a mod thinks this should go there then fair enough)<br />
<br />
The rest of the family has gone clothes shopping (Saturday night, why not?) so while I've got the place to myself I thought I'd crack open a beer and look at SP1.<br />
<br />
At some point in the past I've found a copy of <a href="http://www.worldofspectrum.org/forums/showthread.php?p=594378#post594378" rel="nofollow">Timmy's "Sprite Demo 1" </a>- it's taken me ages to get it to compile because it needed a blank line at the end! Anyway - I was feeling all enthused until I got to thinking about the following:<br />

<ol>
<li>The library is called "<b><span>sp1</span></b>";</li>
<li>I was reading through <a href="http://www.mojontwins.com/warehouse/splib2-tutorial.pdf" rel="nofollow">an excellent-looking tutorial</a> that references "<b><span>splib2</span></b>" - and the first example there wouldn't compile, presumably because "things have changed";</li>
<li>The "sp1.h" header file in my z88dk folder has a comment naming "<b><span>SPRITE PACK v3.0 </span></b>", and</li>
<li>The <a href="http://www.z88dk.org/wiki/doku.php?id=library:sprites:sp1" rel="nofollow">z88dk wiki page's</a>  "Tutorial and Documentation" section doesn't appear to have any hyperlinks to resources.</li>
</ol>
<br />
Can anybody recommend a good place to start?<br />
<br />
No immediate rush - they've just phoned to say they're on their way back so I'll have to go upstairs and prepare tonight's Mexican-inspired feast :-)]]></description>
   </item>
   <item>
      <title>New android application development</title>
      <link>https://worldofspectrum.org/forums/discussion/45713/new-android-application-development</link>
      <pubDate>Tue, 03 Dec 2013 12:18:11 +0000</pubDate>
      <dc:creator>fjguadalix</dc:creator>
      <guid isPermaLink="false">45713@/forums/discussions</guid>
      <description><![CDATA[Hi,<br />
I'm developing an application to load games to the spectrum directly from the phone.<br />
<br />
The app right now let's you search,download an play them as a sound archive.<br />
<br />
I've tested on a Nexus 4 with 4.3, I was able to load the game on the spectrum 48k+.<br />
<br />
It's supposed to work from 2.3.3 to 4.4<br />
<br />
If you're interested in testing the app follow this link<br />
<a href="https://play.google.com/apps/testing/com.zxtapeloader" rel="nofollow">https://play.google.com/apps/testing/com.zxtapeloader</a><br />
<br />
It's the first time I publish an apk, so please be patient.<br />
<br />
Thx.]]></description>
   </item>
   <item>
      <title>Horace to the Rescue - Unreleased</title>
      <link>https://worldofspectrum.org/forums/discussion/45171/horace-to-the-rescue-unreleased</link>
      <pubDate>Wed, 02 Oct 2013 20:12:08 +0000</pubDate>
      <dc:creator>wiper2001</dc:creator>
      <guid isPermaLink="false">45171@/forums/discussions</guid>
      <description><![CDATA[Hi, I am currently writing Horace to the Rescue which is my version of it based on the original unreleased games name. It will hopefully be ready by Christmas. The Horace graphics and the screeching title sound have been stripped from the Hungry Horace game for authenticity.]]></description>
   </item>
   <item>
      <title>yx git repository</title>
      <link>https://worldofspectrum.org/forums/discussion/45706/yx-git-repository</link>
      <pubDate>Mon, 02 Dec 2013 16:40:56 +0000</pubDate>
      <dc:creator>tstih</dc:creator>
      <guid isPermaLink="false">45706@/forums/discussions</guid>
      <description><![CDATA[Hi,<br />
<br />
working version of yx - the preemptive multitasking operating system for zx spectrum - git repository can be found <a href="https://github.com/tstih/yx" rel="nofollow">here</a>.<br />
<br />
Since I "borrowed" a lot of tricks from the community - it is all free to take back.<br />
<br />
Particularly interesting parts are:<br />
- SDCC templates for development,<br />
- tools,<br />
- proportional fonts,<br />
- the IF1 rs232 routines,<br />
- the standard zx send and zx receive serial programs for unix...<br />
<br />
Most of the code is compilable under ubuntu. Some under Windows. Note that this repository is always under development. At present I am working on the buddy user interface. It is a minimal Macintosh 1984 like Windows GUI for ZX Spectrum. I am also doing yet another refactoring of the OS code to make it even smaller and more consistent.<br />
<br />
If anyone wants to join in the project I'll be more then glad to share all the blueprints.<br />
<br />
Things to do:<br />
- implement data link on top of serial communication to handle multiplexing the connection and automatic error correction,<br />
- implement RPC on PC and ZX to enable cheap (resources wise) connection to the internet via the serial data link,<br />
- improve some drivers (original code is available),<br />
- implement process loading and killing code (relocation technology is available),<br />
- implement fast graphics clipping routines to serve as bottom layer for buddy gui (window / messaging blueprints are available),<br />
- implement GDB stub for z80 to be able to remotely debug software on original spectrum hardware, and<br />
- implement some core gui apps: calculator, notepad, paint, chess, IRC, twitter...<br />
<br />
The final operating system - if simple, minimal, portable and complete (with gui) - could be something of commercial value ... if ported to currently used platforms.<br />
<br />
Tomaz]]></description>
   </item>
   <item>
      <title>Cross platform development</title>
      <link>https://worldofspectrum.org/forums/discussion/45686/cross-platform-development</link>
      <pubDate>Fri, 29 Nov 2013 12:34:41 +0000</pubDate>
      <dc:creator>David Jones</dc:creator>
      <guid isPermaLink="false">45686@/forums/discussions</guid>
      <description><![CDATA[I'm just vaguely considering supporting a few more retro 8 bit platforms for something I have in mind to do.<br />
<br />
Just Z80 and 6502 really, but that covers most of the old machines.<br />
<br />
So the idea is that I set up my own simple language that calls in modules in Z80 or 6502 (and potentially others in future) for each of the different machines I support and it will spit out an assembler listing for each platform.<br />
<br />
Which retro platforms apart from the Spectrum have the best assemblers, emulators and other tools/utilities to make them practical targets for this sort of approach?]]></description>
   </item>
   <item>
      <title>bit manipulation conundrum</title>
      <link>https://worldofspectrum.org/forums/discussion/45691/bit-manipulation-conundrum</link>
      <pubDate>Sat, 30 Nov 2013 11:45:51 +0000</pubDate>
      <dc:creator>Battle Bunny</dc:creator>
      <guid isPermaLink="false">45691@/forums/discussions</guid>
      <description><![CDATA[What's a neat way to change this bit pattern in registers BCDE:
<pre>Loop0:  ;change B:00000000 C:abcdefgh D:ijklmnop E:qrstuvwx
</pre>
to this bit pattern?
<pre>;    to B:0abc0def C:0ghi0jkl D:0mno0pqr E:0stu0vwx
</pre>
I've tried several methods and they all look horrible.]]></description>
   </item>
   <item>
      <title>Clear the screen from assembler</title>
      <link>https://worldofspectrum.org/forums/discussion/45655/clear-the-screen-from-assembler</link>
      <pubDate>Tue, 26 Nov 2013 14:06:30 +0000</pubDate>
      <dc:creator>Mr Millside</dc:creator>
      <guid isPermaLink="false">45655@/forums/discussions</guid>
      <description><![CDATA[I want to clear the screen before I draw my graphic elements on it. Speed is not important so I was thinking of using the rom CLS option if that is possible. Can anyone advise on how to call this command or some similar routine to clear the screen?]]></description>
   </item>
   <item>
      <title>Simple memory transfer routine</title>
      <link>https://worldofspectrum.org/forums/discussion/45648/simple-memory-transfer-routine</link>
      <pubDate>Tue, 26 Nov 2013 08:25:17 +0000</pubDate>
      <dc:creator>daveysludge</dc:creator>
      <guid isPermaLink="false">45648@/forums/discussions</guid>
      <description><![CDATA[I'm looking for a simple memory transfer routine that shifts 32 bytes of data from the address HL is set to 55143, I have tried using LDIR, but cant get it to work properly...<br />

<pre>org 57000
		ld a,(51990)	;level number
		ld b,a		
		ld hl,udg-32	;start of udg data minus 32
loop		push bc
		ld b,32		;8 x 4
loopa		inc hl		;increase pointer
		djnz loopa
		pop bc
		djnz loop
		ld b,32		;hl should now point to level x 32
		ld de,55143	;de pointing to 55143 where the udgs are to be loaded
		ldir		;load 32 bytes from level x 32 to 55143
		ret

udg	defb  0, 0, 0	 ; 62       0   0       0   ts
	defb 0, 56, 46, 3	 ; 0       56   46       3   ts
	defb 7, 0, 0, 0		 ; 7       0   0       0   ts
	defb 0, 0, 96, 108	 ; 0       0   96       108 ts
	defb 12, 0, 6, 54	 ; 12       0   6       54   ts
	defb 48, 6, 6, 0	 ; 48       6   6       0   ts
	defb 0, 192, 218, 26	 ; 0       192 218 26   ts
	defb 192, 218, 24, 192	 ; 192 218 24       192 ts
	defb 216		 ; 216 t
</pre>
]]></description>
   </item>
   <item>
      <title>That painter thing..</title>
      <link>https://worldofspectrum.org/forums/discussion/45633/that-painter-thing</link>
      <pubDate>Sat, 23 Nov 2013 11:09:59 +0000</pubDate>
      <dc:creator>R-Tape</dc:creator>
      <guid isPermaLink="false">45633@/forums/discussions</guid>
      <description><![CDATA[I'm struggling to think of a non clunky way of detecting when a 'box' has been surrounded and can be highlighted, like in the pic:<br />
<br />
<img src="http://i1142.photobucket.com/albums/n608/daveyboyhughes/painter_zpsc4378666.gif" alt="painter_zpsc4378666.gif" /><br />
<span>From the splendid Gamex</span><br />
<br />
The best way I can think of is that a box gets coloured when a counter is zero, and the surrounding blocks decrease a particular counter (or counters for shared boxes).  While this is simple enough it'll be a bit of a paint building the map (ok so not <i>that</i> bad).<br />
<br />
Is there a simpler principle I can work on, or is that pretty much the best way to do it?]]></description>
   </item>
   <item>
      <title>"Press any key" detection</title>
      <link>https://worldofspectrum.org/forums/discussion/45528/press-any-key-detection</link>
      <pubDate>Mon, 11 Nov 2013 16:00:00 +0000</pubDate>
      <dc:creator>na_th_an</dc:creator>
      <guid isPermaLink="false">45528@/forums/discussions</guid>
      <description><![CDATA[What would be the simplest way to detect if *any* key is being pressed? No LAST_K trickery, I can't rely on that. It has to be reading the keyboard ports.<br />
<br />
I have several ideas, but they look dirty. I'm sure there's a really smart and elegant way which just takes a few bytes :)]]></description>
   </item>
   <item>
      <title>ANN: SP1 for Z88DK (aka splib3, Sprite Pack v3.0)</title>
      <link>https://worldofspectrum.org/forums/discussion/11729/ann-sp1-for-z88dk-aka-splib3-sprite-pack-v3-0</link>
      <pubDate>Wed, 26 Apr 2006 22:37:40 +0000</pubDate>
      <dc:creator>Alcoholics Anonymous</dc:creator>
      <guid isPermaLink="false">11729@/forums/discussions</guid>
      <description><![CDATA[Well it's finally arrived, after a month of "a few days from now" release deadlines.  SP1 is the lastest version of splib, a flicker-free software sprite engine.  It has now been integrated into z88dk and has undergone a name-change as a result.  SP1 now stands for "Sprite Package #1" in the optimistic hope that there will be several more options to choose from in z88dk's future.  One of the goals of SP1 is to be a cross-platform sprite engine, which means games written with it will be (relatively) easily portable to other machines supported by z88dk.  Write your game for the Spectrum, but share it with the MSX &amp; CPC communities (and vice versa!).  As of now, only the Spectrum version is completed, but the MSX1 version will arrive shortly (it requires only about 100 lines of additional assembly) and versions for the Amstrad-CPC and TI calculators will follow.<br />
<br />
WHAT IS IT?<br />
<br />
Techno-Babble:<br />
<br />
SP1 is a flicker-free software sprite engine based on a differential update algorithm.  It achieves flicker-free status by never erasing anything on-screen but by only drawing completed graphics all at one go.  It is differential in that it only draws to portions of the screen that have changed since the last screen update.  It is interruptable and imposes no restrictions on the user.  In particular you don't have to synchronize with the raster to achieve flicker-freeness nor is there any restriction on size or number of sprites on-screen, aside from non-functional constraints like speed and available memory.  This <a href="http://www.worldofspectrum.org/forums/showpost.php?p=127318&amp;postcount=22" rel="nofollow">post</a> gives a technical overview of how the engine works.  Eventually I will write up a more complete version but this description will take you a long way in understanding the source code if that is your interest.<br />
<br />
User:<br />
<br />
SP1 is a library of machine code subroutines that makes it easy to draw and animate sprites and backgrounds.  It is *not* a game a designer - you must still be able to program to make a game but this library can provide you with the means to draw flicker-free and smoothly animated sprites and backgrounds on screen.<br />
<br />
It is integrated into z88dk which means you can call the library functions from C, asm, or a mixture of the two.  I have gone to great lengths to make it relatively easy to use.  There is a learning curve, especially if your only background is Basic, and for that reason I've decided to put some fully explained test programs here to make clear how the engine and its features work.  The good news is you will learn a lot about how the machine works and this will make it a lot easier to understand asm if that is your goal.  z88dk (and C) is a great bridge between basic and asm, and even when you become an expert asm programmer, you will still appreciate the speed of development C can offer you and the ease with which z88dk can accommodate your asm code for the heavy lifting.<br />
<br />
DISCLAIMER<br />
<br />
#1  Non-hardware assisted 8-bit machines are primarily limited by cpu speed when it comes to games.  For this reason it is not possible to write a general purpose sprite engine that can do everything you would want it to do.  This is why there is a need for several choices in sprite engines, each with its own strengths and weaknesses, and hopefully there will be many such choices in z88dk's future.  Because of the display algorithm SP1 uses, it is best suited for games where only small portions of the screen changes between updates.  This includes such things as platformers, 3d isometrics, strategy, simulations, board games, and non-scrolling arcade games.  SP1 *cannot* do scrolling well at all.  AT ALL.  I may add some character-level scrolling at some point to accommodate strategy and board games with large playing areas but that is all it would be good for.<br />
<br />
#2 I am using Microsoft debugging strategy.  This release seems to work but likely has bugs in it.  The test programs here will help to discover them so that they can be fixed, but if you locate a bug please let me know right away.<br />
<br />
<br />
WHAT'S NEW FROM SPLIB2<br />
<br />
A lot of stuff under the hood, some on top of it.  In particular (not an exhaustive list):<br />
<br />
1. The library has been split up into machine-independent portions and machine-specific portions so that the codebase can be shared across all z80 platforms in z88dk.<br />
<br />
- #defines for colours, border(), screen address calculations have been added to the standard zx library with prototypes in spectrum.h<br />
- functions to read the keyboard, joysticks and mice have been added to the standard zx library with protoypes in spectrum.h and input.h (the latter are functions available with the same name across platforms).<br />
- abstract data types have been moved to their own library adt.lib with prototypes and some documentation in adt.h.  The adt currently contains: doubly linked list, hash table, heap, queue and stack.<br />
- im2 support has got its own library im2.lib with prototypes and some documentation in im2.h<br />
- inp(), outp() (for reading/writing i/o ports), swapendian() have been added to stdlib.lib and stdlib.h.  No linking necessary.<br />
- the block memory allocator is in its own lib balloc.lib and balloc.h<br />
- the rectangles stuff has not been added to z88dk yet -- the rectangles stuff is for collision detection among sprites and is being rewritten to offer faster options that don't worry about pathological intersection cases.<br />
- data compression has not yet been added to z88dk but was not really in a complete state in splib2 anyway.<br />
<br />
2. The display draw order has changed.  In splib2 the display was drawn in top to bottom, left to right order.  Now the display order depends on the order characters are invalidated!  For this reason your program should draw sprites first before doing background tiles to ensure that each sprite is drawn completely instead of (possibly) in pieces.<br />
<br />
3. SP1's data structures are no longer compiled as part of the final binary.  Instead you can specify the location in memory of its structures.<br />
<br />
4. The final blank column required in splib2 for horizontal pixel placement of sprites is no longer required.  You must still create the final column (the struct sp1_cs must still be allocated) but you can make the graphic pointer point at 0 and you must make the sprite RB type (right border).  The blank row at bottom of the sprite as well as 7 blank pixel rows above each column must still be present.<br />
<br />
5. Sprites can use 1- (graphics only) or 2- (mask, graph) byte definitions.  Note that the (mask,graph) pairs are in a different order than in splib2.  There are now 33 sprite types, all minor variations on MASK,OR,XOR,LOAD but offering some relative speed advantages.  This will be made clear in the first test program.  One totally new kind is the attribute-only sprite, though these sprites still suffer from the move sprite function overhead so it may be faster (though not easier!) to mess with the background tile colours directly instead.<br />
<br />
6.  Sprite colours are now masked.  This allows for things like ink-only or paper-only sprites.  By default sprites are now created transparent colour.  Colouring can be done the same way as in splib2 by iterating over the sprite characters with sp1_IterateSprChar() or the fast way with sp1_PutSprClr().  The latter is meant for use inside the main loop where you may want to choose different colours depending on sprite rotation to minimize colour clash.<br />
<br />
7.  X-thresh and Y-thresh parameter have been added.  These indicate the minimum pixel rotation in the x and y directions, respectively before the last column / row of the sprite will be drawn.  By default they are 1 so that the extra blank column/ row will not be drawn when the sprite is not shifted so that these blank areas do not affect colours on screen.  This is also helpful for small sprites where they may be rotated a number of pixels before they spill into an adjacent character.<br />
<br />
8. Sprite animation frames now use absolute addresses.  When a sprite is drawn, a member of struct sp1_ss will now reveal how many sprite characters are active on display following a move sprite function.<br />
<br />
9. Sprites can sit in 256 planes now rather than 64 in splib2.  This is to help out with 3d isometrics.<br />
<br />
10.  Individual character cells can now be removed (and re-added!) to the sprite engine as the need arises.  Additionally, each character cell can be remapped to any character position on screen.<br />
<br />
11.  Features have been added to quickly animate background tiles.<br />
<br />
<br />
<br />
The next post will describe how to get SP1 and the one after will give an overview and the first test program.]]></description>
   </item>
   <item>
      <title>bitmap address to attribute address</title>
      <link>https://worldofspectrum.org/forums/discussion/45555/bitmap-address-to-attribute-address</link>
      <pubDate>Thu, 14 Nov 2013 11:55:34 +0000</pubDate>
      <dc:creator>na_th_an</dc:creator>
      <guid isPermaLink="false">45555@/forums/discussions</guid>
      <description><![CDATA[I've searched, but I don't seem to find the proper keywords.<br />
<br />
I have a bitmap screen address in DL, character aligned (the address of the top byte of a character). For example $4000 or $4027. Is there a quick way to get the corresponding attribute address fiddling with that bitmap address?<br />
<br />
I'd swear I have seen a snipped which does exactly this laying somewhere in this forums, but I can't seem to find it!]]></description>
   </item>
   <item>
      <title>Beepola vector tables</title>
      <link>https://worldofspectrum.org/forums/discussion/45610/beepola-vector-tables</link>
      <pubDate>Thu, 21 Nov 2013 00:19:30 +0000</pubDate>
      <dc:creator>daveysludge</dc:creator>
      <guid isPermaLink="false">45610@/forums/discussions</guid>
      <description><![CDATA[What are the 'interrupt  vector tables' at FE00?<br />
<br />
Is it interfering with my other routines at 65000 onwards?<br />
<br />
will setting the IVT to ROM make any difference?]]></description>
   </item>
   <item>
      <title>Ending a DJNZ loop prematurely</title>
      <link>https://worldofspectrum.org/forums/discussion/45579/ending-a-djnz-loop-prematurely</link>
      <pubDate>Mon, 18 Nov 2013 09:04:55 +0000</pubDate>
      <dc:creator>daveysludge</dc:creator>
      <guid isPermaLink="false">45579@/forums/discussions</guid>
      <description><![CDATA[How do you exit a DJNZ loop before its finished, I've tried loading b with zero but cant get it to stop.]]></description>
   </item>
   <item>
      <title>Troublesome routine, help needed!</title>
      <link>https://worldofspectrum.org/forums/discussion/45571/troublesome-routine-help-needed</link>
      <pubDate>Sun, 17 Nov 2013 02:29:41 +0000</pubDate>
      <dc:creator>daveysludge</dc:creator>
      <guid isPermaLink="false">45571@/forums/discussions</guid>
      <description><![CDATA[Having problems with this routine, it basically fires a rocket up the screen, but refuses to detect collisions. I'm using attribute blocks for detection as most things are colour coded in the game.<br />
<br />
It runs on a black and blue un-bright background i.e. ATTR value 1 but simply will not detect something in its way, I've tried allsorts to remedy this routine but nowt seems to work...<br />
<br />
Thanks in advance to anyone who can sort this annoyance out! :smile:<br />

<pre>org 30000
		ld hl,rktudg
		ld (23675),hl	;set UDG		


		ld b,17		;countdown from 17
loop
		ld a,b		;load a with value of b
		dec a		;decrease by 1
		ld (rx1),a
		ld a,(rx1)
		inc a
		ld (rx2),a
		inc a
		ld (rx3),a
		inc a
		ld (rx4),a
		inc a
		ld (rx5),a	;load co-ords into print string 
		push bc
		call print	;call the print routine
		pop bc
		djnz loop
		ret
print		ld a,2
		call 5633
		ld de,rktdat
		ld bc,33
		call 8252
		ret
av1		defb 0		;attr co-ord vals
		defb 0
bv1		defb 0
		defb 0
attr		LD A, (rx1)	;calculate ATTR
		LD (av1), A
		LD A, (15)
		LD (bv1), A
		LD A, (av1)
		LD H, 0
		LD L, A
		ADD HL, HL
		ADD HL, HL
		ADD HL, HL
		ADD HL, HL
		ADD HL, HL
		LD DE, 22528
		ADD HL, DE
		LD DE, (bv1)
		ADD HL, DE
		LD A, (HL)
		cp 1
		call nz,0	;reset if rocket hits object
		ret

rktdat		defb 19,1,16,2,22
rx1		defb 17
		defb 15,144,145,22
rx2		defb 18
		defb 15,16,7,146,147
		defb 22
rx3		defb 19,15,16,2,148,149,22
rx4		defb 20,15,150,151,22
rx5		defb 21,15,32,32,22
rx6		defb 22,15,32,32

rktudg		defb  1, 3, 7
		defb 7, 15, 15, 15	 
		defb 12, 0, 128, 192	 
		defb 192, 224, 224, 224
		defb 192, 19, 19, 12	 
		defb 12, 19, 19, 12	 
		defb 12, 48, 48, 192	 
		defb 192, 48, 48, 192	 
		defb 192, 19, 31, 15	
		defb 15, 15, 6, 5	 
		defb 5, 48, 240, 224	 
		defb 224, 224, 192, 64
		defb 64, 19, 59, 59	 
		defb 115, 99, 65, 65	 
		defb 0, 144, 184, 184
		defb 156, 140, 4, 4	 
		defb 0, 0		 ; UDG data
</pre>
]]></description>
   </item>
   <item>
      <title>Map compressor based on ZX7</title>
      <link>https://worldofspectrum.org/forums/discussion/45483/map-compressor-based-on-zx7</link>
      <pubDate>Tue, 05 Nov 2013 12:34:22 +0000</pubDate>
      <dc:creator>antoniovillena</dc:creator>
      <guid isPermaLink="false">45483@/forums/discussions</guid>
      <description><![CDATA[Hi<br />
<br />
I have release a map compressor for "La Churrera" game engine, but can be adapted to any other game. Source code is here (Download TmxCompress.0.20.zip):<br />
<br />
<a href="http://www.mojontwins.com/mojoniaplus/viewtopic.php?f=9&amp;p=44442#p44442" rel="nofollow">http://www.mojontwins.com/mojoniaplus/viewtopic.php?f=9&amp;p=44442#p44442</a><br />
<br />
The map must be created with <a href="http://www.mapeditor.org/" rel="nofollow">Tiled</a>.]]></description>
   </item>
   <item>
      <title>128k programming</title>
      <link>https://worldofspectrum.org/forums/discussion/45524/128k-programming</link>
      <pubDate>Mon, 11 Nov 2013 07:56:31 +0000</pubDate>
      <dc:creator>Kiwi</dc:creator>
      <guid isPermaLink="false">45524@/forums/discussions</guid>
      <description><![CDATA[Ok, I have had the normal man look (ie. not really), I want a good resource for 128k asm programming.<br />
<br />
Mostly just to find out how the RAM bank switching works and the screen switching.<br />
<br />
Any help would be very much appreciated.<br />
<br />
Cheers]]></description>
   </item>
   <item>
      <title>BIFROST* for graphic artists - part 2: static tiles</title>
      <link>https://worldofspectrum.org/forums/discussion/44748/bifrost-for-graphic-artists-part-2-static-tiles</link>
      <pubDate>Sat, 24 Aug 2013 05:16:00 +0000</pubDate>
      <dc:creator>Einar Saukas</dc:creator>
      <guid isPermaLink="false">44748@/forums/discussions</guid>
      <description><![CDATA[This tutorial provides some guidelines for designing multicolor tiles. Before reading this text, it's strongly recommended that you (re-)read <a href="http://www.worldofspectrum.org/forums/showthread.php?t=43060" rel="nofollow">part 1</a> first.<br />
<br />
<br />
<b>COLORS</b><br />
<br />
There's a "price" to pay for using multicolor. The main limitations are reduced playing area (144x144 pixels) and less CPU available for other tasks. When using BIFROST*, you better take good advantage of multicolor (and make sure players can notice the difference) so this "price" will be worth it! Although it doesn't mean everything should have psychedelic coloring, obviously :)<br />
<br />
For instance, look at this multicolor tile:<br />
<br />
<img src="http://i41.tinypic.com/xqb6lf.png" alt="xqb6lf.png" /> * <i>Multicolor tile by R-Tape (from the official <a href="http://www.worldofspectrum.org/infoseekid.cgi?id=0027405" rel="nofollow">BIFROST*</a> demo)</i><br />
<br />
This is a great image, that uses multicolor to add little details... but perhaps too little. It's OK if used among other more colorful images, otherwise most players won't even notice your game is multicolor. Also this particular image wouldn't be much different if it used standard Spectrum attributes:<br />
<br />
<img src="http://i44.tinypic.com/2dl64nd.png" alt="2dl64nd.png" /><br />
<br />
In this case, the only easily noticeable difference above is the foot, although this could be disguised by changing the body color to reduce the contrast between body and foot:<br />
<br />
<img src="http://i39.tinypic.com/29c6ya1.png" alt="29c6ya1.png" /><br />
<br />
For comparison, let's take a look at another multicolor tile:<br />
<br />
<img src="http://i43.tinypic.com/1emhq9.png" alt="1emhq9.png" /> * <i>Multicolor tile by R-Tape (from the official <a href="http://www.worldofspectrum.org/infoseekid.cgi?id=0027405" rel="nofollow">BIFROST*</a> demo)</i><br />
<br />
This example shows a better use of multicolor, adding a lot of detail to this image without "overdoing" it. Using different colors for hair, face, glasses, shirt, pants, gloves and boots all make sense, so it doesn't seem out of place. Here's the same image in further detail:<br />
<br />
<img src="http://i43.tinypic.com/2ivjkw1.png" alt="2ivjkw1.png" /><br />
<br />
Using colorful graphics can make your games seem more impressive, since it should be immediately obvious that this kind of image would be impossible using standard Spectrum attributes:<br />
<br />
<img src="http://i44.tinypic.com/t7br4p.png" alt="t7br4p.png" /><br />
<br />
Again the same image in further detail:<br />
<br />
<img src="http://i44.tinypic.com/24gp1rp.png" alt="24gp1rp.png" /><br />
<br />
Even if you prefer a less colorful visual, there are more subtle ways to achieve a similar result. For instance, let's consider a practical example:<br />
<br />
<img src="http://i41.tinypic.com/34squc0.png" alt="34squc0.png" /> * <i>Graphics by Polomint (from <a href="http://www.worldofspectrum.org/infoseekid.cgi?id=0027065" rel="nofollow">Bozxle</a>)</i><br />
<br />
Although Bozxle is a great game (even more impressive considering most of the work was done within a single week!), it doesn't use multicolor extensively. Therefore this game wouldn't look much different using standard Spectrum attributes (except for the hero):<br />
<br />
<img src="http://i40.tinypic.com/65af46.png" alt="65af46.png" /><br />
<br />
Evidently the game designer made a conscious choice for a more pale, less colorful "look" in this game. And that's perfectly fine. Even so, it's worth considering minor improvements that could take advantage of multicolor a little more, without sacrificing the overall "visual style" chosen for this game. In this case, my suggestion would be adding a green marker at the slot positions. It would make multicolor slightly more evident (thus making the game slightly more impressive), and still make sense since this would help explain the boxes becoming greenish when pushed over these positions:<br />
<br />
<img src="http://i41.tinypic.com/2qjghsz.png" alt="2qjghsz.png" /><br />
<br />
<br />
<b>BACKGROUND</b><br />
<br />
Technically, multicolor means you are free to choose any combination of 2 colors (INK and PAPER) for each 8x1 area. In practice however, most multicolor images need to use the same PAPER color as the background gameplay area, otherwise they may seem "out of place" on screen. For instance, the following image is adequate for a black background:<br />
<br />
<img src="http://i42.tinypic.com/2v8mtde.png" alt="2v8mtde.png" /> * <i>Multicolor tile by R-Tape (from the official <a href="http://www.worldofspectrum.org/infoseekid.cgi?id=0027405" rel="nofollow">BIFROST*</a> demo)</i><br />
<br />
Fortunately there's a trick to minimize background restrictions: draw your multicolor image such that it "touches" one side of the tile area, obstructing the background. Whenever it happens, you won't need the background color there, so you will be free to set both INK and PAPER colors to something else. In this case, the trick was used to draw eyes (yellow &amp; red) and chest details (cyan &amp; white, or green &amp; white) on the right side:<br />
<br />
<img src="http://i40.tinypic.com/i6wbwl.png" alt="i6wbwl.png" /><br />
<br />
<br />
<b>SIZE</b><br />
<br />
It's very tempting to design large enough multicolor images to "fill" the entire multicolor tile, thus obstructing the background on both sides. This would give you even more freedom to choose colors... But this may not be such a good idea! In most cases, it's better to create images with 15x15 pixels (instead of 16x16) and leave some "empty space" to help separate tile images, otherwise your program may look like a colorful mess when displaying lots of tiles together on screen.<br />
<br />
For instance, take a look at this image:<br />
<br />
<img src="http://i40.tinypic.com/2hncm7l.png" alt="2hncm7l.png" /> * <i>Multicolor tile by na_th_an</i><br />
<br />
Perhaps a good way to make it look even better would be adding a nice leaf:<br />
<br />
<img src="http://i42.tinypic.com/14bhriu.png" alt="14bhriu.png" /> * <i>Multicolor tile edited by Einar Saukas</i><br />
<br />
This image may or may not work well in practice, depending on the game that will use it. For games that will show lots of tiles together, this is not a great option (as joefish previously pointed out):<br />
<br />
<img src="http://i39.tinypic.com/15ez47.png" alt="15ez47.png" /><br />
<br />
In this case, you better use a smaller leaf, like this:<br />
<br />
<img src="http://i43.tinypic.com/20k7ko9.png" alt="20k7ko9.png" /> * <i>Multicolor tile edited by joefish</i><br />
<br />
This new design wouldn't have problems even if used several times:<br />
<br />
<img src="http://i44.tinypic.com/5n19p2.png" alt="5n19p2.png" /><br />
<br />
The same applies to other variations, like this:<br />
<br />
<img src="http://i39.tinypic.com/20r2yq9.png" alt="20r2yq9.png" /> * <i>Multicolor tile edited by joefish</i><br />
<br />
It could also be used several times:<br />
<br />
<img src="http://i43.tinypic.com/21a1qt.png" alt="21a1qt.png" /><br />
<br />
It's highly recommended that you always choose the same "empty side" in all your multicolor tiles. This way, you will be able to combine any of them freely. In BIFROST* demo, almost all tile images have 15x15 pixels, leaving an empty pixel line at the top, and another empty pixel column on the left side. Therefore it's easy to distinguish individual images regardless of the way they are used:<br />
<br />
<img src="http://i39.tinypic.com/308v9dy.png" alt="308v9dy.png" /> * <i>Graphics by R-Tape (from the official <a href="http://www.worldofspectrum.org/infoseekid.cgi?id=0027405" rel="nofollow">BIFROST*</a> demo)</i><br />
<br />
Even so, it may be possible to "break" this rule in a few specific cases. For instance, multicolor tiles in Buzzsaw typically leave an empty pixel column on the right side (although this column is sometimes "invaded" by small details such as ears or bandana) and an empty pixel line at the top (although it's "invaded" in tile animations). There's a single exception: wood boxes are large enough to "touch" each other and completely "block" the passage when standing side by side, thus enforcing the idea of an "impenetrable barrier" to indicate that a saw cannot fall between them:<br />
<br />
<img src="http://i42.tinypic.com/35kq169.png" alt="35kq169.png" /> * <i>Graphics by joefish (from <a href="http://www.worldofspectrum.org/infoseekid.cgi?id=0027057" rel="nofollow">Buzzsaw</a>)</i><br />
<br />
Walls in ZEXED work the opposite way: they are tall enough to "touch" each other vertically (to help disguise the tile grid), but they keep some distance on each side to help the player measure horizontal distances (which is important for a puzzle game based on horizontal movement):<br />
<br />
<img src="http://i39.tinypic.com/30218c4.gif" alt="30218c4.gif" /> * <i>Multicolor graphics by R-Tape, background graphics by Einar Saukas (from "ZEXED" beta version)</i><br />
<br />
Even so, boxes and walls in Bozxle completely ignore this rule, using the entire 16x16 pixels area. However it works fine in this game, since wall tiles are almost only used to surround the playing area (giving the impression of a continuous wall), and boxes are not a problem since there's usually enough empty space around them anyway:<br />
<br />
<img src="http://i41.tinypic.com/34squc0.png" alt="34squc0.png" /> * <i>Graphics by Polomint (from <a href="http://www.worldofspectrum.org/infoseekid.cgi?id=0027065" rel="nofollow">Bozxle</a>)</i><br />
<br />
There are even situations where certain multicolor tiles are designed to look slightly "confusing" on purpose. In "Knights &amp; Demons DX", the marching knights seem to stay "in line" and keep some distance from each other, like a well organized army. However the flying demons touch their neighbours when flapping their wings, giving the impression of a chaotic out-of-control attack horde. This combination creates a perfect atmosphere for the game, intended to represent all the action from an ongoing battle between good and evil, order and chaos:<br />
<br />
<img src="http://i44.tinypic.com/64q6v4.gif" alt="64q6v4.gif" /> * <i>Graphics by Baron Ashler (from <a href="http://www.worldofspectrum.org/forums/showthread.php?t=44470" rel="nofollow">Knights &amp; Demons DX</a>)</i><br />
<br />
You may compare this effect with the "alternate" release of "Knights &amp; Demons DX", that uses a more conventional graphic design for the demons. This change made the game less confusing and thus somewhat more comfortable to play for some people, although slightly less atmospheric:<br />
<br />
<img src="http://i40.tinypic.com/2mwbdd0.gif" alt="2mwbdd0.gif" /> * <i>Graphics by Baron Ashler (from "alternate" version of <a href="http://www.worldofspectrum.org/forums/showthread.php?t=44470" rel="nofollow">Knights &amp; Demons DX</a>)</i><br />
<br />
<br />
<b>CONCLUSION</b><br />
<br />
Besides the technical considerations explained above, there isn't much more to learn regarding multicolor design. Everything else will mostly depend on your artistic talent, creativity and quite a lot of practice.<br />
<br />
If you would like some help to improve your coloring skills, I suggest reading this <a href="http://www.yarrninja.com/pixeltutorial/" rel="nofollow">pixel art tutorial</a>. But keep in mind that those techniques cannot be applied directly to multicolor 8x1 without adapting them first!<br />
<br />
In my next tutorial I will provide some advice on designing animated multicolor tiles. In the meantime, feel free to ask your questions in this thread, or even post your early multicolor designs so others can help suggesting further improvements. :)]]></description>
   </item>
   <item>
      <title>SE Basic IV Buffy v4.1 source (WIP)</title>
      <link>https://worldofspectrum.org/forums/discussion/45331/se-basic-iv-buffy-v4-1-source-wip</link>
      <pubDate>Sat, 19 Oct 2013 09:33:35 +0000</pubDate>
      <dc:creator>chev</dc:creator>
      <guid isPermaLink="false">45331@/forums/discussions</guid>
      <description><![CDATA[I've been doing a major refactor on the SE Basic source and I'd appreciate a code review from anyone who has time to look at it. I've almost certainly introduced some new bugs and it's pretty unlikely that I'm going to spot them as I don't have a comprehensive test suite for the ROM. The source is all GPLv2, derived from the ZX81 ROM and the SAM Coupe ROM and published with the permission of John Grant and Andrew Wright. In this version I've switched to Logan/O'Hara labelling to make it easier to compare against the 1982 ROM. Sorry about the formatting, but using tabs keeps it under the character limit.]]></description>
   </item>
   <item>
      <title>clang/llvm backend for Z80?</title>
      <link>https://worldofspectrum.org/forums/discussion/45429/clang-llvm-backend-for-z80</link>
      <pubDate>Wed, 30 Oct 2013 12:44:23 +0000</pubDate>
      <dc:creator>Winston</dc:creator>
      <guid isPermaLink="false">45429@/forums/discussions</guid>
      <description><![CDATA[Every so often I feel tempted to revisit assemblers/compilers etc. I had (for unrelated to Z80 reasons) the need to have a look at the clang compiler/LLVM backend (basically to compare optimization behaviour with GCC), and thought "I wonder...with the way this toolchain works, has anyone tried to make a Z80 backend for it"?<br />
<br />
Searching the internet has shown some talk about it and a git repository (which seems to be just the clang/llvm source tree, and a few messages where people are asking "I'm writing a backend for z80 but when I do foo I get bar"). I'm just wondering if anyone here is playing around with this toolchain and whether it'll really be possible to use it for Z80. I seem to remember some talk about gcc not being suitable because of the architectural limits of the Z80 (despite the GNU project putting out a pretty decent Z80 assembler). Now if z88dk could use Clang/LLVM perhaps it'll add some useful features that are missing from the current compiler. But given that we all do this for fun it may be just too large of a job (I'd imagine going this route would be a pretty radical change).<br />
<br />
I'll stop before I start rambling...]]></description>
   </item>
   <item>
      <title>Collision detection for interlocking shapes</title>
      <link>https://worldofspectrum.org/forums/discussion/45410/collision-detection-for-interlocking-shapes</link>
      <pubDate>Mon, 28 Oct 2013 12:53:58 +0000</pubDate>
      <dc:creator>Mr Millside</dc:creator>
      <guid isPermaLink="false">45410@/forums/discussions</guid>
      <description><![CDATA[<span><span>I?m looking for some advice as I?m not sure how to resolve the following problem. I have an in memory structure that holds information about shapes. Note that the shapes are drawn / displayed as coloured attributes and not as a pixel / line representation.</span></span><br />
<br />
<span><span>X</span></span><br />
<span><span>Y</span></span><br />
<span><span>Height</span></span><br />
<span><span>Width</span></span><br />
<span><span>Screen Address</span></span><br />
<span><span>Number of elements that make up the shape</span></span><br />
<span><span>List of elements that define how the shape is drawn (see below)</span></span><br />
<br />
<span><span>The list of elements defines where each part of the shape is drawn based on the previous position. For example, if I wanted to draw an ?L? shape the structure could look like this:</span></span><br />
<br />
<span><span>0 ; X position</span></span><br />
<span><span>0 ; Y Position</span></span><br />
<span><span>3 ; 3 characters high</span></span><br />
<span><span>2 ; 2 characters wide</span></span><br />
<span><span>22528 ; starting address</span></span><br />
<span><span>3 ; 3 elements to draw, note that the item placed at 22528 is not included as part of the elements list</span></span><br />
<span><span>32 ; Add 32 to the starting address (so directly below the first item drawn at 22528</span></span><br />
<span><span>32 ; Add 32 to the item drawn previously, so again directly below it.</span></span><br />
<span><span>1; Add 1 to the item drawn previously so this would be drawn to its right.</span></span><br />
<br />
<span><span>I would now have an image on the screen starting at 22528 in this shape:</span></span><br />
<br />
<span><span>H</span></span><br />
<span><span>H</span></span><br />
<span><span>HH</span></span><br />
<br />
<span><span>I have code that draws these and all works fine. I now want to test for collision so that the shapes cannot overlap. At first I decided to use collision detection based to the X,Y and Width &amp; Height of each shape, which would work. I then realised that the shape bounding rectangles could overlap but the shapes wouldn't necessarily be touching. They could interlock, for example:</span></span><br />
<br />
<span><span>HMM</span></span><br />
<span><span>H M</span></span><br />
<span><span>HHM</span></span><br />
<br />
<span><span>I'm now thinking of using the bounding rectangles to do some basic "fast" collision detection and then looking more carefully when this is detected to see if any of the individual shape elements are actually touching. My first thought was to create a list of attribute address for the two shapes I am checking and then testing for matching addresses. For the type of game I am writing, both speed and memory size aren't too important so I guess I'm looking for a way of testing that just works and could be refactored at a later date if required. Anyone got some views on this? Could I change the way I hold the shape data to make the collision detection easier?</span></span>]]></description>
   </item>
   <item>
      <title>z88dk and im2</title>
      <link>https://worldofspectrum.org/forums/discussion/45401/z88dk-and-im2</link>
      <pubDate>Sun, 27 Oct 2013 19:06:57 +0000</pubDate>
      <dc:creator>slenkar</dc:creator>
      <guid isPermaLink="false">45401@/forums/discussions</guid>
      <description><![CDATA[I set up a minimal IM2 mode so I can draw sprites for a laff<br />

<pre>
#include &lt;string.h&gt;
#include &lt;stdio.h&gt;
#include &lt;im2.h&gt;
#include &lt;stdlib.h&gt;
#include &lt;threading/preempt.h&gt;
#include &lt;threading/semaphore.h&gt;


threadbase_t   threadbase;              // Global threadbase
sem_t sem;


void thread1()
{
    while(1) {
	sem_wait(&amp;sem);
	
       // printf(&quot;thread 1  &quot;);
	
	
	
	#asm

	
	
	LD BC,255
	LD DE,04000h
	LD HL,37000
	
	
	//copy backbuffer to screen	
	LDIR
	
	
	
	#endasm
	
	sem_post(&amp;sem);
    }
    /* A thread mustn't exit! or thread_exit() must be called beforehand */
}

int main()
{

    /* Disable interrupts to start off with */
   sem_init(&amp;sem,0,1);
#asm
   di
#endasm
   printf(&quot;Setting im2\n&quot;); 
   im2_Init(0xd300);                // place z80 in im2 mode with interrupt vector table located at 0xd300
   
   memset(0xd300, 0xd4, 257);       // initialize 257-byte im2 vector table with all 0xd4 bytes
   bpoke(0xd4d4, 195);              // POKE jump instruction at address 0xd4d4 (interrupt service routine entry)
   wpoke(0xd4d5, thread_manager);   // POKE isr address following the jump instruction

   printf(&quot;Manager init\n&quot;); 
   thread_manager_init(roundrobin_scheduler(4));
   printf(&quot;Manager start\n&quot;);
   thread_manager_start();          // Create the main thread, this will start the manager up and enable interrupts
 
   // From here we'll be running in multi-task mode
 
   // Now we can add threads */
   printf(&quot;Create thread\n&quot;); 
   thread_create(thread1,65000,1);
   
   #asm
   	LD BC,37000
	LD L,0
	
	//draw some bytes to the backbuffer at 32000
writeagain:
	
	LD (BC),A
	INC BC
	INC A
	CP 0
	JP NZ,writeagain
   #endasm
   while ( 1) {
	sem_wait(&amp;sem);
        //printf(&quot;main thread &quot;);
  switch( getk() ) {      /* Use OZ to get the key */
                case 'a':
                        printf(&quot;hello&quot;);
                        
					}
	sem_post(&amp;sem);
   }

}
</pre>
<br />
but the keyboard scanning doesnt work<br />
<br />
I tried reading the keyboard with assembly but z88dk says it cant find 'in'<br />
<br />
(compiled with zcc +zx -vn preempt.c -lndos -create-app -othreading.bin -lpreempt -lim2 -lm)<br />
<br />
EDIT- if I put<br />
#asm<br />
rst 56<br />
#endasm<br />
<br />
in the main thread it 'works' but doesnt detect about half of my keypresses<br />
<br />
if I put it in the secondary thread it never works<br />
<br />
<br />
when trying to do it all in assembly it says 'unexpected end of file'
<pre>  
#include &lt;string.h&gt;
#include &lt;stdio.h&gt;
#include &lt;im2.h&gt;
#include &lt;stdlib.h&gt;


int main()
{
	#asm
	  	LD BC,37000
	
	
	//draw some bytes to the backbuffer at 37000
writeagain:
	
	LD (BC),A
	INC BC
	INC A
	CP 0
	JP NZ,writeagain
	
     org 51400
	int
    push af             ; preserve registers.
       push bc
       push hl
       push de
       push ix
       rst 56    
	
	LD BC,255
	LD DE,04000h
	LD HL,37000
	
	
	//copy backbuffer to screen	
	LDIR
                 ; ROM routine, read keys and update clock.
       pop ix              ; restore registers.
       pop de
       pop hl
       pop bc
       pop af
       ei                  ; always re-enable interrupts before returning.
       reti                ; done.
       ret

       org 65024

       ; pointers to interrupt routine.

       defb 200,200,200,200
       defb 200,200,200,200
       defb 200,200,200,200
       defb 200
       
       di                  ; interrupts off as a precaution.
       ld a,200            ; high byte of pointer table location.
       ld i,a              ; set high byte.
       im2                 ; select interrupt mode 2.
       ei                  ; enable interrupts.
       #endasm
       
       }
</pre>
]]></description>
   </item>
   <item>
      <title>How to make Zx Spectrum graphics and animation (videotutorials)</title>
      <link>https://worldofspectrum.org/forums/discussion/45403/how-to-make-zx-spectrum-graphics-and-animation-videotutorials</link>
      <pubDate>Sun, 27 Oct 2013 19:22:30 +0000</pubDate>
      <dc:creator>Leander</dc:creator>
      <guid isPermaLink="false">45403@/forums/discussions</guid>
      <description><![CDATA[Hi all!<br />
Im a experienced pixel artist since 25 years ago, i uploaded some tutorials that i hope you help to develope graphics for Zx Spectrum.<br />
Enjoy! Thanks and sorry my english, im spanish.<br />
<br />
<a href="http://youtu.be/3Eayb52JacU" rel="nofollow">MAKING SPRITES AND ANIMATING</a><br />
<br />
<a href="http://youtu.be/MuLywpXLey0" rel="nofollow">DRAWING TILES</a><br />
<br />
No sound in videotutorials sorry, but these are easy to follow.]]></description>
   </item>
   <item>
      <title>A few questions about ZX Spectrum assembly</title>
      <link>https://worldofspectrum.org/forums/discussion/45268/a-few-questions-about-zx-spectrum-assembly</link>
      <pubDate>Mon, 14 Oct 2013 03:18:20 +0000</pubDate>
      <dc:creator>Zerg</dc:creator>
      <guid isPermaLink="false">45268@/forums/discussions</guid>
      <description><![CDATA[Hi,<br />
<br />
I have a few questions about ZX Spectrum assembly language programming:<br />
- What's the best assembly tool for ZX Spectrum? I tried a bit the ZXSpin integrated assembler and it seems to be very nice, since you can assemble directly to memory and then run programs from Basic. It gives a lot of errors (bugs) but it works though. Is there another better assembler than that?<br />
- I would like to learn a bit how to use Zeus Assembler. Is there any documentation or tutorial?<br />
- The ZXSpin assembler has directives? I would like to define .Byte, .Word and string variables but I have no idea how to do it.<br />
<br />
Thanks]]></description>
   </item>
   <item>
      <title>filled shape creating code</title>
      <link>https://worldofspectrum.org/forums/discussion/45245/filled-shape-creating-code</link>
      <pubDate>Fri, 11 Oct 2013 11:02:27 +0000</pubDate>
      <dc:creator>jamorski</dc:creator>
      <guid isPermaLink="false">45245@/forums/discussions</guid>
      <description><![CDATA[Development is continuing well on a resurrected project of mine from about 20 years ago. Speed and size optimizations are going well along with display engine testing.<br />
However, an offshoot of it that I developed ideas and graphics for needs a type of routine that I've not attempted to write before.<br />
<br />
I need a filled 4 sided shape creating routine. Ideally give it 4 sets of X,Y coordinates and it draws the filled shape.<br />
<br />
Needs to be fast as hell though!]]></description>
   </item>
   <item>
      <title>Rendering clipped glyph</title>
      <link>https://worldofspectrum.org/forums/discussion/45390/rendering-clipped-glyph</link>
      <pubDate>Sat, 26 Oct 2013 12:25:25 +0000</pubDate>
      <dc:creator>tstih</dc:creator>
      <guid isPermaLink="false">45390@/forums/discussions</guid>
      <description><![CDATA[Sometimes you need to render a glyph of arbitrary size to the screen. And clip it.<br />
<br />
For example: drawing a mouse cursor means combining drawing of a 16x16 mask, glyph, and an off screen clipping to get the effect of mouse almost leaving the screen at right and bottom corners.<br />
<br />
Also a letter of a specific font can be drawn inside a window using a function like this -<br />

<pre>draw_clipped_glyph(
   glyph_t *glyph, 
   byte x, 
   byte y, 
   rectangle_t *clip_rect);
</pre>
<br />
My questions are:<br />
1) Has anyone ever done anything that remotely resembles this problem on ZX Spectrum,<br />
2) What were the optimizations he or she used?<br />
<br />
Here are some I can think of:<br />
<br />
1) Use precalculated vmem address table (using standard trick with two tables on 256 byte boundary for fastest vmem address calculations),<br />
<br />
2) Before you do any drawing ... calculate intersection of rows of clipping rectangle and glyph rectangle and make sure you only draw rows of glyph that need to be drawn,<br />
<br />
3) Also calculate intersection of columns of clipping rectangle and glyph and create start (first column) and end (last column) mask which you will apply using AND to first and last column. For example if drawing area is from point 7 to point 12 then first byte mask will be 11111110 and end byte mask will be  00000111. You will first AND the screen with this mask and then OR the shifted glyph to the screen.<br />
<br />
4) Do as much shifting as possible inside registers. Use alternate set if needed. Question: if you need to start drawing something at pixel 26 then you know that you will need to shift everything 2 bits to the right. What is the optimal algorithm to do it? (...what is the optimal generic algorithm to shift for N bits...also note that sometimes it is faster to shift left for the same effect).<br />
<br />
5) Using precomputed mask. For example if your letter "I" width is 3 pixels starting from pixel 1 then you store 10001111 mask at start of glyph definition so that you don't need to prepare it every time. When drawing a letter you AND every row of the screen with the mask and then OR the letter I over it.<br />
<br />
6) Organize glyph_t structure in a way that follows your drawing code needs. This way you don't have to recalculate addresses. Best is to have pointer (HL) pointing to the data inside structure that you will need when executing next operation. For example if you need to advance certain amount of pixels to the right after drawing a letter of a font, put this number at the end of glyph definition so that HL naturally points to it after last glyph data has been transferred to the screen.<br />
<br />
Regards,<br />
Tomaz]]></description>
   </item>
   <item>
      <title>Nasty 'Gotcha' for multicolour timing</title>
      <link>https://worldofspectrum.org/forums/discussion/45374/nasty-gotcha-for-multicolour-timing</link>
      <pubDate>Wed, 23 Oct 2013 17:39:43 +0000</pubDate>
      <dc:creator>joefish</dc:creator>
      <guid isPermaLink="false">45374@/forums/discussions</guid>
      <description><![CDATA[I thought I would be better developing my multicolour routine on the 48K first, being the slowest, so it would then be sure to work on the 128K variants.  Turns out I was wrong...<br />

<blockquote>
<div><a rel="nofollow" href="/forums/profile/4929/joefish">joefish</a> wrote: <a rel="nofollow" href="/forums/discussion/comment/731218#Comment_731218"><span>»</span></a></div>
<div>I'm having a bad time with multicolour at the moment.  I've just written a routine that seems so awkward it even throws up timing differences between the 128K and the ordinary +2.  I've never had too much trouble with the +2A before either, but this one seems to hit all the most awkward contention.</div>
</blockquote>
I think I've found the problem with the +2A.  I've used LD (nn),HL , then I've used the same twice again but with other registers.  This is to lay down a few bytes of colour so I don't have to move the stack away from the attribute data I'm POPping from (at least until I'm ready to do a big block of PUSHes all at once).<br />
<br />
Now whether you use DE, BC, IX or IY, the instructions all take the same form which is one prefix byte longer than using HL.  There's even a slower duplicate of the command using HL, again with the prefix scheme.<br />
<br />
The nasty trick is, if you perform two of these back-to-back in contention, the delay from the end of one write to the start of the next one is 17 cycles.  On earlier Spectrums, with two uncontended cycles in every 8, you can get away with it.  On a +2A, with only one uncontended cycle in 8, you miss the next slot and have to wait another 7 cycles.  And that's a longer delay than the 4 bonus cycles you get for upgrading from a 48K.  I've not had one like that before.<br />
<br />
I think I can do LD (nn),IX followed by LD (nn),HL since the delay between memory operations is then only 13 cycles (extended to 16 by contention).  But then I should probably re-arrange my code to do another POP (or two, e.g. POP IX and POP Hl to refill those registers with new data) before the next LD(nn),DE or whatever, to get ahead on the contention cycle.  Assuming that writing those colours a bit later doesn't cause trouble elsewhere...]]></description>
   </item>
   <item>
      <title>Copy 4Kb in Assembly?</title>
      <link>https://worldofspectrum.org/forums/discussion/45321/copy-4kb-in-assembly</link>
      <pubDate>Fri, 18 Oct 2013 18:28:06 +0000</pubDate>
      <dc:creator>Einar Saukas</dc:creator>
      <guid isPermaLink="false">45321@/forums/discussions</guid>
      <description><![CDATA[Here's an interesting problem: what's the best way to copy a block of 4Kb in assembly?<br />
<br />
The most obvious solution is to use <b>LDIR</b>:
<pre>    ld hl,SOURCE
    ld de,TARGET
    ld bc,4096
    ldir
</pre>
<br />
The routine above runs in 86041T, thus taking 86041/4096 = 21T per byte on average. Also the code is fairly small: only 11 bytes.<br />
<br />
A straightforward optimization is to copy bytes using a long "unrolled loop" sequence of <b>PUSH</b>es. In this case, we could use 292 blocks that copy 14 bytes each, and and extra block that copies 8 bytes:
<pre>REPT 292, COUNTER
    ld sp,SOURCE+COUNTER*14
    pop hl
    pop de
    pop bc
    exx
    pop hl
    pop de
    pop bc
    pop af
    ld sp,TARGET+(COUNTER+1)*14
    push af
    push bc
    push de
    push hl
    exx
    push bc
    push de
    push hl
ENDR    
    ld sp,SOURCE+292*14
    pop hl
    pop de
    pop bc
    pop af
    ld sp,TARGET+(292+1)*14
    push af
    push bc
    push de
    push hl
</pre>
<br />
The routine above runs in 51204T, thus taking 51204/4096 = 12.5T per byte on average. However the code above is 6438 bytes long! Most Spectrum games won't have so much memory available just to copy a block of bytes.<br />
<br />
Perhaps a more realistic definition for "best way to copy 4Kb" would be "fastest routine under 512 bytes to copy 4Kb" for instance.<br />
<br />
The most direct approach would be taking the <b>PUSH</b> method above, and try to "roll the loop" again. In this case, it seems more efficient to use an initial block that copies 16 bytes, and repeat 204 times another block that copies 20 bytes:
<pre>    ld hl,counter_addr
    ld (hl),204
    ld sp,SOURCE+4096-16
    pop hl
    pop de
    pop bc
    pop af
    ex af,af'
    exx
    pop hl
    pop de
    pop bc
    pop af
    ld sp,TARGET+4096
    push af
    push bc
    push de
    push hl
    ex af,af'
    exx
    push af
    push bc
    push de
    push hl
    ld (dest+1),sp
    ld sp,SOURCE+4096-32
loop:
    pop hl
    pop de
    pop bc
    pop af
    ex af,af'
    exx
    pop hl
    pop de
    pop bc
    pop af
    pop ix
    pop iy
dest:
    ld sp, 0
    push iy
    push ix
    push af
    push bc
    push de
    push hl
    ex af,af'
    exx
    push af
    push bc
    push de
    push hl
    ld (dest+1),sp
    ld hl,SOURCE-TARGET-16
    add hl,sp
    ld sp,hl
    ld hl,counter_addr
    dec (hl)
    jr nz,loop
    ...
counter_addr:
    defb 0
</pre>
<br />
This looks much better. The routine above runs in 67365T, thus taking 67365/4096 = 16.45T per byte on average, and it takes only 85 bytes.<br />
<br />
However there's a much better, simpler solution using <b>LDI</b>:
<pre>    ld hl,SOURCE
    ld de,TARGET
    ld bc,4096+128*256
loop:    
REPT 32    
    ldi
ENDR    
    djnz loop
</pre>
<br />
The routine above runs in 67225T, thus taking 67225/4096 = 16.41T per byte on average, and it takes only 75 bytes!<br />
<br />
I found these results interesting and somewhat surprising. So I decided to share these results in case someone else would be interested, and perhaps could offer additional suggestions for improvements! :)]]></description>
   </item>
   <item>
      <title>Spectranet tutorial - libsocket?</title>
      <link>https://worldofspectrum.org/forums/discussion/45310/spectranet-tutorial-libsocket</link>
      <pubDate>Thu, 17 Oct 2013 23:23:17 +0000</pubDate>
      <dc:creator>szeliga</dc:creator>
      <guid isPermaLink="false">45310@/forums/discussions</guid>
      <description><![CDATA[To cut to the chase, does "libsocket.lib" exist?!<br />
<br />
It's been an awfully long time since I've used a C compiler so I could be doing something dumb, but I've been looking at the <a href="http://spectrum.alioth.net/doc/index.php/Spectranet:_Tutorial_2" rel="nofollow">TCP server example</a> that says "<span><i>C users, using the Z88DK should include the relevant includes - normally at least &lt;sys/socket.h&gt; and &lt;sys/types.h&gt;, and link with the library libsocket.</i></span>"<br />
<br />
So I installed z88dk, saved the example source file and tried compiling with the command<br />

<pre>zcc +zx simpleserv.c -llibsocket -v
</pre>
<br />
and was told that <i>libsocket.lib</i> couldn't be found.<br />
<br />
I am assuming that this is not part of z88dk (seeing as I couldn't find it manually) and that maybe it doesn't exist since the <a href="http://spectrum.alioth.net/doc/index.php/Software" rel="nofollow">Software page of the wiki</a> says, "<i><span>The most important part is probably the socket library. This</span> <b><span>will </span></b> <span>provide a subset of the BSD socket library. The plans are for three equivalent libraries...</span></i>"]]></description>
   </item>
   </channel>
</rss>