program not working.

[WiggyWire]

10 REM - Market Day 20 MODE2 30 FOR X=0 TO 7 40 VDU19,X+8,X,0,0,0 50 NEXT 60 ROW=1100 70 REPEAT 80 SIZE=(60-ROW/20)*4 90 ROW=ROW-SIZE-2 100 FOR COLUMN=1 TO 15 110 MOVE COLUMN*SIZE,ROW-100 120 GCOLRND(255),0 130 PLOT0,SIZE,0 140 PLOT81,-SIZE,SIZE 150 PLOT1,SIZE,-SIZE 160 PLOT81,0,SIZE 170 NEXT 180 UNTIL ROW<=0

Starting to see a problem as a bunch of listings I have tried don't seem to work at all as described in the book. I get not implementing something difficult like sound, but there seems to be things that were commonly used in the listings that just break a great deal of stuff that you will find in the magazines and books for the beeb.

[WiggyWire]

The book where basically nothing seems to be working is BBC Micro Programs in BASIC by Derrick Daines.

[soruk42]

Please check line 120 - looks like a typo. I get something out when I do GCOL0,RND(255)

Edit: Nope. Looks like it uses ECF pattern fills. These are not currently supported in Brandy.

Having found some of the other demos, it looks like many of them are making use of hardware features that are not currently implemented and would be very tricky to get them working.

[WiggyWire]

Thanks, are there any books where most of the listings are going to work? I noticed a lot of the old Beeb books seem to use a lot of hardware hacks to get stuff to work.

[soruk42]

That's a good question. Many of the animation tricks, for instance, use palette changing, as on the BBC Micro this changes the actual colour of all pixels at once. In Matrix Brandy (and I believe, BB4W) this is not the case. Irrespective of the chosen screen mode, the display plane is a true-colour display, and pixels are plotted from the palette at the time they're plotted.

I could do something that searches and replaces pixels on a palette change, but that is also liable to problems as if two palette entries are set to the same value, the screen can't then tell them apart for future palette changes.

[WiggyWire]

Would it be easier to stick to Mode 7? that seems to be fairly complete. I just need to find some decent sources on how to program it. It seems to have been the red-headed step child of the modes, not much is written in the old books about it.

[soruk42]

MODE 7 works - and screen memory is even implemented, to a degree. But at a different location (&FFFF7C00 to &FFFF7FFF) due to a completely different memory map. One major difference is that when the screen scrolls, the memory map layout remains fixed unlike on the real BBC, so the first character of the second line is ALWAYS at &FFFF7C28, essentially the screen memory contents are scrolled. A good MODE 7 demo is the Kingdom game from the BBC Micro welcome disc, a copy is linked on the website by the screenshot.

[jgharston]

Some very early BBC programs used out-of-range values to things like GCOL with the values being truncated, eg GCOL RND(blah) would be truncated to GCOL 0-7 with the defined effects for GCOL 0-4 and "odd" effects for GCOL 5-7 due to table overruns in the MOS. Similar things happens with some music programs, where other than the channel the SOUND parameters are 8-bit numbers, and programmers blissfully did things like SOUND ch,thing4... and it didn't matter that thing4 was eg &0268 as the SOUND system just took the bottom byte. Later MOSes such as RISC OS though took the full 16-bit value, giving unexpected results.

[soruk42]

Earlier I wrote: I could do something that searches and replaces pixels on a palette change, but that is also liable to problems as if two palette entries are set to the same value, the screen can't then tell them apart for future palette changes.

I've got this working, by using the top byte of the 32 bits per pixel, in paletted modes, to hold the logical colour used. This is ignored by SDL, but has allowed me to track the pixel value even if two colours are the same. Thus, I now have VDU19 updating the screen with a palette change immediately on the latest commit.