Aww the dummy address, I noticed that - Hmmm it's been a while, but good you're here to remind me, LOL kick start the grey matter to the old low-memory methods of coding! Reminds me of my first few spectrum games, the suite of library functions (such as sprites) used by the company, took up so much memory that I only had 4 to 5 k to fit my game in. As you might guess, I took the time to rewrite big sections of that library!!!

Right, as it's lunch, I'll be getting back to my sprite controller. I'll be sure to be again with more questions soon,

Cheers, Neil

Jeeez, that must have been one heck of a big library. It's not like there were loads a different screen modes to think about and with around 36K+ (sorry no Speccy expert) of normal memory left after screen requirements I can't figure how they wasted so much ! That's about 30K for that library ! How did they write anything ! Who was the company (if you can mention)

Err, lets think - well, the very small company was based in Suffolk - I'd be very surprised if you'd had heard of them... The library was bloated with many straight-lined sprite functions for various different sizes. There was also other stuff, for the love of me can't think what... Anyway, the main bloatness was in the sprite functions.

If you want to know more, I'll be happy to PM you! - Neil

Well, got my sprite drawer working yesterday. I have to admit - it's a basic clone of Steve's ... OK I'll hold my hands up and admit to that.

It's a shame I'm so busy at the moment - but just to keep you updated; ... I'm currently thinking about the masking! I keep trying to think if there's an easier way over my current effort - (that's not working proper like)... I'll post the code here and I'll update the post, if I work out where I've got wrong...



Ok, the idea is - two blank pixels - skip write, then check for either left or right blank ... If this is the case - mask the pixel from the screen position, or the sprite data onto this, store - check the other pixel then ... write back to the screen position.

Now, I can assure you - I'm doing something wrong as the image is basically there, however the pixels being written to the screen are incorrect. As you can see - if you have seen Steve's sprite plotter, the code is placed between the read and write of the sprite data to the screen.

Hopefully, someone can see a mistake in my AND'ing values or general approach to the masking... WHY it couldn't be like the Amstrad and not be interleaved LOL!

Anyway, thanks in advance for having a look - and I'm feeling more confident about 6502, so hopefully any posts soon will be a little be more juicy for you all to get your teeth into!

many thanks - Neil

You'll kick yourself here I think, this line




and the others of this type your using won't work as you think they will. This line from the code



stores the accumulator at the screen address stored at ScreenAddPtr+1 and +2.

So let's think about how that line is assembled by the assembler and what value will be in those labels. Let's say the STA $FFFF,X line is at address $2000.



The label ScreenAddPtr will get the value $2000 as it represents that location in the program code.

So your lines like



are actually this (if you fill in the values for the labels)



So your actually loading data from your actual program code and you want to load it from screen, so you can see why garbage appears;

So all your masking/ANDing/ORing are right in themselves, it wasn't that part that was wrong, it's the fact your pulling your data from the wrong memory address for the screen and sprite.

Sorry, meant to mention. Also you don't need that top CMP #0, remember the zero flag (and some others) get set when you load the Accumulator with anything so the line we don't see before that that loads in the pixel will if the pixel is all 0 set the zero flag so no need for the CMP.

Also in P65 you can represent binary bytes with %, so

AND #$AA

could be written as

AND #%10101010

which I find easier to interpret when comparing and setting binary digits, although you might prefer your Hex for that situation

Yes, that would be nice in BeebAsm too, wouldn't it Rich

Bless you all! It now works!

Steve - I have been kicking myself, I was sure my AND'ing and ORing was sound, but - well, with snatching the odd 15 mins here and there at work, no wonder I had a senior moment! Hmm I suppose I could blame it on Ozzy Osbourne, his new albumn - listening to a couple of tracks - haha first heard Ozzy on "Black Sabbath" in the early 70s - so at 10 I was a major Black Sabbath fan. Anyway his new stuff has that edge to it, that he had with Sabbath in the 70s!

Anyway - thanks for the pointer on removing the cmp - I always forget that LDA sets certain flags, no doubt I'll finally remember it - once it's been pointed out few more times ( multiplied by ten )!
Oh, saving the sprite data and screen pixel information into zero-page before masking has saved several clock cycles per run ( of two pixels )!

Right - on the code front, after some simple screen related stuff, I'll work on the Sprite Controller proper. Hmm then it's a case of a simple way of porting the IFF images I have, to a format that can be used with the Sprite editor in Swift. I def see some form of sprite grabber system that will convert and save the data. I've written several in the past 20 yrs, so have idea's .. if it's useful and there isn't any other tool available ( haven't looked yet sorry ) then I'll add it to the site if there's any use for it!

Thanks again Steve, Right - back to it for me!
- Neil

Check out pages 508, 509 of the BBC Micro User Guide, or trip on over to 'http://ericclever.com/6500/' and grab a copy of the OP code chart there. Stick it up on your wall, and use it frequently :o)

Excellent Recycled!

I've just printed out the pdf of the instruction set, very very helpful ... for a quick over view of the instruction/bytes/cycles... thanks!

Reading the website, remindered me of a friend of mine, who was doing something sort of similar - it was Z80 ( machine code ) into a controlled lazer used for labelling basically any rounded shape object - big or small - they had small ones for labelling electronic components - but the big one I think was a second-hand buy from an old James bond film... I refused to go near it. Hmm the company was also using the software for cutting, I was amazed at the fine control they had over the brill, cutter or lazer.

Anyway enough day dreaming - thanks - Neil

I don't suppose anyone has scanned in 'The Micro User' from about 1986. I wrote a series of articles entitles 'Writing Machine Code Games' which I'm sure would be of interest to anyone new to assembly language on the BBC Micro.

There were some scans kicking about the net as I had printed off some of your articles about a year ago. However, I can't seem to find them again.

If no one else has them, I can dig out the printouts and scan them.

Kind regards,

Francis.

Hello All!!!

Well, it's been a while - so sorry for the long pause!
However I'm back to coding the 6502, bless! Managed to get my master 128k so things are rolling now as I now have a real machine to test my efforts on!

OK, here's another question - well, first a little bit of background.

Managed to get my sprite system together - for Mode2 anyway. It's using Steve's wonderful Swift IDE with P65. It's pretty basic at present - there's a system for 30 sprites, and 6 of them can be active on the screen (I just picked numbers out of my head at present ( as this appears to be about what I would want for my game )) - this masks the sprite onto the screen, also there's sprite clear being used, as I have haven't started my map-block drawer yet.

Right, I'm sure you will all smile, as I'm sure you have all seen this issue - but, HOW do I stop the terrible sprite blanking, ripping and geneally horrid flickering of the sprite as it moves across the screen??

I'm going to dump my code below, but basically I wait for a vertical blank - do the spritewipe, spritedraw then loop around ... There's test code in the example, but I'm sure you're ignore that. I'm also clearing the sprite to colour 0 [BLACK].

Here's the code ...







Any help would be greatful and I'm more then happy to supply any other code etc,

many thanks Guys!

Neil

Just a few observations: shouldn't you jsr SpriteController.SpritesDrawActive after you've changed the position (i.e. just before you wait for a keypress?); otherwise I'd expect a trail to be left...

You don't need to TXA then CMP, you can just CPX #50

I can only assume that your routines are too slow if you're getting flicker - can't see anything obvious that would cause it otherwise... I presume you're writing direct to screen RAM

Thanks ParasS,

well, as I said it's test code for the main loop. The X position is getting updated every frame, the wipe removes any chance of a trail. Err, I always seem to forget that you can compare with other regs ( CPX ), sigh!

Hmmm I'm not sure about the cause of the flicker being the speed of my sprite routines, they are taken from Steve's example. I do have a small sprite - 8x8 ish and after adding several waits for vertical blanks - still getting the flicker. I'm using Beebem, the latest version - and I notice chuckie egg has a flicker as well, meaning it's being redrawn every frame. I understand that you only need to update the sprite once it's moved, so, it's really to do with the actual drawing... I'll have to try a different emulator or get the beeb out and run it on there. That should eliminate either BeeBem or my 'snail' code. I can see area's where I can optimise my code, however it's one sprite thats 8x8 - therefore I feel that there's something I'm missing here.
To be honest here, I've been a games programmer since the late 70's. Worked on Spectrum, Amstrad etc etc ... so I'm sort of surprised with the flicker. Knowing what the spectrum can go, the Beeb is a far superior machine... oh well!
I would be interested in seeing some game code, from anyone... Thus I could see if I'm setting the state of the machine up correctly and also see if it is my sprite routine. I'll be happy to supply a email address and also would be very distrete,

thanks all,

Neil

I'm assuming your wipe routine plots over the sprite with old background data? if so, surely you'd wait for a blank, then wipe it, move it, draw it all before the screen refreshes? That's the way I've always done it in the the past.

[it's been a while - like 20 years - since I've written any code like this, but the logic hasn't changed! ]

That's true - and I'm doing that!

I wonder if I need interrupts off when drawing - or maybe stop the cursor flashing ... or ... god knows!!

I'll keep at it - never one for giving up and it's all GREAT fun!!

But you're doing wipe, plot, then move - I don't get it!

The cursor is done in hardware - so no speed impact, and the beeb is pretty efficient with interrupt processing - I wouldn't expect that to be the biggest cause for flicker... though you could try wrapping the code after osbyte 19 and before the key check with SEI and CLI

Thanks for the continued support in my hour of need!

Hmmm As it's lunch time I've been working away at this issue - and I've moved the sprite further down the screen - It was at 20y, moving it down to 40, 60 and then 80 reduced the the tearing until it looks smooth and no clipping etc.

I'll double check the calculations for the wipe function, as I store pre-calculated stuff like screen address etc. but it's looking just like the wipe ( to black ) and draw does produce tearing at the top of the screen. I don't think it's due to slow code - as I'm drawing three 16x18 sprites and wipping them and it's still running in a frame.

It might be beebEm in the end- won't really know until tonight!

Neil

Stupid question - but your wipe just blanks out where the sprite is, rather than the whole screen, right? I guess that's what you're checking... adn the pre-calc'd address means it doesn't matter that you change the X before the next wipe.