www.retrosoftware.co.uk
http://www.retrosoftware.co.uk/forum/

The Source for Sparse Invaders
http://www.retrosoftware.co.uk/forum/viewtopic.php?f=42&t=379		 Page 1 of 3
Author:  NeilB [ Thu Oct 29, 2009 1:46 pm ]
Post subject:  The Source for Sparse Invaders
Hi Gang,

----------------------------------------
UPDATE!!!

New source zip added, this contains the sound and relocation code, plus works with the latest SWIFT!

----------------------------------------

here's the source for Sparse invaders ... I'm trying to hurry to actually get something up, for you guys to check over.

I've nabbed a GNU license and added a comment in the source files ... I just get so confused as to the best practise here ... "It's freeware for non-commerial use" ... Would be great to get feedback on this.

Once that's sorted, I'll write up some info and place it on the wiki - hopefully for all to use!

I'll await your feedback!!!

Thanks in advance
Neil

Attachments:
File comment: Builds with Swift, includes the binaries needed and project file.
This version has the sound and relocation in,plus works on both the BBC B and the Master.
SparseInvaders.zip [57.48 KiB]
Downloaded 13 times
Author:  SteveO [ Fri Oct 30, 2009 11:09 am ]
Post subject:  Re: The Source for Sparse Invaders
Nice to see you back Neil.

I've tried loading into my version of Swift (4.2.1) and it's not happy when I try to assemble. I'm just trying to figure out if there's an issue I should be looking at. If you download this source to your desktop does it load and run ok for you in your Swift. If so which version are you using ?
Author:  NeilB [ Fri Oct 30, 2009 5:20 pm ]
Post subject:  Re: The Source for Sparse Invaders
Hi Steve,

good to see you on here as well!

The source loads well and runs - err, the version of Swift is quite old, it's

4.0 Beta r3

I need to try and remember what I wanted to chat to you about.... I think I had problems when I added the relocation code, the expression that comes to mind is .. Knickers in a twist! :lol:

If you need the binary I'll be happy to send it over to you, but I expect you have source control or something similar.

I'll have to have another play, and of course I'll have to get the latest Swift... Err looking forward to seeing the additions,

thanks - Neil
Author:  NeilB [ Fri Oct 30, 2009 11:22 pm ]
Post subject:  Re: The Source for Sparse Invaders
Oh err, see what you mean... I'm having a few issues with the new SWIFT.

My first impressions on the 'no .Org' in the source in the project manager is that it's not finding the '.merge' commands in main... just a theory.

I've also tried to create a new project and it does not like the sprite-collections, have you changed the format saved? It says something to the effect of 'Unable to find sprite 0 at bottom of data - hmmm something like that... It then terminated very quickly.

Unless there is some quick fix to this all, I do have all the exe's that allow my other version of swift to build the invader code and run it. This means it can be placed on site and used until time that a solution is found that ables it to be build.

Anyway - I'll await your feedback on this Steve,
many thanks Neil
Author:  Samwise [ Sat Oct 31, 2009 1:03 am ]
Post subject:  Re: The Source for Sparse Invaders
NeilB wrote:
I've nabbed a GNU license and added a comment in the source files ... I just get so confused as to the best practise here ... "It's freeware for non-commerial use" ... Would be great to get feedback on this.

Neil,

If you release the code under GPL v3, you can't restrict the license to non-commercial use only. GPL is specifically designed to allow anyone to use the code, for any purpose - even making money off it - provided that they release further development of the source code back to the community.

For retro game source code like this, I sincerely doubt anyone's going to attempt to profit from it, so I think GPL is probably a good choice - but you have to accept the caveat that, technically, it could be used for commercial purposes.

I think officially you're also meant to include the appropriate GPL text on the SSD image. This was done on Farmyard Fun too so you could just copy the files straight from that SSD. I'll look over the legally stuff for you, if you want, when you've settled on a "release" version of Sparse Invaders. We can also move it from the WIP section to the Releases page too, when you're ready.

We've discussed licensing before in the Software Release Licensing and Open vs Closed source topics.

Sam.
Author:  SteveO [ Sat Oct 31, 2009 10:36 am ]
Post subject:  Re: The Source for Sparse Invaders
Yes, there was post in the Swift thread some time back about the graphics expanding and changing slightly (would not effect your sprite plotting code as the core format for the beeb is the same). But I endeavoured to get Swift to convert the old formats automatically.

Due to issues rising in the latest version I'm putting it back in bet. It sat there for ages with no feedback and s soon s I thought it was safe to take it out of bet issues have appeared :lol: typical :)

Stick with your old version for now and I'll work on the new version so it correctly (s it should) accept your project. I'll use the project you posted s my working test.
Author:  MartinB [ Sat Oct 31, 2009 9:26 pm ]
Post subject:  Re: The Source for Sparse Invaders
SteveO wrote:
Due to issues rising in the latest version I'm putting it back in bet. It sat there for ages with no feedback and s soon s I thought it was safe to take it out of bet issues have appeared typical

Stick with your old version for now and I'll work on the new version so it correctly (s it should) accept your project. I'll use the project you posted s my working test.
Unless you get that 'a' key fixed Swift will stuck in beta forever... :lol:

Martin
Author:  NeilB [ Sun Nov 01, 2009 3:11 am ]
Post subject:  Re: The Source for Sparse Invaders
Thanks Steve!
I'll look forward to the update on Swift - and I'll keep the feedback flowing this time. Hopefully more will use Swift when the source for Invaders is added to the wiki.

Martin, LOL very funny! :D

Sam - you're right, the current GPL should be fine. I can't imagine anyone profitting from it. I'm quite happy with it as is. I'll have to get the text file and add it to the disk, LOL I expect it will triple in size! :lol:

Neil
Author:  SteveO [ Sun Nov 01, 2009 10:05 am ]
Post subject:  Re: The Source for Sparse Invaders
MartinB wrote:
Unless you get that 'a' key fixed Swift will stuck in beta forever... :lol:Martin

Yep, it will :lol: Sorry about that but yes the 'A' key on my lptop has been duff and working on and off for about 18 months now, hopefully replacement machine next year. In fact I've whole column of dodgy keys. Tried the usual of stripping down, replacing connectors etc. but to no avail.
Author:  SteveO [ Mon Nov 02, 2009 12:23 pm ]
Post subject:  Re: The Source for Sparse Invaders
I've sorted the .org issue. (but not released to Wiki yet). I'd not spotted it in my work as lately I've been using flat files with no merging (just .requires etc.). I'll now sort your sprites out so they open up ok in new version. Also like the game, looking good and will be excellent resource when you release the source.
Author:  NeilB [ Mon Nov 02, 2009 1:18 pm ]
Post subject:  Re: The Source for Sparse Invaders
Fantastic Steve,

I'll have to add in PJ's sound - I have the source, might do that now... I need to have a play with the 0E00 relocation as well... I have the memory of a goldfish (MORNING!) so need to redo that as I came across a problem so I can remember the details. I sure it was to do with MAIN starting address, but don't quote me on that! Just out of interest, have you tried any prog that relocates it's self from 1100 to 0e00?

Oh, thanks also Steve for looking (and fixing) these issues so quickly,
Neil
Author:  SteveO [ Mon Nov 02, 2009 3:10 pm ]
Post subject:  Re: The Source for Sparse Invaders
I've managed to convert your sprites (takes about a minute per collection) to work in the new Swift. Is this the latest version of your game, do you want me to zip it up and return it so it'll work with the new version when I release it ?
Author:  NeilB [ Mon Nov 02, 2009 5:31 pm ]
Post subject:  Re: The Source for Sparse Invaders
Yes please - that would be great ... I didn't get much done lunch time - so perfect timing!!! I can PM you my home email address if you wanted?

On the relocation issue:
I've been trying to sort out the relocation (from 1100 to 0900) and at present .. I build to 0f00 - and then within the boot.bin I *LOAD main 1100 and *SAVE main 1100 etc, This sort of makes sence at present with the version of Swift I'm using. I'm assuming it takes the .ORG and then sets that as the LOAD address. This is all very well, however I can't see any workaround when relocating the program to lower memory - without the additions in the boot.bin.
This means, as I use BeebEm - I test only master128 mode, then I would have to make a version for the 32k Beeb mode.

Have you ever had any problems with this before Steve??

many thanks Steve,
Neil
Author:  SteveO [ Mon Nov 02, 2009 9:10 pm ]
Post subject:  Re: The Source for Sparse Invaders
Usual (rough method) would be to load at the higher address and then load some code (or have it within your initial loaded code) that copies the code down into the disk area of memory. Not sure why you're re-saving your code.... oh hang on are you trying to alter the load /execution address ?

I've not got the time now, but I'll knock up an example in Swift for you hopefully tomorrow.
Author:  SteveO [ Tue Nov 03, 2009 11:48 am ]
Post subject:  Re: The Source for Sparse Invaders
I've done an example with the "Sprite Plotter with Movement" project from the Wiki. This initially loaded the code at $1900 and ran it from there. I've now written it so that the code is loaded at 1900 and relocated down to E00.

I'll explain some of the details in a minute but first why are you building at 0F00 if you want to relocate down to 900 from 1100 ? Also be careful about loading in at $1100, is this above the disk input buffer workspace ? If not you'll have problems. The disk interface on a model B uses memory from E00 to $18FF. But a lot of this space is buffers and you can obviously use the output buffers if your only reading from disk. I can't remember the specific addresses off hand but if it's all output type stuff above 1FFF you should be fine.

Ok, that aside here's what I've done to my example to make it work on a model B even though the code runs from E00.

First I changed the .org statement in my single block of code from

.org 1900

to

.org E00

As it is eventually going to be in that location when executed, so the assembler needs to assemble to that position. This is in the file "SpritePlotter".

I then created a additional project item called "Relocate". This has it's org set to $880 (The printer buffer). It's this code that will relocate the code and call the start of it.

The boot file was altered to this;

Code:
OSCLI "LOAD MASK 900"
COLOUR 128 : REM Change to any background colour you wish (values from 128 to 135)
OSCLI "LOAD SpriteP 1900"
OSCLI "RUN Reloc"


So the changes were to Load the main program"SpriteP" (not to run it) at address $1900 (above disk workspace). Even though this code has been assembled to run from E00. Then we load and run the relocation routine. This consists of the following code;

Code:
.org $880        ; printer buffer

Main:

; we have loaded the code at 1900 but it's been assembled to run from E00, so just copy
; the code from 1900 down to E00. We know it's length of the block we've loaded as Swift
; will tell you this from the properties of the "SpritePlotter" source file. You can
; also find it out by examining the disk image created.

.alias LastAddress $1900+1713    ;  1713 is the size of our code,just setting address
                                 ; that we stop copying at when we reach it.



CopyFrom:
lda $1900
CopyTo:
sta $E00
inc CopyFrom+1                   ; lo byte
bne NoCarry                      ; Not gone to zero, so effectively no carry

                                 ; If we get here however....
inc CopyFrom+2                   ; add in the effective carry (note we use BEQ above to
                                 ; detect for rolling over from 255 to 0 as the command
                                 ; INC does not effect the carry flag.
 
NoCarry:                               

; we now do the same increment for the copyto position
                                 
inc CopyTo+1                   ; lo byte
bne NoCarry2                      ; Not gone to zero, so effectively no carry

                                 ; If we get here however....
inc CopyTo+2                     ; add in the effective carry (note we use BEQ above to
                                 ; detect for rolling over from 255 to 0 as the command
                                 ; INC does not effect the carry flag.

NoCarry2:

; now wecheck if we've copied all the bytes
lda CopyFrom+2                   ; check hi byte first
cmp #>LastAddress
BNE CopyFrom                      ; Go back to start of loop if not equal

; high byte is equal, check lo byte
lda CopyFrom+1
cmp #<LastAddress
BNE CopyFrom                      ; if no equal, carry on copying

; we've finished copying all the bytes, run the code at the new address
JSR $0E74        ; start of code to run (actually you could just use a JMP here)
RTS                ; and you don't really need this !


This copies all the bytes from 1900 to E00 then calls my main program code at $E74. The address to call was found out by simply looking at the label values in Swift for the label "Main" in the "SpritePlotter" source. The size of the code 1973 (decimal) was gained from the properties window of the "SpritePlotter" item. Although the code must be assembled at least once to get this information.

Rememeber that although Swift may set certain load and execution addresses you don't have to adhere to them, you can still load your code anywhere into memory that you wish by stipulating the address.

Attached is the Swift project file for this example; Note this will only load correctly into the latest version of Swift.

Attachments:
Mode2SpriteMovement_Relocated.zip [23.89 KiB]
Downloaded 10 times
Author:  NeilB [ Tue Nov 03, 2009 1:50 pm ]
Post subject:  Re: The Source for Sparse Invaders
Execellent Steve...

I sort of realized where I was going wrong - and nearly have it sorted, your example has helped me with the understanding, once I got my head around it, I realized how it makes sense and sigh - sometimes the grey matter doesn't seem to see simple answers that are staring you in the face! LOL

Part of my problem was loading the file in at 1900 when already in mo.2, this caused all sorts of errors and lockups... I have the mode change after the relocate and just need to turn off the cursor - in code.

I'll get back once this is done and the sound added ... Should be ready for adding to the wiki then ...

thanks again Steve for spending the time to explain to a old boy! :D

- Neil
Author:  NeilB [ Tue Nov 03, 2009 3:10 pm ]
Post subject:  Re: The Source for Sparse Invaders
Dump question ....

I'm pulling the last of my hair out - LOL ...

Simple - would you think this would turn the blinking cursor off?

LDA #23
JSR oswrch
LDA #1
JSR oswrch
LDA #0
JSR oswrch

I did have this in old code - but moved it into the boot text file ... Now I've moved it back to the code - I can NOT stop the blinking cursor

The above is done directly after the mode change... I'm assuming I'm doing something silly or forgetting something!?

Thanks in advance, Neil (ran out of lunch break!)
:D
Author:  SteveO [ Tue Nov 03, 2009 3:15 pm ]
Post subject:  Re: The Source for Sparse Invaders
This'll do it with the method your using;

lda #23
jsr oswrch
lda #1
jsr oswrch
lda #0
ldx #7
CursorOffLoop:
jsr oswrch
dex
bpl CursorOffLoop

You can do it by writing to the 6845 registers directly as well.
Author:  RichTW [ Tue Nov 03, 2009 3:47 pm ]
Post subject:  Re: The Source for Sparse Invaders
Yes, more simple to poke the hardware directly:

Code:
LDA #10
STA $FE00
LDA #32
STA $FE01

That's all :)
Author:  NeilB [ Tue Nov 03, 2009 5:08 pm ]
Post subject:  Re: The Source for Sparse Invaders
Hey, thanks Rich, that worked very well ...

Using my effort of VDU 23,1,0 etc - didn't work, and it was driving me nuts!! LOL

Ok, onto the relocation code, then sound and then hopefully all done - ready for the wiki ( how many times have I said that :lol: )

Thanks to Steve's hard work - it will be using the new Swift... BRILL as they say!

Neil 8-)
Page 1 of 3 All times are UTC [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/