Jump to content

Elektron72

Members
  • Content Count

    33
  • Joined

  • Last visited

Community Reputation

25 Excellent

Recent Profile Visitors

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

  1. I don't think that's likely; the most recent commits in the public repositories I found were from the end of last year. Whatever this system is is likely still relevant. Besides, I don't think it would have a separate name if it was just a prototype board for the X16.
  2. Performing a Google search using the following search phrase reveals several repositories, most of which are private. These include an emulator and documentation. However, there are two public repositories containing PCB designs and FPGA source code that appear to support your theory of a system implemented entirely in FPGA.
  3. GETIN returns a 0 if there are no more inputs in the queue. Therefore, to take only the first input, call it repeatedly until it returns 0 to empty the queue.
  4. The Commander X16 is using a 65C02S, according to the FAQ. As for the VERA, more advanced video would likely consume too much VRAM to be practical, as the VERA is limited to 128K of memory.
  5. The reason why it doesn't work with the official ROM is because the routines screen_set_char and screen_get_char in kernal/drivers/x16/screen.s are not equipped to handle more than one continuation line. Continuation lines are created when text (whether typed or printed by a program) goes off the right side of the screen, and wraps around to the left. These lines are handled differently by the kernal in order to allow line wrapping of BASIC code in 40x30 mode. As long as you make sure this does not happen, 20x15 mode should work fine.
  6. I tried making some changes to the ROM to better support 20x15 mode, and have successfully fixed the issues with the test program. The modified ROM is available at https://github.com/Elektron72/x16-rom/tree/screen-20.
  7. In the Commander X16 ROM, switching between the officially supported screen sizes is handled by the kernal function screen_set_mode, located in kernal/drivers/x16/screen.s. Prior to returning, this routine performs a JSR to a routine called scnsiz, which is located in kernal/cbm/editor.s. It sets $386 and $387 (labelled as llen and nlines, respectively), then proceeds to set $388 and $389. Specifically, $388 contains the number of lines plus one, and $389 contains the number of lines minus one. Although I am not sure exactly what they do, they are referenced multiple times in the file, so they are likely used for something important.
  8. Although this won't fix the skipped numbers, I recommend that you add these lines: The kernal uses these variables, and sets them when switching to other screen modes. Therefore, setting them will likely make 20x15 mode act a bit more normal.
  9. Thanks for the correction; I had assumed it was the other way around. While the current version of the emulator does not account for horizontal timing, it does count the vertical front porch lines at the beginning of a frame, rather than at the end. I might open a pull request to fix this.
  10. I decided to calculate how many cycles programmers will have depending on where the IRQ triggers: Beginning of front porch of IRQ line This is where the emulator currently triggers line IRQs. However, its effects are not immediately obvious, since the emulator instantly renders everything at the end of the line. Doing some calculations (numbers are rounded), we can determine: 8000000 Hz (processor speed) / 60 Hz (refresh rate) = 133333 cycles per frame 133333 / 525 (number of lines per frame) = 254 cycles per line 254 / 800 (number of pixels in a line) = 0.32 cycles per pixel 16 (number of pixels in the VGA front porch) * 0.32 = 5 cycles 5 cycles is enough time to run about two short instructions. There isn't enough time to do anything useful before the visible area of the screen begins. Additionally, the 65C02 must also finish its current instruction before handling an interrupt, which will likely take a few cycles. After finishing the instruction, the CPU will jump to ROM before going to a user routine. This routine spends the remaining cycles pushing the registers onto the stack, and jumping to the user routine. With this timing, there is no safe window where changes can be made. Beginning of back porch This would be the ideal time to trigger the line IRQ in order to give the maximum available time to IRQ handlers. 800 (number of pixels in a line) - 16 (number of pixels in the VGA front porch) - 640 (number of pixels in a visible line) = 144 pixels in the VGA back porch 144 * 0.32 = 46 cycles 46 cycles is enough time to make multiple changes to the VERA's registers, allowing for a wide variety of visual effects without any on-screen distortion. Overall, if the actual hardware triggers an interrupt at the beginning of the front porch rather than the back porch, it will greatly hamper the usefulness of line IRQs.
  11. SCAN_WIDTH includes the horizontal back porch of the previous line. This means that the IRQ (at least in the emulator) doesn't trigger until the beginning of the horizontal front porch of the line that the interrupt is set to trigger on. Triggering the interrupt on the line before as soon as scan_pos_x is greater than the sum of SCREEN_WIDTH and either VGA_FRONT_PORCH or NTSC_FRONT_PORCH (changes depending on the video mode) would provide much more time to interrupt routines. Although changing the emulator would be relatively simple, I want to make sure that this will (hopefully) reflect the actual hardware.
  12. Does anyone know exactly when the VERA triggers line IRQs? Ideally, I hope it can trigger an IRQ as soon as it is done drawing the visible part of the previous line. This would give programmers the maximum amount of time for routines that alter the screen between lines.
  13. Although YM2151 support is in the emulator (if you go to line 112 of memory.c, you will see these addresses connected to the YM2151 emulation), it is not currently documented, and these addresses may change in the future. I am assuming that they will document the YM2151 addresses after they finish working on the next hardware revision.
  14. The tilemap can be scrolled horizontally and vertically, and will loop when it reaches the edge. Due to this looping behavior, it is possible to reduce the number of writes necessary by only rewriting the row of tiles that needs to be changed. I definitely agree; the VERA reference is extremely useful. Here is a link.
  15. Super Mario Kart relies on SNES Mode 7 graphics tricks to function, so it would be very difficult to create a game for the Commander X16 with similar functionality.
×
×
  • Create New...

Important Information

Please review our Terms of Use