RevEng

It sounds like you don't need to, but you can also dim extra score variables, in addition to the two scores provided.

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.

Yep, it's implements DMA limits, and it's pretty faithful compared to real hardware.

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.

I must admit that you'd love one, too.

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.

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.

Yep, it's really very impressive! And doubly so, considering it's spendidnut's first dance with Maria.

[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.

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."

He means blurring on each pixel edge, not the screen edge.

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)

Super glad for you, Lewis! A rocky start, but much better than having to send it back.

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.

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.

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.

I'm not arguing against it, but it looks like it uses self-modifying code.

How about Mame - does it do the same?

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

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.

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.

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.

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.

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.

Can you run the following, and advise? ls /home/x/7800basic ls -la /home/x/7800basic/7800basic*