Jump to content

lamb-duh

Members
  • Content Count

    61
  • Joined

  • Last visited

  • Days Won

    3

lamb-duh last won the day on January 17

lamb-duh had the most liked content!

Community Reputation

35 Excellent

Recent Profile Visitors

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

  1. oh, I like that answer even more!
  2. 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?
  3. 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?
  4. 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
  5. 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.
  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 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  
  7. Version 0.1

    20 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.
  8. Doesn't vera have 320x240 modes?
  9. 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).
  10. 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.
  11. I can take a look at your script and/or image files, if you want
  12. 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)
  13. 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.
  14. 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)
  15. 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..
×
×
  • Create New...

Important Information

Please review our Terms of Use