Getting data to/from the X16

[BruceMcF]

3 hours ago, TomXP411 said:

And the flip side of that argument is...  there's no way a 6551 based expansion card will cost less than that, and someone has to write the drivers - whether before or after launch. 

Which gets to the expected market share. If the target for the 6551 is 20% or less of the audience, that's where the fact that it's cheaper for that 20% versus being no benefit to the other 80% comes down on the side of it being on an expansion card.

So would it be more like 60% or more like 20%?

USB Flash Drive sneakernet might be what a certain cluster want, and a Pi Pico, which can act as a USB Host (and which didn't exist back when this project started), would just need some voltage level shifting on a User Port daughterboard to offer that. If backup is the main target, then using the parallel port as an output and the hardware serial line as a clocked serial port input would give much faster throughput than the IEC. A micro-USB to go cable strung out from inside the case would be all that is needed to make the USB flash readily available toward the front of the system.

WiFI may be what a certain cluster wants, and while those who have multiple retro systems would get economies with a fast serial port to a WiFi modem approach, a PiModem on a User Port daughter board or expansion card might be a better solution for those who only have the CX16.

If its connecting to the PC, a EPP parallel port and compatible USB-Parallel adapter cable might be the easiest way to go.

In any event, it's obviously not my call, but I wouldn't want to bank on it being an add that is used by 60%+ of the audience benefiting from the dedicated serial chip approach over the bit bang serial or parallel port approach or microcontroller based approaches without having a strong market read to support that.

 

[rje]

...which gets us to Demographics.  8BG makes noises that rhyme with "ecosystem" and of course we're all adults and understand the multiple variables influencing adoption.  We could write a BASIC program that simulates it, out of whimsy.

At the surface, dropping an $8 part smacks of a Tramiel strategy.  But the argument is more subtle than that, because this is not a mass-market consumer device like the C64.

In short, it won't affect the primary adopters, who will tend to understand technology.  And we are capable, patient, thoughtful, argumentative, adult problem solvers. 

* * *

My prediction is that there will be more noise, and also more than one solution, worked on over the course of a decade or more, two of which will be viable but never get full adoption by the user base.  That's how these things work in this ecosystem.

* * *

I'd love to be proven wrong, but I suspect the easiest solution will win, or, if the cheapest solution gets close enough, then it could capture the flag.  For example, an IEC solution could be easy, could be cheap, or could be neither.

(Note: I've mentioned before how swapping in/out the VERA SD card is not something to be done casually on a regular basis.  In other words, in the long run, it's not cheap if you wear out the VERA card slot.)

 

[Wavicle]

4 hours ago, rje said:

 



(Note: I've mentioned before how swapping in/out the VERA SD card is not something to be done casually on a regular basis.  In other words, in the long run, it's not cheap if you wear out the VERA card slot.)



 

Ouch - I hadn't looked closely before but from stills on the most recent video, it looks like the SD card socket on VERA is an SMT standard sized SD socket. Replacing a damaged one is going to require a hot air rework station and have significant risk of lifting one or more pads. Anyone with a need to swap SD cards should consider also getting an SD extension cable. They're ugly as sin, but only a few dollars to replace.

[rje]

+1 for the SD extension cable.  That's a good idea.

And if a wifi SD card works, then the problem is also avoided.

[BruceMcF]

On 3/16/2021 at 11:19 PM, rje said:

I'd love to be proven wrong, but I suspect the easiest solution will win, or, if the cheapest solution gets close enough, then it could capture the flag.  For example, an IEC solution could be easy, could be cheap, or could be neither.

Seems to me like an EPP parallel port would be cheap enough and fast enough. All it really requires is sifting through the marketplace noise to have a parallel port to USB adapter that supports a register level parallel port driver. They exist, and they are cheap, but they exist alongside parallel port to USB port adapters that do NOT have register level parallel port drivers. That supports access to PCs for transport, access to PCs as emulated back up mass storage, access to microcontrollers that can host USB, and of course then that gives flash USB drives and WiFi.

Also seems like the cheapest expansion card that supports WiFi out of the box is going to get going. For a wireless connection, that can slide in under an EPP parallel port because while a parallel to USB adapter is a legacy adapter with massive economies of scale, it's still two parts to get the adapter and then the RPi 0-W or Banana Pi 0 or whatever to handle the wireless communication, so an integrated solution built onto a batch produced card has an opportunity to come in a notch cheaper.

Also, the cheaper solution that supports USB flash drive file movement seems likely to get going. With the $4 Pi Pico supporting USB hosting, it seems to be that a User Port Pi Pico hat could support IEC for plug and play start up of a Midnight Commander style utility that can move files between the SD card and a USB Flash drive.

The first approach gets cheaper if a dedicated RS-232C 115kpbs serial port is available, since you get a USB to serial adapter and don't have to have the connector to the User Port ... but that's not a reduction in full system cost, it's just cost shifting, in that the serial port chip and the serial connector is already included in the system price. An RS-232C hat for a Pi Pico versus a User Port hat ... in the second situation, the Pi Pico is nestled inside the case and only IEC and USB cables come out, so it can be a bare board, in the first case you'd want to have an enclosure in that ... the two hats would be roughly equivalent in cost otherwise, so the dedicate serial chip isn't even pulling the add-on cost down.

So its a "nice to have" -- and I certainly would be happy if it was there -- but I can see why it ended up getting knocked out not once, but twice (the 6551, and then the Vera based FIFO serial input buffer). When you add on top the people for whom the bit banged serial is "fast enough" and it would just be "nice" if it was faster, It seems likely to me that a substantial proportion of CX16 users wouldn't use the dedicated fast serial port if it was available, AND over 50% of uses of the dedicate fast serial port IF it WAS included can make do without it.

A lot of that comes down to VIA based User Port that has all of the A port and more of the B port than was available in the C64 CIA based User Port. So it was moving the banking registers off of the VIA's that opened up those User Port uses.

[rje]

Here’s the use case I keep thinking about: by sheer luck I actually finish my Traveller Trader game, and want to distribute it free to others.  Or someone writes a very nice Ultima-IV-styled game.  Or David Murray writes Planet X16.  Etc.

There’s at least 512k of banked RAM on this beast.  My game has a 270k map, and other files.  In other words it reads files into 40 banks.  The game loads all that using KERNAL calls, easy peasy, when it starts up.

 

1. I have to use a KERNAL solution.  That means IEC or the new device 1 (SD), right?  I can’t use an expansion card or the user port unless it’s got a modular boot loader that patches the KERNAL and makes it transparent to programs using it.  AND that our games are clever enough to use the “current” device, instead of defaulting to device 1 or device 8.  Or asking which device to use.  Or something.

So while I can hope for an expansion card, what we have now is an SD socket that I will want to buy an extension cable for, and the old Commodore IEC bus (which may not survive to the smaller X16 models).

 

2. Speed.  It is super fast on the emulator, surprise.  But, it won’t be as fast on the X16.  Will it be as fast as a 1581?  Or will it chug along like the 1541? I remember this is LGR’s big criticism of 80s nostalgia in one of 8BG’s videos about his Dream Computer.

How fast do you want 512 kilobytes transferred to the X16 by a game someone wrote?  Answer: probably at fast-loader speeds.  Maybe that just means we load a wedge at boot time.  Ok.

 

[BruceMcF]

On 3/19/2021 at 12:50 PM, rje said:

2. Speed.  It is super fast on the emulator, surprise.  But, it won’t be as fast on the X16.  Will it be as fast as a 1581? 

The SD card will certainly be much faster than a 1581 ... except when the slow clock mode is set, the SPI clock is 12.5MHz, which is substantially faster than the maximum bits per second that a 1MHz or 2MHz CIA can transfer data over a clocked hardware serial line, and the processing speed & sector seek speeds for the 1581 pulls maximum throughput well below the maximum throughput of the CIA serial shift register (which is in turn faster than 1571 fast serial mode, which is in turn much faster than VIC-20 IEC mode).

If you are worrying about the SD card failing to be many multiples of the speed of the 1581, you may be worrying over nothing.

As far as getting files onto the SD card without sneakernetting, an important resource constraint for different people's choices will be different quantities of patience on offer.

 

[Wavicle]

It sounds like the concern comes down to:

1. 
   The SD card is fast, but:
   
   
   
   1. 
      It is inconveniently placed.
      
   
   
   2. 
      It has limited insertions before failure.
      
   
   
   
   


2. 
   The IEC port is slow.
   

I'm still partial to architecturally defining a storage expansion card interface that KERNAL supports and letting 3rd parties build cards that conform to the spec. If it were possible to flash ROM after the unit has shipped, then this could be turned around and a 3rd party could create a solution that is compelling enough that it gets into post-release KERNAL update, but it isn't clear that field updates to the ROM will be supported. The flash IC it looks like they're using (SST39SF040) seems to have a straightforward host-controlled rewriting process, but allowing field updates also means defending against malicious and accidental bricking of the device.

[SlithyMatt]

1 hour ago, Wavicle said:

It has limited insertions before failure.

Is there any real evidence that the SD2IEC is any more durable than the SD slot on the VERA? This seems to be a lot of worrying for nothing. How many times a day is anyone likely to insert and eject the SD card? My guess is that for most folks it will be far less than once a day. Maybe a bit when getting it first set up, but after that when you get new software for it, which is going to be what, twice a week? Like others have suggested, get an SD extension and mount it wherever you like, if you are really concerned. If you wear that out, buy a new one for <$10.

[rje]

Matt (and Bruce), I *think* the SD route is reasonable and (like with the cable) wear can be avoided.

I'm thinking aloud about this, because that's what I'm trained to do at work -- (1) ask questions and (2) think about use cases and (3) suggest worst-case game-stopping scenarios, if it's possible that they can be avoided upstream.

 

How often will we swap that card out?

First, think about the process for new resources.

1. Pop it out of its slot and connect it to your computer.

2. Make a directory for the new thing (e.g. like /planetX16).

3. Copy the files into that directory.

4. BACK UP THE IMAGE (maybe not always).

5. Put the SD card back into the X16.

At what point does that become a bit tedious?  I don't actually think I'll be doing this more than once a week, or even once a month.  So maybe it's a moot point.

I just want to make sure it's a moot point.