Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by lamb-duh

  1. Version 1.0.0


    Play a game of pool on your commander X16. Click inside the light green circle to hit the white ball around the table.
  2. Pool Table Simulator View File Play a game of pool on your commander X16. Click inside the light green circle to hit the white ball around the table. Submitter lamb-duh Submitted 12/23/20 Category Demos  
  3. That's unfortunate that you can't use the kernal mouse routines without losing a sprite to a pointer. I looked at the source, which confirms that the same variable is used to control the pointer sprite and bail out of reading mouse data at all. I guess the solution would be to access the ps/2 interface directly if you really didn't want it.
  4. The documentation gives this explanation for the three modes: However, from testing it seems that mode 0 does not "hide" the mouse, it completely disables it. Using both modes 1 and -1, I can get meaningful mouse coordinates, but something is still trying to draw a pointer (I'm not entirely sure what it's doing, but it looks like it's trying to hijack a sprite). I want to use a mouse, but I want to be in control of drawing my own pointer, how can I get that? And what does "don't configure mouse cursor mean"-- does that mean it's still going to *show* the cursor, but it's up to me to configure a sprite or something for it? eta: I guess I've figured out that I was right about the difference between the two modes---mode 1 puts a cursor icon into the sprite and -1 doesn't, however both modes update the x,y position of sprite 0 every time the mouse is moved. If I set mode 0 though, then mouse_get doesn't work. so I'm still left wondering if there's any way to use the mouse without the coordinates being written into sprite data? also, where in vram is the cursor icon loaded?
  5. I don't know how common this is, but I've been doing pretty much all my arithmetic on a stack in zeropage using zp,x addressing. I've written a bunch of macros to do 16 bit arithmetic, mostly only operating on the top of the stack. here's a sample of that: (written for 64tass) As long as you're careful, you can freely mix 8 and 16 bit values on the stack. Unlike using some fixed registers, you never have to worry about whether calling a subroutine will clobber registers. On the other hand though, you have to save and restore the x register anytime you need to use it for something other than a stack pointer. If you're comfortable with RPN and want to do all your arithmetic on a stack, it's a really good solution. It also works really well for passing parameters into and out of subroutines.
  6. that's more code than I want to deal with for this, but the idea given by Johan Kårlin in that thread to change a background colour would work perfectly to give a visual idea of how long different sections of your code are taking I was hoping to find something in the debugger without having to make any changes. But the emulator's cycle counter could do what I want. It doesn't need to work an actual hardware, I just want to time how long different sections of code take to execute
  7. Is it possible to get the current line in the emulator (rather than in code)? I want to see how much of a frame my code that should be run every frame is using (or is there a better way to measure that than counting scanlines?)
  8. I think this is definitely doable, but you're going to have to make a lot of compromises between things like resolution, framerate, how much stuff is on the track. It's hard to say whether there's a balance of all these things that will make the game you want. That said, I think in terms of computation time there's two things that are going to be taking up most of your time: (1) coordinate projection. you need to do lots of multiply-accumulates, probably with more than one byte of accuracy. It wouldn't surprise me if there are good well-optimized libraries for the 6502 that could easily be adapted, though. (2) the way that vera's memory is accessed is not great for drawing vector graphics. I think this is going to be the most difficult challenge in porting wireframe techniques from other 6502 platforms. even drawing a line requires seeking in vram for every scanline. you might have to render the scene into system memory, then copy it into a backbuffer in vram. or maybe there's something more clever you can do.
  9. I didn't realize gbc games got that big! the toy story racer rom is only 2mb, even the pokemon games are only 1-2mb. The biggest gbc rom I have is donkey kong country (at 4mb, which used a lot of prerendered assets). Do you know which games used 8mb carts?
  10. Have you thought about putting the aliens in a background layer? The aliens all move in lockstep, so there's no need for them to all be separated (unless you're already using both background layers for something)
  11. DMA is available to hardware connected to the expansion slots, right? Does hardware have direct access to video ram, and if so could that be done without interrupting the cpu?
  12. Are you referring to the fact that 6502 instructions tend to run in fewer clock cycles than equivalent instructions on a z80, or something else entirely?
  13. You should take a look at Toy Story Racer for Gameboy Color. this video has a bit of gameplay footage and a brief explanation of the effect What you see on screen is a prerendered video of a 3d track, and a bunch of sprites put on top. Basically, making a green screen. The Gameboy Color has similar processing and graphical capabilities to the x16, however, the x16 has much more ram attached to both.
  14. You're right, the hardware is not open and a big part of the core software is not open. There's decades of case law that lays out exactly how to legally clone a closed platform. If someone wants to make a clone of the machine and sell it, they will. Saying "no clones" isn't going to solve the issue. Emulation is legal, by the way.
  15. That's not true, All new code, and additions to legacy code: ©2020 Michael Steil, www.pagetable.com; 2-clause BSD license FAT32 and SD card drivers: ©2018 Frank van den Hoef; 2-clause BSD license kernal/open-roms: ©2019 Paul Gardner-Stephen, 2019; GPLv3 license Emulator, Copyright (c) 2019 Michael Steil <mist64@mac.com>, www.pagetable.com. All rights reserved. License: 2-clause BSD Commander X16 Documentation (CC BY-SA)
  16. Yeah, I broke the big file up into chunks that are loaded in full. It runs well in the emulator, but I have no idea how it's going to be when it has to also locate those files in a fat filesystem. I'm not terribly satisfied with the solution, but it's working now. it seems that OPEN/GETIN doesn't work yet in the emulator, you have to use LOAD. The emulator comes with symbol definitions for CBDOS. I'm not sure where to go for documentation, but it seems to have more robust filesystem routines, including `fseek`. I'm not sure if it's a useable state though, since I haven't come across any documentation for it. edit: I don't think fat has any limits on how many files can be in a directory except for its file size limitation (which are way bigger than any directory listing). However, directory listings are just an array of filenames and pointers so actually locating a file in a large directory becomes a problem. Using short filenames should mitigate this, somewhat.
  17. I came across this in the emulator repository, which looks like custom emulation for load and save functionality. I'm thinking maybe OPEN just doesn't work on emulator's local filesystem?
  18. What I'm trying to do: My biggest confusion is over the "command" or "secondary address" (y register when you call setlfs). I have a comment from code that's been copy-pasted dozens of times now telling me that putting a 0 there will make LOAD ignore the address header in the loaded file. This commodore manual puts 255 in there but doesn't offer any explanation. When that code is run and the debugger opens, the carry flag is set, which I've been told means that the routine failed (there is more code that calls chkin and getin, but getin just returns zeroes). Changing the secondary address to a variety of random numbers results in the same behaviour, but changing it to 255 causes the kernal to get stuck in a loop--the debugger never opens. This code works if I do a LOAD instead of OPEN. Is there something else that I need to change if I want to use OPEN/GETIN instead of LOAD?
  19. if you haven't seen it yet, this thread may interest you: https://www.commanderx16.com/forum/index.php?/topic/312-ps2-usb-discussion-split-from-whats-the-state-of-play-with-serial-port-support/ It seems that the interrupts generated from the ps/2 ports go into the NMI line on the processor, not IRQ. As far as I'm aware, there's no way to override NMI handler like there is for IRQ. This seems like something that you should be able to do. At the very least for the time being, you could modify your kernal rom so that the NMI vector points into ram. There probably isn't any good documentation right now on how to manually interact with the ps/2 hardware, but you can refer to the kernal source on github.
  20. It would be great if someone with intimate knowledge of vera can answer what the "correct" behaviour is, but in the meantime the emulator purportedly has nearly cycle accurate emulation of the graphics hardware so you should be able to assume that what you see in the emulator is what you'll get on real hardware
  21. Do those work with any usb keyboard or mouse? I thought they were just a convertor between two connector types and relied on the mice/keyboard supporting both ps/2 and usb.
  22. that's it! it's working, thank you very much!
  23. sorry, I shouldn't be so dismissive of that. You're right and definitely just saved me a lot of debugging over an issue that I wouldn't have realized was there until this one was solved. This issue is all happening within the same ram bank. I've reproduced this in a much smaller program. You can assemble it with 64tass, or there's a binary in there too. when the program gets to the end, the accumulator should have a non-zero value read from the file that was just loaded into memory, instead it is zero. However if I `m 01b010` into the debugger, it shows me the data I expect to be there (although I won't discount the possibility that I'm reading the debugger all wrong). If you change the address to $a000 instead of $b000, the accumulator has the expected value. load.zip
  24. The debugger is showing me that the data is correctly loaded into bank 1, which was selected using the same zero page variables edit: I am running r37 though
  25. Hm, the debugger is showing that the data is where I think it is, but I still can't get at it from my program. Here's the last thing that's run (and I verified in the debugger that it stopped here): lda #1 sta 0 lda $bcc7 sta r0 stz r0+1 sei stx $ff jmp * So, set ram bank to #1, then copy $bcc7 to $02. If I look at the zero page in the debugger, $02=0, but if I `m 01bcc7`, I can see the data that I expected to be there. By the way, is it possible to interact with the debugger from the command line? the interface has some accessibility issues.
  • Create New...

Important Information

Please review our Terms of Use