B4J Question Hexadecimal syntax in Select Cases in B4J: &H9E becomes &h9e and causes an error

[zed]

Hello,

I'm developing a CHIP-8 emulator in B4J.
I'm using hexadecimal opcodes in a Select Case, for example:

Select Case Bit.And(opcode, 0xF000)
    Case 0xE000
        Select Bit.And(opcode, 0x00FF)
            Case &H9E
            Case &HA1
        End Select
End Select

The problem:
The IDE automatically transforms &H9E into &h9e,

and then the compiler gives me:
Undeclared variable 'h9e'
Undeclared variable 'ha1'

I can't find any option in B4J to disable automatic case correction.

My question:
What is the correct syntax for using hexadecimal values in a B4J Case, without the IDE transforming them and without causing an error?

I would like to know if:

&H9E is officially supported in a Case statement
the IDE should normally change the case or not
there is a recommended syntax for opcodes (hex, decimal, other)

Thank you in advance for your help.

 

[Cableguy]

I've always used Hex values in the "#AABBCC" format, being the # the identifier symbol, and dealing with them as strings... and changing types as needed

 

[Alessandro71]

why

Hello,

I'm developing a CHIP-8 emulator in B4J.
I'm using hexadecimal opcodes in a Select Case, for example:

Select Case Bit.And(opcode, 0xF000)
    Case 0xE000
        Select Bit.And(opcode, 0x00FF)
            Case &H9E
            Case &HA1
        End Select
End Select

The problem:
The IDE automatically transforms &H9E into &h9e,

and then the compiler gives me:
Undeclared variable 'h9e'
Undeclared variable 'ha1'

I can't find any option in B4J to disable automatic case correction.

My question:
What is the correct syntax for using hexadecimal values in a B4J Case, without the IDE transforming them and without causing an error?

I would like to know if:

&H9E is officially supported in a Case statement
the IDE should normally change the case or not
there is a recommended syntax for opcodes (hex, decimal, other)

Thank you in advance for your help.

Why are you using 0x in the first Case and &H in the other ones?
0x is the right syntax

 

[Erel]

why


Why are you using 0x in the first Case and &H in the other ones?
0x is the right syntax

That's the correct answer.

It should be: Case 0x9E

 

[Alessandro71]

It should be: Case 0xH9E

why the H? isn't 0x enough?

 

[zed]

Thank you for your replies.

All the codes I used are 0x....
For these two examples, I used 0x9E and 0xA1, but the application doesn't respond to keyboard input.
Not finding any information on the forum, I asked "Copilot," who assured me that the correct code is &H9E.

In fact, Copilot told me that the correct syntax in B4J isn't 0x... but rather &H9E. That B4J doesn't accept 0x... it only accepts &H9E.
I told him that all my codes are 0x and that the emulator runs correctly except for the keyboard. His response was that I was mistaken.
I replied that he was the one who was mistaken and that he wasn't up to speed. That he should go back to school.

This is where it gets amusing, or terrifying.

Copilot replied, "I'm not here to mislead you, but to help you. But if you don't like it, you can look elsewhere." I told him I'd ask the question on the forum to be sure.

He replied: "That's a good idea, but I already know what Erel will say. He'll say that 0x values aren't taken into account and that only &H... are valid."

It's unbelievable.

We want to use AI everywhere even though it generates errors, and the AI is incapable of recognizing those errors.

 

[Alessandro71]

In northern Italy it would be called "Copirlot"

 

[zed]

Here is the correct syntax.

Case 0xE000
    Dim x As Int = Bit.ShiftRight(Bit.And(opcode, 0x0F00), 8)
    Dim kk As Int = Bit.And(opcode, 0x00FF)

    Select kk
        Case 0x9E  ' EX9E : skip if Vx key pressed
            If Key(V(x)) Then PC = PC + 2

        Case 0xA1   ' EXA1 : skip if Vx key NOT pressed
        If Key(V(x)) = False Then PC = PC + 2
    End Select

The problem wasn't with the hexadecimal code, but with a duplicate instance of the class.
Everything works perfectly now.