Jump to content

RevEng

Members
  • Content Count

    6,847
  • Joined

  • Last visited

  • Days Won

    10

Everything posted by RevEng

  1. 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.
  2. RevEng

    Get Lost!

    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.
  3. Yep, it's really very impressive! And doubly so, considering it's spendidnut's first dance with Maria.
  4. [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.
  5. 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."
  6. He means blurring on each pixel edge, not the screen edge.
  7. 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. 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)
  8. Super glad for you, Lewis! A rocky start, but much better than having to send it back.
  9. Ah, excellent! 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.
  10. 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.
  11. Interesting. I think we'll have to do some investigation for the next release, playing with target and compilers and such, but I'm pretty tied up with projects, so it probably won't be soon.
  12. I'm not arguing against it, but it looks like it uses self-modifying code.
  13. How about Mame - does it do the same?
  14. 29x29 with 6-scanlines per block works perfectly on my small CRT (with heavy rounding), and there's plenty of blanking around the QR code. I can even QR scan this picture being displayed on my computer monitor. 7800 binary attached, as well as the QR code test image in binary. qrtest.a78 qrtest-binary-data.txt
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. Short story, Maria doesn't do processing it might otherwise do for graphics at rom below $9000. See the "Note" at the end of the incgraphic section of the manual.
  20. Can you run the following, and advise? ls /home/x/7800basic ls -la /home/x/7800basic/7800basic*
  21. I'm not familiar with that tool. I use my stand-alone program 7800header from the 7800AsmDevKit which can add/strip headers.
  22. It depends. If you're using a front-end or CLI, you can skip the CRCs. Something like "mame64 a7800 -cart /path/to/my.a78" works.
  23. 7800basic uses some stable-but-undocumented opcodes, to speed up it's sprite routines. This broke some of the emulators without complete 6502 implementations.
  24. Yep. It's a known issue with bankswitched games. If the "incgraphic" happens later in the cart, the plotmapfile command doesn't know what palette you assigned it. The work around for now is to stick the plotmapfile in the last bank, and gosub to it if necessary. Sorry, less than ideal, but it's a bit of a tough issue to sort out.
  25. RevEng

    Get Lost!

    One more thought... you could run the "Cart Integrity Test" in the 7800 Utility Cart rom, to see if your CC2 is giving up the ghost. 7800 Utility Cart (20161210).bin
×
×
  • Create New...