convert two analogue pulses (5000/second) for display on HDMI or Composite Video

[JonW]

 Ha, ur very welcome, Charlie. You do so much; the least I can do is make it yours. I would prefer to redesign the board for you guys ( no charge, maybe a private tour!), as this really is HW shitola design, like most Chinese designs: 90 per cent there, but the last 10 per cent kills you and your market.  Also Love Les to get something in the Museum too as he is proper smart, maybe a retro PIC game on HDMI!!

Live in Wilts, not far.  I am pimping the dead space as I speak with Glyphs + (Caps) ASCII for you. Battery, ohms, bars, Wi-Fi symbols- these are above the SSD1306 code but will be ignored by the SSD ASIC.

FPGA

It is triggered by a single Start/Stop button on the FPGA; it uses an LFSR to generate a real tape and sprocket in 64 bits.  It wraps top-to-bottom, 32 bits per frame.  I reckon with a couple of Lasers and photodiodes/IO, we can read and decode live tape with ease.   I can also adjust the RTL in some areas to make editing easier. Also, if you want something specific for a demo, let me know.  After that, the display is yours to pimp


Glyphs in progress above/below the user window of SSD1306.  Some are 1 or (2-3-byte) glyphs with parameters, like battery gauge and Wi-Fi strength.

BTW i did explain it, but pictures are way better than words..  This is baked into the FPGA with a trigger, so as you run the tape, it starts scrolling at emulated speed. It has other options to show pictures and run scripts, but these are generated by Python scripts that build the Verilog for me, then re-synthesis, reprogram, just basic font reproduction via PY.  The glyphs are real-time from PIC/MCU so some can be adjusted.  Working on cursor position, glyph /parameter. 

I'll build some 27Q43 demos for you as this will really show off the display capability.  Doing it in Verilog or RTL is much slower

I

[charliecoutas]

That's flipping brilliant Jon! I haven't dipped my toe in the FPGA world but I did use some Programmable Array Logic (PAL) many years ago.

I have just spent half an hour trying to add a photo of my screen driver in action but the forum thingy won't let me. I am trying to add a jpeg image but it says that only certain file types, including jpeg, are allowed. Is it my age that is the problem?

Charlie

Jon: All trips round the museum are "private" and personal.

[RGV250]

Hi Charlie,
Is it the file size?

Bob

[JonW]

Think nit has to be .jpg and not jpeg

[charliecoutas]

Sorry, .jpg  The file size is 620K. It lets me add a photo of my grandchild! But not my screen.

[charliecoutas]

Tried making a short movie, can't upload that either! I can upload .jpg but not .jpeg Correction, i can upload some .jpg files but not others.

[JonW]

The way to do the movie is to get a YouTube account, upload it privately, and post the link here

[charliecoutas]

Good idea, here goes.....

https://youtu.be/w7JUaTtolss

[RGV250]

Hi Charlie,
It says this video is private.

Bob

[top204]

Same here Bob.

Excellent work Jon, and that is an understatement!

I have attached the source code and firmware for my re-creation of the ZX81 Mazogs game using a PIC18F26K22 device on an SSD1306 OLED. I also have the game running on SSD1309, SH1106 and the old faithful, KS0108 LCDs as well, but your emulator is for an SSD1306, so it is attached below. I am busy writing the wording for the game on my google site, but you might like to try the game out on your emulator. Note that it works fully on a real OLED, and in the simulator, so it will give your emulator a good test.

The pinouts for the SSD1306 OLED are:

$define GLCD_CS_Pin  PORTC.0                ' The pin that connects to the SSD1306 CS pin
$define GLCD_RST_Pin PORTB.4                ' The pin that connects to the SSD1306 Reset pin
$define GLCD_DC_Pin  PORTB.5                ' The pin that connects to the SSD1306 DC pin
$define GLCD_CLK_Pin PORTC.3                ' The pin that connects to the SSD1306 Clk pin
$define GLCD_DIN_Pin PORTC.5                ' The pin that connects to the SSD1306 Din pin

And they can be found, along with the button pin ports, in the "Globals.inc" file.

There is also a proteus simulator file, with its 18F26K22 device already pointing to the compiled; "MAZOGs_SSD1306_18F26K22.bas" file.

Regards
Les

[charliecoutas]

I have a bit to learn about Youtube. Try this:

https://youtu.be/s_bDlCO-Ju0

[JonW]

Hi LES

Thats great, ill give it a go as I thin i have the 26k22 on a dev board.  It should work....

[JonW]

Hi Les

I tried the game with a 18F26k22, it compiled fine but the SSD1306 doesnt show anything on a real display.  I checked the pinouts global.inc file and they are good, rechecked the display and all good.  Then just did a HRSOUT loop, hello world and that works so I know the device is running.  Any ideas?


While I was in the office I dug out a 27J53 board with a SPI SSD1306 lib I created with CCS C a while ago.  It runs fine on the same display and better still works on the HDMI EMU.  See Vid.

I am sure the game is something silly and ill keep looking

[top204]

The code is using the MSSP peripheral operating as an SPI master for a PIC18F26K22 device, and they can differ in their operation and setups on different devices.

So check that the MSSP is being setup correctly on the J device, and in the SPI1 writing.

Regards
Les

[JonW]

Hi Les

This was on a 18LF26k22 that i tested the game, the dev board may have an issue

[top204]

I know this sounds obvious, but please check the SSD1306 on your board is using SPI, because a lot of them use I²C, and even on the SPI boards, they use the texts SDA and SCL for MOSI and CLK!

Regards
Les

[JonW]

Hi Les

I found a couple of issues in the code, took me ages to find it,  I just could not get my displays to work, yet they worked on other code/FPGA ruuning at 8M SPI. 


The Bug..

"$define SPI1_hWriteByte(pDataOut)" mechanism relies on BF being 0 at the start so the wait loop has something to wait for. But BF is a read-only status bit — hardware sets it when a byte completes, and the only way to clear it is the side-effect of reading SSPBUF. The write SSP1STATbits_BF = 0 assembles and executes but changes nothing.

So the sequence actually ran like this:

Byte 1 (after reset): BF happens to be 0. Write BUF, loop genuinely waits ~1 µs, byte completes, BF→1, exit. CS rises after the byte. Correct — which is why $AE always decoded.
Byte 2 onward: BF is still 1 from byte 1 (never cleared). Write BUF starts the shift, the Until BF = 1 test passes immediately, macro exits ~200 ns into an 8-bit, 1 µs transfer. Caller raises CS. The SSD1306 spec requires CS held low for the full 8 clocks — deselected mid-shift, it discards the byte. Every byte from #2 onwards, including $8D $14.

The fix's read (Global_GLCD_bSPIDump = SSP1BUF) performs the one action that actually clears BF, re-arming the flag so the wait loop is real again on every byte, not just the first.

And the reason it ever appeared to work: at 16 MHz the byte took 500 ns, and the dead time between "loop exits instantly" and "CS pin actually rises" (proc return + macro exe  + LAT write, ~10+ instructions at 62.5 ns each) accidentally exceeded the byte. Bug present, consequences hidden. At 8 MHz the byte took 1 µs, outran the overhead, and the truncation became real. The below trace shows it literally: clock bursts landing outside their CS windows.

An absolute BHOLE to find, I ended up bit banging a few pixels to prove the IO and comms to the display from the 18F26k I had was working ok, when the fault persisted, I got the decoder out.  I had to slow the SPI as the crosstalk on the pigtails was so bad and the slower speed enabled me to see it clearly in the fauled Pulseview decode chain.

Please see the FIX1 to FIX3 slides for my explanation and some decode plots and fixes.  All working on my SSD1306, even at 16M and alot slower, I may have to change the code in the FPGA to be compliant to this speed now.  Tested at 8M and it MAY will work at 16M, as the pin limit i have mapped is 15MHz. Remeber 16M is 60% over spec for the SSD1306 SPI.

Didn't manage to play it as i dont have any pushbuttons and its beer oclock :-)

Slow that SPI rate 'SSP1ADD = 7' and see if it fails on your display with the original .inc.  The updated one is attached