• Please review our updated Terms and Rules here

I'm writing an emulator but I am having issues understanding the character ROMS.

cbmeeks

cbmeeks

Experienced Member
Joined
Apr 9, 2018
Messages
53
As the title suggests, I am writing my own custom Apple II emulator. Specifically, I want to target the II+ in the beginning.

I have the basic text page 1 working and I can send some custom assembly language to it and it works. However, once I try to load an actual ROM file, I get nothing but garbage on screen.
I don't think I have a real understanding on how the ROM is structured. For example, it is my understanding that the font glyphs (the actual character data) is located at $F800 and is 1K in size.

When I run my own custom 6502 code, that is fine. But it seems any Apple II ROM I find online doesn't work at all. On one particular ROM, I could see the screen messed up but there were 8 patterns at the top that looked different. On a hunch, I assumed it was "APPLE ][". I then manually patched the character ROM location where "A" was supposed to be and sure enough, the A appeared.

This leads me to think the character data at $F800 is getting clobbered when I import the ROM.

I'm at a total loss on this and I cannot seem to find information on the character ROM, addresses, etc. Everything I find assumes I want to replace a real ROM chip, etc.

Any information would be appreciated.

Thanks.

UPDATE:
I actually found this information on the memory mapping. It seems that $F800 is actually the system monitor. But it was my understanding that the first half of that monitor was the character data. Since the A2 pulls characters from an actual character generator chip, I'm not sure how that would work in an emulator setting.

$0000 - $00FFZero Page
$0100 - $01FFStack
$0200 - $03FFMostly Free, Input Buffer, Interrupt Vectors
$0400 - $07FFLo-res/Text Page1
$0800 - $0BFFLo-res/Text Page2 (BASIC programs load here)
$0C00 - $1FFFFree
$2000 - $3FFFHi-res Page1
$4000 - $5FFFHi-res Page2
$6000 - $95FFFree
$9600 - $BFFFDOS3.3 and Buffers
$C000 - $CFFFSoft Switches, Expansion Card I/O and ROM
$D000 - $F7FFBASIC ROM (can be bankswitched later models)
$F800 - $FFFFMachine Language Monitor ROM (also can be bankswitched)


Sorry, another brain dump here. I found the actual source to the machine monitor and it seems it does start at $F800. The first 1K is definitely code. The second 1K ($FC00+) is also code.
This makes me think that the Apple II actually runs CODE (duh!) from $F800. But the character ROM data isn't actually available directly from the computer. Especially since it comes from a character generator chip. This is so much different than the C64 that I am used to.

Does this seem write? This would explain my my screen looks like garbage after the ROM. It's displaying CODE, crashing, etc.


UPDATE AGAIN!

Disregard this entire question. It seems I was right! Once I imported the char data into a specific buffer and quit pulling from ROM, the emulator started working!!
I have a confession. Grok3 told me the font glyphs came from $F800. I guess that's what I get for listening to a robot. LOL!

Feel free to close this but maybe it would help someone in the future.
 
Last edited:
cbmeeks said:
I have a confession. Grok3 told me the font glyphs came from $F800. I guess that's what I get for listening to a robot. LOL!
Click to expand...

*Every time* I google anything about a retro computing related issue Google slaps an AI suggestion above it, and I hate to break it to you, nearly *every time* I've tortured myself by reading them I've found obvious errors. Don't ask AIs.
 
The first thing to keep in mind is that the character generator ROM does not appear anywhere in the memory map of an Apple II.

What happens is the video circuitry fetches the ASCII character from memory, and presents it as part of the address to the character ROM. The rest of the address is the row number for that scan line. The data that comes out from the ROM is the pixel data for that row in that character.

The 6502 processor plays no part in this at all beyond storing the ASCII data in the right locations in main memory.
 
It is much the same as a PET etc. The CPU writes character codes into the video RAM and the hardware 'does it's own thing' and converts the character code into a series of video lines of pixels automagically.

Dave
 
Thanks everyone. Yes, I found that lesson the hard way.
The good news is that my emulator is working. Well, technically. I can run A2, A2+, Integer/FP BASIC, etc. The weird issue I have at the moment is the cursor is not visible.
I assume it's because I don't have the flashing characters setup correctly.

1740688975529.png
 
Yep. I've gotten so much further with it. I now have it working with GR mode and HGR mode in monochrome. Audio basically works (beep) but it's not quite right.
 
Yeah, it's not perfect in any of my emulators either. Modapple's is really raspy, though the theory should be right.
 
I think it's worth nothing here that while for modern computing systems LLMs can give useful (often not correct, but useful) information, I have found them to be absolutely terrible for retrocomputing information. I am guessing that the issue is that they simply produce plausible-sounding strings based on their training, and they have no understanding that they've been trained on texts about the 8080 and 6800, texts about the Apple II and Commodore 64, etc. and they will freely intermix information from these based on the totality of all of the content, not just the content for the particular CPU or system you're interested in. Unlike with modern code, I have never seen an LLM produce even half-way accurate information about a retrocomputing topic.

TLDR: Never (at least for the moment) use an LLM to find out about retrocomputing stuff; just do web searches.
 
  • Like
Reactions: zu2
You must log in or register to reply here.
Back
Top