Can you read the character definitions (font) from ROM in an Apple II using PEEK in Applesoft BASIC? You can do this on some other computers e.g. Sinclair ZX81, Commodore 64, and Amstrad PC1512, but some computers e.g. Luxor ABC80 use character generators that cannot be read from the computer. This would be useful for drawing big characters on screen without loading the font data from a file.

I know there can be an 80 column card in slot #3. This question applies both to Apple II Plus/Europlus with or without 80 column card. It should be a pure software solution running on the Apple II Europlus, in my case.

  • 1
    I remember manually recreating bit-by-bit the font on an Apple2 clone (generally an Apple2 with character generator patched to include the local characters) exactly because I could not get it from the builtin ROM without some hardware tweaking.
    – fraxinus
    Feb 6 at 19:12
  • 1
    You mention being able to read the character definitions on the PC1512. On the PC1512 (and other PCs with CGA displays) the characters in the BIOS ROM which you can read are only used in graphics modes. There is a dedicated font ROM used in text modes whose contents aren't readable by code running on the main processor.
    – john_e
    Feb 7 at 9:26

1 Answer 1


No, it's not possible to read the built-in text mode font data from "inside" the machine. (Update: Except perhaps in the Apple IIgs - see below.) In all Apple II models the font data is in a ROM chip used by the video output circuit.

In the Apple II and II plus (or europlus) the font data is stored in a "Text ROM" chip that contains only the font data. In the original Apple II the Text ROM is a General Instrument 2513 upper case character generator ROM. In Revision 7 the wiring of the ROM socket was changed to accommodate a 2316 ROM supplied by Apple, or a user-programmed 2716 EPROM.

In the Apple //e the font data is part of the "Video ROM" 2732 or 2764 chip that actually contains all possible video bitstream output combinations. (In the Apple //c, the same chip is called "CHAR GEN").

In the Apple IIgs (which is such a different beast that whether it really qualifies as an Apple II is debatable) there's evidence it can read the font data for testing purposes. From the Apple IIgs Firmware Reference, bottom of page 281:

C02C:00 246 CHARROM DFB 0 ; Addr for tst mode read of character ROM

As for third party Apple II video cards, such as 80-column cards, you would need to refer to the manual for a particular card, but in general they did not provide access to the font data either.

Here's the Text ROM in the Apple II video generation circuit on page 8-8 from Sather's Understanding the Apple II. Note that the ROM outputs don't connect to the data bus. Some of the above information about the Text ROM is from Sather's description of Text Video Output on page 8-15.

Text portion of the Apple II video generation circuit

  • 1
    As Nick says you can't get access to the ROM but the Hires character generator in the applesoft toolkit does have an ASCII.SET which I presume is the same as the ROM contents. archive.org/details/applesoft-tool-kit-manual/page/n15/mode/2up for the manual. It's also on the Dos Toolkit archive.org/details/a2_DOS_Tool_Kit_v1.0_1980_Apple.
    – PeterI
    Feb 6 at 11:41
  • @BrianH I'm not familiar with Apple II jargon, but "firmware" tends to be broader than that. For example, the aforementioned General Instruments 2513 is a specialized ROM which translates from (character, row) to a slice of pixels to be output on that scanline. It's not difficult to wire that up so there's no way to access its output from the CPU. In more modern systems, there's firmware in all sorts of places that requires a chip clip to read. A hard drive will probably have two or three embedded ARM or RISC-V cores
    – ssokolow
    Feb 6 at 15:56
  • 2
    Actually, on the Apple IIgs, there was a way to read the character ROM - it wasn't directly in the memory map, this was done in some backdoor way through other video-related registers. It's been far too long, I don't remember the details, or any explanation as to why Apple bothered implementing this. Feb 6 at 19:24
  • 4
    @jasonharper One reason for a back door could be that it enables self-test/diagnostic software to check the function of the ROM and its data paths. If the back door hardware is cheap, that reduces manufacturing cost by simplifying QA.
    – John Doty
    Feb 6 at 20:20
  • 2
    @BrianH Sorry guys for the midnight "braino", now fixed by replacing "firmware" with "circuit"! Woz's Disk II Interface Card state machine has firmware, but this is much simpler. Feb 7 at 1:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.