Hi,

I've been recently playing around with file compression.

Here's a 7-bit run length decoder in 6502 and associated encoder/decoder in 'c'.

I pick up a byte - if bit 7 is set I assume it is a count where count = 2+(byte & $7F) else I assume it is a unique value and pass it on.
$FF marks the termination.

Not a bad saving! ( I ran it on some teletext pages. )

If anyone can improve it - please show me.

I do wish I could use 16 bit macros like ADD16 - 6502 code becomes so long winded.
Is there any advantage to using INC, BNE, INC instead off the adds I use?

On a related note - has anyone got a 6502 Huffman they could post?

Yes, INC,BNE,INC is shorter + quicker.

If you're using BeebAsm for this, now you can use macros (since release 1.05 I think).

e.g.


The conditionals in the macro will be evaluated each time it is used, and so the optimal code will be generated. Beware that macros which assemble different code depending on the parameters passed in can set the flags inconsistently upon return (e.g. the ADDI16 macro sets C differently depending on the 'val' parameter), so be careful if you rely on this.

While you have the macro, you might as well add the LSB=0 optimisations.

There is also SWEET16.

Richard

!!MACROS!! Terrific! You've made my day.

Now I have MOV, ADD16, CP16 and Long Jumps (JEQ etc.) - much easier to program.

INC16 and CMP16 don't seem to work - is it because they contain an existing keyword.

Sorry to be picky but it would be even cooler if it could tell the difference between:
ADD16 label,#23 and ADD16 label,address.

At the moment I use ADD16 (for immediates) and ADDM16 (for memory).
Also the
.label thing drives me crazy - I'm just too used to the 'standard'

label:

At lease it accepts

.label:

Thanks again

- PJ

Yes, exactly. They are equivalent to INC &10 and CMP &10 respectively (because BeebAsm, like BBC BASIC, doesn't require spaces after its keywords). Maybe I'll make a change so that invoking macros takes priority over assembler opcodes, so that the likes of INC16 work ok (this would also be more consistent, given that it's possible to define macros with names like these). My best suggestion for now would be to prefix all macro names with an underscore character, both so that they stand out, and so there's no clashes with reserved words.


When I was implementing macros, I wondered about this, but in the end I figured it didn't make sense. In your example, you'd want it to generate different code depending on whether it was an immediate constant or another address (due to the way the MSB would be handled - in the first, it'd be HI(val) and in the second it'd be addr+1), so there'd be no advantage in 'unifying' the two macros in this way. It could be done by implementing 'overloading' of macro definitions, i.e. the same name but with different parameter types, but this would just be getting far more complicated than would be worthwhile!


When I wrote BeebAsm, my original intention was to create something which would let me write 6502 assembler in exactly the same way as I used to in BBC BASIC, in particular putting multiple instructions on one line, separated by colons. I couldn't find any other 6502 assembler that allowed this, and so I wrote my own! So that's why all the conventions are as per BBC BASIC, right down to the .label syntax, and even the names of the functions. It even uses P% (as well as the more conventional '*') to return the address currently being assembled at.

Of course, since those early days, it's grown quite a bit, and it's true that some of the original features, such as not requiring whitespace, aren't really all that useful.

I used a run-length encoding in the *ScrSave/*ScrLoad commands. They just use simple RLE where everything is a two-byte pair of byte,length. Quite ok for screen images where almost everything is runs of similar data. Screens compressed with this are at http://mdfs.net/Mirror/Archive/JGH/ and http://mdfs.net/Mirror/Image/JGH/

Don't forget there's also Pu Crunch which I have found useful