Neogeo diag bios crosshatch testing / custom prog board

[ack]

1) With a modified z80 test cart the main bios screen now shows these codes (SM1, M1 S1) in the top right after z80 testing. Looks like they refer to the CHAR EPROMS, but what do they mean?

• M1 indicates that z80 tests were run, same as the original diag bios.
• S1 (Sn) is indicating a slot switch happened and which slot was switched to. This is mainly useful when testing multi-slot boards where you have a diag cart in each slot. You get confirmation about which slot was tested. The Sn will not show up on motherboards that don't have a build-in SM1 rom, since no slot switch happens.
• SM1 is indicating a crc32 check was done against the motherboard's SM1 rom and it was correct. The diag M1 rom will copy part of it self into ram, and switch execution to it. The diag sp1 is told to switch back to the SM1 rom, the ram running diag m1 code will do the crc32 check, then the diag sp1 is told to switch back to the diag m1 rom at which point execution jumps back to running from the diag m1 rom.

2) The p-rom test PROG board had three LED indicators on it (I relocated them on this version). Should all three of them be lit when the p-rom tests are running? And what does it mean if only some of them are lit?

SLOTCS LED indicates the slot is active. This should be on when you select the P-ROM test and I think just selecting the slot for z80 test should also cause it to be on. It should remain on unless you do something to switch to another slot. It might always be on for one slot boards, I dont recall.

When the P-ROM test is running the ROMOE and PORTADRS LEDs should be on, but likely a bit dim compared to the SLOTCS LED. They will be off when the test is not running.

There are 3 signals for reading from the P1 ROM on the cart. They are all on the cart edge

• ROMLOE (read lower byte only)
• ROMUOE (read upper byte only)
• ROMOE (read both)

The diag PROG cart is wired up to use ROMLOE and ROMUOE for reading from the SRAM chip. This leaves ROMOE untested and is why I have it wired to the LED so you can verify its getting enabled.

The same type of thing for the PORTADRS LED (usually for reading from P2 ROM / bank switching)

• PORTLOE (read lower byte only)
• PORTUOE (read upper byte only)
• PORTADRS (read both)

 

[bodgit]

Just found these, might have to build an AES and MVS version next time I put a PCB order in.

 

[bodgit]

My kilo parcel of JLCPCB PCBs arrived so I have a pair of each type to build up.

PCB fabs being what they are with minimum orders, I of course now have spares so if anyone wants a set of MVS and/or AES PCBs I have four spare of each which I'm happy to pass on for cost. I chose black, ENIG finish, gold fingers, chamfered edge, etc. so they're not the cheapest.

I went for the TQFP CPLD variant as the chips seem to be in stock compared to ~2 years ago so they should turn up quicker than NEO-ZMCs from AliExpress and QFP is easier to hand solder than faffing with PLCC sockets.

 

[bodgit]

I tried to program the CPLDs using a genuine USB Blaster that I happen to have and I couldn't get the JTAG scan to see anything on either of the two boards I built. The USB Blaster was confirmed working with another different JTAG device so it should in theory have worked.

In the end I grabbed the same cheap FTDI USB gadget from Amazon and wired up the same 6 wire harness and it worked first time on both boards.

Before I try and use them, perhaps the one stupid question; on an MVS the PROG board should be topmost facing up, and on AES (or MVS with vertical slots) it should be rearmost facing away from the joystick ports?

 

[ack]

I tried to program the CPLDs using a genuine USB Blaster that I happen to have and I couldn't get the JTAG scan to see anything on either of the two boards I built. The USB Blaster was confirmed working with another different JTAG device so it should in theory have worked.

Were you supplying external power to the chip? The USB Blaster VCC pin is just for voltage reference so it won't power the CPLD.

In the end I grabbed the same cheap FTDI USB gadget from Amazon and wired up the same 6 wire harness and it worked first time on both boards.

These boards usually supply power on their VCC pin.

Before I try and use them, perhaps the one stupid question; on an MVS the PROG board should be topmost facing up, and on AES (or MVS with vertical slots) it should be rearmost facing away from the joystick ports?

Thats correct.

 

[bodgit]

Were you supplying external power to the chip? The USB Blaster VCC pin is just for voltage reference so it won't power the CPLD.

I was using this pinout which seems to match every genuine and clone USB Blaster:

I generated a separate +5V supply from USB and fed that to both the PCB and the USB Blaster on pins 2,4 & 10. I then wired the remaining 4 T* JTAG pins between the PCB and Blaster leaving pins 6-8 unconnected. I figured that would be it?

While I was waiting for that FTDI gadget to arrive I tried reflowing the solder joints, wondering if I had fried the CPLD with too much heat, or got some bad ones that had the JTAG disabled.

These boards usually supply power on their VCC pin.

That definitely made it simpler to hook up and program. JTAG does seem to be a bit voodoo at times, but that just might be Quartus that has jaded me, that seemed to be really fickle and version-dependent for programming the FPGA I was using previously. OpenOCD is much simpler and lightweight.

 

[bodgit]

MVS version seems to work fine on my MV1B.

However the first time I tried it on power up, I got a VRAM 32K error. Stupidly I should've taken a screenshot, but from memory it displayed 10000 underneath. I power cycled multiple times and I haven't been able to reproduce it again. I've also left the VRAM tests running in a loop for a while and not had any error pop up.

Anything to worry about?

 

[ack]

I'm not sure how that would be related to the diag prog board.

 

[bodgit]

I'm not sure how that would be related to the diag prog board.

No, I didn't think it would be, more likely just a general diagnostic BIOS query. I've done a bit more testing so I'll throw up a separate post.