Jump to content

lamb-duh

Members
  • Content Count

    54
  • Joined

  • Last visited

  • Days Won

    2

lamb-duh last won the day on December 25 2020

lamb-duh had the most liked content!

Community Reputation

21 Excellent

Recent Profile Visitors

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

  1. Doesn't vera have 320x240 modes?
  2. 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).
  3. 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.
  4. I can take a look at your script and/or image files, if you want
  5. 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)
  6. 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.
  7. 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)
  8. 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..
  9. Did not realize it was that big! Maybe it wouldn't be such a useful starting place
  10. now I'm wondering.. has anyone tried to make cc65 self-hosting? I wonder what's holding it back
  11. 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.
  12. 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]
  13. oh, I was sure I had looked there! I've mostly been using this commodore reference which calls it CHRIN. Thank you!
  14. 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.
  15. 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`
×
×
  • Create New...

Important Information

Please review our Terms of Use