My ROM Works!

[ZeroByte]

Yaknow, Atari2600 might be doable because of how Stella worked. You’d have to be a mad genius of cycle exact coding though, because the 2600 was all about timing your code.

[SlithyMatt]

1 hour ago, ZeroByte said:

Yaknow, Atari2600 might be doable because of how Stella worked. You’d have to be a mad genius of cycle exact coding though, because the 2600 was all about timing your code.

Not at full speed, but you could get some kind of emulation. Might work better to have the X16 transpile the 2600 ROM into a more native format -- convert all the TIA and RIOT load/stores to library subroutine calls.

[ZeroByte]

1 hour ago, SlithyMatt said:

Might work better to have the X16 transpile the 2600 ROM into a more native format --

That's exactly what I was thinking. Make the loader go through and modify addresses as needed, etc. One thing I'd thought of would be to load the ROM to BANKRAM so that any carts which do bank swapping would actually behave the same way w/o any real work on the part of the X16. I hadn't thought of hooking TIA/RIOT with subroutine calls. That's a clever idea.

I was thinking that since there're only a few graphic primatives that pretty much only exist in X coordinate space in TIA, it might be doable by using layers and scroll registers to set the X location...

[SlithyMatt]

12 minutes ago, ZeroByte said:

scroll registers to set the X location

scroll registers won't help with the X location, that just going to have to be sprite placement. You can't have multiple scroll X-coordinates on the same line. This will be the hardest part -- converting the delays for X positioning. You'd have to analyze the code to determine when those X-placement TIA writes relative to the last known line start, then convert that into sprite X coordinates. Same with the Y -- count the lines for TIA writes and convert that into Y positioning and row data. Doing all this conversion on the X16 would be intense, but doable if you're patient for the transpiler to spend some time doing its conversion before running the ROM. If you just did the conversion on a modern PC, it would be instantaneous and you would have an X16 program that you could just load and run.

[ZeroByte]

49 minutes ago, SlithyMatt said:

You can't have multiple scroll X-coordinates on the same line.

True, but I was thinking something along the lines of using both layers where L0 = sprite0 and L1 = sprite1, having only one tile in the top-left of each layer's tilemap, and writes to the sprite data register just re-write the first byte of the tile pixel map (which, conveniently, is just a single write because it's 1bpp) - not saying this is the best way at all - it's just what the idea was floating around in my head.

Doubling or tripling sprites would just amount to putting 1 into a couple more tile slots (unless the spacing is variable, which I think it isn't).

I'd use sprites for the ball and missiles - but thinking of it now, it seems using VERA sprites for the TIA sprites is the way to go anyway, because the tilemap is much more suited to emulating the playfield.

It's crazy to think about writing a general-purpose algorithm to analyze a VCS game's kernal(s) and generate code that "just shows it" on VERA, but that's probably the best way to go.