Quote  

Why not falling back to the default it was coming from? Or, even better, falling back to one which can be set.

The firmware has no way of knowing what you have set as colours in teraterm/putty/mmedit etc. It has always set the console colour after an error so the change is minor to set it at program end to be consistent.

  Quote  

Command BIT(var%,bitno)=0 or 1  'sets a specific bit (0-63) in an integer variable
Function BIT(var%,bitno) 'returns the value of a specific bit (0-63) in a integer variable (0 or 1)

Been replaced with the flag command - simpler and faster

  Quote  

FLAG(n)=0/1 'n=0 to 63
? FLAG(n)
? MM.FLAGS

This gives you 64 flag bits without having to allocate a variable. MM.FLAGS returns the value of all 64 flag bits. NB: this will appear as a negative integer if flag 63 is set. All flags are set to zero when a program is run.

Edited 2025-04-03 17:54 by matherp

Hi Peter,

It possibly eludes me, but I fail to see the use for the FLAGS function versus the old BIT function.
In a typical program for readability you would name the flags in the flag regsiter with either a variable, or with a constant.

Lets assume you use 10 flags, that are labeled "b_Flag1"...."b_Flag10"

Using FLAG(n) you use
- 10 variables (regardless if you use CONST or DIM, each use up 1 variable slot).

Using BIT(n) you would use
- 10 variables (regardless if you use CONST or DIM, each use up 1 variable slot).
- 1 user variable that holds the flags.

Agreed, in case you use only 1 flag, it saves 1 variable (50%). But in that case you could also use the 1 variable (64 bits) as 1 flag.

But I may be missing something. That often happens, that I need a bit of explaining to see the brilliance in the new commands.

Volhout
Edited 2025-04-03 18:26 by Volhout

Both the flag command and function take less time than BIT as there is no variable lookup required. No-one needs more than 64 flags and standard basic commands can easily be used to manipulate bits in a standard integer if required

Hello,

I noticed a problem with the Pico 2 running PicoMiteVGA (latest version, but also tested with 02RC6):

The manual states that it isn't necessary to use a level shifter for the PS/2 keyboard (I am NOT using the ADC pins!) I use the default pins for the PS/2 Keyboard.

But I have a USB keyboard which supports PS/2 (as all of my keyboards from Cherry) which failed to initialize on MMBASIC boot-up (no level shifter!), I have to manually re-connect the keyboard and after that everything works fine. This keyboard works fine @ boot-up, if I use a level shifter!

My assumptions:

A: With the additional level shifter a small delay is introduced to leave more time for keyboard initialisation (for detecting USB or PS/2 operation) (?)

B: The additional level shifter is needed because even the none-ADC pins are not 5V tolerant @ boot-up (?)

C: Power issue, I have a small 2W amplifer on the same 5V rail, maybe it draws initially too much power so the keyboard cannot initialize (the more likely problem?)



USB Keyboard which supports PS/2 and has no problem at all:
Cherry G80-1800, power consumption 15mA

USB Keyboard which supports PS/2 and only works after manually re-connecting:
Cherry G84-4100, power consumption 100mA (!!!)

I have multiple (>5 keyboards from each model) and the problem is perfectly reproducible.

Any Ideas?

Things I am going to try now: adding a capacitor close to the keyboard supply - I will report.

Greetings
Daniel
Edited 2025-04-03 19:17 by Amnesie

This isn't a firmware issue. I'll make sure the manual states that a level shifter should ALWAYS be used for PS2 devices unless the device itself will run at 3.3V
Edited 2025-04-03 19:18 by matherp

Hello Peter,

I can confirm that it sadly has nothing to do with the power supply or my circuit (traces routing).

I cut the traces on the pcb to the power amplifier (there is nothing else that draws power). I even added 220uF + 100nF capacitor directly to the PS/2 connector. Nothing.

You are right:

There should be always (!) used a level shifter unless the product / keyboard etc. is specified for 3v3 operation... Argh... Now I have do redesign the PCB again - I am glad I am living in Germany and not USA (trump tariff)  

Thanks
Daniel
Edited 2025-04-03 19:35 by Amnesie

You don't know where the pull-ups are on a PS2 keyboard. The data lines are intended to be open collector transistors, but I don't think there is actually a standard for the pull-ups. Some keyboards have no pull-ups.

Differences in the "high" voltage level between TTL, TTL Schmitt and MOS systems mean that you can't always get reliable data even if the keyboard will power up at 3V3.

As PS2 was designed as a 5V system it's always safe to include level shifting and always risky to omit it. :)

Try to fit in 2 mosfets and 4 resistors for a level shifter. Done carefully it can take up less PCB area than a module as you can tuck resistors away.

.
Edited 2025-04-03 19:56 by Mixtel90

Peter, may I join the chorus of those asking for the return of the BIT command and function.  I use shift registers for some control functions and the ability to hold a variable for each shift register and manipulate it with the BIT command/function made life really easy.  Yes, I realise that this can be achieved with a series of basic manipulations, but this becomes an unwelcome overhead compared with the simplicity of the BIT command.

  Mixtel90 said  

As PS2 was designed as a 5V system it's always safe to include level shifting and always risky to omit it. :)

Anyone tried, maybe a simple voltage divider with resistors could be sufficient in this case.It works for me with UART/TTL converters

  matherp said  

  Quote  

Why not falling back to the default it was coming from? Or, even better, falling back to one which can be set.

The firmware has no way of knowing what you have set as colours in teraterm/putty/mmedit etc. It has always set the console colour after an error so the change is minor to set it at program end to be consistent.

Last comment in this issue: If it could be set, it would know. My only solution to not get my eyes hurt is to set my terminal default to white/black.. Not that I'm using black/white, but I have a slight grey background and even this is annoying for me..

Yes, I've done it using a very simple circuit that was intended for connecting a PS2 keyboard to a 3V3 FPGA. You need a diode from the clock and data lines to 3V3 and a series resistor to limit the current. It's not guaranteed to work as it depends on the value of pull-up resistor in the keyboard. I used BAT85 Schottky diodes and 270R resistors. It didn't blow up, but whether the inputs were within spec I don't really know. :)  That was with an ordinary Pico.

You can force Putty colours to whatever you like providing it understands VT100. Just send it a suitable ESC control code or two. You could do this automatically using SUB MM.STARTUP in the Library and probably some variation of the new END command that I haven't investigated yet. MMBasic itself can't read the Putty colours (there's no guarantee that Putty or Tera Term could send them anyway) and won't configure them automatically.

.
Edited 2025-04-03 20:48 by Mixtel90

  Amnesie said  

I am glad I am living in Germany and not USA (trump tariff)  

Except that USA doesn't hit you up with a VAT. Trump is only doing like-for-like on tariffs.  

@Trump

Fair or unfair, this move is not growing EXPORTS to US (desired by Trump, he want's local production) but as a result is not going to grow IMPORTS from US (undesired side effect).
Direct effect: it only places the US as an unreliable partner. They just do whatever they want, and only to their benefit. And typically that change of mind sticks for a long time. It may cost a whole generation before that is gone.

Volhout

The plan is to eliminate income taxes for Americans.

Did you see the list?

Politics are banned on TBS and particularly on this thread

Sorry

Volhout

  circuit said  

Peter, may I join the chorus of those asking for the return of the BIT command and function.  I use shift registers for some control functions and the ability to hold a variable for each shift register and manipulate it with the BIT command/function made life really easy.  Yes, I realise that this can be achieved with a series of basic manipulations, but this becomes an unwelcome overhead compared with the simplicity of the BIT command.

Why not use Sub(s) + Function(s) ?





bfwolf

G'day Peter,
Can you please take a look at this thread:

https://www.thebackshed.com/forum/ViewTopic.php?FID=16&TID=17798

A problem has been found with the LCD backlight functionality using the original "Backpack" circuit,
as used by Geoff and Silicon Chip Magazine. This uses 2 FETS as drivers for the backlight.

The backlight brightness is unable to be lowered below approx. 20% due to the change in frequency to avoid
audio interference in V5.08.00, the output Mosfet is too slow to switch off at this frequency, however the choice
of components may affect the severity.

Driving the backlight with the PWM command works fine if there is no simple software solution.

Regards,
Lyle.

  Quote  

Why not use Sub(s) + Function(s) ?

Maybe not the fastest approach, but if Peter does not re-implement the BIT commands .... would also like to have them again. Not a question of the number of flags, but flag clusters can be seperated by name and si clashes between library routines can be avoided more easily.

  ville56 said  

  Quote  

Why not use Sub(s) + Function(s) ?

Maybe not the fastest approach, but if Peter does not re-implement the BIT commands .... would also like to have them again. Not a question of the number of flags, but flag clusters can be seperated by name and si clashes between library routines can be avoided more easily.

Sure, it's certainly not the most performant option, but as the saying goes: "In times of need, the devil eats flies..."

Of course, CSUBs would also work - perhaps someone will take pity?



And maybe one day something like this will appear in MMBasic?



bfwolf
Edited 2025-04-04 01:44 by bfwolf