Anonymous
User login
Please support the defense of Ukraine.
Direct or via Unclutter App
Active forum topics
Recent content
Navigation
No Ads.
No Trackers.
No Social Media.
All Content Locally Hosted.
Built on Free Software.
We have complied with zero government requests for information.
I just tried a Ralle Pa A2VGA card in one of my Taiwan ][+ clones and while it produces flawless 40 column video when I try PR#3 (cand is in slot 3) it just hangs and I get nothing. So either I don't have the right firmware loaded, the GAL programmed rigjht or my understanding of how this is supposed to work is wrong.. Does 80 column on a ][+ still require an 80 column card and the A2VGA somehow figures out how to decode its frame buffer or am I just completely off?
I'm going to ask Ralle Pa some questions over on FB and see if he can shed some light on it. Open to hearing what anyone else knows or even speculates...
I had to wonder the same but I don't think it would/should work that way, because in the case of a physical 80 col card, isn't [it possible that] the card is producing video output not present on the bus to sniff in the first place? Intersted to hear what you find out!
Also I don't have a lowercase character ROM in this II+, but I do have another II+ with a videx character ROM. I don't know if that would make any difference at all though.
I wonder about the lower case also. I will have to try that. I don't think the ROM installed on the motherboard matters at all. I think it is whatever is in the firmware loaded on the Pico.
These cards cannot read the character ROM on the motherboard or anything from an 80-column card for an Apple II/II+. On my Pravetz 82 though (an Apple II+ clone with a toggle key for Cyrillic/Latin), I discovered that the Vince Briel version of the card works with the Apple IIe firmware, which has Latin lowercase in the firmware. So when I switch to Cyrillic either using Shift or the toggle key, I get lowercase Latin.
Both the uppercase and lowercase fonts can be in this file: https://github.com/markadev/AppleII-VGA/blob/main/pico/textfont_iiplus.c, but for some reason only the Apple IIe firmware has lowercase Latin. However it can be added to the Apple II+ firmware in two ways:
1. By copying it from this file: https://github.com/markadev/AppleII-VGA/blob/main/pico/textfont_iie.c
2. Using this software: https://www.min.at/prinz/o/software/pixelfont/
My guess is that this will also work on other Apple II+ clones that support lowercase or second alphabet.
Ralle sent me another .jed file which I am going to try. Oher than that I have had no luck getting 80 columns on a ][+ using this card. The other thing I am going to try is a couple other ][+ clones and I will also dig a real ][+ out of storage.
Well, I am looking at CP/M running on a Ralle A2VGA card outputting through another one. No 80 coumns though. This is on that same ][+ clone I was using before. I haven't gotten around to trying the new .jed file yet.
Here is that new .jed in case someone has time to try it before I do.
I also need to try the Z80 on a //e and see if I get 80 columns there.
OK, I was able to get CP/M in 80 columns on a //e using two RP A2VGA cards. One in slot 2 in VGA mode and one in slot 4 doing Z80.
So it is just getting 80 columns on a ][+ that isn't working for me at this point. Hopefully over the weekend I will have time to try the new .jed
Nice, but was it without an 80-column card in the AUX slot? I am asking, because with an 80-column card in the AUX slot even the Vince Briel version can do 80-column mode on the Apple IIe. It's the card in the AUX slot that is making it work.
I had an 80 column card in the AUX slot. I know it was using that but I just wanted to make sure CP/M was using 80 columns.
You mind sharing the CP/M version you use, also the Jed file witch works for you and eventually the uf2 file. I have tried using different versions of files but no luck. Thanks in advance
I am using the PCPI CP/M images. The uf2 I am using is the 4ns VGA ones from the zip file posted earlier. I am still using the older .jed
However, I found out today from Ralle that this card doesn't actually emulate an 80 column card like I had been led to believe. It will work with 80 columns for sure on a //e with an 80 column card in the AUX slot, I've verified that. Supposedly it will also work with a Videx card in slot 3 of a ][+. That I have not yet tested, but hopefully will be doing soon.
I had this suspicion after reading the source code.
I don't have a videx on hand but I have a micromax viewmax 80 iirc. I can always throw it in a II+ and see what happens.
No harm in trying, but if this card cannot do 80-column mode without an Apple II/II+ 80-column card, I don't see how it could do it with one. Unlike the Apple IIe, the 80-column cards for the Apple II/II+ have their own video memory + character ROMs and produce their own composite video. They never write it back to the Apple II bus.
I built two of the 1.2 version card and both work with the NOPLD jumper. I haven't programmed any ATF22V10B for these yet because somehow I managed to misplace my Minipro TL866-II and the chips. I have no idea what I did with them. I've been going crazy trying to figure out where I put them. Anyway. I think my old TL866CS will work to program ATF22V10, if not I will have to order another TL866-II I guess. I already ordered some more ATF22V10B chips. I could probably use some of the Lattice GAL 22V10 that I have but those are hard to find now so I am saving them for something that might need them specifically. Anyway, the 1.2 cards work fine for VGA. I don't think I can try them for CP/M until I get the PLDs installed. I have more Picos and Dsub15 connectors ordered so I can complete the other three 1.2 boards I have. I may order some 1.3 boards as well. On the 1.2 boards I verified that the built in POP9 support works, so no need to solder a wire on the back side like the 1.1 boards. I also by Ralle's suggestion left all the diodes except D1 out, he says they aren't needed and he did away with them in 1.3 version. I just hardwired across them. I also just hardwired the fuse because I know these cards will be used with POP9 modified VGA->HDMI adapters, so I don't think the fuse is really needed, it's no different than the added wire in the 1.1 card.
I think the fuse is a very good idea for production. You never know if some cheap VGA cable won't have pin 9 grounded in order to save on shielding and without the fuse the PSU will need repair.
Sure, that's probably true, it is a good safety measure for people who might not be using POP9 for a VGA->HDMI converter like I am. A jumper like was suggested would also work - only enable if you know you need it.
Thanks for the write-up and the blog post on how to make on of these cards. I now also made some. Based on the PCB v1.3 (FYI: there is also a redesigned v1.4 PCB available since yesterday, which has a reduced PCB size).
v1.3 is similar to the previous (shown above). But three of the schottky diodes are gone, the voltage divider resistors now have more space (now soldered flat to the PCB). And 5V is routed to the VGA connector pin:
A2VGA_PCBs.jpg
I made one with a standard connector:
A2VGA_Connector.jpg
And another one where I replaced the onboard VGA connector with an external one, connected with individual wires - so I could attach the VGA connector to one of the DB9 ports in the back of the IIe.
Other A2VGA PCB designs may be more suitable for this - there is also one with a connector for a ribbon cable to connect a separate PCB, which then has the VGA connector. But hand soldering the wires wasn't too much trouble. It's just the three RGB pins, the two SYNC signals and ground wires. And the extra 5V pin, if you need it.
A2VGA_Cable.jpg
(In case you were wondering: the black box over the VGA connector area is just a 3D printed cable strain relief, to secure the wires, so they cannot be pulled from the PCB. Also, my Schottky diode didn't fit. So it's temporarily soldered to the bottom, until the proper ones arrive - which is why it's missing on the photo).
What may be worth mentioning: after programming the PICO you can already test it - before even plugging the card into the Apple II. Just power the A2VGA PCB externally (bench power supply, if you know what you are doing - or, even easier, plug a powered USB cable into the PICO's MicroUSB connector). The 74LV245s are not yet needed. It will start, complain about missing Apple II bus activity, and show a test image. Nice test feature when you make a new card (especially when you handsolder the VGA connector, like me):
A2VGA_TestImage.jpg
I still like my original green phosphor monitor. But nothing wrong with a dual-screen setup, right? :)
A2VGA_DualView.jpg
Colors look great. Just my camera is a bit confused with the white balance...
Neat: the machine now has two SD card slots, an Ethernet and a VGA connector:
A2VGA_VGAConnector.jpg
So, what's next? USB (= mouse)? :)
And afterwards? PCIe...? ;-)
What it still missing, and I knew that before, is proper support for "Euro" machines. They have a "rocker switch" to toggle the video ROM (also affects the keyboard ROM) between US and local character set. But that's not implemented with A2VGA:
A2VGA_Language.jpg
Character set switching was all implemented in hardware, and the 6502 has no way to detect the state. (The rocker switch is directly toggling an extra address line of the keyboard & video ROMs). So, it would require an extra I/O pin on the A2VGA card, so one could connect a separate jumper cable from the rocker switch. Then A2VGA could then also switch its "video ROM" accordingly. Would be nice if this option would also be added - which would make it a perfect solution, also for the Euro IIes.
I'm not sure how your idea for the character ROM switching would be implemented on the card. I've looked at the schematic and I believe all of the pins on the Pico are used already. Maybe there would be room somewhere to do it on the PLD, but you've built this one apparently with no PLD.
Well, I could still add the PLDs at any time, but it seemed they are currently not needed for the VGA function? And since I don't need the Z80 support, I haven't bothered yet.
But I wasn't necessarily hoping for a quick fix with the current cards. It's just an obvious basic feature which right now isn't supported, so the cards aren't fully replacing the original video output for all applications. So I was hoping this would eventually be added by the project - or one of the variants. Maybe by a hardware revision 2.x.
Yes, if all GPIOs are already used, then it's a little harder. But not impossible. Yes, maybe it's possible to use one of the free pins at the PLD. Otherwise, it would require extra components to improve the multiplexing.
There is one free GPIO on the Pico - GP25 used for the LED. Who needs a LED when you have VGA! :)
It could be patched hardware-wise to free up GP25, but there is still a whole bunch of work that needs to be done on the software side. Someone has to sit down and put a bunch of different alphabets into the Pico firmware: French, German, etc. Then the configuration utility has to be modified to allow the user to choose the alternative alphabet, since there is no other way to determine which seconds alphabet the Apple IIe PAL edition has in its character ROM.
Another idea is to use this instead, which has 30 GPIO pins: https://www.aliexpress.com/item/1005004277013272.html
"Page not found" - the link doesn't seem to work for me...
One could also throw some extra logic gates at the problem, to free up GPIOs. For example, it's currently using three separate GPIOs to select one of the three 74245 buffers. Of course, only one of these must be enabled at any time (they are multiplexing the data and address bus). This could be done with two GPIOs only (two bits still provide four states). It would require an address decoder, like the cheap 74138 to decode the two GPIOs to three individual chip selects. This would free up one of the GPIOs for something else.
But yes, it's an extra IC and it would make the PCB slighty larger. I would have hoped that someone knowing more about the card might come up with a more "Woz-like" minimalistic solution (maybe involving no more than an extra mosfet or two... :) ).
Sure, it would also require a number of changes to the sources. But there are quite a few French, Scandinavian, Italian, German, ... machines and users out there. And the VGA project is quite popular. There would probably be volunteers to help out.
But don't get me wrong. It's still a nice card as it is and I'm happy to have it. And for graphical applications/games it doesn't matter anyway. It's just not yet able to replace the machine's CRT for all the things I want to do.
Yes, I can see using Tor that this seller only allows some countries. Use this link instead:
https://www.aliexpress.com/w/wholesale-Ultimate-Pico-RP2040-128Mbit-16MB.html
Basically these have 4 extra GPIO pins.
I'm a bit confused and maybe missing something obvious... I tried using the A2VGA "utilities" disks to configure the card:
https://github.com/V2RetroComputing/analog-utilities/tree/0f011d98353092abeb58d6d9fde6a39a76950e5a/obj
I'm using the "Ralle Palaveev" of the A2VGA, as discussed above. But that didn't work. The card's VGA output still works fine, of course, but it wasn't recognized by the config utilties. And neither did it respond to configuration changes.
So I removed the "No PLD" jumper and added the GAL (ATF22V10), since I thought, maybe that is required to support bidirectional communication. However, there don't seem to be any JEDEC files in the GitHub project. Only the .PLD file. I need a JEDEC file for my programmer, so I used the one which skate323k137 attached to his blog post. The VGA output still works with the PLD, just as before - but the utilities still don't work.
So:
I have auccessfully used the config utility on the 1.2 board with the picopal N in place.
20231206_215749.jpg
Also I believe it calls for an ATF chip, I just had GALs around from arcade repair projects.
I looked into the sources of the config utility. It is checking the slot ROMs for an ID ("V2A" = 56 32 41) at $CnF8..$CnFA (n=slot number of your A2VGA).
Indeed, I can see "56 32 41" in the slot ROM of my card. However, the dump shows it at $CnF9..CnFB. So it is shifted by one byte...
When I use the monitor to read individual ROM bytes, then it works - but only when I read the same ROM address twice:
]CALL -151*C5F800 (wrong)*C5F856 (OK)*C5F956 (wrong)*C5F932 (OK)*C5FA32 (wrong)*C5FA41 (OK)So it seems something is a little too slow to respond. The 6502 isn't seeing the correct data when reading from the I/O device. It's obviously not an issue with the write direction, since my VGA output is perfect.
What is the speed of the GAL you are using? Some of the older ones I've seen are are labeled -25 vs the ATF22V10B that I hae which say -15 on them.
I'm using ATF22V10C-10PU. These are 10ns devices. (Brand new devices from digikey, datecode 26/2023). There are also faster (7.5ns) and slower (15ns) variants of this GAL on offer (which I do not have).
And I checked what happens to the slot ROM without the GAL (with the "NoPLD" jumper set): the slot ROM only shows random data then - so it's not present without the GAL. Makes sense, since the GAL equations contain address + IOSELECT decoding logic. So, no PLD => no ROM emulation.
However, the "No PLD" jumper connects the PICOs select input directly to DEVSELECT. So the card's I/O registers should work - even without the GAL. And the config utility allows to enter the slot number manually. However, configuration still doesn't work then...
I'm wondering if the issue was something else, not the GAL (since it should probably also work without it). Maybe the 74LVC245s... Maybe mine are not fast or strong enough to drive in the A2VGA => 6502 direction. While the other direction, 6502=>A2VGA, has no issues, hence VGA output works fine (the latter is the much more robust 5V=>3.3V direction).
Your GALs are faster than the ones I am using so I agree that it is unlikely the problem.
I had issues with some 74LVC245 not working right in Briel cards, and not at all in this version. Perhaps you are on to something there. Where did you get those chips? The ones that are working for me are from Jurried Engineering.
I'm using new Texas Instruments SN74LVC245AN, I got from digikey. So pretty sure these are authentic, and not relabled LS245s from some wacky ebay source.
The datasheet says it supports "down voltage conversion", since its inputs are 5.5V tolerant, even when powered at 3.3V. It never claims to support "up voltage conversion" (being able to drive 5V TTL compatible levels, when powered at 3.3V). But since it's obviously normally working anyway, the design is streching its capabilities.
The TI 74LVC245 chips from DigiKey are authentic. I got mine from there and they all worked.
Speaking of out-of-spec, I tried the Vince Briel version with all three 74HCT245 and those worked as well. Another guy on the Bulgarian repro-computer forum tried it with all three 74HC245 and those worked too! A different guy tried it with three 74LS245 – those did NOT work. (I tried with a single 74LS245 pulled from my Apple IIe + two 74LVC245 and it worked.)
Btw: those TI chips you got from DigiKey - if you touch the legs with your fingers, do you see a black fingerprint?
For fun & science I swapped one the 74LVC245s with an HCT. I swapped U4, the one driving the databus - the only one which also needs to work bidirectionally.
Nothing changed. Worked just as well (or bad). VGA output is still absolutely fine. But nothing changed with the config utilities. So indeed HCT245s would be a cheaper replacement for the LVC245s.
Yes, the TI 74LVC245 have these legs with a slightly darkish look. Like your grandmom's slightly tarnished silver cutlery... :)
What still puzzles me is that reading the slot ROM works when I read the same address twice. That's not an uncommon behavior with busses, when you have timing issues. When a bus is floating in between two read accesses. The first one doesn't quite work, since the signals are not quickly enough driven to the correct level. But the second access works since the floating bus still is (almost) at the correct levels from the previous attempt, so the following access is slightly quicker.
However, that doesn't make sense in this case: I'm manually reading the ROM using the monitor, so there are millions of clock cycles in between the two read attempts. Meanwhile the databus is not just floating, but driven with lots of other data. And the A2VGA correctly updates the video output (so data is driven from the 6502 all the way to the A2VGA). The only connection I could see is that the PICO might be slightly faster in responding, when the same address is read again (CPU cache, or maybe it doesn't even need to look the data up, when a read request matches the address of the previous).
Hmm, maybe an issue with the change of the v1.3 PCBs? That's an obvious change with my boards compared to everyone else's here. He removed the 1N4148 diodes and adapted the resistors at the voltage dividers. These affect R/W, PHI0 and the Select signal (from the GAL, or just hard-wired to "DEVSELECT" when "NO PLD" is set). The resistors at the volatage dividers are now about double what they were with the v1.2 version. That would also make signal changes slightly slower.
Yes, perhaps it would be a good idea to try with a stronger-driving voltage divider.
I though the whole idea behind the Shottky diodes in v1.2 was to prevent the signals from propagating in the opposite direction. Not sure why this is no longer an issue in v1.3.
In theory that could be problematic when the chips are powered with 3.3V, while the inputs are at 5V:
HC_HCT_InputDiodes.jpg
The diodes for the I/O signals were not Schottky though - he had them marked as "4 x 1N4148". (Yes, he still used a Schottky diode symbol in the schematic, probably a copy&paste issue. Or, since he added an unnecessary label "Schottky" next to the power-supply's Schottky diode symbol, he probably wasn't aware of the symbol difference for normal vs Schottky diodes).
The 1N4148 drops 0.7V - or at that light load a bit less, maybe 0.5V. The resistor divider is 5/7 - so that combination dropped the TTL level to just below 3.3V. (If you used Schottky diodes for D2-D5 then your signal level would be above 3.3V - and you would need to adapt the resistor divider).
A2VGA_Diodes.png
On github he comments on removing the 1N4148 diodes:
"In this v1.3 the 4 diodes on the voltage dividers were removed as redundant and the values of the voltage divirer resistors were updated."
Many Schottky diodes (like the BAT41 that I suggested on the previous page) have a voltage drop of 0.5V at 1mA and would work perfectly. Also it doesn't need to be exactly 3.3V. As long as it’s over 2V, the Pico will register it as HIGH.
Ok, I think I'm seeing the issue. I currently wouldn't recommend building the v1.3 version - or the v1.4, which seems to be shrinked PCB version of v1.3.
This is how PHI0 looks (red: Apple II bus, blue: at PICO input behind resistor divider):
A2VGA_v1.3_PHI0.png
I will later test this with the old diode/resistor design. I might get away with just changing this for PHI0, since the timing for the other signals is slightly more relaxed. I might also add a bodge with a MOSFET, just for the PHI0 3.3V conversion, if necessary.
Fun fact: Looking at the TTL level of PHI0 on my Apple IIe - I could actually just remove the resistors and hardwire PHI0 directly to the PICO's input. The maximum TTL level on my bus is barely clipping 3.3V anyway... :)
MacFly, if you do not have and would like a 1.2 pcb just shoot me a PM and I'll mail you one to look at similarly.
Wow, PHI0 seems very low on your machine and that could be the cause in combination with the weak voltage divider. For comparison, here is how PHI0 looks on my Apple IIe with the probe in slot 7:
Newfile9.png
This is with 4 cards in the slots: 80 col/memory card in the AUX slot, ESP32 SoftCard in slot 1, Apple Mouse II Interface in slot 4 and Dan ][ Controller in slot 6.
Well, what was planned as a quick Saturday afternoon soldering job, turned into a full-fledged analysis and debugging session again. But I'm not complaining... ;-)
@skate323: Thanks a lot for the PCB offer. Very kind. :) It's not that bad with the PCBs though: the v1.3 PCBs can easily be reverted to the v1.2 schematic - just a matter of soldering the diode & resistor upright (one leg of each in the PCB, and with the other leg/hand "high-fiving"). Also, another minor issue: I'm in Germany... :) And these days the overseas postage even for an empty envelope is usually more than ordering a complete set of fresh PCBs from China... Crazy, but true... :)
@CVT: I currently don't even have other cards in my machine, the power supply is spot on, and there is no significant resistance in the trace, which would cause a voltage drop on the mainboard. On the IIe the PHI0 signal is produced and distributed directly from the HAL. The signal looks good (sharp edges) and 3.3V is well within the allowed range for a "5V TTL high" level. So it's a perfectly valid signal - I can't really blame the HAL to be at fault.
So, I reverted the PCBs to the old v1.2 design. The signals look better. Access to the slot ROM now works (= the bus read emulation). And the configuration utility is detecting the card.
This is how the signals look with the v1.2 resistor/diode combination:
A2VGA_v1.2.png
Much better. The rising edges are much sharper. This is what the main issue with the v1.3 design was. The rising edge of PHI0 starts the read emulation. This needs to work perfectly, due to the tight constraint that the PICO emulation routine needs enough time to be finished within the 500µs active phase of PHI0, otherwise the 6502 would not read the correct data.
However, the falling edges are still not great. And that's because of the diode. The diode prevents the signal from being actively driven to LOW. It's just the resistor in the divider which can slowly "discharge" the PICO's GPIO pin.
This will also cause an issue - even if this won't be immediately apparent. The falling edge of PHI0 takes about 100ns to fall below the TTL LOW threshold. This will cause the databus output transceiver to be enabled for too long. The A2VGAs PIO code mentions that, according to the spec, a device must be off the databus within 20ns after the PHI0 falling edge (the calculation in the firmware tries to time this at 12ns after the falling edge). But that is all wishful thinking, when the falling edge is so sloppy, that it takes almost 100ns before it drops below a level, at which the PICO could even detect the change.
So, I removed the diodes again. Went back to a resistor-only design, like the v1.3 PCB originally meant - but used lower resistor values:
A2VGA_nodiode.png
This is better. Still not perfect, but rising and falling edges are both sharper now. And read emulation still works as with the diodes.
Admittedly, at this point I'm no longer such a big fan of this simplified PCB design. The problem is that it involves a trade-off, which has no perfect solution:
If you check the original A2VGA PCB, it simply used a fourth 74LVC245 to convert the bus control signals to 3.3V. This may have seemed a bit wasteful (one more 8bit transceiver, just to convert 3 extra signals). But if you now look at all these issues... it was just a much more solid design. The transceivers only cause negligible load on the Apple II bus (so it should work in any machine), and they produce perfect 3.3V TTL signals to the PICO. So, yeah, the original design certainly was better in that respect. And an additional 74LVC245 is just be about 2 bucks extra. Seems to me it would be worth it...
Ok, finally: one more thing... One more problem. :) As I said, the config utility is working now. It detects the card. I can make configuration changes, like changing video modes (colors). Or uploading and selecting fonts. However: on my card this changes nothing. I can set it to "green monochrome", but it stays just as it is. If I switch off the machine, then it still shows what I have configured ("green monochrome", for example). So it has certainly saved and restored the setting correctly. But the display is still as before (in white/color). Same applies to the fonts. I can select a different font, it remembers the setting in the config utility. But it doesn't have any effect.
That's weird. I don't think that's still an issue with the bus - since the config tool is working otherwise. And it is able to display what I had previously configured after power-cycling the machine. So "it knows" what I had configured. Just weird that this is having no effect...
=> Has anyone else succesfully used the config tool to change the font, for example?
Take a look at Vince Briel's version. He just uses a 1K resistor in series (R10) and that's it! No voltage dividers and no extra chips:
https://github.com/Retrotink/Apple-II-VGA/blob/main/Design%20Files/AppleIIVGA.pdf
A bunch of us built this card - no issues whatsoever with the signals.
Using series resistors doesn't convert 5V TTL to 3V3 levels—what it does is limit the current through the pin protection diodes built in to 3V CMOS chips. And this "conversion" only works in that direction.
Precisely, it's not a 5V to 3.3V conversion and no one is saying that it is. But the Pico seems fine with it.
Yeah, the Briel version of the card is very simple and easy to build and the video output is the same as the Ralle Palaveev cards. Of course it can't do the Z80 emulation because it doesn't use a PLD, but not everyone is interested in that.
Absolutely, but my point was to try the same approach in v1.3 of Palaveev's card. Just put 1K (or maybe 5K) resistors for R19, R20, R21, R22 and leave R15, R16, R17, R18 unpopulated.
Interesting. Given the Briel card works fine, I would think you may be correct.
Ah, very good hint. The reasoning behind the Briel design may have been along the lines what I mentioned above - that the actual TTL high levels on the Apple II bus aren't really too far above 3.3V anyway.
I'll also check if it's necessary to consider R17/R21 separately. When the GAL is present, that divider takes care of a signal generated by the GAL locally, and not a signal from the Apple II bus, like the other dividers (nor did the Briel design have the GAL).
The GAL, however, is able to drive 4mA. So, for this signal, when an actual divider was still necessary to reduce the level, the resistors could be reduced considerably (even down to a 1/10th of what they are now in the v1.3 design) and the load would still be within spec (for an ATF22v10c).
I'm going to test these variants and make some measurements to compare. But this will take a few days before I have time to look at it again.
No one responded to my earlier question whether the A2VGA configuration utility was actually successfully changing the settings for anyone. But after some investigation today, I know the answer. It really puzzled me. I assumed this was still some kind of issue with the signal levels of my card. But no. The configuration utility is broken - actually in multiple ways. It's weird since it's not specific to the Palaveev variant of the card, but it affects all A2VGA variants. Since that's a popular project, I assumed it's impossible that something so basic wasn't working at all and could have remained undetected since May. But apparently no one tried the config utility - or just didn't complain. Indeed, the normal and plain VGA output is probably all what most people really want from this card anyway.
I need to open up github issues for the problem with the config utility. If someone wants to give it a try - I have attached a fixed version of the config disk:
So now you can configure the colors, fonts etc. For example, you could now set the Apple II to "C64" color mode - and select the "Byte" font (Gaaaaaa! :) )...
A2VGA_Config.jpg
Unfortunately some of the fonts still don't work. That needs another fix which affects the firmware of the PICO itself. Admittedly, once I had already traced it to the affected line, I took me longer to spot the issue than it should:
A2VGA_Fonts.png
If you're also not seeing it immediately: think about what happens when you set font 0x10 (=param0) and then mask it with 0x2f... ;-)
So it's the fonts 0x10 to 0x1F which are still not working at all (German/French/Greek etc). That also needs a firmware fix with the corrected bit mask (the bit mask cannot be 0x2f, of course, but needs to be a proper value of (2^n)-1, like 0x3f)...
Concerning the resistor dividers discussed above:
Ralle has uploaded a new schematic for his latest PCB version yesterday. He now went back to lower resistors, similar to what he had in the v1.2 PCBs, but still omits the diodes:
A2VGA_ResistorDivider_1.4.png
These will work fine and produce sharp rising and falling edges. Disadvantage is that these will put a bit more load on the common signals.
Here's what I have decided to be the final solution for my own boards:
A2VGA_ResistorDivider.png
So I removed R15+R18 and used 1K for R19+R22 - that is for the PHI0 and R/W signals, which are shared between all slots and between many other ICs on the mainboard. So I'm using the approach of the Briel card here, which avoids the resistor divider. Advantage is that this barely adds any extra load on the shared signals while still producing sharp edges required for proper bus timing. And the maximum logic level of these signals isn't even that much higher than 3.3V (at least on my machine), so a divider wasn't really needed anyway.
I kept the divider R17/R21, and used similar lower values to what Ralle is suggesting now. This is for the SELECT signal. This is either a local signal generared by the GAL (ATF), or otherwise the slot-specific DEVICE_SELECT signal (if you're omitting the GAL and setting the NO_PLD jumper). In either case that signal is not shared with anything else, so the divider isn't going to interfere with anything - as long as the load is something that an LS-TTL IC (or the GAL) can drive. And since I had the GAL installed, the logic level of this signal was just above 4V. So, maybe a divider to reduce the level isn't so bad in this case.
And don't worry about R16/R20 for the RESET signal. This can be slow and the high value resistors are fine.
Great stuff everyone :)
Does anyone know off hand what the V2-Analog-RGB9-20230504 version is? It's in among the VGA and Z80 firmwares.
Not sure I understand your question. V2-Analog-RGB9-20230504.zip is the latest firmware release ZIP archive. But you also already linked to this in your blog post.
Pages