Jump to content

SCPCD

Members
  • Content Count

    79
  • Joined

Community Reputation

76 Excellent

About SCPCD

  • Rank
    Star Raider

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    France
  • Interests
    Informatic and Electronic

Recent Profile Visitors

7,688 profile views
  1. All my C code are build with : C2OBJ = m68k-atari-mint-gcc -Wall -I$(INCLUDE) -O3 -c -o obj/$*.o $?
  2. Hi ! I'm currently working on an C app with multiple files and I'm using "m68k-atari-mint-gcc". It works great, but after adding some more variables, I got an issue where a variable in BSS segment are not aligned with what I need : When using gcc, all variable are aligned in word boundaries, but for specific ones, I need those to be longword aligned. I tried to add " __attribute__((aligned(4)))" to have something as "u8_t toto[1024] __attribute__((aligned(4)))" but at build time gcc give me the warning "warning: alignment of 'toto' is greater than maximum object file alignment. Using 2 [enabled by default]" and finally the variable is not aligned to a longword. Why gcc don't take account of the attribute and how to resolve the issue ? Thanks
  3. Are you using the original PSU or another one ? I had something similar when using a PSU given not enough power. Recommanded one is 9V 1.2A
  4. and RAM is 2 cycle and ROM is 5 cycles min.
  5. [$000000, $200000[ = [$200000, $400000[ as it's in the same bank of DRAM and the memory controller will probably wrap (to be checked, but it's what I remember from my test 18years ago) [$400000, $800000[ is another bank of DRAM that is not used on the Jaguar and will always return "FFFFFFFF" (as there are pull-ups on the bus).
  6. It's seems that it's phrase aligned in compile time, but your start data section address in link time is not aligned making the final thing misaligned. Exemple : .text .loop bra .loop .data .phrase toto: dc.b 0 .phrase titi: dc.b 1 will be assembled to : LTEXT+0 : bra.s LTEXT+0 LDATA+0 : toto : dc.b 0 LDATA+1 : dc.b 0 LDATA+2 : dc.w 0 LDATA+4 : dc.l 0 LDATA+8 : titi : dc.b 1 so if DATA is not properly aligned, toto & titi will be misaligned. Another point to take account is to pay attention about multiple file linking as if no proper alignment size is specified between each file, it can result on misalignement.
  7. GPU object doesn't use the YPOS. I initialy thought it was a bug, but in fact it seems that some version of the doc are wrong as the last i known version (7 Nov 1994) describe the GPU obj as interrupt always and reading the netlist confirm that. Probably it was a forgotten features or they think it was not needed since there is branch object and prefer to use more bits to pass information to GPU ?
  8. GPU as a 32-bit bus and so, GPU internal access is 32-bit. But, it can do 64-bit external access because the Hi-data register is part of the 64-bit Gateway interconnection. To speed up DRAM memory read/write, i will probably advise to use loadp/storep, but for ROM1 address space, i think it's more easiest to use standard load/store for optimisation. with loadp you have to be sure that hidata is properly loaded before doing the storep or hidata read, this implies : - to wait that the destination register is written back using the scoreboard detection Or - to insert enough usefull instruction before the storep instruction or hidata read (see my ST2Jag optimised code from Orion_'s original code) When it's DRAM memory, you know that the memory controller will take the same number of bus cycle to read the data than standard load/store so it's easy to insert some instructions (supposing the bus is not taken by a highest priority) . But with ROM1, you don't (generally) know the width of the card and the selected speed, in any case, it will take at least 2x5 cycles to read 64-bit data for highest ROM1 speed with 32-bit size. If you use GPU interrupts : - don't use external load when using loadp - if you access ROM1 with loadp and can't do enough instruction, GPU will be in scoreboard wait state as you will probably need the loadp result, and so delay the interrupt in other word, you will kill GPU performance as it will be very difficult to keep the instruction flow. Using standard load will reduce the overrall pending time. Anyway, the speedest way to copy data will be the Blitter in phrase mode (if there is enough data to copy comparing to the time to set blitter registers), but it also implies that the blitter need to be available to do that.
  9. As describe in the "Technical reference v8" section "Timing Diagram" and probably in another document, you can't rely in ChipSelect to latch the address : there is a pipeline mecanism on ROM1 access, so the Chip Select is remaining asserted during all "burst" transfert. With the 68k it never happens since the memory controller add an extra cycle to "translate" the jaguar bus to the 68k bus width, and so a bus release is made. In opposite, with the GPU, Blitter or OP, you will have 100% chance to encounter successive read/write in "burst mode" at a time or another. With the DSP, i don't remaind if I made some ROM1 tests in the past so can't say if it's case 1 or case 2.
  10. I haven't do 68k code from many years now but : How does this work without a reverse movem before the rts ? Does that mean a post-compile process is done to add instructions that is not in this assembly output ?
  11. SCPCD

    STNICCC

    Here it is : http://scpcd.free.fr/temp/STNICC/stnicc.html
  12. SCPCD

    STNICCC

    Great Job swapd0 ! I try it on my JagFPGA and it works very well ! It's perfectly fluid and too fast in some part It finishs in "1:14:48" in the screen counter (60Hz) and in real time "1:02:66" to loop !
  13. There is no bug on the GPU on that. If it crashs the way you say, I would be probably 100% sure it's one the following way : - GPU code is wrong (wrong registers used, or not properly initialised, wrong address/instructions from the build process, wrong alignment) - Another CPU makes it crachs : most probability the 68k, then the Blitter (wrong commands), then DSP, and the less probability for the OP. What is running on other CPU when the GPU crash ? Some games make fucking bad stuff with the GPU (like overwriting GPU PC at any time, step by step, PC checking, no semaphore, etc...) Many use GPU code in main memory to init some basic stuff but it can be possible that the loading/unpacking process was not executed properly or at the good time if not used on real jaguar with real jagcd and original boot rom, GPU will then crash.
  14. You crash the GPU by making : load (r31),r28 ; return address addq #4,r1 addq #2,r28 ; next op jump t,(r28) ; rte store r29,(r1) in your code R1 = G_FLAGS so you increase by 4 G_FLAGS, instead to incresead R31 (the stack) I think that it should be : load (r31),r28 ; return address addq #4,r31 addq #2,r28 ; next op jump t,(r28) ; rte store r29,(r1) Should work better.
  15. From what i remember : For each line of the ground, a scaled object is modified by a GPU Object interrupt. The GPU compute the Object X position, the start address of the texture and the scale to apply to draw the current (or next?) line.
×
×
  • Create New...