Stella Training Manual

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

JetSetIlly

https://github.com/JetSetIlly/Gopher2600
@JetSetIlly@mastodon.gamedev.place
@jetsetilly.bsky.social

JetSetIlly

Reading through Unit 1 of the manual and I have some questions:

QuotePage 7: "The development station does not enter programs at FFFC like the VCS does as power-up, it enters the first execuable address, for example F000. Therefore the first instruction at F000 should be a jump to the initializing routine". The VCS automatically jumps to the address at power-up. In this way the code will jump to the initializing routine first for both the development station and the VCS."

What was the development station and are there any ROMs that retain the JMP at F000?


QuotePage 10: "[...] the system has an anomoly that if RAM is zeroed from the high
addresses to the low addresses the system can lock up (This will happen if the
store to VSYNC happens at cycle 76 in a scanline)."

Is this on the development machine only? I've never heard of this problem before.


https://github.com/JetSetIlly/Gopher2600
@JetSetIlly@mastodon.gamedev.place
@jetsetilly.bsky.social

alex_79

Quote from: JetSetIlly on 01 Jul 2024, 06:47 PMNew scan of the Stella Training Manual. I'm amazed I've never seen this before.

https://forums.atariage.com/topic/368057-has-the-stella-training-manual-been-scanned-edit-scan-is-now-attached-in-thread/?do=findComment&comment=5494025
That's a very cool piece of history!
I'd like to see some of the documents mentioned in the "RELATED READING" sections surface someday as well, such as the "Stella Packages" ones.

Quote from: JetSetIlly on 01 Jul 2024, 07:24 PMare there any ROMs that retain the JMP at F000?

Just had a quick look at a few games and I found:

Missile Command (jmp f03f - reset vector is f000)
Adventure (jmp f2ef - res. vec. f000)
Super Breakout (jmp f46e - res. vec. f46e)

Others, such as Pac-man, just have the init routine at F000, so they wouldn't need the jmp instruction for the dev system.
Quote from: JetSetIlly on 01 Jul 2024, 07:24 PM
QuotePage 10: "[...] the system has an anomoly that if RAM is zeroed from the high
addresses to the low addresses the system can lock up (This will happen if the
store to VSYNC happens at cycle 76 in a scanline)."

Is this on the development machine only? I've never heard of this problem before.

I'm quite sure it is indeed only an issue with the development machine, which apparently had ways to check "frame timing" as mentioned in the introduction, so it probably had hardware to monitor the SYNC signals from the TIA.

Also note the comment on the "SEI" instruction in the example INIT code on page 10: "necessary for keyboard input"; that's also referred to the dev system, as for a 2600 game you don't need to set the disable interrupt flag because
1 - it is set automatically by the 650x reset sequence
2 - on a 6507 the hardware interrupts are disabled (the IRQ and NMI pads are tied to +5V in the chip die), so the flag has no practical effect in any case.

JetSetIlly

Quote from: alex_79 on 02 Jul 2024, 12:34 AMJust had a quick look at a few games and I found:

Missile Command (jmp f03f - reset vector is f000)
Adventure (jmp f2ef - res. vec. f000)
Super Breakout (jmp f46e - res. vec. f46e)

Others, such as Pac-man, just have the init routine at F000, so they wouldn't need the jmp instruction for the dev system.

Excellent. I was going to write a tool to scan all my ROMs to see if I could find any matches. I find it interesting because it would provide some indication of who used the "development machine".

Quote from: alex_79 on 02 Jul 2024, 12:34 AMAlso note the comment on the "SEI" instruction in the example INIT code on page 10: "necessary for keyboard input"; that's also referred to the dev system, as for a 2600 game you don't need to set the disable interrupt flag because
Right. So the development machine used a 6502 rather than a 6507. Make sense.
https://github.com/JetSetIlly/Gopher2600
@JetSetIlly@mastodon.gamedev.place
@jetsetilly.bsky.social

Thomas Jentzsch

#4
Quote from: JetSetIlly on 02 Jul 2024, 04:54 AMExcellent. I was going to write a tool to scan all my ROMs to see if I could find any matches. I find it interesting because it would provide some indication of who used the "development machine".
I had the same idea. I suppose you will also find bankswitched ROMs, which have a bankswitch at 0xf000.

Quote
Quote from: alex_79 on 02 Jul 2024, 12:34 AMAlso note the comment on the "SEI" instruction in the example INIT code on page 10: "necessary for keyboard input"; that's also referred to the dev system, as for a 2600 game you don't need to set the disable interrupt flag because
Right. So the development machine used a 6502 rather than a 6507. Make sense.
That should help verifying the results.

More obvious games I found
- 3D Tic Tac Toe
- Berzerk
- Bionic Breakthrough
- Crossbow
- Dodge 'Em
- E.T

Most 4K games start at 0xf000 and use SEI.

BTW: With these limitations, the development machine wouldn't work for SuperChip games.

JetSetIlly

Quote from: JetSetIlly on 02 Jul 2024, 04:54 AMExcellent. I was going to write a tool to scan all my ROMs to see if I could find any matches. I find it interesting because it would provide some indication of who used the "development machine".

I've written a tool (using Gopher2600 as a library) to search through all files in the Rom Hunter's v19 archive.

I looked for the JMP instruction at address F000 once the ROM was loaded. I made the assumption that this was a JMP to the initialisation routine. We could narrow it down by checking that either (a) the JMP address is the same as the reset address or (b) the reset address is F000. But I don't suppose there are many, if any, false positives.

For posterity, I've put the results in a Google Sheet:

https://docs.google.com/spreadsheets/d/1kG7zKpy6gYiAc4fe_1MxfDuJhWP60BUIyDmdLpaEM64/edit?usp=sharing

I've filtered out duplicates by ignoring any file with an MD5 that has already been seen.
https://github.com/JetSetIlly/Gopher2600
@JetSetIlly@mastodon.gamedev.place
@jetsetilly.bsky.social

alex_79

#6
Quote from: Thomas Jentzsch on 02 Jul 2024, 05:17 AMBTW: With these limitations, the development machine wouldn't work for SuperChip games.

If the binary was loaded in ram, and the 6502 in the dev system had full r/w access to it, then they could test SARA games by assembling a slightly modified binary that relocated writes to SARA to $f080-$f0ff, that is using the same address for read and write.

This was also the method suggested for the "2600/7800 development kit" available a few years later, which consisted in a special cartridge that plugged in an 7800 console and connected to an ST computer. It was really designed for 7800 development, but could be used for 2600 games with some caveats, such as this one for SARA games.

JetSetIlly

I've OCRd the PDF so it's now searchable

https://forums.atariage.com/topic/368057-has-the-stella-training-manual-been-scanned-edit-scan-is-now-attached-in-thread/?do=findComment&comment=5494637

Couple of other things I noticed in the text:

The VDEL graphics register are referred to DGRP0 and DRGP1. I like that. I'll start using that convention.

There is specific mention that the RSYNC is used only for testing of the TIA chip. There was never any intention for it to be used for anything else. I think we suspected this but I've never seen it written down explicitly that is its only purpose. The full paragraph dealing with RSYNC:

"RSYNC is register not used in game design. Instead it is used by Carl Neilson's group in the LSI testing of the TIA chip. It causes the HSYNC signals to be scrambled, shearing the picture horizontally. After a few scan-lines have passed the HSYNC signals realign and the picture returns to its normal state."

I'd like to know more about Carl Neilson's group and what they did during testing.

https://github.com/JetSetIlly/Gopher2600
@JetSetIlly@mastodon.gamedev.place
@jetsetilly.bsky.social