Jump to content


  • Content Count

  • Joined

Community Reputation

79 Excellent


  • Rank
    Star Raider

Contact / Social Media

Profile Information

  • Gender
  • Location
  • Interests
    Informatic and Electronic

Recent Profile Visitors

7,720 profile views
  1. Oups, reading too fast You will have enough time : it will work fine as all i known game set to 10cycles.
  2. The Blitter as a referenced bug for 2bit pixel mode : - "Unaligned blits in 2bits per pixel mode are not reliable. Use 1bit per pixel blits instead."
  3. The EEPROM interface use the IOSPEED parameter as the EEPROM is read/write from the GPIO interface. If i remember correctly the register is configured it 6cycles. Others mode are not working due to a bug in Jerry wich decode the GPIO range
  4. All my C code are build with : C2OBJ = m68k-atari-mint-gcc -Wall -I$(INCLUDE) -O3 -c -o obj/$*.o $?
  5. 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
  6. 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
  7. and RAM is 2 cycle and ROM is 5 cycles min.
  8. [$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).
  9. 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.
  10. 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 ?
  11. 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.
  12. 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.
  13. 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 ?
  14. SCPCD


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


    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 !
  • Create New...