New game Breakout, assembly breaking out of the basic sandbox

[SteveB]

9 minutes ago, OLD CS1 said:

I saved the program to a FIAD disk in Classic99, then used CS1er to convert it to a wav file.

Thank you! I didn't know that CS1er works this way as well. I always thought this and tape994a are only for reading WAV files... On my setup tape994a had better results, so I used this for my old tapes and not explored all options of CS1er ..  But who else to as than OLD CS1 for cassette topics...

 

[+OLD CS1]

Really neat this has to fit in the BASIC's VDP space, and runs in ~200 byte chunks. Takes some planning to make that happen.

[Tursi]

I really would like to do something with it myself someday... it's such a cool thing that would have really made an impact back in the day. For some reason I keep thinking Donkey Kong, cause it reminds me of loading Donkey Kong off tape on my friend's Coco2. For some reason that really impressed me. But since we already have DK, maybe some other arcade game...

 

Been trying to think about ways to stretch it too. Obviously you can also use code from the ROMs if any of it is useful... though I think the amount that is, is dubious. But any help is probably worth it, since you're limited to less than 16k (how much less? Is it around 12k?)

 

Also thinking it's worth keeping a little CPU RAM free for use as a copy buffer to speed up VDP-to-VDP copies, 8 bytes is enough but 16 bytes feels like the sweet spot. 

 

Maybe it's kind of personal for me... back in the day I was asked by our local TI user group in Summerland to produce something to show what was possible on a stock console, and all I came up with was a little color-swapping TI BASIC demo. Playground would have been so much better.

 

[Retrospect]

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?

[Eric Lafortune]

@Tursi Thanks!

 

I've scanned the console ROMs for useful subroutines indeed. Surprisingly, there aren't that many subroutines, and none seem generally useful. I had expected that the usual small building blocks for accessing VDP, GROM, etc. would be there, but it's all entangled (and not always very efficient).

 

The game has 21 blocks of assembly code, with sometimes only 0, 8, or 10 bytes unused in the scratchpad RAM. Swapping in code is taking up most of the processing time, so it's important to keep tight loops in a single block of code -- 16 bytes are precious! One of the graphics initialization code blocks does use a temporary buffer of 64 bytes for VDP-to-VDP copying (patterns, colors,...). The blocks of the main game loop share 16 bytes for sprite motion data.

 

@Retrospect That's a good question! I wasn't aware of the jailbreak at the time, but I haven't used any other new information. It's just standard assembly, VDP, sound, etc. The development tools are a different matter. Fast computers, linux, xdt99, and emulators make development orders of magnitude more convenient and faster. Programming with Mini Memory and a tape recorder was an exercise in patience and persistence back then, but this would have been a new level.

[+OLD CS1]

35 minutes ago, 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?

The concept was originally described in 1984.  I am not familiar enough with enough of the development tools available at the time for hobbyists, but where there is a will there is a way.  I suspect fortitude and ingenuity was in enough supply at the time to make it work.  I mean, @Tursi can whip up an impromptu program for a TI Faire using EasyBug... I seen some stuff, my friend, and I believe it could have been possible.

[senior_falcon]

13 hours ago, OLD CS1 said:

I saved the program to a FIAD disk in Classic99, then used CS1er to convert it to a wav file.  From there you can use your computer or phone to play into the cassette port (takes some jiggering as most audio outputs have a maximum volume to prevent ear damage.)  You can also load the resulting wav into Classic99.

 

Here is the TIFILES extract from the disk, as well as my converted wav file. BREAKOUT.zip

This works for me in Classic99 as well as on my real console.

This does not work for me using Classic99. I get the usual "STRING NUMBER MISMATCH IN 0"

I tried it in Win994a with better results. The title screen started but no key was active except the spacebar which crashed the program. I'm guessing this is a problem with the emulator - some incompatibility between how Eric implemented the keyboard scanning and how Cory did it in Win994a.

[Tursi]

3 hours ago, 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?

Definitely possible by the 90s anyway.. the bug is on full display in TI Intern, just never read it correctly.

 

We know people saw the crash bug in the 80s (Rich mentioned it, for instance), but there was less of a jailbreak mentality back then (for any system)... today people see a crash and think "if I can crash that the right way..."

 

3 hours ago, Eric Lafortune said:

I've scanned the console ROMs for useful subroutines indeed. Surprisingly, there aren't that many subroutines, and none seem generally useful. I had expected that the usual small building blocks for accessing VDP, GROM, etc. would be there, but it's all entangled (and not always very efficient).

Yeah, I have a doc where I've done similar. The ROM was clearly written with a single purpose in mind.

 

Good point about how crazy actually /developing/ in this manner would have been back then, though.

 

[Tursi]

43 minutes ago, senior_falcon said:

This does not work for me using Classic99. I get the usual "STRING NUMBER MISMATCH IN 0"

I tried it in Win994a with better results. The title screen started but no key was active except the spacebar which crashed the program. I'm guessing this is a problem with the emulator - some incompatibility between how Eric implemented the keyboard scanning and how Cory did it in Win994a.

I re-downloaded and it is working fine here on 399.053.

 

Maybe you have an unusual disk configuration setting that is getting confused?

 

 

I tested with and without TI disk controller enabled, as well as both the DSK image and the TIFILES file.

Setting top of VRAM to >37D7 (3 files)
Loading to VDP >0713 DSK0.BREAKOUT on drive type FIAD
Detected d:\classic99\dsk1\BREAKOUT as a TIFILES file
loading 0x10B8 bytes

 

Do you get the same issue from the wave file? (That would bypass the disk config. Unfortunately it did not load in overdrive for me - that used to work!). But it's not terribly long.

 

[+OLD CS1]

1 hour ago, senior_falcon said:

This does not work for me using Classic99.

What version?

 

Never mind... already asked...

[senior_falcon]

Thinking it might be my use of an older version of Classic99, I downloaded version 399.053

When this starts there is an added line at the startup menu saying CF7+ INSTALLED

I was a good boy and looked in the manual but there is no information on this or how to eliminate it.

This should be an option, not default!

 

[+OLD CS1]

14 minutes ago, senior_falcon said:

When this starts there is an added line at the startup menu saying CF7+ INSTALLED

I was a good boy and looked in the manual but there is no information on this or how to eliminate it.

This should be an option, not default!

It looks like a Classic99.ini option, and requires a CF7 BIOS... which I do not have so have never seen that message.

[Tursi]

10 minutes ago, senior_falcon said:

Thinking it might be my use of an older version of Classic99, I downloaded version 399.053

When this starts there is an added line at the startup menu saying CF7+ INSTALLED

I was a good boy and looked in the manual but there is no information on this or how to eliminate it.

This should be an option, not default!

It is an option, and it's not default. At some point you installed it. Instructions for how were only ever published here on AtariAge, and the ROM is not included, so you also obtained that!  

 

Open your Classic99.ini and find the [CF7] section. The presence of an entry for BIOS triggers the emulation -- and the message you are seeing is coming from the ROM itself, not from Classic99. Just comment out the BIOS line and the CF7 goes away.

 

A quick test here confirms that the game doesn't work when the CF7 is loaded, though I get BAD LINE NUMBER. So VDP layout matters. Not sure why you didn't see the CF7 line on the title page before you updated, but it seems likely that's the culprit.

 

 

[Tursi]

I did a quick test, and confirmed the game doesn't work if CALL FILES is used to change the VDP layout as well (anything but 3). I didn't dig deeply into how the trick works - is this because the program no longer loads at the expected address?

 

It's not a big deal for CALL FILES, but the CF7 steals an extra 6 bytes, and that knocks things out of whack. (edit: and more than that, apparently, since I tried rebuilding it with an offset )

 

Edited January 6, 2022 by Tursi

[senior_falcon]

After commenting out only the BIOS line Classic99 starts up as expected. I was commenting out 3 consecutive lines starting with the BIOS, and Classic99 thoughtfully restored them when I restarted it.

So now, with the new version BREAKOUT works fine, when you disregard my ineptness at playing it.

I should add that it will not run with the older versions I tried, even with the CF7 BIOS change.

I have PM'd Eric with the information he needs to be able to load with the CF7, CALL FILES(1) or plain console and cassette.

Edited January 6, 2022 by senior_falcon

[+OLD CS1]

Ooooh, you know... I did not test on my console without an FDC attached.  Have to put that on my TODO list for tomorrow.

[Eric Lafortune]

My version of the jailbreak is very sensitive to the VDP memory layout in TI BASIC. It expects the FDC to set up the "CALL FILES" memory buffers. I should have documented this, sorry. The program requires a small change if it's to be loaded on a system without a FDC.

 

The OPEN overflow bug calls GPL COPY, which overwrites bytes starting in at >834a. I let it write new bytes in the active register workspace at >83e0. It then overwrites a register with a branch address that the GPL COPY instruction is using. This gets me immediate control, without ever returning to GPL. I do need to carefully preserve a register with a VDP offset before getting there. Admittedly, the original version of the jailbreak that overwrites the address of the interrupt routine at >83c4 and waits for an interrupt doesn't have this problem. Directly seizing control seemed like a nice touch; just my personal preference.

[+Vorticon]

12 hours ago, OLD CS1 said:

I mean, @Tursi can whip up an impromptu program for a TI Faire using EasyBug... 

Yes indeed. He saved my butt when I was planning to do the robot arm demo and had forgotten to pack my driver disk, so he helped me whip up a quick and dirty direct control driver using Mini Memory something like half an hour before my scheduled demo! One for the books he he...

[+Lee Stewart]

10 hours ago, Tursi said:

I did a quick test, and confirmed the game doesn't work if CALL FILES is used to change the VDP layout as well (anything but 3). I didn't dig deeply into how the trick works - is this because the program no longer loads at the expected address?

 

It's not a big deal for CALL FILES, but the CF7 steals an extra 6 bytes, and that knocks things out of whack. (edit: and more than that, apparently, since I tried rebuilding it with an offset )

 

 

It is 8 bytes. The CF7/nanoPEB puts its magic number (>AA03) at >3FF8 and uses the remaining 6 bytes for the DSK1 – DSK3 CF-volume numbers.

 

...lee

[+OLD CS1]

7 hours ago, Eric Lafortune said:

My version of the jailbreak is very sensitive to the VDP memory layout in TI BASIC. It expects the FDC to set up the "CALL FILES" memory buffers. I should have documented this, sorry. The program requires a small change if it's to be loaded on a system without a FDC.

Ah, so no sense in trying a bare console with the tape drive, then.

 

This does give me an idea, though.  Regarding the MiniMemory on a bare console.  It may be easy enough to load a game into 4k RAM using EasyBug (is it, though?)  But a loader which runs in TI BASIC would be better.  Instead of an instruction manual which tells you how to load a tape into RAM, &c. one could produce a TI BASIC program which copies its payload into >7000 then executes it.

[Tursi]

11 hours ago, senior_falcon said:

After commenting out only the BIOS line Classic99 starts up as expected. I was commenting out 3 consecutive lines starting with the BIOS, and Classic99 thoughtfully restored them when I restarted it.

So now, with the new version BREAKOUT works fine, when you disregard my ineptness at playing it.

I should add that it will not run with the older versions I tried, even with the CF7 BIOS change.

I have PM'd Eric with the information he needs to be able to load with the CF7, CALL FILES(1) or plain console and cassette.

Yes, Classic99 writes out all fields when it saves the INI file. A commented line is not visible to the emulator, so it will rewrite it with the default setting.

 

I'm a little curious about it not working with older versions of Classic99, since nothing in the emulation should be affecting the amount of free VRAM (unless we are going back multiples of years, perhaps, to before I started realizing that mattered). But at the same time I've no easy way to test it and it's probably not important overall - what's important is noting that the game is pretty sensitive to VRAM layout.

 

[Tursi]

1 hour ago, Lee Stewart said:

It is 8 bytes. The CF7/nanoPEB puts its magic number (>AA03) at >3FF8 and uses the remaining 6 bytes for the DSK1 – DSK3 CF-volume numbers.

Ahhh, that explains a lot. I rebuilt with an 8 byte offset and then it did work with the CF7 loaded.

 

[senior_falcon]

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

 

(removed the program)

 

OLDCS1 reports that this doesn't work with a cassette. I have another idea that might work, but not too optimistic.

 

Edited January 8, 2022 by senior_falcon

[jrhodes]

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

[HOME AUTOMATION]

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

 

 ...Qapla!