bank 0?

[novemix 0]

As far as I can tell, there is no Bank 0?

The emulator defaults to 1 (peek(40801)), and seems to go to bank 64 (for 512k)

Where else in computing are things numbered from 1... N?  Binary goes from 0 to 255 (1111 1111), not 0000 0001 to 1 0000 0000 (1 to 256)

poke 40801,0 works (peek(40801) then returns 0)
but then if you poke $a000,x, you only get 0 back, no matter the value of x

This is very strange behavior, and makes programming banks more complex, as checking for a 1 limit, or worse, a 256 limit (rather than 255) is a pain  (if 2MB of high mem)

Actually, I just realized, this makes accessing bank 256 impossible. 40801 can't hold 256.

Apologies if this is a known issue, I did some searching but couldn't find anything on this.

edit: looks like, with 512k, bank 64 isn't accessible

Edited February 1 by novemix

[Guybrush 22]

As per the Commander X16 documentation on Github:

This is the allocation of banked RAM in the KERNAL/BASIC environment.

Bank	Description
0	Used for KERNAL/CBDOS variables and buffers
1-255	Available to the user

[m00dawg 125]

It's slightly buried in the docs but it's outlined here.
Specifically:
 

Quote

 

This is the allocation of banked RAM in the KERNAL/BASIC environment.

Bank	Description
0	Used for KERNAL/CBDOS variables and buffers
1-255	Available to the user

(On systems with only 512 KB RAM, banks 64-255 are unavailable.)

During startup, the KERNAL activates RAM bank 1 as the default for the user.

 

EDIT: Ah Guy answered it as well, with better formatting FWIW, I have to content with this too in my tracker. Everything starts at 00 _except_ patterns, which have to start at 1 as I plan on using 1 8k bank per pattern (given the full pattern data for 25 channels is just about 8k).

 

Edited February 1 by m00dawg
JINX!

[novemix 0]

Ah, ok, thanks for the replies.

Still seems odd, when half of zero page, and 2 more pages ($200-$3ff) are reserved.  (mostly, why does it need $200-$3ff, when there's 8k in bank 0?)

Thanks

[Guybrush 22]

1 minute ago, novemix said:

Still seems odd, when half of zero page, and 2 more pages ($200-$3ff) are reserved.  (mostly, why does it need $200-$3ff, when there's 8k in bank 0?)

Because that area stores variables that are probably often used, and if they were in bank 0, then most if not all KERNAL and BASIC functions would need to switch banks all the time.

Imagine calling a KERNAL function with a parameter that references a memory area in bank 2 for instance... now if KERNAL needs to access its variable(s) stored in bank 0 for each byte it need to process, that would require at least two bank switches per byte processed. Not a very efficient use of processor time, is it?

[m00dawg 125]

In regards to the ZP reservations, while I might be doing it wrong, I just followed the docs on using r0-r15 in my own code. There were times something trounced over one of these but in general it's been ok to use these for passing parameters around between routines and free'd up my ZP space for other things.

[novemix 0]

Yeah, I guess I just feel like that 8k is a bit excessive to reserve, compared to what the c64's kernal/basic used.  Like why not just reserve $200-$7ff, and not bank 0?  (i'm not really complaining, since it has up to 2MB (minus 8k) of extra mem, just wondering how efficient it is, reserving that 8k)

 

[SlithyMatt 595]

5 minutes ago, novemix said:

Yeah, I guess I just feel like that 8k is a bit excessive to reserve, compared to what the c64's kernal/basic used.  Like why not just reserve $200-$7ff, and not bank 0?  (i'm not really complaining, since it has up to 2MB (minus 8k) of extra mem, just wondering how efficient it is, reserving that 8k)

 

In reality, only a small part of bank 0 is used. You might be safe in using the upper half at $B000 if you really need the extra space. I think having 63 other banks and a very fast SD interface is an embarrassment of riches for a 65C02 system.

[m00dawg 125]

4 minutes ago, SlithyMatt said:

In reality, only a small part of bank 0 is used. You might be safe in using the upper half at $B000 if you really need the extra space. I think having 63 other banks and a very fast SD interface is an embarrassment of riches for a 65C02 system.

That actually leads me to a question I've been wondering about that you might have the answer to, thinking about XCI. How fast is the SD card? Or I should say, what is the latency experienced in pulling data from it? I did a lot of rework for my GUI drawing routines, and while I think that is the right answer for what I need, I was also thinking about just pulling UI screens off the SD card. I was initially worried the lag would be excessive at least for programs where switching panes of view is pretty common. If the SD card is fast enough, that might not be a significant issue.

[SlithyMatt 595]

3 minutes ago, m00dawg said:

How fast is the SD card?

It's faster than the data bus, so the CPU pulling off bytes is the bottleneck. There is no DMA that could make loading to RAM or VRAM faster, unfortunately. This is done in the emulator when you use the SD card emulation. Be aware that if you are just using the host file system, you are effectively getting DMA, as the emulator RAM or VRAM is just being loaded natively by the host, not through the emulated 65C02.

Edited February 1 by SlithyMatt

[novemix 0]

5 minutes ago, SlithyMatt said:

In reality, only a small part of bank 0 is used. You might be safe in using the upper half at $B000 if you really need the extra space. I think having 63 other banks and a very fast SD interface is an embarrassment of riches for a 65C02 system.

Oh, of course, like I said, I'm just wondering about the efficiency of it.  Like if the 1k at $400 to $7ff, formerly used by the c64 for screen ram (and sprite pointers) would be more than enough, then reserve that, as using that area isn't any more advantageous to the user than anywhere else in memory, including banks (other than selecting the bank).

[SlithyMatt 595]

1 minute ago, novemix said:

as using that area isn't any more advantageous to the user

Actually, it is, because you don't have to worry about bank selection to use it.

[novemix 0]

1 minute ago, SlithyMatt said:

Actually, it is, because you don't have to worry about bank selection to use it.

As I said, but the same benefit would be had (I assume) by the kernal or basic routines that now use bank 0, if they instead used that area.  But like you said, we probably have more memory than we'll ever need as it is.  (Although, didn't they say that about 640k at one time?  ;D)

[TomXP411 357]

1 hour ago, m00dawg said:

That actually leads me to a question I've been wondering about that you might have the answer to, thinking about XCI. How fast is the SD card? Or I should say, what is the latency experienced in pulling data from it? I did a lot of rework for my GUI drawing routines, and while I think that is the right answer for what I need, I was also thinking about just pulling UI screens off the SD card. I was initially worried the lag would be excessive at least for programs where switching panes of view is pretty common. If the SD card is fast enough, that might not be a significant issue.

Depending on exactly how I do it, I read data from SD at around 9-11KBps (that's using CHRIN to read a byte at a time). An 80x60 screen is 9600 bytes, so call the worst case scenario 1 second of load time.  If you buffer to RAM, you should be able to push the entire screen over in less than one frame. So it's just a question of how quickly you need to present the data and how interactive your screens are. 

Of course, bear in mind that the current state of the emulator doesn't necessarily reflect the final system. I'm hoping we see some more code optimizations, and we know there will be some changes to how banking works. So I expect the final product to probably perform a little better. Also, there are better ways to load data than "read one character at a time through GETIN", so you can probably do better than I did with my initial tests. 

Still, I'd probably lean toward buffering screen elements that are constantly in use and loading stuff on-demand when it's only used once in a while or is largely static.

 

Edited February 1 by TomXP411