[Coco] ASM Coders - Round two!

[David Roper]

Robert Gault wrote:
> William Astle has given you the correct answer but I'll expand the 
> explanation.
>
>  You have chosen to move the hi-res graphics screen into your 64K 
> address space so that it starts in the MMU block controlled by $FFA1; 
> $2000 - $3FFF. That is perfectly OK but if you wish to address the 
> entire screen in one contiguous block of memory, you need to consider 
> exactly where it is going.
>  I said in a previous message on this snip of code, that the screen is 
> $7D00 bytes long; $60000 - $67D00. (The total assigned Coco3 space is 
> $60000 - $68000.) You are moving it to start at $72000 and end at 
> $72000+$7D00=$79D00. So where is that in your 64K address space? It 
> starts in free ram but ends in "ROM" address space which on the Coco3 
> is normally RAM.
>  Your counter is initialized to $3E80. So only memory from $2000 - 
> $5E80 gets changed. This is also OK. The problem is that you have 
> taken a previous suggestion that killing the IRQs was not needed and 
> applied the suggestion to new code. Let's see what that means.
>  Actually including LDA #$32, STA $FFA3 does nothing bad. That's 
> because it changes memory at $6000-$7FFF. The only trouble will come 
> when you include LDA #$33, STA $FFA4  because that will remove the 
> first MMU block of Extended Basic code, $8000 - $9FFF. This will crash 
> the Coco3 if the interrupts are still engaged.
>
>  But that still does not address your question which implies that just 
> changing *LDA #$32, *STA $FFA3  to  LDA #$32, STA $FFA3  causes a 
> change  in what you see on the screen or possibly more trouble. That's 
> because it won't do anything! You are either confused about what 
> happens when you change $FFA3 or have not written your question 
> accurately.
>  In either case, there can be garbage in the lower half of the screen 
> because you are clearing $3E80/$7D00 = 0.5 or half of the screen. 
> Unless you have preset the graphics screen to a specific pattern, it 
> will contain garbage which may or may not be random.
>
>  So the full answer to clearing the complete 320x200x16 screen is your 
> counter must start at $7D00. If you want the entire screen mapped into 
> your address space, you must turn off the interrupts, swap the MMU 
> blocks, send data to the blocks, restore the MMU blocks, and restart 
> the IRQs.
>  You don't have to map the entire screen at one time nor do you need 
> to restart IRQs. But you must give more thought to the side effects of 
> your code.
>
Hi Robert, and thanks to all others who replied as well

Sounds like I'd better clarify precisely what I'm aiming at doing, so I 
can get advice on what I should be doing :)

I'm writing a "fire-effect" demo, where flames are 
mathematically-generated on-screen. This is a traditional "Demo"-style 
effect

For my plot-pixel routine to work, and so my head doesn't explode, I 
want to have the graphics memory mapped to 32k of contiguous space, so I 
don't have to calculate which block I'm supposed to be writing to, nor 
swap bits and pieces in and out

I'll also need another 8k block for heat data buffers, and some safe 
space for the code

As far as I'm aware, I wont be requiring interrupts, as the sole purpose 
of the software is to generate a fire

I was only clearing half the screen in the code I posted because this 
happened flawlessly. The "garbage" I referred to was more of a 
"corruption of the existing garbage", as the bottom half of the screen 
presented the same pattern of garbage data (alternating vertical green 
and black lines) every time I ran the (working) code. This pattern was 
corrupted when I mapped LDA #$32, STA $FFA3

So, the questions:

a) To achieve 32k of contiguous memory (whether the physical ram is 
contiguous or not is irrelevent, as long as it's mapped to be 
contiguous), where can you recommend I map this to?

b) can i simply disable interrupts and leave them disabled for the 
entire code, without side effects?

Thanks!