Commander X16

1 hour ago, Scott Robison said:

Just to be clear: It's not necessarily that the FPGA needs a lot of logic cells to allow an external source (such as the X16) to interact with SPI. It's that in order to add the flexibility to VERA to allow it to directly store bytes from SPI to video RAM without passing through the CPU first would require more logic cells than are currently allocated to it. Even if there are enough logic cells left to support a "fire and forget" strategy for the next X bytes, it's not as though we're dealing with a full blown multitasking friendly CPU or OS. Typically (or so it seems to me) if you have an ability to tell the hardware "transfer the next X bytes without the use of the CPU" you would generally want to signal the main system when that process is complete so that it can set up the next transfer. Given the typical implementation of the kernal, it would wind up sitting in a busy loop waiting for the signal that the transfer is done.



I see several possibilities:



1. There aren't enough logic cells available to add the functionality to support both CPU and VRAM delivery options.



2. There are enough logic cells available but it increases the complexity meaning there is another thing that could go wrong, and it doesn't really improve CPU performance because it still has to wait for the delivery notification.



3. There are enough logic cells available and the kernal becomes more complex due to dealing with an interrupt driven SPI interface so that the CPU can go on about other business while waiting for the background VRAM transfer to complete.



In a perfect world, sure, it would be nice to support this mode. I think the general purpose approach is more than adequate for most tasks, even if it isn't optimal for loading into VRAM. It's not like sales of the C=64 were too negatively impacted by its slow IEC bus protocol.

46 minutes ago, Wavicle said:

I could see a SPI-to-VRAM mechanism improving performance of some specific/niche activities; e.g. you could stream frames from the SD card directly to VRAM for video playback. Not sure that would be enough to justify the complexity though.

4 hours ago, Scott Robison said:

Agreed.

5 hours ago, Wavicle said:

I could see a SPI-to-VRAM mechanism improving performance of some specific/niche activities; e.g. you could stream frames from the SD card directly to VRAM for video playback. Not sure that would be enough to justify the complexity though.

57 minutes ago, Ed Minchau said:

 



See, that was my incorrect assumption when I made video demos for the x16.   It seemed logical to me that transfer from SD card to VRAM would be faster than 140kb/s rather than slower.  So that's exactly what I was doing, loading tilemaps and palettes directly from SD card and playing them at 20 fps. Well, it won't work on the actual hardware. 



It's just something that wasn't explicitly stated in the documentation that loading to VRAM is slower. No mention of that speed at all, actually. 

On 12/5/2021 at 6:25 PM, rje said:

Would the pi1581 give a reasonable data transfer rate?  Assuming the x16 could do fast serial?

On 12/7/2021 at 11:56 AM, xanthrou said:

Irrelevant question, but would the X16 support MMC cards, since most SD sockets do have backwards compatibility with MMC cards?

On 1/3/2021 at 1:38 AM, m00dawg said:

I can't remember why but as I recall there were some good reasons for dropping Serial UART from the Vera. I'm trying to remember this from a post on FB (though I no longer use FB so can't go reference it). Anyways! We had an interesting conversation on the Unofficial Discord about getting data to/from the X16. For development, having to constantly remove and insert the SD card might get old. And likewise, transferring files (like maybe tracker files, text files, etc.) to/from another machine could be convenient. This is especially true given SD cards aren't really meant for long-term storage - if you don't power them up every so often, particularly as wear due to writes, the data can be corrupted. This has happened to me a time or two with a Raspberry Pi I only use during Christmas (for a light show, of course!).



So, I'm trying to think aloud about what sort of options might be usable. Of course doing something with the User Port is an option, eventually I'd expect someone is going to implement a serial or even a NIC on an expansion card, then there's IEC Serial. The only serial work I've done is RS232 and I was pondering something like ADTPro where files can be copied over serial with the help of apps on both sides. That, of course, requires RS232 so currently isn't a viable option, though IEC serial presents a potential option, maybe, with using the IEC to Parallel interfaces on PC (I haven't used one in a de...err several years we'll say).



The thought of a Wifi-enabled SD card was tossed around too. I've never used one but that would be an option.



And then the user port might be able to be used for some sort of soft-serial type of solution?



Any other thoughts folks might have? Note, this isn't a dig on the design or lack of serial - this isn't a thread meant to wish for a UART on the X16 or anything. Not trying to be a jerk haha I just didn't want this thread to spiral into a wishlist thread as often happens many times (e.g. whenever someone mentions the word "sound").



I'm just trying to think aloud with the options we have currently and what might be possible or what other folks are thinking about as a potential solve?

On 12/21/2021 at 1:57 PM, martinot said:

Serial port would be good, but why not Ethernetport?