Apple-2-SW/bitmap-editor
1
0
Fork 0
mirror of https://github.com/tilleul/apple2.git synced 2025-02-20 08:28:59 +00:00
Code Issues Projects Releases Wiki Activity

Update README.md

Browse Source
This commit is contained in:
tilleul 2021-05-19 16:03:28 +02:00 committed by GitHub
parent 080708c6dc
commit 2e51e095f3
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
applesoft/spc/README.md
View File

@ -64,7 +64,12 @@ So, before any character is displayed on screen by Applesoft, two masking operat
1. an `ORA` with the value in `$F3`
2. an `AND` with the value in `$32`
`CTRL-RESET` resets the value in `$32` to `255` ("normal" display mode) but it does not touch the value in `$F3`. That's why we have these display glitches if we `CTRL-RESET` after `FLASH`. Clearly, it's a bug.
`CTRL-RESET` resets the value in `$32` to `255` ("normal" display mode) but it does not touch the value in `$F3`. That's why we have these display glitches if we `CTRL-RESET` after `FLASH`.
Clearly, it's a bug.
When we press `CTRL-RESET` the system does a lot of resets, among them a call to SETNORM (`$FE84`) that restores the `$32` memory to `$FF`. Then a bit later it calls the routine pointed by the reset vector (`$3F2`), that is Applesoft's warm restart in `$E003` which in turns calls the `RESTART` routine in `$D43C`. This routine's main purpose is to display the `]` prompt and wait for the user to type a series of direct commands or a line of code. The only way I see we could fix this bug is by pointing the reset vector in `3F2` to a small routine that would reset `$F3` and then call the `RESTART` routine.
## Taking advantage of what we know
Of course Applesoft expects and uses some specific values in `$F3` and `$32`.