Video Repeater

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
lb3361
Posts: 109
Joined: 17 Feb 2021, 23:07

Re: Video Repeater

Post by lb3361 »

Hi Hans61,

Spi is supported in ROM v5a through extension SYS_SpiExchangeBytes_v4_134 at https://github.com/kervinck/gigatron-ro ... m.py#L3021 and its implementation at https://github.com/kervinck/gigatron-ro ... m.py#L3660 . A good example of this happens when the Reset code decides whether to boot a SD card or to start the usual MainMenu. See the well commented GCL code at https://github.com/kervinck/gigatron-ro ... t.gcl#L133 .

I am looking forward to building one of your combined cards when they come. That said, I fully understand what you mean when you speak about the insufficient number of hours per day. I spend far too many on the C compiler. I can compile fatfs which is a good start for really using the SD card at SPI0. But I won't have have the hours before a while...

- L.
Hans61
Posts: 48
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: Video Repeater

Post by Hans61 »

@lb3361 thanks for the info, it took me some time to understand the GCL notation and thus the code.
I have now managed to connect the MCP 23S17 to the Gigatron and have 8 LED's flashing.
https://www.youtube.com/watch?v=DepDiEJabMI

Here is my code:

Code: Select all

;    00111100   0x3C  all off
;    00110100   0x34 /SS1 active
;    00111000   0x38 /SS0 active
;    ^^^^^^^^
;    |||||||`-- SCLK
;    ||||||`--- Not connected
;    |||||`---- /SS0
;    ||||`----- /SS1
;    |||`------ /SS2
;    ||`------- /SS3
;    |`-------- B0
;    `--------- B1

SYS_ExpanderControl_v4_40   EQU     0x0b09
SYS_SpiExchangeBytes_v4_134 EQU     0x0b15
Temp                        EQU     0x81
Counter                     EQU     0x83
Data                        EQU     0x85
sysFn                       EQU     0x22
sysArgs0                    EQU     0x24
sysArgs2                    EQU     0x26
sysArgs4                    EQU     0x28
sysArgs6                    EQU     0x2A


        ; set counter to start 0
        LDI     0
        ST      Counter
        
        ; switch /CS on
        LDWI    SYS_ExpanderControl_v4_40
        STW     sysFn
        LDWI    0x8034
        SYS     40
        
        ; send to SPI 0x40 0x00 0x00 (23S17 IODIRA 0x00=all Output)
        LDWI    SYS_SpiExchangeBytes_v4_134
        STW     sysFn
        LDWI    0x0040   ; 0x40 0x00
        STW     Data
        LDI     0x00     ; 0x00
        ST      Data+2
        LDWI    Data
        STW     sysArgs0
        LDWI    Data+3
        STW     sysArgs2
        SYS     134

        ; switch /CS off
        LDWI    SYS_ExpanderControl_v4_40
        STW     sysFn
        LDWI    0x803C
        SYS     40

loop    LD      Counter  ; increment counter
        ADDI    0x01
        ST      Counter

        ; switch /CS on (without switching off and on again the 23S17 does not work for me, IOCON register default=0 Byte mode/Sequential mode ???)
        LDWI    SYS_ExpanderControl_v4_40
        STW     sysFn
        LDWI    0x8034
        SYS     40
        ; send to SPI 0x40 0x12 Counter (23S17 GPIOA Counter (IOCON.BANK=0 default))
        LDWI    SYS_SpiExchangeBytes_v4_134
        STW     sysFn
        LDWI    0x1240   ; 0x40 0x12
        STW     Data
        LD      Counter
        ST      Data+2
        LDWI    Data
        STW     sysArgs0
        LDWI    Data+3
        STW     sysArgs2
        SYS     134

        ; switch /CS off
        LDWI    SYS_ExpanderControl_v4_40
        STW     sysFn
        LDWI    0x803C
        SYS     40
        
        LDWI    -1000    ; set time for wait a moment
        STW     Temp
wait    LDW     Temp     ; delay
        ADDI    0x01
        STW     Temp
        BNE     wait
        
        BRA     loop
I also made a board. But I already noticed that a ground connection is missing in Rev.1. You should not put quickly made board's into production late at night. It's easy to fix with a wire, but I don't think it's pretty.
The board should arrive early next week. When I have tested it I will post the revised version (I think next weekend).
The spacing of U36 and U37 means it is no longer in the 100mm x100mm limit. I also made the SD card connector the same position as the board with the two GAL's. The reason is, I already made a routing in my wooden case at this position.
With the video repeater you can choose with a jumper between 3 or 4 video lines or the control over port B bit7 of the MCP23S17.
The two ports of the MCP23S17 I put on pin connectors 2x5, so that they can be easily led out with 10 pin ribbon cable and pressed connectors. As pinout I chose Pin1=+5V, Pin2..9=Bit0..7 and Pin10=GND. The board is also congruent with A15. For changes or better suggestions I am gladly ready.
FIFO+Expander-Rev2-brd-t.png
FIFO+Expander-Rev2-brd-t.png (337.75 KiB) Viewed 4974 times
LED_Test_PIO_1.brd.png
LED_Test_PIO_1.brd.png (114.51 KiB) Viewed 4974 times
I also saw the discussion about 6Bit audio. I would also extend the board up to U38 and integrate a DAC with 8 bit and an additional audio jack. In that case I would connect the flashing lights to the MCP23S17. The board would then also become so large that I could provide a second MCP23S17 (does not have to be necessarily equipped).
I don't know if a MCP4802 8-Bit Dual Voltage Output Digital-to-Analog Converter with Internal VREF and SPI Interface would be an alternative. I think the control is getting too slow on the Gigatron.
Attachments
FIFO+Expander-Rev1-sch-s2.png
FIFO+Expander-Rev1-sch-s2.png (123.74 KiB) Viewed 4974 times
FIFO+Expander-Rev1-sch-s1.png
FIFO+Expander-Rev1-sch-s1.png (78.17 KiB) Viewed 4974 times
lb3361
Posts: 109
Joined: 17 Feb 2021, 23:07

Re: Video Repeater

Post by lb3361 »

Cool. This seems pretty packed...

> The spacing of U36 and U37 means it is no longer in the 100mm x100mm limit ...

I guess you mean vertically ?
It seems that the board extends horizontally well beyond the out register, above the audio jack, but not far enough for XOUT and the audio.
Hans61
Posts: 48
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: Video Repeater

Post by Hans61 »

With the 100mm x100mm limit, I was referring more to the price at the PCB manufacturer. For me, this is not really decisive, but for the wider distribution, I think so.
I currently have JLCPCB manufacture, there it does not hurt so "hurt" if one has made a mistake.
My first version of the board was delivered today. I had to assemble and test it right away.
In the first impression everything seems to run well, FIFO works, RAM & IO extension work and the MCP23S17 reacts as expected.
I will post more in the next few days. I have a lot of thoughts about the expansion board and the audio expansion that I still have to sort out and some questions.
Hans61
Posts: 48
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: Video Repeater

Post by Hans61 »

Here is an intermediate stand. I have tested the prototype of the current board.
Except for the two missing GND connections, which I fixed with two wires on the bottom, everything seems to work.
I've attached a few quick cell phone pictures.
A short cell phone video can be found here:

https://www.youtube.com/watch?v=zXaYqxITc6c

In the video you can see that a small program is booted via the SD card on SPI0, which outputs an 8 bit binary counter to the LED's on port A of the MCP23S17, which is on SPI1.
As you can see I also swapped the LED's of bit 6 and 7 and 4 and 5 on the LED test board.
I will still correct both boards, then sleep another night over it and publish them here as Eagle and Gerber files. (For all who don't want to wait)
My further TODO list for hardware looks at the moment as follows:
- on the current extension still SPI1 on pin header lead out
- extend the current board to adapt U38 (Extended Output) with a 8 bit R2R DAC for audio, connecting the 4 LED's from the board to the MCP23S17. For a selection between 6 and 8 bit via hardware I don't see a practicable solution, except with many discrete resistors and jumpers.
- Extension of the test board for the MCP23S17 for inputs with push buttons (gimmick but I think better than a plug-in board).
- I want to make another external board with the MCP23S17 for the 2x3 pin header of the old expansion board
Attachments
20211013-led-test-board-rev1.jpg
20211013-led-test-board-rev1.jpg (45.32 KiB) Viewed 4927 times
20211013-gigatron+expansion.jpg
20211013-gigatron+expansion.jpg (183.04 KiB) Viewed 4927 times
20211013-gigatron.jpg
20211013-gigatron.jpg (308.18 KiB) Viewed 4927 times
20211013-expansion-unten.jpg
20211013-expansion-unten.jpg (131.66 KiB) Viewed 4927 times
20211013-expansion-oben.jpg
20211013-expansion-oben.jpg (265.73 KiB) Viewed 4927 times
axelb
Posts: 18
Joined: 07 Jan 2021, 06:27

Re: Video Repeater

Post by axelb »

Great development! Maybe one could even use two extra LEDs connected to the MCP23S17 outputs for indicating the current Mode 0 - 3 ?
Theoretically it should be possible to safe one gate by replacing the 7400 by a 7402. One could connect the enable input of the 74574 to the MCP23S17 GPB7 and the U5/2 Pin 8 by means of the spare NOR gate. This would avoid the necessity to switch the GPB7 for individual lines...
Hans61
Posts: 48
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: Video Repeater

Post by Hans61 »

Yes I can add a few more LED's for different signals, that is also useful for troubleshooting. I really only have the MCP23S17 on the expansion for one reason, to have the ability to switch video modes (3/4 lines) via software.
I have read through the "Expansion bus" post (viewtopic.php?f=4&t=64&sid=09e6079e162e ... af89660b09) to repeatedly and got the feeling that according to the basic idea of the Gigatron, the MCP23S17 should be outside the expansion. I don't know how the rest of the community sees it.
I have two ideas now.
1. if I understand it correctly lb3361 replaces the 74x273 with a GAL in his extension. Maybe it is also possible in the video repeater to replace the 74x574 including all the logic with a GAL. This would then reduce the repeater to 3 IC's. I still have to deal with the programming of the GAL's, but this is only a timefage and I wanted this for a long time.
2. i would like to keep the possibility to switch the video modes. I would like it best if the MCP23S17 would not be necessary for this. If I understand it correctly 16 bits are passed with the ctrl command on the address bus. At the moment we use only 8 (9 bit1 is not available) of them. So with available flip-flop's there should still be 7 bits available. In the current SYS function SYS_ExpanderControl_v4_40 the upper 8 bits are not saved, but that would not be important for the video mode. At the moment I don't know if there is enough space in the two GAL's of the expansion or if the GAL of the FIFO would have to do this. Does the lb3361 expansion have the /WE_PORT signal for tapping?
Here are the sources for my current PCB's. They are not tested yet, but in production and now hopefully without errors. As soon as they arrive I will test them. But it's probably not the final version (only for those who are interested).
Attachments
LED Test PIO Expansion.zip
(136.06 KiB) Downloaded 239 times
FIFO-Expander.zip
(472.13 KiB) Downloaded 242 times
Hans61
Posts: 48
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: Video Repeater

Post by Hans61 »

If I understand the previous correctly, then it should be no problem to provide the data of A8..A14 on a port with an additional GAL in the IO expander. This is sufficient to supply the 4 blinking lights (for the 8 bit audio extension) and the video mode switching of the video repeater there would be 2 bits left. I will test this on a plug-in board when I get a chance.
This would allow the MCP23S17 to be used externally via a 2x3 pin header (it would no longer be needed on the expansion, 2x3 I find pressed-on connectors convenient).
If I understand the GAL's correctly, then you can't have the video repeater logic done in one GAL because they need a clock and we have two different ones (CP and /hSync). At the moment I think that the two 74113, the 7400 and the 74574 could be done by two GAL's (two GAL16V8 should be enough). I will pursue this further and test it.
lb3361
Posts: 109
Joined: 17 Feb 2021, 23:07

Re: Video Repeater

Post by lb3361 »

The two GALs are pretty full in the memory expansion because there are no I/O pins left.

Here is a copy paste of a text that roughly describes how the GALs split their work :
during the execution of the CTRL instruction, bits 6 and 7 of the address bus are latched into the GAL flip-flops attached to pins B0, and B1 of GAL1. (https://github.com/lb3361/gigatron-lb/b ... L1.pld#L51) These output pins are not connected because their value is used via a feedback path to generate outputs A15R and A16R (https://github.com/lb3361/gigatron-lb/b ... L1.pld#L73) which go directly into the SRAM. GAL1 also latches bit 5 (ex SS3, now ZBANK which controls zero page banking). There are two minor subtleties in the design. Because all GAL flip-flops are latched when pin1 (CTRLCLK in my files) goes high, GAL1 computes a signal CTRLCLKOUT which is externally looped to pin1 of both GALs. The second one is that GAL1 receives two address decoding signals GTG1 and GTG2 which are computed by GAL2. The remaining cells of GAL2 are using to latch the rest of the CTRL instruction argument (the SPI clock and the SPI chip select).
So the function of Marcel's 74HCT273 is split in the two GALs. The signal to record bits of the address bus into the control register is a raising edge on CTRLCLKOUT (https://github.com/lb3361/gigatron-lb/b ... L1.pld#L35) which is externally routed to pin 1 of both GALs. Meanwhile you can send data to the Gigatron by using some of the free pins of the 74HCT244. These will appear on specific bits of whatever is read from address 0x00 when CLK is set to one. Note that the ROM routine SYS_SpiExchangeBytes sends a lot of garbage on address lines A8-A14. Therefore it may be wise to only give them a significance when the other bits represent a combination that should not happen, such as, for instance, asserting multiple SPI chip selects at the same time. In fact I should have done something like that for the ZBANK and CPOL bits instead of overriding SS2 and SS3.

P.S.1 -- the best references I found on CUPL (the language to program the GALs) are http://ee.sharif.edu/~logic_circuits_t/ ... erence.pdf and http://ww1.microchip.com/downloads/en/D ... oc0737.pdf.

P.S.2 -- One could of course use a programmable chip that is beefier than these GALS. The last CPLD in production that works on 5v is the ATF1508, a clone of old Altera chips worth dozens of 22v10 GALs. Such SMT packages with lots of pins may look out of place on the Gigatron. On the other hand, they open a lot of other avenues, such as accessing the RAM for the Gigatron during the high clock, and for video output during the low clock.

P.S.3 -- One should work out a uniform scheme to expand the CTRL instruction. I never was happy with the way I stole SS2 and SS3 to add the zero page banking and clock polarity bits. Ideally I would like to be able to retrofit it into my expansion board by just reprogramming the GALs!
Hans61
Posts: 48
Joined: 29 Dec 2020, 16:15
Location: Saxonia
Contact:

Re: Video Repeater

Post by Hans61 »

Thanks for the info on CUPL, I'm trying to get my head around it right now.
My findings so far:
I already noticed that the two GAL's are full. I want to stick to the basic idea of just ICS of the 80's. That's why I don't like the MCP23S17 on the board.
A third GAL could solve this easily. The ctrl command passes 16 bits of data over the address bus. The SPI extension occupies A0..A7, A15. A1 not really, but we should not touch it to keep the software simple.
So we would still have A8..A14 available. I don't need /WR_PORT I can do it in GAL with /OE and /WE. In the GAL I need then only 7 outputs A8..A14 and 3 inputs /OE, /WE and (the correct) CLK.
I haven't thought about the load capacity of the Gigatron's outputs yet.
Another problem in the software only the lower 8 bits are saved (ctrlBits=0x01f8).
But for the blinking lights and the video mode of the repeater this should not matter.
Since I am currently working on the extension, I have drawn the banking of the original extension again to understand it better:
bank switching.sch-150dpi.png
bank switching.sch-150dpi.png (14.12 KiB) Viewed 4621 times
The concept gives away one page because B0=B1=0 shows the lower 32k once again in the upper area.
If we had kept the 62256 in addition to the 628128 in the original concept, then we could have 4 pages of 32k. We had saved the two gates of the 7400. We would have to connect A15 with /OE of the 62256 and CS2 of the 628128. A15..16 of the 628128 can be connected directly to B0..1.
I know the switching of RAM banks from Z80 times to overcome the 64k limit. Thereby the banking was mostly limited to a range of 8..16k to still have enough space for software outside the range.
If you would limit the banking on the Gigatron to the upper 16k, you would have continuous memory for programs from 8000-BFFF. This requires a bit more logic, but should be possible with the GALs. Now this is just a spontaneous thought, not thought through to the end.
Post Reply