As i spend most of my days using developer studio, i have found that i love using it as an editor.  This use to cause me problems when i had to switch to other editors / system.  To be fair back in the day i loved comet assembler on the Sam, it was much better than the first one i used. I cant remember the name of it now, it was tape based and had line numbers!  I think it may have  been Lerm assembler, feel free to comment if you know the one it was.  I still love comet, but unfortunately the years have passed and my eyes dont like programming at that resolution any more.  Given that all my tools are PC based it also makes sense to keep everything on the PC.

I have used visual studio to develop Sam Stuff in the past, i started using pasmo but as its spectrum based its hard to use it for multi memory bank building.  I recently switched over to Andrew Collier’s pyz80 as it is compatible with comet style which i am used to.  Normally I use use developer studio to write the code then have batch files to build and run the code.  All the projects ive been working on until now use SamDisk to send the code over to my actual Sam Coupe hardware using the Trinity network card.  While this is my preferred choice, i needed to do this while not in my office.  This meant no real hardware, so i dropped to the emulator and built a disk image and ran it direct via the batch file.

Having setup the development stuff i started writing some code.  The first job was to knock up a test for the block / map exported.  The problem with the Sam Coupe is often accessing graphics and screen all at the same time, especially when your graphic blocks take up 180k.  My initial test stuck the code at 0x8000, disabled the interrupts and then paged the map data into the lower memory.  Once i had found the details for the block i needed i could page in the screen to the lower memory.  Problem… code in upper memory, screen in lower memory…. Where the hell do i page the graphics to, i could page them into lower memory, copy the block to upper memory, page the screen back to lower memory etc… all too slow.  To be fair this was a problem i had encountered many years ago on the Sam so knew the best (in my opinion) solution.  The screen only takes up 24k of the total 32k of the lower memory.  This leaves 8k of space above the screen.  You stick your drawing routines in there so when you page in your screen and call the drawing routine, it is free to page in the graphics to the other memory banks.  This is what I did.

So now my code sat at 0x8000, paged in the map data to lower memory, got the details for the block it wanted, paged the screen in and called the draw for the block in question.  The draw call was sitting just above the screen and this in turn paged in the block to address lookup table (a series of 3 bytes for every block giving the page and offset to the start location of the data).  Having read the details for the required block it paged in the required page so the data was there.

This is where i hit my first design issue.  Using 16 bit x and y coordinates did give me the range i needed to draw things off the edges of the screen, but thats a lot of registers used just storing the details before you even start with clipping.  I looked at various options before it became clear that 16bits was too much.  This along side that fact that trying to draw on single pixel boundaries was maybe a little ambitious.  I knew the spectrum only drew things on 4 pixel boundaries so i decided that maybe i could get away with using 2 pixel boundaries on the Sam Coupe.  This works well as in screen mode 4 a byte holds 2 pixels, so dropping to 2 pixel boundaries means a) you are working with bytes, not nibbles when you draw and b) your x coordinates range from 0 – 128.  Having altered this, i dropped the range on x to -64 -> 192. This gave me the 0 – 127 for the screen with a 64 pixel guard-band around the screen.  The Y coordinate isnt such a problem as the screen is only 144 high so i allow 48 for the top clipping as this is the size of the panel and the rest of bottom clipping giving a range of -48 -> 208 which works very nicely as everything on the amiga maps fits this.  These alterations also mean the x and y coordinates are now both bytes.

I updated the exported and altered the code.  Initially i decided to ignore anything that needed clipping and just concentrate on the draw.  Soon enough something appeared that I was pleased with.

I was a happy bunny… It looked just like the Amiga version, but it needed the clipping.  Whether its because its been a while since i programmed z80, or whether its because it really is a pain to do clipping on the values i had, but it took a while to get the clipping working as expected.  But once it was done (and bug fixed) i was finally able to see it was all worth it.

The last thing i added at this point was a very basic keyboard reading routine to allow me to use the cursor keys to move around the  screens.  This allowed me to check all the screens worked.  Unfortunately it highlighted there were a couple of points where graphics moved slightly due to the 2 pixel boundary, but these would be simple enough to fix in the editor.  The other thing that was noticeable was how long it took to draw the screen….