Skip to content

Conversation

@markadev
Copy link
Owner

@markadev markadev commented Mar 8, 2024

This PR integrates in only the Videx Videoterm shadowing & rendering support from @abaffa's PR #38 . The changes to the apple bus handling and overclocking are not currently included to avoid incompatibilities across the different hardware cards currently in circulation.

Videx Compatibility

"Videx compatibility" means that if you have a real (or clone) VideoTerm card in slot 3 then the VGA card will also snoop accesses to it and display an 80 column display when the VideoTerm video 80 column mode is enabled. You must have the actual 80 column card present in slot 3 because it contains RAM and ROM that the VGA card does not emulate.

Videx compatibility is disabled by default so needs to be enabled before it will work. This is to avoid introducing incompatibilities for folks that use slot 3 for other peripherals.

I don't have a VideoTerm card to test directly, but I wrote a simple test case that writes blindly to all the relevant Videx memory addresses (which don't exist on my Apple!) and the mode seems to work.

abaffa and others added 6 commits March 8, 2024 08:46
Refactored the original videx write handling to integrate it in
with the existing shadow write tables and functions.
Update the Videx 80-column mode switch check so that 80 column mode
is only displayed when the "color killer is on", i.e. only if the II+
video mode is text mode. This matches how the real VideoTerm video
switch works.
Some small refactoring and cleanup to:
 * Remove some redundant global variables
 * Use more consistent variable names
Calculate the text window's start address and cursor
address one at the start of the rendering frame to limit
scrolling artifacts.
@aaronsmithdev
Copy link
Contributor

aaronsmithdev commented Mar 9, 2024

**Note: The issue described here is a non-issue and was a problem with my monitor. Leaving it for reference, but please refer to comment below this one. **

Finally landed a gig, so I'll be back at it soon. Going through onboarding and all that jazz now, but I figured I could at least come in and give you a sanity check on this @markadev and @abaffa . I hadn't flashed the 1.2.0 release or the previous pull request, so please consider that. I upgraded from 1.1.0 to this PR directly.

My Steps

  • Built this PR, ran cmake, make, flashed the UF2.
  • Enabled Videx mode, changed default character rom to lower case option 1.
  • Saved using register 4.

Issues

  • A few pixels are clipped from the left side of the screen in Videx mode. When I first noticed it, I had my TV set to widescreen and switched to 4:3, but same performance. I haven't tested it with a monitor because my wires are routed pretty tightly at the moment, but I'll see if I can give it a test with another one and let you know if performance differs. I have no issues with this TV otherwise and don't have that problem in 40 column mode or when using a DOS machine (it has a direct VGA connection and isn't going through an adapter). It's barely detectable when using PR#3 but is more noticeable when running applications. (Personally, it doesn't bother me much and if you gave me the option of having Videx compatibility with this minor clipping or no Videx at all, I'd take this option all day long).
  • And, I guess this isn't from this PR, but I did notice when poking register 4 for saving, screen updates freeze until more updates are sent, in this case, via a key press. Basic commands in the configuration utility cause updates to kick back in and I hadn't noticed it there. Just wanted to call this one out.

So, the only real issue I noticed with this was the clipping. I tested with PR#3, Appleworks (a patched II+ version), ASCII Express, and DCOM and confirmed it across all of them. I thought this might help since I know you can't test directly Mark and I'm not sure how many screens or cards you were able to test on Augusto. I'm using an actual Videx Videoterm (let me know if you want me to check for a model).

I'm including photos, even some unnecessary ones just for sanity. Let me know if I can test anything else for you. I had no problem saving the registers and it seems perfectly stable - I had a 20-minute session in Appleworks and pushed data over the serial connection to ASCII Express for a good half hour.

But great work guys (super shout out to @abaffa!) - this is spectacular. Now I can run all my 80-column stuff! I'll test on another monitor and come back and let you know if it clips.

PXL_20240309_044640428
PXL_20240309_045122595 MP
PXL_20240309_044858924 MP
PXL_20240309_045049891
Screenshot 2024-03-09 002620
Screenshot 2024-03-09 002704
PXL_20240309_053555809
PXL_20240309_054339475 MP

@aaronsmithdev
Copy link
Contributor

aaronsmithdev commented Mar 9, 2024

Issues

  • A few pixels are clipped from the left side of the screen in Videx mode. When I first noticed it, I had my TV set to widescreen and switched to 4:3, but same performance. I haven't tested it with a monitor because my wires are routed pretty tightly at the moment, but I'll see if I can give it a test with another one and let you know if performance differs. I have no issues with this TV otherwise and don't have that problem in 40 column mode or when using a DOS machine (it has a direct VGA connection and isn't going through an adapter). It's barely detectable when using PR#3 but is more noticeable when running applications. (Personally, it doesn't bother me much and if you gave me the option of having Videx compatibility with this minor clipping or no Videx at all, I'd take this option all day long).

Tried it on a monitor and it worked fine after an auto-adjust. I then found some hard to get to settings on that TV that allowed me to manually position the image and that's working fine now. Clipping disappeared. Gosh - of course it was a monitor/TV problem. Lol, I was tempted just to delete my post but it's sat here for 8 hours or so and I wanted to get you guys an update. So, new results are in @markadev and @abaffa:

It all works great on this end! No issues found and multiple 80-column programs work perfectly.

PXL_20240309_143412618

@markadev
Copy link
Owner Author

markadev commented Mar 9, 2024

Great @aaronsmithdev, I was going to suggest the same adjustment! The Videx mode is the first one on the card to fully use all 640 horizontal pixels so any of the misalignment on the other modes would not have been visible. It's good to know that it works on real hardware, so thanks very much.

when poking register 4 for saving, screen updates freeze until more updates are sent, in this case, via a key press.

Yeah that's my dirty little secret... While flash is being written the apple bus snooping is not running so some memory writes can be missed. Luckily on a line scroll, all the text memory to be rewritten to move all the text so it's easy to "fix" after a POKE command. The configuration disk utility works around this by delaying a little after the save command is issued 😃.

I have a couple things I wanted to test but I plan to finalize and merge this PR this weekend.

@markadev markadev force-pushed the abaffa-videx-compatibility-mode branch from e48be7e to f812c5a Compare March 10, 2024 12:52
@markadev markadev merged commit 17d1fd8 into main Mar 10, 2024
@markadev markadev deleted the abaffa-videx-compatibility-mode branch March 10, 2024 13:16
@abaffa
Copy link
Contributor

abaffa commented Mar 23, 2024

@aaronsmithdev Thanks! I'm very glad to have 80 column mode available in VGA and to be able to share the solution. I have a videx card but I chose to use the Apple2vga without it with the rpi pico overclocked.

@markadev's solution is much better for the final product and public and I will adopt it on my card, bringing back my videx card to slot 3. When I wrote my version, my idea was to provide the built-in 80 column functionality as resource for those who don't have a videx card but understand Apple2Vga's concept of only providing vga support to original hardware. (I actually hadn't thought of it that way but it's ideal even because of the overclocking required to communicate with the firmware/video memory)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants