@Voja Antonic where can the challenge be found?

*  *  *  *  Here's the challenge:  *  *  *  *

You have to write the shortest possible program which does this:

- Load two random nibbles (see the 3.SFR manual page 26) in two registers, and
- Calculate the Parity bit for these 8 random bits.

So the result should be a single bit which tells you if the parity is even or odd. The program should be optimized so that it contains as few words as possible.

Please submit your solution here in the discussion group. The shortest program wins. If two or more programs have the same length, then the time of submission counts.

9 lines is (I think) the smallest it can be made, if we make the assumption that the badge is in the state it is found in after a reset (input pins are pulled up, so special purpose register B on page 0 is all 1's). The result is found in the LSB of R1:

-  | Text                 |Instruction binary |Comments
0 | MOV R2,4      | 1001 0010 0100    |Counter for later
1  | MOV R0,[BB]  | 1011 1011 1011          |*Retrieve Rnd to R0
2 | MOV R1,R0     | 1000 0001 0000  |R1<-R0
3 | MOV R0,[BB]  | 1011 1011 1011          |*Retrieve Rnd to R0
   |Loop time
4  | XOR R1,R0     | 0111 0001 0000    |XOR R1 and R0, result in R1
5  | MOV R0,R1    | 1000 0000 0001  |Copy the result of the previous step to R0
6  | RRC R0          | 0000 1101 0000   |Shift R0 to the right
7  | DSZ R2          | 0000 0100 0010  |Decrement R2(counter) and check if 0
8  | JR -5              | 1111 1111 1011             |Jump relative -5

*Retrieving the Rnd register cannot be done by using MOV R0,[FF] because as specified in page 15 of the insruction set, MOV R0,[XY] requires indirect addressing with registers RX and RY. For this, register B was used since it is normally used as an input port register and is nominally pulled up. This code would still work with a single difference if register B cannot be assumed as 1's: an instruction would be added to the start to set R3 to 1111, and then the instructions currently on lines 1 and 3 would become "MOV R0[R3,R3]". Using register B is hacky...but that's the point :)

also the parts placement diagram shows two each 10 uF caps, the second one not on the schematic but connected to the power pins of the two two ICs (shift registers?)

It's the power supply decoupling cap. There was an error on the schematics, please download the new version of the Hardware Rev4b.pdf

Two ICs are decoders 74HC138 (3-to-8 lines)

How critical is the Vcap 10 uF capacitor in this design? The data sheet has some specific requirements for it but I’m not 100% sure it applies to this circuit board. 

Very critical. It is a low-ESR capacitor, used to stabilize the MCU's internal 1.8 V regulator voltage for the processor's core.

oh. Then I’m dead I the water. I didn’t appreciate that critical part and didn’t order any. Looks like I don’t have anything close in my parts bins either. Oh well, another DK order and one more week. Looks like I’ll miss having it running at the same time as the conference is going on 

It's interesting that Microchip suggests that the distance between the MCU "Vcap" pin and the cap terminals should not exceed 0.25 inch (6 mm).

Also, if you order it, note that it should be rated for 16 or 25V, although it works at 1.8V only. It is surely because of its dynamic characteristics.

oh. I just realized. I may be lucky. I have a couple of boards which use Microchip SAM processors and I might be able to steal a 10uF cap temporarily from one of them. Maybe 

Can the Overflow flag be accessed by the program in any way, or is it just for debugging in single stepping mode? No instruction's output (including SKIP) depends on it and the flags seem to be internal to the ALU (not in user mem like other registers).

Overflow flag is accessible in the Special Function Registers area, at the address 0xF4 (RdFlags), bit 1. 

To let this flag affect the program flow, you can load RO with this register and then test bit 1 in R0, for instance...

1101 1111 0100         MOV R0, [0xF4]     ;  R0  <----  [RdFlags]
0000 1001 0001   BIT    R0, 1              ;  Z  <----  Vflag
0000 1111 1110        SKIP  NZ, 2            ;  Skip next 2 instructions if NZ
... next 2 instructions could be an absolute jump, like MOV PC, NN and MOV PCL, N

In my "unofficial" assembler RASM this code may look like this :)

@RDFLAGS EQU #F4

LABEL:
    LR0 @RDFLAGS    // R0  <----  [RdFlags]
    BIT_R0, 1    // Z  <----  Vflag
    SKIP_NZ,2    // Skip next 2 instructions if NZ
    JMP    LABEL    // an absolute jump, like MOV PC, NN and MOV PCL, N

and it will be assembled to this:

 000 0D LABEL:    LR0 @RDFLAGS    // R0  <----  [RdFlags]
     F4
 001 00        BIT_R0, 1    // Z  <----  Vflag
     91
 002 00        SKIP_NZ,2    // Skip next 2 instructions if NZ
     FE
 003 0E        JMP    LABEL    // an absolute jump, like MOV PC, NN and MOV PCL, N
     00
 004 09
     D0

Looks good.
I am so sorry that I couldn't try your assembler. Surely due to my inexperience with using GitHub repos. It seems that I'm not a good team worker :)

I'm pretty sure that "official" assembler is gonna be much prettier, but because it is not yet available I'm offering my "quick & dirty" solution to the public :)

I can build DOS binaries or MAC binaries or whatever binaries of RASM if anybody needs some ;)

I'm not sure that I could name it "official" assembler. It was written about two years ago by Mike Szczys and it works very good, but it must run under Python, which will probably limit a number of users.

I guess that it depends on the ease of application. There are people (like me) who are kind of "autistic" to some forms of interactions with the computer :(

Moreover "official" tools require Python 3.6+ as I heard which should limit number of users even more...

Thanks, I missed that!

A couple more questions related to the V flag:

- In the Instruction Set doc, the table on page 2, both CP R0,N and ADD R0,N are shown to affect the V flag (and this makes sense, since they're similar to ADD and SUB). However, in the Flags affected subsection for each instruction, the effect on the V flag is not documented. Is it just same as ADD/SUB?

- What about INC and DEC, do they affect the V flag? (not documented, so just checking).

Hint: I'm working on an emulator, hope to have something working today :)

One more Emulator? Great :)

If you think like I do... you'll appreciate page numbers added to the badge manuals. You can download them here: https://www.dropbox.com/sh/t0uu3ys5mftlv66/AAC3MJ9OSTowr2Yq4cLf6Jh1a?dl=0

I agree and I hope that I'll have enough time to do it before the Supercon. Unfortunately, manuals were written in CorelDraw, so I have either to do it manually for every page or to reformat PDF pages for every new revision.

Thanks!

Done. Revision 4 contains page numbers.

My "unofficial" assembler is released: https://hackaday.io/project/158426
Now I'm going to create a number of sample programs and may be emulator ;)

There are example programs?

At this moment, there are only two sample pre-loaded programs with the code that can be regularly edited, ran in different speeds or single-stepped. One of them simulates the moving message display with Shakespeare's Hamlet :) and another one is used for Serial In demonstration, with UART_ASCII-to-text conversion.

However, all subsequently written programs will be exchangeable via Internet and up/downloadable via Serial port. The same applies to the main firmware, which can be bootloaded in case the new version appears.

Any chance of buying one of these?  I'm in the UK and have no chance of getting out to SuperCon 😭

I'm not sure. Knowing the production process, there will hardly be any leftovers and subsequent sales were not planned.

where’d you get the PIC24F256 chips? I just got all the parts and the PCB. But I can’t find the PIC anywhere. 

The prototypes were built more than 2.5 years ago, when MCUs were regularly available, and we were careful enough to order the production batch directly from Microchip in the spring this year.

I checked and Microchip estimates that 24,320 pieces are going to be available on 19-Dec-2022. Price is $2.05 for quantities 1 to 24. However, I'm not sure that you can order a small quantity, as they gave prices for 1-24 and 25-99 pieces, but then they used the order form with a note "Multiples of 160". Please check it here:

https://www.microchipdirect.com/product/PIC24FJ256GA704-I/PT?productLoaded=true

I'm currently working on assembler for this CPU under my nedoPC SDK project: https://hackaday.io/project/158426-nedopc-sdk

Good luck!
Is it going to be two-pass assembler, with labels?

Of course :)
With relative short jumps and "synthesized" long jumps to labels (no numbers needed)

Wow...

It could be useful if it generates binary file, so that it can be downloaded and directly executed. File format is described in the main manual, chapter Dir Mode, buttons Save and Load. Here's the file form (Little Endian, bits 15-12 in program body are all zeros):

1. Header, 6 bytes: 00 FF 00 FF A5 C3
2. Program length, 2 bytes (in 16-bit words, Low byte first): NN NN
3. Program, NN 0N×Program Length (Low first): NN 0N, NN 0N, NN 0N...
4. 16-bit Checksum for items 2 and 3 only, 2 bytes (Low first): NN NN

Yes, my assembler RASM in this case generates binary in big-endian format (higher byte 1st, lower byte 2nd), so it has to be extra utility to convert this binary to little-endian format with header and checksum as described above (or it will be specifically written command line program that will take big-endian binary produced by RASM to send it in proper way over serial port swapping bytes on the fly).

Sounds good!

There will be at least one more assembler, created by Mike Szczys, as it was noted in the project description. This one is executable under Python environment only.

I think in discord somebody wrote that there are more than one assembler already and it's still discussed which one will be released as "official" ;)
If "official" assembler will be in Python then mine will be fastest ;)
And more portable - my RASM is compiled by any 16-bit, 32-bit or 64-bit ANSI-C compiler ( I started working on this universal assembler in January 1997 under MS-DOS 6.22 using Borland-C++ 3.1 : )

One thing is for sure: none of them will be mine. Actually, the only programming language that I use is assembler for embedded systems. I'm totally inexperienced with system or application programming.

I'm going through the instruction manual and found a few typos on pages 1-15 so far. Sorry for the tiny blurry screenshot I somehow can't print/export the annotations. Mostly found numbers that are wrong given the rest of the context, and a few places where you call out registers by one name but label them with another (R10/OUT for example).

https://imgur.com/a/aiCoEEp

You are a very careful reader and this was a huge help for me. All typos were corrected and they will appear in the new revision soon.

However, all the register numbers/symbols were left as-is. The examples for all instructions were given in the same way as they are "typed" in the "button interface" - with literal integers, and register tables in the same way as they are represented on the silkscreen table - with register symbols. It's also a good chance for a reader to become familiar with register symbol names.

Thanks, nwinters3000! Please let me know if you spot more errors. I worked alone on these extensive manuals and you probably know how hard it is to locate your own error.

@Voja Antonic p19 JR NN thew new program memory address bits are wrong, still are 65 not 62. p23 DEC RY flags instructions say C should be set when result is 1111 but graphic shows C being reset. p26 AND R0,N sample opcode text is AND R0,6 but bits and rest of example are AND R0,*10*.

I like the IOPOS=0/IOPOS=1 annotations on the arrows on page 30 BIT RG,M. Please copy them to the following pages.

page 36 BTG RG,M example 2 has dashed arrow going from 0xFA into zoom bubble, but it should be coming from 0x0A instead if the switch and numbers are correct.

I haven't looked in the other manuals in as much detail yet, but I think the "Manual" document should move the "Programmers model" section much earlier, probably even before explaining the all the buttons, connectors, and instruction decoder. At least the first page of this section serves as an introduction that gives the rest context. Or maybe there's a more introductory document people should read first?

Anyway I've been finding issues by going through and implementing the instructions in javascript. https://github.com/sphereinabox/had-badge2020-22-websim

Fixed, thanks. A new revision will be released soon. I moved the Programmer's Model pages too.

SFR Rev3.pdf
 - p12 calls 0xF1 "Clock" but p10 calls it "Speed"
 - near the end of the description text on p17 it calls out register pair "SFR7". It should be "SFRF7"
 - p20 suggests AutoOff gets set to 1111 on every keypress. I assume you mean "your code might set it to 1111 for example on every keypress" as described in the text
 - p25 SFRFE could use a bit more detail. Is 15 "most bright"? Does 0 mean "most dim" or "off".

Is the V flag set by add/sub instructions the one at F4 bit at mask 0b0010? p31 of the manual rev3 suggests it's not memory mapped, like PC, V, C, SP, HP, Mode are not memory mapped. Do the C and Z flags show up in the memory map? I'm guessing maybe V is memory mapped because unlike C and Z it's not used by any instructions.

The initial state of some memory isn't documented:
 - SFRF4 (RdFlags)
 - SFRF6 (SerLow)
 - SFRF7 (SerHigh)
 - SFRF8 (Received)

Fixed. Thanks, nwinters3000.

However, AutoOff register is automatically preset to 1111 at every keypress. The suggestion to write 1111 in the program is valid only if you want to protect your badge from unwanted automatic turning off.
Yes, V flag is memory mapped as bit 1 in memory location 0xF4.

Few questions:
1) is anybody writing tetris for this badge?
2) is anybody working on high-level programming language compiler for this badge?
Asking for a friend ;)

1) No, as far as I know
2) No, as far as I know

May I ask a question too?
3) Will someone write Game of Life on hacking night?

What is "hacking night"?

Well, maybe not night, more like evening. When all hackers show what they can do with the badge.

Ok, may be somebody will present GoL in the last moment ;)

I am planning on presenting GoL.

@Voja Antonic ,

@Jacob Still and I worked on Game of Life. I mean, I finished it like 5 days too late, but here it is...

https://github.com/jcstill/supercon_2022/blob/master/programs/04_conway/04_conway.asm

Reading docs - I think I finally understood how to call subroutine (by setting PCH,PCM by MOV PC,NN instruction and then writing to JSR), but how can we RETURN from subroutine?
...
Ok, nevermind - it's RET R0,N instruction...

Just execute instruction RET R0,N at the end of the subroutine.

In many cases N (integer 0-15) will be dummy argument which does nothing except destroying R0 register, but it is useful if you have to create lookup table.

Actually I think it's a great side-effect that allows to do 2 actions at once :)

Another question - it looks like writing to PCL, PCM or PCH immediately initiates jump to combined new address - right? But MOV PC,NN doesn't do that, correct? It just sets PCM and PCH for subsequent write to PCL (or JSR) and only then it's doing the jump.

Writing to PCM, PCH or using MOV PC,NN does not initiate jump. Only writing to PCL or to JSR causes automatic Jump or Call. 

Please note that only instructions MOV RX,RY, MOV RX,N and INC/DEC RY initiate jump or subroutine call. Modifying or writing to PCL or JSR by any other instruction is treated as the simple memory modify or write.

ok, makes sense - then docs need to be corrected - "3 SFR Rev2a.pdf" pages 8 and 9 say in "Operation" paragraph: "However, this register will take action when program jump (writing to PCH) or subroutine call (writing to JSR) occurs." So here it has to be "writing to PCL" instead of PCH (and instead of PCM on previous page).

Corrected.

Thanks!

I need translate this to Polish lang

Hi @Voja Antonic can you enable public chat so we have a good place to discuss badge hacking?

discord or irc

or supercon-2022 chat ;)

It's a good idea. I'll do something about it.

Hi, in RET instruction description the pseudo-code updates R0 with PC instead of N as described in the test.

Also, address calculation to retrieve the return address would be wrong since SP would be off by one before it is decremented.

You're right with your first post, gatin00b. Thanks!
It's corrected and will be visible in the next version, in a few days.

I don't think that there's an error here. SP always addresses the NEXT address field for return, not the current one.

Maybe I'm just reading this bad, but the Operation section of RET instruction in instruction manual mismatches the behaviour described in the User Manual.

You are right! The order of operations in the Instruction Set book was wrong. Thanks for being persistent, this helps a lot!

Somehow I managed to pack two errors in a single statement :)

So the correct operation should be:

(R0) ← N
SP ← SP-1
PC <11...0> ← ((SP×3+2), (SP×3+1), (SP×3))

Thanks!

Hey Voja, quick question: What would be the recommended way to add I2C? I would love to make a few add-ons boards, and offer them to encourage creativity. One in particular I have in mind would be to use the 12-pin connector to provide a proper I2C SAOv2 connector. I see two options:
1) Use a gpio out for SCL, and a clever circuit of gpio in and out with resistors for SDA;
2) Or use a SC18IM704 UART to I2C-bus bridge on the RX and TX lines.

Any thoughts?

I'm not sure that it will be a feature in the version prepared for the Supercon, but maybe in the next one. There is a bootloader, so it will be easy to upgrade with an inexpensive USB/UART converter.

I was reading 2 Instruction Set, page 16 of 39, MOV [NN], R0.  The example shows:

MOV [0x19], R0   1100 | 0110 | 1000   (Those are supposed to be the bits listed in the boxes.)

Should those bits be 1100 | 0001 | 1001 ? Perhaps I’m not understanding that one.

I am loving reading up on this badge for SuperCon. There are going to be a lot of superb hacks that everyone will be able to show.

Good point. Corrected (it will appear in the new revision of all manuals in a few days)
Please keep reporting every error you spot in manuals!
Thanks!

I first reported this on Hackaday's Discord channel, but there are a few discrepancies in the Instruction Set Manual of the badge. JR NN instruction in listed with opcode 0xF in the diagram while using 0xA in its description page which collides with MOV [XY],R0.

The other one I've noted was some of operations' affected flags were also mismatching between the diagram and their description page.

Also, on page 18 of instruction set manual, MOV PC, NN gets renamed LPC NN (which makes more sense to me)

Thank you, gatin00b for your objections!
Fixed in the source file and it will appear in the next release of the manual.

I've checked and found only one wrong flag description (C flag in DEC RY). If you spotted more, please help me locate it.

For those of us who can't make it to the conference - any chance of adding the PCB files?

Maybe, after the conference is over?

PCB files and BOM will be published here tomorrow. 
Source and HEX files for firmware too.