Jump to content

lamb-duh

Members
  • Posts

    63
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by lamb-duh

  1. I'm probably not using the right word. When an interrupt comes in, the program has to write to a certain memory location (depending on what caused the interrupt) to say that the interrupt has been handled, otherwise you'll get stuck in a loop where the interrupt handler is triggered again as soon as it exits. (for vsync you would poke 1 into $9f27) this is done by the kernal interrupt routine, so if your interrupt handler is calling back into it, you don't need to do anything. If SCNKEY is just causing a crash though, that's not what the problem is. I don't think I can be of any more help, sorry
  2. the first address is where I'm reading from on the x16, the second address is what I'm checking with on the banked RAM dump. They *are not* the same, but it's very possible that I calculated the wrong offset in the file. This is RAM bank 1, which should span $2000-$4000 (in the dump file), so $3cc7 corresponds to $bcc7 (on the x16). When I look at the dump file, this range is full of the data that I loaded into it.
  3. oops, I mean banked ram, not vram. (I am copying into vram though, the 4K chunks are being loaded into banked memory, and then tiles are copied out of there into vram individually as they are needed. so data in even slots is successfully being copied/data in odd slots is not. I've worked the issue down to it won't read the data out of *banked* ram.)
  4. Okay, I have this mostly working except for one issue I just can't figure out. I'm splitting each RAM bank into 2 4K sections (skipping bank 0). These slots are numbered consecutively such that even slots are at $A000 and odd slots are at $B000. And everything's working in the even slots, but when I try to read data out of odd slots I just get zeros. I'm debugging by using `jmp *` to stop execution at particular points, then inspecting memory dumps. I have checked that the correct memory bank is selected and that I have the right address. I even tried using an absolute address (because I'm copying data with an indirect index and I'm still hesistent with that). The last thing my program executes before spinning is to copy $bcc7 into zero page. I definitely have the correct page selected, and a zero gets copied across. However, when I look at the vram dump, address $3cc7 is not a zero---the vram dump shows that the data I expect to be there is there. Any ideas what might be going wrong? e; I mean banked ram, not vram
  5. Sorry, I didn't actually get that far, after I found out about SCNKEY I got distracted by something else and never got a chance to test it out. One thing that comes to mind though-- when you pass off control to the kernal, you must *not* clear the interrupt lines yourself. That was a bit confusing for me at first, but if you clear the interrupt line before going into the kernal, the kernal will miss the signal. As for SCNKEY, this is the commodore reference I've been using: http://sta.c64.org/cbm64krnfunc.html As far as I can tell, all you have to do is `jsr SCNKEY` ($ff9f) every once in a while to poll the keyboard, and then GETIN will work again. edit: As far as I can tell, the computer has PS/2 port on it for keyboard input, but it's connected through a controller that makes it (presumably) more like a commodore keyboard. I'm pretty sure PS/2 generates an interrupt when keys are pressed, but that interrupt does not go into the 6502. (I could be completely off base here though)
  6. well to be fair, SD card controllers are also a little out of place in the 8 bit world. it seems a shame to have so much storage capacity attached, and not being able to make full use of it. actually, a virtual tape drive that stores data on sd would be awesome. do you use a lookup table to map 0-16 to petscii? I have files with hex names right now, but haven't written the loader for them yet. thinking about it now, it might be a good idea to use letters A-P instead, then I can map a hex digit, i -> 'A'+i This is all great information, thank you! all I need right now is to resolve a 16 bit pointer to a chunk of data (just a really big array), but I'm definitely going to come back to this when I need more structure. I'm sticking with 4KiB+2 chunks right now because it ended up being just exactly the right size for me to work with easily (I'm not thrilled with the filesystem overhead, but whatever it's going on a 32GB sd card ffs). Each record is 16 bytes, which works out to 256 pages of 256 records each, so I don't need to do any bit manipulation to split it into a page number and index. and then because I only have two slots in each ram bank, I can lsr the slot number to set the ram bank, then use the carry flag to write one of two base addresses into zeropage.
  7. (in r37, at least) the keyboard map is in $00-$40 of ram bank 0, if you pass `-dump B`, it will be right at the beginning of the dump file. you can do before/after snapshots to check if that's the issue.
  8. I have 1MiB of data I'd like accessible to a program. Obviously, this can't all be loaded into memory at one time, I'd like to be able to load it into ram in chunks of ~1KiB. Has anyone done something like this before? As far as I can tell, my options are to load an entire file into ram using LOAD, or I can read the file byte by byte using CHRIN. Doing a seek and then a bunch of CHRIN should work, but there doesn't seem to be a seek command (at least for commodore), and using CHRIN to seek is not going to be fast enough (or, at least I assume it wouldn't be). One strategy I've come up with is to split the file up into 256 chunks of 4KiB, then load files individually. But this is suboptimal for two reason--- first there's a big mess of data files, and second each file needs to contain 4KiB of data, but LOAD needs an extra 2 byte header which will effectively double the disk space needed on a filesystem with 4K blocks. (it's also using bigger blocks than I wanted to use, but that's not really a big deal). Is there something better I don't know about?
  9. How about the keyboard? GETIN seems to break when I clobber the kernal irq handler. Does the keyboard generate interrupts, or do you have to poll it? edit: I found this discussion https://www.lemon64.com/forum/viewtopic.php?t=32619 about commodore 64 keyboard handling. It says that I have to read the keyboard matrix and debounce the keys myself. does the x16 have an api call like joystick_scan, but for the keyboard that would manually trigger the keyboard processor so that I can still use GETIN? edit: turns out SCNKEY from the commodore 64 api does what I want, except that it also writes data into (what seem to be) two random memory locations, but I guess I can just save those on the stack and then I don't have to worry about whether I was using them for something else.
  10. If I clobber the kernel interrupt handler, then my interrupt handler has to handle every interrupt, right? Like if an interrupt comes in and my routine doesn't handle it, as soon as it `rti`s, the interrupt process is going to start all over again and get stuck in an infinite loop, right? Are most interrupt sources like vera, where you have to explicitly turn them on? is there a list of what interrupts my code has to respond to if it doesn't pass off control to the kernel?
  11. What's the best way to handle multiple interrupts coming in at the same time? Another guide to 6502 interrupt handling (http://6502.org/tutorials/interrupts.html ) says that the interrupt handler can be written to only deal with one interrupt at the time, and the processor architecture makes sure nothing gets lost. However, if I continue to use the kernel interrupt handler, I'm relying on the kernel to clear the interrupt flags, does the kernel handle all interrupts at the same time? if it doesn't, then I need my interrupt handler to coordinate with the kernel handler so that we both deal with the *same* interrupt. What if a new interrupt comes in at just the right time that my code misses it but the kernel processes it? If I just clobber the kernel interrupt handler, then I have to do all the hardware processing myself. I'm thinking that my vsync handler should just write something to memory that would trigger something outside of the interrupt handler to process the frame, rather than writing a huge interrupt handler that has most of the program logic. If I write short interrupt handlers, these problems probably become unlikely enough that I can wait until I have a better handle on 6502 programming to actually figure them out.
  12. I'd like to run a subroutine when vsync starts, how can I do this? The list of vera registers suggests that this exists, but I can't find any documentation on how to configure interrupt handlers. The 6502 interrupt vector is mapped into ROM, so presumably it can't be completely hijacked from the kernel.
×
×
  • Create New...

Important Information

Please review our Terms of Use