Commodore 16 PAL to NTSC switchable conversion

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

I was looking to test some upcoming game releases from The Future Was 8 bit, and I had a title for the Commodore 16 / plus 4. I like to test these on PAL and NTSC machines to make sure there are no issues. In the past I had converted a Commodore 16, but I couldn't locate it, so I converted another one.

I have some older post about converting a PAL VIC20 into NTSC. This required a change of a crystal, a ROM, the VIC chip and a few miscellaneous parts.

The TED series made this much easier. The only differences were the clock frequency and the KERNAL ROM. I think in the past I had fitted a crystal socket so I could switch between the 14.31818MHz for NTSC and 17.73447MHz for PAL.

I thought I would try a different approach this time. The clock circuitry is all arranged neatly below the TED chip, along with some potentially useful test points.

Rather than change the crystal, I went down the route of building a second crystal osciallator. The onboard one does the PAL frequency, so I just needed to built one that did the NTSC frequency. I build a fairly standard oscillator circuit around an inverter (I actually used a NAND gate as it made the layout easier, but the principle is the same).

I also added a '257 multiplexor so I could switch between the two clocks signals without running them through a switch or jumper. A rough schematic just to give the general idea.

The plan was to disconnect the clock signal from the output of the existing clock circuit, and feed that into the 257 mux. The output of the mux would then into the TED chip.

This is the board I am going to change, the transistor Q2 and resistor R7 on the right are the final stage of the original clock circuit, and TP is the test point with that signal on.

It didn't quite work out like that because the layout of the board meant I had to cut the link between the bottom of R7 and the collector of Q2 and rejoin them missing out the second (unmarked) test point.

I picked up the clock out (blue), clock in (green), ground  (black) and 5V (red) at appropriate points and wired to a 4 pin header.

There was loads of space in the C16 case to mount the board, I wanted it close by to keep the clock wires short.

The white wire on the left is used to switch the ROM image. I burned a 27C256 with both the PAL and NTSC KERNALs in.

Time to fire up, I am using the DIAG264 cartridge from TFW8b.

The refreshed version now comes in black and has a PAL/NTSC jumper.

First off, I will try the original PAL clock routed through the new board.

So far so good, this is an updated version of Diag264 by Rob Clarke. Time to give NTSC a go.

Excellent, that looks good to me. I also added a label to the mod board so I remember what this board does in five years time when I open up this Commodore 16 and stare confused at a bit of veroboard and a couple of chips on and wonder what I did that for.

So I am pleased I couldn't find the one I modified before, this has been a much nicer solution. This is my test board where I have ZIF sockets for the two most common chips to fail, the TED which is heart of the system (sound, graphics, IO etc.), and the 7501/8501 CPU (which from now on I intend to call Dougal).

Commodore 64 IEEE-488 Cartridges and the SD2PET future

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Today I answer one of the important questions of our generation. A question that literally no one has dared to ask. Can you use an SD2PET future with an IEEE-488 cartridge on a Commodore 64?

The answers is sort of. It does sort of work, but not well enough to be much use. Let me explain further.

This is a DAMS IEEE-488 cartridge. It may looks like a VIC20 cartridge case, because it is a VIC20 cartridge case, but it does plug into a C64. I have used the same technique myself for things too big to fit into a C64 cartridge case, like the prototypes of the Marina 64 cartridge.

They seem to have taken it a step further, and have designed the board so that they can make either a C64 or a VIC 20 version and just cut off the bottom part of the board with the C64 edge connector on.

The contacts were a big corroded, so I ended up retinning all of them to get a nice clean connection.

That was a case of using fresh solder and extra flux to clean and tin the pads, then removing most of the solder leaving a clean flat contact surface.

I presume the VIC20 version would have a different ROM image, here there is a 2532 ROM with a label that says C64 IEEE V.35 I think.

The rest of the chips are a 6821 IO chip, which gives two 8 bit parallel IO ports and a few extra handshaking lines. The 6821 is essentially the same as the 6520 used in the PET, an earlier, simpler version of the 6522 and 6526 chips used in the VIC20 and C64.

There is also a pair of 75160 and 75161 IEEE488 bus drivers, so this should be properly compatible with the IEEE-488 bus specification. I have seen some C64 IEEE-488 cartridges that do not contain IEEE-488 bus drivers, and those will probably not work reliably with something like the SD2PET future.

Notice the 75160 is marked made in England, you don't see many of those. The rest are the usual Portugal and Malaysia. The board is marked Ferranti LTD 15 April 1983 (happy 37th Birthday for last week).

On the back it's marked copyright RAMS 1983. The back also has a nice soldermask, which is missing on the top side of the board.

With all that cleaned up and the ROM dumped, I gave it a go.

The ROM autostarts, and adds a DAMS IEEE CARTRIDGE banner to the screen. I couldn't see that string in the ROM dump, so it's probably encoded somehow.

OK, power off and lets wire up the drive. The SD2PET future plugs into the edge connector at the top, the same as the one used on the PET.

The power connector didn't reach, so I had to make an extension for the power cable. I used a userport cable to supply the power, you will see why later.

That all sticks out quite a way behind the C64, that is as far in to the cartridge bay as it goes. That's an awful lot of exposed traces, not very keen of that.

Powering it on, it looks promising, LOAD "$",8 loads a directory listing as normal.

You can load simple programs like this 10 PRINT favourite

But, anything that requires multiple file loads, anything that doesn't use Kernal routine, any fast loaders etc. all of those will probably not work due to the way it integrates with the C64 Kernal. There are some functions which are not vectored which means they cannot be replaced by a cartridge ROM and are hard wired to use the IEC bus, so anything more complicated than plain LOAD and SAVE will probably not work. There are also potential issues with memory at the same address as the cartridge ROM, The only way to do it properly would be with a replacement Kernal ROM rather than as a cartridge.

I tried various browsers. the normal file browser FB / FB64 etc. worked. I tried CBM commander and the splash screen loaded.

but both SDBrowse and CBMCommander locked up trying to read directories. So they were hitting the issue of either custom disk access routines, or using the non-remappable Kernal routines which will not know they need to talk out the cartridge port to an IEEE-488 bus rather than the usual IEC bus.

I was interested to see how it would cope with IEC devices used at the same time, so plugged one in (which is why I left the datasette port clear for power).

OK, it's getting quite congested back there, that's an old SD2IEC which has been set to act as device ID 9, and that does work as expected. The IEEE-488 drive is ID 8, and if the IEC device is also ID 8 it will be ignored, but if you set the the IEC drive as ID 9, you can access both of them at the same time.

I did notice it was a lot faster loading things from IEEE-488 compared to IEC, approximately 30 seconds to load Rodman from IEC and 5 seconds from IEEE-488, so that is an advantage. This sort of thing would have been used back in 1983 to attach big old PET drives or the newer faster SFD-1001 type drives to a C64 for BBS work. Fast access to lots of plain files. For that it should work well.

If you want to load cracked games with custom fastloaders, forget it. With so many thing won't work and your desk will be such a mess that I really couldn't recommend it.

So, in conclusion:

• Can you do it? - Yes
• Does it work? - Sort of
• Should you do it? - No

Upgrading the divMMC future firmware

The divMMC future uses ESXDOS firmware, which is periodically upgraded. When a new release is published, we test it and when we are confident there are no problems, we start shipping the divMMC future with the new firmware. Currently, we are shipping version 0.8.7.

Users with older units can upgrade their firmware to the later version if they want to, although it is only advisable to do this if you want to make use of a new feature, or if there is a bugfix which is relevant to you. You may also be advised to reflash the firmware if it has been corrupted due to use with a faulty Spectrum. But in general:

If your divMMC is working, you do not need to upgrade the firmware.

The version of firmware you have is shown top left of the screen when the Spectrum first powers on. This one has version 0.8.5, not the latest version, but it is working fine so I have not upgraded it. But for the sake of science, I am going to upgrade this today to show you the process.

1. Load firmware flasher
2. Eject SD card
3. Check you have ejected the SD card
4. Did I mention ejecting the SD card?
5. Run the firmware flasher
6. Update the BIN and SYS files on the SD card
7. Reinsert the SD card and reboot

The first step is loading the firmware flasher program. You can download the files from esxdos.org, or from the TFW8b download page. If your divMMC is currently working, you can copy the flasher program onto the SD card and run it from there. Do not update the BIN and SYS files yet, as the divMMC needs to boot up with the old firmware and old BIN and SYS files before it runs the flasher.

You can also load that .tap file into the Spectrum using a device like the Tapuino or TZXduino or via a phone app. Also in that folder, there is a wav file. You can play that into the Spectrum using a audio player on a laptop or phone.

If you can't do any of those things, then you can buy a prerecorded cassette with the flasher tool for the latest versions from the TFW8b store

With that, you need a suitable cassette player.

Or a +2 with a built in cassette deck.

Once you have loaded the flasher program by whatever means, you will be presented with a screen which tells you to adjust JP2.

No matter how extensively you search around the divMMC future, you will not find JP2. Don't be tempted to open one up as this will invalidate your warranty (and spoil the nice case), and it's not in there anyway.

JP2 would be used to disable the divMMC to allow the firmware to be upgraded. On the divMMC future, we wanted it to be jumperless, so we use the SD card to control this. If the SD card is inserted, the interface is enabled. If it is ejected, the interface is disabled, so it can be reflashed. So all you need to do is push in the SD card to eject it.(we don't recommend using a microSD in an adapter, but if you are using one of those, remove the adapter as well, not just the SD card)

This is what you want to see, a clear air gap around the SD card. You may thing I am over stressing this point, but I have had quite a few people who have had problems doing this upgrade because they had missed out the step where you eject the SD card.

When you press a key, if you forget to eject the SD card, the screen will go an angry red to remind you to re-read the instructions.

If you have remembered to eject the SD card, congratulations, the new firmware will be installed, the screen border will flash funky colours for a while, and when that has stopped it will return with an OK message to indicate it has finished.

Now is time to upgrade the BIN and SYS files on the SD card. 

The version of files on the SD card needs to match the firmware.

If they don't, it will not work properly. So plug the SD card into a PC or laptop via a card reader. I am using an SD2USB card reader, but you can use whatever you have.

Once the new files are copied onto your SD card, reinstall it into the divMMC and boot up again.

The boot screen should have been updated to show the new version, currently V0.8.7. Note the RTC.SYS file [ERROR] will always be there on older firmware versions as most divMMCs do not have a built in real time clock. It would be good if future versions came with a dummy RTC.SYS file so there were no errors displayed. This is now the case.

Everything should now be the same, press the NMI button (the illuminated one) and you should see the file browser menu and away you go.

So, the moral of the tale is, don't upgrade the firmware unless you need to, and if you do need to, remember to eject the SD card.

---

Advertisements

DivMMC Future

The DivMMC Future is avaiable from The Future Was 8 bit

https://www.thefuturewas8bit.com/shop/sinclair/divmmcfuture.html

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. These are often in more detail than I can fit in here. This also includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware