Jump to content

sage

Members
  • Content Count

    1,261
  • Joined

  • Last visited

Posts posted by sage


  1. Btw we always wondered where that edge jittering is coming from btw?

     

    The x-position is updated with a fractional number and the width is updated with a fractional number (dictated by hardware). normally, one would update x1 and x2 and loop from x1 to x2.


  2. yes. the easiest way is to check the default location for useful directory data. these are 512 and 410, depending on which type of epyx loader is used (there are several). in case of bll, the main directory contains only one entry, and a second directory with a slighly different format.

    any homebrew can use any directory format it wants.

    The bootrom only makes it necessary that the first 52 bytes of rom are correctly decryptable. what happens afterwards, depends what code you put inside there...


  3. >> I installed "RetroArch64" and found that shaken not stirred does not work with this emulator. :-o

     

    Can you please tell us which core you were using? Retroarch "contains" at least three different lynx cores.

    And please file a issue in the tracker.


  4. It seems as if the Lynx has a concept similar to the "Master Cycles" on a SNES.

    So the Master clock is 16Mhz, and it seems some of the custom chips run off it from the "marketing" but then you could also says the C64's VIC-II runs at 8Mhz in the same way.

    Is a tick 1 "clock/cycle" in normal CPU terms i.e a full hi + lo phase of the Phi2 clock, at 4Mhz.. or are they slightly faster ticks?

    The RAM data sheet says its 120ns RAM so that is 220ns to do a read which gives a max CPU speed of 4.5Mhz but that takes 5 ticks, a Page look up then takes 120ns but that still takes 4 ticks.. However does Mikey/Suzy still need 4 ticks, or do they take advantage that the data grabs will mostly be on the same page, and grab data faster using the page timings. ( this is going to make self mode mod code even faster and more critical for speed on a Lynx)

     

    Having the Page mode makes it impossible to do shared bus.. as you can't have the graphics chip access RAM which may need a completely different address and keep the Page mode. So I theorize that the blitter etc always eats cycles for every byte it has to read, no shared bus.. I think having a shared bus would be faster overall than this 'special' page logic..

     

    I think we need a "Howard" and a Logic Analyzer ;)

    Is there a way to modify a "background colour" on the Lynx in real time, "work out raster time" inc dec some colour register, pen value? then you could make code that just inc dec inc dec and then see where the bars stretch. I don't have any hardware so I can't test such things.

    yes

×
×
  • Create New...