Support external video buffer, Kickstart switching from keyboard

[penfold42]

Moved config key to HELP

F1..F4 select kickstart roms with PB8, PB9

F9/F10 sets PB10 low/high for other uses (pal/ntsc, DF0/DF1 swap)

PB12 is used as an active high display enable to drive external buffer

[penfold42]

Todo:

• make display enable active low using slave select
• Use the OSD to indicate kickstart and option pin state

[keirf]

Rom switching is nice but it will confuse users that system will likely crash since we are not switching during reset?

[keirf]

Okay my longer take on this is that it's a very good idea and should definitely be included. However, it would be nice if it's fully configurable. OSD names for hot keys, and configurable actions on GPIOB (some subset of: mask, set/clear, toggle, count, ...).

This is beyond what you'd want to configure with a few buttons on the OSD directly. It really needs at least easily-modifiable source code. Better would be a plain text config which gets cooked into the build by a Python script. Better still would be the above, but cooked into a pre-built Hex programming file by a Python script.

Then there's a story around upgrade: Download latest, cook in your previous config file (perhaps slightly changed for new options in the new firmware), then Flash it.

I can't see it getting much easier than that while allowing user (or at least downstream project maker/seller) configurability.

Right now I'm working on LCD/OLED + OSD simultaneous output in FlashFloppy. So this sits on the backburner til I've got that sorted. So I guess later this week, best case.

[penfold42]

I’m basically re-implementing what I had done on an atmega328 on that keyboard adaptor photo.

On that board I also reset the Amiga when I change kickstarts.

I’ve decided to ditch my atmega design and respin it with STM32 and OSD instead.

I could also use the keyboard and OSD to configure kickstart display names.

[keirf]

Is your aim to produce and sell? Or do a full installation service? Or just a DIY project? I think it affects what the best config method might be. Doing these all via OSD could be a pita.

[penfold42]

Sell if there’s some interest. I won’t be doing an install service.

I’ll be bringing out the UART pins so there’s another config option.

OSD keyboard entry should be fine - we have a full keyboard to type on!

[keirf]

It's not a good story on upgrade though -- which currently losing config -- and not so good for slightly higher volume makers either -- eg. zaxon who wants the df0/df1 switch in every build, and he does scores or even hundreds.

I think for "pre configure" method right now, having a source file modifiable by confident users is okay though.

Yes having a key combo which toggles the keyboard into completely stolen mode makes sense given that presses can be hidden from the host. eg. CTRL-ALT-Del or C-A-Return or similar.

[keirf]

Anyway, I suggest rebase this to master later this week once I've done another release. I will be taking a break to work on other things then. And I will get this code in, in one form or another, possibly build-time configurable for now. With an aim to make that more dynamic in the mid-term.

Regarding PB12 as display enable: Is there a specific external circuit you intend for this? I wondered about using the existing tri-state output buffered onto each of RGB via 'totem pole' arrangements: PNP to 3.3v and NPN to 0v. In tri-state there would be no base current and hence no drive onto the RGB outputs. Would that work? Is it sane? Otherwise I think Disp.En. should be a configurable alternative to tri-stating and eg. the DMA to GPIOB_CRH should instead write GPIOB_BSRR. I'm just a bit worried about jitter on the box boundary, particularly doing this in IRQ_pre_osd(). We take a lot of I2C IRQs if running in Fast Mode and that probably would make the box edge noisy.

[penfold42]

I plan to try a few hardware options over the weekend - all with the aim of safer stronger drive strength on all three channels for better contrast.

Have you finished your current work for now ?

Would you prefer separate PRs for kickstart and display output ?

[keirf]

Yes, I have a fix for rotary encoder on branch "pins" -- as I broke rot.enc. support and in fact it might even be hazardous to connect a rot.enc. at the moment as gpio_pins_connected() drives pins HIGH, while a rot.enc. drives them LOW. So I implemented a fix to be much more careful. :)

I also would like to robustify the I2C protocol a bit, in case of loss of sync.

Neither of the above really affect you: The core display code is now solid.

It probably makes sense to do Kickstart and Disp.Out. as separate PRs as they're totally unrelated. It doesn't matter too much as I will expect to refactor stuff a bit when you're done.

[keirf]

Re Kickstart switching: Is it worth considering one key to cycle between images, vs image per key? Obvs we have plenty of keys, then again will you always be able to remember which image is on which key anyway....

There's also the question of default state of pins relating to hot keys? Perhaps we default to them all LOW. Or we could make that configurable (again, just at build time for now, perhaps).

[penfold42]

I think open drain is always the safest default for lines like this.

What’s the flash endurance like on the STM32 ? I’m tempted to also auto save the kickstart after a period of inactivity.

[keirf]

It's rated for 10k erase cycles. You have to write 2 bytes at a time, but that gives you ~500k smallest-possible writes per 1kb of Flash.

[penfold42]

I also would like to robustify the I2C protocol a bit, in case of loss of sync.

I wonder if that explains some weird hang on startup I’m seeing? My wiring is a mess of dupont wires, so it could easily be me

Neither of the above really affect you: The core display code is now solid.

The connected pins test just screwed me ! It was seeing factory default jumpered cos the gotek has pull-ups

[keirf]

But the Gotek doesn't connect to pins A0-A2 and it's that range the pins-connected tests occur in. Ah do you mean rotary encoder? That would make sense. Use the 'pins' branch and see how that goes.

[penfold42]

Sorry - Brain fart on my part.

The jumper to enable FF magic mode on A0.A1 trips the factory default test (in the master branch)

[keirf]

I'll refactor your new patches on the pins branch and see how that works for you before merging it all across to master.

[keirf]

I think this PR is dead now.