Commander X16

3 minutes ago, paulscottrobson said:

Is DMA Access going to be a thing with peripherals, specifically Vera ?



 

As I understand it, it has only few advantages but many drawbacks. Timing is much more critical. If I got it right, it works by suspending the 65C02 and using the bus all by yourself. That might lead to unexpected results as this could happen at any time, I guess transfer start should be triggered by 65C02 code.

I am not sure about the speed advantage, maybe someone could help me here: 

I believe DMA can write one byte to any address (on an active bank) in 1 clock tick, so effectively writing at 8 MByte/s. Using memory mapped I/O this is reduced to the speed of READ,INCREMENT,LOOP cycle, so at best like this - sorry, my 6502 assembler is a bit rusty... 

(Transfer 256 bytes memory mapped IO with auto decrement on external side):

  LDY #$0

loop:

  LDA $MEMORY_MAPPED_IO_ADDRESS  ; 4 ticks

  STA $TARGET_ADDRESS, Y   ; 5 ticks

  DEY  ; 2 ticks

  BNE loop  ; 3 ticks (given that code is page aligned)

So, transfering would cost like 14 ticks, not using zero page tricks if that is possible. So let's just say 10 ticks optimized - DMA transfer is still at least 10 times faster. Is that true?   

 

Ben Eater talks about DMA and the RDY pin on the 6502 in this video: 

From around 6:30 he talks about how his video card "pauses" the CPU to read the memory.

I am pretty sure that VERA will never use DMA as it has it's own memory. Other peripherals might use DMA, but I think that IRQ and/or polling will be a lot easier. 

 

13 hours ago, BruceMcF said:

I also like the idea of a way for a driver to check whether it is already loaded. One idea is to have a defined High RAM segment that contains user readable configuration data like a HighRAM segment BAM, which could also contain a linked list of names of loaded drivers, so an installation program can check whether it's not yet loaded, or perhaps it's been loaded but taken out of the API chain.

oh yeah ! That's sound very nice to my ears :):)

Please refrain from discussing DMA on this thread as that’s really another topic.  In fact much of this conversation is so far off topic. No there isn’t gonna be any way the cards can self identify themselves on initialization. For the most part they’re just gonna be off-the-shelf logic chips. A SID chip can’t identify itself. To get into cards that are true plug-and-play you’re getting into really complex stuff that we just simply are not going to do. If you wanted to sign something that goes that fine he just has to stick within that 32 bike limit and have some kind of usability. But the system itself frankly doesn’t care.  It’s a simple as this you want to put in a new card you install the new card. It won’t do anything without software but it’s installed. If you want to use it then you have to install software that works with it. And you have to tell the software how you’ve installed it.  If specific software directly supports the card you don’t need a driver. If you want the car to work with BASIC in the KERNAL then you do need a driver.  The prime example of this is going to be say a proper RS 232 card. If you plug in the card by itself it’s not gonna do anything it’s not gonna break any software it just won’t do anything. So then you install a kernel extension patch and configure it to use I/O5. All the KERNAL patches effectively does is make sure that all RS 232 data goes to the card instead of the built-in bit bang serial. It basically just puts a new set of routines in memory somewhere, and changes the vector entries so they point to the new routines.  Sent from my iPhone using Tapatalk

All the KERNAL patches effectively does is make sure that all RS 232 data goes to the card instead of the built-in bit bang serial. It basically just puts a new set of routines in memory somewhere, and changes the vector entries so they point to the new routines.

I thought KERNAL would be in ROM, and would run directly from there. So how do I change its vector entries in ROM?

6 hours ago, Cyber said:

I thought KERNAL would be in ROM, and would run directly from there. So how do I change its vector entries in ROM?

The vector table is copied into ZP at bootup. This is how it's accessible from any bank.

10 hours ago, Cyber said:

I thought KERNAL would be in ROM, and would run directly from there. So how do I change its vector entries in ROM?

There is a set of vectors that various I/O routines use, between the hardware stack at $01xx and the Golden RAM at $0400-$07FF.

At power up they are set to point to Kernal routines but you can install drivers by copying the current vectors, writing in vectors pointing to your driver, your driver checks if it is the device being called, if not, it SHOULD jump to the previous driver. So the two main tasks of driver installation are hooking the driver code into the vector chain, and finding places to put the driver code ... typically the end of system RAM, Golden RAM or bank accessing code in one of those two and driver code in a RAM or User ROM segment if the driver code is longer. The Low RAM part could be as short as a far call to the routine in its segment, but if the device checking is done in Low RAM and you only far call when it IS your device number, that would make a faster device chain.

20 hours ago, TheUnknownDad said:

On card installation process, when running the installation software, expansion cards could be in a "uninitialized phase" and provide a standard interface for information on the card itself, including an interface to get the built-in driver in a byte-by-byte interface, just like data transfer to VERA works, but in the other direction. The install software can get the driver this way and put it on the SD card. Any comments on that idea?



I believe, there should be this two phase standardized talking to expansion cards in any way. By using only few I/O RAM spaces for that communication it would also be possible to add this without really implementing two phases on the card, since it could be like first 8 bytes are init phase standard use, leaving 24 bytes for free use without extra cost of implementing 2 phases on the card. If it needed all 32 bytes, fine - the driver should set it to phase 2 mode after finalizing initialization. Again, any comments?

Cards won't provide a "standard interface". A card might be two VIA chips, a jumper block to select which segment it shows up in, and a quad NAND  to handle the /CS and A4 to pick the correct VIA.

A card might be a 65xx bus SPI controller and an SPI serial chip. For the first one, the drivers depends on what it is being used for. If it is for a program that knows it's there, maybe all it needs is a small SEQ file that says which device space it is using. For the second one, the drivers will install as the serial device.

There is no underlying OS to install these cards into, so there is no leverage point to motivate the creator of either card to add any extra hardware. If lots of cards don't t support whatever "standardized" protocol, it's not a standardized protocol, it's just another system that could be used.

The cards come with one or two binary files that are the driver itself and the driver installation program. The driver installation program can easily be a Basic program, but it might be a binary PRG (whether written in Assembler or C, Forth, Pascal, etc). And a SEQ file with instructions, information about potential conflicts, etc.

So, how does fixing the problem with running subprograms not fix the problem with a main CONFIG.BAS program? The only task here is to make it easy to add the driver install programs to an autostart program.

IF the "V2 subprograms trample callers if the callers are smaller" problem is fixed, the main points to "standardize" here are the name of the autostart program and the folder name for holding drivers and driver install programs.

On 1/8/2021 at 9:14 AM, Lorin Millsap said:

On the subject of potentially having a ROM on the expansion cards, a potential solution could be bringing SPI or I2C into the expansion slot. Then you could place a ROM on that card but this alone does not fully address some of the issues so the code in this ROM would need to have enough flexibility to handle the issues.



The main issues

1. the code still needs to be able to account for the address the card has been assigned to. So you either need a way to assign what ID the card is or to auto detect the cards ID.

2. You cannot execute code directly from a serial ROM so it still needs to be copied to RAM in a way to doesn’t overwrite other important code.

3. The code has to set itself up or in order words it is self modifying code. It needs to basically load into a staging area, then execute and copy its routines to a safely assigned area and tie itself into the KERNAL vector table and tie in relevant IRQ.



This is all doable, but whether it’s located in a ROM on the card or gets placed on the SD card it still has to account for and dolce the same problems. Locating it on the SD card allows greater flexibility. Putting it on a built in ROM kind of black boxes the code to a degree. Yes it may have a degree of plug and play ease if set up correctly, but it brings new challenges too.





Sent from my iPhone using Tapatalk

1. Serial ROM... I think the EasyFlash and GMod use this system to save games. 

2. Vector reading from card ROM the same way VERA is vectored. Some sort of latch on the card would set the address on the ROM chip, which would put the data on a particular address on the card. 

Those approaches would still require cooperation from the Commander, though... and since this means running a program from SD, there's little reason to store data on the card when one can just read it from the SD card.

The only thing I can think of that would be useful is a ZIF socket on the motherboard for a user ROM... then a user could install a driver or utility ROM for an expansion card. 

24 minutes ago, TomXP411 said:

The only thing I can think of that would be useful is a ZIF socket on the motherboard for a user ROM... then a user could install a driver or utility ROM for an expansion card. 

Why not in one of the unused ROM segments? They surely won't be filling up all 512K of the ROM.

Again, the driver installation program can easily look for an .INFO file that includes an entry if the driver is available in ROM and what bank and addresses to install into the vector chain. As long as a generic program can be added to a list of programs to run, that would appear to be covered by the upgrade from 128K to 512K FlashROM.