Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by lamb-duh

  1. 10 hours ago, Scott Robison said:

    My biggest concern with a virtual exchange type of setup is the fact that it is one more piece that has to be working for two machines to communicate. If it should disappear at any point, no one can connect to anything. Which is fine if you want to use it for some sort of MMO (where the first M could be massively or moderately) but some of us like the good old BBS style direct connection (over telnet in this case). And it could work for people who wanted to scratch an itch to do IMAP or POP3 or SMTP or HTTP or ... whatever their imagination demands!

    This is always going to be a problem with tcp though, unnless you're directly connecting one x16 to another over tcp, which will have its problems since most of them will be behind at least one nat router. The exchange would be running very simple software (which would probably be either public domain or MIT if i wrote it), which could be run by anyone themselves anywhere. tcp is just really bad for making direct connections between two clients because of changing addresses and various nat routers that try to stop incoming connections. It does has a centralized server, but you really need a centralized server to do peer to peer tcp.

    I don't think there's anything wrong with writing IMAP, POP, SMTP or HTTP clients/servers for the commander x16 if people want to communicate with the internet. I just think that most of what people will want to do is use the internet to communicate directly with another x16.

  2. 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: 

    - the x16 is connected to a "modem" over whatever kind of serial is available

    - at poweron, the modem connects to the virtual telephone exchange over tcp or udp (or over whatever kind of network the modem wants to). the modem contains some kind of secret data that authenticates it with the exchange server as having a certain identity (a "telephone number"--but it could just as easily be a username)

    - the x16 will send a command, asking the modem to "dial a number". the modem relays this to the exchange server, which will cause the modem belonging to that phone number to "ring" if it's connected. software on that end can accept or reject the call.

    - if the call is accepted, then the server will proxy packets between the two clients

    this set up requires a centralized exchange server to act as a proxy, but it would allow anyone to write machine-to-machine multiplayer pretty easily. the proxy server can be protected from abuse by limiting throughput to a few kilobytes per second, and a single active connection per person.

  3. 2 hours ago, Lorin Millsap said:

    The RAM in the Vera is integral to the VERA. We did look at external RAM but it would require a complete overhaul due to timing. And it substantially increases the cost. The next FPGA that has more RAM puts us into a package we don’t want.

    is there any possibility of getting the full 128k for general purpose video ram, or do the registers at the end of the address space eat up that same ram?

  4. The waves available (triangle, sawtooth and square) all have lots of overtones, which make them inappropriate for additive synthesis (I think?), but there's no phase shift which makes it impossible to do subtractive synthesis (I think?). The only thing that's left is the pulse width modulation controller, but I don't understand how it could be used to control the overtones. Is there a name for this kind of synthesizer? Have I completely misunderstood it?

  5. Purpose communicate between an X16 program running on the official emulator (without modification) and another process running on the host. This allows you to begin developing software for hardware that does not yet exist without modifying or recompiling the emulator.

    Implementation A pseudo-serial interface using a pair of chrin/chrout routines that transfer data one byte at a time using LOAD and SAVE on the x16 and read/write on the host side. See unicode terminal for x16 for a practical demonstration. Attached are the 6502 assembly and C implementations used in that program. The 6502 code is likely usable as is, but beware that it saves and restores the .X register using $ff. The C code for the host is likely not usable unless you are making a terminal but it is attached as a reference. It can be modified to use pipes or a socket instead of the posix pseudo terminal interface, or you may wish to write functions that implement matching chrin/chrout functions in your preferred language---the code on the emulator side and the host side do exactly the same thing.

    File Format Data is transferred one byte at a time in a 3 byte file. The first two bytes are ignored but are necessary for LOAD & SAVE, the last byte is what is being transferred. A null byte signals that there is no data to be transferred. This means that there is no way to tell the difference between a null byte and no data. This would normally bother me, but it matches the semantics of the commodore chrin. Data transfer is unidirectional. Bidirectional transfer is done using two different files.

    Output Data is only written to the output file if the data byte is null. The implementation in serial_chrout continuously reads the file until it gets a null byte, and then overwrites the file with the next data byte. This behaviour means that the routine will block indefinitely if there is not a process reading the data.

    Input The input file is read. If the data byte is null then there is not yet any input. The serial_chrin routine will return immediately if there is no input, it will never block. After data has been read in, a null byte is written back to the input file. This is so 1. the process writing the data knows that the next byte can be written and 2. this byte is not read twice by mistake.

    emulator_glue.c emu_serial.s

  6. ux16vt (Unicode Terminal for X16)

    View File

    ux16vt is a UTF-8 and somewhat ANSI compatible terminal emulator for
    Commander X16.

    Currently the only useable "serial" port uses LOAD & SAVE to communicate between
    the X16 emulator and a glue process that moves data in and out of a POSIX

    In the emulator LOAD "UX16VT.PRG" & RUN. On the host, compile and run

    ## Unicode Support

    ux16vt supports up to 4096 1-bit 8x16 pixel glyphs selected at compile time from
    the Unicode Basic Multilingual Plane. Unknown characters are displayed as blank.

    Currently 672 of these glyphs are used covering 862 different code points. The
    following blocks are mapped:

    - Basic Latin (00-7f)
    - Latin-1 Supplement (80-ff)
    - Greek & Coptic (370-3ff)
    - Cyrillic (400-4ff)
    - Box Drawing (2500-257f)
    - Block Elements (2580-259f)


    - no support for right-to-left text
    - characters are represented internally as 16-bit values, making any characters
      outside the basic multilingual plane complete inaccessible
    - completely mono-spaced text. full-width glyphs are not available

    ## ANSI Support

    Only sequences beginning with ^[[ are supported (Control Sequence Introducer).
    Only numeric parameters are read. A control sequence with more than four
    parameters will cause an unchecked buffer overflow.

    The following functions are available:

        A   CUU Cursor Up
        B   CUD Cursor Down
        C   CUF Cursor Forward
        D   CUB Cursor Back
        E   CNL Cursor Next Line
        F   CPL Cursor Previous Line
        G   CHA Cursor Character Absolute [column]
        H   CUP Cursor Position
        J   ED  Erase in Display
        K   EL  Erase in Line
        S   SU  Scroll Up
        T   SD  Scroll Down
        d   VPA Vertical Position Absolute [row]
        f   HVP Horizontal Vertical Position
        m   SGR Select Graphics Rendition

    The only available modes for SGR are 31 to set foreground colour to red and
    30,32-39 set the foreground colour to black.



    • Like 4
    • Thanks 1
  7. 4 hours ago, StephenHorn said:

    VERA already has one fixed resolution. 😛 640x480.

    But once the X16p/c/e line is out, if they do well enough, I could see value in modding the FPGA code to remove various bits that a handheld wouldn't need, and whatnot.

    Doesn't vera have 320x240 modes?

  8. I've been following along with the thread, but I'm still a bit confused about a few different things,


    1. what does it mean that driver software will need to be relocatable-- does this mean code that does not use any absolute addressing, or is there going to be some kind of loader that supports relocation in some way?

    2. if I'm writing a driver for a serial port, I would be writing new routines for chrin, chrout, &c, right? so that means that I replace each routine with a new one that will check if this call is directed at this piece of hardware, and process it if it is, or else call the original routine (I guess you would do that based on the device id in this case?)

    3. what does non-driver software have to do to not interfere drivers? are drivers loaded in ram somewhere already marked for kernel use?

    4. given that (unless I'm completely wrong on #2) every driver that is loaded will slow down certain system calls, do we really want to autoload drivers when the system comes on? I think in most cases it would make more sense to write startup scripts for software that needs certain drivers that load the needed drivers and start the program. but on the other hand, there are some drivers you might want to always load immediately, and having the option isn't going to hurt anything.

  9. if the filesystems you want to create are really that small, you can go as small as 9MB+512 bytes. The MBR partition table takes up exactly one sector on a disk (the actual partition table is, iirc, 8 bytes long, you can fill the rest of the sector with anything you want).

    I remember reading somewhere that commander dos works with fat-32 specifically. If you create a 9MB filesystem with mkfs.vfat, you will get fat-8 by default. You might have to do `-F 32` when you create the filesystem.

    The difference you'll find between the fat and the ext2 tools is that whereas the fat tools require you to create a filesystem of a particular size and then copy files onto it, with the ext2 tools, you can create a filesystem with the files you want in one step.

    Also, mkfs.ext2 accepts a command line argument to start the filesystem at a specific offset, a feature missing from mkfs.vfat. However, the script you have probably uses genext2fs which doesn't seem to have the option. (so it may or may not have a solution that will work with the fat tools)

  10. 55 minutes ago, Cyber said:

    But speaking about IO... I thought that IO range is actually stored in RAM, and each device has access to its own RAM range inside IO range. So am I wrong?

    hardware can't directly access ram because only one address can be read from ram at a time, and the 6502 does a memory read or write nearly every cycle. so, communication with hardware needs to be done with latches that are (physically) outside the main ram.

    • Like 1
    • Thanks 1
  11. 2 hours ago, StephenHorn said:

    I believe I found the tool you were talking about: mcopy.

    So it looks like I needed to install dosfstools and mtools:

    that's the one! I remember now why I wasn't able to find it.. it has a useless name and is packaged with a completely different name.


    1 hour ago, StephenHorn said:

    For some reason, mkfs.vfat doesn't want to respect the partition table written to the file by sfdisk

    yeah, I think that's just not a feature of mkfs.vfat. I'm not sure of a particularly good way to get a partition table without creating the loopback device. (I guess you could create a standalone filesystem, then use dd to attach a premade partition table to it)

    • Like 1
  12. 17 hours ago, Michael Parson said:

    Now, it needs partitions and a filesystem, but first, it needs to be setup as a loopback device:

    If you don't create a partition table, you can skip a step manually creating the loopback device--- `mkfs.vfat` will ~~partition~~ format a regular file, and then when you mount it you can pass `-o loop` to automatically create the loopback device (which will automatically be removed when the filesystem is unmounted).

    Also, a very useful option when mounting a fat filesystem: `-o uid=your-username` so that your regular user account is the owner of the mounted filesystem, instead of root.


    There's also a tool that can copy file into/out of fat images without mounting it (viz. without root permissions) but I'm completely blanking on the name. if no one else knows what I'm talking about, I'll be back when I wake up in the middle of the night suddenly remembering..

    • Like 1
  13. On 12/30/2020 at 12:01 PM, SlithyMatt said:

    Not completely, but the ca65 code may be a good starting point. You could actually use cc65 to build a hacked down version of ca65 for the X16. It's all open source, so why not? You'll at least get all the syntax parsing stuff already implemented.

    now I'm wondering.. has anyone tried to make cc65 self-hosting? I wonder what's holding it back

    • Like 1
  14. By the way, your logic with the bit rotation is right, but the ROL and ROR operators on the 6502 aren't actually 8-bit rotate operations. The bit that is shifted off goes into the carry, and the bit that is shifted on comes from the old carry. I've found them more useful for doing multibyte bitshifts than single byte bit rotates. They are 9-bit rotates, but I find it's more useful to think of them as logical shift with carry.

    I usually do 8-bit rotate left as

    asl a

    adc #0

    but that works best when the value you want is already in the accumulator.

  15. You should look into (zp),y addressing mode. In assembly,

    lda (r0)

    sta (r1)

    will copy a byte from the address referred to in r0 and store it in the address referred to in r1. If you did lda (r0),y the index register y is added to the address in r0. ie, you would get (in pseudocode) r1[y]=r0[y]

  16. The x16-rom source tree includes a fairly large collection of keyboard layouts (presumably sourced from elsewhere? I could not find attribution) but can only build 12 into ROM. Here is what you need to do to build a ROM with different layouts.

    What you need

    - git

    - python3

    - cc65 (old versions without x16 cfg files work)

    I have done this on Linux. The build process is incredibly straight-forward, I imagine it will build anywhere those tools will run.

    Clone & Checkout

    $ git clone https://github.com/commanderx16/x16-rom.git

    $ cd x16-rom

    $ git checkout r38

    Replacing "r38" with the version of the emulator you are using (or a different version at your own discretion).

    Choose Layouts

    $ cd keymap/

    The `klc` directory contains all available keyboard layouts. Make a note of which keyboards you wish to add to the ROM. Only the first part of the file name is needed. Eg. "klc/80A Latin American.klc" is identified by "80A".

    Add these to the first line of the file `make_keytab_asm.sh` (in the variable `layouts`). Layouts that will be removed from the ROM do not need to be changed here, and this list does not need to be in any order.

    Execute that script,

    $ ./make_keytab_asm.sh

    NB some keyboard layouts that do not produce any printable characters on the x16 will produce an error and empty output files. Other layouts that do not produce any printable characters will not produce an error. Keep in mind that all keyboard layouts will produce no output for any characters not available in PETSCII or 8859.

    Edit `keymays.s`.

    This file specifies which keymaps will make it into the final rom and in what order they will be cycled through. Under the comment, "; PETSCII", modify the list of includes to match your own keyboard layout. Each line should be of the form `.include "asm/___.asm"` with the same identifier in the blank. Keyboard layouts you no longer want can be removed by removing the `.include` line. There should be at least one layout and no more than 12.

    Following this section, a similar list appears under the comment "; ISO". This list should match the petscii list except that each filename is of the form "asm/i___.asm".

    Build the ROM

    $ make

    If successful, the useable rom is in the file "build/x16/rom.bin". To use this rom in the emulator, either replace the "rom.bin" in the same directory as the emulator, or specify the ROM on the command line with `x16emu -rom custom-rom.bin`

    • Like 1
  17. 48 minutes ago, desertfish said:

    A 2d physics multi-object collision engine on an 8 bit system, that's actually pretty darn nice even though it's not entirely realistic behavior.  I always find it fun to play around with anything having physics simulation.  It's always more fun when it's less realistic !

    haha, I agree that non-realistic physics can be lots of fun, but this is more broken-physics than cartoon-physics! I'm pretty happy with how it turned out though, very surprised how much I could pack into a frame. When I started I wasn't even sure if I'd be able to get two or three balls bouncing at 60fps. By the time I got all the physics more or less working on 16 balls it still wasn't missing frames, and I managed to pack the whole thing 5 times into *most* frames. (it misses some frames when there's lots of collisions, but I haven't found it to be particularly noticeable).

    The physics engine does a lot better when you turn down the velocities and the friction, but then it's not fast enough to feel anything like pool. There's a lot that could probably be done to make the physics engine more efficient though.

    • Like 2
  • Create New...

Important Information

Please review our Terms of Use