BOM and CPL files and programming/flashing.

[gotnull]

Would it be possible for you to provide a BOM with MFG Part Numbers and CPL file for the A500?

[HenrykRichter]

That most probably won't happen on my part, I'm afraid. I've never planned to have my PCBs populated from the factory and consequently didn't look up part numbers at LCSC.

I'd happily add those files to the repository, should somebody go through the process of collecting part numbers.

[kavanoz64]

I had PCBs produced some time ago with assembly. Due to other projects, I never got to finish it. I'm attaching the files here. I didn't check if the parts are still in the stocks at JLC/LCSC, so you may need to find replacements for some of them. I didn't include U1 and U2 as I intended to hand solder them. Larger leds were also not included. BOM-A500KB.csv POS-A500KB.csv

[gotnull]

Very much appreciate the upload. I’m actually going to attempt to get some produced so I might ping you when I get to the firmware part if that’s okay as I’m not actually sure which wires to hook up the TTL to or what software is required to flash the firmware once it’s built. If you do have additional documentation on those processes that would much appreciated also.

These were the BOM and CPL files that were used to get a quote through PCBGoGo.

BOM-A500KB.xlsx CPL-A500KB.xlsx

[gotnull]

You mention:

UART is connected to KBCLOCK and KBDATA lines. With debug on, please connect the FT232RL to KBCLOCK/KBDATA and use IN3/IN4 for Amiga communication.

I can see the CLK/KDATA on the PCB near RST and 5V+ so I'm guessing these are KBCLOCK/KBDATA that you're referring to. What I'm not sure about is "use IN3/IN4 for Amiga communication", what do you mean by that?

Also I have managed to build and compile the A500KBConfig program and the ATmegaBoard.hex successfully. I'm assuming you use Flip (Windows) software to flash or do you recommend another program?

[gotnull]

@HenrykRichter any help with the flashing would be much appreciated.

[HenrykRichter]

You mention:

UART is connected to KBCLOCK and KBDATA lines. With debug on, please connect the FT232RL to KBCLOCK/KBDATA and use IN3/IN4 for Amiga communication.

I can see the CLK/KDATA on the PCB near RST and 5V+ so I'm guessing these are KBCLOCK/KBDATA that you're referring to. What I'm not sure about is "use IN3/IN4 for Amiga communication", what do you mean by that?

Also I have managed to build and compile the A500KBConfig program and the ATmegaBoard.hex successfully. I'm assuming you use Flip (Windows) software to flash or do you recommend another program? Please have a look at the updated repository. I've done some improvements to the A500KBConfig program (now at version 1.7) which address timing issues I encountered on slow Amigas (68000/68010). The startup delay where the config is loaded from the keyboard should also be shorter now.

In addition, I've provided pre-built ATMega images. Those are identical in functionality. The only difference is the reported type of Keyboard (A500, A500Mini or A3000) as reflected by the Amiga configuration program.

An example flashing procedure is outlined in the updated Readme in the "src/" subdirectory. As I am avoiding Windows as far as possible (Amiga aficinado, after all), I do perform ATMega flashing using AVRDude.

[HenrykRichter]

You mention: I can see the CLK/KDATA on the PCB near RST and 5V+ so I'm guessing these are KBCLOCK/KBDATA that you're referring to. What I'm not sure about is "use IN3/IN4 for Amiga communication", what do you mean by that?

Sorry about the confusion. What you've stumbled over were essentially my notes for the case that I should need ATMega-side serial debugging output in the future.

The regular builds of the ATMega software will result in an intuitive pinout provided by the firmware, where you need 4 wires left, 3 wires right on the main set of holes, exactly matching what the A500 keyboard connector has. The two additional pins (IN3,IN4) can take low-active sources (HDDs,Network etc.) that can be reflected on any of the LED's.

[gotnull]

So I'm having issues trying to find the correct parts for: D53, D52, D51, D7, D1, D6, D5

I thought the correct parts were: CLV1A-FKB-CK1VW1DE1BB7C3C3 although they don't seem to fit according to this:

The yellow is the pins of the part and the green is the pad on the PCB.

Any idea what the correct part numbers are. I'm using JLCPCB who've come back with this issue.

[HenrykRichter]

I thought the correct parts were: CLV1A-FKB-CK1VW1DE1BB7C3C3 although they don't seem to fit according to this:

Those LEDs are indeed "Common Anode" but have a different pin assignment than those I've fitted. Please note that those Cree LEDs would have to be mounted 180 degrees rotated to have the Anode at the +5V pad. Also (as noted before), the R,G,B assignments are different.

An example for LEDs with the correct R,G,B assignment would be from Würth, order no 150141M173100. This type of LED would also needed to be mounted with 180° rotation, though.

I am aware that the pads are not long enough for automated PCB population with solder paste under the LEDs as the PCB was designed with hand soldering in mind. What I could offer is to re-design the LED part for those Würth LEDs, so that both pads and orientation are usable with automated part population processes.

I'll post here once I find some time re-doing the PCBs.

[gotnull]

I thought the correct parts were: CLV1A-FKB-CK1VW1DE1BB7C3C3 although they don't seem to fit according to this:

Those LEDs are indeed "Common Anode" but have a different pin assignment than those I've fitted. Please note that those Cree LEDs would have to be mounted 180 degrees rotated to have the Anode at the +5V pad. Also (as noted before), the R,G,B assignments are different.

An example for LEDs with the correct R,G,B assignment would be from Würth, order no 150141M173100. This type of LED would also needed to be mounted with 180° rotation, though.

I am aware that the pads are not long enough for automated PCB population with solder paste under the LEDs as the PCB was designed with hand soldering in mind. What I could offer is to re-design the LED part for those Würth LEDs, so that both pads and orientation are usable with automated part population processes.

I'll post here once I find some time re-doing the PCBs.

That would be terrific, thank you!

[gotnull]

PCB’s have finally arrived and I was initially going to go with Cherry MX switches, however I can’t seem to find anywhere that sell keycaps that will work for the A500 layout and size.

What keycaps are you using in your photos? I’m assuming they’re Mitsumi compatible keycaps.

Any idea where I can source Cherry MX keycaps?

[kavanoz64]

PCB’s have finally arrived and I was initially going to go with Cherry MX switches, however I can’t seem to find anywhere that sell keycaps that will work for the A500 layout and size.

What keycaps are you using in your photos? I’m assuming they’re Mitsumi compatible keycaps.

Any idea where I can source Cherry MX keycaps?

There is no fully Amiga compatible Cherry MX keycaps. Henryk had recommended to use Mitsumi mechanical switches used on A1000 keyboards. These feel like Cherry MX Brown (silent) and are compatible with a1200.net keycap sets. https://www.ebay.com/itm/325236069397 https://www.aliexpress.us/item/2251832448720693.html

[gotnull]

@HenrykRichter are you able to confirm the current wiring is correct?

I’ve flashed the A500.hex via avrdude and it’s flashed successfully.

I’ve also opened the A500KBConfig but the popup dialog, which says:

Loading current configuration from A500 keyboard… ATT : DON’T TOUCH ANY KEY UNTIL THE REQUESTER DISAPPEARS!

This process might take some seconds

It never actually disappears for me on my A500. I am noticing that the CAPS LED flashes every few seconds though.

If I click cancel it takes me it does take me to the Config. If I click Save EEPROM that also seems to save, however I don’t have any LED’s soldered yet.

Now if I access CLI it seems as if the SPACEBAR is constantly pressed down.

Any ideas what might be wrong?

[gotnull]

@kavanoz64 any ideas?

[kavanoz64]

I installed all 7 RBG LEDs and was able to configure them using the app running under OS 3.2.1. I suggest you check all the connections and maybe install the LEDs if you have them. My CTRL key was initially not working (except it was resetting using CTRL+A+A). After using the app CTRL key is also working.

[gotnull]

I installed all 7 RBG LEDs and was able to configure them using the app running under OS 3.2.1. I suggest you check all the connections and maybe install the LEDs if you have them. My CTRL key was initially not working (except it was resetting using CTRL+A+A). After using the app CTRL key is also working.

Do you have the model number and link to the LEDs you used?

[kavanoz64]

It is the one Henryk mentioned earlier https://www.mouser.com/ProductDetail/Wurth-Elektronik/150141M173100?qs=2kOmHSv6VfT%2Fmnpysgc7Ng%3D%3D

[gotnull]

It is the one Henryk mentioned earlier https://www.mouser.com/ProductDetail/Wurth-Elektronik/150141M173100?qs=2kOmHSv6VfT%2Fmnpysgc7Ng%3D%3D

Thanks for the confirmation. I'm glad to see that they're working.

Can you confirm for me that I've hooked up the wiring correctly to the A500?

https://github.com/HenrykRichter/A500KB/issues/4#issuecomment-1698604415

[gotnull]

I think this might be the problem:

bash-3.2$ avrdude -c usbasp -p at90usb1287 -U flash:w:A500.hex:i
avrdude error: cannot set sck period; please check for usbasp firmware update
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e9782 (probably usb1287)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude error: cannot set sck period; please check for usbasp firmware update

avrdude: processing -U flash:w:A500.hex:i
avrdude: reading input file A500.hex for flash
         with 7132 bytes in 1 section within [0, 0x1bdb]
         using 28 pages and 36 pad bytes
avrdude: writing 7132 bytes flash ...
Writing | ################################################## | 100% 4.55 s
avrdude: 7132 bytes of flash written
avrdude: verifying flash memory against A500.hex
Reading | ################################################## | 100% 3.66 s
avrdude warning: verification mismatch
        device 0x00 != input 0x0c at addr 0x0000 (error)
avrdude error: verification mismatch

avrdude done.  Thank you.

There's a verification mismatch when flashing, which I'm not sure how to resolve.

avrdude warning: verification mismatch
        device 0x00 != input 0x0c at addr 0x0000 (error)
avrdude error: verification mismatch

As well as:

avrdude error: cannot set sck period; please check for usbasp firmware update

EDIT: Flashing a few more times and plugging in the USB file flashing seemed to suppress the verification mismatch error.

NOTE: This was with an different PCB and the same problem persists where no keys are working and saving to EEPROM doesn't fix the issue.

[kavanoz64]

Your keyboard connection looks Ok.

The programming errors are not good. I am using this cheap USBASP from Amazon. https://a.co/d/5L7F6Pr

I use AVRDude on Windows 11. I didn’t install the driver mentioned for this product. There was a general guide I found for installing these devices on Windows 10/11 and it worked fine. https://www.instructables.com/USBASP-Installation-in-Windows-10/?amp_page=true

When I run avedude there is a warming/error at the beginning but the programming part works fine and verification passes.

[gotnull]

Your keyboard connection looks Ok.

The programming errors are not good. I am using this cheap USBASP from Amazon. https://a.co/d/5L7F6Pr

I use AVRDude on Windows 11. I didn’t install the driver mentioned for this product. There was a general guide I found for installing these devices on Windows 10/11 and it worked fine. https://www.instructables.com/USBASP-Installation-in-Windows-10/?amp_page=true

When I run avedude there is a warming/error at the beginning but the programming part works fine and verification passes.

I have the exact same programmer and if I plug in a USB cable it verifies the firmware just fine. So it's not really a problem with flashing anymore. I still get the problems with the keyboard and the keys not working though. I haven't soldered on any switches or LEDs yet.

[gotnull]

I've spent hours trying to work out what's wrong with these and I'm honestly at the point where I'm going to give up. It's such a shame because I really wanted to get this working.

I've tried different programmers, different firmwares (even though they're all the same), i've checked all connections, etc. The only thing pending would be to actually solder on the LEDs, but I honestly don't think that's even the problem considering they're just LEDs in the first place and offer no real reason as to fix the issues I'm seeing.

If anyone bothers to see these comments and has the time to investigate that would be greatly appreciated. Perhaps even documentation on how to debug as that is not available and I'm unsure where to start.

[kavanoz64]

Can you upload a hi-res photo showing the whole top right area and a few keys with diodes? I don't know how much I can help. The PCB is not complicated. If they produced right and you don't have any soldering issue on the ICs, it should work.

Here is some photos from mine. First ones with modified color schema. Unfortunately the 3D printed parts for the key stabilizers didn't work for me, the wires are not staying in the holes. I got them printed at JLC with resin, even with different smaller hole sizes, but I think there is a limit with their process. Space Bar has a thicker wire and that one works, albeit the noise it makes is not ideal. I am thinking of a different design more resembling the wire mounting of the original keyboards, but I am not even a rookie when it comes to 3D design. For now, most of the keys work fine without stabilizers, except right Shift key which is long so need to press to the center of the key.

[gotnull]

Thank you so much for helping out and for also including photos of your PCB. This will help to determine if at least the IC's are soldered on the right way.

[kavanoz64]

It looks good to me.

So you only populated 2 ICs and pin headers. I will try to populate another PCB exactly the same way without switches and LEDs and test with it. If it works, I can send it to you (hopefully you are in the US).

[gotnull]

It looks good to me.

So you only populated 2 ICs and pin headers. I will try to populate another PCB exactly the same way without switches and LEDs and test with it. If it works, I can send it to you (hopefully you are in the US).

I have two PCB's both without LEDs and switches and both behave the same way. Unfortunately I'm in Australia so that wouldn't be an option, however thank you very much for offering.

From your photos, it's difficult to tell whether my SMD's are soldered in the correct orientation.

[gotnull]

I've got a feeling it could actually be the way I've compiled my A500KBConfig:

PS D:\AMIGA\A500KB\asrc> make clean
rm -f A500KBConfig  startup.o utils.o config.o cx_main.o window.o capsimage.o pledimage.o pledbutton.o ledmanager.o ciacomm.o savereq.o 
PS D:\AMIGA\A500KB\asrc> make
m68k-amigaos-gcc  -c -noixemul -Wall -O2 -fomit-frame-pointer -msmall-code  -o startup.o startup.c
startup.c: In function 'Startup_WB':
startup.c:150:16: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
   if( (ttarg = FindToolType( (STRPTR*)dobj->do_ToolTypes,(STRPTR)ttitems->name)) )
                ^~~~~~~~~~~~
m68k-amigaos-gcc  -c -noixemul -Wall -O2 -fomit-frame-pointer -msmall-code  -o utils.o utils.c
m68k-amigaos-gcc  -c -noixemul -Wall -O2 -fomit-frame-pointer -msmall-code  -o config.o config.c
m68k-amigaos-gcc  -c -noixemul -Wall -O2 -fomit-frame-pointer -msmall-code  -o cx_main.o cx_main.c
m68k-amigaos-gcc  -c -noixemul -Wall -O2 -fomit-frame-pointer -msmall-code  -o window.o window.c
m68k-amigaos-gcc  -c -noixemul -Wall -O2 -fomit-frame-pointer -msmall-code  -o capsimage.o capsimage.c
capsimage.c: In function 'init_capsimage_class':
capsimage.c:255:32: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
  cls->cl_Dispatcher.h_Entry    = (HOOKFUNC)caps_dispatch;
                                ^
capsimage.c:259:32: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
  cls->cl_Dispatcher.h_SubEntry = (HOOKFUNC)caps_dispatch;
                                ^
m68k-amigaos-gcc  -c -noixemul -Wall -O2 -fomit-frame-pointer -msmall-code  -o pledimage.o pledimage.c
pledimage.c: In function 'init_pledimage_class':
pledimage.c:471:32: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
  cls->cl_Dispatcher.h_Entry    = (HOOKFUNC)pled_dispatch;
                                ^
pledimage.c:475:32: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
  cls->cl_Dispatcher.h_SubEntry = (HOOKFUNC)pled_dispatch;//pled_dispatch;
                                ^
m68k-amigaos-gcc  -c -noixemul -Wall -O2 -fomit-frame-pointer -msmall-code  -o pledbutton.o pledbutton.c
pledbutton.c: In function 'init_pledbutton_class':
pledbutton.c:459:32: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
  cls->cl_Dispatcher.h_Entry    = (HOOKFUNC)pledb_dispatch;
                                ^
pledbutton.c:463:32: warning: assignment from incompatible pointer type [-Wincompatible-pointer-types]
  cls->cl_Dispatcher.h_SubEntry = (HOOKFUNC)pledb_dispatch;//pled_dispatch;
                                ^
m68k-amigaos-gcc  -c -noixemul -Wall -O2 -fomit-frame-pointer -msmall-code  -o ledmanager.o ledmanager.c
vasmm68k_mot -Faout -quiet -I/amiga-gcc/m68k-amigaos/ndk-include/  -o ciacomm.o ciacomm.s
m68k-amigaos-gcc  -c -noixemul -Wall -O2 -fomit-frame-pointer -msmall-code  -o savereq.o savereq.c
m68k-amigaos-gcc  -s -noixemul -lamiga -nostartfiles -o A500KBConfig  startup.o utils.o config.o cx_main.o window.o capsimage.o pledimage.o pledbutton.o ledmanager.o ciacomm.o savereq.o
PS D:\AMIGA\A500KB\asrc> 

Perhaps you could attach your A500KBConfig file and I could test that? I tried using the one straight from this repository but it doesn't execute on my A500.

[kavanoz64]

I saw your parts were assembled correctly.

On my A500 it didn't execute with OS 3.2 install disk (copied it to RAM: to run). When I boot with TF536 IDE installed with 3.2.1, it works.

[gotnull]

I saw your parts were assembled correctly.

That's great to hear and thank you so much for confirming this for me!

On my A500 it didn't execute with OS 3.2 install disk (copied it to RAM: to run). When I boot with TF536 IDE installed with 3.2.1, it works.

I am running PiStorm and I can get the A500KBConfig running although like I mentioned previously the requester window does not disappear (this is still without LEDs). Saving to EEPROM seems to work and no dialog pops up telling me that it’s not an A500KB, so I’m assuming it’s recognising the keyboard correctly.

I bit the bullet and soldered all of the switches because it was literally my last resort and unfortunately it still doesn't work properly.

I'm noticing that the first switch I press down repeats itself (e.g. pressing "k" results in kkkkkkkkkkkkkkkkkkk, "i" would result in iiiiiiiiiiiiiiiiii continously, very very frustrating).

The only thing pending is to solder LEDs, although I don't see how that would fix the issue? This seems like an issue with either the firmware or SMDs (although you've confirmed they're correct and in their correct orientation).

I am baffled, confused and have no idea what the problem could be.

Perhaps @HenrykRichter could provide some insight when he has some time?

[kavanoz64]

I tested another PCB with ICs soldered without LEDs and switches. Programming worked fine and the keyboard also worked. I was able to use the utility in Amiga OS and keys were working when I shorted the pins. So if you are getting the same result on 2 PCBs, either there is a problem with the production or some incompatibility with your machine. Do you have another Amiga to test it?

[gotnull]

I tested another PCB with ICs soldered without LEDs and switches. Programming worked fine and the keyboard also worked. I was able to use the utility in Amiga OS and keys were working when I shorted the pins. So if you are getting the same result on 2 PCBs, either there is a problem with the production or some incompatibility with your machine. Do you have another Amiga to test it?

Thanks for doing this, I wonder if it’s the rotation of some of the SMD’s and diodes that’s the problem? If you have time can you send me close up screenshots of all your components and some diodes?

Any idea how much shipping would cost from US to Australia? :/

Also, I’m curious to know if running the A500KBConfig is necessary for the keyboard to work properly other than setting up the LEDs?

Do the switches work on a new flash without running the config?

[kavanoz64]

Shipping will cost about $20 using PirateShip Simple Export service. This is what I usually use when shipping stuff to AU. Keys were working before running the config utility. Here is some close up photos.

[gotnull]

Shipping will cost about $20 using PirateShip Simple Export service. This is what I usually use when shipping stuff to AU.

I would be absolutely fine with paying $20 for the shipping to AU if you’re happy posting it.

Thanks for the closeup photos. All the diodes seem to be the correct orientation and everything else like you said seems to be correct.

[kavanoz64]

Send me an email. I am using the most well known email service with the same username here.

[gotnull]

Send me an email. I am using the most well known email service with the same username here.

Thanks, email sent!

[HenrykRichter]

I am running PiStorm and I can get the A500KBConfig running although like I mentioned previously the requester window does not disappear (this is still without LEDs). Saving to EEPROM seems to work and no dialog pops up telling me that it’s not an A500KB, so I’m assuming it’s recognising the keyboard correctly.

Please try the pre-compiled binary from the respective subdirectory if your self-compiled version is a little older. I fixed a read-write turnaround bug in the CIA communication code recently. I also cannot comment about PiStorm compatibility. I've checked the functionality on 68000/68010, 68030, Vampire V2 and 68060 on different computers but couldn't bring myself to install Pi's other than as FlickerFixers :-).

I bit the bullet and soldered all of the switches because it was literally my last resort and unfortunately it still doesn't work properly. I'm noticing that the first switch I press down repeats itself (e.g. pressing "k" results in kkkkkkkkkkkkkkkkkkk, "i" would result in iiiiiiiiiiiiiiiiii continously, very very frustrating).

Sadly, there could be more than one reason why this can be seen. First, please re-flash the firmware with the latest upload. What I forgot to mention (and that's really on me) is that the fuses were meant to be set alongside the flashing of the firmware. What happened is that your board runs at 2 MHz (default clock prescaler 8) instead of the 16 MHz the timing considerations were made for. The new firmware (from just now) will delete the x8 prescaler in software so that the MCU will run at 16 MHz, even when the fuses are not flashed. Hopefully, that's the easy way out.

To give some context: I've basically duplicated the A500 keyboard matrix for this project, with the idea that the upper right portion of the main PCB could also be used as replacement keyboard controller for the classic Mitsumi keyboards. The controller sets pins 44-49 to "high" while the keyboard scan is inactive. Each active pin of those is then pulled low in the scanning process, such that a pressed key will drag the respective input pin (Pin 33-43, 1,9,18,19) down, should a key be pressed. So if a "keyup" is not detected, then either it wasn't transmitted to the Amiga properly -or- the internal Pull-up in the AtMega doesn't work as intended.

The only thing pending is to solder LEDs, although I don't see how that would fix the issue? This seems like an issue with either the firmware or SMDs (although you've confirmed they're correct and in their correct orientation).

The LEDs are not relevant. They are just analog LEDs that sit behind the LED controller. The ATMega will periodically send sequences to the LED controller and won't really care what that one does with them.

[HenrykRichter]

Perhaps you could attach your A500KBConfig file and I could test that? I tried using the one straight from this repository but it doesn't execute on my A500.

Probably the executable flag got missing when transferring that file, perhaps Protect A500KBConfig +e will be sufficient (from CLI). Otherwise, those warnings by the compiler are harmless. Different versions of the AmigaOS SDK have different data types for the same outcome.

[HenrykRichter]

avrdude error: cannot set sck period; please check for usbasp firmware update

This warning typically shows with the reduced USBasp clones from China that don't have the SCK speed jumper. Those Clones tend to work just fine (I have one, too) but won't support fast flashing.

[HenrykRichter]

@HenrykRichter are you able to confirm the current wiring is correct?

The wiring will work, although one of the cables is superflous. The A500 keyboard connector has a key pin, which is pin5. So wiring needs to address pins 1-4 and pins 6-8. In your case of the picture, the black wire is not needed (but doesn't hurt, either).

[gjorans]

Sorry to ask this but I am very newbie on this. Is there a Zero to hero guide for making this? what to upload at pcbway etc? I am totally lost (but know how to solder).

[HenrykRichter]

Sorry to ask this but I am very newbie on this. Is there a Zero to hero guide for making this? what to upload at pcbway etc? I am totally lost (but know how to solder).

This project is relatively complex, due to a combination of PCBs (which require a mix of SMD and THT soldering), a uC that needs programming and 3D printed parts.

The biggest obstacle to overcome in the planning phase is the combination of keyswitches and matching keycaps. There is one option of procuring Mitsumi switches, for which new keycaps are available. Otherwise, Cherry (or compatible) switches may be mounted, too. The downside for Cherry MX, however is that I know of just one person (kipper2k) who has been able to obtain a full Amiga compatible set of keycaps (from an undisclosed source).

I don't know if PCBWay accepts the Gerber files I've prepared. So far, I only ordered with JLCPCB. To order a PCB, you basically just need to zip the contents of the "A500KB_Gerber" folder, upload that to the site and enter some basic information (HASL is OK for this type of PCB, 2mm thickness to make it somewhat sturdy). The second PCB production files are "A500KBPlate_Gerber". The plate should be 1mm. It can be made out of FR4 (like most other PCBs) or (in case of JLCPCB) also Aluminum.