Bird's nest...

[aotta]

Simply.... wow!

Please keep us informed!

[JohnPCAE]

It's slow going. Last night I fixed the visual glitch on the screen that had garbage along the left edge and everything shifted to the right. And it took 8 hours today to track down an intermittent visual glitch. It involved a complex interaction between memory-mapped I/O at $4006 (on the 6502 side), 60Hz interrupts, keyboard-scanning and string-display routines (the routines reuse the same temporary variable). What I would do for a full schematic of the Keyboard Component so I could better determine which memory locations are memory-mapped I/O.

[JohnPCAE]

It's hard to get good pictures on a CRT but here's something else I've got cooking. Follow the keyboard cable up, then look at the screen.

 

KB: 0001

Keyboard detected

 

MOU: 0000

No mouse detected

 

KEY: 1D02

Last key-code detected: 1D ("z"), with left-shift depressed ("02").

 

Since this is working I think I'll first get this working with the ACC+KBC emulation, then I'll write some ECS keyboard-scanning code that returns the same key codes. And that way, both types of keyboards will be supported.

 

[aotta]

Impressive! but please give us some futher info on your ecs emulator... is an evolution of previous ACC or something new?

[JohnPCAE]

It's merely a software change. The ACC uses a Pi Pico, which is a dual-core microcontroller. It began life merely providing enhanced graphics using the Inty's video overlay pin (the same way that the Keyboard Component does), except that the ACC can do it in color and can provide a slew of different screen modes. One core outputs overlay video and nothing else. The other core listens to the Intellivision bus so the Inty can control the ACC, but it has so much spare time that I also use it to emulate a coprocessor (an enhanced version of the Inty's own CPU). But there was even more spare capacity for the software to grow, so I added new coprocessor instructions that can perform the same logic as most 6502 instructions (the CPU that's in the Keyboard Component). An then since it already provides overlaid video, I added an extra video mode that emulates what the Keyboard Component does. And then the final step is porting the Keyboard Component 6502 ROM to use the ACC's emulated CPU instructions instead (which is mostly a one-to-one conversion, with some caveats). That ported ROM doesn't need to be bundled in the ACC; rather, a bootstrap program in a cartridge loads it into ACC memory and starts the ACC coprocessor. It also loads the CP-1600 Keyboard Component ROM into Intellivision memory (at the usual place, $7000) and stats it running. That ROM has to be very slightly modified to support this architecture (it has to do with loading ISR's, Interrupt Service Routines) but is otherwise 99.99% the same as what's in the original Keyboard Component.

Edited November 21 by JohnPCAE

[aotta]

So it continue using the ext video for output? I use modded video output Inty, and that's why i passed your previous offer of ACC

[JohnPCAE]

This definitely won''t work with an RGB-modded Intellivision as that completely bypasses the Intellivision output circuitry, and the video overlay pin requires it. Neither the ACC, the Keyboard Component, nor the System Changer can work with an RGB-modded Intellivision. It will work with a composite-modded Intellivision, as seen above. I don't know if it will work with one modded for S-Video (do they even exist?) but I doubt it. The rule of thumb is, if your Intellivision will work with the Keyboard Component, then it will work with the ACC. They use the same video overlay pin.

 

The ACC does provide a separate digital output of its video info before they get converted to analog. There's a connector in the middle of the board that allows access to this info. I did this specifically so that someday it might be possible to build a box that could combine it with an RGB-modded Intellivision's output. The connector provides timeslice, timing, and clock output signals. The timeslice info is output exactly the same way that the 8915 color chip in the Intellivision does, except that it provides eight bits of information instead of just four, for much finer control (unlike the color chip, the ACC's color palette is programmable, so fine control is needed). So on each scan line it outputs 640 bytes of timeslice information, corresponding to four timeslices for each of 160 pixels across.

Edited November 21 by JohnPCAE