How should file and device I/O be handled?

StephenHorn · Post by **StephenHorn** » Wed Mar 16, 2022 5:34 am

It was suggested on the Unofficial Discord server that the forums would be the place to discuss and debate technical details of the open ROM. I'm not sure what better way to start than to discuss how I/O should work, at least in terms of the API being presented by the ROM.

I want to gather folks ideas.

The C64 kernal presents different devices through different sets of functions. For instance, serial bus I/O is run through the TALK, TKSA, UNTLK, LISTEN, SECOND, UNLSN, etc. File I/O, meanwhile, is implemented through SETLFS, SETNAM, OPEN, CLOSE, CHKIN, CHKOUT, CHRIN/BASIN, CHROUT/BSOUT, etc. And there is also some concept of these existing in a unified context inside the kernal, as READST is used to indicate status for both serial and file I/O. I'm not familiar enough with the kernal to know for sure, but it also appears that at least some serial communication could occur through the file I/O interface to support printers.

As far as the FAQ is concerned, the X16 supports the following I/O:

SD Card (via the VERA's SPI interface, which is connected to the SD port)

Two SNES-style controller ports (but we know the ports will not wire the "Data2" or "Programmable I/O" lines)

PS/2 Keyboard

PS/2 Mouse

IEC-compatible (Commodore) disk drive port

13 general-purpose I/O lines (user port)

Four expansion slots

The first four are emulated in x16emu and Box16, I'm not sure if there's any emulator support for of the IEC disk drive port, and I know there is no emulation support for any user port or expansion slots.

As for my own initial thoughts, I'm circling around the idea that we don't need to worry about serial communication support in an open kernal. And lacking emulator support for certain features, I'm not sure to what extent folks would be motivated to support Commodore drive support in the kernal, either. And I don't think we can really approach GPIO or expansion slots, for want of technical details about how those even work.

Does that mean we want to provide an API that is, instead, focused on providing a FAT32-based file I/O interface? And then have special-case function calls for getting and setting state information about the keyboard, mouse, and gamepads?

TomXP411 · Post by **TomXP411** » Wed Mar 16, 2022 9:54 am

On 3/15/2022 at 10:34 PM, StephenHorn said:

Does that mean we want to provide an API that is, instead, focused on providing a FAT32-based file I/O interface? And then have special-case function calls for getting and setting state information about the keyboard, mouse, and gamepads?

Well, today's revelations may change things considerably:

Storage is likely to move over to an SD2IEC, or maybe to Scott's conceptual Pi2IEC design.
- So for the IEC devices, it's basically about re-creating the needed KERNAL APIs.
- Non-IEC devices use specific APIs

The keyboard and mouse will end up living on an I2C bus.
- This means we can't really talk about keyboard and mouse code, yet.
- All input devices support "make/break" events and "current state" request:
  - presses/clicks/moves since last check"
  - query specific key/button code and get back "up" or "down"

The screen APIs can be very close to the metal:
- Direct Write API
  - direct cursor control
  - ignores cursor commands (allows printable characters in 0-31 and 128-159)
  - screen codes = character codes.
- Terminal API that handles terminal codes
  - ASCII character order (ie: "A" is always 65 and "a" is always 97.)
  - ANSI terminal code support
  - PETSCII is just another "international" character set, accessed with a specific terminal sequence

SlithyMatt · Post by **SlithyMatt** » Wed Mar 16, 2022 2:11 pm

On 3/16/2022 at 5:54 AM, TomXP411 said:

Well, today's revelations may change things considerably:

Storage is likely to move over to an SD2IEC, or maybe to Scott's conceptual Pi2IEC design.

So for the IEC devices, it's basically about re-creating the needed KERNAL APIs.

Non-IEC devices use specific APIs

Well, the SD card is still part of the VERA design, and it may just be a software (i.e. ROM) issue holding it back. Having IEC is nice as a backup, but getting SD-based FAT32 working would be a huge win. And maybe there is a firmware issue, too, and now we can look into the HDL for ourselves as well -- and there's no IP concerns with that code since Frank slapped on the MIT license. So it's not a lost cause, just something beyond the capabilities of the remaining active dev team. If this effort reveals a fix to the firmware, that can be pulled into the main repo or a new fork managed by a new VERA leader. And a fix could also be pulled into the main ROM, if a third party were to spot a key difference between the clean-room developed ROM and the one with the legacy IP.

StephenHorn · Post by **StephenHorn** » Wed Mar 16, 2022 4:02 pm

Haha, yeah, that's quite the tectonic shift in the project. SD2IEC makes a lot of sense for Dave and Kevin, because they can reuse the working implementation from the C64 ROM instead of writing something from scratch.

While Verilog and HDL are not entirely alien to me, I haven't been brave enough to jump into the VERA code myself so far. So I couldn't tell you how smart (or dumb) the VERA's SPI interface is, and thus where the error is likely to exist vis-a-vis the SD card. But from working on the emulation, it was my observation that the SPI interface was >95% kernal logic, so unless or until I can get my greedy paws on hardware, it'd be my guess that the issue lives there.

So here's a fun question to open up: If the community were to make their own ROM, would we want to follow Dave's lead and continue to use the IEC interface instead of the SD card? Presumably, the SD card interface will remain part of the design no matter what at this point, the only question is whether the current problems are coming from the kernal, the VERA itself, or both.

Scott Robison · Post by **Scott Robison** » Wed Mar 16, 2022 5:10 pm

In talking to David about other projects, this came up. The idea would be to remove the unused SD card slot, but the path forward as outlined yesterday isn't yet 24 hours old. I think flexibility is still the name of the game.

StephenHorn · Post by **StephenHorn** » Wed Mar 16, 2022 5:40 pm

Ahaha, well, if the SD card gets removed from the VERA, I wonder what would be freed up by removing the SPI interface from the VERA and whether that could add some other video-related functionality... XD

Wavicle · Post by **Wavicle** » Wed Mar 16, 2022 6:11 pm

On 3/16/2022 at 10:40 AM, StephenHorn said:

Ahaha, well, if the SD card gets removed from the VERA, I wonder what would be freed up by removing the SPI interface from the VERA and whether that could add some other video-related functionality... XD

Not much, unfortunately.

The SPI controller uses just 28 LUTs and 26 registers. Removing SPI increases the number of available logical elements by about 1%. There's quite a bit of room available in the FPGA to increase VERA's capabilities as long as you do not need block RAM, SRAM, or a hardware multiplier.

BruceMcF · Post by **BruceMcF** » Sun Mar 27, 2022 6:05 pm

On 3/16/2022 at 2:11 PM, Wavicle said:

... The SPI controller uses just 28 LUTs and 26 registers. ...

I'm guessing that this is a big part of why SPI was so popular in its heyday and still has a niche today ... while it is not as economical in pins as I2C, it is very economical with logic resources.

This could also be part of why they decided that dropping the SPI port wasn't an option that needed pursuing ... it doesn't free up many other options.

Heck, if they were to end up not being able to make the SD card work, they might just use the SPI port to access the micro-controller for the power supply and PS/2, since it would be substantially fewer pins on the micro-controller supporting CX16 access than putting the micro-controller on the bus directly in the /IO page.

Daedalus · Post by **Daedalus** » Sun Jul 23, 2023 1:45 am

I'm a little confused about something, doubtlessly because I came into the party in October of 2022, when the first big announcement was made. Now, I've been aware that David's been wanting to make his "dream computer" since he first announced in on his channel, but I wasn't all that interested because, frankly, I'm just not interested in the C64 or it's variants.

What made me sit up and say "Ok, this changes everything." is the VERA module.

So, my question is... wasn't the SD card in it the whole time? I had just assumed that it was, and has been working since 2020. But this makes it sound like it was the emulator that's been doing the heavy lifting until some time in the recent past when the SD card was able to work.

TomXP411 · Post by **TomXP411** » Sun Jul 23, 2023 11:33 pm

Daedalus wrote: ↑Sun Jul 23, 2023 1:45 am I'm a little confused about something, doubtlessly because I came into the party in October of 2022, when the first big announcement was made. Now, I've been aware that David's been wanting to make his "dream computer" since he first announced in on his channel, but I wasn't all that interested because, frankly, I'm just not interested in the C64 or it's variants.

What made me sit up and say "Ok, this changes everything." is the VERA module.

So, my question is... wasn't the SD card in it the whole time? I had just assumed that it was, and has been working since 2020. But this makes it sound like it was the emulator that's been doing the heavy lifting until some time in the recent past when the SD card was able to work.

That's actually a bit off-topic for this topic, but the short answer is that the SD card has been working for a long time, but only about 3 people actually had the computer up until recently.

There is an emulator, and it actually has SD card emulation, in addition to file system emulation, but that's a much deeper conversation, and doesn't belong in the Monarch Open ROM discussion, since that's more general discussion, rather than talking about an alternate, open-source OS for the system.

(Actually, there were two different suggestions for Open ROMs: Monarch is a CP/M or DOS like operating system, and Open ROM is a direct replacement for the X16 ROM, but fully open source. Neither are really in development right now, as both were conceived during times when the system software was not under active development.

Commander X16