Dragonfly Pokeymax Covox

[Dragonfly Pokeymax Covox]

If the interrupt is raised during during DMA, when the 6502 is halted, it won't be responded to.

[AI Agent57 plays 2600 games at superhuman levels]

Another update in AI-2600 news. This time the AI learned to play the 2600 games by watching youtube play-through videos, and is kept completely ignorant of any internal game states...

 

 

[A Non-Interactive Title Screen is a Safe Screen]

23 hours ago, PacManPlus said:

[...] or maybe add a check for the PAUSE button to skip for people who don't want to wait [...]

Yeah, I like this. We could also have a compile option that inverts the behaviour - press PAUSE for title screen. My thinking is modders can stick both versions on a 32K eprom, and then use a switch to just hold the eprom A14 line high or low.

 

If someone gets sick of the title screen, flip the switch. Then if you want to occasionally use the screen to troubleshoot if a failing game is being detected at 2600, then just hold pause on power-up. (or flip the switch, but a front-of-console override is handy)

 

[A Non-Interactive Title Screen is a Safe Screen]

Ok, cool. I'll send the assembly version of the title your way, when I get it converted. Real life is a bit busy and I'm supporting the MiSTer core work (which isn't a lot of work, but it's time-sensitive work since it holds the devs up when I don't reply) so it may be a few days.

 

 

16K looks to be the pal bios size, so the game will have to be smaller if we're aiming for compatibility. Currently the Fuji and Atari 7800 graphic take up most of 2x 4k graphics blocks. I can skip holy DMA and put them consecutive in memory, but I think 8k for the game might be a better.

 

[A Non-Interactive Title Screen is a Safe Screen]

1 hour ago, PacManPlus said:

Is the source code available for the BIOS?  If it is, and whomever did that non-interactive screen is willing to share their source code, I'd take a crack a trying to do that.

The main issue is it's written in 7800basic. While it compiles to assembly, it's machine-generated assembly which isn't as nice to work with. On top of that, it uses all of the flexible utility functions to draw the screen for convenience, but they make the assembly a bit more complicated than it needs to be for a bios. i.e. plotbanner commands that can move the fuji or text around. 

 

I'll have a look at unwinding it into a simpler assembly program.

 

So are we talking full encryption signature checking? Seems like a lot of stuff to port, and honestly the reason for the goofy NTSC Atari display is the check. It would be easier to just do a quick PAL style check for the cart type, display the screen a few seconds, and then launch the game. That way you could entirely avoid using Atari's signature check routines, and keep this thing open.

[BACKGRND ?]

Changing the background color for each zone isn't presently supported. If you change the colors using the previous colorbar method, I fear you'll find the result disappointing - if there is moderate-to-heavy number of objects on the screen, the colors will sometimes be pushed a line or two down for some frames.

 

For various reasons, giving the program full access to the interrupts for color changes (which requires tight timing) means I can't use them reliably for other purposes. (visible screen flagging, scrolling, non-dma device communication, etc.)

 

[BACKGRND ?]

Definitely BACKGRND is an omission. Will need to update the docs.

 

One thing to note, is that a loop like that is only really warranted when you want to do 2600 style colorbars or have more than 3 different color areas in your game. It has a huge cost in terms of the cycles available to your game.

 

To change the colors 2 or 3 times mid-screen you can use the interrupts, as demonstrated in the "splitmodedemo*" samples.

[MiSTer FPGA - 7800 Core]

35 minutes ago, mksmith said:

Great stuff Mike! Anything from the core you can feed back into A7800?

Yes and no. FPGA implementation and software based emulation are different enough to make direct transfer difficult (the former being concerned with changes on a clock by clock granularity, the latter much less so) but Kitrinx has uncovered several hardware truths along the way, so that knowledge can be applied to the emulation.

 

I have an experimental a7800 branch (on hold for now, but I'll get back to it eventually) with the goal of improved timing. The Mame YM2151 is already pretty accurate, and the Mame TIA audio isn't bad, though it's not as accurate as Kitrinx's. The big thing that needs improvement in a7800 is the oddball pokey modes, and I don't think there's anything to be gleaned here that wasn't already publicly documented. But I do have one or two ideas about making the a7800 pokey more accurate, so we'll see where that goes.

 

[MiSTer FPGA - 7800 Core]

Thanks!

 

Time for a quick update, I guess. Things are going quite well with the core. As far as I can tell - and I've probed pretty deeply - everything is completely cycle accurate. So far all of the commercial and homebrew games seem to match real hardware, including glitches that happen on both. I did A:B listening tests for TIA, Pokey, and YM2151 sound, and they all sound completely authentic. The 7800 core models the TIA non-linear volume response that was discovered a little while back too, which causes a bit of a rumble at loud volumes.

 

Currently alternative controls are being worked on by Kitrinix, and progressing well. I spent some time yesterday measuring paddle-capacitor charging rate vs resistance on my 7800, as well as measuring the discharge rate, so we could get an accurate experience.

 

interesting side note on real hardware: Atari's 1MOhm paddle resistance range is way overkill, and even the full range of Vic-20 500KOhm paddles can't be read by the 2600/7800 within a single frame.

 

[7800basic beta, the release thread]

Thanks - noted!

[A Non-Interactive Title Screen is a Safe Screen]

2 hours ago, -^CrossBow^- said:

Rev should add this into the Utility Cart if there is room for it?

That's a good idea. I've been planning a re-write of the utility cart for a while now, and this would fit in well.

[My experiments with Atari 7800]

It's super impressive, but the helicopter pilot in front should really watch where he's going!

[Get Lost!]

9 hours ago, Propane13 said:

So, I think the only issue I have is that the game was written in assembly.  Are the fixes limited to 7800basic, or is some of the code ported to the emulators as well?

The idea is language neutral. I implemented them in 7800basic, but there's no reason by they couldn't be implemented in a pure assembly. And I actually dump to the screen, without using an emulator, so real hardware reports are possible. If someone runs into the issue, they can just give a screen shot.

 

The first level of this sort of debugging is just to add certain checks, and kill the game with a certain screen color if the check is violated, without coding up a fancy stack dump. If someone reports a crash with one of these colors, you'll at least know what kind of problem you have, and that writing the stack dump is warranted.

• Check 1 - execution of data. (likely caused by bad bankswitch or bad jump table)  Add the following code to your IRQ vector (instead of the usual RTI). It will tell you if a "0" byte of data was executed. (0=BRK, which is the only source of IRQ on the 7800)

IRQ
  lda #$1A ; YELLOW
  sta BACKGRND
  .byte $02 ; KIL opcode. Stop the 6502.

• Check 2 - look for a "canary" value being overwritten by the stack (likely caused by unmatched jsr/rts, unmatched push/pop, or similar). As your last ZP memory location, define a bit of memory called "canary". Then add this check to your NMI (assuming you have one) or in your main loop.

 lda canary
 beq CanaryIsAlive
 lda #$45 ; RED
 sta BACKGRND
 .byte $02 ; KIL opcode
CanaryIsAlive

Between those two kinds of checks, you can catch a good many weird-crashing type glitches. Not all of them - it's possible a runaway memory-update loop can take everything out before they're triggered, or an unending loop condition happens - but it covers a good many of them.

 

Adding stack dumps to the above is a matter of popping values off the stack, and putting out the values to the screen, same as score values or whatnot.

 

To test the routes, just add a "BRK" opcode to your game somewhere, or overwrite the canary.

[Asymmetrical Playfield+ 48-pixel sprite AT THE SAME TIME!]

8 hours ago, Andrew Davie said:

One major thing I think is needed is to change the PlusCart servicing of the address buss from a polling system to an interrupt system.  That is, the interrupt is triggered by address change, and it's serviced, and the ARM goes back to doing whatever it was doing. In this case, streaming video/sound from a SD card.

If you can manage the bus servicing with interrupts, unshackling the arm this way would be another level of game-changer.

 

[Asymmetrical Playfield+ 48-pixel sprite AT THE SAME TIME!]

11 hours ago, Andrew Davie said:

This means you can remove the expensive indexing of graphics data and replace with a two-cycle fetch for all of GRP0/GRP1/GRP0/GRP1/GRP0/GRP1 and PF1/PF2/PF1/PF2.  That leaves (just) enough cycles in the 76 to do all of those as well as colour changes for COLUPF, COLUP0, COLUP1 and still have 5 cycles to spare.

Just enough time for an AUDV update, for soft-synth or sample playing.

 

(probably not worth the overscan/vblank update requirements, though)

 

[Space Ship Fashion Show!]

Wut? The UniWarS ship beat E.X.O's Wasp? UniWarS is an exceptionally accurate arcade port, but the ship design is more or less a fancy triangle.

 

I am shocked and angered. I will also have you know that I long ago came to terms with my squareness.

 

(fun article)

[Pac-Man Collection - 40th Anniversary Edition]

On 3/19/2021 at 4:29 PM, rj1307 said:

I confirm it, soon I will develop an adapter with the YM2151 module, it will work with any cartridge (homebrew, Concerto, CC2, Mateos).

[...]

This is a very cool development, which makes the future of YM2151 usage in games a lot brighter. Thank-you!

 

7 hours ago, tep392 said:

No, but I did make some notes this week on how to do it.  I'll definitely have time to try it out tonight.

Thanks Perry! I'd love to try out whatever you come up with in A7800 and the in-progress 7800 MiSTer core. I suspect the former will need some rework before the detection works.

 

[Get Lost!]

@Propane13 In case the bug is keeping you from working this gem - heads up that a few AA 7800 coders collaborated on a "Debugging On Ancient Game Platforms" article at the wiki. I personally implemented some of the ideas in the Common Causes of Catastrophic Problems section inside 7800basic, and they've helped a fair bit with these sorts of random errors. 

 

Specifically, I implemented a canary check, and IRQ detect routines. Both sorts of problems will now trigger a dump of stack values to the screen and then run the KIL opcode to stop everything cold. This lets you know which address triggered the problem, which is often a smoking gun.

 

Not harassing you to return - one shouldn't feel pressured to do one's hobby. Just letting you know there might be a more positive path forward with this project.

[7800basic beta, the release thread]

Nothing in 7800basic proper, yet. But if you run the 7800header utility, you'll see there's now options to flag individual YM2151, and [email protected]

[7800basic beta, the release thread]

Yeah, I'm afraid not at this time. In theory it's possible, so I need to think about what that interface looks like, and code it in.

[7800basic beta, the release thread]

18 minutes ago, Karl G said:

 

Thank you! Regarding the first method, the two sprites you would plot would be the sprite to be covered, and the covering sprite, in that order? How does one plot a sprite offscreen? Something like X >= 160?

Actually, it should just be the one sprite - not two like I originally said - since the top one doesn't need to get inserted into the background.

 

And correct, you can hide the sprites in the X area > 160.

 

Thanks for the kind words on the demo. Nobody likes it when you get stuck on the corner of a tile.

[7800basic beta, the release thread]

Thanks RT!

[7800basic beta, the release thread]

Yeah, not really a good clean way to do that. The plot* commands build the underlying display lists that Maria parses, and it does them in object order.

 

You could kind of get away with what you're talking about by plotting 2 off-screen hidden sprites in every zone wherever you need them, and then manually replace them with something like "under the hood", but it's kind of ugly.

 

If it's for minor z-masking, you can try plotting another copy of the underneath-object over top of the sprite you want to block. I tried this out a while back, with success. It's a bit complicated too, but less under-the-hood.

 

occlude.bas.bin occlude.bas.a78 occlude.bas

 

[hitting TIA WSYNC in 7800 mode (a pointless curiosity)]

32 minutes ago, Jinks said:

Ok here is the stupid question of the day. Could there be a game that switches between 2600 and 7800 for different levels? 

For starters it would need to be a 7800 game - meaning it would need to have 7800 cart pins and pass the ntsc encryption check. After that, it can sort-of do 2600 mode, but very badly.

 

The INPTCTRL register is used (among other things) to lock a game into 7800 or 2600 mode, until power is removed from the console. For 2600 games the 7800 bios has already locked in 2600 mode, but if a game is detected as 7800, then the bios leaves INPTCTRL unlocked, and the game can freely switch between modes. That sounds great, but there's one big ugly wrinkle - both TIA and INPTCTRL cover the same register range, so until the console mode is locked in, writing to INPTCTRL writes to the TIA and visa versa. The upshot is, you can't really do TIA graphics and such until you lock into 2600 mode, which then means you can't go back to 7800 mode.

[hitting TIA WSYNC in 7800 mode (a pointless curiosity)]

Apparently both the TIA and Maria WSYNC registers both work to wait for sync in 7800 mode. The interesting thing is, both chips have their own horizontal sync and counters, which are running in parallel.

 

I put together a quick little demo that shows a few color bars drawn with the background color and each kind of WSYNC. Basically the idea is hit WSYNC, change the color, wait for 40 cycles, and then change the color back to black.

 

At the start of the TIA WSYNC rectangle, I need to hit RSYNC, so TIA begins the bars aligned with Maria, and drifts more after each line.

 

 

 

 

Apologies for the crap photo, but it's better than none, which was the choice.

 

Interestingly the TIA line is longer, despite running at Maria speeds for most of the line. On the occasional run of the program, the TIA bar alignment flickers badly. I think the free running TIA sync gets messed up if you hit RSYNC on a particular cycle. Maybe.

 

I don't think there's anything of practical of use here (hence "pointless curiosity") but I thought it was kind of fun to have a peek at TIA's video generation going on behind the scenes.

tiamariasync.bas.a78 tiamariasync.bas.bin