Jump to content

msx

Members
  • Posts

    10
  • Joined

  • Last visited

Posts posted by msx

  1. One of the selling point for me was to have a single architecture frozen in time and available forever. The cx8 would basically be a different incompatibile system thus creating a second one, with a different software library etc. It would diluite the software effort. So i'm for NO. It would be a nice platform on its own but not as a second one. 

    For the rest, i understand the problems and i'm in for the cheapest option, probably phase 3 (i wouldn't have space for a full case too). 

    Keep strong 🙂

  2. On 7/10/2021 at 10:15 PM, lamb-duh said:

    I think tcp is overkill for most applications. I might be wrong, but I suspect most of what people will want to do is talk directly between two x16s, or between an x16 and a server that expects to be talking to an x16 (not to, for example, an imap mail server or an http server). What if instead of tcp, we had some kind of virtual phone exchange? (which would itself run on top of either tcp or udp)

    I haven't thought through all the details, but here's a sketch of how it might work: 

     

    IDK, this seems way overengineered. You're inventing a new network over the internet and with a SPOF. And i don't think TCP is overkill, it's just the simplest of stream connection. It's the safest bet to connect to anything. The server doesn't have to be made for x16, you could connect to any telnet, mud, or bbs already available.

     

    Now i think we can all agree that x16 will NOT be handling IP and TCP itself, the hardware device will. It will present a simple end to end connection to the x16 that can send and read data as with any serial connection. Obviously configuring the router is outside the scope of this thread 🙂 as @Scott Robison said we should all be able to do it, or ask for help, anyway it's not business of the x16 or the expansion network device.

    So it looks like we have 3 possible implementation:

    • An expansion card, in this case the device can interact with the bus and so a memory mapped solution could be feasible, as @Zerobyte mentioned.
    • User port device. As i understand, this is an end to end connection, so at the most basic setup, this will enable only one connection to be open at a time (which could be enought actually). So in some way the x16 have to tell the device where to connect to. AT commands are a possible solution.
    • IEC device. This offer a more standardized way to access the connection as it could be mapped to already existing x16 API. Data transfer speed will be pretty slow

    This is about outgoing connections. For incoming one, some server socket logic needs to be implemented. If there's support for more than one socket, it should be doable. The server logic will reside on the hardware device and the x16 can query wether there are new connections waiting.

  3. Hello there, as discussed in this post, i'd like to address the issue of how to connect the x16 to the internet. It is something probably everyone wants to do so maybe we could prepare some ground (i'm already looking forward to BBS, simple multiplayer games, etc :)).

    So, i think the general idea is to have some external device which will handle the network stack, and relays data to the X16 via uart, spi or any other channel. It would be great if said hardware could be made inexpensively with off the shelf parts and minimum extra, like an ESP32 or some other network-enabled arduino.

    Now, one thing that i consider very important is to have a common, abstract interface to do simple network access, so that every hardware developer can build their api against it and offer programmers an uniform, vendor indifferent way to access the internet. Let's not relive the errors of the past era where every program must include code to deal with all possible hardwares 🙂 Remember when you had to choose which soudn card you had and the game developer had to code for all of them?

    So, if anyone has some ideas, we could perhaps come to a consensus.

    My first idea is to have a specific device that handle tcp sockets, i'll paste my previous post:

    Quote

    So i was wondering if it would be possible to create a "tcp socket" device, where the filename is an IP address. It would need to be managed by the microcontroller, but it shouldn't be hard at all. It would work like this:

    OPEN 1, 20, 0, "142.250.184.100:80"

    OPEN 2, 20, 0, "api.server.com:555"

    The microcontroller will open the socket connection and associate it with the file number. Subsequent read or write will be routed to the socket, and errors can be mapped to the usual FILE_NOT_FOUND, DEVICE NOT PRESENT etc.

    The only problem is that filenames are 16 character long AFAIK, so they can hold any ip address (15 chars top) but not the port. Using the secondary address as port is a problem becouse i think it's at most 128. Now an address+port is 6 bytes so it CAN be fitted in 16 char, for example using hex (C345A100:00C1), but it's pretty unelegant. It would require a conversion routine which is annoying. Perhaps someone has some suggestion (if the whole proposal makes any sense :P). 

    There's a problem with the size of filenames that's a bit unfortunate.

    Another idea could be to reserve some space for a jump table that is to be populated by a "driver" the user can load before the program, if it makes any sense? The API can be as simple as an open/read/write/close set.

    I think TCP sockets will cover most of our needs, but beside it, UDP might also be interesting and could be similarly developed. Higher level protocols, i'm not sure. Perhaps an HTTP interafce could be implemented but i think it will be pushing things too far. (A simple HTTP protocol can be directly written on the x16 side, in case.)

    A flag could be reserved to create a SSL connection instead of a regular one (obviously the cryptography will be on the microcontroller).

  4. Hi there! I'm very interested in connecting the X16 to internet, expecially 1) using cheap off the shelf parts (esp32 or similar) and 2) with the most ease in code.

    Also, i think it sould be important to have some sort of "unified interface" so that programs can take advantage of whatever kind of device is available without knowing the details. If a channel works as a modem, then it could have its own custom AT commands and behaviours, probably breaking the abstraction one way or another.

    So i was wondering if it would be possible to create a "tcp socket" device, where the filename is an IP address. It would need to be managed by the microcontroller, but it shouldn't be hard at all. It would work like this:

    OPEN 1, 20, 0, "142.250.184.100:80"

    OPEN 2, 20, 0, "api.server.com:555"

    The microcontroller will open the socket connection and associate it with the file number. Subsequent read or write will be routed to the socket, and errors can be mapped to the usual FILE_NOT_FOUND, DEVICE NOT PRESENT etc.

    The only problem is that filenames are 16 character long AFAIK, so they can hold any ip address (15 chars top) but not the port. Using the secondary address as port is a problem becouse i think it's at most 128. Now an address+port is 6 bytes so it CAN be fitted in 16 char, for example using hex (C345A100:00C1), but it's pretty unelegant. It would require a conversion routine which is annoying. Perhaps someone has some suggestion (if the whole proposal makes any sense :P). 

    What i'm afraid most is that different hardwares will require different setups, forcin programs to have vendor-specific code to deal with all the possible modems. That's one aspect of the 8 bit era that i'm NOT eager to revive 🙂

     

    (I hope it's not OT but this was the most fitting post i could find)

  5. 30 minutes ago, SplitSpine said:

    I'm using Millfork together with VScode (it even has a add-on for Millfork & X16emu).

    Still a good idea to know a little bit about 6502 assembler since some commands in Millfork (like vera_poke), is a little bit slow if you only want to poke 1 thing into the Vera (it pokes 3 values every time).

    Happy coding 🙂

    I have to look into that add-on. Been using notepads for coding Millfork until now 🙂

    You're right about the vera_poke(), but you don't need assembler to access single fields of the vera control, there are some globallly defined alias for that in the sources. Indeed the vera_poke() is just this:

    inline void vera_poke(int24 address, byte value) {
     vera_ctrl = 0
     vera_addr = address
     vera_data0 = value
    }

    Obviously it's still good to know some 6502 assembler 🙂

  6. Hi there, i'm msx (or msx80) from Italy :) I'm interested in retrogaming in general, i've made a bunch of games for Tic80, like Secret Agents or Turns of War. I'm also writing my own fantasy console to write game in Java. I've also built my arcade machine :) 

    Beside retrogaming, i've made a couple of Lego related software (Lego is one of my other hobbies): Blueprint, a building instruction generator for LDD and Bluerender, a rendering engine to render LDD models.

    I'm interested in developing something for some real retro hardware, i'm looking at CommanderX16 for the quality of the project and the huge community. I'm currently waiting for it to settle down and finalize, i don't have much time and i decided to avoid following the changing specs for now. But i've looked around, i think i'll start developing in Millfork: it looks like a perfect middle ground between assembly and higher level languages and i like what i learned about it so far. The first game i'll do will be something technically simple like Secret Agents, probably.

    I'm also interested in electronics and surely interested in connecting the CX16 to the internet somehow :)

    • Like 2
×
×
  • Create New...

Important Information

Please review our Terms of Use