The first R5 board is on its way to me from Germany, so it's time to get organised and build a test bitstream for it before it arrives. I was hoping that the new i9 13900K-based FPGA build machine would be ready first, but I'm still waiting for the parts to arrive, so I'll be synthesising using my increasingly venerable i7 laptop, that dates back to around 2017. It's still not bad, but probably 3x slower than the i9 will be for FPGA synthesis. It will be nice to get synthesis times down to around 10 minutes.
Anyway, let's focus on what needs to be done for the R5:
1. Some IEC lines have changed pins.
2. Some cartridge ports have changed control mechanisms.
3. The DIP switches are now connected to an I2C IO expander. There are now 8 of them instead of 4, and there are also four pins each for board major and minor version on there, too, so that we can tell the R5 apart from any future boards, or variants, e.g., if we change the SDRAM, HyperRAM and/or QSPI flash part on future batches.
4. The DC-DC power supplies have an I2C interface and a register that needs to be set to prevent noise from them.
5. The joystick data lines can now be controlled bi-directionally, to allow some funny joystick port peripherals to work correctly.
I'm starting with the DIP switches, and just getting a bitstream building, even though it won't yet work. By running a complete synthesis run I can tell if I have the top-level pin changes in order, and the general infrastructure for the new R5 target in the automated build system.
That build. So now I have added the new signals for the cartridge port to the XDC file. That's probably all that's required on that front for now, because the MEGA65 core doesn't initially need to make use of them.
Ah, now having done the DIP switch stuff, I have just realised that they are not in fact connected to the same I2C bus as the rest of the I2C device: Rather the dip switches and DC-DC converters are on their own dedicated I2C bus. So I'll need to rejig some of the plumbing. On the flip side, it does rather simplify some stuff, as it means I don't have to modify the R4 I2C device controller, but rather can re-use it for the R5.
Okay, the board has arrived!
First thing, it looks like the (very easy to make) mistake has been
made of putting the DIP switch bank foot print on the reverse side of
the board has been made. This will be easy to fix for production. You can see the DIP switches on the rear in this next shot:
Second, I was warned that the DC-DC regulators make a lot of unpleasant noise, if they aren't appropriately programmed via I2C to use the correct mode. And they certainly do! They sound like an old 15KHz CRT that is about to die. So first step is to try to find out how to program those to shut them up. We do this by setting the MODE bit (bit 0 of register 1) on the DC-DC converters. There are two of them, and they have I2C addresses $61 and $67. So I'll make the I2C master set those periodically in an endless loop. I'll also make it read the I2C expander DIP switches and board revision signals.
Well, a week has gone by with a lot of stuff going on that has limited my time to sink into this. On the up-side, this has allowed time for my new FPGA build box to arrive and get setup: I can now synthesise a MEGA65 core in about 11 minutes, instead of 25 -- 40 minutes. A very welcome improvement!
Michael has also discovered an oddity in the R5 schematic, that means that some joystick lines can only be read when the cartridge port is enabled. So I have gone on to fix the state of that line for the MEGA65 core.
BASIC is still not booting -- this time, it looks like $DD00 has some bits set wrong, causing the C65 ROM to be stuck in a loop waiting for an IEC connected drive to respond to a request to load a boot file, because CLK and DATA are low, fooling the KERNAL into thinking that there is a device attached. So I'll have to check the IEC lines.
At least the CLK and DATA lines are staying low, even if I tie the output enables for those lines high, which should be dis-activated. It's all a bit of a mystery, as these bi-directional driver circuits are fairly simple, and we have used them elsewhere on the design before. I've even checked that the 5V supply to them isn't being switched off or anything crazy like that.
Well, I think I had some error in my build environment for using the new build server, where it was using old versions of files, because after some fiddling, it's all working as originally expected. The joys of teething problems :/
Anyway, I'm not looking back at the I2C interface to the DC-DC converters and the DIP switch I2C IO expander. In theory this should be pretty easy to get working: I've started by copy-pasting and adapting one of the existing I2C controllers from one of the other MEGA65 board revisions. I have clearly messed something up, though, because under simulation it only does the first two I2C transactions, and then sits stuck after the I2C driver clears its BUSY flag.
It took way more messing around with the I2C master, as I seem to be doing some quite strange things with it in the other board revisions, even though it works for those. So I have refactored things around a bit, and can now read the DIP switches and board revision resistors and set the DC-DC mode under simulation. I quickly built a bitstream with the new build box to confirm that it fixes the DC-DC noise, which it does :) Next, let's check that the board revision resistors and DIP switches get read correctly...
I had set aside this Sunday morning to make more progress, but was rather thwarted by a tree falling on the power-lines nearby, resulting 10 hours WOE (With Out Electricity). So I didn't get any MEGA65 stuff done this morning, apart from looking up a datasheet on my phone. But it did get me to finally get around to buying a pure sine-wave inverter for these situations, so that our fridge and freezer contents don't spoil. In winter its not a big deal, but summer in Australia can easily produce days and nights where the temperature never drops below 30C, which results in rather fast defrosting of freezer contents in particular. Anyway, that's all solved now, the generator is cooling off again ready to get packed away for next time it's needed, and I have a couple of hours before dinner (roast is already in the oven) to make some more progress.
So, let's see how the DIP switch and board revision reading is going. $D69D reads the DIP switches, while $D629 reads the board revision info. At the moment they are reading as all 1's, which is what you get if an I2C device doesn't respond. The most common cause is having the address wrong. Looking through the MEGA65 R5 schematic, I can see I did indeed have the wrong address: I was using $41 instead of $40. So let's resynthesise, and see if that fixes the problem... unfortunately not. So what is going on?
The R5 board conveniently has a header that exposes the I2C lines for this bus, so I can probe it with my oscilloscope, to see if the transactions look good. I'm not really expecting them to be bad, since the simulation tests with simulated I2C devices all pass -- including reading the ports that the DIP switches and board revision lines are connected to.
It's a little hard to trace on the oscilloscope, because the transactions are repeated continuously. It might be worth trying to add a delay between them, so that I can more easily check which part of the transaction it is in at any point in time.
The plot thickens, as pages 7 and 8 of the datasheet indicates that there are many more addresses this part can end up on. It looks like there is some magic where you can connect the 3 address pins to either GND, VCC, SCL or SDA, and the IC detects this to select the correct address. It's quite a clever scheme that let's you select from 64 addresses using only 3 pins. I like it. Except that it's not yielding the address that I am expecting.Ok, I think I know what the problem is: The address is $40 in 8-bit format, not in 7-bit I2C address notation: So shifting it right one to make it $20 should fix it. Time to resynthesise again, and again glad I can do that in less than 12 minutes now, instead of taking close to an hour. If I were still using the laptop for FPGA builds, I'd have had to have resorted to making a separate test bitstream with just the I2C controller and some serial output so that I could read the output. It would have worked, but would have required more effort to construct it, and generally taken a bunch of time.
Good: I can now read the board revision info, although it's appearing in the DIP switch register. I also found that the revision was returning $FF, because I hadn't added logic to the target ID stuff in c65uart. I've now modified it so that for MEGA65 R5 boards, it reads the straps on the board, instead of just passing a hard-coded value. The target ID doesn't have extra bits for minor revision of boards, so now I have made that available in the upper nybl of $D628, which was some unused DDR bits for an IO port. I should also make it return $1 for the R3A board, except that we can't, because we have no easy way to tell the R3 from R3A at the VHDL level. So that will remain an anomaly, unless I get really excited at some point.
Anyway, to try to fix the problem with the board revision appearing in the DIP switch, I'm switching the ports used for the board revision straps and DIP switches, in case I have mixed them up some how, or that the read behaviour of the PCA9655 differs from the model I am using. If it works, then we assume that one of these must have been the case.
While I wait for those to synthesise, I can probably start to take a look at the joystick bidirectional driving: It should now be possible to pull joystick lines by setting their DDR to output and the lines to low. For example, setting $DC02 to $FF and $DC00 to $00 should pull all the lines on joystick port 2 down: And that works first go, with the plumbing I have already put in place for those lines :) Yay!
Actually, an important advantage of the MEGA65 here, is that it controls these lines as open-collector outputs. This means you can't so easily fry the MEGA65 if you put something on the joystick port that tries to pull a data line low while you are driving it high. If the joy device tries to drive it high while the MEGA65 is pulling it low you might still be able to fry the peripheral (just like on a C64), but the MEGA65 should not be harmed.
While waiting for synthesis runs, I've also generalised out the R5 board ID and related bits and pieces to also cater for any R6 or later boards. This will probably guarantee that we will never need one ;).
With that build, the RTC now works again. So that leaves only the IEC bus that requires testing now. Plugging in my Pi1541, I don't get any life. So let's investigate each of the IEC lines, and see if I can make them toggle.
The main IEC lines are controlled by bits on $DD00:
Bit #3: Serial bus ATN OUT; 0 = High; 1 = Low.
Bit #4: Serial bus CLOCK OUT; 0 = High; 1 = Low.
Bit #5: Serial bus DATA OUT; 0 = High; 1 = Low.
Bit #6: Serial bus CLOCK IN; 0 = Low; 1 = High.
Bit #7: Serial bus DATA IN; 0 = Low; 1 = High.
So let's check those first, and then deal with SRQ in a moment, as that is controlled in a different way using C65 IO registers.
So what we expect is that when the bit is 0 for output, that we will then read a high value, and vice-versa. It looks like I have them inverted, because the R5 IEC line controls are flipped. Re-inverting seems to get the CLK and DATA lines behaving properly.
I now have them right way round, and have also confirmed that ATN and RESET are correctly wired on the IEC bus... But I still can't load from the Pi1541. Could it be that the SRQ line is wrong some how? I don't think so. Or at least, SRQ is sitting high, so shouldn't be interfering.
So why on earth can't I get the Pi1541 to respond? Is it broken? I can at least test that using the R3A machine and older core... and that's not working, either. So I am guessing my Pi1541 probably has some problems.
Next will be to try a real 1541 with either a C64 ROM or with C65 ROM and switching the internal drive number away from 8. If that works, then I know it's fine. But that will have to wait for another day, as I need to sleep now.
Another day is here, and I have just squeaked the time in to test with a real 1541, and it works, so the IEC port is confirmed working.
That leaves only the cartridge port control signals.
I just tried a Radar Rat Race cartridge that uses Ultimax mode, and the MEGA65 correctly reads the /EXROM and /GAME signals, but the cartridge doesn't start. I'm sure this worked on previous boards at some point. But I'm not sure if its some change we have made in the VHDL, or a physical problem. I'll test that by trying the C64 core for the R5 board, that Michael and co have already got working.
No luck with the C64 core, either.
I'm building a new bitstream that disables cartridges while in hypervisor context, so that it's easier to try to debug the machine with a cartridge installed.
The problem I am seeing in the MEGA65 core at least, is that the ROM of the cartridge is being read as all 1s. That would be because we have new direction control registers. With those fixed, I can again start cartridges:
Now that we have everything working
So let's summarise the errata for the R5 board:
1. DIP switch footprint is on the rear of the PCB: Move it to the front-side of the board.
2. U9 /OE1 and /OE2 lines should be simply tied to GND, leaving EXP_SLOT_EN only controlling U66. i.e., U65 can be removed.
Errata that are desirable but not vital, i.e., can be deferred to an R5A board (as bitstreams will still be compatible with R5):
3. Add 3.3V line to J17, if there is space, so that additional I2C peripherals can be connected without needing to source the 3.3V from elsewhere.
4. Add a buffer between the DBG header and the joystick bi-directional control lines and U64A, with /OE controlled by DBG11. This will allow this debug header to be used either to provide those features, or alternatively, to connect a high-speed device directly to the FPGA with 11 available GPIOs.
No comments:
Post a Comment