VGA out for Teensy 4.0/4.1

IIRC there was some timing noise/jitter introduced with USB on the original VGA - with T_3.6 - that went into the Teensy64. But it still allowed ALL of C64 to run there. Initially Frank did a private USBHost it seems to disable/alter something - but scan at that old github looked like he went to PJRC release?

Timing and USB different of course with 1062 and faster USB - for better or worse.

I enjoyed working along with FrankB - good to have somebody else on board. And as cool as the T_3.6 was back then ... T_4.1 with PSRAM and more other is a step up.

Frank is definitively a great guy. Very knowledgeable and who contributed to many things on this forum, next to his own projects.

May be someone has a clue why i2s audio is also causing jitter on my qtimer3 line interrupt. Teensy3.6 has its own DAC and was not interfering with uVGA. May be I should try another qtimer or another timer than timer 3 in qtimer 3? I tried raising the priority of qtimer3 ISR but not much change. Not sure how to decrease I2S ISR to see if any effect.

Indeed - FrankB has done some awesome things - hopefully he'll be back from his break and all moved into his new place and ready for more Teensy fun in good time.

@luni or others might have good feedback on timers. They are a bit different and not all for the better than T_3.6 it seems. Interrupts are a bit less efficient on timers and pin interrupts are all cascaded across a single interrupt with the default 1062 switched to fast GPIO.

KurtE made yield() less intrusive and faster to check the serialEvent_X_() things. But doing a "void yield() {}" in sketch can still make even that 'weak' thing go away, as long as none of the Event code [ Arduino serialEvent(), or PJRC's eventResponder's ] are in use. That yield() is called on every exit of loop() - and on delay() as well.

USB keyboard is working fine. I wired the connector and it all went fine with my wireless keyboard. I added a table for handling main keys in the emulator. It works but I have to handle the release differently as that version of UAE does no handle keyup properly. I hope to share the code. I used the keyboard class part of the host library. Hard to say if there is disturbancel effect at this point...!

Hi :)

Great news if we can use directly a USB KB , i was trying to understand how to use my version ( 1 char sent per I2C at a time ) , but how it's done in UAE it's like to try to find out your way in a maze ;)
In your VGA Lib i see this :

Code:

---

#ifdef BITS12
  parallelWidth = FLEXIO_SHIFTCFG_PWIDTH(16); // 16-bit parallel shift width
  pinSelect = FLEXIO_SHIFTCTL_PINSEL(0);      // Select pins FXIO_D0 through FXIO_D12
#else
  parallelWidth = FLEXIO_SHIFTCFG_PWIDTH(4);  // 8-bit parallel shift width
  pinSelect = FLEXIO_SHIFTCTL_PINSEL(0);      // Select pins FXIO_D0 through FXIO_D3
#endif

---

Is this correct ? , 1st for 12 bits / pixels you use FLEXIO_SHIFTCFG_PWIDTH(16); // 16-bit parallel shift width , but for 8 bits/pixel you use FLEXIO_SHIFTCFG_PWIDTH(4); // 8-bit parallel shift width , why is there a 4 in the parameter ?

some lines after thoose you use :

Code:

---

#ifdef BITS12
  parallelWidth = FLEXIO_SHIFTCFG_PWIDTH(5);  // 5-bit parallel shift width
  pinSelect = FLEXIO_SHIFTCTL_PINSEL(4);      // Select pins FXIO_D4 through FXIO_D8
#else
  parallelWidth = FLEXIO_SHIFTCFG_PWIDTH(4);  // 8-bit parallel shift width
  pinSelect = FLEXIO_SHIFTCTL_PINSEL(4);      // Select pins FXIO_D4 through FXIO_D7
#endif

---

Again for 5 bit shift you use 5 but for 8 bit shift you use 4 :D ....

I don't know if it's correct , but if not then you can presume that some graphics tearing can come from here.

When i made it on STM32Fxx i have use this info and take the 640 x 480 60Hz resolution as base of all other res i made.
https://drive.google.com/file/d/1W3Y...ew?usp=sharing

For example :

320 x 240 res was just 640 x 480 but with 2x bigger pixels

now for your 512 x 480 i will add 64 black pixels border on left and right , the advantage is that the pixel ratio is still OK , and when you trace a circle it appear as circle and not as oval :)

And it's working on the 640 x 480 base resolution.

I just hope i explain correctly :D VGA is not a easy stuff ... he he


Cheers.

The 12bits mode is not tested an probably incorrect too ;-(

For 8bits mode is this also incorrect?

the first FLEXIO (the IO I need starts at D0)
parallelWidth = FLEXIO_SHIFTCFG_PWIDTH(4); // 8-bit parallel shift width
pinSelect = FLEXIO_SHIFTCTL_PINSEL(0); // Select pins FXIO_D0 through FXIO_D3

the second uses (the IO I need starts at D4)
parallelWidth = FLEXIO_SHIFTCFG_PWIDTH(4); // 8-bit parallel shift width
pinSelect = FLEXIO_SHIFTCTL_PINSEL(4); // Select pins FXIO_D4 through FXIO_D7

I guess you will have to change the clock divider to add 64 pixels left and right.
I am very curious now...
Again, I must have been very lucky with the 352x480 mode...
I think it is time to use a scope to verify all those signals....
May be they are just all wrong...

I also found that changing CPU clock was making everything wrong.
I was expecting the PLL used for the shift register to be independent...

You have to set the PLL that output the pixels , vsynch , hsync at closest you can from 25.175Mhz to get the perfect timing.



1 : Do this 480 times : Output the 640 pixels , then , after waiting the time it need for 16 pixels (H front porch) , you put hsync signal to 0 , now after waiting the time for 96 pixels (H sync pulse) , you put hsync back to 1 and wait again the time it need for 48 pixels (H back porch).

2 : After this wait the time it need to write 10 lines (V front porch) , you put Vsync to 0 , wait the time it need to write 2 line (V sync pulse) , put Vsync back to 1 , wait the time it need for write 48 lines (V back porch).

3 : return to 1 ;)

If you apply this timing , you no more need ... luck ... ;)

Cheers.

About the FlexIO shift width register...

FlexIO only has 1,2,4,8,16, and 32 bit shift modes.

FLEXIO_SHIFTCFG_PWIDTH(x) configures for x+1 parallel output bits, and the shifter mode is the smallest power of two that greater than or equal to x+1. So PWIDTH(5) is 8 bit mode, but PWIDTH(8) is 16 bit mode and PWIDTH(16) is 32 bit mode.

The difference between PWIDTH(4) and PWIDTH(5) is that either 5 or 6 consecutive bits are enabled inside the FlexIO peripheral, but the shifter still shifts by 8 bits each trigger. The extra bits are discarded.

Hope that helps!

Hi,

Thanks for you clarifications!
So at least 8bits colors mode FLEXIO is correct then. 12bits will have to be adapted and tested.

I pushed the code of the emulator with USB keyboard support (QWERTY, at least relevant basic keys)

I will try to focus on the VGA aspect the coming days ;-)

Great news for the USB KB :)

If you tell me where you do the decoding for USA QWERTY KB to Amiga KB , i will add the AZERTY French one (so i can use mine;) )

I have try to understand how the timing , FlexIO and DMA work on teensy , but a little too hard for me who just know this MCU for at least 10 days ..

But in looking on how the other do i will learn faster :)

Cheers.

Actually my keyboard is also AZERTY but somehow the USB library decodes it as QWERTY (a sends q...) ;-) Not sure what occurs with a real qwerty keyboard, I guess that table works.
May be there is a method to configure keyboard1 in emu_api.cpp as qwerty/azerty in the init?

USB keyboard callback ends up in emu_KeyboardOnUp() and emu_KeyboardOnDown() in UAE.cpp
The code commented out there is printing the key from the USB lib.

keyboardAsciiConv table convert codes <= 0x7f to amiga codes (in keyboard.h)
keyboardSpecialConv table converts codes between 0xc0 and 0xdf.
You could add a #define param in platform_config.h for AZERTY/ QUERTY and make another table for AZERTY then?
You can also add all amiga keys of the keyboard.h if you want.

I forgot to mentioned that I get the keys as in the usbhost36 Mouse example library.
I use the main callbacks as I am not interested in the special keys as Volume control...
The keys I get looks like ascii codes (and special codes for F1-F10) if you look at the keyboard USB lib and not really keycodes.
I am not familiar with USB HID keyboard.
Maybe there is a way to know if the keyboard is AZERTY or QWERTY using USB lib?

https://github.com/PaulStoffregen/USBHost_t36

Press A,Q,W on azerty KB if you get Q,A,Z ... then you need FR conversion , not hard to do , i'm on it ..
I have do FR , DE , IT , ES keyboard for the Maximite in 2012/2013 and i do the same on Maximite 2 actually :D
But , i just see that my USB OTG don't have 5v on the T4.1 ... do you know why ?

PS : i tested on 2 different T4.1 board ... no 5v on the OTG

Teensy4.1 has just standard USB, not OTG.
You just solder the connector (header pins) on top of the Teensy (close to the mini USB). 5 wires (2 gnd)
. 5 volt is there too!

https://www.pjrc.com/teensy-4-1-released/

My bad , i say OTG but it's USB HOST :)
The 5v is not active on the pin , on the schematic i see i'ts something to do with USB_VBUS pin from the MCU
Now on KB i followed the files to see where it go , all country are still done in this file :

Code:

---

C:\Program Files (x86)\Arduino\hardware\teensy\avr\cores\teensy4\keylayouts.h

---

It's an #include to this file in :

Code:

---

C:\Program Files (x86)\Arduino\hardware\teensy\avr\libraries\USBHost_t36\keyboard.cpp

---

The only thing to do is uncoment your language #define in start of keylayouts.h
I go to try to activate the FR KB , it can be that USB_VBUS is set only if something is active in the USB lib ...

I think I read that you have to init the USB_HOST lib to have the 5v active.
Do you have a sketch with USB running?

No USB before for me on T4.1
The 1st sketch is your emulator :D
I go check for some usb demo stuff and try to made them work to see what happens


So , i found a sketch that work :D

KeyboardBT from USB_Host_t36 , it activate the 5v pin

I find out what it was :)

Reset your board , check for 5v on USB Host , it's nothing ...
Start a Game from SD Card ...
5v appear on USB Host !
From the start i think it's active at start from the board ;)
Now i go to look if KB is ok with azerty mode

Quote:

---

Originally Posted by darthvader

I find out what it was :)

Reset your board , check for 5v on USB Host , it's nothing ...
Start a Game from SD Card ...
5v appear on USB Host !
From the start i think it's active at start from the board ;)
Now i go to look if KB is ok with azerty mode

---

Sorry, I forgot...
The keyboard so USB lib is only initialized in the emulator when you launch the game/image.
Else the callbacks were injecting keys in the emulator before the init....

AZERTY is ok , they just don't care on the 'ALT GR' key ... so the special chars are not present

Code:

---

~#{|`\^@]}

---

"<>" was not here too ... i go investigate where they are :)

Hi ,
I was the full evening in trying to get right code out :D
In debugging the KB , the code are correct , but is the conversion to amiga code that didn't work great.
Shift key , AltGr key are not really integrated to the Amiga Stuff.
The USB KB Lib use the HID Code that is easy to understand , but somewhere they made bit mask and from there , it's hard to follow :confused:
I stop for this evening ... tomorrow with fresh idea , it will go better ...

Hi ,
I have use one from the USB HID KB example to understand how the lib work :)
So i modified the example code to follow what we need , actually i made change for the FR KB that use the special 'Alt Gr' key.
Now for the other key that we don't get correct code '¨^£ù*µ§' i see that the HID give a OEM code that we can use too if combined with other key modifier.
For now you can test this if you got some time :
https://drive.google.com/file/d/1sWx...ew?usp=sharing

Open the serial monitor to see the key code.
Some chars don't appear in serial monitor , i think it use system basic chars , but so long the correct ascii code comes out is good :)

Cheers.

Sorry, I was absent for the day with my family...
Just tried your sketch after selecting the proper layout in keylayouts.h.
I tried French and French Belgian.

I still have some problem with the Alt Gr.
If I want to type @ I do Alt GR + 2 normally but I get character 126 which is "tilt" instead of 64.

Have you adapted ALT GR for French or for French Belgian?
What is Alt GR + 2 on your keyboard?
For the rest it is good enough Alt GR + 3 is # so ok

Hi :)

I was not here too .. he he , i have do some debug on Colour Maximite 2 on the FR KB and corrected one error on the DE KB.
After that i have investigate the T4.1 KB system , and i corrected some keys for FR KB in keylayouts.h.
Actually i send key to serial for see what it's coming out and it's not bad at all.
On the FR KB '@' is ALTGR + 0
You can get my file here :
https://drive.google.com/file/d/1e6i...ew?usp=sharing

Some of the keys don't show up in the serial terminal , due to the key-code , but the ASCII code is OK.
And i don't have touch at the Belgian KB , just to understand the FR one was a dantesk task ... he he

Now , for the Amiga emulator , if the keys inside the emulator are not ok , then i think that we don't give the correct conversion ... but here ... i let you take a look , it's a little to much a maze for me ;)

Cheers.

I found..
This code will make us both happy ;-)
if(keymodifier == 0x40){
// ALTGR Key modifier FR Keyboard
switch (key) {
#ifdef LAYOUT_FRENCH
case 233 : key = '~' ; break;
case 34 : key = '#' ; break;
case 39 : key = '{' ; break;
case 40 : key = '[' ; break;
case 45 : key = '|' ; break;
case 232 : key = '`' ; break;
case 95 : key = 92 ; break;
case 231 : key = '^' ; break;
case 224 : key = '@' ; break;
case 41 : key = ']' ; break;
case 61 : key = '}' ; break;
#endif
#ifdef LAYOUT_FRENCH_BELGIAN
case 38 : key = '|' ; break; //1
case 233 : key = '@' ; break; //2
case 34 : key = '#' ; break; //3
case 167 : key = '^' ; break; //6
case 231 : key = '{' ; break; //9
case 224 : key = '}' ; break; //0
case 36 : key = ']' ; break; //$
case 61 : key = '~' ; break; //=
#endif
}
}