Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

LinkoVitch

Members
 View Profile  See their activity

  • Content Count

    2,801

  • Joined

  • Last visited

  • Days Won

    14

Posts posted by LinkoVitch

  1. Posted

    Assuming I am understanding what you are doing (I think you might have pasted the wrong bug link BTW) I think the current version or RMAC does work correctly for calculating the difference between two labels.  I have the following code in the SE

      

    .pc:	move	PC, JUMPTO
	addq	#(mainloop - .pc), JUMPTO

    to calc a branch to the main loop, and that is working fine for me. 

    • Like 1

  2. Posted

    I'd have thought the CPLD would have been programmed via the JTAG and the voltage supplied by the programmer itself via the JTAG header?

    RE amps, it will draw what it needs, you just have to supply enough potential.  IIRC the analogy is imagine the wire as a water pipe, Amps is the diameter of the pipe, voltage is the pressure, so as long as the "pressure" (volts) isn't too high the amps won't matter.

    • Like 1
    • Thanks 1

  3. Posted

    I would suggest one of the tips that is flat and angled (looks a bit like a knife point).  The theory I read was that the tip is cooler at the point than the larger portion, so as you drag along the pins keeping the whole flat edge on the pins with the point end being the last to touch the pin as you pass over, the solder is slightly cooled and it distributes evenly.  Obviously dab a LOAD of flux over the unsoldered pins with the part in place, makes a cool popping noise as you solder but helps with the bridges.

     

    My drag soldering is a bit naff tho :)

     

     

    • Like 1

  4. Posted

    1 minute ago, atari2600land said:

    So does that mean a CLUT can have up to 256 colors in it? If that's the case, then how does someone using Raptor Basic achieve this? In my programming with it, it seems like a CLUT can only have 16 colors in it.

    Yes the CLUT can only have 256 colours in it.  Don't use an indexed bitmap object, use a 16bit or 32 bit object.  The CLUT isn't used if the colour data is stored directly in the pixel data.  Might be worth asking this question in the RB programming section, I have never used Raptor Basic

  5. Posted

    5 minutes ago, atari2600land said:

    Is my assumption of the Jaguar only being able to show 256 colors at a time correct? Having 16 CLUTS available, with each CLUT being able to have 16 colors in it, with 16x16=256. If this is true, then how can one object be 16-bit, using up the 256 colors, and then have more objects using different colors?

    Your assumption is wrong, the Jag can display 24bit true colour images, 16/15bit RGB, 16 bit CRY, as well as 256x 16bit colours on screen at the same time.

    • Thanks 1

  6. Posted

    1 minute ago, agradeneu said:

    Not only photos, e.g. the painting style of Raymans artwork was done in 24 bit (at least) and it would look terrible if downsampled to 16 colors. The 256 color CLUT is a limiting factor, so I guess they had to use a mix of 16 bit and 8 bit to achieve the fidelity of the graphics. 

    I don't know why you are fixating on 16 colour TBH, that is just one of the options.  Personally I'd go for 16bit 1st unless it was blatantly unnecessary, and scale back as issues arise. 

    I'd not be surprised if the large static background on Rayman was 8bit, it has a fairly subdued colour scheme, possibly less than all 256 freeing up some of the palette for the text etc.  I am speculating I've not tried pulling the ROM apart yet :D

  7. Posted

    1 minute ago, agradeneu said:

    It can and it does.

     

    No need to use 16 bit for low color images. Waste of data. However, if you had images of higher quality....

    From my knowledge those background could look a ton better if they were genuine 24 bit quality and then downsampled to 16 bit Jaguar format.

    From my own CoJag digging, ATari do like to use 8bit colours.. dunno why, CoJag has more memory, more ROM, more CPU and more bandwidth..

  8. Posted

    6 minutes ago, agradeneu said:

    Hm, if I understand correctly what you mean, no to both.

    1.

    The image quality of 16 bit bitmaps are much higher than index 4 bit. It's 2000+ colors vs 16 colors. If you downsample 24 bit photos or high detailed artwork to 16 colors it will look ugly. However you can do nice pixelart with 16 colors. 4 bit bitmaps consume much less data when you store them, that can be handy. 

    From my experience, 16 bit color makes a huge difference when you use it effectively. But that needs high quality artwork.

     

    2.  An 16 bit background image can use a blur effect to differentiate. Apart from that it depends on artistic direction and choice of colors. There is no need to make a background dull. Just use color contrasts. In fact you have much more possibilities.

    Think we are at cross purposes here :) and perhaps I haven't understood your meaning.

    1) Yes obviously if you are taking a photo and want it to look like a photo, a horribly dithered mess isn't going to cut it.  If you have an image that can be rendered using less than 256 distinct colours and look the part, then that should absolutely use indexed pixels.  There maybe fewer colours, but they are still 16bit.

    2) I am no artist :), so yes there are more ways to do things which won't mangle foreground sprites.  Having a more subdued palette in the background works nicely for me (in games where I have seen it).  If there is memory and bandwidth to spare, sure have a 16bit or a 32bit colour background.. but if the background isn't the key focus of the game, might be worth halving the memory/bandwidth footprint and squishing it into 256 or less.  Won't always be possible.

     

    It's going to matter precisely on the project and the resources, there is no single right answer.

    • Like 1

  9. Posted

    7 minutes ago, WAVE 1 GAMES said:

    So to confirm you are saying that all objects should be 16 bit (including those large backgrounds) and there is no need to worry about it taxing performance at all?

     

    And may I ask what is the overall benefit of having 2 352x224 bmps as 16 bit assets if they only need 32 colors?

     

    Do you not recommend I conserve when possible for overall better performance?

     

    I'm actually not picking a fight and arguing with you I am asking for clarity.

     

    I just don't see the point of having such a large image be 16 bit if it only requires 32 colors and there is no way that doesnt have a negative impact on performance.

     

    I'm talking preventive damage control

    Nope, I think you should re-read what I put about the reasons for using indexed objects.  You are absolutely correct you should use indexed object for those types of images, and I never said otherwise.  Save on storage, bandwidth etc, much more efficient.

     

    I *DID* say that you *COULD* use those and the jag would be able to handle it, counter to what you put saying it could not.  I don't recommend you do mind, but if done properly the Jag COULD do that.

  10. Posted · Edited by LinkoVitch
    missing line

    21 minutes ago, JagChris said:

    We've talked about this before. The technique Oliver Nallet shared for busting those limits. The same  technique Duranik mentioned recently in what comes to mind for them to fix Native.  

     

    I see programmers on here mixing up what their limits are with what the Jaguars are. Someone was just saying it's hard to even code an old 80s 8bit game on the Jaguar. For THEM it's hard. Too much egocentrism in this forum.

    I guess you refer to this Chris:

    Quote

    Also note that the DSP had lower priority on the bus than the GPU. In 2 player mode we actually display more sprites,

    although I may have split the display list, the costly zone was around the horizon line as that's where we had most sprites in a single line.

    And that "technique" was known way back in the days of them designing the silicon and publishing the developer manual.

    Technically EVERYONE has used that technique, because without it the OP crashes/acts weird, and probably pretty much everyone else with more than a handful of objects on the screen will have done it.  This isn't some secret dark art that only the elite few know.  I've actually mentioned it in passing a bunch of times in my posts on this thread in fact.

    • Like 1

  11. Posted

    3 hours ago, agradeneu said:

    Generally I don't think there is a need for such trade offs, the Jaguar is doing 8bit/16 bit backgrounds just fine. "Fishing Frenzy" does not look like it's taxing the Jaguar hardware, no offense intended, just an observation. 

    If the source bitmap is already low color, 16 bit gives you no benefit however.

    I'm going to chip in as there seems to be some confusion with what I said and stuff, so just to add in my 2p :)
     

    Fishing frenzy most certainly shouldn't tax the jag at all, punting sprites it can do.  Of course a badly created object list will overly tax the system for what it is drawing on the screen, but even with a simple list with no branches I'd imagine the jag could happily handle fishing Frenzy.

    There seems to be some confusion about the "bit" of colours...

     

    3 hours ago, agradeneu said:

    Thanks, was thinking the same. The Jaguar was designed for 16 bit color, at least that is what I heard ;-) But that is 65.000 colors.

     It is smart to use 4 bit or 8 bit CLUTS to save RAM, but then use the RAM for high quality bitmaps as much as possible. 

    A background should be 16 bit, or at least 8 bit. It covers a lot of screen. But with small sprites, it is hard to spot a difference between 16 bit and 4 bit. Just my opinion.

    With 4 MB and 6 MB ROM, even with 2 MB,  you have enough data space for high color quality assets. 

    Now, this is the confusion.. a 1bit, 2bit, 4bit and 8bit image on the jag are all using 16bit colour :).. the 1,2,4, & 8 refer to the size of the colour index into the CLUT (Colour Look-Up Table).  Each entry in the CLUT is 16bit RGB or CRY depending on mode.  The index value of a pixel simply points to which colour in that LUT to use.  So a 1bit image can be 0 or 1, 2bit = 0-3, 4bit =  0-15, and 8bit = 0 - 255.

     

    The assets are high quality colour, just the pixel data is stored efficiently.  Plus backgrounds should be somewhat duller and less detailed to avoid making foreground objects difficult to differentiate.

     

    3 hours ago, agradeneu said:

    You don't need 2MB RAM and a 64 bit bus  for 4 bit graphics. 

     

    Not for the graphics, but depending on the complexity you can spam the bus by making too many calls or tie the OP up with too long a list (the whole list is processed every single scan-line, every frame.)

     

    If you have a large image using indexed pixels saves a load of RAM and also memory bandwidth.  The OP will like to read it's data in 64bit wide chunks.  1 64bit read is 4x 16bit pixels, 8x 8 bit pixels, 16x 4 bit pixels, 32x 2 bit pixels, and 64 1bit pixels.. so for Jeffs 352 pixel @ 4bit that's 22 reads to read a whole scan-line, vs 176 reads if it were 16bit.  (assuming my dodgy mental maths worked there :D ).  Of course if the object is smaller than a single read, you are going to waist a chunk of that potential pixel slurping.

     

    Whilst this may all sound super ossum, it does have it's own cost, in that an indexed Object has to also do a lookup in the CLUT to find the actual colour to paint, so there is additional overhead there, only slight, but still something to bear in mind.  oh and you are limited to 256 colours in total shared between all those Indexed objects.

     

    28 minutes ago, WAVE 1 GAMES said:

    I said a 352 pixel wide 16 bit color background accompanied by a 352 pixel wide foreground image and parllax scrolling (ie movement of large 16 bit objects on screen) combined with over 16 animated 16 bit fish moving around would tax the shit out of the system, because guess what? It will.

    Sorry Jeff, it won't.. not if it's done correctly.  When you move something on the screen with the OP, it doesn't actually "move" anything.  If you badly build your list, don't make use of branches and a well structured list, or have overly large objects that hang off the sides of the screen, then yeah it's going to struggle and fail.  But it is entirely possible to have a full screen image with many layers of parallax.

     

    Sorry if that's a bit all over the place :)  HTH anyway
     

    • Like 1

  13. Posted

    Looking at the pictures Jeff posted earlier in the thread, the original image is a 32 colour indexed image, assuming this is as it is when extracted from the CoJag ROM, I'd suspect they are stored as 32 colour 8bit images.  If they have any other low colour sprites (high score font, HUD etc), then those images would likely have their palettes combined into the shared 256 colour CLUT.

    Low colour doesn't reduce the dynamic range of the colours (well less than 16bit), just stores the colours via an index, which is more efficient (in terms of memory) than storing the full 16bit value.  So if you only need 16 colours, 4bit is perfectly fine, you will still be displaying 16bit colours on the screen, but the pixel data will be a quarter of the size in RAM.

    Cool thing with the OP is that if you are using 1, 2, or 4 bit images, you can merge the palettes together and then provide an offset index into the CLUT for where that objects palette starts.  So you can build a screen with a bunch of low bit depth objects all using different palettes.  The less RAM the bitmaps occupy the less bus bandwidth the OP has to consume to build the scan-line, the happier the overall system is.  There are trade-offs obviously, but this is the Jaguar :D a system of trade-offs :D

    • Like 1
    • Confused 1

  16. Posted

    I don't know if one is available, but probably able to get one made from the PCB design that was published, but an SMD stencil will be a godsend for getting the right amount of solder paste onto the pads for use with your heat gun.  I did a few by hand using i thing bit of plastic to apply paste by hand, it was tedious and messy, worked OK for stuff like resistors and caps, but when the pin density got higher I just couldn't get the right amount on pads and got loads of bridges that then took hours to sort out with wick and faff.

    Using a stencil I was able to solder QFP32 parts in minutes, even QFN32 too! used a lot less solder paste and so much nicer to work with.  They have their own challenges, but for me at least it gave a better result than trying to hand/drag solder those parts, or manually applying paste.

    Good luck with your building whatever approach you go for :)

    • Like 2

  18. Posted

    1 hour ago, cubanismo said:

    Getting technical for a minute: It would be cool to have a huge bank-switching cartridge for this.  Your cdemu bios code could bank switch based on the CD timecode requested from CD_read, and in theory you could run it all without modifying the game code.  Would be hard to test on skunk, but since the Game Drive already supports massive bank switched ROMs, it would be the perfect development platform, even without "real" CD support finished.


    Of course I'm glossing over many, many details here.  It's easy to think up crazy project ideas for other people to work on 😁

    That would require the game to make no calls to cart space (which given it's a CD game is likely during game play), however it would also require a rewrite of the audio code to switch from CD source to streamed from cart, which may not be too complex if the full source is available, but is also going to add additional load to the systems bus.  CD Audio data comes from the CD via the I2C bus and therefore doesn't impact the main system bus at all, reading from cart space would do, and at a slower rate than reading from RAM, and only 16bits at a time for the DSP (thanks Atari! :D ).

     

    Certainly an interesting idea, but like most things on the Jag compromise is going to be needed quite likely :) (will depend how hard the system bus is being pushed)

  20. Posted

    On 3/17/2020 at 5:08 PM, swapd0 said:

    I think that the module player has some bugs, If I remove the play module call it works, but with the module player it hangs but not always on the same place, it's weird, and I've run out of ideas to find the bug.

     

    Later I'll try with an older version.

     

    False alarm... now it also hangs without the music, f*ck!

    Quick update for you and anyone else hitting this bug.  There is a patched version available now:

     

    https://www.u-235.co.uk/se/files/u235se-2020-07-20.zip

     

    This resolves the need to have a mod to use the pads/RNG

    • Like 2

  21. Posted

    If anyone is interested I have just pushed a container to docker hub that contains the latest build of RMAC and RLN.  I am using it for testing commits and package building for my Sound Engine in a CI/CD environment.  Other than RMAC/RLN it also features Make and a 68000 version of nm for extracting labels from the relocatable build of the sound engine.  Built on Ubuntu 18.04 base and is only about 100MB.

     

    It's probably pretty niche but it's available if anyone else wants to use it.  I plan to stick the Dockerfile that built it on github when I get around to it. 

     

    Anyone interested in it can snag it with:

     

    docker pull hisol/jagbuild

     

    (no versions at this time as this is just the 1st push that I needed for my automation shenanigans in GitLab :) )  Will try and keep it updated as new releases of RMAC/RLN are made.

    • Like 4

  22. Posted

    23 minutes ago, swapd0 said:

    9.2MB and 153,798 lines

    OUCH!

    I'd hate to work on something like that, much prefer chopping my source into smaller more manageable chunks and using include to combine them.  I find it makes it easier to find the bits I am looking for.  Would also make VCS like git store more data as it will save the whole file for a single character change.

    • Like 1

  25. Posted · Edited by LinkoVitch
    clarity

    13 minutes ago, WAVE 1 GAMES said:

    As for the input delay and controller functions example in order for both players to press keys simultaneously on jagpad 1 and 2 there needs to be a delay set up using U235. I could be WRONG but I don't recall having to do this with Zeroplayer. It seems to just work. I am going purely off memory here but I am certain I did NOT set up a delay on ZP and it worked and in order to do the same thing with U235 I had to set up a delay. I assumed this was due to the higher BUS usage on the U235 players end. BUT it is all speculation on my part admittedly.

    There is no way to setup any delay on pad reading in my Sound Engine.. it reads both pads as fast as it can and presents the states of the pads.  I just checked the code and it actually reads BOTH pads data at the same time as their data is mixed together.
     

    13 minutes ago, WAVE 1 GAMES said:

    An added note the file size for unsigned audio files can be much smaller than signed which is why I would want to use some signed and some unsigned.

    No it's not, they are size identical, one is using 8bit signed integers, the other is using 8 bit unsigned integers.  The sample resolution is 8 bits in both formats per sample, hence they are identically sized and easy to convert between (literally add 127 to each byte if memory serves - for signed to unsigned).

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...