14

The Apple ][e had 2 HiRES video pages, HiRES animation involved switching between the 2 pages and redrawing the screen. A really early way to take an in game screenshot was to dump the computer with the programmers reset and then make a 2 separate calls one to each page and write the bytes out to the disk as files. You needed to do both as there was no way to tell which page had the currently displayed image and the other was partially overwritten for its next display write.

I probably did this last in the late 80's and I can't remember how it was done. Though PEEK & POKE maybe?

I think I read how in an issue of Nibble and my feeble memory has this as the pages:

  • Page 1 : 0x2000 - 0x3FFF
  • Page 2 : 0x4000 - 0x5FFF

Once you had the pages saved you had to reboot, but then you could POKE the bytes back into a page or dump them straight into an ImageWriter to print them out.

3
  • I'm not sure how to properly assign the answer to this question since Nick's answer covered most of what I loosely recall doing to dump the pages out to disk and then write then write them back into memory after rebooting. Dale's very though answer was mostly over my head for what I was asking and he provided the printing details that finished out my question. Thoughts? Dec 2, 2016 at 21:58
  • For the site's sake it's probably better to choose an answer than let the question dangle - as long as the answers do answer your question. There are several meta questions where others have suggested some criteria that might help you. Dec 15, 2016 at 10:02
  • after reading the meta pages I gave the answer to supercat. his was the correct for saving. and the first. I never had a casette drive, the computer lab all had diskII units. The other answers have been upvoted as well. Dec 19, 2016 at 4:32

3 Answers 3

13

Under both DOS3.3 and ProDOS, BSAVE FILENAME,A$2000,L$1FF8 would do the first graphics page, and BSAVE FILENAME,A$4000,L$1FF8 would do the second page.

Hat tip to Michaelangel007 for suggesting reducing the length by 8 to save a disk block. I'd noticed screens took 34 blocks but hadn't known why.

11
  • 1
    @RowanHawkins: I don't think ProDOS loaded itself, even temporarily, into the region from $2000-$5FFF, but I'm not positive. DOS 3.3 might be a better choice. Alternatively, if you have an older model of Apple you might be able to feed the cassette output port to a modern PC's sound card and capture data that way.
    – supercat
    Nov 25, 2016 at 23:32
  • 2
    L$1FF8 uses one less sector in DOS 3.3. And ProDOS loads SYSTEM files to $2000 so the hires pages usually don't survive. Nov 26, 2016 at 9:23
  • 1
    @RowanHawkins: Otherwise what would you think of feeding the Apple's cassette port into a sound card (or cassette recorder!), and using CALL -151 followed by turning on the computer recording and using 2000.5FFFW to output the hires screens to that?
    – supercat
    Nov 27, 2016 at 16:17
  • 2
    @NickWestgate: Michaelangel007 had made an edit which was rejected but which had mentioned that and explained the reason for it, and while the edit was rejected before I saw it I wanted to offer some level of acknowledgment for the effort. I wish there was a means by which, even if other reviewers rejected an edit, the author of a post could accept it anyway.
    – supercat
    Feb 14, 2017 at 19:46
  • 1
    @RowanHawkins: The savings is a consequence of binary files being preceded by a header giving the start address and length. So a file with a requested length of $1FFC would be exactly 8192 bytes, while one with a requested length of $2000 would be 8196 bytes. The last eight bytes aren't used, so there's no practical difference between $1FF8 and $1FFC.
    – supercat
    Dec 5, 2020 at 3:50
12

There are two separate pages for text and graphics, and they can both hold separate data without overwriting each other if a program is not running.

From BASIC or the Monitor ROM, you can toggle displaying each text or graphics page without affecting what is written to them.

 

Switching Apple II display modes is done via the softswitches in page $C000. You can PEEK/POKE or LDA/STA, LDX/STX, LDY/STY these. I believe an assembly read access is slightly faster if timing is critical.

The negative BASIC values are from the old Integer BASIC which could only handle -32768 to 32767, but were supported on the newer Applesoft / Microsoft / Floating Point (FP) BASIC for compatibility. The negative values had staying power due to people who started out on Integer and later moved to Applesoft BASIC.

Switch from text to graphics mode. What you see depends on the low/hi-res mode and the mixed/full mode state:

  • POKE -16304,0
  • POKE 49232,0
  • STA $C050

Switch to text mode:

  • POKE -16303,0
  • POKE 49233,0
  • STA $C051

Switch from mixed graphics/text to full graphics:

  • POKE -16302,0
  • POKE 49234,0
  • STA $C052

Switch from full graphics to mixed graphics/text:

  • POKE -16301,0
  • POKE 49235,0
  • STA $C053

Display text/graphics page 1:

  • POKE -16300,0
  • POKE 49236,0
  • STA $C054

Display text/graphics page 2:

  • POKE -16299,0
  • POKE 49237,0
  • STA $C055

Switch to low-res graphics mode:

  • POKE -16298,0
  • POKE 49238,0
  • STA $C056

Switch to hi-res graphics mode:

  • POKE -16297,0
  • POKE 49239,0
  • STA $C057

 

Control - Open Apple - Reset writes a couple bytes of garbage all across the memory pages when it forces a full reboot. I don't remember the reason for that.

What Control - Reset did depended on the settings of the soft reset vector. Normally in BASIC this would dump you back to the BASIC prompt.

But if the soft reset vector is changed by games and programs that don't want to allow you to break out of it, Control - Reset triggers a reboot. Many games would point the reset vector to run destructive code that writes garbage across all memory before resetting. Some would just point it at their program start so you can't get out of it with Control - Reset.

$3F2 - 3F3 is the two byte JMP location of what to do next when doing a soft reset. $3F4 holds an exclusive-OR of location $3F3 with the value #$A5. If it doesn't match the system does a hard reset.

If you're running an emulator, you can switch to debug mode to change the reset vector to BF 9D 38 so you can get back to DOS 3.3, assuming the game didn't overwrite the BASIC file manager section of DOS when it loaded. (For hacking of older programs this is considered cheating. They have no defenses in an emulator.)

Refs: http://mirrors.apple2.org.za/ground.icaen.uiowa.edu/MiscInfo/Programming/poweron.monitor

 

ProDOS fully obliterates whatever was at $2000 -$5FFF when it boots. Checked this with: http://mirrors.apple2.org.za/ftp.apple.asimov.net/images/masters/prodos/Apple%20IIe%20ProDOS%20Users%20Disk%20(copied%203-12-85).dsk

 

There was no direct way to output high-res images to printers without some additional program. The image contains strips of horizontal dots, 7 per byte. The printer writes dots vertically along its printhead pins.

Many printer cards included onboard ROMs to help make this easier. The Grappler series of printer cards used Control-I or CHR$(9) to send commands to the card's onboard ROM. ... PRINT CHR$(9)"GDR" would print hires page 1, double size, rotated 90, so it would cover an entire Letter / A4 page.

1
  • 1
    Welcome to Retrocomputing! Great first post!
    – JAL
    Nov 27, 2016 at 18:57
5

The hard part is usually breaking into the program - using perhaps what you refer to as a "programmer's reset" - so I'll add some notes about that below for posterity.

To save the HIRES screens you want to be able to either reset to a command prompt first, or directly reboot to DOS 3.3 with HIRES memory intact. Then you can save HIRES page 1 or 2 with:

BSAVE HIRES1,A$2000,L$1FF8 or BSAVE HIRES2,A$4000,L$1FF8

To load them back and view fullscreen:

HGR2
BLOAD HIRES,A$4000

Here is a summary of the main ways to get to a command prompt with HIRES intact:

  • On a II or II Plus, use the Old Monitor ROM (maybe in a Firmware Card or Language Card)

  • On a II/II Plus or //e use a Senior Prom or Wildcard (if the software doesn't check for a Wildcard)

  • On a IIgs use the Visit Monitor CDA

  • Boot code trace the disk until the HIRES image is in memory, or hack the disk directly by searching for and modifying the code which sets the soft reset vector (not covered here)

  • Image the disk and use an emulator (the easiest option today - again, not covered here)

Reset Details & Miscellania

Reset on the Apple II, or Ctrl-Reset on the II Plus, //c and //e, causes the 6502 CPU to jump to the address stored in the reset vector at $FFFC/$FFFD.

In the original (Old Monitor) Apple II ROM the reset vector points to a reset handler that falls through to the monitor entry point, so reset will enter the monitor and the HIRES pages will be intact for saving.

In an Apple II or II Plus with an Autostart ROM the reset vector points to a reset handler which checks the "soft" reset vector at $3F2-$3F4. If $3F4 == $3F3 EOR #$A5 then it jumps to the address in $3F2/$3F3, otherwise it reboots. Software almost always used the soft reset vector to either prevent exit, or to clear memory and reboot.

If a Firmware Card is installed then you can use the switch on the back of the card to select the Integer Basic/Old Monitor ROM so reset will enter the monitor.

If a 16k RAM Language Card is installed, reset doesn't affect its state, so if high RAM ($D000-FFFF) is switched in when a reset occurs the reset vector is fetched from RAM. Software of that era often took advantage of this, switching in RAM and overwriting the reset vector, making it impossible to reboot the machine without turning of the power.

If the software doesn't overwrite the reset vector, you can use that trick yourself. From the monitor:

C081 C081       // write enable high RAM
F800<F800.FFFFM // copy the monitor from ROM to RAM
FFFC:59 FF      // point the reset vector to the Old Monitor ROM reset handler
C080            // read enable RAM

Now boot the software and press Reset to enter the monitor, then boot DOS and save HIRES.

In the //e and //c Apple added the Ctrl-OpenApple-Reset feature (referred to as "JIVE" in the source code) to ensure that the user could always reboot the system. While this is exactly the behaviour we would want, it also runs a routine called "BLAST" which writes two bytes to each memory page from BF down to 02, making this feature useless to pirates cracking software - and to us for saving HIRES.

Reset in these machines also resets the emulated 16k RAM Language Card state to read main ROM so software can't hijack the hard reset vector and neither can we - so we can't use the trick above.

If the HIRES page you want to capture is mostly black, you could use Ctrl-OpenApple-Reset and then manually fix up HIRES. The following routine will zero out the bytes that BLAST wrote to HIRES1:

      ORG $0300
BL    EQU $3C
BH    EQU $3D
      LDY #$10
      LDX #$00
      STX BL
      LDA #$20
      CLC
BLOOP STA BH
      PHA
      TXA
      STA (BL),Y
      INY
      STA (BL),Y
      PLA
      ADC #1
      CMP #$40
      BNE BLOOP
      RTS

Other hacking options include boot-code tracing the software to get a HIRES title screen, or searching the disk for code that sets the soft reset vector and changing it to reset into the monitor.

The only remaining options are to use additional hardware. You can build or order a Senior Prom (or other hacking ROMs) for any machine, use a Wildcard (or other copy card), or use an emulator.

3
  • Is the ROM socketed? Is it pin-out compatible with a 2764, 27128, or 27256? It would seem that using a patched ROM could make things much nicer (perhaps even adding an option to have reset copy useful parts of the first 64K to the second 64K of an enhanced Apple //e). Speaking of the latter, I wonder how hard it would be to mod an Apple //c with a switch that would force all memory accesses to use either the first or second 64K? When running code which only needs 64K, engaging reset, flipping the switch, and then releasing reset would be guaranteed to reset the system while...
    – supercat
    Nov 27, 2016 at 16:06
  • ...leaving the contents of the original 64K undisturbed. I've not physically played with the Apple II-family hardware, but it would seem pretty easily hackable for many such things.
    – supercat
    Nov 27, 2016 at 16:08
  • I believe all Apple II machines have socketed ROMs and are quite hackable thanks to Woz. Mask ROM pinouts are often different and so need a simple adapter for EPROMS, but I think the //e can use 2764s (except the Platinum //e). Did you look at the Senior Prom link? It can copy all main memory to AUX, run different programs in each 64k and so much more. I've been meaning to buy one from a2heaven. Nov 28, 2016 at 0:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .