Apple II VGA PCB

[swetland]

I recently bought an Apple IIe on ebay and was thinking "maybe you could do a video card by just snooping bus writes"... a bit of searching trying to figure out if that was feasible landed me here where I got my answer along with "and it's already been done."

I thought it'd be fun to build one and I'm not fond of working with perfboard so I fired up KiCAD and ended up with this...

I kept the design very close to the original, so I could try the firmware with minimal changes. I used four buffers for all the bus signals to reduce the number of IC types needed, and the board can be configured to make D0..D7 input only and route SYNC to the Pico instead of direction control for D0..D7 as an option to explore trying to synchronize video updates.

[swetland]

My PCBs arrived from JLCPCB today (cost worked out to about $5.10 ea for the card and a stub for the rear panel, for 5 boards) and parts had arrived earlier this week, so time to put them together and see if things worked...

Two changes I'd make for the next revision: Fix the "1uF" labels to read "0.1uF" as they should, and make the card fingers section maybe 1-2mm narrower (the boards are rather snug in the expansion socket).

[swetland]

I disabled the read cycle part of abus.c and abus.pio and tried it out in the IIe with very positive results:

I'm planning on tidying stuff up and pushing the project to github soon (under some permissive license) and also thinking about doing a version with a TI TFP410 DVI/HDMI encoder as well -- could provide both VGA and HDMI from a single board, I believe.

[markadev]

Nice board, the output looks good. Thanks for sharing!

Those are some good trade-offs you made in the design for a more IIe focused board. I originally wanted to add Videx emulation for II+ 80-column support but not much software really used it so ultimately abandoned the idea. Without that there's not a good reason to keep the device read_cycle support.

Did I read that right, that you paid ~$26 for 5 PCBs with gold-plated edge connectors? Wow, I would've also taken that deal instead of hand wiring 😀

[abaffa]

All done! The code is tested and running on my emulator. Now I (or we) need to figure how to insert it to AppleIIVGA project. My code (notes and comments) here for further reference.

PS: It uses the videx firmware and two char roms in another file. It's necessary to download them here.

[abaffa]

I found an issue: we must revert the code to REV A in order to use GPIO10 as IN/OUT control to data.
I was having some progress but I got confused about how to write to bus during IOSEL/DEVSEL/IOSTB. It's necessary to read the firmwware/rom from the board and also the special memory page from videx.

@markadev @aaronsmithdev can you help me? if we're able to read data from the card I can finish it :)

// abus.c
//
// In the rev A schematic this pin was originally used to control the data bus pins transceiver direction
// so that bus reads could be responded to with data. This code has since been removed so the GPIO could be
// repurposed.
//
// A pull-down is set on this pin to remain compatible with these rev A based designs. This will ensure that
// by default the data transceiver direction in "inward".
gpio_set_pulls(CONFIG_PIN_APPLEBUS_SYNC, false, true);

[abaffa]

Good news... I read how to implement i/o from the V2Analog project. After a day working with timings, the apple2 is finally reading the firmware and responding when I type some trash. All data is stored in videx memory and I could revert the PR#3 using ctrl+z+1.

Now I need to adapt the vga rendering code to read the memory from videx memory array and draw the characters. This is the easy part.

[abaffa]

it's almost there... few bugs but running https://youtu.be/gcQpmpK4G-8
The bus timing is tricky sometimes.

[abaffa]

finishing this thread - all done. I found out the videx card is not compatible to grappler+ (printer interface) 'cos they share the same banking rom solution using I/O STB address. I had to remove my printer interface to have the videx running :D. Also, I decided to map slot 3 directly from the memory address in order to leave the devsel signal to change the character rom fonts. So the card can be used in slot 7 but it always maps videx card to slot 3. (Let slot 3 empty and the card in slot 7 will answer to both slots)

The code is available at https://github.com/abaffa/AppleII-VGA/ and I requested a pull #38 so Mark can verify my solution and suggest some project standards.

80 Columns mode on AppleII+ - Videos

[swetland]

I'm interested in playing with the read cycle stuff to maybe implement some kind of IO, network, or disk interface, though I think I'd probably want /IOSEL as well as /DEVSEL for that, so a slightly different board might be called for.

JLCPCB is rather impressively inexpensive and fast -- $23.50 for 5 of the main PCBs and $2 for 5 of the little VGA connector + header board (HASL not ENIG for those) for the rear panel. $17 for shipping. Six days from placing the order to boards arriving by DHL.

I love the "use multiple buffers to sample chunks of the bus in sequence" approach to conserving GPIOs and I am absolutely going to steal the idea for a ZX81 IO interface project to simplify things there -- there's a little less headroom at 3.5MHz, but I think it should still be workable (and I probably only need two buffers of capture, worst case, for that one).

I also changed the power setup slightly -- using the 3V3 out from the Pico to power the buffers and supplying 5V to the Pico's VSYS from the Apple II bus, using a P-FET to disable this if VBUS is present (per the suggestion in section 4.5 of the Pico datasheet).

[markadev]

Cool, yeah I think there's a lot of potential using cheap/fast modern microcontrollers like the Pico to build new or emulate older peripherals, like this project that emulates a full Z80 Applicard.

Fair warning that the current read_cycle implementation is not that good because the ARM core is just a little bit too slow to get the data into the PIO's FIFO in time reliably. A couple solutions I've seen are to overclock the Pico, or this guy's fascinating project where the PIO program emulating a ROM chip directly triggers a DMA engine & bypasses the CPU completely. There's definitely some interesting ideas to play with in this space 😁

[swetland]

I pushed everything to github here: https://github.com/swetland/appleii.vga

[markadev]

Hey Brian, I'm finally designing my own board now (with through-hole components) and you've already validated many of the changes I was thinking of making, so thanks very much for that! I'm planning to make your SYNC->GPIO10 connection the default connection, with cuttable jumpers if I ever want to reconfigure to experiment with read-cycle support again.

Also, the separate connector board is a great idea and makes the IIe installation very neat. It's a way better idea than what I was thinking of.

[swetland]

One thing to keep in mind is that clearance between the appleiivga board and the connector board can be a little tight. Using right-angle connectors helps a bit, but things could probably be arranged a little better than what I landed on for my first attempt:

[markadev]

I've made some PCBs and see what you mean now 😀. The VGA connector itself that I have is pretty deep so I'm not sure it's possible to use a right-angle connector without blocking a slot unless the pin header was below the VGA connector.

I didn't need slot 4 anyway so it works for me and I really like the clean look! If I do another PCB run then maybe I'll try another layout.

[swetland]

With the single-row 0.1" head, a right-angle on the main PCB avoids issues with an adjacent card -- I'm not sure if the problem is avoidable with the VGA connector board -- maybe with a slightly shallower connector and making the PCB as small as possible...

[swetland]

Looking at disassembly of abus_loop(), it seems like the compiler is inlining a lot of stuff and generating a fair bit of code.

When I was poking at my ZX81 IO project I wasn't even using the PIO, just having core1 implement the Z80 bus interface in a tight loop written in thumb assembly (this was easier because I wasn't running anything as intensive as VGA on core0), figuring I'd further optimize using the PIO later. The approach I took for reading was having a small array of register values so when a read happened the only work to do was use the low address bits to index into this array, push the value out to the Z80 bus, and flip a bit in a status register (which would be reset by core0 code later) so the Z80 could tell if it was reading things too quickly.

I think a similar approach may work here -- probably easier for custom new peripherals than for emulating existing hardware that may have more work that must be done between back-to-back bus operations than cycles available -- but the general model is to try to have the registers always ready to read so you don't have to call out to any other code during the read cycle.

It might not even require writing it in assembly... possibly something like this might be workable:

volatile uint8_t abus_card_register[16];

void __time_critical_func(abus_loop)() {
    while(1) {
        uint32_t value = pio_sm_get_blocking(CONFIG_ABUS_PIO, ABUS_MAIN_SM);
        uint32_t address = (value >> 10) & 0xffff;
        bool is_write = ((value & (1u << (CONFIG_PIN_APPLEBUS_RW - CONFIG_PIN_APPLEBUS_DATA_BASE))) == 0);
        if(((value & (1u << (CONFIG_PIN_APPLEBUS_DEVSEL - CONFIG_PIN_APPLEBUS_DATA_BASE))) == 0)) {
            if (!is_write) {
                // device read access
                pio_sm_put_blocking(CONFIG_ABUS_PIO, ABUS_DEVICE_READ_SM, abus_card_register[address & 0xf]);
            }
            // possibly signal that a read occurred, flip a status bit somewhere, etc...
            gpio_xor_mask(1u << PICO_DEFAULT_LED_PIN);
        }
        shadow_memory(is_write, address, value);
    }
}

I'm stuffing another board so I can use one for a display and a second as an experimental peripheral and try this out and see what there is to see.

[swetland]

So I tried this out and reads from the Apple IIe were unreliable until I commented out the shadow_memory(...) call. Looks like sometimes the time spent in there is enough to miss the window on responding to a following read.

I think one approach that might work would be to immediately process videoram writes, but queue softswitch writes to be handled during vsync ahead of the next frame. Though it's also possible that one could tune the shadow_memory(...) handling so it's fast enough to always complete in time for the next bus access.

[swetland]

Hmm. You need the softswitch writes processed to handle videoram writes, so deferring them is not going to work.

[swetland]

An excessively debug-instrumented Apple II VGA board (SWD debug probe, Serial to USB adapter, and big red physical reset button just in case):

We'll see if I can get away without stuffing the headers for connecting an oscilloscope or logic analyzer to the Apple BUS or not...

[marketideas]

So once you get this going, you might want to consider dropping the Pico board and going directly to an RP2040...you will get your extra GPIOs and can use 3 of them to add one more bit of color to each RGB. Thinking ahead for the iigs version.

[swetland]

Quick question on timing, @markadev -- I notice you figure an 18ns buffer plus clock input delay for rising PHI0 and 28ns for falling. Are those based on measured or estimated times from the '07, and/or do they factor in some data on general RP2040 input delays?

While tinkering with the PIO programs to handle IOSEL as well as DEVSEL (I've now got a readable "rom" at 0xCn00 as well as the register bank) I noticed this and realized that the tPHL/tPLH on the 74LVC245As (which I'm using for the clock) are not asymmetrical and also faster (2.9ns typ, 6.3ns max), so I may want to slightly tweak these for my board. I probably should just put a scope on it and see exactly what's going on, but I'm still curious for the basis of your timing computations.

Thanks!

The experimental scanline effect looks nice. I wired up /DEVSEL 0xF as a toggle so I could flip it on and off from the IIe itself, but I'm thinking I'll probably end up leaving them on.

[markadev]

Hey there. That 18ns figure includes an estimated delay through the the 74LS07 but also a measured delay in the RP2040 inputs.

With my scope I was measuring the time from the buffer's output going high to the time that other Pico outputs (like the transceiver controls) were changed by the PIO program. Since the PIO timing is so deterministic any unaccounted for time I just called "input delay" and then added in the 74LS07's tPLH (6ns typ/10ns max). IIRC I made the same estimation on the PHI0 falling edge, but with 74LS07's tPHL (19ns typ/30ns max).

Very cool that you could get both IOSEL and DEVSEL reads working!