Commander X16

17 minutes ago, lamb-duh said:

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.

That's not quite correct, but Cyber's not correct, either.

Hardware actually CAN directly access RAM. It just needs to assert the DMA pin on the CPU. This suspends the CPU and lets the hardware access the bus. 

However, that's not how I/O devices usually do it. They use something called the Chip Select (CS) pin. 

Every clock cycle, every device on the bus looks at the CS pin and decides whether or not it should respond to the address and data bus. If the CS for that device is high, that device is allowed to talk to the bus. If the CS is low, that device is NOT allowed to talk to the bus.

On the Commodore 64, the device that controls the CS pin is the PLA chip. This chip examines the data bus address on every clock cycle, then sets the CS pin for every device on the system based on the current bank configuration and address on the bus. 

So when the address is in the RAM range, the PLA sets the CS pin tied to the RAM chips. When the address is in the ROM range, the CS pin for the ROM is activated. This is what allows RAM, RAM, and I/O to all live in the same address ranges and be banked in and out as needed by the operating system. 

 

@lamb-duh @TomXP411

Ok, so I/O latches usually are physically outside the main RAM. We also call these latches "device registers". When we access them programmaticaly we actually don't care how they implemented physically, we just read or write I/O address in memory, thus communicate with device.

But speaking physically - what are these latches (registers) are? Is it internal part of actual device? Or is it just another separate RAM-like chip somewhere on board? Or it might be one or another?

16 minutes ago, Cyber said:

@lamb-duh @TomXP411



Ok, so I/O latches usually are physically outside the main RAM. We also call these latches "device registers". When we access them programmaticaly we actually don't care how they implemented physically, we just read or write I/O address in memory, thus communicate with device.



But speaking physically - what are these latches (registers) are? Is it internal part of actual device? Or is it just another separate RAM-like chip somewhere on board? Or it might be one or another?

In case of VIAs, YM-2151, VERA, the're internal to the chip.

In case of $00 and $01, they're in separate components on the board, probably in the same bunch as the address decoding logic.

On 1/7/2021 at 2:28 PM, Cyber said:

 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.

No, 65xx family IO devices are "memory mapped", which is to say that the processor does not have any special signal to say it is talking to IO, it reads or writes to "an address", and it is up to the system design to either select RAM or select an I/O device at a particular address.



The CX16 selects IO when any one of the $9Fxx addresses are read or written to. Those are 256 addresses. In binary that is %10011111xxxxxxxx. Those eight "x"s have two different jobs. The first three select the specific device "space", the remaining five select the up to 32 addresses available for each device "space". So it could be expressed as %10011111dddaaaaa. When ddd=%000, you are selecting the VIA's. Each VIA has four address lines for a total of 16 register locations, so by using the top address line to select between the two, you can fit two VIA's in one "device space". The (updated from it's original design) VERA address space is fully populated with five address lines so the VERA occupies one whole address space.



Five of the address spaces are allocated to the cards. How that works, I won't have time to find out until after the semester ends, but there could be a dedicated select line for device spaces 4-7 (of 0-7) for for cards 1, 2, 3, and 4, and a common select line for space 3 that goes to all four card slots, which some expansion cards can take advantage of for extra I/O space. Indeed, if there was a "enable use" select bit in the "native" address space, the "common extra" 32bytes could be shared by cards if their drivers knew about each other.

If I want my programs now to be compatible with the older configuration (and V38 emulator) and also work with the new $00/$01 bank registers, will it be okay to simply write the same value to $9F60 and also to $00  (for rom bank) and $9F61 also to $01 (for ram bank)  or are the old bank registers repurposed and it it no longer safe to write to them like this?

(also do i have the order of $00 and $01 correct?)

Just now, desertfish said:

If I want my programs now to be compatible with the older configuration (and V38 emulator) and also work with the new $00/$01 bank registers, will it be okay to simply write the same value to $9F60 and also to $00  (for rom bank) and $9F61 also to $01 (for ram bank)  or are the old bank registers repurposed and it it no longer safe to write to them like this?



(also do i have the order of $00 and $01 correct?)

Repurposed ... those are VIA parallel ports, some of them will now be on the User Port.

4 hours ago, TomXP411 said:

Hardware actually CAN directly access RAM. It just needs to assert the DMA pin on the CPU. This suspends the CPU and lets the hardware access the bus. 



However, that's not how I/O devices usually do it. They use something called the Chip Select (CS) pin. 



Every clock cycle, every device on the bus looks at the CS pin and decides whether or not it should respond to the address and data bus. If the CS for that device is high, that device is allowed to talk to the bus. If the CS is low, that device is NOT allowed to talk to the bus.

Ok, so will this mode be supported on the X16? I am currently thinking of developing an expansion card for communications. Moving "large" memory blocks (large in terms of X16) is very CPU intensive and requires many RAM access events.

Is getting next command from RAM/ROM in the 6502 also tied to the same bus at the same system clock? If so, moving a single byte would involve like about 10-12 clock ticks - pausing the cpu would make IO run at least 10x the speed. Am I right to this? And is this possibly supported for X16 expansion cards? 

7 minutes ago, TheUnknownDad said:

Ok, so will this mode be supported on the X16? I am currently thinking of developing an expansion card for communications. Moving "large" memory blocks (large in terms of X16) is very CPU intensive and requires many RAM access events.



Is getting next command from RAM/ROM in the 6502 also tied to the same bus at the same system clock? If so, moving a single byte would involve like about 10-12 clock ticks - pausing the cpu would make IO run at least 10x the speed. Am I right to this? And is this possibly supported for X16 expansion cards? 

Since the expansion ports (at least to my understanding) have all 16 address lines and both the RDY and BE lines, you should be able to halt the CPU and take over the system, even going as far as replacing the 6502 with another CPU (e.g. a 65816) on your expansion card.

  I'm still learning these things, so please forgive me for my dumb questions. I ask them to better understand how things work.
 
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?

Technically yes, but then you have 2 devices driving the bus at the same time and they may have different timing. At best that’s a bad practice and at worst you could damage something and most of the things in between involve data corruption and unstable operation. You only ever want on thing driving the busses at any given time. The banking latches work because they never drive the bus.


Sent from my iPhone using Tapatalk

18 hours ago, Lorin Millsap said:

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.

Great minds think alike ;oD

https://github.com/commanderx16/x16-rom/issues/184