Jump to content

Luigi301

Members
  • Content Count

    372
  • Joined

  • Last visited

Everything posted by Luigi301

  1. I've got a U1MB upgrade that I can't install in my XEGS because none of the chips inside are socketed and I don't have the ability to desolder DIP ICs. I'm looking for an 800XL with the socketed MMU and OS ROMs that I can install it into.
  2. Is there a fast way to do transparent blits with the blitter alone? I have some 16x16 sprites I want to blit from a sheet onto a background layer. I dont want to do it with the object processor because theyre bullet sprites instead of player sprites, and blitting a million bullets with the object processor would be a waste of DMA time. On the Amiga you could combine bitmaps A, B, and C into D using C as a mask but the Jag blitter only has two channels. edit: The DCOMPEN flag seems to be what I was looking for. Man, the technical manual sucks.
  3. My Skunkboard and Jag arrived, too. But why does my spinning square, which works on Virtual Jaguar as you can see above, get drawn incorrectly on the real machine? Hmm.
  4. I'm running vasm 1.8a and the MOVE PC,Rn instruction of the jagrisc CPUs is giving me an internal error. I copied this macro from some Atari example code: .MACRO JSR ; Jump to subroutine macro ; trashes R6 subq 4,SP ; adjust the stack pointer nop move PC,r6 ; determine current program address addq 16,r6 ; new address for after this macro store r6,(SP) ; push return address onto stack movei \1,r6 ; load up subroutine address jump (r6) ; jump to subroutine nop ; jump doesn't occur until this instr .ENDM And when I try to use it, I get this error in vasm: vasm 1.8 (c) in 2002-2017 Volker Barthelmann vasm Jaguar RISC cpu backend 0.4b (c) 2014-2017 Frank Wille vasm madmac syntax module 0.4b (c) 2015-2017 Frank Wille vasm vobj output module 0.8 (c) 2002-2016 Volker Barthelmann fatal error 5 in line 4 of "JSR": internal error 0 in line 476 of cpus/jagrisc/cpu.c called from line 7 of "FIXED_MMULT_PRODUCT" called from line 349 of "dsp_matrix.jerry.s" > move PC,r6 ; determine current program address aborting... make: *** [Makefile:43: obj/dsp_matrix.o] Error 1
  5. I went around the problem with a better solution anyway - adding a 1bpp text layer with the object processor instead of combining a 1bpp text layer and an 8bpp background layer. Now I can put text on my screen
  6. If I have a 1bpp text layer and an 8bpp background layer, can I use the blitter to combine them automatically? i.e. if I set the text layer up as A2 and 1bpp and the background layer as A1 and 8bpp, is it smart enough to expand the 1bpp pixels to 8bpp pixels? I'm not sure if my problem is the blitter not being able to do that or not setting the parameters up right.
  7. Look at that! We've got transformation! Now I just need to do all the math on the DSP instead of the 68k...
  8. Yeah, thats why you need a multisync monitor and expensive converter cable instead of just a VGA header. The monitor signal for the ST and TT isnt quite within spec for standard VGA equipment - most monitors dont like the 15KHz horizontal sync in low/medium resolution or the 71Hz vertical sync in high resolution.
  9. That's helpful, thanks! I think I'm on the right track now. e: Yep! Got them drawing in all octants now. I'm thinking the distortions are accuracy problems with doing trigonometry with 16.16 numbers...
  10. Yeah, I ended up picking up a console bundle off eBay.
  11. Okay, it looks like the problem is my line blitting routine. I'm not converting a slope to A1_INC and A1_FINC values right. Draw a line from (0,0) to (64,64) - slope of 1, A1_INC = (1,1), no fraction. Okay. Draw a line from (0,0) to (32,48) - slope of 0.666... A1_INC = (0,0), A1_FINC = (0.666,0)? Now there's no Y increment... A1_INC.y = 1? 0.666? Draw a line from (0,0) to (100,10) - slope of 10. A1_INC = (1,10)? Do we increment by X = 1, Y = slope for slopes > 1 and X = slope, Y = 1 for slopes < 1? Do we need A1_STEP at all? I haven't figured out the correlation yet. I can draw all the vertical and horizontal lines I want though. Here's the whole blit routine on Github.
  12. I was hoping to get a better deal than overpriced eBay listings but I know theyre on the rare side.
  13. Yeah, I wired up a simple double-buffering setup and it took care of the issue. I don't know why I didn't think of that. Now I've got... uh, other issues to fix with my rotation logic.
  14. The emulator claims it's running at 60fps. I tried putting the blitter in phrase mode (it was running in pixel mode for blitting 320x200, whoops) and it didn't seem to help. Hmm.
  15. I played with the blitter settings and I don't think it's the blitter. I don't think I'm synced to vblank. Either that or setting a matrix to identity with the CPU takes 200 scanlines. I can't find the jaglib source code so I'll try writing my own vblank interrupt sync stuff using Breakout 2000's startup code as a reference. I've done all this on the Amiga but the Jaguar's video hardware is... stranger than the Amiga.
  16. Im not sure, but clear_video_buffer just blits a black 320x200 rectangle to the screen and has the same slowness. Maybe the problem is something else, I'm not sure how the DMA priorities work. It shouldn't be doing anything else other than processing the object list. The GPU and DSP are idle and the object list only contains 3 bitmaps and a stop object.
  17. There's a few different Atari Diagnostic Cartridges out there. If you're looking for color adjustments, you probably want the Videosoft Color Bar Generator.
  18. I guess I'll use this thread as a general Jaguar questions thread. I'm working on adding wireframe 3D to my Jag program, currently doing calculations on the CPU. I'm blitting lines to a 320x200 bitmap that gets drawn as the lowest-priority object by the Object Processor. The first thing that my frame loop does is use the blitter to set the contents of the buffer to 0. The problem then is that the bitmap stays blank until around scanline 140 of the screen. Nothing I draw appears above that line, like it's taking that long to get there. The blitter surely doesn't take half the screen to blit 64KB of 0s and the calculations aren't happening until the end of the frame loop, so what am I missing? Here's my frameloop on Github.
  19. I thought tape trading died with tapes, guess not. Sometimes I run across old catalogs of wrestling tape traders. Homemade best-of collections going back to the 70s.
  20. My monitor has both phase and clock adjustments. I was able to clear up most of the jail bars on my ST video by playing with them but it's still noticeable. I just use a CRT when possible.
  21. I'm getting into Jaguar programming. I've ordered a Skunkboard while they're available but I'm lacking something very important: an actual console. Does anyone have one they're willing to sell? I'm located in the US.
  22. Yeah, it seems to be crashing for me with --debugger on even if I don't load a cartridge image.
  23. I solved my problem. In my case, the solution was: void DSP_START(uint8_t *function) { uint32_t calculated_pc = 0xF1B000 + (uint32_t)(function - dsp_matrix_functions); MMIO32(D_PC) = calculated_pc; printf("DSP running from 0x%08X\n", calculated_pc); MMIO32(D_CTRL) = MMIO32(0xF1A114) | 0x01; } Where dsp_matrix_functions is the start of the program code in DSP RAM and *function is a pointer to the function I want. D_PC just needed to be set to the offset in DSP RAM. I was trying to make the DSP run the programs out of cartridge ROM above. Now I've got 4x4 matrix addition and subtraction running on the DSP!
  24. I have this program containing some matrix math functions for the DSP that I'm working on. I want to be able to load the whole thing into DSP memory once and run the individual snippets that I need. How do I calculate the offset I need to point jag_dsp_go() to in order to call an individual snippet? I want to be able to do: #define DSP_FUNCTION_LOAD(X) jag_dsp_load(D_RAM, X, X ## _end - X ); #define DSP_FUNCTION_GO(X) jag_dsp_go((uint32_t *)X, 0); /* here's what I need to figure out, this is wrong */ #define DSP_FUNCTION_OFFSET(X) ( (uint32_t *)(0xF1B000 + (dsp_matrix_functions_end - X)) ) jag_dsp_load(D_RAM, dsp_matrix_functions, dsp_matrix_functions_end-dsp_matrix_functions); jag_dsp_go(DSP_FUNCTION_OFFSET(dsp_matrix_add), 0); But I don't know how to calculate the starting address for dsp_matrix_add.
×
×
  • Create New...