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.
Video Repeater
Forum rules
Be nice. No drama.
Be nice. No drama.
Re: Video Repeater
@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:
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.
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.
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
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.
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 (123.74 KiB) Viewed 8923 times
-
- FIFO+Expander-Rev1-sch-s1.png (78.17 KiB) Viewed 8923 times
Re: Video Repeater
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.
> 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.
Re: Video Repeater
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.
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.
Re: Video Repeater
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
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 (45.32 KiB) Viewed 8876 times
-
- 20211013-gigatron+expansion.jpg (183.04 KiB) Viewed 8876 times
-
- 20211013-gigatron.jpg (308.18 KiB) Viewed 8876 times
-
- 20211013-expansion-unten.jpg (131.66 KiB) Viewed 8876 times
-
- 20211013-expansion-oben.jpg (265.73 KiB) Viewed 8876 times
Re: Video Repeater
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...
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...
Re: Video Repeater
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 (https://forum.gigatron.io/viewtopic.php ... 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).
I have read through the "Expansion bus" post (https://forum.gigatron.io/viewtopic.php ... 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 493 times
-
- FIFO-Expander.zip
- (472.13 KiB) Downloaded 504 times
Re: Video Repeater
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.
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.
Re: Video Repeater
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 :
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!
Here is a copy paste of a text that roughly describes how the GALs split their work :
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.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).
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!
Re: Video Repeater
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: 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.
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: 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.