I was about to go to bed when I thought I would have a quick poke at my Jaguar code and run my memory dumper against a known good object list.Â The results? mine matched (as much as it could given they resided in different parts of RAM and hence had different link data etc).. So, why is it that mine didn’t work and this other did.
My first thoughts were that perhaps the two branches I had put at the start of my list were in-correct, they should be there I recall to keep the hardware happy, but this other list didn’t have them and worked.Â So I skipped the branches and fed the OP the address of the raw meat of the list.Â OUTPUT! although not what I expected, some garbled lines, and not a smidgeon of anything resembling the bitmap it was supposed to. Hmmm more pondering.
Inspiration came and a glance at the developers manual to confirm.. 16 byte boundary in 64 bit RAM.. HmmmmÂ A few tweaks here and there and I tried again, dumping the list from its full head including branches but ensuring that the meaty goodness resided only on a 16 byte boundary.Â The dump now showed a row of zeros between the last branch and the bitmap object and the monitor showed the bitmap!Â EUREKA!Â success at last.Â It even looks like the adjustments for start of display worked too!Â I am most pleased with myself.
Now I just need to work on ensuring that bitmap object reside correctly and that the prior object is aware of this for link generation! more complexity, or waste a bit of RAM.. for now I think I might just go for the more wasteful route, its only a few bytes and I have 2MB to play with 😀