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

RevEng

+AtariAge Subscriber
 View Profile  See their activity

  • Content Count

    6,681

  • Joined

  • Last visited

  • Days Won

    10

Posts posted by RevEng

  2. Posted

    BCD numbers are basically hex numbers. i.e. When you convert the decimal value "13" to BCD, it becomes $13. Since a byte's max value is $FF in hex, those 2 hex digits only allow for representing a BCD value up to "99".

     

    Yes, there could be a routine developed to return 2 bytes, but I try not to add a lot of functions that will go unused by a large number of games.

     

    How's your number generated in the first place, and what's it's max value? If it's updated with addition and subtraction, you could also use an extra score variable to track it in BCD. Or if we're just talking about a value with a max of 255, you could just do some iterative subtraction to pull out the 100's place.

  4. Posted

    Arbitrary user-interrupts (other than the current near-top, near-bottom, and offscreen ones) aren't planned in the near future. An NMI color change interrupt needs minimal overhead to be reliable - otherwise, adding more dma increases the chance of the color change not taking effect until the next scanline, to the point where the heaviest DMA limits can cause a miss in the most minimal color change code.

     

    I may change this in the future if I take on an NMI handling rewrite, but honestly I have a few different pieces I'd like in place before I consider that, to avoid painting myself into a corner.

    • Like 2

  6. Posted

    The Haunted House issue isn't really a 7800 compatibility issue. HH has a code bug that accidentally loads a value from TIA instead of using a constant value. This is literally a goof-up on the programmer's part. On most consoles the game works despite the code bug, because those consoles have enough bus capacitance to give previously read values some hang-time, if the bits in question remain undriven.

     

    However this isn't expected or guaranteed behaviour. Some seemingly rare consoles don't have sufficient hang time to overcome this sort of code bug, including 2600s. I haven't seen any evidence that the 7800 is more or less prone to the issue than the 2600 is, though admittedly the rarity of these consoles makes the comparison a bit tricky.

     

    • Like 2

  7. Posted

    Yep, that's a clean result. If you have problems with ROM on the device, some of those blocks might turn red. It may be worthwhile to leave it running for a bit.

     

    The missing blocks are normal, and just ones I can't check for technical reasons.

  9. Posted

    [edit - beat by Karl, but something odd seems to have happened to his post.]

     

    The font graphic data is in ROM, imported into the correct place and format via the incgraphic command.

     

    In the example I used, the character strings are in ROM. The RAM version of my example is nearly the same, except you dim a buffer "dim charbuffer=$2200" and use "memcpy screen1map charbuffer 288" (or whatever the size is) to populate it, and then plotmap the "charbuffer" ram buffer instead of the "screen1map" rom.

  10. Posted

    On 4/6/2021 at 9:48 PM, Lynxpro said:

    GCC didn't finish the GUMBY and it wasn't directly because of Jack Tramiel. [...]

    According to Steve Golson, The mini-gumby design was complete, GCC had prototype chips manufactured, and they also had a "minnie rag" demo playing music. In my book that's finished.

     

    Steve looked over that wiki entry, and while he had some suggestions for the technical sections, he had no objections for the assertion "the chip ultimately never made it to production, due to the Warner sale of Atari to Jack Tramiel, which marked an end to GCC's relationship with Atari."

    • Like 3

  12. Posted

    12 hours ago, batari said:

    What would happen if I made a 12-high zone, aside from wasted space? Does it mean the sprites won't work correctly if I tweak the DLL to 12 high zones?

    At a minimum, any line in the top portion of the sprite that has an offset in the zone greater than 11 wouldn't appear. I'm pretty sure there would be some additional glitching on the bottom-portion of the sprite too, though I'd need to trace the code to describe the effect in any detail.

     

    12 hours ago, batari said:

    As for the 12-high pixels for the standard kernel, the only way I can see that could match things up is to use three 8-high 7800 characters stacked vertically for every two playfield pixels high. It shouldn't be that hard to do. A potential issue with this, though, is converting the 48 bytes of playfield data to 288 bytes of character data in 7800basic. It can be helped with a lot of lookup tables and unrolled loops, but still that is a lot of stores. It'll take thousands of cycles to convert that.

    If you're willing to update them during the visible screen (there might be perceptible shearing if there are regular updates) you probably have the cycles to do it. With DMA running and a modest 160A screen with double-wide characters you'll have about 10000 6502 cycles leftover.

     

    But as you point out, playfield: needs to be converted anyway. It would just be easier to directly use 7800basic alphadata+plotmap. Something like this... 

    playfield:
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 X..............................X
 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

    Could become something like this... 

     alphachars '.X'
 alphadata screen1map tileset_blocks
 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'X..............................X'
 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'
end

; you also need to "plotmap" this map somewhere onto the screen
; and include a PNG graphic called tileset_blocks.png in your code
; with graphics for the 2 characters.

     

    Things like pfpixel and pfread would require updates to pokechar and peekchar. (pfpixel/pokechar would need a different setup for the playfield though, as you'd need RAM based characters)

     

  14. Posted

    Ah, excellent!

    46 minutes ago, batari said:

    I am more wondering if 7800basic can easily display a playfield-like character map similar to the dimensions bB uses. I suppose one equivalent for the standard kernel might be characters 8x12 pixels high in at least a 16x12 grid (20x12 maybe) in a 160-wide mode. Or 16x14, if a score is to be done below the main screen. Each character would represent two adjacent playfield "pixels." Initially the characters will be defined as one of four values and would look just like playfield pixels, but could be changed to be actual tiles.

    [...]

    The playfield pixel width is easily matched. 16-wide, 32-wide, 40-wide, whatever. The height is a bit more problematic. While other zone heights are possible, a zone height of 8 or 16 are "normal" ones for sprites and characters - any other choice means you need to keep big chunks of the rom empty above and below sprite data - so 7800basic locks you in to one of those.

     

    The sprites are no problem, and locating the sprites is done with similar coordinates to bB. Here's the "simple" sample that comes with 7800basic. 

     rem *** a simple program to move a happy face around with the joystick

 set zoneheight 8

 dim playerx=a
 dim playery=b

 incgraphic face1.png

 rem *** set the colors of palette 0, which we'll use to draw the happy face
  P0C1=$82
  P0C2=$48
  P0C3=$fb

main
 clearscreen
 if joy0left  then playerx=playerx-1
 if joy0right then playerx=playerx+1
 if joy0down  then playery=playery+1
 if joy0up    then playery=playery-1
 plotsprite face1 0 playerx playery
 drawscreen
 goto main

    Adding more sprites is just a matter of adding more "plotsprite" commands before the drawscreen. (which different coordinates, possibly different graphics or palettes)

     

    Another sample you might want to check out is the "adventurer" one. It has a sprite, score displays, and background character map.

     

  15. Posted

    27 minutes ago, Albert said:

    Interesting, I'd like to see an example of this.  :D

     

    I find you sometimes need to pull out a bit, so the lines between each ascii row are blurred.

     

    Also some neat non-ascii, but non-standard QR codes...

     

     

     

    ...now I need to get out of r/qrcodes before I go any deeper down the rabbit hole.

     

    • Like 2

  20. Posted

    32x32 was just what I figured was the maximum with PF and character resolution and being nearly square, and dialing back a bit on the squareness; a back-of-the-envelope calculation of what was possible. Of course 29x29 is the goal.

     

    203 would be fine on either platform, but the further we go past 192, the more rounding distortion we get on CRTs, which I anticipate is going to be more problematic than non-square pixels.

  21. Posted

    I challenge the assumption that there's a need for a ground-up rewrite to reuse code. There have already been a few ports and co-developing of bB games. All of the logic, data structures, and TIA sound should come over as-is, with the graphical stuff and collision handling needing to be unique. (I include a boxcollision function, so the latter isn't a huge hardship)

     

    The flow is remarkably similar to bB, since I also have a drawscreen command, which similarly waits for a part of the frame to begin. (though in 7800basic the wait releases near the top of the visible display, where the most-abundant and least-strategically useful cycles are on the 7800)

     

    The stuff that needs to be updated is also the stuff that's the hardest to pull off here. player copies, widths, and reflections don't get stored with the sprite definitions, they get updated on the fly. I could try to store multiple copies of each sprite with baked-in pixel delay, but it gets even more complicated when the zone height is different than your sprite height.

     

    It seems a lot of effort and rom space to pull off what would ultimately just allow for inferior ports of 2600 games. I'm not saying the idea doesn't have merit as a mid-ground for ports, so much as I I'm saying there are other features I need to tackle first, with not enough hobby time in the day for those. e.g. scrolling, native sprite-based-tiles, qr codes, etc.

    • Like 1

  22. Posted

    Been looking at this from the 7800 side.

     

    I reached the earlier conclusion here about alphanumeric not supporting proper URL encoding. I think it's questionable that all QR readers would turn these into proper links (since URLs are case-sensitive, i anticipate many not bothering)

     

    v3 29x29 doesn't seem out of question. With the aspect ratio of the 2600 and 7800, you'd need 6.89 lines vertical for perfectly square pixels based around 2600 PF pixels or 7800 characters. If you drop that to 6, you get a 32x32 display, with 15% distortion. IMO that's good enough. People use monospace fonts to embed QR codes in reddit posts, and those are nowhere near square.

     

     

     

    • Like 1

  23. Posted

    3 hours ago, BydoEmpire said:

    Just out of curiosity, what are the graphical glitches?

    When sprites aren't perfectly aligned in a zone, the zone graphics are incorrectly aligned. Some lines appear as if they're missing, other lines appear to be duplicated.

     

    730590187_prosystemwizd.png.ca704cdfb702ef3d54f94035247fbc22.png

     

     

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...