Great Exploitations

I've been thinking about this sort of thing also. With RESPx, you spend most of the scanline waiting. If you knew exactly when to hit it, then you can fill up the rest of the scanline with meaningful work.

 

But your technique sounds like a lot of wasted space.

 

Why not do it on the Supercharger and replace at least some of the repetition with self-modifying code?

I remember old [stella] discussions regarding such techniques. IIRC Erik Moneys rrampage demo works like that.

I've been thinking about this sort of thing also. With RESPx, you spend most of the scanline waiting. If you knew exactly when to hit it, then you can fill up the rest of the scanline with meaningful work.

 

But your technique sounds like a lot of wasted space.

 

Why not do it on the Supercharger and replace at least some of the repetition with self-modifying code?

That would save some space, most notably the 3 pages of JSR's wouldn't be needed, direct jumps could be used and you could use immediate loads for much of it, but you would still need 11-12 mini-kernels to copy in, since these would be unique enough that they couldn't be generated by an algorithm.

I remember old [stella] discussions regarding such techniques. IIRC Erik Moneys rrampage demo works like that.

*Looks* yes, it does - it makes me wonder if any of us late-comers to the 2600 scene have actually thought of anything new or just rehashed old ideas? However, it does appear that rrampage doesn't use the playfield, so maybe the JSR trick is the best way to hit a RESP0 while hitting PF2 at 48. A BRK would work too, but would require more cycles, and would also write to PF1. At least, I can't think of any other way to hit PF2 at 48 and also hit RESP0 between cycle 46 and 50.

*Looks* yes, it does - it makes me wonder if any of us late-comers to the 2600 scene have actually thought of anything new or just rehashed old ideas?

 

Hm... well, old ideas sitting around is one thing, making real use of them is another

 

Very recently I was pretty surprised that my plans of turning the VCS into a MIDI instrument are 5 years old already. A workmate of mine had asked me wether I had some idea for him for a small microcontroller project, so I explained him the plan I had back then and dug out the old [stella] discussion for him. He said he'll have a look during the holidays, so maybe something gets on the way after all those years. Either that or it'll sit and wait there for another 5 years

 

One thing I need to try some day is horizontal softscrolling. I know someone on [stella] once reported an effect like that, and if I ever find the time I'll dig it out and give it a try

 

Same with linking two consoles via the joystick ports. It's all there... waiting...

Same with linking two consoles via the joystick ports. It's all there... waiting...

I want to do that too, but the need for two consoles, two televisions, two programmable carts and a custom-made cable has prevented me from bothering with it.

Last time I wanted to do it for this one

 

I think Eric also wanted to try it for a 2 player skeleton and I think Simon once bought a Zero Tolerance cable to see wether it could be used for linking the 2600 as well. IIRC he thought to do a Battleships type game.

Very recently I was pretty surprised that my plans of turning the VCS into a MIDI instrument are 5 years old already. A workmate of mine had asked me wether I had some idea for him for a small microcontroller project, so I explained him the plan I had back then and dug out the old [stella] discussion for him. He said he'll have a look during the holidays, so maybe something gets on the way after all those years. Either that or it'll sit and wait there for another 5 years

 

One of the Chimera dongles is a PC gameport w/MIDI. I was going to hit up Paul Slocum to work on the VCS end of this when we get something up and running. It might even make for a nice built-in application since it should be pretty small.

Same with linking two consoles via the joystick ports. It's all there... waiting...

I want to do that too, but the need for two consoles, two televisions, two programmable carts and a custom-made cable has prevented me from bothering with it.

 

That's where the internet comes into play.

 

The bottom line, though, is serial input on the VCS is slow and it really eats into your VBLANK time that could be better spent on the rest of the game. I don't think you'd get much in the way of results without having the serial port exposed as a byte-stream through a hotspot like Chimera does it.

The bottom line, though, is serial input on the VCS is slow and it really eats into your VBLANK time that could be better spent on the rest of the game. I don't think you'd get much in the way of results without having the serial port exposed as a byte-stream through a hotspot like Chimera does it.

 

In one sentence, the core plan was to trigger a synchronized start on both consoles, then simply pass through the joystick bits each frame, just as if it was connected on the other console straight. Same input = same output.

At least, I can't think of any other way to hit PF2 at 48 and also hit RESP0 between cycle 46 and 50.

 

If you don't mind needing two lines for repositioning, you can simplify things greatly. Then you only need six spots where you can hit RESPx and the cycles around 48 won't be a problem.

At least, I can't think of any other way to hit PF2 at 48 and also hit RESP0 between cycle 46 and 50.

 

If you don't mind needing two lines for repositioning, you can simplify things greatly. Then you only need six spots where you can hit RESPx and the cycles around 48 won't be a problem.

That's a good idea. 3 pages of JSR's did seem really clunky.

[T]he PF2 write must occur at 48.

I overlooked this before. Are you writing at cycle 48 because of mirrored symmetry? Have you looked at my chess kernel to see how I did a 32 pixel playfield with a transposed PF, six loads,only four stores, and flexible timing for PF updates?

[T]he PF2 write must occur at 48.

I overlooked this before. Are you writing at cycle 48 because of mirrored symmetry? Have you looked at my chess kernel to see how I did a 32 pixel playfield with a transposed PF, six loads,only four stores, and flexible timing for PF updates?

Yes, I want to do a mirrored PF. So does yours work like a mirrored PF without the fixed PF2 write?

Yes, I want to do a mirrored PF. So does yours work like a mirrored PF without the fixed PF2 write?

Basically, except the PF is not mirrored. Basically X is set to $0F and is used to clear PF0_left. Then you load and store PF1_left, PF2_left, and PF1_right as usual. Then load a byte to A with PF0_right in the high nybble and PF2_right in low. Sta to PF0_right, and sax to PF2_right.

 

I got it backwards - it's six stores and four loads, assuming you don't need to change X.

 

See the blog entry if you want an example. It took me a long time to work out this scheme, and I couldn't have done chess without it.