New game Breakout, assembly breaking out of the basic sandbox

[senior_falcon]

2 hours ago, jrhodes said:

I'm just waiting for a new version with improved controls.

Yes, I seem to be having trouble training my fingers. S and D are often used for left and right and maybe A and F could be fast left and fast right. The TI keyboard even has the arrows on the S and D.

I think that would work for me.

 

Edited January 8, 2022 by senior_falcon

[+OLD CS1]

3 hours ago, senior_falcon said:

This should do the trick. It works with CALL FILES(1) and CALL FILES(2) and should work with a plain cassette with no disk drive.

This is not a very elegant solution, but it works. At startup I look at >8330 to find out where the BASIC program starts, then relocate it so it is placed in the normal location when using a standard disk controller and 3 disk files

If you have a CF7, you will have to do a CALL FILES(1) or CALL FILES(2), then OLD DSK1.BREAKOUTX

 

Just tried this on a bare console with just a tape deck.  It gives me a long beep and hangs.

[senior_falcon]

Well drat. Let me try it here.

(edit)

I don't know how to test this. Neither the original nor my modified version of this will run on Win994a. I do get the title screen when loading from a disk but it crashes when I press a key. if I do CALL FILES(1), I can load the original program but it just crashes. But the modified program behaves the same in that it gets to the title screen.

I loaded the program from disk and saved it to a virtual cassette. I can OLD CS1 and RUN and it shows the title screen and behaves just like the modified disk version.

Can you run either the original or the modified program using a disk system on a real TI?

 

Edited January 8, 2022 by senior_falcon

[senior_falcon]

3 hours ago, HOME AUTOMATION said:

Saved to TAPE in win994a, then re-loaded...

 

 ...Qapla!

Can you get past the title screen on Win994a?

[HOME AUTOMATION]

Froze-up.?

 

D'oh

[+OLD CS1]

41 minutes ago, senior_falcon said:

Can you run either the original or the modified program using a disk system on a real TI?

The original release works on my real TI, but only with an FDC attached.

[senior_falcon]

12 minutes ago, OLD CS1 said:

The original release works on my real TI, but only with an FDC attached.

Does the modified version work on a real TI when read from disk?

If you do CALL FILES(1) and then load the modified version does it work?

[+OLD CS1]

23 minutes ago, senior_falcon said:

Does the modified version work on a real TI when read from disk?

If you do CALL FILES(1) and then load the modified version does it work?

No in both cases.  Now, I also have a WHT SCSI and a non-TI FDC, so I have no idea what that might do to VDP buffers, if anything.

[senior_falcon]

Mystery to me, grasshopper. I don't know why there would be a difference.

[senior_falcon]

@OLD CS1 - can you put the E/A or MiniMemory cartridge in the slot.

CALL PEEK(-31952,A,B)

PRINT A,B   prints the address of the beginning of the program.

Type OLD DSK1.BREAKOUT and find the address with the CALL PEEK.

Then OLD DSK1.BREAKOUTX and find the address

CALL FILES(1) and then load BREAKOUT and BREAKOUTX and find the addresses.

And report A and B for the 4 different configurations

 

Can anyone with the ability to do this using a plain jane TI controller please check whether BREAKOUTX works when loaded from cassette.

 

Finally, I would be interested in knowing if the attached program works from cassette.

 

SCOLORSBX

[+OLD CS1]

@senior_falcon  Would you believe that during these tests my TI program recorder bit the dust??  Here are some extra results, as well.  Note that right now I only have BREAKOUTX on tape.

 

No program loaded

MiniMemory w/FDC and WHT SCSI: 55, 215

MiniMemory bare console: 63, 255

E/A w/FDC and WHT SCSI: 55, 215

E/A bare console: 63, 255

 

OLDing BREAKOUT

MiniMemory w/FDC and WHT SCSI: 39, 40

E/A w/FDC and WHT SCSI: 39, 40

 

OLDing BREAKOUTX

MiniMemory w/FDC and WHT SCSI: 39, 40

MiniMemory bare console: 47, 80

E/A w/FDC and WHT SCSI: 39, 40

E/A bare console: 47, 80

 

Going to take a minute or two on the SCOLORSBX file as I rejigger for the dead tape drive.

[+OLD CS1]

1 hour ago, senior_falcon said:

Finally, I would be interested in knowing if the attached program works from cassette.

SCOLORSBX works from tape on a bare console, as well as with the FDC.

[senior_falcon]

Thank you for checking that. There is no difference in the VDP areas, so BREAKOUTX should work with a cassette. I don't know what the difference is between a real TI and Classic99, but since it doesn't work  I have amended my earlier post and removed the program.

I have one more idea to try, which won't take long. That will either work or not.

Good to verify that at least my programs will work with cassette.

Edited January 8, 2022 by senior_falcon

[Tursi]

2 hours ago, senior_falcon said:

Thank you for checking that. There is no difference in the VDP areas, so BREAKOUTX should work with a cassette. I don't know what the difference is between a real TI and Classic99

If you discover what it is, please let me know so I can eliminate it.

[Eric Lafortune]

I've just released Breakout v1.1 based on your feedback. These are the changes:

* Automatic jailbreak support for systems with NanoPEB/CF7+. Thanks to @senior_falcon and @Tursi for pointing out the issues.

* Compile-time jailbreak support for systems with just a cassette tape player. Thanks to @OLD CS1 for keeping me on my toes.

* Changed keys to z x , . Thanks to @jrhodes and @OLD CS1 for reminding me of the layout of the actual keyboard.

* Added support for the Mechatronic mouse. Thanks to @mizapf for emulating it in Mame. Cool! I don't think standard joystick support would add much.

* Now also building and providing a TIFILES version.

 

You can find the latest source code and binaries on Github. Enjoy!

[senior_falcon]

On 1/8/2022 at 7:44 PM, Tursi said:

If you discover what it is, please let me know so I can eliminate it.

I think the problem is simple. I believe I was overrunning the VDP.  I was setting the VDP address to read from, then immediately reading the byte without an instruction such as NOP. Remember that this is running on the 16 bit bus. Grrr.

[Tursi]

18 hours ago, senior_falcon said:

I think the problem is simple. I believe I was overrunning the VDP.  I was setting the VDP address to read from, then immediately reading the byte without an instruction such as NOP. Remember that this is running on the 16 bit bus. Grrr.

Yeah... this is a tricky one to do in emulation. I tried putting in a warning in the past, and people hated it (even though it was technically right! ). To do it correctly, you need to emulate each cycle of the VDPs memory access, AND it needs to be done in sync with the CPU operation. Since emulation needs to batch functions up to achieve decent performance, it's pretty tough to do. My previous attempt just timed how long between CPU accesses, and that should have been adequate in theory, but... hmm. It's not only the time between accesses, but exactly WHEN those accesses occurred. So something could work for a very long time on hardware if everything lined up just right, even when the access IS too fast to be 100% reliable. If you manage to set the address register RIGHT before a CPU memory access cycle, then that data WILL be there. If you can get into perfect lockstep, then it might just work every time.

 

I will put some more thought into it for V4. I might be able to run the system in small enough chunks to be able to simulate this a little better. It's tough to balance.

[+mizapf]

14 minutes ago, Tursi said:

Yeah... this is a tricky one to do in emulation. I tried putting in a warning in the past, and people hated it (even though it was technically right! ). To do it correctly, you need to emulate each cycle of the VDPs memory access, AND it needs to be done in sync with the CPU operation.

The 99x8 emulation in MAME does not consider this timing either, but I could imagine that some day, someone might pick up that issue. This also surprised me, comparing this to the high efforts people took for emulating disk access with precise timings, but it seems too few people actually cared about that point, and the disk access was much more important (remember the complex disk protection schemes outside the TI world).

[Tursi]

5 hours ago, mizapf said:

The 99x8 emulation in MAME does not consider this timing either, but I could imagine that some day, someone might pick up that issue. This also surprised me, comparing this to the high efforts people took for emulating disk access with precise timings, but it seems too few people actually cared about that point, and the disk access was much more important (remember the complex disk protection schemes outside the TI world).

It's difficult to be correct, and generally implementations have been plagued with false positives. There's also little advantage to implementing it insofar as reproducing existing software goes. Correct emulation of this effect doesn't make any game suddenly start to work. At best, if you get it right, some software fails sometimes.

 

It's also not completely clear to me if the actual use of the VDP RAM access slots is documented officially - I don't think it is. I did see an MSX documentation effort to work it out though.

 

I don't imagine anyone will pick it up until they are looking for any remaining targets to hit... that said, I still believe that the timing approach should be accurate enough, just need to take into account more cases than I did last time.

 

 

 

Edited January 11, 2022 by Tursi

[senior_falcon]

I have tweaked the latest version, BREAKOUT 1.1 so that it works if you do CALL FILES(1) or (2). It should also be possible to load it from a cassette. (OLDCS1 tested an earlier iteration of this for me.) If you have a CF7, you will probably have to do CALL FILES(1) or (2) before you load and run the program. Thank you Eric for a really cool program.

BREAKOUT11

This can be run from Extended BASIC as well. From the Playground docs, which apply to this as well:

The BASIC program created above can be run from Extended BASIC.  If there is no memory expansion you can RUN it like any other XB program.  If there is a memory expansion, it must be turned off before running the program.  The following line of code shows how to do this:
CALL INIT :: CALL LOAD(-31868,0,0):: RUN "DSK2.PROGRAM"
This can be part of a menu driven loader program or entered while in the immediate mode.

 

[senior_falcon]

On 1/5/2022 at 6:28 PM, Retrospect said:

Would this have been possible back in the 80s?  I mean, we have the things we have now, but back then what would it have taken to get to know how to do all of this without TI releasing any sort of documentation?

Absolutely. In 1984,  Morphy used this method to load the assembly payload to scratchpad, and then set the stack pointer to return to the BASIC startup routines. It also set >83C4 to point to a short assembly routine. All the assembly routine did was reset 2 VDP registers to use sprites at locations that are accessible by BASIC with CALL COLOR and CALL CHAR, then clear >83C4.

 MG Explorer has a copyright date of 1985. That's what I always used for my debugging back in the day.

So the tools were there, and if it was generally known that you could load and start an assembly program this way from BASIC, then the rest would certainly have fallen into place naturally.

 

(edit) James Abbatiello had a different method of starting the program, but by combining his method with my own ideas, I came up with a method that is identical to that devised by the authors of Morphy almost 30 years earlier. As the good book says:

What has been will be again, what has been done will be done again; there is nothing new under the sun.
 

Edited January 15, 2022 by senior_falcon

[Eric Lafortune]

I've just released Breakout v1.2. Thanks to the enhancements of @senior_falcon, the jailbreak is location-independent now, so it runs on all hardware configurations. You can find the latest source code and binaries on Github.

 

The jailbreak still builds on the OPEN overflow bug, which overwrites a large part of the scratchpad RAM. Earlier versions on this forum overwrite the GPL return stack or replace the interrupt handler address. My version overwrites the register workspace of the GPL at >83e0. By changing the registers, it changes the data flow and some branch addresses. It then jumps directly to its own code, without ever returning to GPL, ROM, or interrupt handlers. That seems like a nice feature. V1.0 required the BASIC program code to be at a known location, v1.1 accounted for a possible 8-byte shift with a NanoPEB/CF7+, and now v1.2 accounts for any shift. @senior_falcon's enhancements let BASIC first draw some bytes in the VDP screen table, so they can be a source of data at known locations during the overflow. You can find the details and documentation in the source code of the jailbreak.

 

We haven't found a more compact way so far. I've considered BASIC code inside the line number table (too limited?), BASIC code in the string space (convoluted), and BASIC strings that straddle the symbol table and/or the line number table (impossible?). So here's the challenge: can anyone do better?

[+TheBF]

I reading the jail break code and I am in awe of the minds that discovered this. 

It makes me wonder about porting a "sector Forth" (512 bytes or so) to Breakout.

My project stack is going to overflow...

[Eric Lafortune]

In his research to improve the performance of CALL invocations, @senior_falcon found out that CALL ... works just as well as OPEN #1:"..." for the jailbreak: both statements call the DSRLNK subroutine with the overflow vulnerability. Amazing! It's a small but nice simplification. I've updated the code and the documentation of Breakout.

 

You can find the latest source code and binaries on Github. Enjoy!

[XLERB]

I too am in awe of this work. I’d seen the Tesio brothers’ technique and it was interesting, but to use it to sneak a whole assembly language game in and out of the scratchpad RAM while not requiring additional CPU or expansion memory is just jaw-dropping. Some really clever understanding of the TI’s strange GPL and BASIC infrastructure and some fancy VDP memory wrangling here.