Jump to content

lamb-duh

Members
  • Posts

    63
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by lamb-duh

  1. 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. oh, I like that answer even more!
  4. 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?
  5. 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?
  6. 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
  7. It's very straight forward, but I'm going to do a quick write up on it today or tomorrow. The relevant 6502 code is in src/emu_serial.s and the host-side code is in emulator_glue.c, if you want to see what it's doing in the meantime.
  8. 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 pseudo-terminal. In the emulator LOAD "UX16VT.PRG" & RUN. On the host, compile and run emulator_glue.c. ## 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) Limitations: - 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. Submitter lamb-duh Submitted 01/15/21 Category Productivity Apps  
  9. Version 0.1

    55 downloads

    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 pseudo-terminal. In the emulator LOAD "UX16VT.PRG" & RUN. On the host, compile and run emulator_glue.c. ## 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) Limitations: - 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.
  10. Doesn't vera have 320x240 modes?
  11. there's an ongoing discussion about that, serial ports would be accessed using chrin and chrout (and the kernel routines that go along with them).
  12. 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.
  13. I can take a look at your script and/or image files, if you want
  14. 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)
  15. 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.
  16. 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. 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)
  17. 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..
  18. Did not realize it was that big! Maybe it wouldn't be such a useful starting place
  19. now I'm wondering.. has anyone tried to make cc65 self-hosting? I wonder what's holding it back
  20. 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.
  21. 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]
  22. oh, I was sure I had looked there! I've mostly been using this commodore reference which calls it CHRIN. Thank you!
  23. Could you post the symbol definitions you're using? (or point to where i could find the right ones). Some of the functions, like BASIN I can't find any information on.
  24. 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`
  25. 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.
×
×
  • Create New...

Important Information

Please review our Terms of Use