Commander X16

On 1/5/2021 at 4:18 PM, kktos said:

As a dev, I'm a tad displeased by the change for Bank Switching to ZP $00/$01.....

Not coherent with all the other system switches (mem location wise, I mean).

Taking 2 addresses on the tiny and already packed ZP.

Am I the only one ?

Not really, given that the ZP is NOT already packed ... at least, compared to the tiny amount of free User zero page space available to the C64, $02 to $7F is a big slice of zero page for assembly language programs even when called by Basic as SYS routines.



And it was heading toward having almost no User Port capabilities at all, while now it has more GPIO available than the C64 User Port had.

20 hours ago, kktos said:

:oD

32 ? ok, seriously, I thought only about the VAddr (3), VData0 (1), VData1 (1) and VCtl (1)

Part of the benefit of the emulator seems like finding out where that was a bottleneck in juggling access to internal VERA registers, especially for things like running sound on an interrupt loop while pumping graphical data into the "VRAM", leading to a change to the Vera design to map a critical range of internal registers directly into the address space, occupying the full 32 byte range for a single memory mapped device.



It's certainly cleaner for the "mirrored bank register latch" approach to be selected in the bottom half of RAM when all of the address space CONTROLLED by the latches are in the TOP half of RAM ... and if selected independently of the select logic for the ROM and RAM banks, there is no simpler space in the bottom half of RAM to select for than $0000/$0001.



And of course, for anything ported from or made to be portable to the C64, the internal I/O port in the MOS6510 at $0000/$0001 means that things like a Sweet 16 engine already starts somewhere above $0001.

Here is Adrian's video about the troubleshooting:

Part of my thinking as I’m the one who pitched the ZP banking feature to Kevin was that by making it a ZP feature it speeds up all banking operations. This includes many KERNAL functions since those are often in banked ROM, as well as user code that uses banked RAM.  Admittedly in theory using ZP for VERA makes some sense for speeding up access, the added circuit complexity isn’t desirable and you have to be aware that the more memory decoding you add the more potential it has to add unwanted timing delays which could result in stability issues.  On this I suppose I should clarify how the latches basically work and to do that I need to explain how the normal IO space works.  So as you know there is a RAM and ROM in the base 64k memory map. By default the RAM is selected with exclusions. If the address lands in the ROM memory range the RAM is excluded and the ROM gets addressed instead. The same is true for the banked RAM range. This also applies to the IO range. This allows any of the chips in those ranges to be addressed correctly without any bus contention.  However how the zero page latches work is a little bit different. The latches “shadow“ the ram. Basically the latches themselves are write only. When you write to $00 or $01 you write to RAM and the latches. The RAM is not excluded the way it is for other address ranges. When you read $00 or $01 you are reading from RAM.  Now if you wanted to move VERA to zero page you would need to add exclusion logic to the RAM so that it doesn’t conflict. But every bit you add does 2 things. Firstly your part count goes up which drives up cost, but also you add propagation delays which if you get enough will cause unstable operation or non operation.   Sent from my iPhone using Tapatalk

Its great to see Adrian contribute. I'm sure the entire team appreciates him. The excitement is building ?

Moving the bank registers to zero page only makes sense if it is also possible to read them. It is useful to allow calls between banks using a trampoline (bank switcher) in non-banked memory. Such trampoline needs to push the bank number together with the return address so that it later can return via another trampoline to the caller (switching the bank back).

If reading is not possible, a shadow bank number could be written to RAM, but that would mean writing the bank twice which defeats the gain of having it in zero page.

Moving the bank registers to zero page only makes sense if it is also possible to read them. It is useful to allow calls between banks using a trampoline (bank switcher) in non-banked memory. Such trampoline needs to push the bank number together with the return address so that it later can return via another trampoline to the caller (switching the bank back). If reading is not possible, a shadow bank number could be written to RAM, but that would mean writing the bank twice which defeats the gain of having it in zero page.

I think you misunderstood me you can read them technically the value stored in RAM and the value stored in the registers should always be the same. The only exception is during initial power up the ram might contain random values but is soon as the post rouroutine writes the bank it will immediately be updated and match. There is no condition once it is set where the value you read back will ever be different than the actual value stored in the latch.  Sent from my iPhone using Tapatalk

Nice job by Adrian in explaining what the issue was.

Sounds like Kevin was so close, but as Adrian said, it just needed a second set of eyes to look at it a little differently.

  I'm still learning these things, so please forgive me for my dumb questions. I ask them to better understand how things work.

 

10 hours ago, Lorin Millsap said:

So as you know there is a RAM and ROM in the base 64k memory map. By default the RAM is selected with exclusions. If the address lands in the ROM memory range the RAM is excluded and the ROM gets addressed instead. The same is true for the banked RAM range. This also applies to the IO range. This allows any of the chips in those ranges to be addressed correctly without any bus contention.

I already knew this about the ROM. And it sounds clear for me about banked RAM.

But speaking about IO... I thought that IO range is actually stored in RAM, and each device has access to its own RAM range inside IO range. So am I wrong? From Lorin's quote above it seems like each device has its own latches to store its data.

 

10 hours ago, Lorin Millsap said:

Now if you wanted to move VERA to zero page you would need to add exclusion logic to the RAM so that it doesn’t conflict.

Why would it conflict? If I move VERA registers to zero page, shouldn't VERA register values be technically always the same as RAM values? What am I missing?

55 minutes ago, Cyber said:

But speaking about IO... I thought that IO range is actually stored in RAM, and each device has access to its own RAM range inside IO range. So am I wrong?

hardware can't directly access ram because only one address can be read from ram at a time, and the 6502 does a memory read or write nearly every cycle. so, communication with hardware needs to be done with latches that are (physically) outside the main ram.