Jump to content

StephenHorn

Members
  • Posts

    440
  • Joined

  • Last visited

  • Days Won

    20

Everything posted by StephenHorn

  1. If I didn't have one of those as a kid, myself, then I had something very close to it. I specifically recall the springs. That said, I found that I didn't really learn a whole lot from it. I'd connect up the projects, but never bothered to make sense of why things were connected the way they were. Definitely something I wish my parents had been more involved with, but then I think it was a gift from one of my uncles.
  2. Oh! My mistake then. I thought the kernal would only support loading into individual banks.
  3. I have a practical example using ca65 macros, you can find the relevant files here: https://github.com/indigodarkwolf/x16-racer/blob/playing_with_line_irqs/src/math.asm https://github.com/indigodarkwolf/x16-racer/blob/playing_with_line_irqs/src/kernal.inc https://github.com/indigodarkwolf/x16-racer/blob/playing_with_line_irqs/src/system.inc But essentially, it boils down to this: .segment "CODE" LOADBANK=$10 ; Select bank to load into lda #LOADBANK sta $9F61 ; Call SETLFS LOGICAL_NUM=$01 DEVICE_NUM=$08 SECONDARY_ADDR=$00 lda #LOGICAL_NUM ldx #DEVICE_NUM ldy #SECONDARY_ADDR jsr $FFBA ; Call SETNAM FILENAME_ADDR=FILENAME FILENAME_LEN=$08 lda #FILENAME_LEN ldx #<FILENAME_ADDR ldy #>FILENAME_ADDR jsr $FFBD ; Call LOAD lda #0 ldx #$00 ldy #$A0 jsr $FFD5 .segment "DATA" FILENAME: .byte "FILE.SEQ" If your file can't fit into a single bank, you'll have to either break it into smaller chunks, or else open the file and read it a byte at a time. Personally, I'd suggest breaking it into multiple chunks.
  4. Hell, you could almost halve your sprite memory usage for that ship just by shading it so the light source is directly on the vertical axis. Then you could remove half of the axial roll frames and use the VERA's horizontal flipping to pretend the other half exists. But I agree with others that, ultimately, the VERA is best suited for 320x240 graphics, which is appropriate for the 8-bit era. The SNES was 256x224. Would you believe that was smaller than the NES's 256x240? The Genesis/Master System was 320x224. PC games as late as Wing Commander: Privateer and Descent (the latter being a fully 3D game with texture shading) were 320x240 resolution. The PS1 was technically a 640x480 platform, but you'll notice that the sprite work in games like Castlevania: Symphony of the Night were still 320x240.
  5. Pretty much this. But more generally, if folks want to dunk on the X16's design goals, at least be up front about that. I think rje's scorecard is pretty reasonable. I would probably be a little harsher about "off the shelf components", in part because of the necessary FPGA daughterboard solution for the VERA, but also because I can at least agree that the YM2151 shouldn't get full credit, as it's no longer in production. If there'd been an in-production audio chip and the VERA had been limited to only video, then I would have agreed with 9/10.
  6. Yaaaaaaawn we already know that if the YM2151 supply craps out then they'll roll an FPGA daughterboard. Literally posted by Lorin less than 48 hours ago. 2/10 is patently vindictive. 7/10 is reasonable. If you're that convinced that the FPGA YM2151 will become mandatory, maybe a 6/10.
  7. Yes, the emulator expects to flip the buffers and present a new frame every 60fps, which matches the display rate of the final X16. If the system doesn't allow that, then the emulator will run slow.
  8. Based on the behavior of the "palette" portion of VRAM ($1FA00-$1FBFF), I think the registers at the end of the address space do map to VRAM that does technically exist but is unusable because it is shadowed to other components, so a write to this range goes to both VRAM and the component. I don't know what the Verilog looked like to separate VRAM from the other components, but I assume it was necessary to remove in order to free up resources to support other VERA features, like sound. Even if I don't personally plan to take full advantage of the VERA's sound capabilities, I agree that the VERA was the right choice for adopting these features when suitable chips were not available on the market, as opposed to rolling a separate audio FPGA and daughterboard. It's no more or less "magical" than any other FPGA solution, but helps keep the cost of the X16p down.
  9. Shrug. I'm guessing your PC was only barely capable of running the emulator at full speed before, and asking SDL2 to blit the pixels is pushing it over by some small quantity. For reference, I comfortably run the emulator at full speed on a 4K display, scale 2, quality nearest, on the following machine specs: Intel Core i7-9700K @ 3.60GHz 32 GB of DDR4-2132 memory GeForce RTX 2080 TI (I doubt this is relevant, but maybe SDL2 is using hardware acceleration to perform the blit).
  10. Or 320*240 @ 256 colors. (76,800 bytes of the 129,472 available) Or 640*480 @ 4 colors. (76,800 bytes of the 129,472 available) Or double-buffered 640*480 @ 2 colors. (76,800 bytes of the 129,472 available) Or 640*480 @ 4 colors plus a second layer 640*480 @ 2 colors. (115,200 bytes of the 129,472 available) Clever image authoring and color cycling can animate displays without having to modify pixel data. Or using the second layer as a tilemap for repeating 8x8 or 16x16 tiles at 256, 16, 4, or 2 colors. Tilemaps can specify their palette offset on a per-tile basis, so you could have a 16-color tilemap with up to 16 palettes. There are lots and lots of things the VERA can do. Edit: And I almost forgot about parallax effects. With clever authoring of tilemaps, combined with layer scrolling, you can create parallax effects. With clever use of line IRQs you can fake multiple layers of parallax. With strategic use of sprites as well you can fake an almost arbitrary number of overlapping layers of parallax, as long as you don't go over the 801 work units of sprite data allowed per line (described elsewhere on the forums).
  11. I know it's a pretty big assumption that the VERA's PSG noise source will be an LFSR. But if it is an LFSR, would it be easy to re-use the pulse wave's duty cycle bits to adjust the length of the LFSR, such as from 15 bits to 7? This was useful on the Gameboy because a shorter LFSR produced a more "metallic" sounding noise effect, and it could be interesting to play with that idea further.
  12. And if you're willing to reverse your strings and prefix them with their length, you can make a really fast routine: CHROUT = $FFD2 ldx Msg loop: lda Msg, x jsr CHROUT dex bne loop rts Msg: .byte $0d, "!dlroW ,olleH"
  13. I like it. Couple of bugs, though: ldx, but indexing on y -> No idea what offset you'll be grabbing Never increments the index register -> Infinite loop Might also be considered a bug that the string length is limited to 256 characters. Here's a few alternatives. Arbitrary-length, null-terminated string (for up to a 16-bit address space): CHROUT = $FFD2 lda #<Msg sta loop+1 lda #>Msg sta loop+2 loop: lda Msg beq end jsr CHROUT inc loop+1 bne loop inc loop+2 bra loop end: rts Msg: .byte "Hello, World!", 0 String length less than or equal to 256 characters, null-terminated: CHROUT = $FFD2 ldy #0 loop: lda Msg,y beq end jsr CHROUT iny bne loop end: rts Msg: .byte "Hello, World!", 0 String length less than or equal to 256 characters, length-prefixed: CHROUT = $FFD2 ldy #0 ldx Msg loop: lda Msg+1,y jsr CHROUT iny dex bne loop rts Msg: .byte $0d, "Hello, World!"
  14. I don't think we have anything to worry about there, if you're thinking about folks re-flashing the VERA to their own custom designs and bifurcating the X16 community with mutually-incompatible machines. Will a few people re-flash the VERA? Probably. I expect at least one will then come to the forums here, asking for the VERA's original code so they can flash it back to normal, only to be told that the VERA's code isn't available to the public yet. Maybe Frank et al. will work something out with that person, or maybe that person will just have to live with the consequences of their hubris and buy a second X16 or a separate VERA module. Will a significant fraction of the userbase reflash the VERA? I find that highly unlikely. The VERA is already very powerful by the standards of the machines to which the X16 wants to compare itself, and anyone who wants to implement their own video solution will have the real chicken-and-egg problem where all the software developers will be inclined to write for the original VERA on unmodded X16s until many users have the mods, but more users will have original VERAs and unmodded X16s because that's what all the software is written for. Someone wanting to re-flash the VERA will have to develop a smashingly fantastic feature, and a killer app to drive adoption. If the feature isn't awesome or the app milquetoast, the mod will be a curiosity on the forums and Facebook, drive a few "likes", maybe a few more adventurous souls will play with it, and then it'll fade along with its novelty.
  15. Ah, I was wondering what was up with the ORA and STA before getting back to the RTS. That makes sense, and allows them to save a byte from SETMSG as well, since that too runs straight through READST and UDST. Clever. The academic in me wonders if they secretly depend on that execution path anywhere in the kernal. The horrified engineer in me is wondering if those dependencies are documented.
  16. An easy thing to miss in ASM projects is that "RUN" on a SYS command still leaves you in ROM bank 4 to run the BASIC command. So an ASM-based program probably wants to manually set its ROM bank to 0 fairly early in execution. This also makes the interrupt handler much, much lighter as well, since it doesn't rely on BASIC code to catch the interrupt and then trampouline into proper kernal handling. That said, I have no idea whether it's possible to exit gracefully after that by resetting the ROM bank to 4 before your program's final JSR instruction.
  17. Woah, how'd that happen? I'm digging through disassembled code in the emulator, and if you're starting from ROM bank 0, that should be: Edit: If you're not starting from ROM bank 0, say you're in ROM bank 4 (BASIC), there may be hoops it jumps through to trampouline into the ROM implementation. Or there may be another implementation altogether that assumes we're running a BASIC command...
  18. You get to choose your poison: Copy the VRAM data you want to preserve to somewhere else, where it'll be out of the way. Clobber the VRAM data you would have otherwise been preserving. There is no reason you have to keep the character set at $0F800. If you intend to use it, copy it to somewhere else in VRAM and update the layer data that would use it, accordingly. I also want to point out that the VERA does not have "banks" in the sense that I think you mean. It simply has 128KB of addressable memory, however the tail end of that (starting at $1F9C0) is overlapped with the audio generator, followed by the palette, and finally sprite attributes. So don't clobber that area with pixel data.
  19. The emulator shouldn't be adding any delays to file I/O. If you're timing wall-time, you might be seeing efficiency problems in the emulator's implementation, but I'm not sure why they'd go away in the interrupt handler. The interrupt handler looks no different to the emulator code, it's still just running a loop to process CPU instructions and update the state of various emulated subcomponents. I'm guessing that at least part of the explanation is that doing loads in the interrupt mean that the loads aren't being interrupted on every vsync when the VERA signals a new frame has occurred. 4 second load = 240 interruptions from VSYNC, during which the kernal does its ordinary per-frame stuff. If you want to make sure a load outside of the interrupt handler isn't interrupted, insert an SEI instruction before starting it. Just make sure to also have a CLI instruction afterwards.
  20. That's a useful tip. I did my own RLE expander in assembly, and while I didn't think to do that, I'm totally going to add it.
  21. Well, it looks like these effects would have to be driven by software instead of hardware. This would probably cost you somewhere on the order of 40-80 cycles for the first channel, but subsequent channels could have their costs greatly reduced (probably to around 20-ish cycles) with some clever setup. It also depends on how much memory you're willing to throw at the problem. Personally, since I seem to be willing to dedicate all of one entire himem bank to a single significant feature (math and graphics tricks, so far), I could see myself creating up to some 8KB's worth of table data to drive software-based audio effects. Though I probably won't need that much (my math lib only uses 1.5KB so far, and graphics about the same). To be clear, the SAA1099 has the same "deficiency" relative to the NES' APU. And I seem to recall that giving instructions to it was roughly as cumbersome as working with VRAM addresses in the VERA, and along with the VERA's clever tricks for reducing the costs of sequential accesses, I don't think the VERA represents that substantial of a loss in runtime performance, either.
  22. Oh, I'm fully expecting it would be possible to replicate RushJet1's VRC7 covers of Megaman games. The only trick is that certain effects that the NES used to be able to do on its own would have to be done in software on an X16, such as pitch bending/sweeps. I'm not sure how the VERA will treat a subtle pitch change, or if it'll produce audible artifacts.
  23. In theory, the X16 will retain a 640-wide display, whereas the SNES was 256x224. It's just that the interlacing is drawing half the 480 scanlines per frame - evens on one frame, odds on the other. So, again in theory, you could probably play with classic NTSC tricks for color-blending and transparency by alternating what's visible between any two frames, either by keeping your own count or by referring to the top bit of the DC_VIDEO register on the VERA. Of course, you can still do that with 320x240, and if you're doing multimedia then you're probably in 320x240 anyways just because 640x480 requires prohibitive quantities of memory in many cases.
×
×
  • Create New...

Important Information

Please review our Terms of Use