Welcome to AppleII-VGA Discussions!

[markadev]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[vitasam]

Hello! I just found recently this amazing project and now trying to adapt it to my hobby project with MPF-II (an early clone of Apple-II):
https://github.com/vitasam/mpf-ii_retro_6502

[epaell]

This is a fantastic project @markadev and it's inspired me to try and build this for an Apple II I revived from the dead a year or so ago but haven't used much because the composite output is horrendous. I managed to get my hands on a Pico Pi and have just quickly checked the test code that you wrote and it worked a charm. I also made an alternate test where I run it in the non-test mode but populate the screen memory during initialisation to check the graphics/text modes - to my delight that also worked. OK, so now I'm keen to actually interface it to my Apple II and would like to get all the components in preparation and was wondering which Schottky diode you used for your prototype (and also wanted to confirm that it connects to the 3.3V power rail as shown in the schematic)?

[markadev]

Hi there, nice job reviving your Apple II and I'm glad to hear you're having some success so far!

The specific diode I used there was a 1N5817 but you could substitute in different parts since it's only used to OR together some power supplies. I've even used some random glass diode during some prototyping of a different Pico project. It is indeed connecting to the 3.3V power rail, though in retrospect I can't remember why I chose this instead of connecting to the 5V power rail. According to section 4.5 of the Pico datasheet it only needs voltage in the range 2.3V to 5.5V here so either would seem to work.

@vitasam put together a great bill of materials enumerating all the main components needed so that'd be a good starting point for ordering some parts if you haven't seen it already.

Best of luck!

[epaell]

Thanks for the additional information - that's very helpful. Oh, and thanks @vitasam for compiling the bill of materials. I've got most of the parts on order now so I just need to wait (impatiently) for them all to arrive.

[vitasam]

You are welcome, @epaell! Nice project!
I hope that I will be able to assemble my prototype board for MPF-II. Also, I thought that if I get to the creation of a full-fledged printed circuit board phase, it might make sense to provide jumper connectors that will switch the board (and Pico FW) between Apple-II and MPF-II.

[epaell]

I'd have to admit that until I saw your post I was completely oblivious to the existence of the MPF-II - it looks like a really cool device! I'm curious, how does the bus/video differ from the Apple II? From what little I've been able to find out about this computer it looks like it is supposed to be compatible? Making a board that is compatible with both does sound like a great way to go!

[vitasam]

I'd have to admit that until I saw your post I was completely oblivious to the existence of the MPF-II - it looks like a really cool device! I'm curious, how does the bus/video differ from the Apple II? From what little I've been able to find out about this computer it looks like it is supposed to be compatible? Making a board that is compatible with both does sound like a great way to go!

Hi. I also did not know about MPF-II until I accidentally bought it at a local electronic "flea market". There are some differences between MPF-II and Apple-II in respect to video-memory addressing and the bus. We have had a discussion with @markadev about differences. It looks like it is possible to make such a dual-system board.

[epaell]

My very dodgy set-up to test the VGA output :-)

[Paco1979]

Hi guys, I build the VGA card, and put it on my Apple iie Enhanced, but I'm only getting some blocks, nothing else. Is the software compatible with the iie roms? I would though so, but not sure what is going on. The test pattern look perfect when compiled with the #define activated. So it has to be something on the coms with the Apple ii

[Paco1979]

Hey Mark thank you so much, i managed to get it working, I added a print via serial (i know this will destroy the timings but i wanted to see the addresses it was reading) noticed that the address high byte and low byte where the same. Looking with an oscilloscope I noticed that the enable pulse to one of the transceiver was to narrow, I went to the pio asm thing and added more delay while reading the lower byte and boom! Image and text.

There is no fun in the other vga card! :) I just added lowercase capabilities, and want to try to get it to display 80 columns text. Thanks again

[markadev]

Nice! Glad to see that you got it working and that lowercase text looks great.

[epaell]

Excellent ... I'm still waiting for my final parts to arrive so I can try this myself. I have a II+ and a IIe so I'd be really interested in the any updates you make to the software.

[Paco1979]

I dont have access to push a new branch in :( @markadev Is that something you can help us with?

[markadev]

What you can do is fork the repository then create branches in your fork. Then if you'd like to submit your changes to be incorporated in (your choice, no pressure) you can open a Pull Request.

[Paco1979]

Hey guys I just got 80 Columns working!! 💪🏻

[Paco1979]

I need to make some sort of #define to change the char rom to non enhance version!

[epaell]

That's awesome! Great work!

[Paco1979]

Got DHIres working kinda! It works fine with some games but King quest 1 for some reason it does not work, maybe they are doing something strange. It seems it a problem with paging, but is strange since dhires does not page uses page 1 from ram and page 1 from aux ram. Any ways once I get access I put it on a branch the. We can all clean it up and see if we figure it out. Really fun project! :)

[epaell]

A quick update ... the last component (the VGA connector) finally arrived in the mail and I have just completed the board:

It turned out cheaper to get a board designed than it was to order a prototype board off e-bay and have it delivered to Australia and this way I get 5 boards rather than just one.

I just tried a smoke test in an Apple II+ and the display output looks beautiful - sooo much better than composite!

And thankfully no smoke! Text and Lores graphics seem to work fine. However, I noticed that something is not quite right with the high resolution graphics - it's mostly right but it seems like a bit is stuck:

When I get a chance I'll need to do a bit of debugging to work out what's going on. Hopefully it is as simple as me missing a solder joint somewhere (my eyesight is not what it once was). It's been nice to un-dust the Apple II again. Once I get this running fully I'll test it on the IIe as well. I'll have to agree with @Paco1979 that this has been really fun! And thanks again to @markadev for making this design available.

[epaell]

I'm out and about today but will try to capture the lores screen when I get back and start a new "discussion". My feeling is that there isn't anything wrong with your code because the composite and VGA screen-shot you posted are consistent with each other and look similar to what I get if I look at the composite output when I run a similar test running a basic program. I'll double check that I have the resistors all correctly installed in the right places with the right values - I guess if I messed up there there might be situations where some of the colours could look correct but others may not. I might also try to modify the test pattern to show each of the steps of the primary colours if I get a chance - that should very quickly tell me if I messed up on that aspect of the build.

[Paco1979]

@epaell
I made a fork https://github.com/Paco1979/AppleII-VGA-Experimentation we can play with the code here, I will add my Branch with all the graphical modes working (Expect for King quest lol so heart broken cant figure it out yet). I want to work with you to add some sort of #define so it is compatible with the Older apple II, for example #define that changes the Character ROM and removes lower case etc.

[Paco1979]

@epaell
Have you try the Render test patters? you can activate them with a #define, there you can check the colors, compare to the picture
https://github.com/markadev/AppleII-VGA/blob/main/docs/test_pattern.jpg

[Paco1979]

Yeah!!!

[epaell]

Nice! Achievement unlocked!

[epaell]

Yes, I had tried to run the test pattern and the result looked very similar to the one in the document. This is what I get:

I also wrote a bit of code for the pico to generate a lores pattern using the "Apple" colours from 0 to 15 but I get a very different result to the one in the document:

Particularly the first few colours are quite different. When I run a similar program in Apple BASIC I get the right colours from the composite output (I'll try to reconfirm that) but the same wrong colours out of the VGA port. I checked the resistors and they all appear to be connected correctly and go to all the right pins - it's all very odd.

[epaell]

OK, here are the images from the lowres test using an Apple BASIC program (basically the equivalent of what I wrote in C for the pico). This is the VGA output:

This is switching over to the composite output:

And this is running on an Apple ][+ emulator on my Mac:

[Paco1979]

@vitasam If you go to my Repo https://github.com/Paco1979/AppleII-VGA-Experimentation/tree/fgutier-mpf2-pallet
I added a Variant for MPFII where I change the lores Pallet to match the PDF Color list
Build it using this command
cmake -DAPPLE_MODEL=MPFII -DCMAKE_BUILD_TYPE=Release ..
then make
let me know how the color looks

[Paco1979]

_RGB333(0x00, 0x00, 0x00),  // black
_RGB333(0x00, 0x77, 0x22),  // d.green
_RGB333(0xdd, 0x22, 0xdd),  // h.violet
_RGB333(0xff, 0xff, 0xff),  // white
_RGB333(0x00, 0x77, 0x22),  // d.green
_RGB333(0xff, 0x66, 0x00),  // h.orange
_RGB333(0x22, 0x22, 0xff),  // h.blue
_RGB333(0xff, 0xff, 0xff),  // white
_RGB333(0xdd, 0x22, 0xdd),  // h.violet
_RGB333(0x00, 0x77, 0x22),  // d.green
_RGB333(0xdd, 0x22, 0xdd),  // h.violet
_RGB333(0xff, 0xff, 0xff),  // white
_RGB333(0xff, 0xff, 0xff),  // white
_RGB333(0xff, 0x66, 0x00),  // h.orange
_RGB333(0x00, 0x00, 0x99),  // d.blue
_RGB333(0xff, 0xff, 0xff),  // white

I'm sure we can tune the correct colors, but at least the array will have the correct one according to the PDF

[vitasam]

Wow @Paco1979 , you are so fast!

Unfortunately my VGA-card is in the middle of construction:

Also, there is no guarantee that it will work - it appeared that the extension bus of MPF-II is not fully compatible with Apple-II, at least some timing should be corrected in Pico's PIO code.

[Paco1979]

@vitasam aaah no worries, just let us know when you build it, we can probably have a different timing for your variant. Where are you based?

[vitasam]

@Paco1979 thanks!

I'm from Finland. I started my proto-board quite long time ago, but just now I started to have free time to continue with it.

I have an idea - if the board will work with MPF-II after all possible changes in bus connections and firmware - develop an updated PCB with jumpers, so one can switch between Apple-II and MPF-II. The latter one is quite interesting machine.

P.S. An ultimate dream - combine VGA-Card board with floppy-drive emulator :) since MPF-II has an official floppy-drive

[epaell]

@Paco1979 Does the experimental fork have your updated code pushed up to it? I'm keen to give it a try.

[epaell]

I'm curious to understand the detection code in the V2-analog firmware. I had a brief look and it looks like it is just checking for a unique bit of the start-up screen to identify which machine is which i.e. for the IIgs it is looking for "Ig" in the screen location where it presumably normally write "Apple IIgs"; "/e" for the IIe enhanced; "P" for the II, II+, J+ with autostart (since APPLE is written in capital); and a "*" with flashing cursor at the beginning of the last line for Apple II without autostart (although I'm not sure what that is). I didn't quite work out how it decides when to perform this check (it would have to get the timing right otherwise if it checks before the screen is written or after it has passed then it'll miss it) - I thought maybe it would wait for an attempt to access the disk drive perhaps (since I think that is done almost immediately after writing the message on the screen) but in my quick look I couldn't see anything like that. Do either of you know how that timing is worked out?

[Paco1979]

@markadev I agree with Mark, I dont see my self moving this vga card from apple to apple, is a fixed thing, so I think it makes more sense to Compile it in directly and reduce complexity.

[epaell]

Sure, I agree too ... I was just curious to understand how it worked.

[markadev]

This is the detection code, right @epaell? https://github.com/V2RetroComputing/analog-firmware/blob/a82b03e6317ad8c81de0663bd5b18b999b86af13/common/main.c#L90-L118

It looks like on power-up current_machine is set to MACHINE_AUTO and then it runs that detection code after every bus cycle until it detects the actual machine type and sets current_machine to the real type.

[epaell]

Ah, of course, how did I not see that - it's so obvious now that it is pointed out. Thanks @markadev - I'll sleep better now :-)

[markadev]

@markadev Formatting would not be a problem, I can probably redo it so it keeps the original, I just use to our C format standards in Jaguar. I think I bumped the speed due to some strange rendering artifacs, but maybe it was another problem we can try slowing it down again to see if something changes. I will make another branch in my fork, and then let you know when I have it done. so for non Apple iie, just need to #define it and just blank out softsw that we do not need (anything to do with 80 columns and double res)?

Yup I think that would be a great start @Paco1979, thanks! Then if you can create a Pull Request that has a clean diff of your modifications then it'll be easier to review and discuss any other specific changes further. I also want double-check that the abus.pio changes still work on my II+.

And I may have just gotten an old beat-up IIe off of ebay to restore. Once it's working I can join the IIe club!

[Paco1979]

@markadev Done, check my repo, compile it for apple ii+ and let me know how it goes. I lower the speed to 126 MHz at the end did not need the extra speed, I just check using the IIE flag and everything works fine.

[markadev]

Okey I get that sorted! What should I disable for non IIe, I guess, the char rom has to be different since no lower cap, what else? I can probably not allow the change to DHIRES. Can Apple ii (not enhance) have 80 Column Cards?

I think that's OK (based on what I see in your branch). Apple II+ can have a third-party "Videx" 80 column card but I didn't see much software that used it.

I wonder if we could use the RP2040 to emulate the chip

Given current technology I think a lot of old retro peripherals and chips could be emulated nowadays using cheap fast microcontrollers. A big challenge is the 3.3v vs 5v difference so you need chips to do the translation which can get bulky.

Done, check my repo, compile it for apple ii+ and let me know how it goes. I lower the speed to 126 MHz at the end did not need the extra speed, I just check using the IIE flag and everything works fine.

Great @Paco1979! I'm glad it still works at the stock speed. There is one bug in II+ text rendering - you'll need this:

--- a/pico/render_text.c
+++ b/pico/render_text.c
@@ -24,6 +24,8 @@ static inline uint_fast8_t __time_critical_func(char_text_bits)(uint_fast8_t ch,
   } else {
     bits = character_rom[((uint_fast16_t)ch << 3) | glyph_line];
   }
+  #else
+  bits = character_rom[((uint_fast16_t)ch << 3) | glyph_line];
   #endif
   /*
       Character stored in ram like this

To get this integrated let's do this next:

• After applying the fix I mentioned above please also run clang-format using this configuration on all the c and h files except the hires_*.h files. This will resolve any remaining big formatting or whitespace changes so the diff will be reviewable
• Then you can open a Pull Request to main branch of the markadev/AppleII-VGA repository
• In the Pull Request we can discuss if there's any further changes need to be made to the code before merging it

Thanks Paco!

[Paco1979]

Done
#13
@markadev can you check it please on your Apple ii+
I think we can do another MR later and I can add pictures of the new Video modes, add the instructions for the Apple Variants, etc

[markadev]

Merged! Thanks for the additions and the new screenshots look great too.

[Paco1979]

Thanks it was very fun to work on this!

[TMS2764]

Would it be possible to add a mode where the text would automatically appear as per the monochrome settings (text mode) but graphics would still be color (graphics mode)?

[markadev]

Hey there, yeah that would be possible to add. The text color choice is just a simple conditional check here so it'd be pretty straightforward to add another condition.

I could take a look at adding this feature sometime in the next couple of weeks.

[TMS2764]

Excellent. I will definitely try it. I think that would be a cool feature.

[TMS2764]

I just tried v1.4.0 with monochrome text and color graphics. Works great. This is my new favorite mode. Thanks for going the extra mile.
I do have a few questions. What is "Soft-mono" mode used for?
In graphics mode "GR" there are 4 lines of text at the bottom. Can those four lines be configured as monochrome color as well?

[markadev]

"soft mono" mode is a mode that emulates a monochrome monitor, so displaying monochrome dot patterns instead of blending together into NTSC colors in the graphical modes. Some software uses hires mode in a way where it looks terrible on a color monitor but very crisp on a monochrome monitor so this option assists with that software.

For mixed modes I opted to keep the text white with this change so that green/amber text wasn't mixed with color graphics. There's no option to change that specifically but it would be a small code change here and here to change false to soft_force_alt_textcolor.