Jump to content

lamb-duh

Members
  • Posts

    63
  • Joined

  • Last visited

  • Days Won

    3

lamb-duh last won the day on January 17

lamb-duh had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

lamb-duh's Achievements

Newbie

Newbie (1/14)

35

Reputation

1

Community Answers

  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

    47 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.
×
×
  • Create New...

Important Information

Please review our Terms of Use