I've just built one of these:
∀2 Retro Computing - Analog (v2retrocomputing.com)
And I have to say the output is beautiful compared to composite, here are a couple of pics:
As soon as I have time, I will be building a second as it can also emulate an Applicard Z80 CPM board.
What did you use to program the PAL?
Adrian also did a pretty awesome video on this: https://youtu.be/ReTXGczq8Vk
In the end I couldn't program the PALs with my TL866 Pro and I used a GAL16V8B instead and it works just fine.
The BoM has appeared on the repository ans is now suggesting ATF16V8C-5JX which are apparently still available.
It was seeing Adrian's video that prompted me to build one, and I'm going to build another to use as an Applicard Z80 CP/M adapter.
Still haven't resolved my 80 column/RAM card issues, but the base machine runs and tests perfectly now and is good enough to test the cards.
ATF16V8 is often used in place of GAL16V8 from what I've seen [in arcade repair]
I also was lucky enough to obtain one of these cards, and I concur, the output is stunning.
I've just built a 2nd to use as an Applicard, we'll see if the GAL 16v8B works again as I had 2 :)
The ATF16v8s seem hard ish to find too, GALs not so much.
GAL16V8D is usually my go to even though digikey and such don't stock it anymore.
I have had no trouble finding Atmel or Lattice 16V8 not any issues programming them with my Minipro TL866-II. I don't use the Windows software though (don't have Windows), I use the Open Source software on Linux.
I'm about to build one of these too, hopefully this weekend. Also went with the ATF16V8 instead of the GAL, and plan on using a TL866 to program it as well. I have a GQ 4x4 as backup so we'll see how that goes. Did you just use the existing batchfile and wcupl to build it as is? Did you have to update the device when changing to the ATF16V8?
I sourced the wifi Picos for the project as well - I see there's a wifi firmware, but not much documentation on how to use it...
I haven't done much work on the WiFi side of the firmware. The -LC firmware leaves out the wifi libraries and hardware initialization, which is all of about 8 bytes difference at this point. You are unlikely to see any difference between the -LC or -WIFI firmware builds on either PicoW or Pico boards, especially the -VGA builds. It is on my roadmap to have WiFi and/or bluetooth usable in the near future for the Z80 builds but it may come at a cost of emulated Z80 speed.
I made some progress last week on implementing the UARTs into the Z80 firmware. There are two virtual serial ports, the intent was to have them working over USB for use with ADTPro and other software, or attachable to either a WiFi modem or printer implementation. So far they appear to be working at a surface level for loopback only until I (or someone else) writes code to do the modem and/or printer. Both serial ports are available from the Z80 and the 6502 sides, so they should eventually be usable with terminal software under CP/M (included on the PCPI disks) or 6502 terminal software that has been patched to use one of the ports.
This week has been lots of effort getting Video7 emulation working, and trying to tweak various video color encodings to get the best possible picture in each mode. I've almost given up on trying to improve the HGR video, though for some games the new interpolation does look better at times than the old method, but the old method usually results in easier to read text. Because DHGR directly encodes the raw dot patterns, its not as easy to do a sliding window lookup the way the old HGR implementation does. I'm welcome to any help others may offer in the way of a simple sliding window interpolation that works on the raw 560 bit scanline (with a window of no more than 32 bits) that can be implemented in only a couple lines to generate good looking results for DHGR. At the moment the choices are basically a 140x192 naieve chunky mode, or a sliding subpixel implementation that blends adjacent pixels and has optional vertical aperture simulation. The various color implementations can be switched with the card's $C0n1 register lower 4 bits. $8 turns on the old color implementation, $4 enables Video7 features, $2 and $1 affect the new interpolation.
I've been slowly working on writing some 6502 ROM code for the 80-column card implementation for Apple II/II+ systems, but its been a while since I did major 6502 asm work and its taking time to finish.The actual serial stream parsing is done on the RP2040 while waiting for scanline buffers to render, so all the 6502 side firmware really needs to do is patch the keyboard input to gain lowercase, and shove characters into the card's FIFO endpoint as long as there is room for it. I went this route because of the difficulty in implementing bank switching fast enough for the videx or other 80-column card firmware. Offloading the terminal emulation to the RP2040 means theres no need for the 6502 to read from a paged window representing the card's text buffer. Large portions of the 80-col firmware will probably be reusable for the serial / parallel card emulation ROMs as well.
I also have been developing a GS version of the card with 12-bit color, a larger CPLD to do the needed GS specific bus qualification and better $C800 handling, and the ability to overlay ROM images over other slots (so the serial ports could have ROMs in slots 1 & 2, even if the physical card is in slot 4 for Z80 emulation) as long as all the slot ROMs can share the same 2KB $C800 bank or are written in such a way to wait for a bank-switch operation to complete on the RP2040. The card also moves the VGA connector and resistor DAC to a panel mount board that connects with a cable. Other I/O modules can be swapped in on the GS version for things like real RS232 serial ports or a ESP32/ESP8266 WiFi module (leveraging existing WiFi modem firmwares).
-DK
I did a similar patch to the //c and //c+ ROMs to allow use the FijiNet PRINT and MODEM ports. The ROM redirects PR#1 and IN#2 commands for wireless printing and use of the built-in Terminal program. Unfortunately, some printer and most communication software wants to talk directly to the built-in serial chips so that limits its usefulness.
If you can emulate the hardware on one of the standard interface cards of that era you should be able to make this all work!
It does emulate a pair of UARTs on the upper 8 bytes of the I/O window for the card. On the 6502 side each is presented as a 6551. On the Z80 side they appear as a Z80 SIO / DUART chip (emulating this addon: https://planemo.org/2012/07/29/high-speed-serial-port-for-the-apple-ii-pcpi-applicard/ ). Both sides access the same FIFO, so you should only have software attached to one or the other, not both at the same time.
So I take it the V2 Analog project is dead? There hasnt been a real firmware upgrade in one year and the tindie store shows the item is discontinued. I really thought this was going to be a game changer, then it went dead. What happened?
It is was a game changer and it was branched and continued by others:
https://github.com/rallepalaveev/analog
https://www.applefritter.com/content/a2usb-apple-ii-usb-mouse-interface-card-emulation
https://github.com/rallepalaveev/a2pico
I am aware of those but they are all still based on the firmware of the original. And other than mouse suppory its still been dormant/dead a year.
ABuy yeah great card. Beautiful video output.
The A2Pico's firmware was last updated 2 month ago. The others - maybe they just work well enough and there is no need for updates.
And of course there is the A2FPGA Multicard, which is also loosely based on this.
The A2pico is a different fork of a different project altogether. Im referring to all the projects based from the V2 analog.. not just cards that use the pico.
The v2 analog made mention of further updates including iigs graphics support. It never came to be.. so again my initial question what happened to stall the project since something happened to hinder development.
The A2Pico is not different. They are all based on the original AppleII-VGA, which came up with the Pico bus interface. The V2 Analog project simply added the GAL/PAL chip, which you don't need for VGA. For Apple IIgs VGA support, you should probably ask on GitHub, both the original project and the V2 Analog one.
Btw, the A2FPGA Multicard gives you HDMI on the Apple IIgs and it's available on backorder. If you want that, I am sure you can get it way before any of those projects above add VGA to the Apple IIgs.
1111.jpg
As you can see Its a completely different project not linked to the original v2 analog in anyway. So unless you can explain where you think its connected its just mucking up my question.
22222.png
No, I am seeing this information in the schematics of all the cards. They are all based on the original AppleII-VGA project, which I have been following from the beginning. Vince Briel's Apple-II-VGA, which I have not mentioned yet, is too.
It is important to give due credit the project that started it all, even though it is not very obvious from all the branches that have sprung.
Ok fair enough. If thats the case I really think they ought to include that in thier repositorys since it borrows from someone elses work. I take it at its core its how it interfaces with the Apple II bus rather than the end functionality of the cards (vga, mouse, HDD controller).
Can I flash a a2Analog card with one of the newer firmware?
No harm in trying! I use mine for a wireless mouse.
Indeed, I haven't heard from David (a2Analog) for months. When I sent him the first bugfixes, he replied, he would take a look and merge these, but that he had currently packed his A2 gear away, so it would take a while. Seems he's busy with other interests, family matters or whatever. Nothing wrong with that. Working on retro projects is a hobby for (almost) all of us. You can't complain when someone doesn't continue his work - or it takes almost forever. No one owes you or us anything. All you can do is ask nicely... :)
I have worked on other (non-retro computing) open source projects before. It's normal to loose interest and move on with hobbies. That's why it's a really good idea to develop such projects as open source - especially for such "one man projects". That gives a chance to others to pick up and continue. "Closed source projects" eventually (some day...) result in all the effort being "lost". No one else has a chance to continue (unless they re-invest the same or more effort for reverse engineering).
Concerning a2pico: those who saw the initial a2pico presentations at Kansasfest 2023, would still have seen a quite different hardware design (no bus transceivers). But the latest hardware iteration became more similar (again) to the A2VGA design, using the well-known 74LV245s again. Ralle and Oliver had been working on this. But there are differences with a2pico - and it's not a direct variant of the other VGA projects (firmware is not a derivate, the PIO code for a2pico is new and also works quite differently). But of course, the fundamental idea of using the PICO's blazingly fast PIO state machines to directly interface the Apple II bus is the same (bus interfacing is, however, one of the PICO's application examples, so that's exactly one of the ideas the original designers had in mind, when they combined the PICO's ARM cores with those fast PIO machines).
Finally, I have a variant of the A2USB mouse firmware for A2PICO. Oliver and Ralle were so kind to send me one of the A2PICO prototype PCBs, even months before it was released. It's in my "queue"... Unfortunately, I also got caught with other stuff and haven't had much time to spend on retro computing in recent months. Ralle and Oliver are probably already annoyed that I haven't finished and released the mouse support for A2PICO yet. But, see above: it's a hobby project for all of us. You can't complain or demand anything. All you can do is ask nicely... :)
This is often the case when one project becomes aware of another, sees something similar being done in a better way and adopts it. But the reason I consider Mark Aikens the progenitor of this Pico revolution (which is spilling to other platforms) is because his VGA card came more than a year before Kansasfest 2023 and it already had the design that everyone later converged towards.
In post #24, "MacFly" wrote:
" That's why it's a really good idea to develop such projects as open source - especially for such "one man projects". That gives a chance to others to pick up and continue. "Closed source projects" eventually (some day...) result in all the effort being "lost".
Uncle Bernie comments:
Making any project "open source" before it is mature is no good. People will grab your still imperfect source code off github (or elsewhere) and start to mess with it in an (most often) well-meant attempt to add things that are lacking. And then they encounter problems and start to bug you by "message" or "email" etc. about their mods / adds not working with your code. This is such a theft of time that you will wish to never have posted the source code.
But I agree that to make a project live beyond the life span (or interest span) of the original author / developer, it must be made "open source".
The trick is to find the right point along the development trajectory to post your source code. With my stuff I decided to post its source code when it's mature, so it does not lack anything I'd want to add (or take away). In some sense, if it has reached a certain point of perfection.
You can also see this whole topic from the stand point of an artist. Say, Leonardo Da Vinci. What would he say if somebody bought his "Mona Lisa" off his hands and then proceeded to make "improvements" to it, by means of paint and paintbrush ? Yikes ! But since he is long dead, he can't complain about "improvements" done today. Which, BTW, happens a lot with old paintings or objects of art in general, in the attempt to preserve them. Not sure if any such "restoration" work was done on the Mona Lisa painting, but you get the idea.
I leave the discussion of whether a software program (or any technical device in general) can be construed to be an "object of art" to you, the readers. But I hope you can see the validity of my point.
- Uncle Bernie
Totally seconds @macfly here on the open source thing. I don't touch projects that aren't fully open source, and I insist on releasing everything as MIT licence myself as well. There are so many projects that just are flash in the pan. This a2Analog card is one of them BTW, enough to spark huge interest, including youtube channels, but by the time I had mine done it had fizzed away. And I don't *mind* that either, but it'd be nice to have something saying 'Okay guys, lost interest -- or got married -- or whatever) instead of just ghosting the community, really. At *least* we got the bits and someone else picked it up and made it better, that's not the case for many other projects. I got a WHOLE stack of open source project I haven't touched in a century. And I don't feel bad about it either. If I get PR, every few months I merge/discuss/refuse etc but I haven't contributed *major* stuff in a while. It's OK really.
Recently I asked about that fancy new FPGA board that has been discussed a lot recently, and basically it *looks* like open source, but it isn't. The base board isn't. The CPLD isn't. It's a dead cheap board with a $10 CPLD on, but it basically locks the project out of being open source. Just so the boards can be sold for $200 instead of the $50 of parts. And please don't tell me about "oh but they have to pay themselves for the work" it's ridiculous. The device you are reading this webpage on wouldn't *exist* without many people (me included) spending their talent and time for free for tools to make it all possible. Do you think "Chrome" and "Webkit (aka safari)" came out of a vaccum, and the megatons of underlying technology, not even mentioning the compilers that that are made with -- the list is long!
I totally agree with @UncleBurnie in Post #26.
Furthermore the only time you can complain about someone else's project not being open source is if they start it that way and then all of a sudden make it closed source. In all other cases it's completely ridiculous. If you don't like people using your open source code in a commercial product, simply choose the appropriate license upon releasing it.
Besides if a board is $50 of parts, how much do you expect a maker to ask for it fully made and tested? Also $50 ??