stardot.org.uk

Here's the code to obtain the ascii code of the sprite from a lookup stored at &1300 row of 38 consecutively. The first row (see attached) is scrolling accurately but the other rows are nonsense (e.g.second row should be blank). lksp5%?f3%=f3%MOD20 and lksp6%?f3%=f3%DIV20 going from 0-139 should be ...

Thanks. Will update if I make more progress.

Here's the result so a few things to check.

So I think I end up with the y-value 38x in &88-89 and the x-value in &7E.
Is it correct to add these:
CLC:LDA&88:ADC&7E:STA&88
LDA&89:ADC#0:STA&89



Then add to &1300 where hopefully I can store the ascii table.

This will hopefully be the last one. I have lookup tables containing the x and y position of sprites within a 38x18 map given a sprite block counter, X, which goes from 0-139 on screen (20across x 7 down). I then add in the offsets for the onscreen scroll, x% (&7E) and y%(&7F), but need to multiply ...

I think it is probably assuming the number written down is 0111 then.

Just reading about multiplication and division in binary and following an exercise for long division. 10010.001//11.1 I get down to subtracting the divisor 111 from the working dividend 1001 and have to do a 2s complement of 111. The exercise says this is 1001 but how is that the 2s complement? Sure...

So store the high bytes in another table? Ok, thanks, will try that.

The index can only be 255 max though?

Is there any way of accessing a lookup table with double byte size. This obviously does not yet work: 225LDX counter2 \low byte of index 230LDA lksp3%,X \low byte of offset 240STA &81:JSRctr2 245LDX counter2+1 \high byte of index 250LDA lksp3%,X \get high byte 260STA &82:JSR ctr2 312.ctr2 INCcounter...

Surprised I got away with that for so long. Thanks to both of you.

tricky wrote: ↑

Fri May 22, 2020 7:03 am

Are you setting P% inside the loop?

No outside.

Don't know what you did there. Got rid of some LDAs in the first part, because the accumulator doesn't change value after an STA and took advantage of the fact that you know the values of the absolute values you are storing to rearrange the calculation to get rid of unnecessary loads/stores. E.g. 2...

dp11 wrote: ↑

Thu May 21, 2020 11:28 pm

can you post the full code ?

A bit long to go through entirely. I'll have another look. The m% is a byte array so maybe Ive overwritten something although why this would break the program during assembly is another question.

291.sl 292LDA#0:STA&83:LDA#0:STA&84:CLC:LDA&83:ADC&77:STA&77:LDA&84:ADC&78:STA&78:RTS 293.tr 294LDA#64:STA&83:LDA#0:STA&84:CLC:LDA&83:ADC&77:STA&77:LDA&84:ADC&78:STA&78:RTS Not sure about the error, but you could optimise the above a little as follows: 291.sl 292LDA#0:STA &83:STA &84:CLC:ADC &77:ST...

It's not unfortunately.

Sorry if I've missed the answer but why does the assembler produce "out of range at line 287" from this, using OPT 0 to 3 STEP 3. P%=&900 and m%=&C00. The code doesn't reach &B00. 285LDX &79:LDA m%,X \get ascii of sprite at current plot pos 286CMP#94 287BEQ sl 288CMP#88 289BEQ tr 290RTS 291.sl 292LD...

Yes.
Almost there:

!&77=&C00 should do that? Yes, but please note that this also writes 0 to &79 and &7A. It writes 4 bytes at once! That explains a couple of problems. Here's my lookup which is supposed to print consecutive blocks 20 horizontally and 7 vertically (mode 1). Base address of &5800 is in &72-3 which is ...

By coincidence, I posted some code earlier in the week which uses this addressing mode, to fetch 16,384 bytes sequentially from the ROM area. I've always found the Advanced User Guide a splendid reference work for 6502 machine code and BBC BASIC assembler. Here's a snippet (p.39) which describes th...

!&77=&C00 should do that?

Thanks. I think its the base address Im feeding the plot routine is repetitively added in. However i noticed a load from sprite data operation had stopped working:

LDA sp%,X works
LDA (&77),X doesn't

Where sp%=&C00 and !&77=&C00

Here again trying to get a soft-scrolling map that works using screen offset lookup tables, using assembler. The tables seem to work fine in a BASIC version. It calls a 16x16 Mode 1 sprite plotter (.plot) that works fine alone. the map is 20x7 onscreen blocks at one time. &72 and &73 are passed to t...

CMcDougall wrote: ↑

Fri Mar 06, 2020 5:13 pm

pure brilliant

How did you design your loader? Nice.

480x500 pixels. Imagine if it could have been exploited. Sure i read about the isue in a magazine before or PD program.

Might be interesting to know who is, might or would use BeebEm on Mac. i.e. for testing purposes. Currently we know of - Jon Welch (primary maintainer) - You (guddler, maintainer helper in training?) - Me (elminster) - Lurkio - Dave Hitchins - geraldholdsworth - Danielj - mlouka Anyone else? I am t...

Thanks

What is the pixel resolution of Mode 7 text? Isn't it possible to use this for graphics?

Is this related to Mac Beebem?

May i ask how prnyb returns to the main loop and why you used BCC?