Img2BBC image loading appears skewered

[Pablos544]

Hi.

I'm trying to impress my friends by doing an artistic cover page for a compilation ssd image. I saved the image using Img2BBC off a BMP file.

I'm using the *LOAD <imagefile> 12288 but the image seems to have skewered off to one side.

I don't understand it. &3000 = 12288 in decimal, and this afaik is the start of VIDEO RAM for MODE 2!!

I've attached a screenshot demonstrating my amazing artwork going off to one side.

Please help guys. I'm still new.

Cheers,

Pablo.

[MartinB]

*LOAD requires hex parameters so use *LOAD <image file> 3000 without the ampersand and do it immediately after the MODE 2 selection. (I suspect it thinks your 12288 is hex..... )

[Pablos544]

Ha ha!! Thanks, Martin I get it now

[SimonSideburns]

As MartinB says, make sure you change mode and then immediately *load the screen.

The reason for this is that due to hardware scrolling, the start address of the screen may change if you have scrolled down below the bottom of the screen.

To see this in action, try the following:

Code: Select all

MODE 2
*.
*HELP
*LOAD title 3000

By performing a *. and then a *HELP (maybe do it a couple of times) there's a good chance you will scroll the screen, then you'll find out that the title loads but doesn't start at the top of the screen.

Oh, and by the way, even though file names are stored as entered with regard to upper/lower case, the *load or even CHAIN "xyz" is case insensitive (so *LOAD title, *LOAD TITLE and even *load tItLe are all considered the same.

[Pablos544]

As MartinB says, make sure you change mode and then immediately *load the screen.

The reason for this is that due to hardware scrolling, the start address of the screen may change if you have scrolled down below the bottom of the screen.

...

that's good to know. I would assume the start of the screen is fixed in memory.

[jgharston]

As MartinB says, make sure you change mode and then immediately *load the screen.
The reason for this is that due to hardware scrolling, the start address of the screen may change if you have scrolled down below the bottom of the screen.
...

that's good to know. I would assume the start of the screen is fixed in memory.

The start of screen IS fixed in memory for a particular MODE, but the top lefthand corner isn't, it moves through memory as you scroll the screen unless you have defined a window.

[Pablos544]

The start of screen IS fixed in memory for a particular MODE, but the top lefthand corner isn't, it moves through memory as you scroll the screen unless you have defined a window.

Thanks, I think I understand this. Thanks for clarifying.

[1024MAK]

The position of the top left corner is set by registers. If the picture is scrolled using the video hardware, these contain a value which causes the video hardware to start generating the picture from a different position in memory (RAM). The circuitry that generates the picture has a counter and the addressing that accesses the memory wraps around when it gets to the end of the screen area. It then continues generating the rest (bottom part) of the screen image from the start of the memory area used for the screen.

I hope this does not muddy the waters

Mark

[Pablos544]

Thanks guys, that's fixed it. I note what you say about case insensitivity as well, SimonSideburns

Thanks for explaining about the scrolling etc. The scrolling does seem fast. Does the Beeb have something like a blitter or hardware scrolling aka C64??

And for your eyes only, folks at stardot, a sneak preview of my amazing cover for my compilation SSD. It's meant to be four games, amazingly drawn in iconic format using my legendary drawing skills

Can you guess what they are?

[Pablos544]

btw if anybody wants this amazing ssd for a very modest fee.. lol jk

[Pablos544]

The position of the top left corner is set by registers. If the picture is scrolled using the video hardware, these contain a value which causes the video hardware to start generating the picture from a different position in memory (RAM). The circuitry that generates the picture has a counter and the addressing that accesses the memory wraps around when it gets to the end of the screen area. It then continues generating the rest (bottom part) of the screen image from the start of the memory area used for the screen.

I hope this does not muddy the waters

Mark

No, it's very helpful actually 1024MAK. Thanks!!

[jgharston]

Thanks for explaining about the scrolling etc. The scrolling does seem fast. Does the Beeb have hardware scrolling aka C64??

Yes, it does have hardware scrolling, that's what most of the thread has been about.

Taking MODE 0/1/2 as an example, the screen memory starts at &3000, and an unscrolled screen displays memory starting at &3000. If the screen is scrolled one line the VDU drivers don't move anything in memory, they just set the start of displayed memory to be &3280 (&3000+80 chars*8 lines). The video hardware then just displays everything from &3280 to &7FFF and then wraps around to display &3000 to &327F.

Do something like this:

Code: Select all

MODE 0
REPEAT
!&3000=-1
A%=GET
PRINT VPOS
UNTIL FALSE

and watch how the displayed screen moves through the screen memory.

[Pablos544]

Thanks for explaining about the scrolling etc. The scrolling does seem fast. Does the Beeb have hardware scrolling aka C64??

Yes, it does have hardware scrolling, that's what most of the thread has been about.

Taking MODE 0/1/2 as an example, the screen memory starts at &3000, and an unscrolled screen displays memory starting at &3000. If the screen is scrolled one line the VDU drivers don't move anything in memory, they just set the start of displayed memory to be &3280 (&3000+80 chars*8 lines). The video hardware then just displays everything from &3280 to &7FFF and then wraps around to display &3000 to &327F.

Do something like this:

Code: Select all

MODE 0
REPEAT
!&3000=-1
A%=GET
PRINT VPOS
UNTIL FALSE

and watch how the displayed screen moves through the screen memory.

That's definitely going to help. Thanks a lot, man. I gonna try it. Respect

[Pablos544]

Yes, it does have hardware scrolling, that's what most of the thread has been about.

Taking MODE 0/1/2 as an example, the screen memory starts at &3000, and an unscrolled screen displays memory starting at &3000. If the screen is scrolled one line the VDU drivers don't move anything in memory, they just set the start of displayed memory to be &3280 (&3000+80 chars*8 lines). The video hardware then just displays everything from &3280 to &7FFF and then wraps around to display &3000 to &327F.

Do something like this:

Code: Select all

MODE 0
REPEAT
!&3000=-1
A%=GET
PRINT VPOS
UNTIL FALSE

and watch how the displayed screen moves through the screen memory.

That is unbelievable. This forum rocks. This should be on the BBC World Service, amazing. Unbelievable. Lost for words. So the little flashing mark you put with the !&3000 line actually STAYS on the SCREEN!! Yet apparently all text rolls upwards.

I'm not sure how it works but I'm seeing what you've been alluding at.

Cheers, bosses!!

[Pablos544]

Ok now I'm really confused.

The original flashing mark caused by the line

Code: Select all

!&3000=-1

STAYS on the screen and wraps around as you print stuff, which I can kind of understand.

Then I add a few lines to draw some coloured shapes and these scroll off as if they were being pushed like the text does.

I thought I was getting it but now I'm really confused

I've attached a screenshot.

Here's my hacked together code, modified from JGHARSTON's original:

10 REM ** THIS EXAMPLE BY JGHARSTON **
20 REM ** DEMONSTRATES HOW THE SCREEN
30 REM ** MOVES THROUGH MEMORY
40 LET C%=0
50 MODE 2
60 REPEAT
70 GCOL 1,C%
80 PLOT85,100,100
90 PLOT85,500,500
95 PLOT85,300,500
100 LET C%=C%+1
110 IF C%>7 THEN C%=0
120 !&3000=-1
130 A$=GET$
140 PRINTVPOS
150 UNTIL FALSE

[tricky]

printing text on the bottom line makes the OS scroll the screen up by moving the start of where the picture is drawn from and then blanks the new line at the bottom so it looks like it just went off the top.
graphics and text are stored in the same bit of memory (are the same thing), so when the display starts from a different place, everything moves.
You can define a "text window" (see the user guide), this will then be scrolled in software and the rest of the screen will stay where it was.

[Pablos544]

printing text on the bottom line makes the OS scroll the screen up by moving the start of where the picture is drawn from and then blanks the new line at the bottom so it looks like it just went off the top.
graphics and text are stored in the same bit of memory (are the same thing), so when the display starts from a different place, everything moves.
You can define a "text window" (see the user guide), this will then be scrolled in software and the rest of the screen will stay where it was.

That explains it very well, Tricky da man at Arcade Conversions, and certainly that seems to be what's happening. So the display of the computer is "fooled" into believing it's moving wherw in fact only a display start is moving. I know it's what you guys have been trying to tell me and I did actually understand that bit. The thing that I thought was confusing is the way that little flashing mark seemed to wrap around seemingly violating this rule.

Is it because it uses flashing bits or something?

Sorry for being a pain, it's just I did put there in my image that for some reason that mark stays there!!

I did get about the display start moving or at least got the gist.

Cheers

[jgharston]

Try this:

Code: Select all

   10 REM BBC ONLY
   20 MODE 0
   30 REPEAT
   40 FOR A%=&3000 TO &7000 STEP &1000
   50 A%!0=!(&C080+A%DIV512):A%!4=!(&C084+A%DIV512)
   60 FOR B%=8 TO 28 STEP 8:A%!B%=!&C080:A%!(B%+4)=!&C084:NEXT
   70 NEXT
   80 PRINT GET
   90 UNTIL 0

It pokes into screen memory the address of that location in screen memory. As you scroll the screen you can see how the displayed screen starts at higher and higher addresses in memory and wraps past the end of screen memory back to the start of screen memory.

Note that you should normally never access the system character set this way, as your program has no way of knowing where it is. You should use the defined API, OSWORD 10. F'rinstance, try running this on a Master.