CRTC R12 and absolute ram address

[Curlypaul]

I can't recall where I read this, but as I understand it the CRTC uses the absolute RAM address and not the current logical ram address. Apologies if my terminology is wrong.

So with this in mind I thought that if more than 64k is available, then we'd be able to expliot this to double buffer without having to sacrifice so much memory, but it seems not.

Code Select Expand

;; Draw some pixels on the screen
ld hl,#C000
ld (hl),%11110000
ld d,h
ld e,l
inc de
ld bc,100
ldir

;; Bank switch #c000 out to somewhere else
ld bc,#7fc1 ; 0127
out (c),c

call #bb18 :First
;; Draw something different in c000
ld hl,#c000
ld (hl),%00001111
ld d,h
ld e,l
inc de
ld bc,200
ldir

ld bc,#BC0C
out (c),c
ld bc,#BD00+48 ;; &C000
out (c),c
I was hoping at this point the CTRC would re-reference the current memory positions and draw the new screen. In fact I can't find any way to make it draw the pixels in C000. I've tried changing R12 to use #8000, some more bank switching and forever more when rending C000, it only draws those original pixels.

Is what I'm trying to do possible? It doesn't seem it, but I'd like to understand what's going on with R12 and the logical/absolute RAM addresses

[fgbrain]

CRTC reads (displays actually) from only the first bank of 64kb - so no it cannot display anything from any kind of extra ram....

[McArti0]

If you set C1 and bank 7 is at &c000 then bank 3 is in shadow for Z80 but sill screening by CRTC.

[Curlypaul]

CRTC reads (displays actually) from only the first bank of 64kb - so no it cannot display anything from any kind of extra ram....

Right so to display some data, it has to be in RAM0-4, it literally can't show anything stored in any other chip?

Damn, that's more restrictive than I thought things were going to be 

[Curlypaul]

If you set C1 and bank 7 is at &c000 then bank 3 is in shadow for Z80 but sill screening by CRTC.

I added a bit onto the end of my example which I'd missed, I was hoping to draw to the screen, page that away, draw another screen at the same address and then change R12 to display the new one, thus only having the 16k I'm currently drawing in memory, but not going to work is it.

Thank you for you help guys

[McArti0]

You can changing C0 and C3 and drawing always to &4000 (Bank 1 or Bank 3) . 
Drawing by basic past poke &b7c6,&40

[Curlypaul]

That seems to be the way to go yes, problem is #4000 is the most useful in terms of paging in the extra memory. Not a huge issue, it what 2 vblanks to copy 16k into another bank to be used? I can live with that 

[Nworc]

That seems to be the way to go yes, problem is #4000 is the most useful in terms of paging in the extra memory. Not a huge issue, it what 2 vblanks to copy 16k into another bank to be used? I can live with that

I'm not sure why you want to copy 16K of memory, that sounds like something you want to avoid.

As you said, the block starting at &4000 is normally used to switch the RAM banks for the CPU.
If you want to do double buffering, why not switching the CRTC R12 between &8000 and &C000? That way you have 32K of video RAM at your disposal.
This is of cause only an option if in your project you don't need the operating system, set the stack to &3FFE, then you can use the block at &4000 to switch in any RAM blocks, and use the whole space from &8000-&FFFF for display.

Some people would say kicking out the OS is bad style. They are right, but I don't care.

[Curlypaul]

I've got a lot of bitmaps and music that need to be stashed in memory before I wipe out the firmware, so seems I would need to copy them before I could show them. 

I can only find examples of loading from disk that use the firmware so far, not sure if I can create my own routines or if I'll still need the default #38 jump block value for any disk loading to work anyway. 

[gurneyh]

Hi

You can copy or restore the firmware vectors.
A rom call is enough to restore the system vectors, however, to my knowledge it will not work with the M4.
By copying them, however, it will work in any case.

Another solution is to do without the firmware completely
http://www.julien-nevo.com/arkos/fdc-tools/
But again it won't work with the M4

[Nworc]

You don't need to write your own disk loader for this, you can still kick the firmware back again in, which is of cause possible if you don't need the data between &A800-&C000 while loading, and if you know how to do that, which requires enabling the LoRom from a save place and do the right system calls (would have to check the Kernel manual to see how to do that).

Ah, I see, gurneyh was faster ...

PS: Very cool that Targhan published the source of their FDC routine. Still I think, if it's possible in your project, try to use the firmware routines if possible.

@gurneyh: What is the problem anyway with the M4 by restoring the firmware vectors using the right kernel calls?

[gurneyh]

@gurneyh: What is the problem anyway with the M4 by restoring the firmware vectors using the right kernel calls?

The M4 changes the system vectors.
Also, restoring in the standard way does not work.

[Curlypaul]

oh wow great info guys thank you very much, especially the fdc tools, very useful.

I obviously need te read deeper into the firmware manual to see what's possible with the roms as well

[Nworc]

Here is something I dug out .. one method to bring back the firmware including the disk ROM after the memory was cleared is something like the following - but if you want to use it better test it, don't rely on that this is ready to use.

What need to be done is enable the Lo ROM on the GateArray beforehand, and replace the Call &BD16 by the actual target in the ROM (464: 060B, 664: 0609, 6128: 061F), after that call, the jump blocks can be used again. Maybe other people here know a more elegant way for that.

This brings back the firmware and disk rom. Guerneyh mentioned above that the M4 would not be hung in by this procedure. I believe that replacing Call &bcce (kl init back) by Call &bccb (kl rom walk) would solve that, as the only method of the M4 to get hung in logically would be via a rom.

Just try it, and feedback if you do would be nice. The only not-nice thing about this rom walk is, that it might take a second or so, depending on what the Roms do that are hung in, and if roms think they want to say hello, you would see that on the screen. Setting the ink of pen 1 to background solves that, alternatively poke a &C9 into &BB5A (TXT Output)

 ld bc,&7f85 ; enable lo rom and set mode 1
 out (c),c
 ld hl,boot
 ld c,&ff
 call &bd16   ;mc start program  ; replace by actual Rom address
.boot
 ld a,&c9
 ld (&bb5a),a  ;mute the ROM blathering
 ld c,&07
 ld de,&0040
 ld hl,&b0ff
 push de
 call &bcce   ;kl init back: kick in the disk rom  (alternatively: call &bccb   ;kl rom walk)
 ld hl,disk
 call &bcd4   ;find rsx command: |disk
 xor a
 call &001b   ;execute the comman
; continue with your loader, you can use regular system calls now

.disk defm "DIS",&c3  ; RSX |disk

[gurneyh]

This brings back the firmware and disk rom. Guerneyh mentioned above that the M4 would not be hung in by this procedure. I believe that replacing Call &bcce (kl init back) by Call &bccb (kl rom walk) would solve that, as the only method of the M4 to get hung in logically would be via a rom.

Yes, kl rom walk is probably the solution.

Oddly enough, I seem to have tried this solution but was having other problems.
Also, I don't have an M4 so it wasn't easy to test.